[Webkit-unassigned] [Bug 210739] [SOUP] Downgrade requests upgraded by HSTS when cookies will be blocked by ITP

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=210739

--- Comment #8 from John Wilander <wilander at apple.com> ---
(In reply to Michael Catanzaro from comment #6)
> (In reply to Michael Catanzaro from comment #2)
> > The point is simply that prevalent domains should not have HSTS.
> 
> Well one thing has changed: nowadays ITP blocks *all* third-party cookies. I
> guess this means HSTS should be disabled for all third-party resources?
> 
> Or does Safari still allow HSTS upgrades on non-prevalent third-party
> domains? We might investigate what Safari does. But it probably shouldn't,
> because that would be subject to the same issues discussed in
> https://webkit.org/blog/9661/preventing-tracking-prevention-tracking/. (Note
> that ITP has since tightened "all third-party cookies blocked on websites
> without prior user interaction" to "all third-party cookies blocked without
> storage access API request.")

Since all third-party cookies are blocked by default and not based on classification, HSTS is also blocked across the board.

Two things to keep in mind here:

1. Entries on the HSTS preload list should not be downgraded since they are not stateful and thus cannot be used for cross-site tracking purposes. Only downgrade dynamic HSTS.

2. Make sure you also cover HSTS on redirects. This turned out to be the trickiest part for us because it required a new callback from the HTTP layer saying “This redirect was actually to HTTP but I already upgraded it to HTTPS. Do you want to change that?” This is different from the initial request which WebKit sees *before* it goes to the HTTP layer where an upgrade may happen. I.e. you can be proactive on the initial request but need to be reactive on redirects.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20200423/92869b4a/attachment-0001.htm>