Ask Lemmy
A Fediverse community for open-ended, thought provoking questions
Rules: (interactive)
1) Be nice and; have fun
Doxxing, trolling, sealioning, racism, toxicity and dog-whistling are not welcomed in AskLemmy. Remember what your mother said: if you can't say something nice, don't say anything at all. In addition, the site-wide Lemmy.world terms of service also apply here. Please familiarize yourself with them
2) All posts must end with a '?'
This is sort of like Jeopardy. Please phrase all post titles in the form of a proper question ending with ?
3) No spam
Please do not flood the community with nonsense. Actual suspected spammers will be banned on site. No astroturfing.
4) NSFW is okay, within reason
Just remember to tag posts with either a content warning or a [NSFW] tag. Overtly sexual posts are not allowed, please direct them to either !asklemmyafterdark@lemmy.world or !asklemmynsfw@lemmynsfw.com.
NSFW comments should be restricted to posts tagged [NSFW].
5) This is not a support community.
It is not a place for 'how do I?', type questions.
If you have any questions regarding the site itself or would like to report a community, please direct them to Lemmy.world Support or email info@lemmy.world. For other questions check our partnered communities list, or use the search function.
6) No US Politics.
Please don't post about current US Politics. If you need to do this, try !politicaldiscussion@lemmy.world or !uspolitics@lemmy.world
7) No Hit-and-Run questions.
Please don't delete your post for no apparent reason. If you plan on deleting a question later, say so in the post, or if you feel that you have a good reason to remove it, message a mod beforehand. It's not fair to the ones who took their time to answer, and it's not in the spirit of the community.
8) No Bots.
Posts or comments from bots, LLM's, AIs, Neural Networks, Transformers, or Marvin the Paranoid Android are not welcome in AskLemmy. Real humans only please.
Reminder: The terms of service apply here too.
Partnered Communities:
Logo design credit goes to: tubbadu
view the rest of the comments
An extension is probably not needed. JavaScript and local storage allow you to do this kind of stuff. Proton Drive and Mail accomplish this without an extension.
I've answered this question in many other threads at this point, but since you're now the top comment:
Proton Drive and Mail still require you to trust them to serve you Javascript that doesn't snoop on your plaintext content. They don't have any way of proving that their web app isn't taking your plaintext emails (which you can read in your browser and therefore they are visible to Javascript on that page) and sending it back to their server.
It seems that ignorance abounds in this post's comments. People are apparently unaware that one can write an extension that has no more privileges than a normal web page, and unlike a page, the code cannot change on every load. Your idea is good. I'd recommend not using any minification or obfuscation in the extension, and keep it as brief as is possible, for maximum transparency.
In a parallel situation, I've always been wary of hosted password managers' web interfaces like those of Lastpass, 1Password, and even Bitwarden, because one has to accept the code served at every access is clean. Ultimately, one enters their master password/secret keys, as plain text, into a web page that's difficult to audit & unlikely to be, on every view. Whereas offline/client-side encryption outside the transmission medium is far more trustworthy (e.g. KeePass).
Is their JS code open source? If so, I don't see any real differences between an extension and JS code. Unless extensions have less privileges or something. The user will have to either trust the code or inspect it themselves regardless if it's an extension or JS code.
The difference is that JS code served by a web server can change at the server's whim, and there is no standard way to verify that it matches what you expect except by reading it every time you visit the page.
With an extension, assuming you trust the browser itself, you can check that the extension matches its source, and you only need to do that once per install.
That's true. On the other hand, the extension gains a much larger attack surface since it has access to a lot more data (every site you visit vs. only the site that serves the JS code). At the end of the day, people wouldn't use your site if they didn't trust your site, especially if they use it for privacy and integrity reasons, so for most users I think JS is the better option. I suppose there's no reason you can't offer both though.
I think that's the prevailing sentiment in this thread. People would rather trust the site to run the code as advertised and get some added convenience rather than verify the code for themselves.
Perhaps it makes more sense to have an extension that checks that the served javascript is correct? That should be a very simple, basic extension that doesn't increase the attack surface much. Users who care to verify the code can use that and everyone else can live with the convenience.
Not sure if it makes much sense, it's probably more work than it's worth and maybe leads to doing the same thing twice.
Another commenter just told me about WAICT and there is also an experimental extension called WEBCAT by the freedom of the press foundation. Going to look into these more.
One way to not place full trust on the "server" IMO is to make the JS open source and use jsDelivr or unpkg or some other 3p service to serve the JS so that it's not in the website's control. Independent.
Just FYI: I think since manifest 3 or so you do need explicit permissions to access a sites HTML. And the end user can see which sites the extension has access to. Doesn't make me install more extension than I really have to though.
Extensions can have more access.
They can snoop / manipulate across tabs or even scan the local drive and execute system commands... when given the access.
I had to make one for work once to let a web app run a legacy command prompt system. The web app's search was better, but the users wanted to edit with the old tool.
It was kind of interesting the way it worked. Not remembering the full details, I created an extension and a batch script and had to register the batch script with a group policy and declare the extension's permission to run that batch script
Then the users could search a client in the web app and press a button to bring up their profile in the prompt app.
Not a recommended approach for public facing apps.
*Edit: No! It wasn't a batch script... exactly... it was a C# app compiled to .dll that accepted client id as an argument
When was the last time you wrote an extension? Long gone are the days when they could run system commands, and permissions must be declared in the manifest or they cannot be used, so if they aren't in there, they're not being used.
... 3 years ago ish?
I tried to clarify with the edit, you're sorta right, it wasn't a system command. It was "native messaging"
But you're sort of full of it too, as you can use this native messaging to execute arbitrary logic. Nobody said you don't need a manifest, and someone did say you needed a group policy entry too
I know what native messaging is, and I'm not "full of it" because native messaging does exactly nothing at all unless the user explicitly installs software at the system level to receive those messages and act upon them. If the user doesn't know the difference between installing an extension in a browser and downloading & executing local programs, that's an education problem, but having to do some separate installation step is a useful security obstacle. It's much safer compared to old school extensions.
Also, Firefox Quantum came out in 2017, which used the manifest permissions system (wasn't Chrome ahead of them?), so the tech you were originally talking about is older than 9 years, not 3.
💩 semantic distinctions, extensions can run whatever when you register the logic in advance, as suggested in my first comment
If you think installing a downloaded program alongside your browser is a "💩 semantic distinction" from a bit of script running inside your browsers sandboxing, then it's clear you either don't know what you're talking about, or you'd rather continue to to spread FUD than concede on basic facts.
It is he thing I suggested from the start.
I already get you're full of it. You don't have to jeep selling me
> Says they wrote an extension 3 years ago but doesn't seem to know about decade-old isolation.
> Tries to tell everyone that extensions like OP's can run system commands, despite their use case not having any need to do so.
> Accuses others of being full of it.
Jog on, mate.
💩
Interesting perspective, though of course as the MX sending and receiving all the messages in the first place, they probably wouldn’t need to do it at the browser level.