#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
Component: | Torbutton → TorBrowserButton |
---|
comment:2 Changed 7 years ago by
Summary: | TorButton 1.3.2 alpha does not disable link prefetching → Torbutton should disable link prefetching |
---|
comment:3 Changed 7 years ago by
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 follow-up: 5 Changed 7 years ago by
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 Changed 7 years ago by
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:7 Changed 5 years ago by
Component: | TorBrowserButton → Tor Browser |
---|---|
Keywords: | tbb-torbutton added |
Owner: | changed from mikeperry to tbb-team |
comment:8 Changed 4 years ago by
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).
comment:9 Changed 3 years ago by
Resolution: | → wontfix |
---|---|
Severity: | → Normal |
Status: | new → closed |
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
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?
See https://lists.torproject.org/pipermail/tor-commits/2008-August/003565.html where Tails chose to disable link prefetching.