Most active commenters
  • kelnos(4)

←back to thread

656 points EthanHeilman | 14 comments | | HN request time: 0.042s | source | bottom
Show context
staticassertion ◴[] No.30102061[source]
This is pretty incredible. These aren't just good practices, they're the fairly bleeding edge best practices.

1. No more SMS and TOTP. FIDO2 tokens only.

2. No more unencrypted network traffic - including DNS, which is such a recent development and they're mandating it. Incredible.

3. Context aware authorization. So not just "can this user access this?" but attestation about device state! That's extremely cutting edge - almost no one does that today.

My hope is that this makes things more accessible. We do all of this today at my company, except where we can't - for example, a lot of our vendors don't offer FIDO2 2FA or webauthn, so we're stuck with TOTP.

replies(15): >>30103088 #>>30103131 #>>30103846 #>>30104022 #>>30104121 #>>30104716 #>>30104840 #>>30105344 #>>30106941 #>>30107798 #>>30108481 #>>30108567 #>>30108916 #>>30111757 #>>30112413 #
c0l0 ◴[] No.30104121[source]
I think 3. is very harmful for actual, real-world use of Free Software. If only specific builds of software that are on a vendor-sanctioned allowlist, governed by the signature of a "trusted" party to grant them entry to said list, can meaningfully access networked services, all those who compile their own artifacts (even from completely identical source code) will be excluded from accessing that remote side/service.

Banks and media corporations are doing it today by requiring a vendor-sanctioned Android build/firmware image, attested and allowlisted by Google's SafetyNet (https://developers.google.com/android/reference/com/google/a...), and it will only get worse from here.

Remote attestation really is killing practical software freedom.

replies(16): >>30104148 #>>30104166 #>>30104241 #>>30104603 #>>30105136 #>>30106352 #>>30106792 #>>30107048 #>>30107250 #>>30107515 #>>30108070 #>>30108409 #>>30108716 #>>30108754 #>>30109550 #>>30123243 #
1. reginaldo ◴[] No.30104241[source]
It depends on the level of attestation required. A simple client certificate should suffice for the majority of the non-DoD applications.
replies(1): >>30105519 #
2. kelnos ◴[] No.30105519[source]
It "should" suffice, but entities like banks and media companies are already going beyond this. As the parent points out, many financial and media apps on Android will just simply not work if the OS build is not signed by a manufacturer on Google's list. Build your own Android ROM (or even use a build of one of the popular alternative ROMs) and you lose access to all those apps.
replies(3): >>30105961 #>>30107238 #>>30110457 #
3. ethbr0 ◴[] No.30105961[source]
The clearer way to put this is: when faced with a regulatory requirement, most of the market will choose whatever pre-packaged solution most easily satisfies the requirement.

In the case of client attestation, this is how we get "Let Google/Apple/Microsoft handle that, and use what they produce."

And as a end state, leads to a world where large, for-profit companies provide the only whitelisted solutions, because they're the largest user bases and offer a turn-key feature, and the market doesn't want to do addition custom work to support alternatives.

replies(1): >>30108879 #
4. bigiain ◴[] No.30107238[source]
I’m not even so sure I’m totally against banks doing that either.

From where I sit right now, I have within arms reach my MacBook, a Win11 Thinkpad, a half a dozen Raspberry Pis (including a 400), 2 iPhones only one of which is rooted, an iPad (unrooted) a Pinebook, a Pine Phone, and 4 Samsung phones one with its stock Android7 EOLed final update and three rooted/jailbroken with various Lineage versions. I have way way more devices running open source OSen than unmolested Apple/Microsoft/Google(+Samsung) provided Software.

My unrooted iPhone is the only one of them I trust to have my banking app/creds on.

I’d be a bit pissed if Netflix took my money but didn’t run where I wanted it, but they might be already, I only ever really use it on my AppleTV and my iPad. I expect I’d be able to use it on my MacBook and thinkpad, but could be disappointed, I’d be a bit surprised if it ran on any of my other devices listed…

replies(3): >>30108219 #>>30109286 #>>30156528 #
5. mindslight ◴[] No.30108219{3}[source]
Putting a banking app on your pocket surveillance device is one of the least secure things you can do. What happens if you're mugged, forced to login to your account, and then based on your balance it escalates to a kidnapping or class resentment beatdown? Furthermore, what happens if the muggers force you to transfer money and your bank refuses to roll back as unauthorized because their snake oil systems show that everything was "secure" ?
6. withinboredom ◴[] No.30108879{3}[source]
In my experience, it isn’t that companies don’t want to put in the work, it’s that some middle manager made a decision. I’ve been told to “implement login with X” more than once in my career and when asked what about Y or Z, they say, “we only want X” with no further explanation.
7. nijave ◴[] No.30110457[source]
For something like LineageOS, ironically, the solution is to root your device to adjust build properties so it looks signed.

My vanilla LineageOS install fails but I can root with Magisk, enable Zygisk to inject code into Android, edit build properties, add SafetyNet fix and now my device is good to go?

It's crazy to think the workaround is "enable arbitrary code injection" (Zygisk)

replies(2): >>30113995 #>>30156501 #
8. ece ◴[] No.30113995{3}[source]
This, or we could have dual booting that's relatively as easy to do on mobile as it is on PCs.

Currently, you'd have to do find an unlocked phone, hope there is a downloadable factory image, re-flash, re-lock, re-install to run whatever needs attestation. Potentially using something like Android's DSU feature, this could all be a click or two, and you could be back running Lineage with a restart.

replies(1): >>30156509 #
9. kelnos ◴[] No.30156501{3}[source]
Yeah, that's the crazy thing: that this entire "verification" house of cards can be so easily defeated by just faking the response to an API call from code that you can control (after unlocking your bootloader and installing your own code). I guess this is why there is a push to stop allowing bootloaders to be unlocked.
replies(1): >>30176675 #
10. kelnos ◴[] No.30156509{4}[source]
I mean... no thanks? I remember dual-booting Windows and Linux (and macOS and Linux) for years back in the 00s, and it was inconvenient and annoying. I don't want to go back to that, even (especially?) on a phone.
replies(1): >>30189186 #
11. kelnos ◴[] No.30156528{3}[source]
> I’m not even so sure I’m totally against banks doing that either.

The hole in this reasoning is that you don't need the app; you can just sign into the bank's website from the mobile browser, and get all the same functionality you'd get from the app. (Maybe you don't get a few things, like mobile check deposits, since they just don't build features like that into websites for the most part.) The experience will sometimes be worse than that of the app, but you can still do all the potentially-dangerous things without it. So why bother locking down the app when the web browser can do all the same things?

> I’d be a bit pissed if Netflix took my money but didn’t run where I wanted it

I actually canceled my HBO Max account when, during the HBO Now -> HBO Max transition, they somehow broke playback on Linux desktop browsers. When I wrote in to support, they claimed it was never supported, so they weren't obligated to care. I canceled on the spot.

12. nijave ◴[] No.30176675{4}[source]
Even locked bootloaders only help a little. Afaik all iOS devices have locked bootloaders but that doesn't stop jailbreaking. I imagine Android, with spotty vendor support track record, would be even easier
replies(1): >>30189262 #
13. ece ◴[] No.30189186{5}[source]
Dual booting isn't so bad, I've almost always had a gaming partition somewhere, while my current install doesn't even run 32-bit binaries. That said, attestation should be possible with user-locked bootloaders, not just vender-locked bootloaders. I suppose Magisk provides something close to this currently with bootloaders that can't be re-locked for custom roms, so more power to it.
14. ◴[] No.30189262{5}[source]