[laszlokorte]

It seems all those css tracking tricks (a:visted, [value=...], now :hover) depend on external resouces (background-images) being loaded lazily only once the selector is matched. Wouldn't a easy solution be for browsers to always download all url('...') references found the the stylesheets even if the selector is never matched?

[calcifer]

That could potentially be bandwith heavy, but even then it's not a solution since you could just add more CSS at runtime as the Github repo shows.

[mcv]

It would only be bandwidth heavy for sites that abuse this feature, so that's actually fine by me. And when CSS gets added at runtime, you can prefetch that too.

[altfredd]

You seem to be confused about meaning of "CSS tracking". Detecting that user clicks on the link, that you have shown him, is harmless — as demonstrated by Google, a website can always track it's own outgoing requests by replacing all it's outgoing links with redirects. This is inherent part of hypertext.

The infamous "a:visited" tracking didn't simply track your visits from Google — it tracked all your visits across entire Internet. Browser vendors are bunch of lazy hacks, who can't even implement per-site link history (just like they failed to implement per-site cookies). All "a:visited" states are source from single SQLite database, that stores your full web history. THAT is the "CSS Tracking", because it can tell a page about visits from completely different domains. Instead of separating your web history per-domain those <censored> have crippled :visited selector in several undocumented ways.

[icebraining]

> Browser vendors are bunch of lazy hacks, who can't even implement per-site link history

But who asked them to? As far as I know, the spec says nothing about per-site histories, and I find it much more useful to know if I already visited a site, regardless of the origin - for example, if I'm researching a topic, two or more sites might link to the same place, and I don't want to open it multiple times.

Plus, the idea that one can look at a modern browser, which are some of the most complex software packages being developed, and think "clearly these people don't know how to add an 'origin' column to a SQLite database", well, it boggles the mind.

[altfredd]

> the idea that one can look at a modern browser, which are some of the most complex software packages being developed, and think "clearly these people don't know how to add an 'origin' column to a SQLite database", well, it boggles the mind

It boggles my mind too. Imagine, what would have happened, if those small Javascript snippets, used mainly to add cute visual effects to pages, could check if some image from different site is already in browser cache by performing cross-site HTTP requests... That would allow completely new dimension of spying on web users!

Fortunately, browser developers are some of the most competent people in the word. They would never give web pages too much power by letting them start CPU threads, use OpenGL, allocate arbitrary amount of memory or read your battery level to set exorbitant taxi tariffs for people in a pinch. Browsers are well-designed and highly secure, because they are being updated with security fixes every day, sometimes even multiple times a day.

[icebraining]

I think you're confusing having different goals from yours with incompetency.

[altfredd]

I don't care about goals (or competency level) of browser makers. But it is hard to deny, that they are repeating the same mistakes Sun committed in late 90's with browser applets. They don't learn.

[robocat]

> just like they failed to implement per-site cookies

To be fair there has been an ugly solution to this recently, the `__Host-` cookie prefix:

https://www.sjoerdlangkemper.nl/2017/02/09/cookie-prefixes/

[fwip]

This reply doesn't address the question above it. Perhaps you replied to the wrong post?

[zbentley]

This would cause serious negative consequences for users (in rather a lot of the world) on slow or bandwidth-limited internet connections.

[mcv]

If your connection is so slow that background images are a problem, then don't load background images at all. That also fixes the problem.

If you want to prevent this kind of spying, the solution is to load these kind of interactive background images either always or never, but not on the interaction they're supposed to track.

[zeroimpl]

It does seem odd that browsers don’t preload images for hover effects. I guess in practice most hover effects just use colors? Otherwise there’d be a noticeable lag the first time you hover or something.

[iMerNibor]

This is actually an issue, to work around this as a dev you would usually use sprite sheets (one single image file with multiple images in it)

[hombre_fatal]

You can front load it with an <img> tag and various other ways. Look at how arbitrary asset loaders work for browser games.