Oh boy. github.com/signalapp/Signal-De

tl;dr Signal Desktop is based on Electron, which in turn is based on Chromium 58-59, and it seems to be affected by bugs that have been fixed in Chrome/Chromium 60-62.

Gotta love . As somebody said "now everyone is running 5 different instances of old insecure versions of the most scrutinized and attacked application on Earth."

@rysiek how on earth is electron that much behind! Horrifying

@rysiek @lattera also non BSD compatible. Signal is great but some decisions puzzle me. Before they choose a chrome app. Also very "portable". Actually I have my chromium mostly because of it.

@oriol @rysiek The Signal protocol is great. The gold standard implementation of it is horrid.

@drwho @rysiek @lattera they did, but still work, if you use a BSD you have no other choice for Signal on desktop.

Recently on the forum I proposed to get a setting for the proxy, and they were reluctant, too much complication for the average user. But I think a lot of the people that use Signal will run TOR too. Makes sense to me. But is the way it is.

@drwho @rysiek @lattera
So riot.im is a good option too, but after moving so many people to Signal... complicated. Briar looks excellent, the process of adding contacts could be cumbersome though.

@dangoljames we tried everything else.

But there's also regulation. And I think we should try that too, albeit *very* carefully.

@dangoljames uhm excuse me?

This is a solid talk, with great ideas, and a strong message. The speaker is a well-recognized security researcher with years of experience, and tons of examples to back up their claims.

The talk makes perfect sense to me, shows a deeper problem in the IT sector that has not been properly recognized, and provides concrete ways to start solving it.

You have any particular criticisms of this talk you want to share?

- emotional appeals
- weak metaphors
- buzzwords/catchphrases like 'attack surface', 'turing complete'
- 'software sucks ass'
- "Kurt Goedel' a physicist? give me a break; the man was not a physicist; he was a fantastic number theoretical mathemetician who authored a seminal theory on that topic, and who had nothing to do with physics.

There's nothing professional about this gal's talk, and very little technical substance.

The whole thing is a load of posturing fail.

@rysiek

Forgive me if I seemed to be toxically critical of the referenced talk.

We need practical solutions down here in the trenches; can't very well invest the time and energy on Electron apps (and the like) if making them secure is only approachable in theoretical terms.

@dangoljames well, seems to me we should not be investing time and effort in Electron apps.

Also, again, there are practical, concrete examples of solutions. If you say they are unworkable (with which I disagree), can you provide any other ideas for practical solutions?

@rysiek

Not certain what you have against Electron apps, but Ok.

Concerning practical, concrete examples of solutions, I haven't seen any, which is why I asked my original question: "What's to be done?"

@dangoljames What I have against Electron apps:
mastodon.social/@rysiek/100016

tl;dr it's a huge attack surface. Any Electron app bundles full ffmpeg, and a shit-ton of other stuff. This means that there is a *LOT* of code that can be buggy/vulnerable.

I am not even going to go into size, memory consumption, etc.

The sheer insecurity of the Electron ecosystem is mind-boggling.

@rysiek

Re: Electron; point taken.
However, the worst of electron is the worst of browsers as well, so its at least moderately naive to assume that because you don't use eg, Atom that you are somehow safer.
So I ask, how can this vector be mitigated, with the tools and on the networks that we have at our disposal, today?

@dangoljames stop writing shitty software. And one practical way to do this is via what's in the presentation.

And yes, the fewer Electron apps I am using, the safer I am. Because Electron *lags behind* Chrome/Chromium, so it is vulnerable to *published vulns* in Chrome/Chromium.

And Electron-based apps lag behind Electron. So it's even worse.

I would rather not run 3 old different vulnerable versions of Chrome/Chromium just to have a chat, IRC, and IDE.

@rysiek PS I don't wan't to have to become more uber leet than that gal and her poor deceased husband and THEN write my own browser to use the freakin' interwebs

@dangoljames okay, so let me get this straight:

1. you did not watch the talk to the end
2. but still decided to throw random sarcastic hashtags at it
3. you considered Electron apps secure
4. you don't consider stuff in the talk -- which you have not watched in full -- to be solutions
5. you refuse to entertain a notion that there are no immediate solutions and that perhaps we do need to change the way we write software
6. but you have no solutions of your own

I think we're done here.

@rysiek
1. Correct. This is not in question, and reasons have been provided
2. Incorrect. The hashtags were by no means sarcastic in nature
3. Incorrect. I never considered electron apps secure.
4. Strawman. I don't consider the theory presented in the talk to be of practical use in the wild.

@rysiek 5. I don't know of intermediate solutions, but I am open to suggestions. I don't dispute that changes are neccessary. I suspect, however, that "change the way we write software" should read "redesign the protocols and then change the way we write software accordingly"
6. I have repeatedly emphasized that I am l looking for practical solutions to these problems.

@dangoljames I have linked you to a talk about this. I have specified slides in this talk to focus on. I have gone above and beyond in explaining my position.

If you still don't like the solutions provided, please provide your own.

@rysiek the solutions I have come up with feel pretty ineffective in the face of the maelstrom.

I never got started writing electron apps before realizing what a potential problem it is.

I've ditched chrome/chromium in favor of waterfox, and run it in 'do not track' mode.

I left facebook just before it became cool to do so.

This is why I asked the original question, what can be done?

@dangoljames you do realize that this talk is targeted and software engineers writing software, not users using the software, right?

I mean.

@rysiek the lines are ne'er so finely drawn, except in the bright halls of academia

@dangoljames what is to be done?

Slides: 23, 24, 38, 40, 42, 44, 50, 52, 53, 54, 57.

Here are the slides:
slideserve.com/evan/the-scienc

But way, way more in the actual talk.

The gist of it: be explicit about input handling and (domain-specific or otherwise) languages your program parses. Use the language with least "computational power", stay away from the halting problem.

Or, you know, actually watch the talk.

@rysiek

I watched as much of the talk as I could stand, and before making this reply I reviewed your slide highlights.

This was just a lot of pretentious grandstanding on the part of this individual giving the presentation.

There is absolutely nothing there about what I can do to fix the browser that I have to use, right now.

@dangoljames well, again: I find the suggestions concrete, actionable, and well-rooted in evidence.

You don't agree? Great. What are your solutions?

@rysiek now i understand why it is sooooooo RAM intensive to run like Atom and Discord

@rysiek

That's learning for me today.... I used to like the concept behind electron although haven't used electron apps but now that I read what you have written I can see why it is not such a good idea after all.
Sign in to participate in the conversation
Mastodon

Server run by the main developers of the project 🐘 It is not focused on any particular niche interest - everyone is welcome as long as you follow our code of conduct!