By the end of the lesson, you can explain what data arises on a web page, you can tell the role of the first and the third party apart, you know the principles of the GDPR and the rights of data subjects, you can recognize deceptive design patterns, and you can treat privacy as a design question.
Why is privacy a design question?
While operating, a web service can handle data about the user, their device, and their behavior. The technical possibility does not answer what is justified to collect, for what purpose, for how long, and with what real choice. Privacy is also a question of design and of user trust: what has not been collected cannot leak (chapter 8), and the user can decide meaningfully only if they understand what happens to their data.
What does data mean on the web?
Data can be a name, an email address, or a date of birth, but seemingly insignificant details can also be linked to a person or a device: a login identifier, a persistent advertising identifier, an IP address (4.1), a precise location, purchase history, or which articles someone has read. A single piece of data is sometimes little on its own, but several together can form a detailed profile.
It is worth asking three questions:
What data arises?
Who receives it: only the operator, or also analytics, advertising, embedded-video, and social providers?
For what purpose and for how long is it kept?
If there is no clear answer to these, the user cannot make a meaningful decision. On an appointment-booking page the email address may reasonably be needed for notification; the browser's language can help in displaying the interface. Building an interest profile, however, is a different purpose: it does not follow automatically from the booking. Changing the purpose is a particularly important design moment.
flowchart LR
U[User] --> S[Service]
S -->|necessary data| M[Operation]
S -->|separate purpose and decision| A[Analytics or tracking]
A --> T[Retention and deletion]
Cookies and other ways of tracking
We discussed how a cookie works in lesson 7.2: the server sends a name–value pair, and the browser sends it back with the appropriate later requests. According to MDN, cookies serve three main purposes: session management, personalization, and tracking (recording and analyzing user behavior, often across websites). The attributes of a cookie (Secure, HttpOnly, SameSite) are security and operational properties, not automatic exemptions for privacy.
Not every cookie is tracking, and not every tracking is a cookie. A first-party login cookie is often needed for a function the user asked for. Identification can, however, also happen with a value stored in localStorage (7.3), a URL parameter, a login, server-side logs, or by linking several browser characteristics. The latter is device or browser fingerprinting: the combination of screen size, language, fonts, graphics capabilities, and other signals can make a returning device probable, and it is often less visible than a cookie.
First and third party; measurement and profiling
The first party is the website the user visited. A third party can be an analytics script, an advertising network, a map, a font, a chat module, or a social embed loaded into the page. According to MDN a third-party cookie belongs to embedded content arriving from another site, and also allows cross-site tracking; browsers increasingly block these by default. In the browser's network view (2.5) third-party content appears as a separate request. A convenient embed is thus also a data-flow decision.
There is a big difference between aggregated, briefly retained visit statistics and a behavioral profile built over a long time between individuals. For product development it is useful to learn at which step of a form many people get stuck; for this it is not necessarily needed to tie every click to a name, or to recognize the same person on other websites. A measurement that fits the purpose is often possible with less data.
Consent: real choice, not decoration
A cookie bar appears on many pages. In the good case it is a short and understandable decision point: what is necessary for operation, what is optional, for what purposes data would go, and how the choice can be changed later. Rejection must not be unjustifiably hidden or made harder either. Next to the big, colorful "accept all" button, a tiny, multi-step rejection is a bad user experience and also an ethically problematic design pattern.
Consent is worth splitting by purposes (necessary, preferences, measurement, personalized advertising). The "necessary" category is not a magic word: only the technology without which the expressly requested service cannot reasonably work may belong here. The choice must later be made as available as the acceptance. An understandable privacy notice is not instead of the banner, but its detailed background. The consent interface should be operable with the keyboard too (9.2).
The GDPR as a framework of thought
European data protection regulation, the GDPR (General Data Protection Regulation, Regulation (EU) 2016/679), emphasizes the rights of data subjects and the responsibilities of controllers. Article 5 of the regulation lists seven principles of the processing of personal data:
Principle
Meaning in design
Lawfulness, fairness, and transparency
Clear information, not deceptive handling.
Purpose limitation
We use the data only for the stated purpose.
Data minimization
We collect only the necessary data.
Accuracy
The data should be correct and up to date.
Storage limitation
We do not keep it longer than necessary.
Integrity and confidentiality
Adequate security (4.3, chapters 7 and 8).
Accountability
The controller can demonstrate compliance.
According to Chapter III, the data subject has rights, among others of access, rectification, erasure, restriction, portability, and objection. The principles above are named by the text of the regulation; their application in a concrete case depends on the purpose and circumstances of the processing. That is why it is not right to pronounce a ready legal verdict within a course on whether a real page is "GDPR-compliant". The developer's responsibility is rather to recognize the data flow in time, to ask questions, and not to treat protection as a late afterthought: is the phone number really needed? Why do we keep the event log? Who has access? How do we inform the person?
Digital ethics: what the rules do not yet settle
Something can be thought technically permitted, yet be unfair. Deceptive design patterns (formerly known as "dark patterns") are good examples of this: pre-ticked options, misleading wording, a shaming rejection button, or a flow that talks the user into handing over more data. The European Data Protection Board (EDPB) has issued a separate guideline on the topic (Guidelines 03/2022, addressed to social media interfaces), which helps in recognizing and avoiding them. A similar question is algorithmic personalization: if a system knows the vulnerable moments and tries to extract more time or money by exploiting them, "it increases conversion" is not a sufficient reason.
The designer of an ethical system asks not only whether we can obtain the data. Also whether the user understands the consequence, whether the benefit is proportionate to the intervention, and who bears the risk in case of error or abuse. Data minimization is often also a security advantage.
Worked example: newsletter and visit measurement in Kurzuspont
An event page asks for an email address for a newsletter, measures visits on the event page, and displays an embedded video. The first step is to map the data flow: the email goes to the subscription handler; the measuring code sends events; loading the video may connect to an external provider. The second step is separating the purposes: managing the newsletter, running the service, and the optional analytics are not the same.
Decision
Reason
The newsletter needs only an email address, no name
Data minimization.
The video "loads on click"
The third party does not automatically receive data.
The measurement is aggregated, with short retention
Purpose limitation, storage limitation.
The cookie bar is split by purposes, with equal "accept"/"reject" buttons
Real choice, not a deceptive pattern.
Unsubscribing is one click
Transparency, the right of the data subject.
The result is not "zero data", but considered data handling.
Common misconceptions
Statement
Clarification
"Every cookie is forbidden until there is a click."
The name of the technology does not decide the question alone: storage related to a requested function is different from tracking; the exact judgment depends on the circumstances.
"Incognito mode is completely anonymous."
It mainly treats the local browsing traces differently; the network and the visited sites can still see data.
"If we do not ask for a name, there is no personal data."
A persistent identifier or several signals together can be linked to a person or a device.
"A privacy notice solves the ethical problem."
A long, incomprehensible notice does not make a manipulative or disproportionate practice fair.
"The GDPR is only a documentation task."
It is a design question: purpose limitation, data minimization, retention.
In brief
On the web even seemingly insignificant data (identifier, IP address, browser characteristics) can be tied to a person, and together can form a profile.
A cookie is not the same as tracking; fingerprinting identifies even without cookies.
A third party (analytics, advertising, embeds) is a data-flow decision; browsers increasingly block third-party cookies.
The seven principles of Article 5 of the GDPR are a design consideration; the data subject has rights of access, rectification, erasure, restriction, portability, and objection.
Deceptive design patterns are ethical problems even when technically permitted.
Review questions
Why is a cookie not the same as tracking?
What is the difference between the first and the third party, and why is an embed a data-flow decision?
List three GDPR principles, and give a design consequence of one!
Privacy, tracking, and digital ethics
Objectives
By the end of the lesson, you can explain what data arises on a web page, you can tell the role of the first and the third party apart, you know the principles of the GDPR and the rights of data subjects, you can recognize deceptive design patterns, and you can treat privacy as a design question.
Why is privacy a design question?
While operating, a web service can handle data about the user, their device, and their behavior. The technical possibility does not answer what is justified to collect, for what purpose, for how long, and with what real choice. Privacy is also a question of design and of user trust: what has not been collected cannot leak (chapter 8), and the user can decide meaningfully only if they understand what happens to their data.
What does data mean on the web?
Data can be a name, an email address, or a date of birth, but seemingly insignificant details can also be linked to a person or a device: a login identifier, a persistent advertising identifier, an IP address (4.1), a precise location, purchase history, or which articles someone has read. A single piece of data is sometimes little on its own, but several together can form a detailed profile.
It is worth asking three questions:
If there is no clear answer to these, the user cannot make a meaningful decision. On an appointment-booking page the email address may reasonably be needed for notification; the browser's language can help in displaying the interface. Building an interest profile, however, is a different purpose: it does not follow automatically from the booking. Changing the purpose is a particularly important design moment.
flowchart LR U[User] --> S[Service] S -->|necessary data| M[Operation] S -->|separate purpose and decision| A[Analytics or tracking] A --> T[Retention and deletion]Cookies and other ways of tracking
We discussed how a cookie works in lesson 7.2: the server sends a name–value pair, and the browser sends it back with the appropriate later requests. According to MDN, cookies serve three main purposes: session management, personalization, and tracking (recording and analyzing user behavior, often across websites). The attributes of a cookie (
Secure,HttpOnly,SameSite) are security and operational properties, not automatic exemptions for privacy.Not every cookie is tracking, and not every tracking is a cookie. A first-party login cookie is often needed for a function the user asked for. Identification can, however, also happen with a value stored in
localStorage(7.3), a URL parameter, a login, server-side logs, or by linking several browser characteristics. The latter is device or browser fingerprinting: the combination of screen size, language, fonts, graphics capabilities, and other signals can make a returning device probable, and it is often less visible than a cookie.First and third party; measurement and profiling
The first party is the website the user visited. A third party can be an analytics script, an advertising network, a map, a font, a chat module, or a social embed loaded into the page. According to MDN a third-party cookie belongs to embedded content arriving from another site, and also allows cross-site tracking; browsers increasingly block these by default. In the browser's network view (2.5) third-party content appears as a separate request. A convenient embed is thus also a data-flow decision.
There is a big difference between aggregated, briefly retained visit statistics and a behavioral profile built over a long time between individuals. For product development it is useful to learn at which step of a form many people get stuck; for this it is not necessarily needed to tie every click to a name, or to recognize the same person on other websites. A measurement that fits the purpose is often possible with less data.
Consent: real choice, not decoration
A cookie bar appears on many pages. In the good case it is a short and understandable decision point: what is necessary for operation, what is optional, for what purposes data would go, and how the choice can be changed later. Rejection must not be unjustifiably hidden or made harder either. Next to the big, colorful "accept all" button, a tiny, multi-step rejection is a bad user experience and also an ethically problematic design pattern.
Consent is worth splitting by purposes (necessary, preferences, measurement, personalized advertising). The "necessary" category is not a magic word: only the technology without which the expressly requested service cannot reasonably work may belong here. The choice must later be made as available as the acceptance. An understandable privacy notice is not instead of the banner, but its detailed background. The consent interface should be operable with the keyboard too (9.2).
The GDPR as a framework of thought
European data protection regulation, the GDPR (General Data Protection Regulation, Regulation (EU) 2016/679), emphasizes the rights of data subjects and the responsibilities of controllers. Article 5 of the regulation lists seven principles of the processing of personal data:
According to Chapter III, the data subject has rights, among others of access, rectification, erasure, restriction, portability, and objection. The principles above are named by the text of the regulation; their application in a concrete case depends on the purpose and circumstances of the processing. That is why it is not right to pronounce a ready legal verdict within a course on whether a real page is "GDPR-compliant". The developer's responsibility is rather to recognize the data flow in time, to ask questions, and not to treat protection as a late afterthought: is the phone number really needed? Why do we keep the event log? Who has access? How do we inform the person?
Digital ethics: what the rules do not yet settle
Something can be thought technically permitted, yet be unfair. Deceptive design patterns (formerly known as "dark patterns") are good examples of this: pre-ticked options, misleading wording, a shaming rejection button, or a flow that talks the user into handing over more data. The European Data Protection Board (EDPB) has issued a separate guideline on the topic (Guidelines 03/2022, addressed to social media interfaces), which helps in recognizing and avoiding them. A similar question is algorithmic personalization: if a system knows the vulnerable moments and tries to extract more time or money by exploiting them, "it increases conversion" is not a sufficient reason.
The designer of an ethical system asks not only whether we can obtain the data. Also whether the user understands the consequence, whether the benefit is proportionate to the intervention, and who bears the risk in case of error or abuse. Data minimization is often also a security advantage.
Worked example: newsletter and visit measurement in Kurzuspont
An event page asks for an email address for a newsletter, measures visits on the event page, and displays an embedded video. The first step is to map the data flow: the email goes to the subscription handler; the measuring code sends events; loading the video may connect to an external provider. The second step is separating the purposes: managing the newsletter, running the service, and the optional analytics are not the same.
The result is not "zero data", but considered data handling.
Common misconceptions
In brief
Review questions
Learning resources