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

[bugzilla-daemon at webkit.org]

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

--- Comment #17 from Michael Catanzaro <mcatanzaro at igalia.com> ---
(In reply to Milan Crha from comment #16)
> 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

Yes

>    - 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)

Yes

>      * 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.

Since this setting affects the security of the page, the current code ensures that it is not possible to re-enable it once it has been disabled. There doesn't seem to be any strong reason for your patch to remove this restriction. I would prefer that your patch make only the originally-desired change.

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