Live data from Hacker News

I read the federal government’s Zero-Trust Memo so you don’t have to

bastionzero.com

361–369 of 369 posts

Re: I read the federal government’s Zero-Trust Memo so you don’t have to

#361
post #98

Earlier quoted context omitted.

The thing I don't get about the non-religious arguments is that we already have a national ID, it's just a patchwork system of unreliable, not-particularly-secure forms of identification that are a pain in the ass for a regular citizen to have to deal with. And the REAL ID stuff essentially makes state IDs conform to a national ID specification anyway. And regardless, if you do want a national US ID, you just get a p…

Many State governments do not recognize a US passport as valid ID. This was unexpected when I first encountered an example of it, but apparently that is normal and I was just the last person to find out. The REAL ID legislation only regulates processing and format, there is no enforceable requirement to share that with the Federal government and many States (both red and blue) do not in practice. States recognize the…

> Many State governments do not recognize a US passport as valid ID.

Whoa, I did not know this. That's wild.

Re: I read the federal government’s Zero-Trust Memo so you don’t have to

#362
post #98

Earlier quoted context omitted.

The thing I don't get about the non-religious arguments is that we already have a national ID, it's just a patchwork system of unreliable, not-particularly-secure forms of identification that are a pain in the ass for a regular citizen to have to deal with. And the REAL ID stuff essentially makes state IDs conform to a national ID specification anyway. And regardless, if you do want a national US ID, you just get a p…

> The thing I don't get about the non-religious arguments is that we already have a national ID, it's just a patchwork system of unreliable, not-particularly-secure forms of identification Yes, and this unreliable patchwork is already being heavily abused by surveillance companies (eg Equifax, Google, LexisNexis, Facebook, Retail Equation, etc) involuntarily storing our personal information - creating permanent recor…

> Before there is any talk of strengthening identification, we need a US GDPR codifying a basic right to privacy.

That's a fair point, agreed. Privacy needs to be legally recognized as a strong right before we allow more centralization of this sort of thing. (Though sadly it's already pretty centralized, just not by the federal government.)

Re: I read the federal government’s Zero-Trust Memo so you don’t have to

#363
post #242
post #88

Earlier quoted context omitted.

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.

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)

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.

Re: I read the federal government’s Zero-Trust Memo so you don’t have to

#364
post #301
post #242

Earlier quoted context omitted.

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)

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.

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.

Re: I read the federal government’s Zero-Trust Memo so you don’t have to

#365
post #88

Earlier quoted context omitted.

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.

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 w…

> 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.

Re: I read the federal government’s Zero-Trust Memo so you don’t have to

#366
post #363
post #242

Earlier quoted context omitted.

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)

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.

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

Re: I read the federal government’s Zero-Trust Memo so you don’t have to

#367
post #61

Earlier quoted context omitted.

Somewhat unrelated, but hopefully this also means TreasuryDirect will get rid of its archaic graphical keyboard that disables the usage of password managers. (Graphical keyboards are an old technique to try to defeat key loggers. A frequent side effect of a site using a graphical keyboard is that the developer has to make the password input field un-editable directly, which prevents password managers from working, un…

Just saying in this in case it will help you. For treasurydirect, you can use inspect element and change the value="" field on the password element, and paste in your password from your password manager. It's not as convenient as autofill from your password manager, but it sure beats using the graphical keyboard.

Thanks! That would definitely be a way to do it. I was hinting at something similar by saying "unless you use a user script to make the field editable again". You could also run a bookmarklet that makes the input editable using JavaScript, and then using the password manager. But it's a pain in any case if you're using the site on a mobile device.

Re: I read the federal government’s Zero-Trust Memo so you don’t have to

#368
post #364
post #301

Earlier quoted context omitted.

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.

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.

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.

Re: I read the federal government’s Zero-Trust Memo so you don’t have to

#369
post #366
post #363

Earlier quoted context omitted.

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.

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

[deleted]
Post reply on HN