Note how the decision contains the question of whether leaking the IP was necessary. They noted it is not necessary to serve the fonts via Google, it can happen without leaking the IP (I assume they mean self-hosting):
> Google Fonts kann durch die Beklagte auch genutzt werden, ohne dass beim Aufruf der Webseite eine Verbindung zu einem Google-Server hergestellt wird und eine Übertragung der IP-Adresse der Webseitennutzer an Google stattfindet.
translated:
> Google fonts can be used by the defendant in a different way, so that a connection to the website does not make a connection to the Google server, thus without transmitting the IP address of the website visitor to Google.
Which is good news! It is a totally consistent decision with the current privacy rules and best practices: Do not save or leak private data if not necessary, always minimize data exposure as much as possible. The as much as possible part is very important - if there is no way to embed Youtube videos without leaking the address, then that's still possible to do. Sounds fair to me.
> this could probably be avoided by extending the sites terms.
Reading the judgement, I don’t think so. Consent is required before exposing the IP address and is must be explicitly given. Terms can help in cases where there is a technical requirement, for example “if you want to watch this embedded video, you must consent to this”, but they won’t save you when you just embed.
For the average user, it's yet another thing to click without thinking, just to be able to visit a page.
> Consent is required before exposing the IP address and is must be explicitly given
There's the crux of the problem, it's difficult to know what to consent for without first displaying the website, so you implicitly give consent for "just the bare minimum", until you accept the rest. This sounds great, but is both an absolute nightmare for website developers (it's not very easy to do, with how the internet was designed, inline scripts, fonts, CDN stylesheets) and for "most" end-users who just expect good defaults and don't want to sign a consent form every time they visit a website.
> For the average user, it's yet another thing to click without thinking, just to be able to visit a page.
And yet, they’re still protected: They’ll click on the video when they want to watch the video, load the like button when they want to like, the tweet button when they want to tweet. And all the other times when they visit a website that offers any of this functionality, no data is transmitted to YouTube, Facebook, Twitter.
> This sounds great, but is both an absolute nightmare for website developers (it's not very easy to do, with how the internet was designed, inline scripts, fonts, CDN stylesheets
There is no need to ask for consent for every Stylesheet you load from a CDN. You’re allowed to use cloudflare, cloudfront, fastly,… - they’ll all provide the required DPA that allows you to use them without consent. You need to be careful when it comes to things like like-buttons etc. that get loaded from places that use them to create user profiles for non-consenting users. Yes, that’s hard. But the culprits are the entities that siphon up every bit of data. Direct your ire there.
And Google doesn't? (Honest questions)
On first look serving a font from Google and a stylesheet from Cloudflare seem very, very similar things.
AFAIK google fonts does not require any contract. Google could certainly offer a contract, a DPA, etc., assert that they are subject to the GDPR and waive processing of the data they gather from operating google fonts as a service.
Also the late web was designed by guess who: Yes, the ad-spyware companies…
What the EU actually wants to accomplish is to set a standard where people do business in a different (safer/higher quality/more ethical) way[1]; which many believe is both better for consumers and for business.
I wouldn't be surprised if a next round of regulations were to explicitly target (actual or perceived) malicious compliance.
My recommendation would be to find other ways of achieving your technical/advertising objectives that minimize the touching of peoples PII.
[1] This is not unusual, the EU originated as the European Economic [Community/Union], and the regulating of safety, quality and ethics standards between businesses and trading countries has been in their bailiwick for a long time (as behooves a trade treaty organization). Not all kinds of regulation are bad for commerce. This kind promotes fair competition and interoperability, while preventing races to the bottom and tragedies of the commons.
Why single out Germany? Do you have experience doing business there?
When everybody would use it, and ISPs would sell access, that could help the users to regain control over their data, and make privacy on the internet finally first class.
I welcome this idea.
Yes, and that's a good thing! A web page should only communicate with the server i've reached, there should be zero third-party involved unless i explicitly consent.
That for example <img> tag can use an arbitrary URL is explained by the fact that back in the day storage/bandwidth was expensive. The same is true for video to this day, but i guess it's good that heavy-to-load content is click-to-play.
> there should be zero third-party involved unless i explicitly consent.
Hyperlinks are the foundation of the web. However, when we started loading resources (eg. images) from third parties due to high bandwidth/disk cost, we opened a Pandora's box which i believe does more harm than good.
Easiest way to deal with this is to self-host the videos. Most people over-estimate how popular their websites are, and for the ones who don't, getting a dedicated instance with unmetered bandwidth is trivial to get and setup for video-hosting.
In the past when video was a novelty and no one had any real expectation of performance or quality, it didn’t matter much because expectations were low.
But so much work has been done since on reliability/performance/network efficiency and very few products can provide that. Without that work, people will think your player is broken, you will waste mobile traffic, etc. Even Reddit can’t get it right and they are a top 10 website.
Plus YouTube handles all re-encoding and adjust the quality based on the speed and device.
It is possible to do it with open-source components, but it requires a server farm and just not feasible using single cheap private server or VPS.
Now if only browsers would implement native HLS and/or DASH support then every site could have this without having to package a bunch of JS with different quirks of reach site.
Of course, it is not really in Google's interest to help YouTube competitors so this is unlikely to happen for Chrome.
For most videos, this would be a copyright violation. i.e. there are now two laws which prevent reasonable technological solutions, making it harder for most people to host and produce content - favoring the already heavily advantaged big companies.
The solution to bad law is not to ignore it, it's to follow it to the letter, every time. Only then will people sit up take notice, and weigh the tradeoffs. In particular, we've let industry run away with far too much of the public's right to do things.
For example, say I want to embed an instagram post on my website. You could argue that I should talk to the person who took the picture and get a license for the image so that I can host i on my own domain rather than loading the content for instagram. In practice this is obviously much, much more cumbersome than embedding the IG post and so would result in huge changes how websites work (by vastly reducing any externally loaded content).
In a similar vein, you could argue that serving cached content from another host is not strictly necessary. Why not just run your own caching servers? It's probably worse in most ways (my cache server << cloudflare's cache server), but if minimising the amount of content loaded from external hosts is your aim then it is feasible.
In that case, you could:
a) get a license (your suggestion),
b) link but not embed Instagram pages, or
c) embed in such a way that it shows a user-controlled notification that opening the embed will connect to Instagram and as a consequence sends data to Meta.
And indeed, some websites use c) without any problem, they even integrate it into the cookie popup. BBC even steps it up: all of their Twitter citations are screencapped and linked instead of other websites just embedding Twitter (in their defense, they can say that this is to preserve the context in case that the user subsequently deleted the post).
This is how we arrive at cookie popups and annoying "you're leaving our website" notifications. I posit that perhaps both of these could be a feature of HTTP protocol and the browsers - i.e. a browser could just display a small standard icon in its UI notifying user that he's consenting to cookies, and another one notifying him that he's being redirected outside of the domain he's in, The user could then configure the browser to auto-accept or auto-deny such attempts, review all the consents he's given earlier etc. - all in all, it would result in much better UX.
Google has probably not proposed and implemented something like this in Chrome already only because it would actually improve privacy and that's obviously not in their interest. Which proves that de facto giving up Web standards to the commercial entity was never a good idea. If the EU was better at execution, they would mandate something like this as the law, instead of the current requirements which can be met by just spamming users with popups no one reads.
So, working as intended I think.
We were better off 15 years ago
Imagine a kind of decision square. Rows are "consciously" and "unconsciously", Columns are PII collection, and privacy (no PII collection) .
This gives us a list of 4 possible scenarios (from least to most desirable). 1. unconscious privacy, 2. unconscious PII collection , 3. conscious PII collection, 4. conscious privacy
In detail (least to most desirable situation)
Box 1: Early internet everyone had unconscious privacy. No one was collecting PII, and no one was aware of it.
Box 2: Early 21st century, people started collecting PII at an ever increasing (and frankly alarming) rate. You may have encountered tall tales where people got sent baby advertisements before they themselves even knew they were pregnant.
Box 3: The goal of the GDPR, shine a light on the situation and make everyone conscious that there is a problem; and unveil the extent.
Box 4 (future): fix the underlying problem.
GDPR already addresses box 4 a little bit. Just by shining a light on these practices, some of the slightly shady bits at the edges are already solved.
Now that the situation is visible and known, we can take further political steps at mitigation.
What's disheartening is that in physical stores, this already started happening in the '90s, mainly for analysis of loyalty programs' data.
If you need to notify the user that he is "giving consent" then there is no consent.
> and another one notifying him that he's being redirected outside of the domain he's in
There is rarely a reason to redirect to other domains. The most common case is making outbound links go through a redirect for tracking purposes - and that I won't miss.
> There is rarely a reason to redirect to other domains. The most common case is making outbound links go through a redirect for tracking purposes - and that I won't miss.
You misunderstand this part, which is forgivable if you're outside Germany. This is about the mandatory "You're leaving X, we do not have control on their data collection or endorse this site's contents. Do you want to continue?" you'll see on German-language website because a court in Hamburg says that they're implicitly liable if they didn't state that.
And this is how it should be done, otherwise you read the article a few years latter and see a strange mess with empty holes.
If you want to make sure that you're not getting the balancing test wrong, you can always go for the legal basis of last resort: consent. Just ask the user whether you can load content from Instagram and only do it if they agree. In fact, since in parallel to the question of your legal basis under GDPR, you also have to comply with the cookie provision from the e-Privacy Directive, where there is no "legitimate interest" exception to the requirement to ask for consent, you will have to ask for consent anyway (as Instagram embeds place cookies).
I don't think that's true. The cookie provision is misunderstood when you think you have to ask for consent for functional cookies. Follows from the GDPR, and there is no specific cookie law actually implemented in european countries. See also https://gdpr.eu/cookies/. Ah, but maybe I misunderstood and you are only talking about the cookie set by the embed?
These are the guidelines on consent exemption by the Article 29 Working Party (the European Data Protection Board's predecessor) that explain it: https://ec.europa.eu/justice/article-29/documentation/opinio...
However:
> This is not the case for cookies placed by Instagram embeds.
Yeah, I can see how this is complicated and how it fits the topic. It's not a third party cookie for the embed, but for the website it might be, and is it even a functional cookie? I doubt it. I'm not sure how those would be judged and what is a reasonable way to work with embeds. It's only certain that there is not a solution as easy as it was in this case, where self-hosting the fonts was possible.
Other than court judgments, the Article 29 Working Party opinion is the most authoritative opinion you will get on the interpretation of the e-Privacy Directive, which is the "real legislation" that you need to look at.
edit: Nobody claims that the e-Privacy Regulation is in effect, by the way -- of course it isn't, it hasn't even been passed. The cookie consent clause of the e-Privacy Directive is however in effect, and has been since 2009.
Edit: No, I'm not. The GDPR page I linked states the situation that follows both from the GDPR and the e-Privacy Directive. It also fits to what is written in the directive itself.
Everything sqrt2 says in the comments is entirely correct, as far as I can tell.
Ridiculous to govern non-privacy relevant tech usage like this. I still think that's illegal where I live. Regardless, let's hope the e-Privacy Regulation or future court decisions solve this.
The part that is tricky, is where we offload additional burden of knowledge and responsibility to the website providers.
When it is on the user to figure out whether they are allowed to use a product – and that means in fact any product – that one of the biggest companies in the world is allowed to offer in my country legally, we are in trouble.
Law is complex. Tech is complicated. Most people are not law or tech experts. Getting sound advice on both is expensive, and the trend to increasingly need more of both is worrisome.
This seems neither fair nor reasonable to me. Or particularly democratic.
I'm still waiting for the ability to have mail received from someone or a company without giving such parties my name and physical address. This could very easily be implemented in many ways, but somehow does not exist.
There is no reason for a mail order company to know my full name and physical address to deliver anything to do, and I feel this sis far more compromising than an i.p. address.
I find giving ulterior parties my name, and the physical location on the planet I live far more scary than being tracked by cookies without such cookies being able to be tied to such things.
Not quite? Wouldn't the users browser have sent its own IP address to Google? That's different that "forwarding" it, and it may not even be enough for Google to connect the user to that site.
Now from a practical standpoint, I'd like to see a privacy consent header which informs the web site of the privacy options the user has selected. Absence of that header or absence of specific selections will result in annoying popups like we have now.
If URL "hacking" is illegal, then we have decided as a society that persuading a piece of software to do something does not equate to informed consent on the part of the person operating it (and by extension that we're meant to make some sort of guess as to what they do intend).
Users on the other hand are just people. Being a user on a service does not grant you power over other users (not out-of-the-box anyway). Sure you can scan for vulns and/or follow a public link to a top-secret document: in my view that's nothing wrong. Now reverse the situation: why should a remote server administrator dictate the computing performed on your machine?! Is it ethical for some website operators to start scanning your local network?
A service operator knows about threats, hopefully has counter-measures in place, and can always ban you (or specific requests) if it comes to that. A user is mostly helpless, especially when it comes to computations performed by a script you unconsciously downloaded and executed from a server. How many users are aware of what RCE even means and that a web browser with JS enabled is essentially RCE-as-a-service?
A document that is expected to be executed by the receiving system. Might as well log in to your companies production server as root and send the completely meaningless string of letters "rm -rf / \n", not your fault if the receiving system actually executes it.
You’re not wrong that one could logically evolve your interpretation from circumstances, but GDPR’s authors chose not to accept your interpretation as sufficient, and went further than that.
2) this is probably more of a browser issue than a site issue.
3) the reason browsers dont complain about content coming from different domains is because the entire ad industry depends on that behavior. That may need to stop ;-)
The European Court of Justice did not buy this argument. By coding the website in a particular way, the website operator was responsible for causing the user's browser to act in a particular way, so it was the “data controller” for the collection an transmission of personal data by the Facebook Like button, though Facebook is of course jointly responsible for what their code does.
The underlying argument is that someone is a data controller and thus responsible for GDPR compliance when they determine the “purposes and means” of processing, alone or jointly with others. Embedding the code for the button was an exercise of this power to determine purposes and means. In contrast, the website operator is not a data controller for whatever Facebook does with the collected data on its servers, because it cannot control what FB does.
The given case from Munich is a very straightforward extension from the Fashion ID judgement, though the website operator didn't even claim that they weren't responsible. Instead, they argued that they had a “legitimate interest”in loading fonts from Google servers, which the court rejected. While I consider it probable that Google does not use data from Fonts servers for tracking, the judgement correctly points out that Google is well-known for tracking – but this doesn't matter anyway, since already the disclosure of personal data without a legal basis is a problem.
I can go "bash < somefile" and I can go "csh < somefile" and I can go "cat < somefile". It's my choice to use bash, csh, or cat. somefile will have data in it, that data will be interpreted by MY choice of program to read the data. If I don't want the contents of somefile interpreted as commands I shouldn't be passing it to something that runs commands based on its content. replace somefile with `curl someURL` and nothing changes. If I don't want my computer to connecte to other computers based on what content comes back from `curl someURL` that's my responsibility.
Maybe a better example. It type `npm -i somepackage`. npm then looks in somepackage and sees dependencies and downloads them. By the same logic as the judgement npm or `somepackage` is responsible for leaking PPI based on the dependencies listed. Not the user for running npm in the first place.
The same with `apt update` and `apt upgrade` etc...
The ruling would apply in tons of places that seem like they'd make it hard for things to keep working.
If you don't have a contract stating that the other part will honor GDPR then we will assume that the other part will misuse all data sent to them, so you aren't allowed to send any data at all.
Or proxying. Or proxying with caching, which is kind of part way between self-hosting and proxying. :)
Why do you think that? I would never agree that a link should carry any responsibility to the site owner, even if it linked to porn, warez or really illegal stuff.
But there is. Where does it stop being reasonable? When you have to host your own video delivery infrastructure?
Do you still think it’s reasonable that it should be a legal requirement that to embed a video on your web page you must develop your own video delivery infrastructure?
I think the important part is that this is an issue, only because companies like have had a surprising hard time not misusing every single bit of information sent their way. The result is that companies have forced governments to step in and now they are overregulating.
If you do not request preload behavior, then you’re just linking another site on the web, and users are considered to understand that links go to other sites, and that’s acceptable. A theoretical GDPR complaint would find that the user agent was responsible for the behavior, not you as site operator.
(I am not your lawyer, this is not legal advice.)
I already agreed in a comment above that these questions wrongly answered by a pure privacy maximizing position carry a huge danger for the german web.
maybe just use software to fix the problem instead of spreading FUD. HuGe DaNgEr
https://allaboutberlin.com/guides/abmahnung-creative-commons
That copyright example by the way, that applies everywhere.
> The browsers don't share third-party caches across domains, because it made it easier to leak information about which sites the user has visited.
> September 21: After months of silence, we have received another letter from Kanzlei Schröder. This time, they threaten to take us to court unless we pay 400€ by October 1. We decided to pay. That was our last interaction with Kanzlei Schröder.
The government has the absolute authority to regulate you into a corner, if need be, to protect its people from predation by powerful interests. That's what governments are for.
https://doctorow.medium.com/a-bug-in-early-creative-commons-...
(action still required: authors need to update to CC 4.0 or later)
It has a very chilling effect on innovation no doubt.
The worst you could do to a lawyer is that maybe you could embarrass them about their lack of network engineering knowledge, but they in turn can extract real money from you through various means.
Also defending oneself results in involving a different lawyer enriching lawyers as a whole anyways.
I’m fairly certain it’s possible to do much worse to a laywer, especially a technically clueless one.
Defending oneself from a frivolous lawsuit (e.g. judge has already said ‘you can’t do that’) in a sensible country like Germany might not cost you anything.
Much, much more likely however, is that they wouldn’t go to court at all (because, you know, they would lose, and even if both sides pay their own cost they’d lose more money than they could potentially make).
Just don't do it but serve your stuff from your domain.
> It is undisputed that the plaintiff's IP address was forwarded to Google when the plaintiff visited the defendant's website.
In this context, "It is undisputed" does not mean "It is a truth universally acknowledged by everyone", but rather "there is no dispute between the defendant and the plaintiff that this happened; in the light of that non-disagreement, the court is not required to decide whether that happened or not, and will accept that as a fact".
So in this case, the defendant (as well as the plaintiff, of course) agreed that "the plaintiff's IP address was forwarded to Google when the plaintiff visited the defendant's website". If there was a place to bring forward this "agency argument", this was the place; however the defendant seems to have chosen not to bring it forward.
It may be because the defendant's lawyers are unprofessional and forgot; it may also be because they are professional and so they knew this argument would not hold.
P.S. see also https://news.ycombinator.com/item?id=30139489
If the defendant's code violated GPDR (which seems to be the court's conclusion) by sending the plaintiff's browser somewhere, it's a defendant's problem, not plaintiff's.
Again, you're talking about an opt-out. GPDR (the law) requires an opt-in.
> User agents should have the ability to convey and enforce privacy preferences on behalf of the user, and website providers should be legally required to comply with these if possible (or refuse service if not).
The burden of respecting privacy choices in every single other case (data in the backend, data shared with partner, paper data) is already with the website. Every non-privacy-respecting implementation in the frontend is made by website owners.
Keep in mind that sometimes websites don't work with blocking other stuff, or are more difficult to use when blocking fonts (Google Material). So this is not even a practical suggestion.
If the option B seems unwanted for some reason (any reason), there is still option A. Implementing a different solution (that breaks the law) has consequences.
In reality, websites will add more crap "opt in" CYA forms at first loading, making the interaction fugly and unusable. We can discuss here in HN how that is unnecessary and whatnot, but that's what's going to happen...
I just wish that websites wouldn't force us outside of the EU to the asinine UX required by the EU (I hate having to press ACCEPT ALL on each page I visit.... whatever I dont want is already blocked by an extension anyways).
They no longer do, since browsers implemented cache isolation.
> if I "host" my fonts in S3 do I have to get consent for sharing IP with Amazon?
No, you're supposed to contractually bind your vendors/service providers as data processors with a contract (“data processing agreement”) per Art 28 GDPR. There's some debate around whether US-based companies are legally able of entering into such an agreement (say hello to the Cloud Act from me), but the general consensus still is that non-US cloud regions might be OK, and that CDNs that let you sign a DPA (like Akamai, Cloudflare, Fastly, …) are also OK. In contrast, Google Fonts does not seem to be covered by the Google Cloud DPA.
> with every router that goes through tracert?
No, such mere transmission doesn't count as processing, and/or the intermediaries are responsible for their own compliance. In any case the connection should be protected by TLS so that only the client IP address + your domain name is visible to intermediate routers.
> websites will add more crap "opt in" CYA forms
Unfortunately, I agree, though the point of this judgement is that self-hosting some assets is a perfectly cromulent alternative. I think relying on “consent” would be difficult in a case like this, since it is not generally possible to make access to a service conditional on consent to unnecessary processing activities. Using a CDN for assets like files is unnecessary.
> I just wish that websites wouldn't force us outside of the EU to the asinine UX required by the EU
For EU-based websites there is no choice, as the law doesn't care about where the users are.
There's also a bit of irony in here that there has been a lot of work in replacing the cursed cookie consent requirements that gave us most of these annoying consent banners – but the past few months revealed that the US tech giants have been successfully lobbying against the proposed ePrivacy Regulation. So please redirect your ire against Google. Without them this might have been fixed in 2018.
Imagine embedding many social media sites. Instead of forcing the social media sites or browser vendors to create embeddings that ask for consent themselves, the website provider has to ask for consent on behalf of all external sites before loading any content. As a web developer, this is a nightmare.
I beg your pardon, but in this case "the provider" (website) has directly sent the user's browser to a third party (google fonts) by including an instruction in the code (HTML) that the provider has sent to the user's browser. The browser did not decide to contact google fonts all by itself; it was directed to do so by the provider. Arguing the provider "has nothing to do with the interaction" looks a bit disingenuous to me.
I do get that argument; I just don't think it holds any water.
If one hires a hitman to kill someone, that one may still be held accountable to manslaughter, even if that specific person didn't kill anyone themselves. It may also not matter how many degrees of separation are there between that person and the hitman: as much as putting a (Bitcoin) bounty on someone's head (with a "smart contract" or whatever) may be considered manslaughter, even if nobody knows who the actual hitman is.
"Agency" is not a magic get-out-of-jail card.
Also, one may try convincing a judge "Your honor, it's true that I wrote the code that encrypted the plaintiff's network and wrecked a havoc, but I did NOT execute it; the plaintiff could have instructed his CPUs to not execute my code"; I don't know if this argument would hold.
Finally, there might be a "reasonable burden" argument in this case. It's reasonable to expect that website builders would know how browsers/internet work. It's not reasonable to expect that website visitors (general populace) would know that. Hence, the burden of GPDR compliance is better put on the builders' shoulders, which is exactly what happened in this particular case.
Summary: A company did try the “it was the browser, not us” argument in the “Fashion ID” case. The court did not fall for it. Data controller and thus responsible for compliance is whoever determines the purposes and means of processing. Being able to control what the website does seems to be good evidence for being a data controller.
In this Google Fonts case, the website operator didn't even try this discredited argument.
> Sure your honor, the victim died by carbon monoxide asphyxiation, but it was his choice to inhale the gas, even though it smells the same as normal air"It is opt-in. You decided to use a browser that implements the full HTML spec. Just use a basic browser.
False analogy.
Ironic that people use this line of reasoning to defend ad blockers (I'm responsible for whatever software I run) but then use the opposite argument when they don't like what the software does.
In theory and in practice it is, though. The browser viewport, by executing remote code, is in fact under control of the defendant's website.
Most websites are closed-source. The "instructions" are not available to the customer.
Luckily! A large german media corporation called "Springer" has for years, and is still, unsuccessfully trying to get the courts and politicians to rule that users can not manipulate web content and must run it as intended, as changing it would violate copyright and is a sabotage of their program. And i bet they aren't the only ones globally. Also: how many devices are locked down and can only run code as it is provided by trusted third parties? Try installing an ad-blocker on a smart-tv or a playstation.
That browsers by default tend to follow links to resources automatically doesn't change that. It's still the agent the user has chosen to represent them when talking to the website making the decision not the website.
If a legal body want to make the call that users shouldn't be responsible for choosing what their browsers automatically do or don't do on their behalf that's fine. But it's absurd to do it by making it the website creators problem. It's the browser that's choosing to do things without asking the person it represents for explicit permission. It's the browser sending the information to the third party. Put it on the browsers!
We've got a handful of choices for browsers. They all gratuitously send every bit of information they can get their hands on to every website they can. Just straight up informational security Judas'. And GDPR blames websites? It's crazy to me.
If I visit example.com I am not to guess what 3rd parties it uses.
None of that makes them stupid. Just like, when I am in grocery store I can be sure all food there is reasonably safe, even if I don't know anything about them. I am not expected to research them all personally for dangerous substances else "I am stupid for poisoning myself".
I always prefer to reframe it as someone with a very important, intelligence requiring job, say vaccine reasearcher, who doesn't have time to deal with your shitty UI when they want to print a document.
I feel the same applies here.
Second, if they are a target group, a website has no excuse but to deal with them.
There is a legal framework that has certain requirements. Enforced by a court here. These laws are from elected representatives of the people.
So they are binding. Like it or not.
So there's no excuse for hostility but it has to be legal and layperson-friendly.
So penalising unwanted behaviour isn't about stupidity at all.
That's an opt-out and GPDR requires an opt-in.
Consent is not consent unless it's informed consent. If the user was not made aware of the request in a clear way before the request happened, he did not have a choice. If the person (and by person we mean the human being, not their browser) did not make the choice, then he did not consent. There's no "technically" about it, the question is only if the person knew what was happening and was given an opportunity to opt in.
The responsibility of the website owner is not to send users' personal data to third parties, OR to receive their users' informed consent to such sending BEFORE that sending occurs.
That's the law. It's enforced by courts.
Web standards aren't law. They aren't enforced. You can't sue anyone in W3C court for using non-standard CSS or forgetting to close a `<b>` with a `</b>`.
>receive their users' informed consent to such sending BEFORE that sending occurs.
Neither of these are what's actually happening in this case. According to this court's decision, the responsibility of the website owner is not to send instructions to the user's machine that might expose their personal data to third parties after the user's machine follows these instructions, OR receive informed consent before such instructions are sent. I'm not saying the GDPR doesn't apply here, but at least it's clearly a different situation.
For the purposes of this Regulation:
(1)
‘personal data’ means any information relating to an identified or identifiable natural person (‘data subject’); an identifiable natural person is one who can be identified, directly or indirectly, in particular by reference to an identifier such as a name, an identification number, location data, an online identifier or to one or more factors specific to the physical, physiological, genetic, mental, economic, cultural or social identity of that natural person
— Clause 26 of GPDR [0].
[0] https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CEL...
The law is clear: you don't have to send your users' data to third parties, but if you decide to do it, you have to receive their informed consent first. In this case, the defendant chose to send personal data to a third party without receiving their informed consent.
The option of conforming with the law by not sending that data anywhere still stands, as does the option of receiving informed consent beforehand.
>It hardly matters in the court of law what you "could also say".
On the contrary, it's exactly what the court is there for.
... in a violation of GPDR, because user's informed consent was not received beforehand.
> it's exactly what the court is there for
I might have been more clear: it hardly matters what you or I could say — what does matter is only what the lawyers say. In this case, I assume that either A. the defendant's lawyers have brought this argument before the court, and the verdict still was what it was; or B. the defendant's lawyers have failed to bring this argument before the court.
The courts are not there to discuss arguments made in HN comments.
There is a case for third-party requests, and considering that some websites make tens and sometimes hundreds (eg Yahoo) of third-party requests, passing the burden of filtering those requests to the customer doesn't really scale.
The burden is fully on the website operator here. They wrote the software, and it's most certainly closed-source. Just as the burden of keeping my data safe on their backend is on them, the burden of keeping my data safe on my frontend is also on them.
I think it scales better than forcing millions of website providers to engage in the legal fiction that they are an intermediary between the user and all external content providers that are embedded on their page
All the embedding is being done by the people building the websites, so yes, they do have full control and therefore full responsibility.
Just because I don't perform a crime or violation myself, it doesn't automatically absolve me when I pay or ask someone to commit it.
> forcing millions of website providers
Millions? There are billions of website visitors, and most of those don't have any control or deep knowledge over their tools. There are only 3 significant browser technology suppliers at the moment, and none of them provides the hypothetical tools to users, only third parties, and those tools often break websites.
Website builders, however are significantly more technical and able to control their tech stack. If anything just hire another company. The burden should definitely be on them.
I agree that its a big problem that the big browsers do not act in the interest of their users, and that their vendors are in fact disincentivized to do so. That would be a good reason for antitrust action and public funding, since they should be public goods.
I don't see how this is relevant, but:
Again, whether those consent forms are understandable or not depends solely on how websites implement them. The fact they are confusing is purely because website operators want them to be.
These confusing forms are not a requirement of the GDPR. How they look and feel is up to the website hosting them. They go against the spirit and some go against the letter of the law.
The goal of GDPR is letting people answer to the question such as "Can I give your data to company X?". The fact that the internet became a cesspool of privacy violations doesn't change the original intent of the law.
> This approach seems equally ineffective for achieving what this regulation is intended to achieve, to not just to have the users sign away their rights with a click, but give them an understanding of what they give away.
The law already states that rejecting should be as easy as allowing. The fact websites don't make it means they're breaking the law, and I hope they get punished by it.
> I agree that its a big problem that the big browsers do not act in the interest of their users, and that their vendors are in fact disincentivized to do so
We already have a Do-Not-Track header, but websites refused to obey it for more than 10 years, to the point they were removed from browsers.
Solutions were always there. It is websites that chose not to comply.
Not in practice. It requires configuration that is non-trivial for most users and might not be available for them in all cases (eg: using a computer in a library).
In fact, I can't think of a solution that doesn't require third-party software/hardware/product and some computer expertise (AdBlock? Pi-Hole? VPN? Little Snitch? Hosts File?).
Not only from your own domain, but from your own servers. If you still server-side send the IP to Google servers, it's still sharing of personal data with a 3rd party.
I wonder how this works when you rent servers from VPS providers. If you host data on their servers, does it mean you share it with them? What if this data is behind a root password? What if it's encrypted?
This ruling could easily get overturned.
Actually, most people don’t actually know that. And why would they? Why should they get bogged down in such technical minutiae? Why require users to play tedious uBlock whack-a-mole of enabling resources from external domains until the website starts working in order to have any semblance of privacy?
Just because something is common doesn’t make it right.
So you could conclude that my program can do whatever it wants within those constraints, and it's your problem as a user if it does something you don't like.
But I don't think it is fair to expect normal people to analyze a program for malicious behavior before running it. And I don't see how it is relevant whether that program is a compiled binary or a spaghetti blob of html, css, javascript, and web assembly. Also it is not clear that such analysis is permitted by the draconian copyright laws.
Am I? Maybe I am, because I have worked as a web developer, but most people don't really have this knowledge.
And even if they suddenly start having the knowledge, what is their choice? Stop using the web for good?
Instead of blaming the user for not having technical means and personal rules to apply privacy best practices, the site creator has to offer options to review the situation _before_ letting loose all the trackers and third party carnival.
And it makes sense to me. If tomorrow a site decide to get their favicon from microsoft‘s new marketing service, it would be unreasonable to expect the users to know to block that.
If the user visits foo.de they obviously expect that some data is transmitted to foo.de
They also might know that companies use service providers and therefore necessary data might be shared with 3rd party companies (which is fine according to the GDPR).
However the user can also expect that that a) foo.de minimizes data transmissions and b) 3rd parties conform to the GDPR rules (which Google can't).
If the user is logged in to Google (e.g. for Gmail) Google would be able to connect the user with foo.de with a high likelihood. This in turn might expose the users behaviour to automatic analysis by foreign government agencies without any legal oversight (since the user most likely isn't a US citizen)
GDPR is going to manage to make the internet unusable. Who would've thought it was going to be bureaucrats the ones to kill the web!
- With Google Fonts, to track the identity of users AND the real popularity of websites,
- With Google DNS 8.8.8.8, to track everyone’s DNS resolutions,
- With Google Analytics, to track who sees what, even if they only display masked IPs to the owner of the GA profile,
- Etc with Google Maps, emails, they don’t provide those services for free, they can track everyone’s profile, down to their obedience to Covid rules.
I wouldn’t be surprised if Germany bans more aspects of using Google’s free services.
The sharing with ruters etc. is required to operate the service (website). Using a Google CDN for fonts isn't (required for operating a website).
The ruling explicitly points that out.
Furthermore DNS is handled by the contract you signed with you ISP or you explicitly changing it. Same for some other parts.
Where is exactly is the line for needed for operating a website and being optional?
What if you create your website in wix.com, the data from your domain will be shared with them AND it is needed for this data to be shared for operating the website.
EDIT: To make it clear, I always recommend self-hosting fonts and agree that Google CDN fonts should be avoided. But even if you self-host the fonts, those are still hosted on a server that is very unlikely to be your basement.
Remember that your user agent is sent as well.
In Firefox 96 network requests to 3rd parties (in this case Google) still seem to include the 1st-party hostname as REFERER header.
But even without a referer it gives Google some information, even if its just that this user (ip, useragent, other identifying bits) is currently exists.
And for someone with masses of extra data like Google it is enough to identify who is doing the browsing, so this isn't some crazy overreach.
I mean, IP address ranges are publicly known. If I now run a `for` loop over all IPv4 addresses and write them to my HDD, am I suddenly illegally storing personal data of all the people behind those IP addresses? Obviously no. An identifier by itself is not worth anything, unless it's connected to actual personal data.
EDIT: Never mind. GP's assumption that "there’s no Referer header - which there won’t be, assuming Referer-Policy is set sanely (which by default it is in all browsers)?" does not seem to hold in my browser. So Google does not only receive the IP address but also the HTTP REFERER.
That there is correlating information like timestamps, useragent strings, or referer headers increases the likelihood of actual identification, but the mere reasonable possibility of identification is sufficient for IP addresses to be personal data.
The present court case and also the one you're referring to (Breuer v. Bundesrepublik Deutschland[0]) do not say anything to the contrary. They were concerned with situations where there is additional data that could be used e.g. to build a user profile. For instance, the Bundlesgerichtshof judgment addressed the question of "whether dynamic IP addresses of website visitors constitute personal data for website operators" [0] (which clearly know which website the visitor visited and therefore possess additional data about the visitor).
[0]: https://medium.com/golden-data/breyer-are-dynamic-ip-address...
For something to be personal data, it must be information that relates to an identifiable natural person. There are two criteria here: (1) it must relate to a natural person, and (2) that person must be identifiable.
Your “loop over IP all addresses”example does not involve personal data because the information doesn't relate to anyone – it is just a list of numbers. Even if it were to relate to individuals, no court would order an ISP to disclose information about corresponding subscribers for such generated IP addresses. Then, the identifiability argument in Breyer cannot work.
In contrast, an IP address that is part of an IP packet received by a server clearly relates to the person sending the packet, if there is such a person. And, with the help of third parties, the person on the other end of the connection is reasonably likely to be identifiable. This does not depend on the website operator having any additional information such as cookie identifiers, other than the date. To avoid confusion, let me quote the relevant part from Breyer:
> 49. Having regard to all the foregoing considerations, the answer to the first question is that [Art 4(1) of the GDPR] must be interpreted as meaning that a dynamic IP address registered […] when a person accesses a website […] constitutes personal data within the meaning of that provision, in relation to that [website] provider, where the latter has the legal means which enable it to identify the data subject with additional data which the internet service provider has about that person.
The only additional data involved here is that held by the ISP, not by the website. That the judgement scopes its conclusion to website providers must be understood not as a limiting factor (as in: IPs can be personal data only for website providers), but as a contrast to the uncontested observation that IPs clearly are personal data for ISPs.
An IP address that relates to an identifiable person is personal data by itself. Thus, its mere disclosure to a third party without a legal basis is a breach of the GDPR. The article you linked highlights the “absolute vs relative” identifiability discussion, but this reasoning holds even under the “relative” standpoint because Google too is a website operator who has the same reasonably likely means for identification as the original website operator, if not substantially better means due to its trove of other data it can correlate with the IP address.
In this LG München case, the court determined that sharing this data with Google was illegal, regardless of whether there is any additional data. It is, in a sense, a very formal argument, that doesn't consider it necessary to dive into specific fact patterns (that's the abstract vs concrete means part quoted in my previous comment). The court did consider the impact of Google's tracking abilities in calculating damages, though.
To summarize my disagreement with your comment: (1) I assert that an IP address by itself can be personal data for a website operator (such as the defendant or Google), per the Breyer argument. (2) The LG München judgement in this Google Fonts case is not concerned about additional data when considering the legality of processing. (3) Additional knowledge held by the website operator is irrelevant for both this case and the Breyer judgement. Since a negative is difficult to prove but a positive can be shown by a single example, could you please point out the paragraphs in the Google Fonts case[1] or the ECJ's Breyer judgement[2] where I'm mistaken for disagreements 2 or 3?
[1] https://rewis.io/urteile/urteil/lhm-20-01-2022-3-o-1749320/
[2] https://curia.europa.eu/juris/document/document.jsf?docid=18...
An IP + user-agent combination (both of which are sent) is enough to uniquely identify a typical home user with high certainty unless they're behind a carrier-grade NAT and use a very popular browser.
That's actually a good point. The IPv4 space is pretty limited. I guess the GDPR law makes it PII if you bundle both the IP with an action made by that IP (e.g. that IP visited that website).
Google Translate: https://rewis-io.translate.goog/urteile/urteil/lhm-20-01-202...
> The defendant is sentenced to pay the plaintiff €100.00
> The plaintiff has a claim against the defendant to refrain from passing on the plaintiff's IP addresses to Google under Section 823 (1) in conjunction with Section 1004 of the German Civil Code.
> It is undisputed that the plaintiff's IP address was forwarded to Google when the plaintiff visited the defendant's website.