🇮🇹 🇪🇪 🖥
You don’t need root (dump memory). You need the user password or to control the binary. Both of them relatively easy if you have user access. For example, change ENV variable to point to a patched binary first, spoof the password prompt, and then continue execution as the normal binary does.
I am saying that based on the existing risks, effort should be put on the most relevant ones for the threat model you intend to assume.
In fact the “fix” that they are providing is not changing much, simply because on single-user machines there is borderline no difference between compromising your user (i.e., physical access, you installing malware unknowingly etc.) and compromising the whole box (with root/admin access).
On Windows it’s not going to have any impact at all (due to how this API is implemented), on Linux/Mac it adds a little complexity to the exploit. Once your user is compromised, your password (which is what protects the keychain) is going to be compromised very easily via internal phishing (i.e., a fake graphical prompt, a fake sudo prompt etc.) or other techniques. Sometimes it might not be necessary at all. For example, if you run signal-desktop yourself and you own the binary, an attacker with local privileges can simply patch/modify/replace the binary. So then you need other controls, like signing the binary and configuring accepted keys (this is possible and somewhat common on Mac), or something that anyway uses external trust (root user, remote server, etc.).
So my point is: if their threat model assumed that if your client device was compromised, your data was not protected, it doesn’t make much sense to reduce 10/20% the risk for this to happen, and focus on other work that might be more impactful.
Privacy is not anonimity though. Privacy simply means that private data is not disclosed or used to parties and for purposes that the data owner doesn’t explicitly allow. Often not collecting data is a way to ensure no misuse (and no compromise, hence security), but it’s not necessarily always the case.
A security company should prioritize investments (I.e. development time) depending on a threat model and risk management, not based on what random people think.
I am a security professional. I would personally not care less to make the distinction, as both are very generic terms that are used very liberally in the industry.
So I don’t see any reason not to call this hacking. This was not an intended feature. It was a gap, which has been used to perform things that the application writer did not intended (not in this form). If fits with the definition of hacking as far as I can tell. In any case, this is not an academic discussion, it is a security advisory or an article that talks about it.
Lack of rate limiting is a code vulnerability if we are talking about an API endpoint.
Not that discussion makes any sense at all…
Also, “not securing” doesn’t mean much. Security is not a boolean. They probably have some controls, but they still have a gap in the lack of rate limiting.
There are almost 30 different countries in Europe. They also have quite different cultures and policies around immigration (for example).
Who are you talking about, specifically?
Over nextcloud probably the e2ee. I suppose soon they will also integrate this better with email (like you can attach directly and save directly from email), so the seamless integrations with the rest of the products will probably amount to other benefits over time.
Until I can easily export the data, where is the vendor lock?
Vendor lock means that migrating away has significant cost or technical challenges.
Take this case: documents saved are first of all easily downloadable from drive (in bulk), and also exportable in markdown.
They change pricing/add features that I don’t want/sell off the company (hard now that it’s managed by a nonprofit but still) etc.? I make a nice bulk download and move everything in whatever other system I want. I can do the same for contacts, email (I use my own domains) and calendar. Basically, 1h + the time to download files and I am moved to another provider.
Can you elaborate in what you think the vendor lock looks like?
https://github.com/ProtonMail/WebClients/tree/main/applications
They use monorepo for the web clients, at least.
Here the mobile apps:
Also in Italy, but I think once the data protection agencies will get on it, it will be forbidden. It will take some time, but there is no way that’s a legitimate use of consent.
Does it work phone to phone? I was under the impression that a backup restore was needed if you wanted previous messages. It’s really an unnecessary security risk to have previous message sync. Someone gets your phone in their hand for 20 seconds, links your device and they get every message you have ever sent? No bueno.
I think OP refers to the first install/link. It is a feature that previous conversations are not shown when you do a fresh client link.
https://support.signal.org/hc/en-us/articles/360007320551-Linked-Devices
No sorry, you said name as in the person’s name, I did not understand “username”.
I am not sure I understood. You called some mod by name and they removed the comment? If that’s the case, I perfectly understand and agree with the decision tbh.
That said, this is a general argument, not referred to any particular mod. I think that many people get angry when their content is moderated and they might want to harass/argue/avenge against the mod who took that action.
You need to learn what abstraction is, my friend. I am not speculating. Quite the opposite. I am saying that you like to think the world works according to precise laws that you can use to predict the future. This is why you are arguing in multiple comments that “they would have…”, as if people are NPCs with 3 different behaviors and the outcomes are predetermined so it’s just a matter of choosing.
The reality is simple: you, me, nobody can know for sure what " would have happened" if history happened differently. This is a methodological issue, not a discussion on the merits of your speculation.
I don’t know if nuclear bombs caused less deaths than the millions of other potential courses of actions, and neither do you, neither does anybody else. I don’t know if Israel wiping off Gaza from the map potentially saved thousands of lives in future conflicts. You see the problem?
Now, before assuming that everyone else is an idiot and that you are the only smart one in the room, you might want to try a little harder to understand the point of your interlocutor, considering we are also discussing in what (I assume) is your native language but not mine. If you didn’t understand so far that my critique is in the method, not in the merits, of your claim, then I agree, there is nothing to talk about.
I just made an example of speculating on future occurrences to justify concrete actions that instead happened. In fact, the entire comment was about the general idea of considering history deterministic, not about the specific atomic bomb event…
And where is the count of deaths in the different timeline?
Look, my point is simple: human history is not deterministic and we simply can’t know what happens tomorrow like if we were predicting the laws of phisics. Maybe there were other 100 different course of actions leading to as many outcomes.
You can analyze what happened, but it’s foolish to say “this was better because the alternative would have led to”. You can only analyze and discuss what happened, otherwise anything can be justified with “it wouldn’t have been worse”.
“this genocide was good, because without it the oppressed population would have led to civil war and many more deaths”.
I complain about people who support Soviet-style dictatorships having full control over online platforms moderating exactly as one would expect
I will ask in good faith: given that those people started the whole project to have that space, but built it using federated technologies which allow others to run their places, what is exactly the basis for your complaint? As absurd as they might be, instances can decide their own moderation policies, whether you or I agree with them or not. Given the fundamentally distributed nature of this platform, there is no such thing as “having full control”, and instead we can choose instances based on our preferences, so we are free to not subject ourselves to those policies, they are free to do, and both a free to use the platform in the way we use. The code is open, there are plenty of other instances. What exactly is the complaint here?
I am not proposing anything actually, I am implying that this change won’t modify the threat model in any substantial way. Your comment implied that it kind of did, requiring root access - which is a slightly different tm, not so much on single user machines…
So my point is that “The data is safe until your user password is safe” is a very tiny change compared to “your data is safe until your device is safe”. There are tons of ways to get the password once you have local access, and what I strongly disagree with is that it requires more work or risk. A sudo fake prompt requires a 10-lines bash script since you control the shell configuration, for example. And you don’t even need to phish, you can simply create a SUID shell and use “sudo chmod +s shell” to any local configuration or script where the user runs a sudo command, and you are root, or you dump the keyring or…etc. Likewise, 99.9% of the users don’t run integrity monitoring tools, or monitor and restrict egress access, so these attacks simply won’t be noticed.
So what I am saying is that an encrypted storage is better than a plaintext storage for the key, but if this requires substantial energies from the devs that could have been put on work that substantially improved the security posture, it is a net negative in terms of security (I don’t know if it is the case), and that nobody after this change should feel secure about their signal data in case their device would be compromised.