Opened 4 years ago

Closed 2 years ago

#15555 closed defect (fixed)

view-source requests hit the network

Reported by: gk Owned by: tbb-team
Priority: High Milestone:
Component: Applications/Tor Browser Version:
Severity: Normal Keywords: tbb-usability, tbb-linkability, ff52-esr-will-have
Cc: arthuredelstein Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

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.

Child Tickets

Change History (12)

comment:1 Changed 4 years ago by gk

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.

comment:2 in reply to:  description ; Changed 4 years ago by 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

comment:3 Changed 4 years ago by mikeperry

Keywords: TorBrowserTeam201504 added

comment:4 Changed 4 years ago by mikeperry

Keywords: tbb-4.5-alpha removed

comment:5 Changed 4 years ago by mikeperry

Keywords: TorBrowserTeam201505 added; TorBrowserTeam201504 removed

comment:6 Changed 4 years ago by mikeperry

Keywords: TorBrowserTeam201505 removed

comment:7 in reply to:  2 Changed 4 years ago by gk

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.

comment:8 Changed 3 years ago by arthuredelstein

Severity: Normal

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.

comment:9 Changed 3 years ago by cypherpunks

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.

comment:10 in reply to:  9 Changed 3 years ago by cypherpunks

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
<html><head>
to bottom line
</body></html>

In contrast, using only Ctrl+U also shows
<!DOCTYPE HTML>
above the
<html><head>

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.

Last edited 3 years ago by cypherpunks (previous) (diff)

comment:11 Changed 2 years ago by cypherpunks

Keywords: tbb-usability added; tbb-linkability removed
Summary: view-source requests hit the network and are not isolated by URL bar domainview-source requests hit the network

and are not isolated by URL bar domain

Fixed in ff52-esr

comment:12 Changed 2 years ago by gk

Keywords: tbb-linkability ff52-esr-will-have added
Resolution: fixed
Status: newclosed

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.

Note: See TracTickets for help on using tickets.