Hacker News Reader

Comment by turbinerneiter | Hacker News Reader

Maybe if everyone wasn't leaking my entire lifes history to 58 different adtech shitcompanies the EU wouldn't have needed to step in.

Now people say "oh but if every website hosts their own fonts the browser can't cache them" while sending me 35 megs of shitty tracking Javascript code.

There is a very clear aggressor here and it's not the EU or the regulators.

View on HN

Each origin has its own cache, so it doesn't matter if you load your fonts from the same place as some other site -- they won't be shared.

https://andydavies.me/blog/2018/09/06/safari-caching-and-3rd...

https://www.zdnet.com/article/chromes-new-cache-partitioning...

https://arstechnica.com/gadgets/2020/12/firefox-v85-will-imp...

Yes but that added inefficiency is also a result of adtech abusing the font cache for tracking. Which led to the need to isolate sites.

Additionally - when everything is served from the same server - existing connections can be re-used, resulting in a latency advantage.

What about a HTML tag that includes a hash sum? Only request the resource if not already present. That could enable cross-website resource caching without leaking information. (IF the resource the site sends if necessary matches the resource of the tag, otherwise the hash sum would tell the server whether the user visited some other site.) Hashing content makes more sense than relying on the URL staying the same IMHO.

Including the hash is exactly what subresource integrity[1] does (it was even designed for a CDN context originally), but so far people haven’t figured out a sufficiently non-leaky design to use it for caching[2,3].

[1] https://developer.mozilla.org/en-US/docs/Web/Security/Subres...

[2] https://github.com/w3c/webappsec-subresource-integrity/issue...

[3] https://hillbrad.github.io/sri-addressable-caching/sri-addre...

I think the reason this is not done is it would leak to the website if the user had previously downloaded the same file from a different website.

Sure. And you can do the same thing with a CDN file by timing how long it takes to load. Sub millisecond means cache.

It's why newer versions of Firefox and Safari use segmented caches. Which, of course, means that loading fonts from a CDN no longer buys you anything at all.

Chrome as well. (The zdnet article above is about Chrome, which shipped this last year.)

The Decentraleyes extension does this.

Unless the situation has changed the LocalCDN extension is a bit more active and contains more (recent) resources.

>Maybe if everyone wasn't leaking my entire lifes history to 58 different adtech shitcompanies the EU wouldn't have needed to step in.

But it's not "everyone" - it's you. Your computer sends out all the information that is requested from it. That's how the internet is built. Even when a website tries to use an external font it is still your browser that asks the font host for the font.

A little too much blaming the victim vibe from this. "It's not the rapists who let you get raped! You let yourself get raped! Why didn't you have more personal security?"

It seems you either missed the point of what the post was getting at, or you are being purposefully obtuse about it.

Victim blaming? What's the point of your system being open and you are in control if you don't use that control to stop voluntarily sending data to websites you don't want.

I agree that it would be nicer if websites slurped up less data. But to portray a lot of this stuff as the user being the victim is ridiculous. The users are the ones that voluntarily started using browsers made by an adtech companies. There are alternatives but they don't use them! And yet they complain that their data then ends up with the adtech company because their browser, that is under their control, sends it to the company.

In case you didn't realise it's Google who controls the browser not the user.

This design is largely perpetrated by the adtech companies in question. Your reference to an external font is, of course, largely referring to Google Fonts. Nobody embedded externally-hosted fonts until adtech companies started pushing you to just add their convenient code that grabs the fonts from their servers direct, but it's insane we allow this.

Of course, the web browser should do something about it... but the adtech company built that too. "That's how the internet is built" is an aggressively dismissive attitude, because there are specific companies building the Internet. Note that every new trash web standard is written by... oh, yeah, Google too.

Sidebar: I block Google Fonts. You should too.

Yes, but the ones at fault there are us. We choose to use the browser made by them.

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.

Reply on news.ycombinator.com