transparency, trust, emscripten, XMLHttpRequest

[fholzer]

First off, thanks you for taking the time to work on this project.

I like browsing the source code of new project I consider using. Especially so if they are forks of prior work, looking specifically at the diff to the original source code. As someone not familiar with what emscripten usually outputs i can only guess that it is probably normal that the code it generates includes things like large base64 blobs as well XMLHttpRequest. The XMLHttpRequest is a bit confusing as there's no obvious reason for this project to make http requests - though I suppose this could be some Gnome related thing. Usually this would be a red flag from security point of view.

Anyway, where I'm going with this is that for the sake of transparency it would be really great if the repository included the source code of whatever was compiled using emscripten here, instead of the compiled code - and compile these at build time. This would drastically improve transparency wrt. what the code does.

[FelipeFTN]

Hello, Buddy! Thank you for sharing your thoughts about this project! 💯

I'm also a huge fan of exploring source codes, also, transparency on the way I use tools is also very important to me! 🔍 I'm very interested about your findings over this project, but I'm also quite confused about what do you mean by emscripten stuff in the project. Can you give me some examples/evidences about this? As for the XMLHttpRequest, I can ensure you the extension itself does not share any data, or communicates directly with any tracker server or anything like that. 😄 Perhaps this might be something with Gnome Extensions doing requests to its server to get any updates from extensions? I don't know, maybe further investigation might be required for this.

But I really appreciate your idea. The way it works today, all the code is manually "compiled" - through make - and the generated .zip file is sent by me to gnome extensions. A better move would be to automatically "deploy" it to gnome extensions with some sort of CI/CD. That's actually a good idea for the next features!

Anyway, for today's action on transparency, you can always check out what is the code installed into your machine. Since all the extensions are installed using the Gnome Extension app, Emoji Copy cannot control, or chose some different path or installation - it's all controlled by Gnome Extension. So, you can read the code in your machine by accessing ~/.local/share/gnome-shell/extensions/emoji-copy@felipeftn/. All the Javascript code that is compiled with Makefile should be there. 🚀

If I misunderstood something, or didn't get your idea, feel free to share some images, screenshots, links or stuff to enrich our conversation!

Thanks for your report!

[fholzer]

sorry, seems I forgot to add a link to the file i was referring to. Here it is: https://github.com/FelipeFTN/Emoji-Copy/blob/master/emoji-copy%40felipeftn/libs/sql/sql.js Though I realize now that the file is just downloaded from https://github.com/sql-js/sql.js/releases/tag/v1.10.2 Is it node possible to specify it as dependency and load it using e.g. require('sql-wasm.js')?

[FelipeFTN]

@fholzer No problem haha!

Unfortunately, we cannot import dependencies like this, by using node require. Life would be much easier if we could hahaha :sweat_smile:

That's why we need this file in libs for SQLite connection. There are not many differences between the file from libs and the file from the releases v1.10.2. We just added a line exporting with modules for compatibility with Gnome Extension.

I don't like the way we did this, but It was the only good way. We also could use a native library to achieve this, called libgda, which allows us to use SQLite directly from JavaScript. But we could not keep using this library, because of a bug in OpenSuse distributions, which the extension was not working in any way.

You can take a look at this here: https://github.com/FelipeFTN/Emoji-Copy/pull/32#issuecomment-1946456118