Skip to content
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

Backwards compatability, cookies, and consent #12

Open
robrwo opened this issue Jun 18, 2021 · 5 comments
Open

Backwards compatability, cookies, and consent #12

robrwo opened this issue Jun 18, 2021 · 5 comments

Comments

@robrwo
Copy link

robrwo commented Jun 18, 2021

The way session handling in most websites work is through cookies.

  1. User-agent (UA) sends request to website
  2. Web server (WS) sends cookie with response
  3. UA accepts cookie
  4. UA returns cookie in next request.
  5. WS validates cookie as being in same session as no. 1

See also some discussion in #11, particular the assumption that the web server will not send a cookie until it receives consent in an ADC header, something like
6. UA passes ADPC consent request to user and receives permission to use cookies
7. UA includes ADC headers giving consent
8. WS responds with a cookie

The problem is that user agents which do not support ADPC will never issue consent (7), so websites that require cookies for some purposes will not work with older user agents.

I think the workaround for this is for web servers to not send cookies if they request has a "ADC: withdraw=*" header but send cookies if the the request consents to it. User agents would pass a withdraw header the first time they connect to a webserver.

@michael-oneill
Copy link

They would not have to place cookies even if the ADPC is not present (because ePrivacy)

@robrwo
Copy link
Author

robrwo commented Jun 21, 2021

They would not have to place cookies even if the ADPC is not present (because ePrivacy)

Who is "they"? The User-Agent? The web server?

@michael-oneill
Copy link

Sorry, I was too terse. I meant the web server (or the browser context of the web server). Only cookies that are solely required for the underlying communications, or those strictly necessary to fulfil a user request, can be placed on first HTTP request. The url might signal a user request in some circumstances, and there may be a requirement for a cookie to help load ballancing (though I have never seen one), but every other case there should be nothing in the Set-Cookie header.

@robrwo
Copy link
Author

robrwo commented Jun 22, 2021

Only cookies that are solely required for the underlying communications, or those strictly necessary to fulfil a user request, can be placed on first HTTP request.

That's what I am talking about.

@gb-noyb
Copy link
Collaborator

gb-noyb commented Jul 8, 2021

The problem is that user agents which do not support ADPC will never issue consent (7), so websites that require cookies for some purposes will not work with older user agents.

As discussed in #11, if websites “require cookies for some purposes”, they either do not need to ask for consent, or they need to ask consent whether or not the user agent supports ADPC. For older user agents (not supporting ADPC), websites could fall back to using a classical consent request (‘cookie banner’). As Mike said, this makes no difference for the first request and response. Does this resolve the issue?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants