Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

yes. That's a fact. A 3rd party is a 3rd party and a website leaks it's visitors to it.

Just don't do it but serve your stuff from your domain.



Doesn't this attitude overlook the "agency" of the "User-Agent"?


Note the text:

> 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


Yeah, the plaintiff's browser made the request after all, no?


The plaintiff's browser did what the defendant's code ordered it to do.

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.


Yeah, that's exactly the agency argument. It's not as if the plaintiff's browser is actually under control of the defendant, a user agent is not forced to follow the instructions that are contained in a website it requested on behalf of its user.


> not forced to follow the instructions

Again, you're talking about an opt-out. GPDR (the law) requires an opt-in.


I don't think forcing each and every single website provider to implement their own consent forms is the right approach to regulating this. 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). But requiring ever more complex, explicit and custom opt-in consent forms for various provider, third party and user jurisdiction combinations is just inane.


Consent forms are not required, just host the font. They are also way more expensive and complicated to implement than self-hosting fonts. Asking for consent over usage of third-party fonts borders on pettiness from the website owner.

> 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.


There are two options to do what's required by the law: either A. not sending users' personal data to third parties; or B. receive informed consent from the users before sending their personal data to third parties.

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.


This is a pretty sad state of affairs IMO. The fact is that CDNs and similar third party services play an important role. Websites wont stop us6them, it's not feasible (btw if I "host" my fonts in S3 do I have to get consent for sharing IP with Amazon? With DNS? with every router that goes through tracert?) .

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).


> The fact is that CDNs and similar third party services play an important role.

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.


There's a difference between data sent to the website provider (and through it, indirectly to third parties), and interactions between the browser and third parties. The linked ruling forces the provider to ask the user for consent for third parties (even though the provider has nothing to do with the interaction!), instead of mandating a direct opt-in interaction between the user (agent) and third parties.

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.


> even though the provider has nothing to do with the interaction

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 don't think you get the agency argument. Of course the request to the third party provider is causally related to the website sending the instructions. But while that is necessary for it to happen, it is not sufficient. The user agent's execution, on behalf of the user, makes it happen.


> I don't think you get the agency argument.

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.


I discussed that argument over here: https://news.ycombinator.com/item?id=30139489

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.


Thanks, that's very relevant and on-point (as opposed to my examples).


As pointed out in another great comment:

   > 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"


> Again, you're talking about an opt-out. GPDR (the law) requires an opt-in.

It is opt-in. You decided to use a browser that implements the full HTML spec. Just use a basic browser.


"Your honor, the victims of my ransomware attack decided to use a modern CPU to run my code. The attack would not have succeeded have the victims used Z-80, so there's no one to blame but the victims themselves."


Yeah like when you use a browser no where did you literally cause & consent to loading and running stuff.

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.


> It's not as if the plaintiff's browser is actually under control of the defendant

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.


> a user agent is not forced to follow the instructions

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.


Website have no authority over the browsers accessing them. They can't order. Just state information. "There's a font over here" not "you have to go access this font over here".

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.


Use this one weird trick to make all browser exploitation legal.


no. It didn't decide and so isn't responsible. Have you ever seen a gun in jail?


no, if external resources are pulled in prior informed consent then there is no agency. Such consent is a hard requirement.

If I visit example.com I am not to guess what 3rd parties it uses.


Isn't regulation precisely the act of acting in behalf of the citizens because they are seen as "too stupid" to know what they are doing?


or too under-powered in relation to the powerful organizations that take advantage of them, or too overworked by all the tasks and details of their lives to deal adequately with all the things it might be beneficial for them to deal with, but are not strictly necessary for getting through the day.


No. It is so that they don't have deal with developers tricks and misdirections and intentionally misleading uis and so on. It is also so that they are not required to learn tons of obscure and otherwise useless knowledge to function reasonably.

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".


When talking about UX, there's this bad habit of using people's mothers or grandmothers as examples, because they are 'too stupid' to understand the UI that was built. Aside from the obvious problems, this also implicitly removes blame from the designer/implementor of the interface.

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.


first I don't agree with coining any group as stupid per se.

Second, if they are a target group, a website has no excuse but to deal with them.


[flagged]


the car example again.

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.


Okay, and I made an argument of why I am against the law. That is all.


and: many are forced to use the www if they like it or not. E.g. for tax or to get access to public services.

So there's no excuse for hostility but it has to be legal and layperson-friendly.


So you advocate a computer licence?


no. They just can't care about everything themselves individually all the time.

So penalising unwanted behaviour isn't about stupidity at all.


What does the browser's user agent have to do with this?


The browser is the user-agent, ie. an agent acting on behalf of the user. The browser chose to fetch the font, based on the orinal response. It could be configured not to.


> It could be configured not to

That's an opt-out and GPDR requires an opt-in.


You could also say that the user is opting in to loading a font from google when he actively sends the request to google. You could also say the user is opting in to storing cookies by accepting the file and writing it to his own disk, and sending the file back when the site asks for it. I think it is too late for these kinds of arguments in the EU though, and maybe with good reason, if it turns out the average citizen is not actually able to configure these kinds of decisions.


> You could also say that the user is opting in to loading a font from google when he actively sends the request to google.

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.


So it is the responsibility of the website owner, to make sure that the user is informed about how his own browser works. Couldn't you make a case for shifting this responsibility to e.g. the browser vendor or the regulating bodies who decide on web standards?


No.

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>`.


>not to send users' personal data to third parties

>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.


IANAL but

   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]. 
Whereas I would point out the directly or indirectly part, the latter of which happened here.

[0] https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CEL...


It hardly matters in the court of law what you "could also say".

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.


But technically, the user itself is sending his own data to the third party, and the original website is merely requesting the user to do so. You could interpret it like this: "To use this website, it's best if you have this font. You can get it from here: https://google.com/fonts/blah". It's not exactly the same case as a more obvious GDPR violation, where the website would collect information from the user, and then send it to a third party (e.g. selling user data to a data broker).

>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.


> the original website is merely requesting the user to do so

... 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.


At the end of the day, nothing matters, so why discuss anything at all?


Technicalities don't matter. The user never consented to this data being shared with third parties, and there is no simple mechanism for the user to block them that is available to all website users. As other mentioned, GDPR also requires opt-in.

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.


> passing the burden of filtering those requests to the customer doesn't really scale

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 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.


How many of these billions want or are even capable of understanding what they do when they click the "i accept" button? Legal complexities seem even further removed from public understanding than technical ones. 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. But I'm not sure whether that will ever be possible.

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.


> How many of these billions want or are even capable of understanding what they do when they click the "i accept" button?

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.


GDPR requires informed consent.


I know, which is why I said: "and maybe with good reason, if it turns out the average citizen is not actually able to configure these kinds of decisions."


> It could be configured not to.

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?).


Ublock Origin in advanced mode can be set to block all third-party requests by default. I browse the internet that way, but it's definitely not for everyone.


I also browse the internet this way, but yeah. This solution is not available to people not using their own computers, people using certain browsers that don't have it, or just people that haven't heard of it.


Also Google can definitely make use of That information because they know so much about the user that a single IP connect is enough to establish that a specific user visited that website.


> from your domain

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?


Note that if you are an American, this still isn't a solution. This ruling prohibits any US citizen having EU IP addresses. So if you as an American host your own servers, you either have to remove all connection logging or ban all Germans.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: