Closed Bug 1575929 Opened 5 years ago Closed 5 years ago

-osint -private-window no longer works (configured via manually modified registry key so external links open in private windows)

Categories

(Toolkit :: Startup and Profile System, defect)

defect
Not set
normal

Tracking

()

RESOLVED WONTFIX

People

(Reporter: evilpie, Unassigned)

References

(Regression)

Details

(Keywords: regression)

Reported by SleweD:

Something has broken on the latest nightly, you can no longer launch urls using firefox.exe >-osint -private-window "%1%", only firefox.exe -private-window "%1". firefox.exe -osint -url >"%1%" works fine still.

Probably:
https://hg.mozilla.org/mozilla-central/rev/43a837ab3e86ae321a2de0cfd27fc08977721a21

Flags: needinfo?(gijskruitbosch+bugs)

How/why do things ever get launched with both -osint and -private-window?

Flags: needinfo?(gijskruitbosch+bugs) → needinfo?(evilpies)
Regressed by: CVE-2019-11751

-osint was added so we'd know if an url was opened using os integration and thereby be able to restrict what was passed to Firefox from other applications opening urls using os integration. So, an url that was trying to exploit Firefox by including things like non urls in an url would not perform the additional commands. I'm curious if you are adding that to the registry so it is part of os integration?

From reddit:

Why: Because when I double click a url from another application or if an installer decides to hijack my browser, it opens in a private window instead of a current window.
How: I edit the values of the two registry keys,

HKLM\SOFTWARE\Classes\FirefoxHTML-<random identifier>\shell\open\command
HKLM\SOFTWARE\Classes\FirefoxURL-<random identifier>\shell\open\command

then because nightly overwrites it on every update, which is twice a day, I set both the keys to read only from system.

Flags: needinfo?(evilpies)

I only see 2 resolutions... we could allow -private-window instead of -url in CmdLineAndEnvUtils, or we wontfix.

I'm a bit hesitant about the former because it's an edgecase and widens scope, and because it leaks more behaviour into toolkit/xre that's very browser-specific, and actually handled in browser/, so duplicating bits of it into toolkit/ feels yucky...

It doesn't help that FlagLiteral won't work for flags that have dashes in them... :-(

Dave, whaddyathink?

Flags: needinfo?(dtownsend)
Component: General → Startup and Profile System
Product: Firefox → Toolkit
Summary: -osint broken → -osint -private-window no longer works (configured via manually modified registry key so external links open in private windows)

I think in bug 1572838 we agreed that although it is technically possible for users to modify the URL used by other applications to launch users that it isn't something we wanted to support. Part of this is because if we support that then in a future update that URL may no longer work but it is also a risk mitigation strategy which vastly reduces the work we need to do to protect against vulnerabilities in other applications that can impact Firefox.

Arguably adding an exception for -private-window is pretty straightforward but I don't think the use-case is compelling enough (or something that it is easy enough for the user to do) to warrant making an exception here.

Status: NEW → RESOLVED
Closed: 5 years ago
Flags: needinfo?(dtownsend)
Resolution: --- → WONTFIX

We should look into the right way to support this in bug 1471311.

See Also: → 1471311

Dave,

Great.

For the time being:
Preferences show Firefox is NOT the default browser after replacing "firefox.exe -osint -url "%1%"" with "firefox.exe -private-window "%1%"".
And the status should be "Firefox is your default browser".

Has Regression Range: --- → yes
You need to log in before you can comment on or make changes to this bug.