| |||||||||||||
Leaking browser historyLeaking browser historyPosted Jun 26, 2008 2:39 UTC (Thu) by cventers (subscriber, #31465)Parent article: Leaking browser history
That is an interesting problem indeed... it sounds like the appropriate fix might involve an option in the browser's configuration so that users can choose between having a slightly broken DOM and a slight privacy leak.
(Log in to post comments)
Leaking browser history Posted Jun 26, 2008 3:41 UTC (Thu) by elanthis (guest, #6227) [Link] I'm not really sure it would be a "broken DOM" - it would just be an option to willfully choose to not store history in a way accessible by the DOM. It would be no different (from the standpoint of the DOM and JavaScript) than a browser which does not remember history at all. I have to admit, there are only two or three places I ever use the colored history links. And even those are just because it's only slightly more convenient to use them than to look at the timestamps on the link text.
Leaking browser history Posted Jun 26, 2008 5:35 UTC (Thu) by jwb (guest, #15467) [Link] This would definitely break a specified behavior of the DOM. If you call getComputedStyle you expect to get the computed style. If you can get the computed color, then you can get the visited or unvisited status of a link. Simple as that.
Leaking browser history Posted Jun 26, 2008 5:42 UTC (Thu) by jhs (guest, #12429) [Link] Perhaps NoScript or another extension could have a new option along the lines of "Allow Javascript, but disable/override privacy-leaking functions in a non-standard way"? The wording is awkward but it might be a reasonable compromise for some situations.
Leaking browser history Posted Jun 26, 2008 5:48 UTC (Thu) by cventers (subscriber, #31465) [Link] Konqueror does something lik this intelligently already. For "Open new windows", you can choose "Allow", "Ask", "Deny" and "Smart". They also have an "Allow" and "Ignore" for: 1. Resize window 2. Move window 3. Focus window 4. Modify status bar text Presumably, they could add a 5: 5. Examine URL history
Leaking browser history Posted Jun 26, 2008 8:52 UTC (Thu) by jamesh (guest, #1159) [Link] It depends on what the you consider to be privacy-leaking functions. If the CSS visited handling remains intact, getComputedStyle() is not the only way to get at the information. If you specify a different font size for visited links, then the dimensions of any parent element will leak the information. Displaying all links as non-visited is pretty much the only way of fixing the bug. Applying the browser's visited link colour when rendering while leaving the DOM as is might be an option, but that leads to accessibility problems for sites that change font/background colours (i.e. almost every site).
Leaking browser history Posted Jun 27, 2008 0:34 UTC (Fri) by wahern (subscriber, #37304) [Link] Not all links. Just links outside the domain.
Leaking browser history Posted Jun 26, 2008 13:31 UTC (Thu) by Jonno (subscriber, #49613) [Link] There is one solution to this problem that would not break the DOM model, but it would introduce a loss of (minor) functionality. The browser simply don't set the 'visited' pseudoclass to any links! That means all links looks like they are unvisited, both in the UI and for any scripts. So the user looses the usual visual clue to whether a link has already been visited but gains some privacy.
Leaking browser history Posted Jun 26, 2008 16:26 UTC (Thu) by iabervon (subscriber, #722) [Link] Actually, it's completely conforming for a browser to simply never say a link has been visited (and render it in the :link style), or to claim to have rendered it in the non-visited style while showing it to the user in the visited style (not that this couldn't social-engineer the user into disclosing the information). See The CSS spec.Alternatively, browsers could say that the domain or URL of the page containing the link (or something else suitable) is part of the identity of the link for purposes of determining whether you've previously visited it, and therefore only disclose to sites whether you previously clicked on this very link, rather than disclosing whether you've visited the target at all. (In general, sites can easily collect information on which of their links you've used with an "onclick" event handler, and I don't think people expect privacy with respect to the source site there.) This change would mean that links to sites you visit from sites you haven't visited look new, but I don't think that would be an unwelcome change for users.
Leaking browser history Posted Jun 26, 2008 20:37 UTC (Thu) by droundy (subscriber, #4559) [Link] This sounds to me like a perfect solution. It maintains most of the currently used (and useful) functionality, while at the same time closing the hole, as far as I can see. Does anyone have an idea whether this is under discussion by the folks at mozilla?
Leaking browser history Posted Jun 28, 2008 19:34 UTC (Sat) by man_ls (subscriber, #15091) [Link] Seconded. It could get a little annoying if link colors depended on whether I brought up www.lwn.net, lwn.net, https://lwn.net, and so on. But most of the time it would be fine, and a little heuristics (such as storing just the second level domain) would do the rest.
Leaking browser history Posted Jun 26, 2008 6:40 UTC (Thu) by dlang (✭ supporter ✭, #313) [Link] this wouldn't be the first time that safety requires 'breaking' the official standard of something (just about all anti-spam functionality involves 'breaking' the initial SMTP standards (although recent revisions may have been changed to allow current behavior) changing the implementation so that the status of the links (and anything else that the browser sets based on it's private information) is not qble to be queried by any code sent as part of that page is a smart thing to do, and once it's done by a few browsers it will get written into the next version of the standard (as an optional mode of operation) as noted, the result will not look any different to the page then if the browser didn't have any relavent history.
|
|||||||||||||