W3C home > Mailing lists > Public > public-webapi@w3.org > April 2008

RE: [selectors-api] Handling :link and :visited Pseudo Classes

From: Travis Leithead <travil@windows.microsoft.com>
Date: Wed, 16 Apr 2008 13:49:30 -0700
To: Lachlan Hunt <lachlan.hunt@lachy.id.au>, public-webapi <public-webapi@w3.org>
Message-ID: <0003CB8B8FE2154EB50431DB2B8F69C002C7A38E5C@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com>
Good to see people read my whitepaper :)

Yes, the selectors API will ignore any selector with a :link or :visited pseudo-class. We shipped that with the intention of providing a 360 degree protection from the :link/:visited problem in our final release, but I believe that the rest of the plan has been cut.

However, I recently decided to keep the Selectors API behavior the same because 1) we have had no customer-reported problems/feedback on the current mitigation, and 2) I'd like to make IE8 just that much more secure. (On reason #1, I concede that this is a Beta, and the Selectors API has not had large public adoption as of yet.)

The current mitigation does exclude the ability to retrieve a list of links. However, I'm sure I don't have to remind you folks that for this scenario, there's already an excellent pre-established list of links off of the document [1]. The only thing you're not getting is the subset of links that the user has visited, and while there are use-cases for styling said list, the exploitation of this list for destructive purposes is a reality that I don’t think a good security-minded browser should ignore.

>> I'm considering adjusting the spec to allow just two options, and making
IE8's behaviour non-conforming.

That sounds like you're trying to play hardball. :) Seriously, in both of your alternative suggestions, the document.links collections is a more direct route for the web developer (and I would point them there as a workaround). There really only appear to be two choices: mitigate (as IE8 Beta1 has done, and the spec [in its current form] allows, or allow the matching to happen un-mitigated.

[1] http://www.w3.org/TR/2003/REC-DOM-Level-2-HTML-20030109/html.html#ID-7068919


-----Original Message-----
From: Lachlan Hunt [mailto:lachlan.hunt@lachy.id.au]
Sent: Wednesday, April 16, 2008 5:12 AM
To: public-webapi
Cc: Travis Leithead
Subject: [selectors-api] Handling :link and :visited Pseudo Classes

Hi,
   The current Selectors API draft states:

   "... user agents may treat all links as unvisited links, or implement
    other measures to preserve the user’s privacy."

I have noticed that to address this issue, Microsoft's implementation in
the current IE8 beta, both :link and :visited pseudo-classes are being
completely ignored.  That approach would technically fall under "other
measures to preserve the user’s privacy", but it seems like it could be
an interoperability issue.

Current WebKit builds and our internal Opera builds don't take any
action.  Both :link and :visited return unvisited and visted links,
respectively.  This also appears to be the approach Mozilla are planning
to take [1].  I think we need to be interoperable with our handling of this.

I'm considering adjusting the spec to allow just two options, and making
IE8's behaviour non-conforming.

Either:
1. Match unvisited and visted links normally with :link and :visited,
respecitively.
2. Match all links with :link, and no links with :visted (i.e. treat all
links as unvisited)

Another option would be to effectively treat :link and :visited as
synonymous and match all links with both, but I'm not so comfortable
with that.

Feedback from implementers on this issue, particularly from Microsoft,
would be appreciated.

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=416317#c16


--
Lachlan Hunt - Opera Software
http://lachy.id.au/

http://www.opera.com/



Received on Wednesday, 16 April 2008 20:49:58 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 16 April 2008 20:50:00 GMT