Re: [csswg-drafts] [selectors] Solve :visited once and for all

The Working Group just discussed `Solve :visited once and for all`.

<details><summary>The full IRC log of that discussion</summary>
&lt;dael> Topic: Solve :visited once and for all<br>
&lt;dael> github: https://github.com/w3c/csswg-drafts/issues/3012<br>
&lt;dael> TabAtkins: Over weekend there was a new attack on :visited using houdini api for timing channel attacks. Apprently chromium is mitegating by disallowing paint on links dbaron had proposals to reduce bandwidth of channels. I think we shoudl solve this<br>
&lt;dael> TabAtkins: This is leaking history information. I suggest we limit what is exposed to page to things it can have observed and then we can make :visited an ordinary pseudo calls<br>
&lt;dael> TabAtkins: Same origin pages visited are visible. Links that have navigated into your origin so that could be exposed. Finally any links that are visited from your origin are observable through a number of channels. That's the basis of the entire ad industry.  That's r easonable to expose<br>
&lt;dael> TabAtkins: I think that gives you all  the usefulness of :visited but limits privacy to things we've lost battle. Only thing we're loosing is cool links of the week pages you wont' be able to tell you've visited it before. most cases are links you've visited in the same origin or in search. That's preserved<br>
&lt;dael> TabAtkins: Concerns by Mats that the sort of tracking from the 3rd case with outbound links may violate GDPR. I can't comment on legal issues. I've reached out to our laywers. In the meantimes, does this seem r easonable? It this promising area to push, turning :visited back into a normal pseudo class?<br>
&lt;dael> dbaron: I think Mats wants  both sets of restrictions. Adding what you propose without removing existing restrictions.<br>
&lt;fantasai> What are the new restrictions?<br>
&lt;AmeliaBR> One addition to Tab's comment: All of this origin-specific history data would need to be tied into the ability of users to clear their cookies etc.<br>
&lt;fantasai> I can't tell from the minutes<br>
&lt;dael> TabAtkins: That would add a lot of complexity and not give people anything useful. Reduces information leakage, but I'd like to get all the way over the finish line<br>
&lt;dael> astearns: New restrictions. I think it's that :visited only applies to a certain subset of links that follow the restrictions TabAtkins said<br>
&lt;dael> TabAtkins: Any same origin is visiable. Page nav into origin or pages nav from origin and out to. That's all observable already<br>
&lt;smfr> i think we’ll need to talk about this internally at Apple before we can give an OK to breaking link coloring for “links of the week” pages; that seems like a serious usability regression<br>
&lt;dael> fantasai: So when a browser records if something is in history it also needs to see where you clock...you visited w3c and you have to record everywhere that I came in from as well. All ways I clicked to it from would all be recorded together.<br>
&lt;dael> dbaron: Simpier way to think about i t. What you're doing is you're keeping sep history for each origin.<br>
&lt;dael> TabAtkins: It's per origin not per page. Yes. Sep. history database, basically<br>
&lt;dael> astearns: smfr responded on IRC [reads]<br>
&lt;dael> TabAtkins: It would eliminate that use case, yes. That's the major casulty<br>
&lt;dael> astearns: He says they'd have to talk internally before giving an opinion<br>
&lt;dael> TabAtkins: okay<br>
&lt;dael> astearns: Other objections or reservations?<br>
&lt;dael> astearns: I'm not convinced, personally, but don't have an objection to investigating<br>
&lt;dael> TabAtkins: Anyone reviewing with teams, when weighing please do so against the current status quo where you can basically jsut do link coloring. And there will always be timing channel hacks in the current but this would stop that entirely. Benefits of killing status quo are reasonable. Make sure you weigh that against losing particular use cases<br>
&lt;dael> dbaron: I think always going to be timing channel attacks i s a  bit strong. I think there are fixes<br>
&lt;dael> TabAtkins: So we can make repaint always observable?<br>
&lt;dael> dbaron: No, you always repaint no matter if you visited<br>
&lt;dael> TabAtkins: Doesn't stop user interaction based<br>
&lt;dael> dbaron: Other trade off is some browsers double key the cache. They may have different trade offs<br>
&lt;dael> astearns: We're at the hour. Sounds like people are interested in discussing so let's continue in the issue.<br>
</details>


-- 
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/3012#issuecomment-413263701 using your GitHub account

Received on Wednesday, 15 August 2018 17:00:29 UTC