Open Bug 1517520 Opened 6 years ago Updated 2 years ago

Links clicked in Browser Toolbox in private mode are opened in normal mode, leading to the urls and data being stored with them forever in chrome_debugger_profile.

Categories

(DevTools :: General, defect, P3)

Product:
DevTools
Component:
General
Version:
66 Branch
Type:
defect

Tracking

(Not tracked)

People

(Reporter: modi.konark, Unassigned)

References

(Blocks 1 open bug)

Details

(Keywords: privacy)

Attachments

(2 files)

link-gaurdian.png
(deleted), image/png
Details
thegaurdian-places.png
(deleted), image/png
Details
Attached image link-gaurdian.png (deleted) —
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3578.98 Safari/537.36 Steps to reproduce: 1. Enable Browser Toolbox in Firefox. a. Inspect-element b. Settings (By clicking three dots on top right side of the panel) c. Check box for: i.Enable browser chrome and add-on debugging toolboxes. ii. Enable remote debugging. 2. Once enabled the remote debugging, Open Browser toolbox. a. Tools -> Webdeveloper -> Browser Toolbox 3. Now open new private window and visit a website which prints some links in console, like `https://www.thegaurdian.com`. 4. It prints a link like `https://workouts.thegaurdian.com/careers/digital-development`. 5. If you click the link in step4, it opens the chrome_debugger_profile. But it does not open the link in normal window instead on private window. You can check the places.sqlite and other storage by checking the path to chrome_debugger_profile via about:support Actual results: Since, the original link was opened in private window and this link is opened in normal window, it leaves a persistent history of url and storage that the user visited. Expected results: If you click the link in Browser console or Browser Content Toolbox instead of Browser Toolbox, it is opened in what ever the original window was. In case of private window, it is opened in private tab. Expected result in Browser Toolbox is also to open in the same context or not allow to open the link in the first place. Tested on both production and Nightly, and the issue exists on both.
Attached image thegaurdian-places.png (deleted) —
Clarity on step5: 5. If you click the link in step4, it opens the chrome_debugger_profile. But it opens the link in normal window instead of private window.
Some more examples of websites to test: 1. https://www.coursera.org/ 2. https://www.facebook.com/ I checked TorBrowser - 8.5a6 (based on Mozilla Firefox 60.4.0esr) (64-bit) and it does not seem to be impacted from this. Not sure, if they patch it or ESR does not have this issue. Still adding :arthur to verify.
I don't think this is a security problem in the sense that nobody can realistically "trick" users into this and then abuse it somehow. If you can convince the user to take these steps, you might as well just get them to run JS with system privileges. Even besides that, history being saved locally is a privacy issue, but not a security flaw. Firefox cannot protect you from other software running on your machine. Ni dveditz to check that we can unhide this. Separately, I'm fairly sure that we don't actually support using the chrome debugger to open any links. As in, we could break it tomorrow and I don't think anyone would care. The browser toolbox is a tool to debug the browser, for which you basically never need to open web links. If you're debugging a webpage like the guardian, you can just use the normal devtools and console etc., which work correctly. Brian, can you forward this needinfo to whoever works on the browser toolbox these days?
Component: Untriaged → General
Flags: needinfo?(dveditz)
Flags: needinfo?(bgrinstead)
Product: Firefox → DevTools
(In reply to :Gijs (he/him) from comment #4) > Separately, I'm fairly sure that we don't actually support using the chrome > debugger to open any links. As in, we could break it tomorrow and I don't > think anyone would care. The browser toolbox is a tool to debug the browser, > for which you basically never need to open web links. If you're debugging a > webpage like the guardian, you can just use the normal devtools and console > etc., which work correctly. Brian, can you forward this needinfo to whoever > works on the browser toolbox these days? Right, we don't really expect someone to do normal browsing in the chrome debugger profile. There are only a couple ways I know of to open a normal browsing window for browsing from the Browser Toolbox: 1) On OSX you can trick it into opening a window by right clicking on the dock icon and saying 'New Window' 2) Clicking on a link in the UI (i.e. About -> Nightly -> "Mozilla") or a link from the console, etc Also, the private window is in the normal browsing profile, but the link is being opened in the Browser Toolbox profile (which doesn't have a private window opened). I double checked and if I did happen to have a private window opened in the Browser Toolbox then the link gets handled in that window (normal behavior). Given how hidden this is (and the fact that it has to be initiated from a preffed-off-by-default developer tool), I don't think there's a strong expectation or use-case for Private Browsing in this profile, and don't want to do Browser-Toolbox-specific bugfixes for this. If this reproduced from the normal devtools toolbox or even Browser Console I'd say we should fix it, but I don't think it does.
Flags: needinfo?(bgrinstead)
If we wanted to we could open the Browser Toolbox profile in perma private browsing mode with the command line arg to ensure we never write to history in that profile - I don't feel strongly one way or another about that.

Agreed with comment 4, this bug doesn't need to be hidden.

(In reply to Brian Grinstead [:bgrins] from comment #6)

If we wanted to we could open the Browser Toolbox profile in perma private
browsing mode with the command line arg to ensure we never write to history
in that profile - I don't feel strongly one way or another about that.

Is there any benefit from storing history and such in that profile? Assuming there's not (or nothing compelling to a large number of the browser/extension devs who might use the feature) might be kinder to their drive/space to turn off useless data-saving.

Group: firefox-core-security
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: needinfo?(dveditz)
Keywords: privacy

(In reply to Daniel Veditz [:dveditz] from comment #7)

Agreed with comment 4, this bug doesn't need to be hidden.

(In reply to Brian Grinstead [:bgrins] from comment #6)

If we wanted to we could open the Browser Toolbox profile in perma private
browsing mode with the command line arg to ensure we never write to history
in that profile - I don't feel strongly one way or another about that.

Is there any benefit from storing history and such in that profile? Assuming there's not (or nothing compelling to a large number of the browser/extension devs who might use the feature) might be kinder to their drive/space to turn off useless data-saving.

I don't think there's any real benefit from storing history in that profile. It's also unlikely that much would be saved since it's hard to open a normal browser window in it.

It'd take little effort to add -private to the arguments at https://searchfox.org/mozilla-central/rev/76fe4bb385348d3f45bbebcf69ba8c7283dfcec7/devtools/client/framework/ToolboxProcess.jsm#273, so I'd be fine to take a patch that did that assuming it doesn't cause any breakage I haven't thought of.

Priority: -- → P3

(In reply to Brian Grinstead [:bgrins] from comment #8)

It'd take little effort to add -private to the arguments at https://searchfox.org/mozilla-central/rev/76fe4bb385348d3f45bbebcf69ba8c7283dfcec7/devtools/client/framework/ToolboxProcess.jsm#273, so I'd be fine to take a patch that did that assuming it doesn't cause any breakage I haven't thought of.

This doesn't seem to work, at least when I tried it.

Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: