zlacker

I'm less concerned with reversing hashes and more concerned with tracking via the attlestation provider.

What is stopping them from recording the value returned to you that is then passed to the site you tried to visit? Does the data provided to the integrity checker allow for identification? Could the original vendor pass some value to use in the integrity check to prevent replay attacks, and could that value itself encode your personal information?

>>helloj+(OP)
> What is stopping them from recording the value returned to you that is then passed to the site you tried to visit?

> Could the original vendor pass some value to use in the integrity check to prevent replay attacks, and could that value itself encode your personal information?

Well that value is most likely a cryptographic signature, a "challenge" or a combination of both. Unless there's some separate payload you can't really hide arbitrary data in hashes/signatures that would be used in such a process.

In the end "could" is a very loose word, PII as such is not really part of the process. In this current (Apple's PAT) case, the information is "you have an Apple device", can't currently hide anything else in that.

>>Avaman+3j
Thanks for the response. As a second question, would what prevent someone with an "approved" apple device from firing off a bunch of token requests and then distributing those tokens to different entities for those entities to submit to the origin to pass the validation test?

>>helloj+zw
They could, but I'm sure there are rate-limits in place against that.

>>Avaman+Po1
Good to know. And the rate limits themselves have to apply to user agents in the old style, right? Because there is no identifying information apart from current browser fingerprinting methods. If abused, do we foresee captchas having to be placed as a guard against attlestation abuse?