Most active commenters
  • lern_too_spel(7)
  • ori_b(3)

←back to thread

Unpacking Google’s Web Environment Integrity specification

(vivaldi.com)
756 points dagurp | 22 comments | 26 Jul 23 11:30 UTC | HN request time: 1.12s | source | bottom
Show context
rcxdude ◴[26 Jul 23 18:15 UTC] No.36882331[source]▶
This is especially rich coming from google's, who's 'safetynet' for android results in a significant reduction in security (contrary to its stated purpose): it locks out 3rd-party up-to-date and secure ROMs while allowing horrificly insecure manufacturer-provided ROMs to still pass, because to disable those would cause a massive user outcry. So it functions as a vendor lock-in but no meaningful increase in security for the average user, while preventing more advanced users from improving their security without needing to buy more hardware. This needs to be called out more to push back against the claim that this kind of attestation somehow has a legitimate benefit for the users.
replies(6): >>36882444 #>>36883913 #>>36884154 #>>36885533 #>>36885781 #>>36890534 #
1. lern_too_spel ◴[26 Jul 23 20:07 UTC] No.36884154[source]▶
You're using it wrong. SafetyNet is able to assert that the build the device asserts is what it claims. After you know that, it's up to you to decide whether you trust communications from that build or not. If it's a known-insecure build, you can say that you don't. SafetyNet cannot assert that a third party ROM is what it claims to be, so you have to decide whether you trust communications from that device or not based on not knowing at all what build is on the device.
replies(5): >>36884229 #>>36884517 #>>36884788 #>>36885296 #>>36886555 #
2. wmf ◴[26 Jul 23 20:12 UTC] No.36884229[source]▶
Does anyone use SafetyNet "right"? I assume not due to the user outcry issue.
replies(1): >>36884350 #
3. lern_too_spel ◴[26 Jul 23 20:19 UTC] No.36884350[source]▶
Most (all?) corporate endpoint security systems use it right in my experience. Even when using it right, you would have to block third party builds and cause outcry. You would additionally block some builds that SafetyNet (or Play Integrity) attests.
replies(2): >>36885261 #>>36890240 #
4. realusername ◴[26 Jul 23 20:30 UTC] No.36884517[source]▶
Then you are back to square one pretty much since the safetynet result doesn't tell you anything about the security of the device.
5. ori_b ◴[26 Jul 23 20:49 UTC] No.36884788[source]▶
In other words, it's virtually impossible to use right without also being the entity that hands out phones to users.
replies(1): >>36885527 #
6. franga2000 ◴[26 Jul 23 21:24 UTC] No.36885261{3}[source]▶
> Even when using it right, you would have to block third party builds

Unless you have an obvious and accessible way of getting secure third party builds whitelisted, this is still a very anti-user approach, which is not justifiable unless the user of the device isn't its owner (like with company-owned work phones).

replies(1): >>36885561 #
7. ◴[26 Jul 23 21:26 UTC] No.36885296[source]▶
8. lern_too_spel ◴[26 Jul 23 21:44 UTC] No.36885527[source]▶
Potentially, a manufacturer could make a multibuild phone where the user could switch between an attested build and a non-attested build and have access to services whose security requires attestation with just a reboot. Otherwise, you would use different devices for different purposes, as I do today. It's unfortunate, but if you really need something that isn't supported by the existing Android APIs, that's the only way.
replies(1): >>36886596 #
9. lern_too_spel ◴[26 Jul 23 21:47 UTC] No.36885561{4}[source]▶
That's up to the service to decide on the appropriate level of security risk in whether they allow unknown builds. They already don't allow custom builds on any other mobile OS, so this is really the best you can get as a user. What is your proposed solution?
replies(2): >>36886886 #>>36888921 #
10. lxgr ◴[26 Jul 23 23:22 UTC] No.36886555[source]▶
> so you have to decide whether you trust communications from that device

"You" in this scenario being, most likely, an engineer at a large, regulated, risk-averse corporation that might have to justify this choice during an audit.

What would your decision be?

11. ori_b ◴[26 Jul 23 23:28 UTC] No.36886596{3}[source]▶
Or, just don't do remote attestation. The cure is worse than the disease.
replies(2): >>36887093 #>>36887140 #
12. justinclift ◴[26 Jul 23 23:58 UTC] No.36886886{5}[source]▶
> They already don't allow custom builds on any other mobile OS ...

Keep in mind that Pinephones and similar are a thing. Lots of people are hoping they don't fizzle out and die off like previous "open" phone projects. :)

replies(1): >>36887021 #
13. lern_too_spel ◴[27 Jul 23 00:15 UTC] No.36887021{6}[source]▶
And Pinephones and similar don't have apps for these services that require attestation and never will. If some allow web access without build attestation, that works on custom Android builds as well.
14. simbolit ◴[27 Jul 23 00:21 UTC] No.36887093{4}[source]▶
That is viable in 2023.

Think about "don't use a smartphone" in 2013. That was viable back then.

It isn't anymore. What you can do is live smartphone-lite, using it only as a secondary device (as grandparent suggested). The same will be true in a couple years (if the big G is successful). Until, then, yea, don't use it, actively campaign against it.

replies(1): >>36894776 #
15. lern_too_spel ◴[27 Jul 23 00:26 UTC] No.36887140{4}[source]▶
Good luck convincing corp security to allow you to use your device on your corporate network without remote attestation.
replies(1): >>36887915 #
16. ori_b ◴[27 Jul 23 01:58 UTC] No.36887915{5}[source]▶
I don't use personal devices on corporate networks. If they want a phone with remote attestation, they can pay for it to sit in a drawer.

Though, at this point I am the founder of my own company. Any software we use will not require attestation. I would be willing to switch vendors over that.

As for web attestation: the software I use regularly needs to run on OpenBSD. It's that simple.

17. Dylan16807 ◴[27 Jul 23 04:28 UTC] No.36888921{5}[source]▶
> What is your proposed solution?

Ban attestation methods that owners can't control.

replies(2): >>36892142 #>>36972537 #
18. realusername ◴[27 Jul 23 07:42 UTC] No.36890240{3}[source]▶
> Most (all?) corporate endpoint security systems use it right in my experience.

I've never seen a usage of Safetynet which I would consider right, pretty much everybody thinks it creates some kind of "security" whereas it doesn't.

One very rare useful usage for it could be removing bots for game leaderboards but certainly not banking apps.

19. hoffs ◴[27 Jul 23 11:55 UTC] No.36892142{6}[source]▶
What does that even mean? It sounds like your proposal makes attestation pointless since owner can attest in whatever way they want.
replies(1): >>36899235 #
20. thefurdrake ◴[27 Jul 23 15:09 UTC] No.36894776{5}[source]▶
If this happens the way google wants, I'll have to have a separate physical box set up specifically to access google's shiternet for things like banking and shopping. I'd be glad to stick to websites that have no need or interest for WEI otherwise.

The internet was already going increasingly-downhill anyway.

thisisfine.png

21. Dylan16807 ◴[27 Jul 23 19:55 UTC] No.36899235{7}[source]▶
It only makes it pointless for DRM purposes.

If a company wants control over devices they own, that's still fine.

22. lern_too_spel ◴[02 Aug 23 15:49 UTC] No.36972537{6}[source]▶
So regulation. I can get into that. Until such regulation exists, phone manufacturers have no incentive to maintain different SKUs.