Both can be true at the same time. I currently wouldn't waste my time with open models for almost all use cases, but they're crucial from a data privacy and competitive perspective, and I can't wait for them to catch up enough to be as useful as the current frontier models.
Android actually supports secure transaction confirmation on Pixel devices using a secure second OS that can temporarily take control of the screen and volume button as secure input and output! https://android-developers.googleblog.com/2018/10/android-pr...
This is really cool and goes beyond the usual steps of securing the key, but handling "what you see is what you sign" and key usage user confirmation at the OS level, which can be compromised much more easily (both input and output).
Quote: "Android Protected Confirmation is deprecated due to the high
support/maintenance cost for Android device makers and low adoption rate
among app developers. APC requires Android device makers to have a
substantial amount of device-specific UI code running in the trusted
execution environment. That has proven to be expensive to maintain and
non-scalable, as there cannot be a single implementations device makers
can share or use as a reference. Additionally, app developers have not
adopted this feature, as the Android platform offers other mechanisms
for authentication a user's intent. These mechanisms, such as
authentication-bound Keystore keys, are less secure than Trusted UI, but
are more wide-spread. While we explore alternatives to APC that are
viable to the device makers ecosystem, we sunset the APC API."
Oh damn, I missed that, thank you. I could see how it was a very expensive thing to maintain for an effectively Pixel-only feature.
Still, I think this was one of the most ambitious and user-beneficial implementations of trusted computing I've seen so far, in that it theoretically safely allows a completely rooted/user-owned device to still participate in things like online banking or e-government transaction authorization. I hope it'll return in some form.
That's still an improvement. In sophisticated attacks, attackers might well store stolen credentials and use them at a later, more opportune time.
Of course a real secure attention sequence would be preferable, such as e.g. requiring a Touch ID press on macOS for keys stored in the Secure Enclave. Not sure if TPM supports something similar when a fingerprint sensor is present?
That’s DNS64, which is pretty annoying in practice. (For one thing, you can’t use your own DNS server anymore, but more importantly, anything using v4 literals will 100% break.)
What’s nicer is 464XLAT, or more generally NAT64 prefix announcements. Then your local OS can just synthesize NAT64 addresses from v4 literals, either at the socket library or kernel networking (via “bump in the stack” translation) layer.
No idea, but people do it. Every time this comes up on HN there are dozens of comments about how they like hiding their devices behind a NAT, for security
Just because people regularly bring up a non sequitur doesn't mean there actually is a problem.
"I have a device acting as both a NAT and a stateful firewall, why are you making me switch to IPv6 and in the process drop both the NAT and the stateful firewall?" is a non sequitur.
I think we're talking about two different things, or maybe I just don't understand your reply.
What I'm saying is this: There exist people in the hobbyist space who believe that when their devices only have private IPv4 addresses such as 192.168.0.0/16 that this meaningfully increases their network security, and that if their raspberry pi has a globally-routable v6 address that this weakens their network security, even though this is bogus because NAT is orthogonal to network security considerations, and that this belief contributes to IPv6 hesitancy.
That sounds more like broken support then. Not having any support at all (i.e. A records or v4 literals only) should just send you to whatever v4 transition technology your ISP offers, no?
There are also still Telex and X.25 networks around there, not to forget the whole public telephone network!
But at some point, getting a native connection to all of these started becoming increasingly rare, and now these are largely emulated/tunneled on top of IP. The same can happen for IPv4.
IPv4 is provided using DS-Lite or MAP-E depending on the provider.
I'm using OpenWRT and paid for a static IP so I had to manually configure all the details for the MAP-E tunnel in OpenWRT myself, I think typically the routers sold to consumers pick up the configuration automatically somehow.
Which provider are you using? I'm curious about this since there are not many OpenWrt guides for getting connected in Japan. Is your config similar to this write-up? https://github.com/fakemanhk/openwrt-jp-ipoe
I didn't need to do any configuration for DS-Lite or MAP-E, as DHCPv6 with a configured prefix got IPv6 working, although DNS is still broken when turning off IPv4 entirely.
Of course there's an incredibly long tail here, but in the big picture, "nobody except some people maintaining a few legacy systems ever need to learn to work with this protocol anymore" is practically the same thing.
reply