Skip to main content
Hafan

What are storage and access technologies?

Contents

At a glance

  • PECR applies to any technology that stores information, or accesses information stored, on a subscriber or user’s ‘terminal equipment’.
  • PECR allows you to use storage and access technologies in particular circumstances, or with valid consent from the user.
  • The rules apply to any use of these technologies, including on mobile apps and connected devices.
  • Where the information stored or accessed is personal data, the UK GDPR also applies.

In detail

What technologies does PECR apply to?

PECR applies to any technology that stores information, or accesses information stored, on a subscriber or user’s ‘terminal equipment’. This includes, but is not limited to:

  • cookies;
  • tracking pixels;
  • link decoration and navigational tracking;
  • web storage;
  • fingerprinting techniques; and
  • scripts and tags.

This guidance uses the term ‘storage and access technologies’ to refer to these. PECR allows you to use storage and access technologies in particular circumstances, or with valid consent from the user. The rules are explained in the ‘What are the rules?’ section.

The rules apply to any use of these technologies, including in web browsers, mobile apps and connected devices. For example, a mobile app developer might wish to store information on a user’s device, or access data from that device. These services can lead to storage or access of information on the user’s device just like any website, so these rules will still apply.  

The terms ‘subscriber’, ‘user’ and ‘terminal equipment’ are explained in the ‘What are the rules?’ section.

Cwcis

Cookies are small text files generated by a web server responding to a request from a website. The user’s device can store cookies (for example, via their web browser) and send the information back when they next make a request to the same web server.

Cookies are widely used to make websites work, or work more efficiently, and to provide information to the website operator. For example, they can be used for:

  • recognising a user’s device;
  • remembering what’s in a shopping basket when shopping for goods online;
  • supporting users to log in to a website or remembering they are logged in; or
  • analysing traffic to a website and how users interact with the website.

They can also be used for other purposes, such as tracking users' browsing behaviour.

Tracking pixels

Tracking pixels are small pieces of code, usually an image file, embedded into a piece of content like a website or an email. Their purpose is to create a communication between the user’s client (for example, a web browser) and a server. The server can then identify information, such as when a user has viewed a webpage or opened an email.

Example

An organisation conducts electronic marketing and incorporates a tracking pixel within its emails. The pixels are used to record information including the time, location and operating system of the device used to read the email.

The majority of electronic mail marketing is governed by Regulation 22 of PECR, but where tracking pixels store information (or gain access to information stored) on a user’s device, Regulation 6 applies to this processing.

Link decoration and navigational tracking

Regulation 6 applies where link decoration and navigational tracking techniques involve storage of, and/or access to information on a device. The key consideration for compliance is the purpose for which the techniques are used.

Link decoration refers to the practice of adding extra information to the URL in a link that someone clicks on. This doesn’t change the destination of the link, but provides a way to pass additional information to the destination site beyond what is essential to navigate to the page that the user wants to visit.

This extra information is generated:

  • statically, eg by being attached to a URL when a link is created; or
  • dynamically, eg through the use of JavaScript code.

When a user navigates to the webpage via the URL, the browser loads the requested resource. It may also involve storage or access of other information.

Online services often use link decoration to identify the origin of their inbound source of traffic — such as a specific email campaign.

Example

An e-commerce site emails its customers providing a URL to an article about its new product, available at https://www.example.com/article

When the recipient clicks on the URL from the email they received, they are taken to: https://www.example.com/article?referrer_source=emailnewsletter

However, this technique can also be used to pass tracking information around the web. Navigational tracking is where link decoration is used to identify that a user of one site is the same person as a user on another site. For example, by adding a user ID to a URL. The same user ID may also be stored in a cookie or local storage, which can then be accessed to identify the user.

Example

As part of a marketing campaign, an advertiser places ads on multiple social media platforms. They want to know how many sales originate from each platform. They also want to re-target users on each platform who have clicked on an ad but did not go on to make a purchase.

While scrolling on a social media platform, a user clicks on a relevant URL embedded in an ad and navigates to the advertiser’s website. The social media platform adds a unique user ID to the URL when a user clicks on the advertiser’s ad. The advertiser stores the unique identifier in a first-party cookie. 

The user leaves the advertiser’s website having viewed an item but without making a purchase. The advertiser uses the information passed from the social media site via the link decoration to re-target adverts about that item to that user on the same social media platform.

Regulation 6 will apply.

Device fingerprinting

Device fingerprinting, such as browser fingerprinting techniques, involves the collection of pieces of information about a device’s software or hardware. These can be combined to uniquely identify a particular device.

Device fingerprinting may sometimes be used in the belief that Regulation 6 does not apply to this process. However, it will apply where fingerprinting stores information, or accesses information stored, on a device.

Examples of the information elements that fingerprinting techniques can single out, link, or infer include (but are not limited to):

  • data derived from the configuration of a device;
  • data exposed by the use of particular network protocols;
  • CSS information;
  • JavaScript objects;
  • HTTP header information,
  • clock information;
  • TCP stack variation;
  • installed fonts;
  • installed plugins within the browser; and
  • use of any APIs (internal, external or both).

It is also possible to combine these elements with other information, such as IP addresses or unique identifiers.

Example

An online service uses device fingerprinting for detecting fraudulent account creation and use of login credentials.

It involves collecting hardware information, browser information, location information and the IP address. This information is sent to a third-party security provider which probabilistically identifies a device using this information, to identify whether the activity is fraudulent.

Regulation 6 will apply.

Example

A retailer collects email addresses from visitors to their website when they register for their newsletter or make a purchase. It uses this email address to re-target their visitors with ads for their products on other websites.

The retail site embeds a tag on the webpage from an identity vendor, which accesses and hashes the email address on the page when collected. This hashing technique generates a value, which is then stored in a first-party cookie on the user’s browser. Later the identity vendor helps the retail website’s advertising and social media partners to match this hashed value with additional information to enable the retargeting of that user.

Even though the full email address is “masked”, an identifier is created for the purpose of processing information relating to the user, regardless of whether the original email address or other personal information can be inferred from it.

Regulation 6 will apply. The UK GDPR also applies, as this processing involves personal data.

Web storage

Web storage is another way in which online services can store information, or access information stored, on someone’s device. It involves websites storing data in someone’s browser. It’s also known as “local storage”, “HTML5 storage” or “DOM storage”.

Web storage involves a standard API that browsers include, known as the web storage API. There are two types of storage:

  • “localStorage”, where the data may be stored permanently unless removed; and
  • “sessionStorage”, where the data is stored only for the duration of the user’s visit to a webpage. 

The main differences between web storage and a technology like cookies are that:

  • web storage allows more data to be stored in the browser; but
  • the data is not transferred to a server (unless this is done manually).

In some situations, information may be generated as part of the general function of the device’s software or hardware. PECR may not apply when that information, or information derived from it, is not accessed by an outside entity and stays on the device.

Example

A website wants to increase the value of the digital advertising they display. They decide to integrate a service on their site that helps segment their website visitors into audiences and categories relevant to potential advertisers.

Now, when a user visits the website, the new service uses information obtained from the web page and the user's activity to understand if the user can be categorised into a particular audience category. When the information on the web page aligns to a pre-defined audience segment (eg “sport”), the service stores this information in the browser's local storage. 

Later, the user visits another page on the same site where the website owner has chosen to display an ad. Here, the service accesses the audience category previously recorded in localStorage and passes them to the advertiser interested in displaying a digital ad to a particular audience.

Regulation 6 will apply.

Scripts and tags

Online services can add pieces of JavaScript code, often referred to as ‘scripts’ or ‘tags’, to web pages to collect additional information about visitors to their service. When a user accesses a web page, their browser interprets the instructions included in the script and executes them. While scripts can be used for many purposes, ‘tags’ often refers to a JavaScript ‘snippet’ included specifically to gather data about a website's visitors.

To record and track information about a user, tags often involve the use of other storage and access technologies such as cookies, local storage or device fingerprinting techniques.

Regulation 6 of PECR applies wherever the use of scripts and tags accesses or stores information on a user’s device — whether or not this is in conjunction with other storage and access technologies. 

Organisations commonly work with a range of technologies and third-party providers when operating their services. To reduce complexity, they may use a ‘tag management system’ or ‘tag manager’ so they can add, edit or remove tags centrally.

Server-side tags can further reduce the amount of tag activity on a user's device, improving page loading times. Here, data relating to the user's activity on a site is sent to the tag manager's server before a decision is made about what data should be sent to each individual partner.

Where the information stored or accessed is personal data, the UK GDPR also applies.

Using storage and access technologies in different contexts

Storage and access technologies can be deployed in different contexts. The most common examples are:

  • ‘first-party’ or ‘third-party’;
  • ‘session’ or ‘persistent’; and
  • ‘client-side’ or ‘server-side’.

It is important to understand that these contexts don’t necessarily impact whether Regulation 6 applies. The key consideration is whether the technology stores or accesses information on a device and the purposes for which it does so.

What is the difference between ‘first-party’ and ‘third-party’ storage and access technologies?

Many uses of storage and access technologies differentiate between the concepts of ‘first party’ and ‘third party’. However, these terms can mean different things depending on the circumstances in which you use them.

The terms have no inherent meaning in PECR or UK GDPR. The PECR rules apply to any technology you use to store information, or access information stored, in someone’s device — whether in a first-party context or a third-party context.

The concepts are more relevant to web standards development and online practices.

The classic distinction usually relates to web standards terminology, where:

  • ‘first party’ means the website the user is visiting (eg the domain/URL shown in the browser’s address bar); and
  • ‘third party’ means a domain other than the one the user is visiting (eg cookies, code or other technologies from other websites, which allow the third party to store or access information on the device).

The most well-known example of this is with cookies, which may be ‘first-party cookies’ or ‘third-party cookies’.

Online services commonly use third-party cookies. For example, when they incorporate resources hosted elsewhere, such as images, social media plugins or advertising.

However, third-party cookies can also link people’s activity across different sites and devices — ie web and cross-device tracking. This presents specific privacy risks, particularly when users may not know it is happening. Over time, software applications like web browsers have implemented limitations on the use of third-party cookies. These include providing user controls such as “tracking protection” features and restricting or blocking third-party cookies from being set.

In some cases, this has led to the resources previously delivered by a third-party cookie being delivered via a first-party cookie — even where the resource itself is still external to the online service the user interacts with. This, alongside the use of communications at the server level, further complicates use of the terms.

Ultimately, whether a storage and access technology is classed as ‘first-party’ or ‘third-party’ is not the main consideration for data protection and privacy purposes. Instead, what’s primarily relevant is:

  • who is responsible for the storage or access on terminal equipment — which in most cases is the service provider; and
  • the purpose(s) of the storage / access.

Example

An organisation, Example.com, has a presence on the social media network Social.net. As part of its marketing strategy, Example.com wants to identify which users of its website are also members of Social.net so that it can promote its products and services to them on that platform.

Social.net provides a number of targeting tools for these purposes. These include a JavaScript snippet that Example.com can add either to the header code of its website (so that it records visitor activity across all pages), or to specific pages or sections of the site.

Using the tool leads to information about website visitors being disclosed to Social.net. This identifies visitors who are members of the social media network.

Example.com can deploy the tool in both the first-party and third-party contexts.

In the first instance, a visitor’s browser recognises the tool as something delivered from Example.com’s domain. In the second, the browser recognises it as something delivered from Social.net’s domain.

However, Example.com’s choice to deploy the tool in one context or the other doesn’t change the fact that it may result in the storage or access of information on the devices of people visiting its website.

As such, Regulation 6 applies and Example.com must obtain prior consent for the use of the tool.

What is the difference between ‘session’ and ‘persistent’ storage?

Storage and access technologies can last for different periods of time, depending on the choices you make when setting them. They can be:

  • session storage, which generally expires when someone closes their browser or shortly afterwards; or
  • persistent storage, where the information is stored between browser sessions and can therefore have a longer duration.

This is not an absolute rule. For example, some session cookies can be restored by the browser in the next session, and effectively last indefinitely. Similarly, data can be removed from persistent storage.

The purpose of the technology can sometimes determine whether the storage is session or persistent. For example:

  • session storage is generally used for things that don’t need to be stored for a long period of time (eg cookies that remember what someone has put in their shopping basket); and
  • persistent storage is generally used for things like remembering someone’s preferences between visits to an online service (eg a preference cookie).

As the online service provider, you are responsible for making decisions about the duration of storage and access technologies on your site, such as whether persistent storage is necessary for your purpose.

The ‘how long can we store information for?’ section contains more information about how to make these decisions.

What is the difference between ‘client-side’ and ‘server-side’?

In web development, the terms ‘client’ and ‘server’ refer to who is making and responding to requests for information over the internet.

A common example is with HTTP requests and responses. When someone clicks a link on a web page or types a URL into their browser’s address bar, their browser — the client — communicates with a web server asking it to provide a resource (eg the content hosted at a particular URL). The server replies with a HTTP response, which, if successful, will include the requested resource.

A ‘client’ is commonly a web browser, but it may also be a mobile app or IoT device. The ‘server’ may be a web server, a database or email server.

Tag management systems can be run on the ‘client-side’ — where the user’s browser is instructed to execute the tags. They can also be delivered by ‘server-side’ solutions — where event data received from the client-side is further processed and distributed to various tag partners on a remote server.

These tag partners may not be directly collecting the information from the user, rather they may be obtaining information from the party deploying the tag management system. 

Regulation 6 will apply in both a ‘client-side’ and ‘server-side’ context where information is stored or accessed on a device.  Where personal data is involved, both the tag management deployer and other parties receiving the information have responsibilities under the UK GDPR.

The use of server-side tags may provide benefits to users, including faster page loading times. But it can also mean that the data being collected, and any third parties the data is shared with, may not be visible to the user. For this reason, website operators using a server-side tag manager must inform the user about any third parties the information will be shared with.

Example

An e-commerce organisation uses a tag management system to centrally configure its JavaScript tags without needing to directly edit its website’s code.

The tag management system allows the organisation to collect information from JavaScript tags to understand its users. This information includes:

  • the device operating system, browser and version;
  • screen dimensions of their device; and
  • specific ‘events’ like whether they completed a purchase.

The organisation also integrates tags from:

  • a third-party social media platform, to help the organisation to measure the effectiveness of their advertising campaigns;
  • an adtech partner specialising in re-marketing campaigns; and
  • an analytics platform that helps the organisation to understand their user journeys.

The use of JavaScript tags for non-essential purposes will require consent under PECR. This is the case regardless of whether the tag management system is running on the client-side or server-side.