3 ms·

>Conflating serverside generated code to native app restrictions is nonsensical, they are not the same thing > You did it first. Attestation has nothing to do w

>Conflating serverside generated code to native app restrictions is nonsensical, they are not the same thing > You did it first. Attestation has nothing to do with extentions. First of all, extensions are not serverside code, so... no, that doesn't make any sense. Second of all, attestation has a lot to do with extensions because extensions are based on browser functionality, and attestation impacts which software you can run. In this case, attestation means websites can check to see if you're running modified or forked browsers that might allow for broader extension APIs. And attestation has even more to do with extensions when extended to websites than it normally would because if the point of this is to established "trusted" environments, then arbitrary extension access to a web page means the environment is not trusted. If you allow arbitrary extension access, you can't provide guarantees about whether someone is human or not -- extension APIs allow for automation and scraping and ad fraud. And blocking that behavior is explicitly one of the use-cases listed in this proposal for the integrity API. If this doesn't block extensions, then it's not a useful proposal for blocking bots. Quite literally every single use-case that this proposal lists are impossible if extensions are not restricted. Blocking ad fraud, blocking bots, blocking malware from a banking site, and blocking cheating in web games -- all of that requires blocking extensions. A "trusted environment" the way the proposal describes it can not have arbitrary extension access because extensions can do all of that stuff; from posting automated content to fraudulently clicking on ads to cheating at online games to stealing your bank password. > With attestation doesn't reveal what OS you are using, so it owned still be impossible to reliably block Linux. Do you genuinely think that an Open Linux environment is going to support attestation? We're having a hard enough time getting Passkey to support Linux, there is zero chance that Arch Linux becomes a trusted attestation provider for the Web Environment Integrity API. And if it did, this whole proposal would be useless, because I'd be able to use Headless Chromium on Arch Linux and just have Arch Linux say that my computing environment was secure. There is no definition of "trusted computing environment" for a website provider that doesn't involve blocking access to arbitrary user-controlled code execution at the OS and browser level. Because if you couldn't block that access, you wouldn't have any security guarantees. The entire premise falls apart if fully user-controlled environments are supported. It would be a useless proposal. > And there is a ton of evidence that attestation will be used for DRM and to prevent adblocking > Please share it. https://developer.android.com/google/play/integrity https://developer.android.com/google/play/integrity -- please do any amount of research into how this has played out. > uBlock Origin already objectively runs worse on Chrome than Firefox > I use it just fine on Chrome and do not see any ads. https://github.com/gorhill/uBlock/wiki/uBlock-Origin-works-best-on-Firefox https://github.com/gorhill/uBlock/wiki/uBlock-Origin-works-b... -- this is also not very difficult to look up, I kind of feel like you should have been able to find this link yourself. > FLOC is [another long explanation of why advertisers are the victim and FLOC is actually making the web more private] I have to say again, I don't know if you expect this to sway anyone reading these comments, but it's not going to. No one is going to read that paragraph and think, "you know what, this person probably does care about adblockers and probably is really committed to making sure they're not harmed."

charcircuit 3y ago
>attestation means websites can check to see if you're running modified or forked browsers that might allow for broader extension APIs. It does not tell you what browser the user is using. Websites can not block a specific browser. >Blocking ad fraud, blocking bots, blocking malware from a banking site, and blocking cheating in web games -- all of that requires blocking extensions How does this affect browser modifications and extensions? Web Environment Integrity attests the legitimacy of the underlying hardware and software stack, it does not restrict the indicated application’s functionality: E.g. if the browser allows extensions, the user may use extensions; if a browser is modified, the modified browser can still request Web Environment Integrity attestation. It's about reducing the rate of those things. >Do you genuinely think that an Open Linux environment is going to support attestation? When Linux distributions start to actually care about security yes I do see plenty. >Play Integrity 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. >this is also not very difficult to look up Chrome has worked on CNAME stuff since that was written and most of it does not really matter to most people. >another long explanation of why advertisers are the victim and FLOC is actually making the web more private Advertisers aren't the victim in this situation. It's the users who are losing privacy due to cross site tracking.
- danShumway 3y ago
  > 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? The API isn't supported, what are you talking about :) And if a nearly 20% reduction in adblocking capability doesn't matter to you, great! But don't pretend that it doesn't exist. Chrome objectively has a worse adblocking experience than Firefox. Manifest V3 will make that experience worse. Maybe you don't care about that, which is fine for you, but "this won't affect adblocking" and "meh, what adblocking you'll have will be good enough, stop caring so much about adblocking" are very different arguments. > It's the users who are losing privacy due to cross site tracking. FLOC would not have stopped cross site tracking or improved user privacy. None of the proposals Google made about restricting cross site tracking needed FLOC (Firefox and Safari were able to block cross site cookies just fine without FLOC). In addition, it's not really even accurate to say that Google is clamping down on cross site tracking; in fact First Party Sets exposes mechanisms to treat cross site cookies as if they are first party. Chrome was last to the table on blocking common cross site tracking techniques, specifically because they refused to implement industry wide defenses until they had another user targeting solution implemented. Chrome very literally delayed user privacy improvements until they could make sure that advertisers were taken care of. They were the last browser to add those improvements because they were worried about advertisers more than users. And they immediately proposed specification changes that weakened the user protections that other browsers had already launched.

charcircuit 3y ago

>attestation means websites can check to see if you're running modified or forked browsers that might allow for broader extension APIs. It does not tell you what browser the user is using. Websites can not block a specific browser. >Blocking ad fraud, blocking bots, blocking malware from a banking site, and blocking cheating in web games -- all of that requires blocking extensions How does this affect browser modifications and extensions? Web Environment Integrity attests the legitimacy of the underlying hardware and software stack, it does not restrict the indicated application’s functionality: E.g. if the browser allows extensions, the user may use extensions; if a browser is modified, the modified browser can still request Web Environment Integrity attestation. It's about reducing the rate of those things. >Do you genuinely think that an Open Linux environment is going to support attestation? When Linux distributions start to actually care about security yes I do see plenty. >Play Integrity 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. >this is also not very difficult to look up Chrome has worked on CNAME stuff since that was written and most of it does not really matter to most people. >another long explanation of why advertisers are the victim and FLOC is actually making the web more private Advertisers aren't the victim in this situation. It's the users who are losing privacy due to cross site tracking.

danShumway 3y ago
> 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? The API isn't supported, what are you talking about :) And if a nearly 20% reduction in adblocking capability doesn't matter to you, great! But don't pretend that it doesn't exist. Chrome objectively has a worse adblocking experience than Firefox. Manifest V3 will make that experience worse. Maybe you don't care about that, which is fine for you, but "this won't affect adblocking" and "meh, what adblocking you'll have will be good enough, stop caring so much about adblocking" are very different arguments. > It's the users who are losing privacy due to cross site tracking. FLOC would not have stopped cross site tracking or improved user privacy. None of the proposals Google made about restricting cross site tracking needed FLOC (Firefox and Safari were able to block cross site cookies just fine without FLOC). In addition, it's not really even accurate to say that Google is clamping down on cross site tracking; in fact First Party Sets exposes mechanisms to treat cross site cookies as if they are first party. Chrome was last to the table on blocking common cross site tracking techniques, specifically because they refused to implement industry wide defenses until they had another user targeting solution implemented. Chrome very literally delayed user privacy improvements until they could make sure that advertisers were taken care of. They were the last browser to add those improvements because they were worried about advertisers more than users. And they immediately proposed specification changes that weakened the user protections that other browsers had already launched.