[Webkit-unassigned] [Bug 182924] Potential privacy issue: DNS prefetching can be re-enabled

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Mon Feb 26 01:32:15 PST 2018


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

--- Comment #16 from Milan Crha <mcrha at redhat.com> ---
(In reply to Chris Dumez from comment #10)
> (In reply to Michael Catanzaro from comment #9)
> > I also think early return would be cleaner.
> > 
> > Chris, you're OK with changing the semantics of this HTTP header to only
> > allow disabling prefetch, never enabling it? I think we need to; the bug
> > report is valid.
> 
> I think the change makes sense. Client setting should override anything else
> IMHO.

The suggestion in comment #15 goes against the above quoted part, from my point of view. Especially when we agree that the web page should not ever enable the DNS prefetch on its own when user settings is OFF. I look on it this way:

   - settings = OFF, then DNS prefetch is kept off whatever the page or
     response headers will claim
   - settings = ON, then the DNS prefetch is enabled and the page can only
     disable the prefetch; when the page uses "on", then it won't change
     anything (prefetch is already enabled)
     * if the page (or the transport headers) disable DNS prefetching
       and then the page "changes its mind" and will try to enable it again,
       then the code with m_haveExplicitlyDisabledDNSPrefetch doesn't
       make much sense to me, because in that case WebKit would try to dictate
       some "workflow" to the web pages, which looks odd, because WebKit has
       the settings to let the clients (users of WebKit) influence the DNS
       prefetching behaviour, and the user already said it's fine to do DNS
       prefetching, thus it doesn't matter whether the page disabled and then
       enabled it again (or ten times).

I think that the code complexity with m_haveExplicitlyDisabledDNSPrefetch is not needed, unless you are afraid of (or you want to cover) some header injection on the response headers/page content(/iframes?), but even then the last word has the WebKit client through the settings and if it is fine with DNS prefetching, then let the page do it or change it on/off to its likings.

-- 
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/20180226/e1dc9bc5/attachment.html>


More information about the webkit-unassigned mailing list