Firenvim addon does not work

[zbyna]

Describe the bug

firenvim addon for embedding Neovim in browser does not work

To Reproduce the bug

Please see: glacambre/firenvim#811

Expected behavior

Possibility to Edit text field with Neovim

Server configuration and status

https://hosted.weblate.org/

Additional context

glacambre/firenvim#811 (comment)

[nijel]

Sorry, but we're not going to lower application security because of some browser add-on. See for example https://stackoverflow.com/a/53777772/225718

[zbyna]

OK. Thanks for explanation. I am moving to solutions which allow me to use vim way for working with text.

[alerque]

@nijel The SO link you sent seems to completely contradict the diagnosis here.

[nijel]

Sorry, I have no knowledge of writing extensions, so I really can't judge what can and cannot be done there. But changing website CSP because of somebody using browser add-on is not really an appropriate solution. Either fix the add-on or discuss a solution that would work with the browser developers...

[alerque]

I think you are being a little dismissive here. I'm not very familiar with CSP issues, but I believe there are a number of different ways to configure it depending on what the goals are. From what the Firenvim developer is saying what you are setting is blocking all extensions across the board from doing anything. This is not a very user friendly approach, nor do I think it actually think in improves security in most situations. If your goal is to have a website where nobody's extensions do anything ... um okay ... but ask yourself: do you really have a threat model that requires you blanket blocking something that works fine on GitHub (I'm composing this message in Firenvim), Gmail, Twitter, Facebook, Slack, and about 99% of the websites out there have determined is fine for their models?

[glacambre]

Hi, Firenvim's author here :). Here's a bit more context: when a browser loads a page a webextension should execute on, two javascript contexts are created: one for the page and one for the extension.

The webextension can do whatever it wants in its context (except for web requests in Firefox) no matter what the page's CSP is set to. The problem is that the webextension's context doesn't have access to the page's context. This is an issue for Firenvim because text editors are often big blobs of javascript objects that live in page context memory.

In order to be able to read the content of these big blob-of-js text editors, Firenvim needs to execute javascript in the page's context. It does so by creating a <script> element with the code that needs to be executed and appending it to the page. The <script> element reads memory objects in the page's context and then triggers an event which is detected by the webextension in its own context.

What this all means is that webextensions that do not need a deeper level of integration with websites will work just fine no matter what the CSP is. However, other extensions that do need this integration will have reduced functionnality (e.g. Tridactyl) or even not work at all (e.g. Firenvim).

I'm not convinced that @nijel is wrong to refuse to change weblate's CSP. In an ideal world, webextensions would be able to work without having to inject javascript in the page's context. Moreover, trying to convince every sysadmin on earth to use a CSP that allows Firenvim to work is probably an uphill battle. I think the best way forward is to work on Firefox and to get it to do what we want :).

[nijel]

Just to clarify: CSP is not about blocking extensions, these are supposed not to be affected. CSP is a way for a website to add additional safeguard against certain types of attacks, most significantly XSS. Loosening CSP to allow such extensions for few users would lower security for all users. This is a compromise I'm not willing to take. @glacambre is right here - it's not reasonable to expect that every website will adjust because of this.

Is it possible for a webextension to patch CSP headers? That's what earlier referenced SO link suggest and would address the issue on the webextension side for all websites.

[glacambre]

Is it possible for a webextension to patch CSP headers?

This is unfortunately against Mozilla's terms of use. Tridactyl used to do that and was told to stop IIRC.

[nijel]

Okay, then it's probably most reasonable to talk with Mozilla about what is the desired approach if they block this one. The specification clearly states:

Policy enforced on a resource SHOULD NOT interfere with the operation of user-agent features like addons, extensions, or bookmarklets.

And there is even a five years old bug for that: https://bugzilla.mozilla.org/show_bug.cgi?id=1267027