datenrecht.ch

EDSA: Gui­de­lines on the scope of appli­ca­ti­on of coo­kie con­sent, comm­ents on coo­kies under Swiss law

On Novem­ber 14, 2023, the Euro­pean Data Pro­tec­tion Board EDPB published its gui­de­lines on the mate­ri­al scope of Art. 5 (3) of the GDPR. e‑Privacy Direc­ti­ve published (Gui­de­lines 2/2023 on Tech­ni­cal Scope of Art. 5(3) of ePri­va­cy Direc­ti­ve).

Art. 5 para. 3 in its cur­rent ver­si­on was amen­ded by the DIRECTIVE 2009/136/EC and has the fol­lo­wing wording:

(3. Mem­ber Sta­tes shall ensu­re that the Sto­rage of infor­ma­ti­on or the Access on infor­ma­ti­on that has alre­a­dy been Ter­mi­nal device of a sub­scri­ber or user is only per­mit­ted if the sub­scri­ber or user con­cer­ned has given clear and com­pre­hen­si­ve con­sent on the basis of Infor­ma­ti­onwhich it recei­ves in accordance with Direc­ti­ve 95/46/EC, inter alia, on the pur­po­ses of pro­ce­s­sing, its Con­sent has given. This shall not pre­vent tech­ni­cal sto­rage or access if the sole pur­po­se is to car­ry out the trans­mis­si­on of a com­mu­ni­ca­ti­on over an elec­tro­nic com­mu­ni­ca­ti­ons net­work or if this is strict­ly neces­sa­ry to enable the pro­vi­der of an infor­ma­ti­on socie­ty ser­vice expli­ci­t­ly reque­sted by the sub­scri­ber or user to pro­vi­de this service.

It is undis­pu­ted that this pro­vi­si­on does not only cover coo­kies; this is why coo­kie poli­ci­es usual­ly refer to “simi­lar tech­no­lo­gies”, but the scope of appli­ca­ti­on is unclear in detail.

The EDPB attempts to shed light on the dark­ness of such tech­no­lo­gies with the express inten­ti­on of pre­ven­ting cir­cum­ven­ti­on, i.e. with a deli­bera­te­ly broad interpretation.

The facts of Art. 5 para. 3 have four ele­ments:

  1. Infor­ma­ti­on” is stored or read out;
  2. It is about a “ter­mi­nal device”;
  3. the tran­sac­tions are in con­nec­tion with a tele­com­mu­ni­ca­ti­ons trans­mis­si­on in a public net­work (“pro­vi­si­on of publicly available elec­tro­nic com­mu­ni­ca­ti­ons ser­vices in public com­mu­ni­ca­ti­ons networks”);
  4. the­re is a “sto­rage” of or “access” to information.

The EDSA dis­cus­ses the­se four elements:

Infor­ma­ti­on”

  • Not only per­so­nal data is cover­ed, becau­se it is about the con­fi­den­tia­li­ty of infor­ma­ti­on and pro­tec­tion against intru­si­on, not infor­ma­tio­nal self-deter­mi­na­ti­on, i.e. not a cer­tain use of data with per­so­nal refe­rence – this is the gui­ding prin­ci­ple for the inter­pre­ta­ti­ons of the EDPB, but wit­hout attemp­ting to deter­mi­ne the limits of the cor­re­spon­ding pro­tec­ted area;
  • It is suf­fi­ci­ent if infor­ma­ti­on is only read – and not chan­ged – which is why, for exam­p­le, a MAC address is also recorded.

Ter­mi­nal device”

  • An end device is any device that not only trans­mits infor­ma­ti­on. Whe­ther an end device belongs to a user, is ren­ted or only used is irrelevant.
  • It also does not mat­ter whe­ther the user wants or is awa­re of the pro­ce­s­sing of infor­ma­ti­on via the end device.
  • Examp­les include smart­phones, lap­tops, con­nec­ted cars, smart TVs and smart glasses.

Tele­com­mu­ni­ca­ti­on transmission

  • This requi­re­ment is hard­ly rest­ric­ti­ve. Howe­ver, only public net­works are cover­ed. Howe­ver, a cer­tain rest­ric­tion of the user group, e.g. to sub­scri­bers, does not exclude it from the scope of application.

Access” to information

  • Infor­ma­ti­on of a legal enti­ty is also pro­tec­ted against access.
  • Access is also recor­ded if the data is not stored at all or is stored by ano­ther body. The ori­gin of the data read out is also irrele­vant. Art. 5 para. 3 the­r­e­fo­re applies when­ever infor­ma­ti­on is actively accessed.
  • Use cases are ins­truc­tions from the ser­ver to the end device with a feed­back of infor­ma­ti­on, such as when rea­ding coo­kies. Access to infor­ma­ti­on via an API in soft­ware on the end device, for exam­p­le, or a Java script via which a brow­ser pro­vi­des infor­ma­ti­on, would also be recor­ded becau­se the pro­cu­re­ment of infor­ma­ti­on is also actively initia­ted here.
  • This also applies if one body initia­tes the trans­mis­si­on of infor­ma­ti­on to ano­ther body.

Sto­rage” of information

  • This means that infor­ma­ti­on is stored on a phy­si­cal data car­ri­er that func­tion­al­ly belongs to the end device, for exam­p­le in RAM or a cache, or on an exter­nal but con­nec­ted memo­ry. This is usual­ly not done direct­ly, but via soft­ware on the end device that gene­ra­tes the infor­ma­ti­on, but it can also be done by the user them­sel­ves or ano­ther loca­ti­on, as long as the sto­rage is only actively initiated.
  • How lar­ge the infor­ma­ti­on is and how long it is stored does not matter.

Use cases

The use cases dis­cus­sed by the EDSA include the following:

  • The rea­ding of MAC or IP addresses;
  • Fin­ger­prin­ting based on infor­ma­ti­on such as HTTP hea­der information;
  • Pixel track­ing or track­ing through links, i.e. in both cases the call of a coded URL by the mail cli­ent or brow­ser with a cor­re­spon­ding trans­fer of infor­ma­ti­on to a ser­ver. The trans­mis­si­on of the pixel or coded link results in the acti­ve rea­ding of information:

    Under the con­di­ti­on that said pixel or tracked URL have been dis­tri­bu­ted over a public com­mu­ni­ca­ti­on net­work, it is clear that it con­sti­tu­tes sto­rage on the com­mu­ni­ca­ti­on net­work user’s ter­mi­nal equip­ment, at the very least through the caching mecha­nism of the cli­ent-side soft­ware. As such, Artic­le 5(3) ePD is applicable;

  • a request for infor­ma­ti­on via an API, pro­vi­ded that infor­ma­ti­on is sub­se­quent­ly trans­mit­ted via a network;
  • Track­ing sole­ly via an IP address, pro­vi­ded that this infor­ma­ti­on is read out by the end device – for exam­p­le by a rou­ter – even with a dyna­mic IP address, which is also gene­ra­ted on the ser­ver side via DHCP, for example;
  • rea­ding infor­ma­ti­on from a con­nec­ted IoT device if it trans­mits infor­ma­ti­on via a public net­work (e.g. via WiFi or a SIM card), but not if infor­ma­ti­on is trans­mit­ted via a non-public con­nec­tion (point-to-point connection);
  • the rea­ding of a uni­que iden­ti­fier, e.g. a hash value based on user data or a login.

Howe­ver, access to infor­ma­ti­on exclu­si­ve­ly in the end device its­elf, such as an appli­ca­ti­on in the cell pho­ne to the came­ra or in the brow­ser to coo­kies or other local­ly stored data, is not recorded.

A look at Switzerland

Switz­er­land has a rela­ted pro­vi­si­on in Art. 45c TCA (“Pro­ce­s­sing on third-par­ty devices”):

Editing data on third-par­ty devices by means of tele­com­mu­ni­ca­ti­on trans­mis­si­on is only permitted: […] 

b. if the users are infor­med about the pro­ce­s­sing and its pur­po­se informs and be advi­sed that they may not pro­cess the Reject can.

In prin­ci­ple, this pro­vi­si­on requi­res infor­ma­ti­on about the pro­ce­s­sing and its pur­po­se and the right to object, even if data is pro­ce­s­sed “on third-par­ty devices”. Howe­ver, its scope of appli­ca­ti­on is lar­ge­ly unclear. The wor­ding, for exam­p­le, only refers to pro­ce­s­sing on the third-par­ty device. Accor­ding to the mes­sa­ge, howe­ver, the rea­ding of infor­ma­ti­on should also be cover­ed (“pro­ce­s­sing of data within the mea­ning of Artic­le 45c inclu­des sto­rage, access and any other processing”).

The doc­tri­ne then argues that Art. 45c TCA only covers the pro­ce­s­sing of per­so­nal data. Howe­ver, the dis­patch on Art. 45c TCA in its­elf sug­gests a broa­der inter­pre­ta­ti­on, espe­ci­al­ly sin­ce it not only men­ti­ons pri­va­cy as the pur­po­se of pro­tec­tion (and even here: Art. 13 BV also con­cerns the pro­ce­s­sing of non-per­so­nal data), but also the pro­tec­tion against access to devices, and express­ly intends a refe­rence to Art. 5 para. 3 (but in the ori­gi­nal ver­si­on of the Direc­ti­ve, which had pro­vi­ded for a right of objec­tion, but not a requi­re­ment for consent).

Howe­ver, as soon as per­so­nal data is pro­ce­s­sed, data pro­tec­tion law is appli­ca­ble. The fol­lo­wing infor­ma­ti­on applies:

  • The con­cept of per­so­nal data still cor­re­sponds to the Logi­step decis­i­on. A date is only per­so­nal if it can be assi­gned to a natu­ral per­son with rea­sonable effort. A coo­kie ID, a Mac address, etc. does not gene­ral­ly con­sti­tu­te per­so­nal data for the ope­ra­tor. It would be dif­fe­rent if the ope­ra­tor uses this infor­ma­ti­on in a way that enables iden­ti­fi­ca­ti­on, e.g. in cri­mi­nal pro­ce­e­dings invol­ving the ISP or in con­nec­tion with a user login.
  • Con­sent is gene­ral­ly not requi­red. Art. 45c TCA only pro­vi­des for a right to object and, as is well known, data pro­tec­tion law does not requi­re con­sent as long as the pro­ce­s­sing prin­ci­ples are com­plied with.
  • The prin­ci­ples of data pro­tec­tion law requi­re trans­pa­ren­cy. In addi­ti­on, the­re is the obli­ga­ti­on to pro­vi­de infor­ma­ti­on in accordance with Art. 19 FADP.
  • Neither Art. 45c TCA nor data pro­tec­tion law requi­re a coo­kie ban­ner. It is suf­fi­ci­ent to pro­vi­de infor­ma­ti­on in a pri­va­cy poli­cy or coo­kie notice.
  • If a coo­kie ban­ner is used, it does not have to be desi­gned in a cer­tain way as long as it is not mis­lea­ding. In prin­ci­ple, an “OK” but­ton, an “Agree” but­ton, a “Con­fi­gu­re” but­ton or a com­bi­na­ti­on is per­mit­ted. Anyo­ne who uses an “Agree” and a “Con­fi­gu­re” but­ton, but no “Reject” but­ton, is not beha­ving in a par­ti­cu­lar­ly user-fri­end­ly man­ner, but is not vio­la­ting Swiss law. Such a design is also unli­kely to vio­la­te the prin­ci­ple of good faith, inso­far as it applies at all (which pre­sup­po­ses the pro­ce­s­sing of per­so­nal data). User-unfri­end­ly beha­vi­or is not con­tra­ry to good faith; the thres­hold of inter­fe­rence is not that low, and the­re is no spe­cial rela­ti­on­ship with the user of a web­site that could requi­re a hig­her standard.
  • Anyo­ne who deci­des to work with con­sent is allo­wed to do so.. In Switz­er­land, the­re is no requi­re­ment to tech­ni­cal­ly faci­li­ta­te the with­dra­wal of con­sent (nor the objec­tion pur­su­ant to Art. 45c TCA). Accor­din­gly, the­re is no obli­ga­ti­on to offer an opt-out menu or simi­lar on an ongo­ing basis. Howe­ver, anyo­ne working with con­sent must obser­ve the pri­va­cy by default prin­ci­ple. Depen­ding on the design of the set­ting opti­ons, this may result in the requi­re­ment to deac­ti­va­te the coo­kies affec­ted by con­sent by default.
  • The pur­po­se is the bench­mark for asses­sing pro­por­tio­na­li­ty. The con­trol­ler free­ly sets the pur­po­se in accordance with the prin­ci­ple of pri­va­te auto­no­my within the frame­work of man­da­to­ry law. The­re is no legal pur­po­se in the pri­va­te sec­tor out­side of man­da­to­ry pro­ce­s­sing, i.e. no “iustum pre­ti­um” for data pro­ce­s­sing. Data pro­tec­tion law only requi­res that the con­trol­ler does not lea­ve the scope of the self-impo­sed pur­po­se. Accor­din­gly, it can­not be said that the ope­ra­ti­on of a web­site or app does not objec­tively requi­re coo­kies, which is why their use would be dis­pro­por­tio­na­te, becau­se “ope­ra­ti­on of the web­site” descri­bes a pur­po­se, the deter­mi­na­ti­on of which is the respon­si­bi­li­ty of the con­trol­ler and not of the legis­la­tor, an aut­ho­ri­ty or a “rea­sonable man”.

Aut­ho­ri­ty

Area

Topics

Rela­ted articles

Sub­scri­be

Sub­scri­be to news →