zlacker

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

>>jefftk+(OP)
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.

>>saagar+u9
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.

>>Thorre+pz
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.

>>Thorre+pz
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.)

>>mackie+qm1
Wouldn't a holdback prevent it from being used to create walled gardens?

>>Thorre+8R2
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/...

>>deleha+i13
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.

>>Thorre+cD5
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.