Re: Firefox permission dialog and org-protocol

[Max Nikulin]

On 29/01/2023 20:50, Ihor Radchenko wrote:
> Max Nikulin writes:
> > On 26/01/2023 01:01, Ihor Radchenko wrote:
> > > https://bugzilla.mozilla.org/show_bug.cgi?id=1678994
> >
> > Bug 1678994 "website permission to open special links in external
> > applications not configurable"
...
> It appears to be a newer version of Firefox.
> I originally got to know about the problem from
> https://old.reddit.com/r/emacs/comments/10jr2up/orgprotocol_permissions_on_firefox/

Likely the person uses a bookmarklet to initiate capture. This case 
JavaScript snippet is executed in the context of the current web site, 
so it is necessary to confirm permission for each site. I would 
recommend to install an add-on for org-protocol instead. It would be 
enough to confirm once that *this extension* is allowed to launch 
external application through a custom scheme URI.

An additional advantage is that if some site were had a malicious 
org-protocol link hidden by some attractive description then browser 
would ask user even if some pages on the same site were captured earlier.

I faced a similar issue 3 years ago when "always allow" checkbox just 
disappeared from chromium popup.

The popup with permission request appeared because some version of zoom 
allowed unsolicited video call. They decided that a dialog in the app 
before switching on camera would be annoying to users. Users already 
confirmed their intention in the Safari dialog. So other browser had to 
add this popup as well. The intention is to avoid joining a video call 
accidentally while being naked.

https://infosecwriteups.com/zoom-zero-day-4-million-webcams-maybe-an-rce-just-get-them-to-visit-your-website-ac75c83f4ef5?gi=2ed4ab044837
Jonathan Leitschuh. Zoom Zero Day: 4+ Million Webcams & maybe an RCE? 
Just get them to visit your website! 2019-07-08

To summarize, I believe that a browser extension is a safer way to use 
org-protocol. With a native messaging helper application it is even 
possible to avoid desktop-wide org-protocol configuration and to call 
emacsclient directly by the add-on but not through links on non-trusted 
web sites.

P.S. Actually launching an application from an add-on is not really 
reliable as well. The following issue has links to some other bugs. Not 
to mention that external scheme URI is a shoot and forget approach with 
hardly possible error detection. (A native host application may check 
emacsclient exit code.)

https://bugzilla.mozilla.org/show_bug.cgi?id=1745931
External scheme handler configured to "Always ask" can not be launched 
from add-on background page.