Closed
Bug 557013
Opened 16 years ago
Closed 16 years ago
Feature: Privacy-related changes coming to CSS :visited
Categories
(Core :: CSS Parsing and Computation, defect)
Core
CSS Parsing and Computation
Tracking
()
RESOLVED
WONTFIX
People
(Reporter: discoleo, Unassigned)
Details
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.3a3) Gecko/20100315 MozillaDeveloperPreview/3.7a3
Build Identifier: Firefox-next
The post "Privacy-related changes coming to CSS :visited" describes some future limitations in Firefox regarding the CSS :visited selector. I have another proposal, that does not set any limitations on this selector, while still enabling privacy.
Reproducible: Always
Steps to Reproduce:
1. Not applicable - Conceptual issue with CSS :visited
2.
3.
The post "privacy-related changes coming to CSS :visited" describes a set of new limitations regarding the CSS :visited selector, and getComputedStyle(). I was unaware of this security breach up to now, however I consider that limiting this feature is counterproductive per se. I do not agree to solve the issue by limiting a feature. Instead, I would propose to make the process transparent, so that users have an informed choice, if they permit this feature or not, and how sites are allowed to do it.
There is already one similar case: pop-ups. Users are allowed to permit pop-ups, or to block pop-ups. I strongly suggest to go this way - let the user decide which URLs are visible, and which are NOT. In order to have an informed consent from users, we need some mechanism to inform the user, and to bring a security level to :visited. Here goes my proposal:
1. getComputedStyle()
on same domain URL's: will return the correct style
on different domain URL's: will return *always* the not-visited style, except for the cases described below
2. Informed permission to return visited-style
A site may get the actual style of an URL, only IF it registers the URLs it will request. Regsitering is done in the html header, so that the user knows already from the beginning what URLs will be registered. The user may permit or deny registering those URLs.
a.) new HTML tag/element
<register type="URL" value=".../the/URL" />
[Someone with solid html/xml knowledge shoud design this element - <register> is just a simple proposal.]
b.) registering URLs
A site has to explicitly register ALL URLs that will be queried. IF an URL has been registered, then Firefox will compute the correct getComputedStyle(), otherwise it will return the style of the not-visited URL.
c.) Alerting user
Similar to pop-up windows, whenever a page registers URLs, then the user is warned that the site has registered the corresponding URLs. A full list is shown. The user has the options:
- do not allow registering
- allow registering
- Never allow registering and do not ask me again
- Always register and do not ask me again
In this way, users will always have enough information to decide if they trust the site and permit the site to access the given URLs. They can review the registered URLs, so they really can decide if they would permit the site to access the information for those URLs.
d.) Exclusion lists
Some URLs, like Facebook/Linkedin/... may be to sensitive for other sites to sneak in. So, I propose an exclusion list: URLs present on this list will be always excluded from registering, and so will always result in the not-visited style. This list can be accessed through the Options and modified accordingly to the users preferences. A default list may include all these social networking sites.
e.) Options for registering
A site/web page may register:
- a domain, eg. www.mozilla.org: access to everything below level is granted
- a detailed URL, e.g. http://hacks.mozilla.org/2010/03/privacy-related-changes-coming-to-css-vistited/
- include or not include the protocol (eg https will register only https://...)
- special keyword: all - will register all URLs
-- only possible, IF a special option in about:config (ALLOW_REGISTER_ALL) is set to true, otherwise will be ignored, even if user selects Yes in the pop-up option window
A last technical detail may be discussed:
If a site registers an URL, should the :visited refer only to URLs visited from that page, ignoring the same URL if visited from outside? This will significantly increase security, but makes the implementation more difficult, and removes some of the power of the :visited selector. I do not have a strong opinion for or against this one.
| Reporter | ||
Comment 1•16 years ago
|
||
Another option in about:config would be:
MAX_NUMBER_REGISTERD_URLS = default 255
So, a site may register up to 255 URLs, not more than this. Any further URLs would be disregarded, and would return the not-visited style.
As to your point (1), getComputedStyle lying is not sufficient; if that's an important part of your proposal, then you need all the major points in the approach we've taken. See the discussion in bug 147777 (and, to some extent, http://dbaron.org/mozilla/visited-privacy ) for details of how similar things to getComputedStyle attacks can be done in more indirect ways (detection of layout changes and performance effects of styles).
I also don't think most users will understand what your proposed UI means or what effects it has on their privacy. That said, I also think most sites would just want to avoid triggering that UI.
Finally, I'm hesitant to make the behavior different between same-domain and cross-domain links; that seems likely to just cause user confusion over what they've actually visited.
So I'm marking this bug as WONTFIX for now based on my current understanding of what you're proposing.
Status: UNCONFIRMED → RESOLVED
Closed: 16 years ago
Component: DOM: Core & HTML → Style System (CSS)
QA Contact: general → style-system
Resolution: --- → WONTFIX
| Reporter | ||
Comment 3•16 years ago
|
||
THE ONE-FITS-ALL page or Why Google will win with personalized pages!
I am still strongly against the limitations imposed by the work-around, because it is still a workaround. It is the user who shall decide if a site has the right to sneak into the history or not. It is by no means the browsers decision to limit this.
The contentious issue is about the ability of a site to determine whether a URL is in the user's history very quickly and without any interaction from the user. The focus is on the *interaction from the user*, not on determining if the URL is in the history or not.
The web of the last 15 years is like this: there is a site, and all users visiting a site see basically the same content: the one-fits-all page. But this is not the web of the next 15 years. I want sites to determine what I am interested in, and to adapt the content to my interests. I am the user, and I want to have the most appropriate content - not by searching myself, but by an automatic mechanism, where the site knows what I want. And surfing history is a very good indicator about my surfing habits and my interests. Though, I would like to have this process transparent, and to be informed about this activity - I want an informed consent, not default limitations.
The "register" option is a good extension to allow such an informed consent. It will force sites to register such URLs, which allows users to review any URL that might be used to track the user's habits.
URLs that are NOT registered: will not be styled (extreme version), or only minimally so (like currently). This will ensure ABSOLUTE security and confidentiality, disabling even the "very fine grained" attack vectors hypothesized in the original post. [in the extreme version]
While at the same time, registered URLs will have NO limitation in styling. And the good part is, that users can choose between allowing those URLs to be registered by the site, or disallowing this. They have the choice, and this choice is well informed - you see the URLs.
Improving content and adapting content to a user / personalizing the content will be a necessity in the next 10 years, otherwise I believe that only Google and a few other sites will be able to deliver customized content, and the rest is doomed to use archaic concepts and design one-fits-all pages.
I think you're confusing the questions of how :visited should behave with whether there should be an API, designed with privacy in mind, for sites to query a user's history. I'm still skeptical that there should be such an API, but I feel quite strongly that if there were one, it shouldn't be built on top of the hacks people have figured out related to :visited.
You need to log in
before you can comment on or make changes to this bug.
Description
•