view-source requests hit the network

If I visit foo.com and look at its source (e.g. via Ctrl + U) another request is sent over the Tor network using "--NoFirstPartyHost-about-blank--" as SOCKS username. There are two things wrong with that behavior: 1) view-source requests should not hit the network at all as this is not necessary. 2) All these requests are sent over the same circuit allowing user profiling which the isolation to the URL bar domain should prevent.

added component::applications/tor browser ff52-esr-will-have owner::tbb-team priority::high resolution::fixed severity::normal status::closed tbb-linkability tbb-usability type::defect labels

If one is loading a resource from the viewed source the default circuit is used. I wonder whether we want to have a different behavior here as well.

Replying to gk:

If I visit foo.com and look at its source (e.g. via Ctrl + U) another request is sent over the Tor network using "--NoFirstPartyHost-about-blank--" as SOCKS username. There are two things wrong with that behavior: 1) view-source requests should not hit the network at all as this is not necessary.

It seems like a lot of people agree with you, e.g., see this bug report:

https://bugzilla.mozilla.org/show_bug.cgi?id=307089

Trac:
Keywords: N/A deleted, TorBrowserTeam201504 added

Trac:
Keywords: tbb-4.5-alpha deleted, N/A added

Trac:
Keywords: TorBrowserTeam201504 deleted, TorBrowserTeam201505 added

Trac:
Keywords: TorBrowserTeam201505 deleted, N/A added

Replying to mcs:

Replying to gk:

If I visit foo.com and look at its source (e.g. via Ctrl + U) another request is sent over the Tor network using "--NoFirstPartyHost-about-blank--" as SOCKS username. There are two things wrong with that behavior: 1) view-source requests should not hit the network at all as this is not necessary.

It seems like a lot of people agree with you, e.g., see this bug report:

https://bugzilla.mozilla.org/show_bug.cgi?id=307089

Looking at that bug again I wonder whether our cache isolation is actually the culprit here. There are a lot of people claiming we need all caches being disabled (which we don't have) in order to hit this problem.

Here's what I have worked out so far. The key function appears to be viewSource(URL, outerWindowID, lineNumber), here: https://dxr.mozilla.org/mozilla-central/rev/aa90f482e16db77cdb7dea84564ea1cbd8f7f6b3/toolkit/components/viewsource/content/viewSource-content.js#222

outerWindowID refers to the content window for the document whose source we want to view.
The subsequent line, let contentWindow = Services.wm.getOuterWindowWithId(outerWindowID), gives us a reference to that content window object. So we should be able to use this to obtain the first party URL. Then we will need to work out how to alter the function call this.loadSource(URL, pageDescriptor, lineNumber, forcedCharSet); to force it to retrieve the file from the cache partition assigned to that first party, or, if that is somehow not available, to load over the corresponding first-party Tor circuit.

Trac:
Severity: N/A to Normal
Sponsor: N/A to N/A

FWIW this issue caused multiple problems for me.

1. The page refetch takes time which results in a blank source window until the page is refetched.
2. The use of a different circuit causes websites that use CloudFlare to sometimes display the CloudFlare captcha page source instead.

As a workaround for both problems i use the Inspector tab in Firefox Developer Tools.

,,IMO Mozilla should merge view-source and Firefox Developer Tools and give the later an option to not show dynamic changes (so it reflects how view-source works) but that's outside the scope of this ticket.,,

Replying to cypherpunks:

As a workaround for both problems i use the Inspector tab in Firefox Developer Tools.

I use this workaround: Ctrl+A (Select All), then context click, "View Selection Source" Source opens, and shows all the html of page from top line

to bottom line

In contrast, using only Ctrl+U also shows

above the

There may be other differences somewhere in between top and bottom lines, but the bug ticket opener implies that the "workaround" html code is what is desired.

Trac:
Reviewer: N/A to N/A

and are not isolated by URL bar domain Fixed in ff52-esr

Trac:
Summary: view-source requests hit the network and are not isolated by URL bar domain to view-source requests hit the network
Keywords: tbb-linkability deleted, tbb-usability added

Nice find. We don't care so much about those requests hitting the network (stopping that would have been a convenient solution to the first party isolation problem). So, closing this as it is fixed in 7.0a4.

Trac:
Status: new to closed
Resolution: N/A to fixed
Keywords: N/A deleted, ff52-esr-will-have, tbb-linkability added

closed

mentioned in issue #16453 (moved)

mentioned in issue #16747 (moved)

mentioned in issue #20042 (moved)

mentioned in issue #25672 (moved)

mentioned in issue tpo/core/tor#20042 (closed)

moved to tpo/applications/tor-browser#15555 (closed)

mentioned in issue tpo/applications/tor-browser#25672