eyedropper-api
eyedropper-api copied to clipboard
WICG
Leaks browser history from :visited color
From https://github.com/WICG/eyedropper-api/issues/13#issuecomment-932584477
PoC: An image editor could provide an eyedropper, and when activated overlay the entire UI with a link with :visited { background-color: rgba(0, 0, 0, 0.05); }. When the user has picked a color, the page should know where the pointer is and therefore whether the link was visited.
Possible mitigation: Style all links as unvisited when the eyedropper is open? This would prevent some legitimate use cases (e.g., getting the color of a visited link when designing a website).
Does this attack actually work? The alpha channel gets dropped on visited colours.
That's not my understanding of @upsuper's original comment. That was more (iiuc) something like telling the user "go click the purple text", in which the page doesn't know which of n links is visited, but the user does.
The alpha of :link will be used instead, but that can be almost-transparent and you can use a different background color to tell the difference with EyeDropper. PoC: https://software.hixie.ch/utilities/js/live-dom-viewer/saved/12527
@upsuper's comment is a social engineering attack where the page can detect which link was clicked more simply with an event listener. The attack I described can be used as part of the user's normal workflow when using a web app where an eyedropper is normally used (e.g. image editor), and the web app can steal browser history information every time the user uses the eyedropper without them knowing.
The picked color will be slightly wrong, so it's possible that users would notice. Or maybe the webapp can post-process the picked color to undo the color change.
By my original comment, what was in my mind is more like, having multiple semi-transparent links overlapping the same area, and guide user to pick color of that area and the page may be able to decode visited state from the color of all links inside. For example, we can have three links one uses red, one uses green, and the other uses for visited color, then the existence of color in each channel reveals visited state of all three links.
When the user has picked a color, the page should know where the pointer is and therefore whether the link was visited.
I don't think the API returns the pointer position. With mouse as input device, one may be able to observe mouse move event thereafter to have an approximation, though.
