4 ms·

Google employee responds to negative feedbacks on WEI

45 points by luag 3y ago

voytec 3y ago
> WEI’s goal is to make the web more private and safe Yeah, hopefully you can sleep better telling yourself that. > An owner of this repository has limited the ability to comment to users that have contributed to this repository in the past. Fucking joke.
rolph 3y ago
https://www.ftc.gov/about-ftc/contact https://www.ftc.gov/about-ftc/contact
- voytec 3y ago
  Quoting this[1] commit comment: US: https://www.ftc.gov/enforcement/report-antitrust-violation antitrust@ftc.gov EU: https://competition-policy.ec.europa.eu/antitrust/contact_en comp-greffe-antitrust@ec.europa.eu UK: https://www.gov.uk/guidance/tell-the-cma-about-a-competition-or-market-problem general.enquiries@cma.gov.uk India: https://www.cci.gov.in/antitrust/ https://www.cci.gov.in/filing/atd [1] https://github.com/chromium/chromium/commit/6f47a22906b2899412e79a2727355efa9cc8f5bd#commitcomment-122762976 https://github.com/chromium/chromium/commit/6f47a22906b28994...
mikelward 3y ago
I think the actual comment is this one? https://github.com/RupertBenWiser/Web-Environment-Integrity/issues/28#issuecomment-1645329286 https://github.com/RupertBenWiser/Web-Environment-Integrity/... On my phone this is collapsed and hard to find by default.
- mthoms 3y ago
  That one is 5 days old. The one being referenced is https://github.com/RupertBenWiser/Web-Environment-Integrity/issues/28#issuecomment-1651129388 https://github.com/RupertBenWiser/Web-Environment-Integrity/...
haburka 3y ago
Amazingly clever that they have hold backs! Make sure to read this before going along with the anti WEI train > WEI prevents ecosystem lock-in through hold-backs > We had proposed a hold-back to prevent lock-in at the platform level. Essentially, some percentage of the time, say 5% or 10%, the WEI attestation would intentionally be omitted, and would look the same as if the user opted-out of WEI or the device is not supported. So this avoids the DRM or blocking certain browsers issue. Brilliant. I’m not entirely certain but I think this avoids the main issues which people had with the proposal. I still think a lot of people will not read this and react with vitriol but I would like to expect more from hacker news, as a forum where people don’t simply downvote opinions they disagree with.
- steve_avery 3y ago
  The existence of a configuration that limits attestation to a probabilistic phenomenon seems like a very thin foundation to stand on here - if it can be changed to requiring 100% attestation rate in the future I think it will be changed as soon as it is feasible to do so. I haven't reviewed the proposal enough to see how they implemented that, and if it was done in a cryptographic way that prevents changing to 100%, then that could work. But the fact remains that control of our browsing computing environment is diminishing under this proposal.
  - haburka 3y ago
    It seems to me that “if it can be changed to 100% attestation rate in the future, it will be done” is a slippery slope argument and assuming bad faith on behalf of the proposal writer. I think if it were changed to be 100% then it would be problematic. Also it seems the proposal writer would also agree that some form of opt out is required to make it viable so as to not forbid unknown clients. I think its important to stay away from considering potential “what ifs” that completely defy the intent of the spec. For an example of why this isn’t effective discourse, we could have a potential addition to the spec to explicitly block users from certain countries. That’s not great but also its easy to understand why its not worth debating that point (even though it does sound scary).
mthoms 3y ago
Direct link to comment: https://github.com/RupertBenWiser/Web-Environment-Integrity/issues/28#issuecomment-1651129388 https://github.com/RupertBenWiser/Web-Environment-Integrity/...
danShumway 3y ago
Holdbacks are an insufficient solution; there is a fundamental conflict in the specification's goals surrounding lock-in. The overall goal for the spec is described in the comment: > The WEI experiment is part of a larger goal to keep the web safe and open while discouraging cross-site tracking and lessening the reliance on fingerprinting for combating fraud and abuse. Fraud detection and mitigation techniques often rely heavily on analyzing unique client behavior over time for anomalies, which involves large collection of client data from both human users and suspected automated clients. In other words, the intended goal of this spec is to discourage the development and use of fingerprinting techniques, login screens, and other invasive user-validation techniques on websites. However, the goal of holdbacks is then described in the following way: > This is designed to prevent WEI from becoming “DRM for the web”. Any sites that attempted to restrict browser access based on WEI signals alone would have also restricted access to a significant enough proportion of attestable devices to disincentivize this behavior. [...] The hold-back and the lack of browser identification in the response provides cover to browsers that spoof their user agents that might otherwise be treated differently by sites. This also includes custom forks of Chromium that web developers create. In other words, one of the goals for the holdback system is to make it practically impossible for a website not to have fallback mechanisms for validating user trust when encountering requests that don't have attestation. And a essential part of that design is that even implementing browsers like Chrome will refuse to verify the environment integrity 10-15% of the time. ---- So why is this a problem? Because holdbacks are on-purposed designed to make it so that fallback mechanisms have to exist and that sites can't skip including them; but the whole point of this spec as stated is to discourage developers from building those same fallbacks they're required to include because the fallbacks violate privacy or are are invasive or are essentially login walls. And 10-15% of the time even users in participating browsers will be subjected to those fallback strategies. So you're still basically guaranteed to have your device fingerprinted, and any site that uses login as a backup verification method still will require you to make an account. The only thing that this would affect is the frequency of user-annoyances in front of websites -- essentially, if sites started using this as a substitute for captchas, this would encourage them to drastically increase the number of captchas they use since Chrome browsers would only see 10-15% of those captchas. And that's also a problem if you're trying to guarantee that competing browsers won't be affected, because "your users see 9x as many captchas on every website" is a pretty stinking big competitive moat. Forgive me for thinking that "you can build a browser that competes with us, but unless we specifically approve of your browser, anyone who uses it on Android will be solving captchas over and over at a massively increased rate until they eventually give up and move back to Chrome like a good little consumer" still kind of has a lot antitrust implications. ---- This proposal doesn't make sense; assuming the best of the authors I can only assume they haven't really thought through what they're trying to build. But you can not build an attestation method that simultaneously improves the web substantially for your own users over non-attestation methods, but that also magically does not hurt the web for any of your competitors who don't get those improvements. And holdbacks only make those goals even more contradictory: because privacy, paywalls, and logins will still affect Chrome if it decides randomly that it's not going to attest to the NYT for the duration of today. The only aspect that this makes sense for is specifically user annoyances; and where annoyances are concerned an attestation method that excludes most mainstream users on unmodified devices from annoyances while leaving niche browsers out is an invitation for websites to discriminate against those browsers -- holdbacks change nothing about that situation. You can't tell me this is about discouraging fingerprinting in the same comment that you tell me that you're going to guarantee that sites will still need to build fingerprinting solutions and will still need to use those solutions even on participating browsers.
MadcapJake 3y ago
> We had proposed a hold-back to prevent lock-in at the platform level. Essentially, some percentage of the time, say 5% or 10%, the WEI attestation would intentionally be omitted, and would look the same as if the user opted-out of WEI or the device is not supported. So, does that mean that sites would need to fallback to existing practices for these users (or for custom forks)? So, these users get the worse ux and that's considered "supporting custom browsers"? Now sites can spend less time and resources on detection, but wait...what about the 5-10%? So IT departments will be less likely to spend precious dev time and funding on improving detection due the overall risk reduction. I'm not sure that's a net win.
- wzdd 3y ago
  Seems like it. Also that everyone will eventually end up fingerprinted if they browse for long enough, because the holdback is randomly enabled on a per-(client,site) basis.
unintendedcons 3y ago
Can't trust 'em.

45 points by luag 3y ago

> WEI’s goal is to make the web more private and safe Yeah, hopefully you can sleep better telling yourself that. > An owner of this repository has limited the ability to comment to users that have contributed to this repository in the past. Fucking joke.

rolph 3y ago

https://www.ftc.gov/about-ftc/contact https://www.ftc.gov/about-ftc/contact

voytec 3y ago
Quoting this[1] commit comment: US: https://www.ftc.gov/enforcement/report-antitrust-violation antitrust@ftc.gov EU: https://competition-policy.ec.europa.eu/antitrust/contact_en comp-greffe-antitrust@ec.europa.eu UK: https://www.gov.uk/guidance/tell-the-cma-about-a-competition-or-market-problem general.enquiries@cma.gov.uk India: https://www.cci.gov.in/antitrust/ https://www.cci.gov.in/filing/atd [1] https://github.com/chromium/chromium/commit/6f47a22906b2899412e79a2727355efa9cc8f5bd#commitcomment-122762976 https://github.com/chromium/chromium/commit/6f47a22906b28994...

mikelward 3y ago

I think the actual comment is this one? https://github.com/RupertBenWiser/Web-Environment-Integrity/issues/28#issuecomment-1645329286 https://github.com/RupertBenWiser/Web-Environment-Integrity/... On my phone this is collapsed and hard to find by default.

mthoms 3y ago
That one is 5 days old. The one being referenced is https://github.com/RupertBenWiser/Web-Environment-Integrity/issues/28#issuecomment-1651129388 https://github.com/RupertBenWiser/Web-Environment-Integrity/...

haburka 3y ago

Amazingly clever that they have hold backs! Make sure to read this before going along with the anti WEI train > WEI prevents ecosystem lock-in through hold-backs > We had proposed a hold-back to prevent lock-in at the platform level. Essentially, some percentage of the time, say 5% or 10%, the WEI attestation would intentionally be omitted, and would look the same as if the user opted-out of WEI or the device is not supported. So this avoids the DRM or blocking certain browsers issue. Brilliant. I’m not entirely certain but I think this avoids the main issues which people had with the proposal. I still think a lot of people will not read this and react with vitriol but I would like to expect more from hacker news, as a forum where people don’t simply downvote opinions they disagree with.

steve_avery 3y ago
The existence of a configuration that limits attestation to a probabilistic phenomenon seems like a very thin foundation to stand on here - if it can be changed to requiring 100% attestation rate in the future I think it will be changed as soon as it is feasible to do so. I haven't reviewed the proposal enough to see how they implemented that, and if it was done in a cryptographic way that prevents changing to 100%, then that could work. But the fact remains that control of our browsing computing environment is diminishing under this proposal.
- haburka 3y ago
  It seems to me that “if it can be changed to 100% attestation rate in the future, it will be done” is a slippery slope argument and assuming bad faith on behalf of the proposal writer. I think if it were changed to be 100% then it would be problematic. Also it seems the proposal writer would also agree that some form of opt out is required to make it viable so as to not forbid unknown clients. I think its important to stay away from considering potential “what ifs” that completely defy the intent of the spec. For an example of why this isn’t effective discourse, we could have a potential addition to the spec to explicitly block users from certain countries. That’s not great but also its easy to understand why its not worth debating that point (even though it does sound scary).

mthoms 3y ago

Direct link to comment: https://github.com/RupertBenWiser/Web-Environment-Integrity/issues/28#issuecomment-1651129388 https://github.com/RupertBenWiser/Web-Environment-Integrity/...

danShumway 3y ago

Holdbacks are an insufficient solution; there is a fundamental conflict in the specification's goals surrounding lock-in. The overall goal for the spec is described in the comment: > The WEI experiment is part of a larger goal to keep the web safe and open while discouraging cross-site tracking and lessening the reliance on fingerprinting for combating fraud and abuse. Fraud detection and mitigation techniques often rely heavily on analyzing unique client behavior over time for anomalies, which involves large collection of client data from both human users and suspected automated clients. In other words, the intended goal of this spec is to discourage the development and use of fingerprinting techniques, login screens, and other invasive user-validation techniques on websites. However, the goal of holdbacks is then described in the following way: > This is designed to prevent WEI from becoming “DRM for the web”. Any sites that attempted to restrict browser access based on WEI signals alone would have also restricted access to a significant enough proportion of attestable devices to disincentivize this behavior. [...] The hold-back and the lack of browser identification in the response provides cover to browsers that spoof their user agents that might otherwise be treated differently by sites. This also includes custom forks of Chromium that web developers create. In other words, one of the goals for the holdback system is to make it practically impossible for a website not to have fallback mechanisms for validating user trust when encountering requests that don't have attestation. And a essential part of that design is that even implementing browsers like Chrome will refuse to verify the environment integrity 10-15% of the time. ---- So why is this a problem? Because holdbacks are on-purposed designed to make it so that fallback mechanisms have to exist and that sites can't skip including them; but the whole point of this spec as stated is to discourage developers from building those same fallbacks they're required to include because the fallbacks violate privacy or are are invasive or are essentially login walls. And 10-15% of the time even users in participating browsers will be subjected to those fallback strategies. So you're still basically guaranteed to have your device fingerprinted, and any site that uses login as a backup verification method still will require you to make an account. The only thing that this would affect is the frequency of user-annoyances in front of websites -- essentially, if sites started using this as a substitute for captchas, this would encourage them to drastically increase the number of captchas they use since Chrome browsers would only see 10-15% of those captchas. And that's also a problem if you're trying to guarantee that competing browsers won't be affected, because "your users see 9x as many captchas on every website" is a pretty stinking big competitive moat. Forgive me for thinking that "you can build a browser that competes with us, but unless we specifically approve of your browser, anyone who uses it on Android will be solving captchas over and over at a massively increased rate until they eventually give up and move back to Chrome like a good little consumer" still kind of has a lot antitrust implications. ---- This proposal doesn't make sense; assuming the best of the authors I can only assume they haven't really thought through what they're trying to build. But you can not build an attestation method that simultaneously improves the web substantially for your own users over non-attestation methods, but that also magically does not hurt the web for any of your competitors who don't get those improvements. And holdbacks only make those goals even more contradictory: because privacy, paywalls, and logins will still affect Chrome if it decides randomly that it's not going to attest to the NYT for the duration of today. The only aspect that this makes sense for is specifically user annoyances; and where annoyances are concerned an attestation method that excludes most mainstream users on unmodified devices from annoyances while leaving niche browsers out is an invitation for websites to discriminate against those browsers -- holdbacks change nothing about that situation. You can't tell me this is about discouraging fingerprinting in the same comment that you tell me that you're going to guarantee that sites will still need to build fingerprinting solutions and will still need to use those solutions even on participating browsers.

MadcapJake 3y ago

> We had proposed a hold-back to prevent lock-in at the platform level. Essentially, some percentage of the time, say 5% or 10%, the WEI attestation would intentionally be omitted, and would look the same as if the user opted-out of WEI or the device is not supported. So, does that mean that sites would need to fallback to existing practices for these users (or for custom forks)? So, these users get the worse ux and that's considered "supporting custom browsers"? Now sites can spend less time and resources on detection, but wait...what about the 5-10%? So IT departments will be less likely to spend precious dev time and funding on improving detection due the overall risk reduction. I'm not sure that's a net win.

wzdd 3y ago
Seems like it. Also that everyone will eventually end up fingerprinted if they browse for long enough, because the holdback is randomly enabled on a per-(client,site) basis.

unintendedcons 3y ago

Can't trust 'em.