Disappearing messages for Signal
whispersystems.org
whispersystems.org
1. Images are downsampled without warning. There should be some sort of warning or mini info box for the times when the images are downsampled and there should be information about the changes in resolution.
2. If one uses it as the main messaging app, one has to search through history sometimes. But there is no chat search feature. I am forced to scroll all the way up and copy the message data to an editor. Even really basic case insensitive search would be great.
Personally, I want an automatic, encrypted network backup of all my messages so I don't lose them if my device is lost or destroyed. But I know lots of folks around here are excited about the automatic delete thing too. It's going to be very hard to make something that all of us can be happy with.
This might help with security if it takes as long to crack someone's phone as it takes to expire the messages.
I really want to keep records, so I have a second device, and take a picture of the screen every time I get a message of you.
There is no software or protocol that can entirely eliminate this human problem. The two parties have to have some level of agreement and trust.
I often get disconnected on Signal after 20 minutes or so on a voice call, but I suspect that's due to the other end being behind a VPN with awful latency.
WhatsApp is, I agree, very good quality for what it is, but I would never trust it or FB with anything but social/personal calls. Social Media platforms are for other people to hand over their lives to. Let them subsidize my detachment from their usage, and I thank them for it. I'm sure there will come a day where you can't use WA without a FB account, at which point it is dead to me and my social contacts will be the first to know about it via WA.
"WhatsApp calls are also end-to-end encrypted When a WhatsApp user initiates a call: 1 The initiator builds an encrypted session with the recipient (as outlined in Section Initiating Session Setup), if one does not already exist 2 The initiator generates a random 32-byte SRTp master secret 3 The initiator transmits an encrypted message to the recipient that signals an incoming call, and contains the SRTp master secret 4 If the responder answers the call, a SRTp encrypted call ensues"
From wikipedia:
"Signal voice calls are encrypted with SRTP and the ZRTP key-agreement protocol, which was developed by Phil Zimmermann.[1][57]"
So from where I'm reading they seem to be doing more or less the same thing when it comes to encrypting voice calls.
https://www.whatsapp.com/security/WhatsApp-Security-Whitepap... https://en.wikipedia.org/wiki/Signal_(software)
Are you saying "maybe/maybe not"?
If they seem to be doing something that is "more or less" the same then my radar is triggered for them not actually declaring they are delivering totally encrypted (ie no backdoor tomfoolery) voice calls.
ZRTP makes negotiation possible, so a roll-out of opus should be possible without breaking older clients.
But no worries... there are a ton of moving parts in these protocols, and even though I've been working with them for a while, I still tend to forget details here and there, too.
edit - what did you upgrade to/from?
To be fair, that's a high bar. Our (SC) phone guys are masters at optimizing audio quality. I would be extremely surprised if any other app (encrypted or not) had significantly better audio quality than Silent Phone.
[1] https://wire.com/resource/Wire%20Privacy%20Whitepaper/downlo... [2] https://wire.com/resource/Wire%20Security%20Whitepaper/downl...
Can you talk more about "our guys" in respect to the fact that the CIA and NSA use the Blackphone? Should I, as a casual business person, be wondering that the handsets you supply to them are in some way compromised? I know that both the NSA and the CIA are interested in my phone conversations, which is why I ironically bought a Blackphone (for when I assume they are listening) and others which make their life harder (but I do accept that I do this more for the kicks of making them work for their intel)
tl:dr - is SC actually secure given that the company has been short on cash for a while and that the CIA and NSA equip their agents with the same phones. I don't mind talking because I have nothing to hide, but backdoor code is usually the case if you are selling 10k phone units to US LE.
Keep in mind that "an organization using a secure app" and "an organization wanting to spy on people" are pretty independent goals. I haven't poked around in the client source too much (although I have implemented some stuff for the Android client), but:
1) Nothing in the client seemed out of place. 2) I've seen every line of code running on the web backend and there's nothing untoward going on. 3) Given the culture, I think many of the high-level people would quit before they compromised the product. Especially Phil, who has been sued by the US government for exporting strong cryptography before.
I haven't read very much about it, but there seems to be concerns about opus leaking data about the call. I don't know how, but from android5.0 there is an opus encoder included that supports CBR mode.
Not ... really. Latin characters are available in every locale. Virtually anyone literate enough to use signal is going to distinguish the latin letters A through F. You reading this, I'm assuming you're not literate in Greek, but can you distinguish the letters α, β, γ, and δ, even if you cannot name them? Don't bring up CJK; virtually no one in this day and age is functionally literate in any CJK language that can't read the Latin alphabet.
Let's take the hypothetical person literate in another script who is completely unfamiliar with the letters ABCDEF. They don't use our arabic numerals either. If you need to localize arabic numerals, why on earth couldn't you localize hexadecimal, too?
Obviously, hexadecimal is not friendly to the layperson as a means of representing numeric quantities. But neither is comparing two 60 decimal digit numbers as a means of authentication. I don't think it's inherently easier for a layperson to match 60 decimal digits versus 50 hexadecimal digits.
http://support.whispersystems.org/hc/en-us/articles/21294015...
Didn't signal used to be explicitly against this feature.
Not deleting the messages from the senders view just to teach users a lesson about security doesn't make any sense and would just confuse people. Showing a warning about it still being possible to take a picture of the phone with another camera would make more sense but seems a bit silly.
I think these two comments make good points:
I just had an interesting conversation with a friend who was recommending that I use Telegram/Wickr, and I told him that Signal was where it's at. Then he asked me if it had self-destructing messages, and I said "Why bother? That can be easily circumvented". His reply was that in some countries phones had been confiscated, and even though one person had enabled local encryption, the user with the confiscated phone had not enabled it; thereby implicating everyone who had communicated with that person (even though the messages were delivered secure over the network). So while self-destructing messages are in many ways a flawed guarantee of privacy, they can perform a very useful function in cases where the users are not malicious, but rather are security ignorant (i.e. most people with a phone).
https://whispersystems.discoursehosting.net/t/automatically-...
I've always been thinking that the critique of such a feature is based on a false underlying premise.
Yes, it's true that the recipient can make a screenshot of the message. But the recipient in the absolute majority of cases is not a "threat" in a classical sense, not someone with bad intentions or someone who is not supposed to know the contents of that message. After all, the sender trusts the recipient, as he is the one sending the message to the recipient in the first place.
The usual scenario is a recipient who is not that security-aware and doesn't think about those things that much if at all. Personally, I'd say most of my contact are that way.
The sender might send this recipient a message containing something especially critical, say, a user name and a corresponding password, and doesn't want to see that information in the wrong hands if e. g. later on, the recipient loses their phone, the phone gets stolen, etc. Also note that this kind of recipient is unlikely to use a general passphrase for Signal as this lessens convenience.
So what's essentially happening here is a security-minded sender taking security measures for or in place of a thrustworthy, albeit forgetful, non-security-minded, etc recipient.
https://whispersystems.discoursehosting.net/t/automatically-...
Great job on the app! It's one of the few apps I use every day.
Relying on this user to not have disabled your self-destructing messages seems like a really dumb move.
I don't disagree that it works for the average user, but I do agree with the sentiment that it is a false sense of security.
Unless maybe you cryptographically verify the deletion (is that possible?) and notify the other party of the successful deletion. But even then a copy could be made beforehand, on-device or with an external camera...
I think it's much better to maintain zero expectation of message destruction with all end users.
I'd never heard this word so I looked it up. Google didn't have a definition but merriam-webster was the first result. They showed me an extra concise definition and then this message...
>Wait, there’s more! This word doesn't usually appear in our free dictionary, but we’ve shared just a bit of the information that appears in our premium Unabridged Dictionary. There’s more definition detail there. Start your FREE Trial Now!
Umm.. Fuck you Merriam-Webster?
In other words, there used to be such a thing as 'too much dictionary'. Now, like any other information source, it's the size of my phone, except when it's the size of my laptop.
When I was taking a formal class in Mandarin, some classmates complained, "the definitions you're getting from Pleco are so much better than ours! What are you doing differently?" They lost interest when I responded "I paid for the better dictionaries".
Different dictionaries have different strengths. CC-CEDICT has entries for standard Chinese versions of western names, and for slang. Then again, it doesn't even have usage examples. ABC has many, many entries, including stuff like technical terms in linguistics. Tuttle Learners' has very few entries (it's a learners' dictionary!), but it does nice things like provide antonyms and, where it might be helpful, character-by-character glosses. Tuttle has my favorite entry for 糟糕 [a mess/very bad/bad luck], headed by "[modif: 糟 messy + 糕 cake]".
If you know the word "duplicate", though, you should be able to figure this one out.
It's also not intuitive to tap on a recipient's name to enable disappearing messages.
Lastly, maybe messaging should default to 1 week disappearing messages...
I actually want my messages to just be deleted every month, but w.e. I'll take it.
I just wish we had way to see what's going on in their server.
They can run it, but allow developers to somehow see running processes, and write (rate-limited) queries to test things.
I haven't solidified this concept in my head but it seems like a step towards federation without the problems of federation.
As moxie said, it's about raising the defaults of the world, not about making it secure for the crypto nerd.
The thing is, the attacks in the "crypto-nerd paranoia" category tend to become everyday attacks over time. Pre-Snowden, most people would put a lot of the things the NSA is doing into the "crypto-nerd paranoia" bucket. Now we know they were wrong to do so.
Signal routes all conversation metadata through one infrastructure, which becomes a very tempting target. By also requiring phone numbers as identity, they make it very easy to tie that metadata to real people and perform graph analysis on it.
Regarding the simplicity of using a phone number and how it would be very easy for all users - Wickr provides basically the same service, is more popular, but uses usernames instead of phone numbers.
The fact that something is open source isn't always a clear win. OpenSSL, for example, is open source and yet they seem to have many bugs.
For the record, I use Signal almost exclusively for communication. I just wish it was more protective of users' privacy without having to put in a ton of effort.
This is country-specific. In Germany, any data usage exceeding your plan is free but terribly slow, usually 64kbit. That's good enough for messaging and checking email (and HN comments).
Of course you can pay cash and make up an address
No muss, no fuss. Just activate it at the on-prem McDonalds and you're golden*.
The phone requirement is beyond ridiculous. How did Signal get the reputation it enjoys in the tech community anyway?
You can thank Edward Snowden for that. In fact, they have his picture and testimonial on their front page:
[1]: https://wire.com
After the last flare up on Twitter, I thought they wrote their own implementation, using the Signal code as a reference.
------------------------------------------------
I've been using Wire for a few weeks now and I'm absolutely happy. They recently released a linux client https://medium.com/wire-news/get-your-linux-on-999403a1a4fe#... (not a chrome app!) (though I think it's electron).
I'm quite happy with them, give them a try.
Possible reason: https://medium.com/@wireapp/axolotl-and-proteus-788519b186a7...
> does not need a copy of your contacts
is not quite correct if you read the fine print.
> 5.1 Account ... You agree that if you give the App permission to access your address book, anonymized phone numbers and emails from the address book will be uploaded to the Service for the purpose of connecting users.
I just posted a sibling comment to the GP: At least in August it wasn't optional and happened automatically on Android, unless you were running M: The permissions requested during installation (contact access, to even have a way to offer this feature) of the app were exercised without asking for further consent and your contacts were shared with their server unconditionally.
Don't know though if the app asked for permission to access contacts like it should, since I don't have any device with M.
This is from the Privacy whitepaper how they manage the data shared [1] :
> Address books are uploaded to backend servers if users grant client applications access to their contacts. Each address book entry is first normalized, i.e. phone numbers are ensured to be in E.164 form. Entries are then hashed (using SHA- 256) and base-64 encoded before being transmitted to the server. No other information, such as names, addresses, birthdates, notes, etc. are extracted from the address books. Address books are checked for changes every 24h by clients and changes are uploaded again. Uploaded address books are used to match users on Wire, i.e. to suggest new contacts and to automatically create connections between users (see section 2.2). The matching algorithm creates connections between users who have each others e-mail address or phone number in their address book.
Tried it on Pre-M and M, it worked correctly on M ("Wants to access your contacts" -> Denying didn't harm the app). For Pre-M it was as I described above: Opt-out (and worse, they have/had no way to remove contacts, at all) instead of opt-in.
I appreciate the update though - will look into Wire again these days.
Oh, thanks that's good to know. And impossible to find out without just installing the app.
> Entries are then hashed (using SHA- 256) and base-64 encoded before being transmitted to the server.
This signals that they care about privacy, but it doesn't really provide much protection against someone who wants to break it. Maybe it's just about keeping honest people honest. It would be very straightforward to dictionary attack the un-salted hash. Using a password cracking program like HashCat, you could probably recover most of the numbers in a few hours.
I still use Telegram for the most part, Wire for some, and Signal the least - this is mainly due to the user experience, feature set and speed of message delivery.
Wire has not even a way to remove contacts. I'm not kidding. After the faux pas above I had random 'Wire contacts' that it discovered for me, based on a combination of 'in my address book' and 'in their address book'. You cannot unfriend/remove those, at all. Talked to their support and they actually confirmed that (4th of August, doubt that it changed) you can only _block_ users.
Blocking != removing. If "random ex-coworker" comes up in my list, I might want to remove the contact without blocking the person. One's "Don't care about this contact" vs "This contact has no place in my life".
Bringing Wire up as a decent example for contact handling therefor seems .. strange.
I am sorry to hear about your Android experience, but I abandoned that platform long ago because of confusing management of per-app permissions, along with Google's penchant for data collection. Wire users on Android should try to get Wire developers to improve the control options on that platform, they usually respond within a few days to support requests.
I almost bought a separate iOS phone just to run Signal without access to contacts. Since Wire came along, that is no longer necessary and I can use Wire without a phone number.
If a privacy-focused app makes you nervous about privacy they've already lost the war, haven't they?
They have a privacy policy https://whispersystems.org/signal/privacy/
They have explained their reasoning https://whispersystems.org/blog/contact-discovery/
You have access to the source https://github.com/WhisperSystems
You have proof that they don't store your contacts and can't provide them even after a subpoena https://whispersystems.org/bigbrother/
Again, what exactly are you nervous about? What is gained by removing contact discovery?
I don't particularly want to send Signal a list of contacts - I'd rather not leak that information about my social graph. I understand how they want to use that information for discovery, so they can know who already uses the app.. But for my needs, this isn't necessary. I'd prefer to manually ask my friends for their username on the service.
If there were additional options, I might choose to use their service. As it is, it doesn't fit my needs, and that's OK.
I'm sure there's plenty of other people who appreciate it.
Of course it would be nice if we didn't have to trust them that this won't change in the future (whether through a court order or their decision doesn't really matter).
Another feature that I would like to see (Chat backup and restore). If it's there, I can't find it.
I can back up that Chrome point, unless it has been added in a recent update. On Android, it can do encrypted and plaintext backups - never tested, but I assume they include messages. What else.
Telegram allows using a username to mask sharing the phone number with new contacts, but its initial setup is based on the phone number and it insists on notifying everyone who has your number that you've joined the platform. Messaging platforms would be much better if they considered such things as privacy issues and provided more control in the user's hands, with sensible defaults and good initial setup instructions.
Using GCM is only a problem for people running a custom Android ROM without Google Play Services. Using GCM doesn't make Signal less private.
Google doesn't see any data via gcm, it's just a tickle. If you want push messages, you gotta use a push network.
https://twitter.com/whispersystems/status/695399112833761283
Feel free to help out with code https://github.com/LibreSignal/LibreSignal/issues/43 or money https://www.bountysource.com/issues/35722527-create-proper-p... if using Signal without GCM is important to you.
If the only thing that the remaining people here want out of LibreSignal is a websocket-only solution and gmscore isn't an option for whatever reason, I would consider a clean, well written, and well tested PR for websocket-only support in Signal. I expect it to have high battery consumption and an unreliable user experience, but would be fine with it if it comes with a warning and only runs in the absence of play services. However, I also realize that still won't help people that are trying to build a Google-free experience on Google's platform https://github.com/WhisperSystems/Signal-Android/issues/127 , since we still don't have the things we need https://github.com/WhisperSystems/Signal-Android/issues/127#... to be comfortable distributing software outside of Play.
https://github.com/LibreSignal/LibreSignal/issues/37#issueco...
Considering how a small minority complain about this everytime Signal is mentioned you'd think they'd do something about it, but take a look at that Bountysource link and you'll see 8 backers. Guess complaining is easier.
He also uses the GCM library from Google, which pulls in several analytics libraries into the APK, so "Using GCM doesn't make Signal less private." is objectively false.
(And in addition to that, Moxie even refuses to allow any distribution that doesn’t come with full analytics, which is extremely user hostile.)
> Guess complaining is easier.
No, it’s easier to use XMPP than to fix a system that’s broken by design like Signal.
EDIT: Seriously? Downvotes for criticising publicly documented user-hostile behaviour from Moxie? Fuck this, the discussion culture here really got worse than even Reddit.
LibreSignal was abandoned according to their github, first of all. Secondly, the issue is that OWS doesn't want "others" using the servers that they own and maintain for Signal.[1] As far as I understand, they disapprove of people using the name Signal or TextSecure or Redphone for their forks, due to confusion by users who believe that the fork is actually the app released by OWS. He doesn't explicitly say whether "LibreSignal" is okay, but would prefer for a namechange to reduce confusion.
Afaik, he also encourages people who don't like the GCM build in Signal to swap it out with the rewritten open source one and build with that.
[1]https://github.com/LibreSignal/LibreSignal/issues/37#issueco...
Yes, because Moxie threatened in the discussion you linked?
> Secondly, the issue is that OWS doesn't want "others" using the servers that they own and maintain for Signal
The issue is that Moxie refuses to federate, or allow others the right to develop third party apps interfacing with his server (Which, btw, he can’t prohibit in the EU anyway).
> Afaik, he also encourages people who don't like the GCM build in Signal to swap it out with the rewritten open source one and build with that.
Yet he threatens anyone trying to distribute an alternative build with it stripped out.
How the fuck is that open source development, if you threaten anyone forking it, and don’t allow any PRs that could make it more open, AND refuse to allow federation? That’s not any better than just using Facebook Messenger.
Moxie is taking issue with others using the name "Signal", as that would lead to confusion. Forking and using your own name and servers is totally okay with him.
And of course you can allow others from distributing apps that use your servers in the EU. There's a difference between using modified code with OWS servers (which might be okay in the EU, IANAL), and distributing apps that interface with OWS servers despite their demand that you do not (which is certainly not okay in the EU).
The whole point why Moxie created it is so that everyone is on the same one, to avoid federation issues.
> stributing apps that interface with OWS servers despite their demand that you do not (which is certainly not okay in the EU).
I'm not a lawyer, but:
EU law very specifically allows you to create software interfacing with third party software or services, even if they tell you not to do so, and you can even decompile their software to learn how to do that interfacing (compare §69d UrhG), as long as you don't have to break their ToS doing so. (Which I don't, the only ones possibly breaking the ToS would be the users, and there's also a legal argument that you can't prevent users from modifying the software they use to access your service (see the AdBlockPlus vs. BILD case, LG Hamburg)).
Please cite this. To my knowledge I never threatened anything, and your comment is a response to a quote from the discussion about LibreSignal, where I suggest that they submit a PR with the functionality they desire to Signal. Is that not an alternative?
> He also uses the GCM library from Google, which pulls in several analytics libraries into the APK
Could you cite this as well? Here's the entire POM file for the version of the GCM library we use:
<?xml version="1.0" encoding="UTF-8"?> <project xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd" xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <modelVersion>4.0.0</modelVersion> <groupId>com.google.android.gms</groupId> <artifactId>play-services-gcm</artifactId> <version>8.1.0</version> <packaging>aar</packaging> <dependencies> <dependency> <groupId>com.google.android.gms</groupId> <artifactId>play-services-base</artifactId> <version>8.1.0</version> <scope>compile</scope> <type>aar</type> </dependency> </dependencies> </project>
A single dependency. If you follow it, the only transitive dependency is the supportv4 library. Where are the "several" analytics libraries?
> (And in addition to that, Moxie even refuses to allow any distribution that doesn’t come with full analytics, which is extremely user hostile.)
What do you mean by "full analytics?" Is there something user hostile about having an aggregate count of the number of users you have on what platforms, so that you can develop and deploy software accordingly? About being able to receive crash reports when users choose to submit them so that you can fix their problems?
I’m sorry, what was this entire discussion then supposed to mean? https://github.com/LibreSignal/LibreSignal/issues/37#issueco...
If they can’t fork it while still using your servers, and you refuse to allow federation, how the FUCK is it open in any way?
How are users supposed to be able to verify the software running on their own systems when you only allow binaries compiled by yourself to communicate with your users, abusing the lock-in effect?
> Could you cite this as well?
Have you actually read the code that gets compiled in when you depend on play-services-base and play-services-gcm?
As I happen to have reversed all of it to write an open source library for GCM, I have. And let me tell you, most of the code in there is "measurement"-code.
> What do you mean by "full analytics?"
Distributing through any means where the user can get the app without being required to be fully tracked by the Google Play Services?
You only distribute through the Play Store, which doesn’t fully work with microG at the moment, requiring users to install spyware on their devices.
What makes you think you have a right to demand federation? Run your own server if you don't like how they're doing it. You have access to the source under a Free Software license https://github.com/WhisperSystems but of course you don't want to actually do any work, you want to complain about what other people do because they don't do it in the exact way you want it done for free.
> How are users supposed to be able to verify the software running on their own systems when you only allow binaries compiled by yourself to communicate with your users, abusing the lock-in effect?
https://whispersystems.org/blog/reproducible-android/
> You only distribute through the Play Store, which doesn’t fully work with microG at the moment, requiring users to install spyware on their devices.
Because Moxie claims he wants to change mainstream communication?
You don't revolutionise mainstream communication by fragmenting your user base even more.
If every fork did what Moxie suggested, and create a completely new network, then soon there will be only a handful of users per network at all.
And users will just go back to Facebook or WhatsApp.
The claimed aim of Moxie is that everyone uses the same, partially safe, chat system.
The only merit Signal has over XMPP is that it aims to be used by everyone, including your grandma, trading adoption vs safety.
If that is the aim, you have to ensure it also is 100% compatible.
If you directly suggest to fragment the userbase, you are destroying the one single merit Signal has over XMPP with OMEMO.
Because then it becomes just another protocol for crypto nerds (and a worse one, in fact, considering the inclusion of Google code).
So, explain to me, how is fragmenting the userbase in any way conductive to the claimed aim?
> but of course you don't want to actually do any work, you want to complain about what other people do because they don't do it in the exact way you want it done for free.
Nah, I don't spend months of my own free time maintaining an open source IRC app, and working on creating tools to make IRC easier for users to use.
I don't actually spend time making open chat systems more useable to users, sure.
That accusation from you doesn't belong at all on HN, and is not only a personal attack, but also wrong.
I could just run a Signal fork with my own servers tomorrow, but one of my goals is to allow users to have one single place where they can send a message to a user, and it will arrive. No matter what service the other user uses, what app, what chat system, if they're on an obscure 20 people IRC network, on Signal, WhatsApp, etc.
My ideal goal would be a universal, federated protocol, but even having libraries for each protocol with a unified API would make things already easier.
And Moxie is fighting for the opposite.
He fights against any compatibility, and suggests I tell my mother to install yet another chat app, ignoring that her phone can't even install Signal in the first place because it only has 3MB of useable memory, left.
You and Moxie actively tell people to create more, and less interconnected, chat networks.
How the fuck is that going to help?
If everyone uses a different secure app, that doesn't help at all! People will just use the systems everyone has (case in point: usage of SMS in the US, or WhatsApp everywhere else), and thereby you ensure no one gets any security.
So stop insulting people you don't know, and claiming untrue motives to be theirs, just so you can justify your actions.
And Moxie is fighting for the opposite.
Yet here you are, pissed off that your goals don't align with someone elses. Use your open source IRC app to talk to your mom and I'll use Signal to talk with mine. No one is forcing you to do anything. Considering your goals and ideas are superior surely whatever you're suggesting will become the one service everyone uses, problem solved.
That shows even more how much you misunderstand the entire market even worse than Google does.
An app can’t win because it is the best, but only through network lock-in effects (which Moxie tries to use for Signal, too) and marketing combined.
The issue is not privacy, it's the use of a proprietary service. Now, GsmCore from microG does solve the problem somewhat. But then you have to ask "where will you get the app from?". The answer is "not F-Droid because moxie doesn't like it". So you have three options for actually installing the app and keeping it up to date:
1. Use the Google Play Store (proprietary). 2. Build the app yourself and keep it up to date yourself (not fun and doesn't help anyone other than me). 3. Use an unofficial FDroid repo (or do step 2 and host the repo myself). This option means that you have some random administrator controlling updates. I actually agree with moxie that FDroid really should add developer signatures to packages (though IMO the desktop GNU/Linux model of package updates is actually fairly solid -- though you don't have the Open Build Service for android packages :P).
Overall, the choices are a shit-show. Now, I get that it isn't of concern to moxie what people like me have to do to get this to work with their phones. That's fine, I understand. But that doesn't mean that I'm not going to mention it if I get the chance -- because it does legitimately make things harder for me. I get that free software on phones isn't a big concern to many people, but it is to me.
> Considering how a small minority complain about this everytime Signal is mentioned you'd think they'd do something about it, but take a look at that Bountysource link and you'll see 8 backers. Guess complaining is easier.
I contribute (both code and money, and also as part of my day job) to many free software projects, but I refuse to contribute to a project which actively encourages the use of proprietary software in order to use it properly. I get that it makes things easier for users, but that doesn't make it right. So maybe you shouldn't be so condescending?
Bad encrypted message, if I recall correctly, means either the MAC check failed or the protobuf payload inside didn't deserialize correctly.
I don't know.. I'm not setup to debug it on my regular phone with a production signal apk installed.
This was the main reason I almost stopped using Signal several months ago and started trying out Wire (which is also slower when compared to Telegram). I find it disappointing that the problem still exists. I can't convince others in my circle to use it if basic message delivery is flakey and slow.
60 digits have 199 bits of security, so I suppose that's mostly okay, right? Does the birthday paradox apply here, reducing it to 98 bits?
If I can generate a key that hashes to the same value as your key, I can convince anyone I am you. If I can generate a second collision for a third party's key, I can convince you you are talking to that third party, as well. Generating hash collisions is, as I understand it, pretty well modelled with the birthday paradox (and variations like the one I linked). Physical proximity seems entirely unrelated.
Did you mean 198?
198 bits is entirely reasonable assuming a brute force attack is the only option. Were it not we'd be in a panic over AES-128 and AES-192. :)
98 bits is still plenty, of course, but it's not 128 bits.
There's simply no excuse to choose to use SHA1 in 2016. It's not completely broken, it's probably good enough, but why not just truncate SHA2?
The same principle applies to checksums that are sometimes published for binaries - many still use MD5 or SHA-1 - and that's fine too, as (second) preimage resistance is what counts here, rather than collision-resistance.
"The group is funded by a combination of donations and grants, and all of its products are published as free and open-source software."
* https://whispersystems.org/blog/whatsapp-complete/
Antox from the tox.im people is a better more secure and anonymous messaging application.
Ring.cx is also better.
I'm sure there are issues with this, but it seems like a nice feature for when secure out-of-band communication is not possible.