middlemouse.contentLoadURL is set to true by default

Please consider setting TBB's default 'middlemouse.contentLoadURL' (in about:config) from 'true' to 'false'.

When copying and pasting personal URLs that could contain personally identifiable information or link to said information the default behavior of a privacy minded browser should focus toward privacy and security over the ease and convenience of a loading URLS with a single button click. This default behavior often occurs by mistake when missing a middle mouse click on a link (to open in a new tab).

Reference links: https://bugzilla.mozilla.org/show_bug.cgi?id=366945 https://bugzilla.mozilla.org/show_bug.cgi?id=667340

Trac:
Username: WDXfjqDN4QKGYrlY

added TorBrowserTeam201709R component::applications/tor browser owner::tbb-team priority::low reporter::WDXfjqDN4QKGYrlY resolution::fixed severity::normal status::closed type::enhancement labels

I use this feature. I imagine a lot of people do.

Is the recent change of "ignore the thing you paste unless it's a URL" not good enough? (It seemed good enough for most of the people on the tickets you reference.)

It has happened to me that I have by mistake pasted in a Tor session a URL that identified me, so the "ignore the thing you paste unless it's a URL" hasn't been a good enough safeguard for me.

Trac:
Username: beadcafe

The problem that I've seen is that even highlighting any URL (without copying it) will cause the browser to go to the page when middle clicking. This even happens if you highlight a URL in non-Tor firefox then middle click in TBB. Just selecting text should not cause a potential security breach.

An easy fix would be to enable autoscrolling by default, since this changes middle click behavior. At least if the user wants to change back, it is easy to do so in the preferences menu without going to the config page.

Trac:
Username: breadyt

Trac:
Milestone: Tor: unspecified to N/A
Version: Tor: 0.2.4.17-rc to N/A

Trac:
Component: Firefox Patch Issues to Tor Browser
Owner: mikeperry to tbb-team
Keywords: middlemouse privacy deleted, privacy, tbb-firefox-patch, middlemouse added

We closed #10490 (closed) and #7639 (moved) as duplicates of this one.

I found this ticket after accidentally middle-click navigating to a URL that would uniquely identify me. Please set middlemouse.contentLoadURL = false by default, at the very least in the hardened bundle.

Trac:
Username: martingale
Sponsor: N/A to N/A
Reviewer: N/A to N/A
Severity: N/A to Normal

#11209 (moved) is a duplicate.

Trac:
Cc: N/A to blubber

This just happened to me and was completely unintended and unexpected (and confusing as I hadn't intentionally copied the URL to begin with, although I had visited it earlier in another browser). This setting is actually turned off by default in Firefox Linux, but not Tor Linux.

I obviously have no data to back this up, but I'd imagine that the majority of users who do this do it unintentionally (although perhaps intentional users do it frequently).

Given the potential to reveal your identity and the ease of switching it back on, I see this as an easy change to default off.

In case it isn't clear from the rest of the ticket, middleclicking ANYWHERE on a page except on a link will immediately navigate to the URL in the clipboard.

Trac:
Username: discram

Replying to discram:

This just happened to me and was completely unintended and unexpected (and confusing as I hadn't intentionally copied the URL to begin with, although I had visited it earlier in another browser). This setting is actually turned off by default in Firefox Linux, but not Tor Linux.

This setting is actually turned on by default in Firefox (and we don't change it in Tor Browser).

https://bugzilla.mozilla.org/show_bug.cgi?id=366945 fixed in firefox 57

Trac:
Priority: Very Low to Low
Keywords: N/A deleted, tbb-linkability added

Trac:
Keywords: N/A deleted, tbb-backport, ff59-esr-will-have added

Trac:
Keywords: privacy, tbb-firefox-patch, middlemouse, tbb-linkability deleted, tbb-pref added

From #22814 (moved):

Mozilla finally decided to fix this 11 year old bug report and set middlemouse.contentLoadURL to false in Firefox 57: https://bugzilla.mozilla.org/show_bug.cgi?id=366945

I think it would be nice if someone from the TB team backports this easy patch,

diff --git a/modules/libpref/init/all.js b/modules/libpref/init/all.js
--- a/modules/libpref/init/all.js
+++ b/modules/libpref/init/all.js
@@ -4256,7 +4256,6 @@ pref("browser.drag_out_of_frame_style", 
 
 // Middle-mouse handling
 pref("middlemouse.paste", true);
-pref("middlemouse.contentLoadURL", true);
 pref("middlemouse.openNewWindow", true);
 pref("middlemouse.scrollbarPosition", true);
 
@@ -4319,7 +4318,6 @@ pref("browser.drag_out_of_frame_style", 
 
 // Middle-mouse handling
 pref("middlemouse.paste", true);
-pref("middlemouse.contentLoadURL", true);
 pref("middlemouse.openNewWindow", true);
 pref("middlemouse.scrollbarPosition", true);

It handles Android as well

Trac:
Keywords: N/A deleted, TorBrowserTeam201709R added

This has been fixed for FF57 so removing ff59-esr-will-have keyword.

Trac:
Keywords: ff59-esr-will-have deleted, N/A added

Let's keep it until we are sure we ship that patch in the ESR52 timeframe.

Trac:
Keywords: N/A deleted, ff59-esr-will-have added

Okay, I cherry-picked that one from gecko-dev (commit 993944794e48e93074842e127ec1b9b6c34c1ef8 on tor-browser-52.3.0esr-7.5-2).

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

closed

mentioned in issue #10490 (closed)

mentioned in issue #11209 (moved)

mentioned in issue #22814 (moved)

mentioned in issue #22814 (moved)

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