Ticket #15988: 0002-Improve-the-speculative-and-preconnect-section.patch

File 0002-Improve-the-speculative-and-preconnect-section.patch, 3.8 KB (added by mikeperry, 3 years ago)

Describe speculative connection handling more clearly.

  • design-doc/design.xml

    From 76412a1af88de0b23385d489ef27491904232d08 Mon Sep 17 00:00:00 2001
    From: Mike Perry <mikeperry-git@torproject.org>
    Date: Mon, 6 Mar 2017 16:57:52 -0500
    Subject: [PATCH 2/2] Improve the speculative and preconnect section.
    
    ---
     design-doc/design.xml | 37 +++++++++++++++++++++----------------
     1 file changed, 21 insertions(+), 16 deletions(-)
    
    diff --git a/design-doc/design.xml b/design-doc/design.xml
    index fafe27e..9c86403 100644
    a b This functionality is part of a 
    16141614
    16151615      </para>
    16161616    </listitem>
    1617     <listitem><command>Speculative connections</command>
     1617    <listitem><command>Speculative and prefetched connections</command>
    16181618      <para>
    16191619
    16201620Firefox provides the feature to <ulink url="https://www.igvita.com/2015/08/17/eliminating-roundtrips-with-preconnect/">connect speculatively</ulink> to
    16211621remote hosts if that is either indicated in the HTML file (e.g. by
    1622 <command>link rel="preconnect"</command>) or otherwise deemed beneficial.
     1622<ulink url="https://w3c.github.io/resource-hints/">link
     1623rel="preconnect" and others</ulink>) or otherwise deemed beneficial.
    16231624
    16241625      </para>
    16251626      <para>
    16261627
    1627 Although it turns out this feature is not enabled in a context as Tor Browser,
    1628 where a proxy is used
    1629 (see <ulink url="https://trac.torproject.org/projects/tor/ticket/18762#comment:3">
    1630 comment 3 in bug 18762</ulink> for further details), we would like to provide the
    1631 URL bar domain isolation in a patch to Firefox as a means for defense-in-depth.
     1628Mozilla has disabled speculative connections where a proxy is used (see <ulink
     1629url="https://trac.torproject.org/projects/tor/ticket/18762#comment:3"> comment
     16303 in bug 18762</ulink> for further details). Explicit preconnects via the
     1631<command>rel</command> attribute are still performed, however.
    16321632
    16331633      </para>
    16341634      <para><command>Design Goal:</command>
    16351635
    1636 XXX: describe linkability risk. I'm a little fuzzy on this one.. From a design
    1637 requirements perspective, they seem not that much worse than images, objects,
    1638 stylesheets, etc. Is it just that this can cause link visits without user
    1639 consent? That could be a good enough reason, but it's not an explicit design
    1640 requirement, I think. Interesting edgecase..
    1641 
    1642 Speculative connections MUST be isolated to the URL bar domain.
     1636All pre-loaded links and speculative connections MUST be isolated to the URL
     1637bar domain. This includes isolating both Tor circuit use, as well as the
     1638caching and associate browser state for the prefetched resource.
    16431639
    16441640      </para>
    16451641      <para><command>Implementation Status:</command>
    16461642
    1647 There are no speculative connections made right now in Tor Browser as it is
    1648 using a proxy (tor). A patch for defense-in-depth <ulink url="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-45.7.0esr-6.5-1&amp;id=80c53022a40aaf9d9def7dc04ee200c9b9ba78fd">is available</ulink>.
     1643For automatic speculative connects, we leave them disabled as per the Mozilla
     1644default for proxy settings. However, if enabled, they will be isolated to the
     1645proper first party Tor circuit by the same mechanism as is used for HTTP
     1646Keep-alive. For explicit speculative connects via rel, we isolate them <ulink
     1647url="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-45.7.0esr-6.5-1&amp;id=80c53022a40aaf9d9def7dc04ee200c9b9ba78fd">via
     1648this patch</ulink>. This isolation makes both preconnecting and cache warming
     1649via rel=prefetch and rel=prerender ineffective for links to domains other than
     1650the current URL bar domain. For links to the same domain as the URL bar
     1651domain, the full cache warming benefit is obtained. As an optimization, any
     1652preconnecting to domains other than the current URL bar domain can thus be
     1653disabled (perhaps with the exception of frames), but we do not do this.
    16491654
    16501655      </para>
    16511656