Digital Omnibus: pros & cons of Council’s ePrivacy proposals

The Digital Omnibus evolutions at the level of the EU Council continue to have a mix of good and bad. Today, a quick focus on ePrivacy rules. First, some good:

– There’s an interesting new Recital 46a on standardisation re consent preferences, stressing that technical solutions should allow data subjects to “easily set their consent preferences and enable them to make granular and informed decisions”, and adding that “The standards should be prepared in a way that takes into account the operation of businesses in a digital environment and that ensures information is promoted in the digital economy and supports access to content and services on the open web”.

– Global Privacy Control is clearly not an solution to the 88b discussion (now renumbered as “88a” after the deletion by the Council of the previous 88a, due to changes to Art. 5(3) of the ePrivacy Directive [ePD] in their draft), as the Council wishes 88b/a to cover technical means to allow data subjects “to withdraw consent” as well as to give or refuse consent or to object to legitimate interest processing.
[More on this issue: https://lnkd.in/eAFgm_Jn ]

– The Council wants GDPR supervisory authorities to have the power to enforce 5(3) ePD, which could end a discrepancy among various Member States.

– The ePD transition period would be 24 months, not 18.

Some bad:

– The Council continues to misunderstand the issue of fraud prevention. It has placed fraud prevention within the “security” consent exemption, while make that exemption more restrictive:

maintaining or restoring the security of the interface strictly necessary for the provision of an information society service requested by the user or the security of the terminal equipment used for the provision of such service, including in particular cybersecurity, the protection of personal data and privacy of the user and prevention of fraud

=> Fraud prevention isn’t usually about the “security of the interface strictly necessary” for the provision of a service. Usually it’s about ensuring that the *broader* service is protected against fraudulent users/load. By focussing purely on the “interface” itself – and then only the interface “strictly” necessary for the service – the Council’s addition about fraud prevention is in effect near useless. In most cases, fraudsters will then need to give their consent before anything can be done against them.

– You thought contextual advertising might not require consent under the ePD? Think again, says the Council, removing an earlier proposal to exempt consent when “measuring the display and performance of advertising made solely on the basis of the immediate content displayed on the user’s interface and not based on any type of profiling”. Given the EDPB’s expansive interpretation of the scope of 5(3) ePD, consent will be required.

It’s an odd mix, but still overall in my view worse than the current 5(3) ePD framework, however flawed its interpretation may be.

Data protection

🫖

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 ↗