5 ms·

> As an example, the Eleventy documentation seems to avoid using client-side JavaScript for the most part. As Eleventy supports various templating languages it

by jefftk 3y ago

> As an example, the Eleventy documentation seems to avoid using client-side JavaScript for the most part. As Eleventy supports various templating languages it provides code samples in each of the different languages. Unfortunately, it doesn’t record which language you’ve selected so if your chosen language is not the default one, you are forced to change tabs on every single code sample. A little client-side JavaScript here would make the experience so much more pleasant for users. This may actually be an ePrivacy limitation (cookie law) not a desire to avoid JS. Persisting the setting across pages requires client size storage, which in ePrivacy countries requires either that the setting be obvious to the user that it's persisted, getting per-action consent (ex: a "preferred language" setting) or site-wide user consent (a cookie pop-up).

Gustek 3y ago
My understanding of ePrivacy (mostly GDPR) is that this kind of feature does not require consent. It's only features that would allow you for tracking of the user that require consent. Storing some setting in a local storage, never sending it to the server is fine. Things get a bit muddy when sending to server but even then you may not need a consent if it is a feature that is required for correct working of the website or better experience without tracking and profiling.
- diggan 3y ago
  This is correct. Unless it involves personal data and/or tracking the user somehow, then GDPR isn't relevant. Example: If you're storing lightOrDarkTheme in a cookie/localStorage, then there is no need to try to follow any directives, nor are you required to inform the user about that you're storing the preference.
- jefftk 3y ago
  GDPR and ePrivacy are different regulations. Under the latter even purely local data storage still requires consent unless it's "strictly necessary" to implement something the user has requested. For example, see the discussion the sibling commenter linked around storing UI customization choices for only the duration of the current session: https://ec.europa.eu/justice/article-29/documentation/opinion-recommendation/files/2012/wp194_en.pdf https://ec.europa.eu/justice/article-29/documentation/opinio...
  - troupo 3y ago
    You don't need consent in this case, as clearly stated in 3.6 UI customization cookies --- start quote --- 3.6 UI customization cookies These customization functionalities are thus explicitly enabled by the user of an information society service (e.g. by clicking on button or ticking a box) although in the absence of additional information the intention of the user could not be interpreted as a preference to remember that choice for longer than a browser session (or no more than a few additional hours). As such only session (or short term) cookies storing such information are exempted under CRITERION B --- end quote ---
    - jefftk 3y ago
      See discussion above: https://news.ycombinator.com/item?id=38901520 https://news.ycombinator.com/item?id=38901520 As long as it's clear to the user that they're making a site-wide UI customization choice and just not choosing the language for this specific example I agree with you, but I don't think it's clear in the typical case.
      - troupo 3y ago
        IMO this is splitting hairs, and no one will take you to court because you changed the snippet language across the entire site for the session
gbuk2013 3y ago
As long as it’s implemented as a session cookie (or local storage as IIRC it also behaves as a session cookie) it should not need consent (as per 3.6 “UI customisation cookies” of https://ec.europa.eu/justice/article-29/documentation/opinion-recommendation/files/2012/wp194_en.pdf https://ec.europa.eu/justice/article-29/documentation/opinio...)
- jefftk 3y ago
  I agree for something that's clearly customizing the UI of the whole site, but if it looks like you're choosing a language only for the currently displayed snippet then I think that wouldn't qualify?
  - gbuk2013 3y ago
    I think it still qualifies - in the guidance doc (and a related doc focused on tracking cookies) the focus is on the purpose of the cookie - the intention is to avoid tracking the user - a session cookie that is specifically for remembering a choice a user made in relation to the UI passes the test of a) being necessary to enable a piece of functionality and b) being set as a result of an explicit action on the part of the user in clicking on the particular language tab.
    - jefftk 3y ago
      I think the place where it gets tricky is whether you're meeting the "strictly necessary in order to provide an information society service explicitly requested by the subscriber or user" standard. If the control looks like it only affects the current box, then I don't think storing the choice to apply beyond the current page meets that standard.
      - gbuk2013 3y ago
        agree to disagree ¯\_(ツ)_/¯

by jefftk 3y ago

Gustek 3y ago

My understanding of ePrivacy (mostly GDPR) is that this kind of feature does not require consent. It's only features that would allow you for tracking of the user that require consent. Storing some setting in a local storage, never sending it to the server is fine. Things get a bit muddy when sending to server but even then you may not need a consent if it is a feature that is required for correct working of the website or better experience without tracking and profiling.

diggan 3y ago
This is correct. Unless it involves personal data and/or tracking the user somehow, then GDPR isn't relevant. Example: If you're storing lightOrDarkTheme in a cookie/localStorage, then there is no need to try to follow any directives, nor are you required to inform the user about that you're storing the preference.
jefftk 3y ago
GDPR and ePrivacy are different regulations. Under the latter even purely local data storage still requires consent unless it's "strictly necessary" to implement something the user has requested. For example, see the discussion the sibling commenter linked around storing UI customization choices for only the duration of the current session: https://ec.europa.eu/justice/article-29/documentation/opinion-recommendation/files/2012/wp194_en.pdf https://ec.europa.eu/justice/article-29/documentation/opinio...
- troupo 3y ago
  You don't need consent in this case, as clearly stated in 3.6 UI customization cookies --- start quote --- 3.6 UI customization cookies These customization functionalities are thus explicitly enabled by the user of an information society service (e.g. by clicking on button or ticking a box) although in the absence of additional information the intention of the user could not be interpreted as a preference to remember that choice for longer than a browser session (or no more than a few additional hours). As such only session (or short term) cookies storing such information are exempted under CRITERION B --- end quote ---
  - jefftk 3y ago
    See discussion above: https://news.ycombinator.com/item?id=38901520 https://news.ycombinator.com/item?id=38901520 As long as it's clear to the user that they're making a site-wide UI customization choice and just not choosing the language for this specific example I agree with you, but I don't think it's clear in the typical case.
    - troupo 3y ago
      IMO this is splitting hairs, and no one will take you to court because you changed the snippet language across the entire site for the session

gbuk2013 3y ago

As long as it’s implemented as a session cookie (or local storage as IIRC it also behaves as a session cookie) it should not need consent (as per 3.6 “UI customisation cookies” of https://ec.europa.eu/justice/article-29/documentation/opinion-recommendation/files/2012/wp194_en.pdf https://ec.europa.eu/justice/article-29/documentation/opinio...)

jefftk 3y ago
I agree for something that's clearly customizing the UI of the whole site, but if it looks like you're choosing a language only for the currently displayed snippet then I think that wouldn't qualify?
- gbuk2013 3y ago
  I think it still qualifies - in the guidance doc (and a related doc focused on tracking cookies) the focus is on the purpose of the cookie - the intention is to avoid tracking the user - a session cookie that is specifically for remembering a choice a user made in relation to the UI passes the test of a) being necessary to enable a piece of functionality and b) being set as a result of an explicit action on the part of the user in clicking on the particular language tab.
  - jefftk 3y ago
    I think the place where it gets tricky is whether you're meeting the "strictly necessary in order to provide an information society service explicitly requested by the subscriber or user" standard. If the control looks like it only affects the current box, then I don't think storing the choice to apply beyond the current page meets that standard.
    - gbuk2013 3y ago
      agree to disagree ¯\_(ツ)_/¯