I wonder if we are measuring, and therefore concentrating upon, things that turn out to be only incidental to how much we, or perhaps some of us, feel stress.
Cost of replacement is not relevant as the chip and passport are linked, so need a new passport to get that fixed. Not terribly costly. But annoying given that, like you, it is due to no obvious fault on my part.
However it seems pretty routine. All the face-scanning readers eventually (after several attempts and failures) bubble you up into to a process exception that refers you to a human and you get sent into another queue: this time, to be reviewed by a human.
Unless border control are particularly by the book, most of them will simply accept the explanation, and let me directly into the human queue. Sometimes this works out for the better — for all their cleverness, the automated scanners seem particularly tricky for them to keep working reliably. Other times there's lots of families travelling, and I end up waiting a bit longer.
Either way, I'm glad that most of them are alive enough to the issue that time consuming try/fail/repeat/escalate/re-queue part of the process can be skipped.
We should not be giving money to these mega corps because that also implies giving them our most personal health data. For sure they'll say that we can trust them — maybe it's even true right now, but that can change on a dime, and I don't want to have no option but to trust a crook with no way to pull our public money and my personal data out.
We do need to make things more efficient. But it's lazy of us tech types to fall for centralisation in its most naive form — centralisation of personal data storage always comes with huge risks. We overstate the benefits, and we're not around to pay the price when the benefits fail to pass and the hidden costs creep out.
Instead, we should be pushing the health record out to individuals, and away from the centre. We should own our own data — perhaps it should even reside on our own device. Our governments should be pushing to store less data, not more.
> Instead, we should be pushing the health record out to individuals, and away from the centre
One of my observations was that trusts think the opposite. I was in a call with one, and I said at one point, "Of course, the patient is the Data Owner" and I was corrected by a trust staff member who said, "No, the trust is the Data Owner".
Because - as I learned and saw later - trusts will sell data for studies. So they want the data.
It rather assumes you could enforce them. Those rights will be great against a responsible outfit. But if the data is exposed in a breach, or if the outfit goes rogue (or if a future government decides to change the law and sell your data, as, by the way, the previous Conservatives tried to do), then you're lost.
I thought you may mean that the legal rights provide protection, so one need not worry until deidentification or detachment. Maybe your emphasis was same.
But for clarity, I think we need to worry long before deidentification and detachment — basically the Trusts are not to be trusted, and our legal rights will vanish in a heartbeat.
The mere existence of Tailscale should give a hint that NAT is only a speedbump and not any protection whatsoever. It protects you against nothing. Every method that Tailscale uses to traverse NAT can be in isolation used by any other piece of software. For more info about that you can read the following article.
What people really want is a firewall, and since NAT acts as a firewall, they confuse it with that.
My university has a public IP for every computer, but you could still only connect to the servers, not random computers, from the outside. Because they had a firewall.
What ordinary people (as opposed to IT departments) really want is firewall that can't be accidentally disabled by pushing an overly permissive firewall rule.
NAT/port forwarding, for all their faults make it rather difficult to write rules allowing traffic to a machine you didn't intend to expose to the world.
Yeah but the average person wouldn't know to set up a firewall (and can't count on their ISP to have their best interests at heart.) Therefore the general public benefits from the degree of protection that NAT provides.
Then just enable the firewall by default, or don't even provide a way to disable it unless the user enters "developer/advanced/Pro (tm)" mode. None of these are valid excuses for NAT.
"not any protection whatsoever" is way too strong a statement. NAT does raise the bar to exploiting a random smart lightbulb in your house significantly higher.
The big distinction is that for Tailscale both endpoints know they want to talk to each other, and that both have Internet access. That's not the usual case firewalls are designed for.
Tailscale doesn't strictly need NAT traversal. They can run only their DERP servers and still continue to work. If your firewall tries to block two devices from communicating and yet allows both devices internet access, you have already lost.
Sounds like you like the idea of a stateful firewall, and good news: There are stateful firewalls for IPv6!
They have all the upsides of NATs (i.e. an option to block inbound connections by default), with none of the downsides (they preserve port numbers, can be implemented statelessly, they greatly simplify cooperative firewall traversal, you can allow inbound connections for some hosts).
I found it weird that IPv6 folks are so against NAT as a cultural thing when it works perfectly well on IPv6. They're not fundamentally opposed.
I could have all of my servers in public subnets and give them all public IP addresses, but I still prefer to put everything I can in private. Not only does the firewall not allow traffic in, but you can't even route to them. It now becomes really hard to accidentally grant more access than you intended.
I would hazard that most devices on there internet are in the boat of want to talk to the internet but not be reachable on it.
Yea IPv6 folks are indeed against NAT philosophically because it's considered one of the big mistakes of IPv4.
There is a distinction between being publicly addressable and publicly routable. You can have the former without having the latter.
If you want more private addresses, IPv6 has a solution too: use ULAs and not GUAs. Design your internal network so it has mostly ULAs for application servers, database servers and the like, except for the reverse proxy having both publicly accessible GUAs as well as ULAs for talking to the rest of the network.
I personally use ULAs and GUAs concurrently on my network, because I have a residential ISP where my GUA prefix is not fixed.
I'm not opposed to anyone voluntarily using a NAT at all. I just hate it when somebody makes that decision for me, and that unfortunately still happens all the time.
If it's a well-reasoned decision, sure, but I do suspect that more often than not it's a lack of knowledge about alternatives that makes people still opt for NATs, and that just makes me sad on top of being annoyed with the inconvenience of having to tunnel when a direct connection seems so close at hand.
> I would hazard that most devices on there internet are in the boat of want to talk to the internet but not be reachable on it.
I highly doubt that. One big example is VoIP: Incredibly common these days, yet so much of it is going through centralized relays, and often for absolutely no technical reason.
For a personal network where you decide to use NAT on ipv6? Sure, go ahead.
Being forced into a CGNAT on ipv6 is just a dick move though. And I believe that's the kinda NAT that has coloured the opinions of most NAT for ipv6 detractors.
If you don't want that, then complain about a lacking a configuration as such and configure your firewall so that that they can't. But don't cheer on something that's breaking functionality that others might want (especially if it doesn't actually achieve your own goals reliably).
But to your point about not cheering on NAT, well I will because I see NAT as useful tool.
It is not an opinion well aligned with the preferences of the IETF. But the purist model of transparent end-to-end networking has never sat well with me. It’s just not a thing we want.
So because you don't want it means that nobody can get it?
Because that's what happens if you advocate for NAT by default. Conversely, with "IPv6 + inbound-blocking-firewall on CPEs by default", everybody gets the same behavior by default, and people that want something else can get that instead.
A telematics tracker in a vehicle that logistic companies use (e.g. Amazon, FedEx) is also considered as an IoT device. I don't believe that the author is talking about Smart Home appliances exclusively.
Same, but ISTR we had some Cisco gear where NAT (or PAT as they insisted; yes, I know difference; no, no one cared) had a different license or hardware requirement or something from firewall rules.
I agree until I discover I'm doing something where I want to access/change that device. It is really nice when I'm returning home early that I can change my thermostat out of vacation mode. I've often wished I had a way to tell if I left a door unlocked.
Security and privacy is of course critical to all this, but the concept of internet itself is not wrong.
That's what a VPN is for. Every router I've had in the past decade has had support for running a VPN server so you can have one running 24/7 without any additional hardware. Even my retired elderly parents run a VPN server on their home router.
I hope you're not implying that allowing IoT devices access to the internet is not a massive security vulnerability. IoT devices are notoriously insecure and poorly maintained. I'd much rather have LAN-only IoT devices and an internet-accessible VPN server than letting IoT devices access the internet.
But theirs uses certificates (the router UI generates the openvpn client config files with the certificate embedded inside it) and no, they do not understand the security implications between those two choices.
Mine is a wireguard VPN with both the pub/priv keypair and PSK.
I'm implying that a VPN is not a "silver bullet." In particular since they don't understand the model, are stuck with a vendor implementation, and probably never update their router firmware.
There's a reason IoT vendors try to do this all "in device."
The problem is that OKRs are divorced from the “go do this piece of work” instruction, and so, just like code comments, they quickly become out of date or are outright ignored.
Because of that, the prescription about SMART and focus on delivery is simply wasted effort. At best a duplication.
The good part about OKRs is (/should be) that it forces an alignment conversation between teams and amongst managers. And the performance discussion with manager is often useful and sometimes revealing. More often both focus on metrics, losing the last opportunity to extract value from the concept.
There was an absolute willingness to allow views in support of a fear narrative win through. (No matter their grounding.) The probing/questioning threads were quickly closed down.
Some of it was done by the social media companies acting at the direction of the state. But much of it was actioned by military information security units acting against the general population.
But I think you hit the nail on the point that “it is actionable”.
You argue any such conclusion is not actionable. But it is, and to make example, one can imagine that senators will be more circumspect in sponsoring labs to do this kind of work. If no one held the opinion, they wouldn’t care a hoot.
Is it a certainty? For sure it’s not. But having opinions is worthwhile.
If our hypothetical $1 common cold pill turns out anything like our COVID pill, it will only be effective for a few months before making you marginally more susceptible than you were before.
Although I suppose it's good that it's getting studied.
reply