Google employee responds to negative feedbacks on WEI
1–10 of 26 posts
Re: Google employee responds to negative feedbacks on WEI
#2> 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.
Re: Google employee responds to negative feedbacks on WEI
#3Re: Google employee responds to negative feedbacks on WEI
#4https://www.ftc.gov/about-ftc/contact
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
Re: Google employee responds to negative feedbacks on WEI
#5I think the actual comment is this one? https://github.com/RupertBenWiser/Web-Environment-Integrity/...
On my phone this is collapsed and hard to find by default.
Re: Google employee responds to negative feedbacks on WEI
#6Amazingly 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.
Re: Google employee responds to negative feedbacks on WEI
#7Amazingly 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…
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.
Re: Google employee responds to negative feedbacks on WEI
#8Amazingly 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…
See the original note: It was much more of a "maybe we could do this, but it has a lot of problems": https://github.com/RupertBenWiser/Web-Environment-Integrity/...
Re: Google employee responds to negative feedbacks on WEI
#9Amazingly 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…
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%,…
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).
Re: Google employee responds to negative feedbacks on WEI
#10Amazingly 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…
See the original note: It was much more of a "maybe we could do this, but it has a lot of problems": https://github.com/RupertBenWiser/Web-Environment-Integrity/...
Including the text since it’s pretty illuminating:
>Holdback
>To protect against both risks, we are evaluating whether attestation signals must sometimes be held back for a meaningful number of requests over a significant amount of time (in other words, on a small percentage of (client, site) pairs, platforms would simulate clients that do not support this capability). Such a holdback would encourage web developers to use these signals for aggregate analysis and opportunistic reduction of friction, as opposed to a quasi-allowlist: A holdback would effectively prevent the attestation from being used for gating feature access in real time, because otherwise the website risks users in the holdback population being rejected.
>Although a holdback would prevent the attestation signal from being used for per-request enforcement decisions, there remains immense value for measurement in aggregate populations.
>However, a holdback also has significant drawbacks. In our use cases and capabilities survey, we have identified a number of critical use cases for deterministic platform integrity attestation. These use cases currently rely on client fingerprinting. A deterministic but limited-entropy attestation would obviate the need for invasive fingerprinting here, and has the potential to usher in more privacy-positive practices in the long-term.
>We ask for feedback from the community group on the idea of a holdback, and are very interested in alternative suggestions that would allow both goals to be met.
To me this is very clearly stating there needs to be some mechanism that forces website developers to not block access based on the results at attestation so as to allow clients to opt out. I’m not seeing the “maybe we could this,” interpretation, instead I’m seeing “we need to do something to allow client opt out, here’s one such way (with issues)”