Clarify cookie banner options #3460
Conversation
✅ You can preview this change here:
To edit notification comments on pull requests, go to your Netlify site configuration. |
| @@ -109,7 +109,7 @@ You can choose not to have a cookie banner if the service only sets essential or | |||
|
|
|||
| However, you must tell users that you set essential cookies. You can do this with a cookies page – link to this page in the footer. | |||
|
|
|||
| ### Option 2: If you set non-essential cookies on the server | |||
| ### Option 2: If your server sets non-essential cookies | |||
There was a problem hiding this comment.
Personally, I do think "If you set non-essential cookies for users with or without javascript" would be clearer than "your server sets" here.
If a user has javascript enabled and they are sent some javascript by your web server, and running that causes them to store a cookie on their machine, I think a reasonable person might describe that Cookie as having been set by "your server".
I think the distinction you are looking for is between users who have javascript enabled or disabled
HTH
There was a problem hiding this comment.
Hi Richard,
Just feel the need to jump in here to try and clarify a few things.
It's important to note that the component we ship doesn't provide any functionality. That minutae up to individual teams, so the guidance here is trying to cover a variety of scenarios as to how it might be used in a technology-agnostic way.
Option 2 covers the scenario wherein clicking a button in the banner submits a form and performs a postback. The cookie is ultimately created by a server-side programming language like Ruby, PHP, Python in response to the form submission. It can be enhanced with JavaScript, but does not require it to work.
Option 3 covers the scenario wherein clicking the button runs a piece of JavaScript code that is already loaded somewhere, and the cookie is created by that JavaScript code.
Not all government websites are able to implement Option 2. Quite a few are static sites—including the Design System!—and don't have a server-side programming language backing them to create those cookies.
A team may also choose Option 3 if their only usage of cookies is via other JavaScript (e.g. Google Analytics). In that scenario, obtaining cookie consent is only needed for users that have JavaScript available, so Option 2 is 'overkill'.
The two options are not solely distinct by whether they use JavaScript or whether the users seeing them have JavaScript available; but also by different technology architectures and different requirements of each service.
The neatest way we've thought of splitting these up is thus 'cookies set by the server' (or, in long, cookies created by a server-side programming language) versus 'cookies set by the client' (by a client-side programming language, JavaScript).
I am conscious that these are pre-loaded terms to developers, and maybe slants more technical than a lot of other guidance on the Design System side. If you think there is a different way we could slice this particular cake, we'd like to hear about it!
There was a problem hiding this comment.
Thanks, I do understand all that.
I do still feel that "cookies set by the server" v.s. "cookies set by the client" is unclear and technically misleading language, and you would be much better off using the phrasing "for users with javascript disabled/enabled".
As I mentioned above, if I have Javascript enabled, and I visit your website, and your server sends me some Javascript as part of that page, and my browser executes that Javascript (which is invisible to most users), then if that chain of events causes cookies to be set on my machine ... most people would quite reasonably describe that as having cookies set by your "server", even though in your proposed terminology, you want to call that cookies set by "the client".
My key point is that Option 3 applies only if non-essential cookies are not set for users with Javascript disabled, regardless of whether the site itself uses server-side rendering or not. Sites such as mine that use server-side rendering, but which use client-side javascript to set the tracking cookies can still use this approach. So the key distinction is whether disabling javascript on the client will opt out of tracking cookies, not whether the site uses server-side or client-side rendering.
You are of course quite entitled to use whatever phrasing you choose. I won't be offended if you stick with the current phrasing.
There was a problem hiding this comment.
I do still feel that "cookies set by the server" v.s. "cookies set by the client" is unclear and technically misleading language, and you would be much better off using the phrasing "for users with javascript disabled/enabled".
The problem there is that "for users with javascript disabled/enabled" would also be technically misleading, as Option 2 can still be used if JavaScript is available. The distinction between the options is principally in the technical architecture of the service, not in the client's JavaScript availability.
[…] if I have Javascript enabled, and I visit your website, and your server sends me some Javascript as part of that page, and my browser executes that Javascript […] most people would quite reasonably describe that as having cookies set by your "server", even though in your proposed terminology, you want to call that cookies set by "the client".
I also don't really agree with your description here. The use of 'server' vs. 'client' terminology in development is principally concerned with where the code is being parsed and executed, not from where that code originates.
The server sends the JavaScript, yes, but the browser—the client—is where that code is executed and the cookie is created. The server will not even be aware that the cookie exists until the client informs it of the creation on the next HTTP request.
Personally I'm satisfied that we're using client and server terminology correctly here.
There was a problem hiding this comment.
The problem there is that "for users with javascript disabled/enabled" would also be technically misleading, as Option 2 can still be used if JavaScript is available. The distinction between the options is principally in the technical architecture of the service, not in the client's JavaScript availability.
No, my proposed wording was as follows (see linked comment), so does cover that angle:
- "Option 2: If you set non-essential cookies for users with or without javascript"
- "Option 3: If you set non-essential cookies, but only via clientside javascript"
There was a problem hiding this comment.
Thanks @RichardBradley, based on your suggestion and a chat with @querkmachine and team, I've made (and committed) another draft for the team to review:
| ### Option 2: If your server sets non-essential cookies | |
| Option 2: If you set non-essential cookies for users (with or without JavaScript) |
Ahh thanks for catching – will squash and merge. |
Apply contributor suggestion Update heading markdown
calvin-lau-sig7
force-pushed
the
clarify-cookie-banner
branch
from
2f340df
to
72aa821
Compare
Add clearer language to explain the different scenarios our cookie banner guidance covers.
Based on backlog comment from a user that found the current wording confusing: alphagov/govuk-design-system-backlog#12 (comment)