Protect your tabs in Firefox with Don't Touch My Tabs! (rel=noopener)
The Firefox add-on Don't Touch My Tabs! (rel=noopener) adds the link attribute rel=noopener to all links encountered in the web browser with the exception of same-domain links.
The extension addresses a long-standing issue that affects all modern web browser: when a linked resource is opened inÂ anew tab, it gets control over the page that it was loaded from.
That's a problem, as it opens the door for manipulation, tracking or malicious attacks. Visit the About rel=noopener website and activate the first link that says "click me..". It opens a new page in a new tab and while that in itself is not that exciting, going back to the originating page is because it has been manipulated by that site.
Websites may add the rel=noopener attribute to links to avoid this. Most should, considering that control is handed over to the linked resources. These could do all kinds of things, from changing form field destinations to loading tracking pixels or displaying advertisement.
Sites may implement rel=noopener to protect users and their own data from such attacks or manipulations. The problem is that this needs to be implemented by each site individually as browser makers have been reluctant to make the change. Mozilla did test rel=noopener for target="_blank" links in 2018 but did not activate the change for users of the browser. Check out the linked article for instructions on enabling noopener for blank targets.
Note: The preference appears to have the same effect as the Firefox add-on. It may require further testing to be really sure about that but a quick check of a couple of sites suggests that it works equally well.
When you check external links here on Ghacks, you will notice that noopener is used for all of them.
The Firefox add-on Don't touch my tabs! (rel=noopener) steps in by enabling noopener sitewide for any link you encounter after installation of the extension. The only exception to the rule applies to links that point to the same domain (as the site in question already has full control over its own pages).
The extension does the following, basically:
- Searches for hyperlinks on active pages and checks if they have the "target="_blank" attribute. For any found
- It adds the rel=noopener attribute if no rel attribute is used already.
- It adds noopener to the attribute if rel is already used leaving any other attributes untouched.
Breakage should be minimal and the extension works automatically in the background once it is installed. The extension is open source; you can check out its GitHub webpage to check out its source. Chrome users can check out No Opener instead which does the same.
Now You: How do you handle this in your browser?
Or just go to about:config, look for “dom.targetBlankNoOpener.enabled” and flip it to true. No extension required.
Just for more info on this before implementing, here is the extension author’s response to another user suggesting this option:
Are you sure it’s usable right now?
I’ve been tracking https://bugzilla.mozilla.org/show_bug.cgi?id=1522083 for this functionality and it seems (according to that issue) that this flag has not been officially implemented yet due to blocking issues in other areas (It seems to stop downloads from working when opened in new tabs for example). I also do not see anything in the release notes of 68, 69 and 70.
Would love to hear from you if I have the wrong information!
This extension works a little different from the ‘dom.targetBlankNoOpener’ flag by the way. The flag adds noopener to ALL target=_blank links, this extension only adds them when the domain name does not match the link name.
(Once the flag is fully operable I will make this difference clear in the description, since some people might prefer one solution/implementation over the other)
I don’t know what the extension author is talking about that’s not the tracking bug for this setting. Secondly, the setting in about:config fixes this vulnerability unlike the extension which simply spams rel=noopener in the DOM of every web page you visit, which is not a solution but rather stop-gap workaround.
Lastly the setting I mentioned is already set to true in Firefox Nightly.
Since they obviously haven’t considered removing the feature of tabs being in control of a page, what’s the normal use case for it?
Would this break the login popups that open on some websites?
I know they don’t appear to be tabs but I don’t know exactly how they function.
Shouldn’t be an issue. That’s just code that runs within the same page.
Sounds like a worthwhile extension.
I wonder if there are any privacy implications when using this?
All I found was a “Permissions:” statement on the Mozilla extension page – “Access your data for all websites”. Â¯\_(ãƒ„)_/Â¯
@Vrai just enable the flag in aboug:config (dom.targetBlankNoOperner.enabled), and you don’t have to worry about permissions or an extension being rogue.
It’s a recommended extension.
Recommended extensions are curated extensions that meet the highest standards of security, functionality, and user experience. Firefox staff thoroughly evaluate each extension before it receives Recommended status.
@Vrai, I like your shruggie. You must be using Espanso on your Mac, I am too ;-)
Thanks for referencing No Opener for Chrome. It seems to work well in Chrome Version 80.0.3987.16 (Official Build) beta (64-bit).
@Martin, thanks for linking your November 30, 2018 article.
I don’t use alot of extension due to the CSP problem.
If dom.targetBlankNoOpener.enabled is set to “true” in about:config, shouldn’t it accomplish the same functionality as the “Don’t Touch My Tabs!” web extension?
If dom.targetBlankNoOpener.enabled set to “true” breaks a website, then I’ll open the broken website in my backup browser (currently Chrome).
Check Darren’s comment above, he contacted the developer to find out. Basically, the extension avoids many of the compatibility issues by preventing noopener on internal links.
It’s already turned to ‘true’ in Nightly so the issue the extension author is concerned about is no longer an issue anymore, Martin.
Thanks for the reply Martin!
I’ve been using dom.targetBlankNoOpener.enabled set to “true” from the time I read your article (around November 30 or early December 2018) & only 1 website is broken (cough … Reddit … cough), which I visit about 2 or 3 times a month on average (with Google Chrome).
Full disclosure – I don’t login in to Reddit (why would I join a site famous for censorship, LOL) & I don’t use the Reddit Enhancement Suite web extension (I’m not installing an extension for one website).
TLDR – dom.targetBlankNoOpener.enabled set to “true” has worked really well for me. I’m not interested in installing an extension that promises greater compatibility, due to extra overhead on my computer (memory requirements) and the additional CSP problems of another web extension.
It’d be great if that link actually worked too…
True, it’s a rotten door for off the ground hackers, especially in the field of Bitcoin buying and cryptocurrency transactions. That’s why we at BitsellX.com implement automated discovery of external links and rel=noopener adding.
Thanks Martin and from the moment you introduced thru your article:
Don’t touch my tabs I am a pleased user from it.
In your articel https://www.ghacks.net/2018/11/30/firefox-security-relnoopener-for-target_blank/
you reported that “Mozilla is testing a new security feature in Firefox Nightly currently that adds rel=”noopener” automatically to links that use target=”_blank”.”
Do you think it will be implemented in the near future?
Hmmm…no problem exists using current Basilisk which is forked off Fx 52ESR.
I do see the problem in Fx60.8 ESR which is the only Fx I currently have.
@Mele: be careful when it goes off its rocker.
Basilisk is experimental. The dev warns about that.
I use it, but in a sandbox within a VM.
This article fails to link to … the main subject of the article. Maybe that first mention of the plugin could actually link to it!
The link is in the summary box below the review, as usual.
Hi all, the DTMT Dev here, I saw a spike in the number of users, so I had to Google where it came from and ended up here among other places.
I see that some of you have some questions and/or doubts.
I therefore updated the description page hoping that things will become clearer!
Thank you Jeroen i am now using it in Waterfox classic, and a merry crimbo to all of you.
Warning for Firefox Android users:
For me on Ffx Android the about:config setting was still set to false!
Which was the default!
Now I had a forced Reset on this smartphone in 9-2018.
So although it isn’t a super old Firefox install,
I guess the default setting could have been carried over from when I did (re)install Ffx back then.
Your situation may differ of course.
Hope this helps.