>It's like saying that Play Integrity doesn't tell you if the user is running LineageOS, so it doesn't mean that apps can block LineageOS. This is not a serious argument.
But, it's true. Since LineageOS doesn't break Android's security model they could work with phone manufacters / Google to allow LineageOS to be trusted. Then apps would not be able to tell via play integrity that it could be lineageos since it looks like any other trusted device.
>There is zero evidence this will reduce the rate of those things.
I think this is fair criticism of the proposal. If it's not effective in practice then sites won't invest time in using it since it's a pointless API.
>Regardless, blocking Headless Chromium on its own is a restriction of user autonomy and a restriction of user freedom.
This API is not about blocking headless chromium.
>but people are still getting their bank passwords stolen by malicious extensions, lock the extensions down too
Protecting against that is unrelated to this proposal.
>:) Come on. Linux security is not the reason it would be blocked in these situations
Considering most Linux users are 1 curl | bash away from installing malware that can easily pivot to root and install a kernel module to hide itself. It's related.
>and three of them are about preventing the user from doing actions that the website owner considers harmful.
Can you quote that section. I don't see it.
>it is a proposal about blocking off user capabilities that website authors would rather the user not have.
Except this proposal doesn't block any user capabilities. It simply adds a way for sites to check if the user has a secure environment.
>That is the reason why attestation won't be coming to Linux: because Arch Linux won't lock me out of my own system and prevent me from running software that I choose.
Arch could simply have in their settings app a toggle that allows you to disable trusted mode to allow you to install kernels or whatever you built yourself. Similar to how motherboards let you disable secure boot.
>it does not escape my notice that you haven't provided an argument for why Linux won't be blocked
Firstly, this proposal isn't about blocking people. Secondly, their will be many Android bsed Linux distros that will be considered secure. For the Debians and Archs of the world they will need to work with others and prove they can provide a trusted environment. I believe this is possible and I think something similar happened in relation to secureboot.
>"it does block an OS and that's actually a good thing to do."
I never said that it was a good thing to do.
>Rooting an Android device is the part we're talking about and the part this has implications for.
Rooting breaks the android security model and provides by definition an untrusted environment. Android apps may not want to deal with supporting devices that don't support the security features an Android operating system is supposed to provide.
>It is extremely likely that Google would use the same underlying system and that Android would refuse to provide attestation for apps that aren't from the Play Store.
The Play Integrity API works with apps not from the store.
>
danShumway 26 minutes ago | parent | context | flag | on: Web Environment Integrity API Proposal
> It does not tell you what browser the user is using. Websites can not block a specific browser.
This is unbelievably silly. It's like saying that Play Integrity doesn't tell you if the user is running LineageOS, so it doesn't mean that apps can block LineageOS. This is not a serious argument.
> It's about reducing the rate of those things.
Again, this is incredibly silly. There is zero evidence this will reduce the rate of those things. Extensions are very likely the most common vector for this.
And if you genuinely can't see a clear path in this proposal where website operators will say, "we can block Headless Chromium, but people are still getting their bank passwords stolen by malicious extensions, lock the extensions down too" -- then, I don't know, it must be nice to be able to somehow trust corporations that much despite the entire history of how advertisers and corporations have interacted with the web standards process.
Regardless, blocking Headless Chromium on its own is a restriction of user autonomy and a restriction of user freedom. That is still blocking me from using a specific browser. And if your argument is that scriptable browsers aren't going to be blocked, then this entire proposal is a waste of time.
This proposal will affect extensions for obvious reasons, but even if it didn't it would still be a problem.
> When Linux distributions start to actually care about security yes I do see plenty.
:) Come on. Linux security is not the reason it would be blocked in these situations, user agency to run headless browsers like Headless Chromium is the reason it would be blocked.
You're trying to shift this conversation to be about security, but security is only one of four use-cases proposed, and three of them are about preventing the user from doing actions that the website owner considers harmful. This is not primarily a security proposal, it is a proposal about blocking off user capabilities that website authors would rather the user not have.
That is the reason why attestation won't be coming to Linux: because Arch Linux won't lock me out of my own system and prevent me from running software that I choose.
Of course, it does not escape my notice that you haven't provided an argument for why Linux won't be blocked, you've provided an excuse for why Linux should be blocked. What you're telling me is "yes, your device won't support attestation and you won't be able to use your bank website on that device, but that's Linux's fault. And maybe eventually Linux will support attestation in the future."
Okay, it's nice to know I'll only be locked out using the OS I prefer for an ambiguous amount of time until it caves and meets an unspecified standard of security at some unspecified point in the future. But I'm still going to be blocked from Linux. And you've moved from "this doesn't block an OS" to "it does block an OS and that's actually a good thing to do."
> Play Integrity covers both attesting to if the system is in a secure state and if the app you are running is from the play store. This proposal only has an equivalent for the former.
Luckily the former is the part I care about and is the primary part that is abused. Rooting an Android device is the part we're talking about and the part this has implications for. You started out this conversation by asking me to read the proposal. Let me extend the same request to you: please do some research on this.
Also, please don't make claims that aren't substantiated about how attestation will work. This proposal does not specify that attestation on Android wouldn't use the Play Integrity API. It is extremely likely that Google would use the same underlying system and that Android would refuse to provide attestation for apps that aren't from the Play Store.
Nothing in this proposal preempts them from doing that, there is no reason to trust you when you say that sideloaded apps will be able to pass attestation. The proposal specifically does not lay out what attestation requirements will be.
> Chrome has worked on CNAME stuff since that was written and most of it does not really matter to most people.
"Chrome works on CNAME stuff": where?
https://bugs.chromium.org/p/chromium/issues/detail?id=118065...
Chrome now handles CNAME aliases internally: https://bugs.chromium.org/p/chromium/issues/detail?id=1151047.
We also now plan to support this for extensions as part of declarativeNetRequest API.
The linked issue shows CNAME support being added to at least Chrome's built in adblocker.
>FLOC would not have stopped cross site tracking or improved user privacy
Yes, but the plan was that after FLOC cross site cookies would not be sent. The whole point is to provide an alternative to people using cross site cookies before it gets removed.