-
Notifications
You must be signed in to change notification settings - Fork 6
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Avoid misuse of protocol for tracking. #3
Comments
I thought the same when reading the draft. What a wonderful way to store information in a user's agent. Even if the user reject a consent, the browser will have to send this information (that's server generated). Just imagine Facebook and a As I understand it, the proposal is too wide to let the server set their own consent name. It should be normalized to very few cases so as not to serve as another fingerprinting technic. For example, another layer of indirection could be used while declaring the consent:
The browser would then only reply to the agreed level of consent, and, optionally for the higher classes only, send one or more ID, so instead of That would also simplify the browser's work, since the user could set up the default level he agrees to without a prompt and the popup would only trigger for higher levels and/or customized consent id. |
If there are normalised request IDs then there would have to be standardsed text, especially if automatic acceptances can be sent. |
Probably most readers of this thread will have already read the tracking subsection of the privacy considerations section in the draft spec, but I will quote it here as it exactly what this discussion is about (and was partly inspired by earlier private comments by @michael-oneill):
|
Thanks for the quote. My comment above was about adding a well-defined type that a browser can understand (unlike the consent name and helpful text, that would also soon become a way to send ads as unblockable pop-up as well) in order to classify the consent type. It does not interfere with the quoted text, I'd say, to the opposite, it's adding safety against misuse of the proposal. The consent's count can be used as a relatively inefficient fingerprint technique as stated, but I really doubt browser will make 2 request to fetch some resource (the current technology is trying to avoid round trip, not to add more), so the "send a virgin request first" solution is, IMHO, not practical. (Not even speaking about a server that can also remember the IP address and send the same fingerprint ID for the same IP address). Also, it's completely possible to have an (invisible) iframe to some website to extract the "consent" fingerprint. A server in this case will simply set up a fingerprint consent on a subdomain, and return a html document with a There are many other side channels to pass information from iframe to main frame, and this proposal just can use one. |
I presume this issue arises only because of potential external scripts that inject an identifier via the purpose ID, is this correct? If yes: Would limiting consent requests to be generated by first-party or pseudo-first party scripts be a viable solution? E.g. if script has been loaded from external source vs script loaded from first-party domain i.e. prohibit third-party scripts and iframes from generating requests?
|
A legitimate use-case where a unique identifier may be required is when the purpose identifiers (consent request id) are used as identifiers for the user. E.g. |
Much user tracking is done with top level origins, and most will be in future as browsers restrict embedded cross-origin cookies. There are many techniques used for this e.g. link decoration correlated via IP address or email address, or redirection based methods such as bounce tracking., and it is hard for browsers to stop them. |
It is a very old data protection principal that if a service provider (as a controller) does not require user dentifying data, it should not require it to be collected. This is stated in the GDPR and elsewhere. |
If clients simply returned the request IDs in the ADPC header the protocol could be co-opted to create a super cookie.
For example, a determined tracker could get a site to host some script that creates a misleading consent request i.e.
`{
}`
The request ID is dynamically generated unique to each user, and sent back in the ADPC header if users are fooled into giving their consent. Depending on how browsers implement the protocol, tracking may continie even after users delete their cookies.
Although not everyone will be fooled, some could be and find themselves being tracked.
One way to mitigate this is to ensure the request IDs have a low-entopy i.e. non unique value, and that the browser shuffles or randomises the oder they are placed in the ADPC header.
Browsers could also apply their own low-entropy response by encoding the positional index of the agreed requests as a single digit, and responding with that instead, along with re-ordering if there are several. There could never be more than 10 separate purposes but more than this would be confusing anyway.
e.g.
ADPC: consent=0
or
ADPC: consent=1 3
if there are multiple purposes, with the order randomised.
The text was updated successfully, but these errors were encountered: