>For safer communications on desktop systems, please consider the use of a safer end-point client like PGP or GnuPG instead.
Meanwhile, regarding yesterday's PGP flaw:
>EFF’s recommendations: Disable or uninstall PGP email
plugins for now. Do not decrypt encrypted PGP messages
that you receive. Instead, use non-email based
messaging platforms, like Signal, for your encrypted
That said, the EFF recommendation turns out to be somewhere between 'overzealous' and 'wrong'. If you're using Protonmail or another solid GPG implementation, the attack is already handled in full by re-encrypting mixed plain/cipher messages and requiring MDC.
Input is never the issue, output is: you don't know how the input will be used/rendered, so it should be messed with as little as possible.
The HTML tag attack on PGP works by mixing plain and cipher text, which is a thing people might genuinely want to do. But the safer clients still interfered with it by re-encrypting anything which didn't begin with a PGP signature, for the very good reason that they couldn't trust mixed messages. The clients which mildly constrained inputs prevented the entire attack vector, and it looks a very good tradeoff right now.
I'm Alfredo Ortega, part of the team that wrote the original exploit. This is (unfortunately) not true. The exploit on the video was loaded from a Windows share that the victim's computer was not already connected. This is possible using "Anonymous shares" in Windows 10, and older windows versions.
To be clear, you need absolutely no additional software on the victims computers, besides having a vulnerable signal-desktop and be running on windows.
If you are who I think you are, maybe you could speculate if there is actually any use for this other than loading local files (local file execution) and crashing signal?
Does CSP prevent this working with, for example, a malicious.js file on a remote, attacker-controlled Samba server (configured to allow "anonymous" connections)?
So, 'self' is ALL file:// URIs.
Luckily this is fixed in the latest version (v1.11.0), so if you're a Signal user (you should be!) and you haven't upgraded already, you should upgrade immediately.
I don't see how going from one IM silo to another just because it's encrypted is going to help with anything. Especially one that's hostile towards alternative clients. I'm using XMPP with OMEMO, as I should be :P
...but it's unfair to call Signal another IM silo that's "hostile" towards other clients. Signal is 100% open source, along with the Signal Protocol which powers it all. It is community supported and wholly dedicated to brining cryptography to everybody. The latest implementation of OMEMO as it exists today would not be what it is without Signal.
In Poland I don't see many people using Signal yet. I'm recommending Conversations to anyone who asks, which doesn't seem far away in terms of usability. On desktop it's a bit worse (I mean, I'm very comfy with my Psi, but wouldn't recommend it to a random person on the street), however Dino looks very promising and might fill that niche soon.
Still all code is open source and Signal's code does support federation. Moxie stated before that you can take the code and start a federated version of Signal if you want.
> (and thus doesn't allow other apps to connect to their servers)
"thus"? You can easily use centralized model and allow the client ecosystem to thrive. You don't have to do much, just don't actively prohibit them.
And I know the blog post, it isn't very convincing.
Encrypted Open Source Messaging > Non-encrypted messaging
(submitted yesterday at https://news.ycombinator.com/item?id=17070032)
> Remove escaping from `linkText`
> We leverage jQuery’s HTML escaping in `$.html(…)`.
Why don't developers who think they need Electron instead just run as standalone browser windows with controlled resource access as suggested? Answer: because browsers haven't done the work required to provide the stuff that people think they need from electron.
The core idea that is flawed with Electron is that there really shouldn't be any context in which an application needs unrestricted access to the underlying OS - what application needs that? Electrons combines such unrestricted access with the ability to download and run code from the web which is a recipe for disaster. The effort being put into Electron should instead go instead putting controlled access to local resources into browsers.
It used to be that XSS is was only an issue on the web, but thanks to Electron it is now everywhere, including desktop and mobile apps.
It seems like rather poor timing to make such a derogatory comment.