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

So... the problem with that argument is that users do not choose whether or not to have fonts on their webpages. The web developer does that. No browser will, out-of-the-box, ask you "Hey, do you want to send your IP address and Referer to Google in order to see this website with the correct font?" or "Hey, do you want to run this untrustworthy, obfuscated, proprietary blob of Somebody Else's Code in a sandbox?". You just tell the browser "go to this website", and it dutifully does whatever the website says within the web sandbox.

If this was a clickable link to Google, and the EU was saying that telling people to go to Google makes you a GDPR data exporter, then I'd be up in arms about this.

But it's not.

What we're talking about are subresource references, not anchor links. Those get loaded automatically without user control, and users do not get the ability to audit them by default. So it's reasonable to argue that subresource requests are "caused" by the developer of the website, not the user.

Furthermore, this is how actual ad trackers work. It's very common for ad trackers to include a reference to either a script file or a 1x1 pixel GIF (the latter called a "tracking pixel"). This isn't a misinterpretation of GDPR, it's the heart of the issue. If we treat subresources the same as clicking a link, then GDPR is a hollow, toothless meme of a law.



>No browser will, out-of-the-box, ask you "Hey, do you want to send your IP address and Referer to Google in order to see this website with the correct font?"

Then make one that does. Or demand for one. But everybody wants to use Chrome and then they're surprised that their browser doesn't give them the control they want.

The whole point is that Google gets your data because you send it to them. Your browser and computer are under your control.

It's no wonder Apple thrives while taking away control from the user. Because when we do have control we just don't use it.

>Those get loaded automatically without user control, and users do not get the ability to audit them by default. So it's reasonable to argue that subresource requests are "caused" by the developer of the website, not the user.

It would only be reasonable to argue this if you think your computer/browser/os is not under your control. NoScript has been a thing for a long time. How many people actually use it?


On your average modern website (or, really, any website), such a design would result in pop-up fatigue very quickly. This is when you pelt the user with so many permission dialogs and "Are you sure?" prompts that they just learn to click "Yes" to get to the thing they actually want to do. Furthermore, I'm not entirely sure what "No" should even do in this context. Most subresources are non-negotiable - if you do not load them you do not get a working website. So even a slightly-savvy user will try denying things, realize that it breaks websites, and learn that they just have to either click "Yes" or close the tab out and not use that website.

The same concerns apply to NoScript and that browser extension the FSF has that bans non-Free JavaScript. If you point them at GDocs, you don't magically get a tracker-free, Free Software word processor. You just get a broken web page. The reason why users don't exercise this control is because they don't have it to begin with. It's not their webpage to modify.

On a more meta-level, you're arguing for technical controls & DRM where legal ones are needed. We don't want browsers where users can pick and choose where their data goes, but if they choose wrong and don't enable enough trackers they don't get the website they wanted. We want websites that don't have trackers on them to begin with.


This is why Do Not Track was a great idea. No popups because the browser indicates your choice proactively.

The problem was the legal framework to enforce it didn't exist so the industry was just using it as a suggestion. The EFF's voluntary declaration didn't help either.

I think if it had been enforced in the style of GDPR it would have been a great thing to have.




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

Search: