Implement a WebExtension and some client libraries for different languages

[KOLANICH]

Implementation of encryption in JavaScript turns all the security into snake oil. Users cannot be sure that the code available on the webpage is not malware. So the code used should be the same for all the websites and there should be guarantees that it is not backdoored.

A possible way to solve the issue is to implement a WebExtension. When a website supporting Mozilla Send is loaded, the extension detects it and no content from the website is executed or shown. Instead the extension opens its own GUI and does all the work itself, interacting to the website via API when needed. No third party libs (including vendored ones), frameworks and WebAssembly blobs is allowed in the extension, only Vanilla JS and API provided by the browser. Extension is not attested, it is just installed by a user, audited by him and can be modified by him without preventing it from operation.

[hellosct1]

Hi,

I published this week a web extension that you can find here
https://addons.mozilla.org/fr/firefox/addon/send-to-fx/

best regard
Christophe

[KOLANICH]

I am sorry, but the WebExtension (at least the version published on GH, I usually don't unpack XPIs, if authors provide a link to source code repository) is useless. It just opens the website in a sidebar. It is definitely not what I meant. The extension I mean should contain an OWN SELF-SUFFICIENT IMPLEMENTATION. It MUST BE DESIGNED TO GET BROKEN if backend changes in an incompatible way. It is ONLY the way to keep away malware - you have and use own copy of software, the audited and approved one, not the one provided by the website, and you don't use anything provided by the website. Your webextension doesn't do it. Instead it uses a potentially backdoored implementation provided by the website.

Using the website this way means that de-facto there is NO end-to-end encryption (because the keys are available to company-controlled environment), and all claims about it is just marketing bullshit for the uneducated users who understand nothing in computers or security. Sertainly I can use PGP or OpenSSL, but it is not a ready to use product. The service is positioned as a ready-to use product, but in fact it is not. Currently a user has to create an own implementation in order to use the service securely rather than use the existing one.

A possible way to fix it is to require a user to install a free open-source AUDITED and COMMUNITY-APPROVED WebExtension in order to use the service of this kind. But it is not done.

[dannycoates]

@KOLANICH I understand you have strong feelings about security but there's no need to criticize a volunteer community member's work so harshly just because it doesn't meet your needs.

Computer security is not an absolute secure or insecure proposition. Even formally proven code can be vulnerable to hardware exploitation. Running code downloaded from the web (or any source) involves some level of trust and risk. Send does provide secure encryption for people who trust Mozilla, the code in this repo, the infrastructure we use to distribute it, and the rest of their own software and hardware stack. Anyone who isn't comfortable trusting any of those may use alternatives in conjunction with or instead of our service.

[KOLANICH]

people who trust Mozilla

These people need no encryption, it is waste of time and resources. The whole purpose of end-to-end encryption is that the service provider is explicitly untrusted. You should either stop advertising the product as end-to-end and probably remove client-side encryption code, or implement end-to-end encryption the right way. Probably the protocol should be standardized in order to make it easier to third-party websites implement an own backend. Or you may use any of already standardized protocols, like WebDAV + own standardized extension to WebDAV + own standardized discovery protocol.

Running code downloaded from the web (or any source) involves some level of trust and risk.

So it was proposed not to run any code "downloaded from the web" without any audit. Instead the webextension should be called.

People clone git of the extension, read the whole source code of the extension, pack repo contents into an xpi file and use it (no need to invoke any special build tools in order to create a workable XPI file). For the ones who feel like it is too complex for them, a prearchived extension should be provided, which files must be bit-to-bit identical to the ones in the repo.

[hellosct1]

Hi,
I have published a new version with your comments.
The extension will evolve further because I have been asked for new functions

thank's

[KOLANICH]

@hellosct1, unfortunately the extension still doesn't contain any own implementation of the frontend code needed to use tue service.