1807608 - Expand webextension fetch-access to local files

Status: NEW

(WebExtensions :: General, enhancement, P5)

Description

[Cimbali]

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

Steps to reproduce:

This is an alternative to 1266960 (wants webextension to access file:// URLs at their leisure and by path, IIUC) for some use cases, and is not related to 1744532 (wants to open file:// tabs or link to file:// URLs)

Actual results:

Currently webextensions can fetch() local files if they are passed through drag & drop or an input with type="file". This can be a little clumsy in a webextension's workflow.

Expected results:

I would like to suggest 2 supplementary cases in which a webextension is allowed access to a local file:

• When a local file is accessed through a registered protocol, e.g. ext+myextension:file:///path/to/file
• When a tab on the local file is opened and the pageAction is clicked

The mechanism could be similar to what is currently used for drag/drop and input files, i.e. pass instead of the correct file:// path, a blob URL (or an object from with a blob URL can be built) that allows access to that file in the given context.

In terms of security implications:

• The permission would be granular (a single file in a single context) and would require user interaction, which means there should be no additional risks
• Both are cases where the user explicitly requests the webextension access the local page (in fact the second case even allows to inject scripts into the page) so there should be no accesses granted unknowingly either
• ext+myextension:file:///path/to/file should have the same restrictions as other similar URLs e.g. view-source:file:///path/to/file

Comment 1

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

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

Comment 2

[Cimbali]

I’m not sure what this has to do with bug 1787179, I’m proposing more of a one-time explicitly-granted access to a page in the style of activeTab rather than granting full access of any sort. Unless activeTab is scheduled to be retired or made opt-in?

By the way, I opened this bug with regard to local files, but recently noticed the issue also applies to web pages.

If you click a pageAction on a web page, with activeTab you now have host permissions on this page. However if you choose to do this with a registered protocol or have the pageAction redirect you to an extension page that fetch()es the page, you no longer have the same level of permission. In particular, this means CSP enforcement may prevent the web page from being fetched -- because the extension is considered to be a web resource and not part of the browser as far as cross-origin requests are concerned.

There’s many reasons why an extension page fetching a local or web resource should be a better practice than directly injecting content scripts into an existing page: better control of the environment (e.g. display things in a sandbox, possibility of using web workers, etc.), less risk of leaking things (fingerprintable extension ids, privileged webextension API context, etc.). The current model means an extension needs to ask for host permissions on all hosts (the dreaded <all_urls> or in my case :///*.md) to have a functional extension page.

So I think the more general formulation of this issue is to transfer host permissions to an extension page, specifically when it is opened with activeTab-like mechanisms, e.g. from pageAction or a registered protocol. I.e. more granular permissions.

Comment 3

[Rob Wu [:robwu]]

It is complicated to add support for fetch() of file:-URLs restricted to activeTab. That amount of work would be even more than a global permission system for file:-access by extensions. Anything of that sort is very dangerous and therefore we would only expose that on an opt-in basis, i.e. bug 1787179.

FYI to developers: Anything to allow file:-fetches would require changes in https://searchfox.org/mozilla-central/rev/01d7150d99c3c175300560d33dcdeea3f6b7eb29/caps/nsScriptSecurityManager.cpp#1092-1110 .