Opened 9 years ago

Closed 3 years ago

Last modified 3 years ago

#3010 closed defect (wontfix)

Torbutton should disable link prefetching

Reported by: HG2G Owned by: tbb-team
Priority: Medium Milestone:
Component: Applications/Tor Browser Version:
Severity: Normal Keywords: tbb-linkability, tbb-torbutton
Cc: gk, DrMikeTwiddle Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

TorButton 1.3.2 alpha rightly disables DNS prefetching, yet it does not disable link prefetching. I believe TorButton should disable link prefetching to increase privacy and reduce load on Tor network (re unnecessary traffic); see: https://developer.mozilla.org/en/Link_prefetching_FAQ

I use the following setting in user.js:

user_pref("network.prefetch-next", false);

Child Tickets

Change History (10)

comment:1 Changed 7 years ago by arma

Component: TorbuttonTorBrowserButton

See https://lists.torproject.org/pipermail/tor-commits/2008-August/003565.html where Tails chose to disable link prefetching.

comment:2 Changed 7 years ago by arma

Summary: TorButton 1.3.2 alpha does not disable link prefetchingTorbutton should disable link prefetching

comment:3 Changed 7 years ago by arma

I guess the tradeoff here is whether the user experience improves because they were probably going to click there, vs whether user experience gets worse because of the added network load from everybody prefetching.

#7656 certainly exacerbates this issue.

comment:4 Changed 7 years ago by mikeperry

Cc: gk added
Keywords: tbb-linkability added

My feeling right now is that any reasoning that makes us disable prefetching would make us also disable image tags too... Unless prefetched links get their scripts evaluated or can be otherwise elevated to a first party.

My guess is this can't happen, because scripts and CSS elements won't get evaluated until the user actually clicks on the link to render the page.

Cache isolation issues might be interesting to investigate, I guess?

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

Replying to mikeperry:

My guess is this can't happen, because scripts and CSS elements won't get evaluated until the user actually clicks on the link to render the page.

Yes. Prefetching just downloads the resource and puts it into the cache. See: nsPrefetchNode::OpenChannel()

Cache isolation issues might be interesting to investigate, I guess?

Mmm... I made some basic tests with nested Iframes, images, first party and third party loads and binding the prefetch cache entries to the domain in the URL bar worked. BUT: Looking briefly at the code and https://developer.mozilla.org/en-US/docs/Link_prefetching_FAQ I am inclined to conclude that it is possible to get the cache key wrong as there is no load context saved in the prefetch queue. Maybe that's even exploitable by some clever attacker. I need to make some further tests and take a more thorough look at the code...

comment:6 Changed 6 years ago by gk

Cc: DrMikeTwiddle added

#12050 is a duplicate of this one.

comment:7 Changed 5 years ago by erinn

Component: TorBrowserButtonTor Browser
Keywords: tbb-torbutton added
Owner: changed from mikeperry to tbb-team

comment:8 Changed 4 years ago by gk

While thinking a bit about #16998 I came back to this one in order to test whether URL bar domain isolation is still working as expected (including circuit isolation). It does, it seems: https://people.torproject.org/~gk/misc/prefetch.html.

Note: While these tests cover a bunch of scenarios they are not exhaustive (yet).

Last edited 4 years ago by gk (previous) (diff)

comment:9 Changed 3 years ago by gk

Resolution: wontfix
Severity: Normal
Status: newclosed

FWIW: As indicated in the previous comment we want to have it adhering the URL bar domain isolation idea. Thus, this is a WONTFIX.

comment:10 Changed 3 years ago by cypherpunks

You closed this as defect (wontfix), but it's not a defect, and there's nothing to fix ;)
Is isolated DNS prefetching the next step to go?

Note: See TracTickets for help on using tickets.