#GDPR

@valthebald and @longwave are right, that this is not a violation of the GDPR - but of the EU ePrivacy Directive and national laws in european countries (since 2002!).

The ePrivacy Directive Art. 5 (3) says, that you need users’ consent before you "store information" (cookies, localStorage etc.) "in the terminal equipment of a subscriber or user" (e.g. browser) except "strictly necessary" data. This EU directive is not a direct law, but is implemented by national laws, in Germany the TDDDG and in Spain the LSSI for example.

The new EU e-Privacy Regulation is currently being drafted; this will replace the directive and will then become direct law (in the same way as the GDPR). According to the current status, it contains an analogous passage, see Article 8 "Protection of information stored in and related to end-users’ terminal equipment":

It is not about which data is processed, but about the protection of the visitor's end device - so it does not matter whether it is a tracking, 1st or 3rd party cookie.

It is a violation in all european countries.

+1 to #9. GDPR is only relevant to the processing of personal data, this is kept entirely client side and cannot be used to track or identify a user so I believe this usage of localStorage is exempt.

As far as stickyHeaderState is entirely client-processed and is not collected/processed by the server (who should it be?), I'd argue it's not a subject to GDPR or similar regulations.
GDPR, as it states in the very first article, is about

...rules relating to the protection of natural persons with regard to the processing of personal data and rules relating to the free movement of personal data.

since there is no processing of personal data, I'd say there is no need to get user consent

Thank for your comment. I added the test.

Please review.

@jan

And my CSP does not report anymore.

The new solution looks promising (clever idea)! I'll look into it this week. I'll report back once I tested it (potentially needs some slight asjustments to Gin Toolbar as well). Thank you for working on this

@ambient.impact

My original implementation of dark mode toggling was primarily CSS using @media (prefers-color-scheme: dark) {}, which not only would have avoided having to store anything by default

Both solutions had it's pro and cons (and still have). I still think the solution we went with is suited pretty well for the specific use case we have.

Yes, I learned, too. Now we are using a json variable instead of inline-JS:

    $page['#attached']['html_head'][] = [
+      [
+        '#tag' => 'script',
+        '#attributes' => [
+          'type' => 'application/json',
+          'id' => 'gin-darkmode',
+        ],
+        '#value' => new FormattableMarkup('{ "ginDarkmode": "@value" }', ['@value' => $settings->get('enable_darkmode')]),
+      ],
+      'gin_darkmode',
+    ];

And my CSP does not report anymore.

Thanks for reporting, we could use a test case showing this as a problem.

My original implementation of dark mode toggling was primarily CSS using @media (prefers-color-scheme: dark) {}, which not only would have avoided having to store anything by default, but also removed the additional problems with having to check storage with JavaScript, i.e. no chance of brief flashes of light mode unless you used an inline script which is a problem with CSP, etc. See #3161904-27: Auto Darkmode option → for my concerns at the time.

You are right, the question is if the storage item is technically necessary.

> I can follow the argument that it is technically necessary because there is no other way to follow the user's preference.

The user has not made any preference at this point. Only the website operator's default setting is saved in the visitor's browser. That is the problem, that it is NOT a setting made by the user. Hence my approach of working without storage until the user makes a selection.

I have to admit that I'm a layman when it comes to legal topics. But following the above discussion seems to be boiling down to a simple question:

Is storing a user preference for, e.g. dark or light mode, technically necessary or not?

I can follow the argument that it is technically necessary because there is no other way to follow the user's preference.

You didn't understand the judgment. It is not about the type of cookie, but about the fact that data was stored on the user's device without consent. See also Article 22.2 LSSI.

The ePrivacy Directive says, that you need users’ consent before you use any cookies except strictly necessary cookies. This EU directive is not a direct law, but is implemented by national laws, in Germany the TDDDG and in Spain the LSSI.

The new EU e-Privacy Directive is currently being drafted; this will replace the directive and will then become direct law in the same way as the GDPR. According to the current status, it contains an analogous passage, see Article 8 "Protection of information stored in and related to end-users’ terminal equipment".

It is not about which data is processed, but about the protection of the visitor's end device - so it does not matter whether it is a tracking, 1st or 3rd party cookie.

The article https://gdprhub.eu/index.php?title=AEPD_(Spain)_-_PS/00524/2023&mtc=today is about 3rd party cookies. It's correct, that 3rd party cookies are not allowed without a users consent.
Your dark mode cookie will be a first party cookie, furthermore a binary value, not for tracking purposes.
So you can't compare these.

We are not aware of any process that has dealt with anything like this first party cookie with a binary value for technical purpose.
What would probably cause less discussion (also from the thread): the default (=cookie not present) is light mode; if the user explicitly selects dark mode, the cookie is set.

What is correctly presented in the thread is that setting a cookie and writing a value to local storage are of course the same thing on a more abstract level, namely storing data on the end device.

Created MR. Please review.