3 ms·

A good explanation of how he would reconcile his proposal and the ideas he's previously expressed: https://github.com/RupertBenWiser/Web-Environment-Integrity/b

by jefftk 3y ago

A good explanation of how he would reconcile his proposal and the ideas he's previously expressed: https://github.com/RupertBenWiser/Web-Environment-Integrity/blob/main/explainer.md#how-will-we-prevent-this-signal-from-being-used-to-exclude-vendors https://github.com/RupertBenWiser/Web-Environment-Integrity/...

saagarjha 3y ago
This just seems like a generic “oh people might hate this proposal here’s a place where we mention this”, not a response to the question asked above.
- Thorrez 3y ago
  Why isn't it a response to the question above asked? The question above seems to be saying that this API will be used to create walled gardens; the linked part of the design is about how to prevent the API from being used to create walled gardens. Disclosure: I work at Google but not on this.
  - mackie_roy 3y ago
    Unfortunately, what you link doesn't answer how they will prevent it being used to create walled gardens. It's just an open question, and as such, it does seem it's an afterthought, when it should be front and center if anyone care for an open web.
    - Thorrez 3y ago
      Wouldn't a holdback prevent it from being used to create walled gardens?
      - delehal 3y ago
        I doubt it. As explained by GitHub user tbrandirali, the stated goals seem to be inherently contradictory. Quoting in part: "This internal contradiction is further demonstrated by the fact that the proposed solution to prevent misuse by websites - holdbacks - is to simply sabotage the functionality of the system itself, by making attestation probabilistic. This is not a workable solution to the problem: if the holdback rate of requests is low enough, the denial of service to legitimate users will simply be a cost of business that websites will accept; if instead it is high enough, websites will not use this system as it does not provide meaningful enough information, even for analytics purposes, due to the high uncertainty. There is no goldilocks zone where this system is useful but not open to abuse by implementer websites. You're either implementing a feature that can - and most likely will - be used by websites to exclude unattested clients, or you're implementing a useless feature." https://github.com/RupertBenWiser/Web-Environment-Integrity/issues/116 https://github.com/RupertBenWiser/Web-Environment-Integrity/...
        Thorrez 3y ago
        Why wouldn't a 10% holdback work? Would a company consider it "simply a cost of business" to block 10% of people at random? That's going to cause a huge amount of support load and probably a lot of negative press. 90% of data will still be good for analytics.
        delehal 3y ago
        If the holdback rate is low enough that the data is "good enough for analytics", then you may as well not have a holdback rate at all.
  - saagarjha 3y ago
    It doesn’t have very concrete answers. It’s really more of a couple of ie thoughts, with an exhortation for people to provide ideas on how to fix this. For example: > Attesters will be required to offer their service under the same conditions to any browser who wishes to use it and meets certain baseline requirements. What prevents this set of baseline requirements from being e.g. “the device is backed by a TPM from these four vendors”? > 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. “So, like, here’s a vague idea on how we might prevent this. However this idea has significant problems.” Not a very convincing argument? > If the community thinks it's important for the attestation to include the platform identity of the application “If we assume that we can’t actually solve this…” Basically there’s not much in the way of answers there. Generally when you put out proposals with a history of significant pushback I’d expect the likely feedback to be addressed in more depth than this. (I guess since we’re doing disclaimers I also work at Google but not on this.)

by jefftk 3y ago

saagarjha 3y ago

This just seems like a generic “oh people might hate this proposal here’s a place where we mention this”, not a response to the question asked above.

Thorrez 3y ago
Why isn't it a response to the question above asked? The question above seems to be saying that this API will be used to create walled gardens; the linked part of the design is about how to prevent the API from being used to create walled gardens. Disclosure: I work at Google but not on this.
- mackie_roy 3y ago
  Unfortunately, what you link doesn't answer how they will prevent it being used to create walled gardens. It's just an open question, and as such, it does seem it's an afterthought, when it should be front and center if anyone care for an open web.
  - Thorrez 3y ago
    Wouldn't a holdback prevent it from being used to create walled gardens?
    - delehal 3y ago
      I doubt it. As explained by GitHub user tbrandirali, the stated goals seem to be inherently contradictory. Quoting in part: "This internal contradiction is further demonstrated by the fact that the proposed solution to prevent misuse by websites - holdbacks - is to simply sabotage the functionality of the system itself, by making attestation probabilistic. This is not a workable solution to the problem: if the holdback rate of requests is low enough, the denial of service to legitimate users will simply be a cost of business that websites will accept; if instead it is high enough, websites will not use this system as it does not provide meaningful enough information, even for analytics purposes, due to the high uncertainty. There is no goldilocks zone where this system is useful but not open to abuse by implementer websites. You're either implementing a feature that can - and most likely will - be used by websites to exclude unattested clients, or you're implementing a useless feature." https://github.com/RupertBenWiser/Web-Environment-Integrity/issues/116 https://github.com/RupertBenWiser/Web-Environment-Integrity/...
      - Thorrez 3y ago
        Why wouldn't a 10% holdback work? Would a company consider it "simply a cost of business" to block 10% of people at random? That's going to cause a huge amount of support load and probably a lot of negative press. 90% of data will still be good for analytics.
        delehal 3y ago
        If the holdback rate is low enough that the data is "good enough for analytics", then you may as well not have a holdback rate at all.
- saagarjha 3y ago
  It doesn’t have very concrete answers. It’s really more of a couple of ie thoughts, with an exhortation for people to provide ideas on how to fix this. For example: > Attesters will be required to offer their service under the same conditions to any browser who wishes to use it and meets certain baseline requirements. What prevents this set of baseline requirements from being e.g. “the device is backed by a TPM from these four vendors”? > 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. “So, like, here’s a vague idea on how we might prevent this. However this idea has significant problems.” Not a very convincing argument? > If the community thinks it's important for the attestation to include the platform identity of the application “If we assume that we can’t actually solve this…” Basically there’s not much in the way of answers there. Generally when you put out proposals with a history of significant pushback I’d expect the likely feedback to be addressed in more depth than this. (I guess since we’re doing disclaimers I also work at Google but not on this.)