Conformance to European Union's "ePrivacy Directive" 2002/58/EC as amended by 2006/24/EC & 2009/136/EC

[xax]

Art. 5(3) of cited Directive provisions, that data stored on an end user's "terminal equipment" has to be either "solely for the purpose of carrying out the transmission", "strictly necessary … to provide the service", or he user has to give his consent ("with clear and comprehensive information … about the purpose"). [Any one is free to judge the sanity of cited directive.]

The fabulous Relean-Hugo-Theme stores theme variants (style sheet variants) and visited sub pages in localStorage or sessionStorage, respectively; the latter only, if params.showVisitedLinks is set true.

Could you apply a hook (adding a Javascript hook re-defining Storage.setItem to NOP in custom-header.htmlis to late; you could succeed doing that in meta.html, though).

Aside from providing means to disable "storing data on an end user's terminal equipment", providing a i18n-able consent dialogue or a hook allowing the implementation of custom consent dialogues would be very much appreciated! :)

[McShelby]

Thanks for the input. I see the necessity for such an annoyance.

I will implement the localStorage / sessionStorage proxy and a section in the docs in the next 7.x release.

Nevertheless utilization of the proxy will come in 8.x as it requires some renovation on the script side.

What can you expect from the final solution?

The theme will do the cookie handling. If it discovers missing consent or the cookie has expired (after 31 days), a hook will be called. In the default implementation, the hook always returns true.

You will have to override the hook, give your user notice and return true or false based on the users choice. The theme will handle the rest.

It will only be possible to turn off all storage facilities of the theme all together.

Third-party-scripts (every library stored in subdirectories of assets/js/) may come with their own storage and will not be affected by the users choice. This lies out of the scope and the possibilities of the theme's code.

Does this sound reasonable?

See #1070 #1071

[xax]

Thanks a lot! The sketched approach sounds very reasonable to me!

Making the theme use a proxy object to use storage looks like the clean way to implement such functionality.
For the time being I went with redefining methods on the Storage prototype early in the loading process, like so:

orig_Storage_setItem = Storage.prototype.setItem;
Object.defineProperty(Storage.prototype, 'setItem', {
  value: function(key, value) { }
});

[McShelby]

Thanks for pointing out your solution approach. This would make it possible to also interfere library code - which isn't part of my previous outline. I will do further reasearch in that direction.