CSS mix-blend-mode is bad for your browsing history | Hacker News Reader

CSS mix-blend-mode is bad for your browsing history

lcamtuf.blogspot.com

196 pointskawera40 comments

Clever!

Here's one way I can think of to fix it without just taking out the feature or trying to hide its results: redefine "visited" from being "visited ever, from anywhere" to "visited from here". For instance, if I visited a wikipedia article on my own, and it appeared on hacker news, it wouldn't appear as "visited". However, if I clicked on it from hacker news, next time I load hacker news the browser would mark it as visited. I think that would keep all the useful properties of visited, without leaking information.

I like that!

My own suggestion would be to make :visited something that renders at the browser-chrome level (like OS tooltips or IME controls), rather than the renderer level (like on-page find result highlights or selection-caret link outlines.) Don't hand the state to the renderer process in the first place; just stuff it in the renderer-inaccessible part of the DOM (like XHR response cookies) and then have the browser indicate where on the rendering surface the visited—or maybe unvisited!—links are, in some floating-control fashion (perhaps like Firefox's find-in-page scroll-bar notches.)

Where would chrome like that appear in touch UI? Typically tooltips show on hover, but touch UI has no hover effect.

Doesn't need to be a hover element. It cam be an underline or a translucent square.

>[...] redefine "visited" from being "visited ever, from anywhere" to "visited from here" [...] I think that would keep all the useful properties of visited, without leaking information.

Almost. However, sometimes websites are linked to from multiple locations. E.g., there might be links to something posted both on /r/programming, on lobste.rs and on HN. I like the fact that a page I have visited ever, from anywhere, is marked as such everywhere.

If you're following along in the code, four classes are defined, l_and, l_and:visited, l_and_not, l_and_not:visited.

l_and:visited and l_and_not are set to background color white, the others black.

512 link 'stacks' are created, each one in a td tag, each one for each possible setting of the 9 sites he checks.

Each of the classes get mix-blend-mode: multiply turned on.

He then looks for a final image with color white -- that's the bitset of your visited sites, since the multiplies will all give white as the output.

I think the best solution would be if visited only applied to the local domain.

Like all the other cross domain policy stuff.

This article would more accurately be named the CSS :visited psuedo-class is bad for your browser history, not blaming it on the mix-blend-mode property.

The same idea has been done before, except more cleverly with the color property and captchas:

https://frantzmiccoli.github.io/visited-captcha-history/

They should just kill it already if they do not want to work around this forever, since CSS will only grow.

Did you read the article? It explains how browsers mitigated the :visited pseudo-class issue, then how he bypassed that mitigation using mix-blend-mode. As presented, mix-blend-mode absolutely is to blame for being able to exploit it.

He also explains how this is different than the captcha POF that you linked because the captcha requires user interaction for each URL tested (something that wasn't necessary before the browsers mitigated against it). He explains how to reduce this to a single user interaction, by exploiting mix-blend-mode.

Yes, :visited is a key part of the exploit, but to say it's just that isn't accurate.

I think grandparent's point is that `:visited` is actually the source of the problem, and that the "fixes" that browsers applied were leaky. Surely this will continue happening with future additions to CSS.

It seems like a perfect example of leaky abstractions.

I think the title is very good because I am aware of problems and mitigations with :visited, so if the title just talked about :visited, I would have thought to myself, "yup, good thing they fixed that long ago in all browsers", whereas with the present title, I actually learned about these new discoveries.

> This problem was eventually addressed by browser vendors by simply improving the accuracy of color quantization when overlaying HTML element

What does this mean?

> What does this mean?

It means the problem was solved accidentally.

Luckily enough, all problems will be solved for good by rewriting the browser in Rust, according to my reliable 10x engineer sources.

Thanks but that doesn't answer my question at all. I want to know what "improving the accuracy of color quantization when overlaying HTML element" means exactly.

His previous hack relied on browsers rounding the result of an opacity calculation in order to force a binary outcome (i.e. one of two colours rather than multiple shades). Once they improved the accuracy of those calculations this trick was no longer applicable

I'm probably not explaining it very well, but you can read the full details of the hack here: http://lcamtuf.coredump.cx/css_calc/

Tor Browser doesn't seem to add[1] any defenses against history disclosure attacks.

1. https://www.torproject.org/projects/torbrowser/design/

Any Tor Browser user would be clearing their history constantly with the "New Identity" feature.

I think the Tor Browser doesn't mark links as visited at all.

This is very bad. If I open a website and it knows which of 100 other specifically selected sites I visited, I'd be instantly "profiled" for advertising. Is it possible to block visited link leaks? I'd be willing to give up visited highlighting altogether.

At a guess (can't test right now, on mobile) a browser plugin that manipulated CSS might be able to override *:visited, setting the colours to something that wouldn't permit detection -- "inherited" perhaps?

Has anyone tried something like this, e.g. with the userstyles plugin?

https://userstyles.org/

In about:config, set this option to false

    layout.css.visited_links_enabled

(if missing, create it as a boolean)

I disabled :visited coloring a long time ago and it hasn't caused any significant problems. It just took a few weeks to get used to the changed link colors.

You can also get browser history by misusing CSP violation reports.

It has since been fixed since Chrome 48, it seems. Not sure about other browsers. The attack is pretty interesting btw: pinning CSP to http-only, which means that the block can be timed to reveal whether the URL was in history.

the fix was just dis-allowing CSP to restrict to http.

Does this require a click from the user? Couldn't you set a background image to make a GET request to the server with the results?

It would make it anyway because it does not know that it is not shown.

What browsing history? For me, it goes when Firefox closes :)

You are a strange man. You don't want browsing history and more important: You close your browser.

Not only that, I use Linux with LUKS, and shutdown whenever I'm not using the box :)

This is why I don't run JavaScript unless I absolutely must. Unfortunately, a lot of sites leave no option; I find myself choosing to miss out on the content rather than risk the exposure and bad usability.

Side note: Michał is truly prolific, I get the feeling that his dream is to have a full system secure against common attackers, which consumers might actually want to use. He seems to attack every piece of system software in every way from design flaws to implementation bugs.

This attack purely relies on CSS. There's no JS involved. (Okay, there is in the PoC, but only to provide the alert listing what sites you've visited; the data leakage can be exploited with no JS involved.)

How could you take advantage of the leak without JavaScript?

The `href` attribute of the visible mole could pass the data back to the server.

Oooh, that's clever. So the mole I clicked on in the author's POC was in a position that was unique to my combination of visited and non-visited sites. The evil attacker has no way of knowing that though, until I play the "game", click on the mole, and trigger a GET request with the info. Do I have that right?

Even with JS the the attacker has no way of knowing it until a user-initatied event, such as a click. But yes, in the non-JS case it must cause a full page reload, but as pointed out in a sibling thread, that could just be on a legitimate link (like, say, a link to elsewhere on the site, just passing the data in the query string).

If you turn JS off, you'll still see a mole in the position which signifies your visited subset of tested-for addresses. If you inspect the code, each position has multiple anchor elements, the last of which has an onclick right now. All you'd have to do is add a href to it.

How do you send this information back to the browser then? You can't embed it into forms nor send requests to the server. While this information is always there (unless you disable CSS), there is no way to extract it (unless you use JavaScript).

This is why OPs point is still true. Without JavaScript, this information is worthless.

The point is that you can use the technique on a legitimate link on the page, e.g. a log-in button. The browser will then make a request anyway, through which you can pass the information back to the server. That is what paxcoder means by saying using a href instead of an onClick. No JavaScript is needed for this.

Put 10 links on the page, each with a slightly different href. Use CSS to make 9 of the links invisible, based on the browser history, so the user sees only one link. When they click on that link, the URL of the page they visit reveals which pages are in their history. The server can store that information, and you can tie it up with the session. To prevent spiders crawling the links, you could use buttons instead, making POST requests.

No JS required, just CSS and HTTP.

You would use background-images for the links - they will trigger the parametrized GET to the server. Present browsers only load the image if it is visible and not hidden ("display:none"). They can be transparent 1px - they just need to be turned visible one by one if a slecetor fits.

For example: you'd hide every link, except the one that should trigger a GET to the attackers server to leave the information there. Easy - and with cascaded :NOT and ~ selectors you can accomplish this on scale. The links would look something like this:

A while back i demonstrated that a website without JS can trigger GET-requests BY HOVERING A LINK. My coworkers didn't believe me - they were wrong. Caveats: When caching is enabled this attack will trigger just once - but that is enough in that case.

I found the codepen, that i had made back then: http://codepen.io/teamgroove/pen/mIxfg

USE LYNX: Turns out one shouldn't just turnoff JS - but images also. Maybe then better use: lynx as a browser (with all cookie-stuff-deavtivated and behind a tor-proxy or better: proxy-chains) if concerned about privacy. Even that will NOT be "secure enough" - of course - it just wouldn't expose your browsing-history in the first place - which was the topic.

Reply on news.ycombinator.com