1878648 - Open link with Extension asks for confirmation every time

Status: NEW

(WebExtensions :: General, defect, P3)

Description

[hife]

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:122.0) Gecko/20100101 Firefox/122.0

Steps to reproduce:

On a new browser profile:

• Install Tree Style Tab addon.
• Type in URL bar: ext+treestyletab:group
• Select Tree Style Tat to handle ext+treestyletab Links, check "always use this application"
• Click "open link" to confirm
• Again, type in URL bar: ext+treestyletab:group

Actual results:

• Dialogue asks: Open Link with Tree Style Tab?
• "Open Link"-button is greyed out for a period of time determined by some condition on user input that I do not know (similar to the Download file dialogue).

Expected results:

• Link should be opened with Tree Style Tab without confirming every time.

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'WebExtensions::Untriaged' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 2

[Rob Wu [:robwu]]

This is a regression of bug 1828334. The restriction added there is too strict for the scenario of "safe" schemes (ext+), with no safe work-around (an unsafe work-around is to set security.external_protocol_requires_permission to false).

To fix this, I'll quote a fragment of my comment from https://bugzilla.mozilla.org/show_bug.cgi?id=1828334#c40

If we return to the drawing board - the purpose of the patch to this bug is to prevent external protocol handlers from being triggered without user interaction. I think that it is safe to keep the current behavior for protocols that are handled within the browser ("safe schemes" from registerProtocolHandler and certain schemes with the ext+ and web+ prefix - see extension_protocol_handlers.json) . Or at the very least, we can prioritize the fix for external protocol handlers and defer the behavioral change for these internal schemes to a follow-up.

There is no guarantee that the URL is going to be opened in Firefox, even if the protocol handler is in the format described above. One of the ways to determine whether a protocol is going to open internally, is to look up the protocol handler and see if it maps to a URL that starts with http(s): or moz-extension:. The extension-registered protocol handlers are implemented in ext-protocolHandlers.js. To detect them, you'd have to add a check that mirrors that logic. It looks like that logic exists at https://searchfox.org/mozilla-central/rev/8acfbe4ba09b46b91c862dc2fbc064d4fc1bac9a/toolkit/mozapps/handling/ContentDispatchChooser.sys.mjs#58-62 , but only to skip a prompt loop. I suppose that you could add a similar check to weaken the condition that you've added in the patch. When you do, ask Gijs for another review.

The recommendation from my comment was not implemented. Sarah, is this something that you could work on?

Comment 3

[:Gijs (he/him)]

Why are people typing these URLs in the URL bar? Is there a more realistic/useful scenario where this is a problem?

Edit: also, in bug 1828334 comment 41 I already expressed that I am skeptical about specialcasing web+/ext+ or https handler schemes here...

Comment 5

[hife]

(In reply to :Gijs (he/him) from comment #3)

Why are people typing these URLs in the URL bar? Is there a more realistic/useful scenario where this is a problem?

The actual relevant scenario for me are bookmarks:

1. I have bookmarked some tree structures including group tabs and want to reopen them.

2. I have a bookmark to ext+treestyletab:group?title=%s with keyword to manually create group tabs to organise my tab tree.

If it was just about typing (or rather pasting) in the URL bar, I could use moz-extension://ALPAHNUMERIC-CODE/resources/group-tab.html instead, which works without confirmation. However, when bookmarking this URL, it is automatically converted to ext+treestyletab.

Comment 6

[hife]

Note: I am "not authorized" to access bug 1828334, so it is impossible for me to get a proper idea of the considerations discussed there.

Comment 7

[:Gijs (he/him)]

(In reply to hife from comment #6)

Note: I am "not authorized" to access bug 1828334, so it is impossible for me to get a proper idea of the considerations discussed there.

It's a security bug, which is normally kept hidden until there are no more supported releases that are affected by the bug (e.g. esr), sorry.

I would have liked to have tested what happened here prior to bug 1731898 (because I would have expected there to have been a dialog) but it appears I cannot install TST on older versions of Firefox. Rob, is there some way around this, for testing purposes?

Comment 8

[Rob Wu [:robwu]]

(In reply to :Gijs (he/him) from comment #7)

I would have liked to have tested what happened here prior to bug 1731898 (because I would have expected there to have been a dialog) but it appears I cannot install TST on older versions of Firefox. Rob, is there some way around this, for testing purposes?

Have you tried older versions of the add-on? You can find them at https://addons.mozilla.org/en-US/firefox/addon/tree-style-tab/versions/

If the add-on was merely declared as incompatible, but still functional where it matters, then you can try setting xtensions.checkCompatibility.nightly to false.

Comment 9

[:Gijs (he/him)]

So older builds don't prompt at all, which somewhat surprised me. It looks like webextensions set webextension protocols' "always ask before handling" to false.

But then I tried to reproduce on current nightly with current TST and I cannot reproduce comment 0 as written. That is, I do not get asked to choose how to handle the link, or a checkbox to "always use this application", followed by a second prompt. I just get 1 prompt (the second one described, with the clickjacking-protected "Open link" button). Perhaps this is a snap/linux thing, where the Linux widget code claims there are other handlers available for this protocol? Is there another option for opening the links (besides TST) on your system?

And, the second time you open a link like that, I assume you only get the second prompt (iff you tick the "always use this application" checkbox)? Or do you get asked to pick an application a second/third/... time as well (2 dialogs each time)?

Comment 10

[hife]

(In reply to :Gijs (he/him) from comment #9)

So older builds don't prompt at all, which somewhat surprised me. It looks like webextensions set webextension protocols' "always ask before handling" to false.

This is consistent with my experience on older versions. I used to get no prompt at all.

But then I tried to reproduce on current nightly with current TST and I cannot reproduce comment 0 as written. That is, I do not get asked to choose how to handle the link, or a checkbox to "always use this application", followed by a second prompt. I just get 1 prompt (the second one described, with the clickjacking-protected "Open link" button). Perhaps this is a snap/linux thing, where the Linux widget code claims there are other handlers available for this protocol? Is there another option for opening the links (besides TST) on your system?

And, the second time you open a link like that, I assume you only get the second prompt (iff you tick the "always use this application" checkbox)? Or do you get asked to pick an application a second/third/... time as well (2 dialogs each time)?

My bad, I got mixed up when testing with various profiles. It is as you say:

1. On a fresh profile with TST installed, on the first try only the "Open link with TreeStyle Tab?" prompt shows up.

2. If I then go into file handling settings and choose "always ask" for "ext+trestyletab", I get two prompts: a) You have to select an application: Button: Select application -> b) prompt to select which program to use.

3. If in the previous prompt I ticked the box "always use this application", the next time it is back to one prompt as before.

I will edit Comment 0 accordingly.

Comment 11

[hife]

I cannot edit Comment 0. (Sorry, I'm not used to bugzilla's process.) The steps to reproduce should be only Steps 1 and 2.

Comment 12

[Sarah Clements [:sclements]]

(In reply to hife from comment #10)

(In reply to :Gijs (he/him) from comment #9)
My bad, I got mixed up when testing with various profiles. It is as you say:

1. On a fresh profile with TST installed, on the first try only the "Open link with TreeStyle Tab?" prompt shows up.

2. If I then go into file handling settings and choose "always ask" for "ext+trestyletab", I get two prompts: a) You have to select an application: Button: Select application -> b) prompt to select which program to use.

3. If in the previous prompt I ticked the box "always use this application", the next time it is back to one prompt as before.

I will edit Comment 0 accordingly.

As I recall, that is expected behavior from the changes made in bug 1828334. It might be annoying, but I don't think this is an actual regression.

Comment 13

[Sarah Clements [:sclements]]

(In reply to Rob Wu [:robwu] from comment #2)

This is a regression of bug 1828334. The restriction added there is too strict for the scenario of "safe" schemes (ext+), with no safe work-around (an unsafe work-around is to set security.external_protocol_requires_permission to false).

The recommendation from my comment was not implemented. Sarah, is this something that you could work on?

Sorry, I don't have time to work on this. If it needs to be iterated on to work-around ext+ schemes, assuming that's something that Gijs/other frontend folks support changing, someone else will need to pick it up.

Comment 14

[hife]

So I see that this extra confirmation is now implemented for protocols like apt, zoommtg and others, (but not mailto), when typed into the URL bar.

On the other hand, if I click to open Zoom on the Zoom website, I can allow zoom.us to open zoommtg-Links with Zoom and make this permanent by checking a box.

What is the difference here? Could "bookmarks" be treated like a source URL like in the second case to specifically allow bookmarks to open ext+treestyle links with the Treestyle Tab extension, just like I can allow zoom.us to open zoommtg-Links with Zoom?

Comment 15

[:Gijs (he/him)]

(In reply to hife from comment #14)

So I see that this extra confirmation is now implemented for protocols like apt, zoommtg and others, (but not mailto)

mailto and other standardized protocols are treated as safe because they are well-established and applications that handle them won't do anything stupid without [further] user confirmation (like send the email, make the phonecall for tel:, etc.).

The same sadly cannot be said for most custom protocol implementations. In fact, the reason this permission system exists at all is those custom protocols: early on in the pandemic, people figured out you could make people driveby-join a zoom call from a malicious website by navigating to the "right" zoommtg call, etc. Their camera etc. was on by default without any further prompts. So pretty obviously, browsers needed to do something to protect people. Hence the permission prompt.

, when typed into the URL bar.

On the other hand, if I click to open Zoom on the Zoom website, I can allow zoom.us to open zoommtg-Links with Zoom and make this permanent by checking a box.

What is the difference here?

You can check the box because we store a per-site permission. So we store "on [something].zoom.us, allow access to zoommtg links without prompting".

Our (very generic) permission manager code does not understand how to store permissions for "the user did this" (internally known as "system principal" aka the highest level of access), because the user can normally do whatever they like (don't need to store permissions).

When (re-)introducing this prompt for access from the address bar (or bookmarks or external applications or other user-focused entrypoints...) to such protocols, we didn't think to cater for this (which is also why the checkbox you reference does not appear at all). We would need to write specific code for the protocol handling code to consult e.g. prefs to remember if the user thinks these protocols are always safe to open.

Comment 16

[hife]

Interesting. Thank you for the explanation. With this information I found a workaround by creating a local html file, redirecting to ext+treestyletab:group, and then giving this file the permission to open Treestyle Tab, as those permissions can be remembered. To also pass on the URL parameter title=%s, I've put the following in the local file:

<script>
var uri = 'ext+treestyletab:group';
uri = uri + document.location.search;
window.location.replace(uri);
</script>

Now I can bookmark file://local-file.html?title=%s and get the result I want as before.

(If I wanted to not depend on a local file, I could upload that same file to some server, but then I guess I would have to whitelist the whole domain.)

Comment 17

[:Gijs (he/him)]

(In reply to hife from comment #16)

Interesting. Thank you for the explanation. With this information I found a workaround by creating a local html file, redirecting to ext+treestyletab:group, and then giving this file the permission to open Treestyle Tab, as those permissions can be remembered. To also pass on the URL parameter title=%s, I've put the following in the local file:

<script>
var uri = 'ext+treestyletab:group';
uri = uri + document.location.search;
window.location.replace(uri);
</script>

Now I can bookmark file://local-file.html?title=%s and get the result I want as before.

OK, I'm glad this helped you find a workaround!

(If I wanted to not depend on a local file, I could upload that same file to some server, but then I guess I would have to whitelist the whole domain.)

Yes, permissions are per-origin, which is approximately equal to domain in the http/https context. I'm actually not sure, without testing some more, how broad the file: permission grant is in this case, just fyi.

Comment 18

[hife]

(In reply to :Gijs (he/him) from comment #17)

Yes, permissions are per-origin, which is approximately equal to domain in the http/https context. I'm actually not sure, without testing some more, how broad the file: permission grant is in this case, just fyi.

The prompt says "allow this file [...]", so I assumed it was per file. A quick test with another file name in the same folder or the same file name in another folder shows the prompt again, so it seems to be per full individual file path.

Comment 19

[Rob Wu [:robwu]]

(In reply to :Gijs (he/him) from comment #9)

So older builds don't prompt at all, which somewhat surprised me. It looks like webextensions set webextension protocols' "always ask before handling" to false.

We set it to false if the extension is the only protocol handler of the ext+... protocol. It is a very poor UX to repeatedly bug the user to confirm the navigation with no way to dismiss the prompt forever.

We've discussed this bug in the triage meeting of the WebExtensions team, and we would be fine with not prompting at all for ext+ protocol handlers that are handled by extensions.

Comment 20

[:Gijs (he/him)]

(In reply to Rob Wu [:robwu] from comment #19)

It is a very poor UX to repeatedly bug the user to confirm the navigation with no way to dismiss the prompt forever.

Nobody is disputing this, for some meaning of "dismiss the prompt forever". The situation in which permission does/doesn't need to be given needs to be clearly defined and understood by the user. I might be fine with pages on skype.com opening skype protocols, but not pages on evil.com. The same thing applies here.

we would be fine with not prompting at all for ext+ protocol handlers that are handled by extensions

So the delineation here really matters, and this phrase is under-specified. Presumably you mean "when opened directly by the user" (ie with system principal), as opposed to e.g. links on websites?

It would be really helpful to understand why you think this set of protocol+handling combinations is the right set to be given an exemption (based on the security properties rather than UX). What makes this set different from others? As some examples:

What about other (web+ or other approved protocol handlers like mailto or webcal or whatever) handled by webextensions? Is there a difference? I think there might be, because ext+ is not likely to be opened, deliberately or otherwise, via links/actions in other apps, whereas unlike ext+ protocols, mailto may be associated to Firefox at the OS level. But perhaps I'm missing something there.

What about web+ (or other...) handlers handled by websites (again, when opened directly by the user, where right now there is no checkbox and we always prompt)?

What is the scope of risk for these links in general (not specific to TST), when e.g. the user is asked to copy/paste a link from a website into the address bar, it's opened by an external app on the machine, or the user is otherwise convinced to open it?

Also, how do you see the relative merits of that exemption vs. a functioning checkbox that would apply to all schemes (when opened with system principal) ? From a quick look, perhaps we could hook up the checkbox to the warn-external prefs, which presumably is the explanation for why mailto is treated differently by default? (Can the user meaningfully evaluate the risk of [always] opening these links?)