Surely you don’t need consent to display a user interface? UIs illustrate issues re the EDPB’s strict ePrivacy guidelines, combined with a strict approach re consent exemptions. After all:
– UIs are programming instructions (e.g. in HTML, CSS, Javascript in the case of websites) so that your browser / OS / … knows how to draw the UI
– While their purpose is different, those instructions are technically similar to those in e.g. PHP, Python or Javascript to generate an identifier or to combine information
– Under Art. 5(3) of the ePrivacy Directive (ePD), the “storage of information” and the gaining of access to information already stored on a device require a justification: (i) consent, (ii) strict necessity for provision of a digital service, (iii) sole use for transmission of an electronic communication
– In its proposed guidelines, the EDPB says that this rule doesn’t only apply to cookies and the like but also to the (ephemeral) storage of information, such as in RAM (random access memory) and even CPU cache => browser runtime environment logically also covered
– On local processing, the EDPB says that “If […] for example in the client-side code, the processed information made available is being sent back […] to a server, such an operation (instructed by the entity producing the client-side code distributed on the user terminal) would constitute a �gaining of access to information already stored�. The fact that this information is being produced locally does not preclude the application of Article 5(3) ePD”.
– Yet if that local processing leads to access to information “already stored”, then any result of instructions in client-side code (e.g. UI) is necessarily (from the EDPB’s perspective) “stored
– Asking for consent before displaying a UI makes no sense whatsoever
– Surely then displaying a UI is strictly necessary for provision of the service explicitly requested by the user
– Where though does necessity end? For a provider, displaying a UI shares the same purpose as any functionality, including debugging, service improvement & analytics: it’s in order to continuously provide the best service according to its own definition of the service (e.g. there is a wide gap between a barebones “strictly necessary” UI and a really good one)
– Data protection regulators tend to differentiate between actual delivery of a service and service improvement under the GDPR, and national positions on analytics show ePrivacy harmonisation is messy, so greater clarity is needed
– When this was purely about cookies & such, this was less of an issue. But now that the EDPB has considered that even ephemeral processing is “storage”, everything gets caught
– Perhaps (contrary to the EDPB’s view) information that passes ephemerally on a device is not �stored� � and the ePD was meant to only cover the act of (actively) storing information and the actual (active) retrieval of information?
Just 10 days to comment. Reach out if you need help!
Did this analysis get you thinking? Reach out!
DataLaws.net is entirely open-access, and instead of getting your data in exchange for this content, how about another trade? If this commentary saved you research time or sparked an idea, feel free to invite me over for tea, chai or a hot chocolate next time you are around Brussels or Antwerp - or invite me over to your offices for a chat!
Get in touch ↗ Let's connect on LinkedIn ↗