an attacker could use css to cover a login input and button with their own elements.
Without html injection just think about what might be done to disrupt a site. Here on HN you could swap the comments and hide or flag links and make the site unusable. If it were on a page with a delete link or a close account link, you could trick someone into irrecoverable data loss.
Thinking only about key loggers is very narrow thinking.
In addition, 'unsafe-inline' violates separation of content and presentation. I'm surprised that modern frameworks require it, when it should receive the same hate that table-based layouts and !important have.
it also creates a giant attack surface because its a giant pile of C/C++ (was, dunno current state). the solution has always been to isolate browsers and run one isolated browser per "web app" until the web finally dies.
Would you care to enlighten us houseplants as to how? The :visited selector is limited to a very small subset of CSS properties[1] for exactly this reason; I’m sure if you have an exploit that can be used to extract browsing history the browsers will be very interested in a security report.
Check the colours of links, if they're blue, they're new, if they're purple, they've been visited. It works the same way for anyone looking at the page, not just the user's eyes.
> The window.getComputedStyle method, and similar functions such as element.querySelector, will always return values indicating that a user has never visited any of the links on a page.
> For many years the CSS :visited selector has been a vector for querying a user’s history. It’s not particularly dangerous by itself, but when it’s combined with getComputedStyle() in JavaScript it means that someone can walk through your history and figure out where you’ve been. And quickly – some tests show the ability to test 210,000 URLs per minute. At that rate, it’s possible to brute force a lot of your history or at least establish your identity through fingerprinting. Given that browsers often keep history for a long time it can reveal quite a bit about where you’ve been on the web.
> At Mozilla we’re serious about protecting people’s privacy, so we’re going to fix this problem for our users.
Regardless of it being fixed (thanks for the update) it's still possible to do this via timing attacks. I wouldn't be surprised if the sieve that is a browser still allowed it in some other way.
Links in images are always rendered as unvisited. See https://output.jsbin.com/wowalokusa, the first is an HTML link, the second is a link in an SVG, the third is a link in an SVG in an image.
Sure, it shows those colours to the user. But they're not exposed to the website; if it tries querying the colour of the links, the browser returns the same blue value for all of them, visited or not.
It used to be that CSS leaked all visitor states with no user interaction. This was patched by browsers a few years back, but there are still ways to extract some data from :visited, it just requires user interaction now.
Without html injection just think about what might be done to disrupt a site. Here on HN you could swap the comments and hide or flag links and make the site unusable. If it were on a page with a delete link or a close account link, you could trick someone into irrecoverable data loss.
Thinking only about key loggers is very narrow thinking.