Wednesday, June 21st: 16:00 UTC (09:00 California, 12:00 Boston, 17:00 London, 18:00 Berlin)
- Dan Veditz (Mozilla)
- David Dworken (Google)
- Daniel Huigens (Proton)
- Bartosz Niemczura (Meta)
- Kyra Seevers (Google)
- Chris Thompson (Google)
- Carlos IL (Google)
- Anne van Kesteren (Apple)
- Frederik Braun (Mozilla)
- Ari Chivukula (Google)
- Joe DeBlasio (Google)
- Edward Qiu (Meta)
- Artur Janc (Google)
- Ian Clelland (Google)
- Mike West (Google)
- You?
Minutes from the 2023-04-19 meeting
- Kyra Seevers will present Partitioning
:visitedlinks history explainer for feedback. - Freddy Braun would like to discuss HTTPS upgrades (including proposals like whatwg/fetch#1655).
- TPAC is coming: we'll begin to sketch an agenda.
kyra: Explainer. Goal is to partition :visited link history. Why? :visited selector leaks user browser history.
...: Browsers keep track of pages users have visited. This provides the ability to style links if user's been to a page before. Known issue since ~2000. Side-channels allow attackers to determine user's history. Some mitigations implemented over time. Essentially did two things: 1. Browsers would lie when queried: all links are unvisited. 2. Narrowed the scope of which CSS attributes could be used in :visited rules. These stemmed some of the side-channels, but they're still leaking browsing history today.
...: Goal is to more robustly mitigate these side-channels. Rather than deprecating :visited completely, we propose ensuring that it never renders net-new information to attackers.
...: Triple-key partition for history state: only style link as visited if the user has clicked on that link in the given context before. Key includes the link URL, the top-level site, and the origin of the frame in which the link is rendered.
...: Drew inspiration from many previous proposals, all have pros and cons.
...: Why partitioning? Allows search.com to continue showing visited state to users, while attacker.com can't do the same. Sites already know what links are clicked in their context, shouldn't know which links were clicked elsewhere.
...: Why top-level site? If this wasn't part of the key, cross-site tracking would remain possible (link state ~= cookie).
...: Why frame origin? If this wasn't part of the key, information from the main frame's navigations would leak to each frame.
...: Other bits: clicks vs other navigations. Clicks from a page are all that :visited can process. Typing URLs in the address bar, bookmarks, etc do not cause links to be :visited.
...: Transition: We aim to store :visited history in a partitioned fashion for N days before shipping the partition. This dark launch means the user won't have a blank slate, but a good subset of browsing history will be covered.
dveditz: I understand why you wouldn't count address bar, etc. But is a click necessary? Pages might script navigations via JavaScript for instance.
kyra: Hadn't thought of that particular use case, will think through.
artur: I was assuming that script-initiated navigations would be treated similarly, would preserve styling since we can attach the provenance of the navigation to the history entry. Distinct from address bar, which has no natural context to record.
annevk: Link targeting could create some issues. Might not be the origin of the frame that causes the navigation. Could be some complexities there to think through. e.g. A opens B, then B is navigated by A. Shouldn't be recorded as B.
people: [more discussion of complex edge cases]
kyra: We love messy corner cases. Keep them coming. Please leave feedback and questions to https://github.com/kyraseevers/Partitioning-visited-links-history/issues.
artur: Browsers other than Chrome: reasonable? Tentative interest?
dveditz: Off and on we talk about this. This solution seems nice, involves more work. Might be able to do something with existing history data, or have stronger restrictions (same-origin/site). But search use case is important. Dovetails with another question: is this a proposed standard, or a note? Do we need to produce something as a WG? Doesn't seem like all browsers have to work the same on this UX question. NOTE rather than REC? I'd have to go back to talk to people, but I like it.
annevk: Generally makes sense. Questions around impact for users, but many sites already style links in a way that users can't see a difference. Real privacy benefits.
artur: dveditz asked whether this should be a standard: in the long run, CSS folks are excited about getting rid of the mitigations in :visited to allow more flexible styling. That only seems possible if we have a principled, partitioning-based solution. Would be unfortunate for developers if there was divergence.
dveditz: If designers want to relax the original 2010 mitigations, then we'd need to standardize something like this.
kyra: From initial conversations with UX folks, there is a demand for more CSS extensibility for these links. Would be ideal to reduce the complexity in CSS. Talked to dbaron, probably doesn't need to change the spec, but there are certainly benefits to doing so.
fbraun: Slides! But I want this to be a discussion.
...: HTTPS-Only mode. Pretty graph showing plateau in HTTPS navigations. ...: Two modes: HTTPS-Only, HTTPS-First. Chrome has similar names for different things. ...: HTTPS-Only: Upgrade everything. No fallbacks. Navigations give a warning and prompt. Default-enabled in Tor. Opt-in for users, not on by default. ...: HTTPS-First: Only upgrades top-level document loads. Has a fallback, no prompts or warnings.
dveditz: Once you upgrade the top-level, some upgrading might happen due to "Mixed Content" spec, separate conceptually from "https-first" actions.
fbraun: Will get to that! First is enabled by default in Private Browsing mode for a ~year.
...: Pretty timeline. Names are confusing! Similar concepts across browsers. ...: A comparison chart! ...: A bugzilla entry with lots of dependencies! ...: FF planning to ship Mixed Content upgrading. Looking forward to collaborating on HTTPS Upgrades. What are other folks thinking?
cthomp: Thanks for the summary! Naming is hard. Got pushback for the "HTTPS-Only" name because of the interstitial opt-in fallback. We don't use either of those names anywhere in UX. ...: Aiming to relax the opt-in nature of things. Maybe cases in which the user really wants HTTPS, always connect to a site via HTTPS, learn? Spec proposal is opportunistic with fallback. We'd like to get rid of unnecessary HTTP. ...: Sounds like FF is generally planning to ship Mixed Content auto-upgrading. Is that for all users, just for users in these modes?
fbraun: Gradual rollout (~5%?). See a higher rate of images, audio, etc failing than in the control group. Delta from Chrome experience. Giving us pause. But we'd like to do it for all users.
cthomp: Carlos can comment on the launch. Was a bit of a slog of doing outreach. Hopefully easy to follow? Conceptually for the HTTPS-Upgrades proposal, we're treating it as conceptually stacked on top of Mixed Content upgrades, which means we can keep the focus on navigational requests smaller.
fbraun: We originally tried upgrading everything all the time. That broke pages because scripts that weren't previously loading started to load. Now aiming for the Mixed Content upgrade as specced.
dveditz: Would keep HTTPS-Only mode in the code because Tor, others, want it.
anne: One slide from freddy showed that Chromium would upgrade an iframe? Is that incorrect then or is that an exception?
cthomp: It should not upgrade. Bug? Not intentional.
fbraun: Might be outdated?
cthomp: HTTPS-Upgrades is, roughly speaking, an attempt to convert our implementation into a spec that we think could be interoperable.
annevk: Matches our general thinking. Do an upgrade for the top-level, then the rest follows from MIX2. Aim to read the spec PR this week or next. Seemed large.
cthomp: Also trying to spec in the fallback behavior, which requires hooking into main fetch and HTTP fetch. The latter catches the failure of the navigation request, allows a hook for the fallback. Other complexity is leapfrogging HSTS: reframing as an injected redirect. That's in this upgrade PR as well. More closely matches implementations.
mkwst: great opportunity reflect, make progress on work. We have Thursday & Friday afternoon (Spain time)
...: Not enough time to talk about everything. But enough to talk about what is considered important. E.g., HTTPS Upgrades. Other topics like xsleaks might be good use of our times? What other top-of-mind issues do you have that you suggest for TPAC and other working groups?
...: We should brainstorm the agenda similarly to how we do it for these kinds of meetings in a GitHub issue. What other ideas do folks in the room have?
anne: the origin idea for blobs.
artur: the cookie model after 3rd party cookie blocking becoming ubiquitous and whether we can address some xsleaks then.
mkwst: agreed, there's value in context with last-months (or 2 months ago) agenda item from this working group (FIXME: add link)
daniel: Web Crypto. Secure Curves draft is close to finished. Could figure out how to merge that into the web crypto spec itself. At least 25519 is getting implemented. 448 not as much yet. Also, could think about other improvements to that spec. More modern algorithms.
...: Unrelated to that: ad hoc conversation in this call around source code transparency. Source served by web apps is the same as everyone elses'. Can we verify it to be the "correct" version for some definition. Prevent a host from serving one version to one person, another to another.
iclelland: For unload, but also as a general-purpose notion for deprecations, we'd like to think about adding none as a default permission.
mkwst: Great. I'll wrap this up in a GitHub issue and post it to the mailing list.
We'll plan it in #626.