Disappearing messages for Signal(whispersystems.org)
whispersystems.org
Disappearing messages for Signal
https://whispersystems.org/blog/disappearing-messages/
186 comments
It'd also be nice if the iOS or Chrome client had a chat history backup feature like they have on android. This is one of my biggest complaint with messaging apps in general. I'd like to be able to preserve and archive my chat history with people close to me.
What if the person you're chatting with does not want it archived? (I'm not questioning, but wondering what a protocol would be)
Suppose that you are chatting to me. You don't want your messages archived in any way.
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 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.
This is also why Data Loss Prevention software is truly useless in an employee environment. Sure it can spot you forwarding email, but I can take a picture of the email with my phone.
You can't trust the client. It's the same fundamental flaw with DRM. If that person does not want it archived, you can make it difficult but not impossible.
I don't think it's nearly as difficult as DRM.
That feature is mostly a gimmick. A lot like Snapchat's.
This might help with security if it takes as long to crack someone's phone as it takes to expire the messages.
This might help with security if it takes as long to crack someone's phone as it takes to expire the messages.
Actually, I can get the source code for the client, delete the "auto expire" feature and compile it. So there's nothing stopping anyone from archiving messages you want them to be able to read.
This issue is one of those that make it very difficult to build a single "secure chat" app that does everything for everyone.
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.
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.
Doesn't downsampling have the affect of preventing the use of more popular stego apps? Makes me wonder if there's something hidden in 25519. According to recent publications, it's easy to create backdoored primes fashioned to simplify search methods. Although those were for SNFS and DH, there are likely applications for searching the ECDH space.
I know this is apple level 'file a radar', but you should also ping about this in the github issues page.
Signal keeps getting better with each release, great job at everyone from Whisper Systems.
I love using Signal and will continue to make modest donations, but I would really appreciate an improvement in audio call quality. I still use Silent Circle for calls because it is so tiring to talk when the bitrate is low.
> I still use Silent Circle for calls because it is so tiring to talk when the bitrate is low.
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.
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.
Having used all the encrypted call possibilities there are , you are, in my opinion, absolutely spot on. SC has exceptional clarity. WA isn't bad.
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.
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.
As far as I know (and I'm not really very high up in the hierarchy, nor do I know much about the Blackphone hardware), the NSA and CIA are buying them because they are secure. I heard they had a list of phones/apps they are allowed to use internally, and SC was pretty much the only app that made the list at the time.
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.
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.
Wire's audio quality is quite good, even on cellular and/or VPN. Haven't compared with Silent Circle.
I have to agree. Privacy is a right. It's not often you run into a free alternative that offer sync capabilities across all platforms and devices. You also have a way to restrict or remove access from unknown fingerprints. The only downside I see about Wire is that the option to "submit crash reports and usage data" is enabled by default but that's just an Advanced options visit away from disabling. Give Wire a try and give their white papers covering how they approach [1] privacy and [2] security a read.
[1] https://wire.com/resource/Wire%20Privacy%20Whitepaper/downlo... [2] https://wire.com/resource/Wire%20Security%20Whitepaper/downl...
[1] https://wire.com/resource/Wire%20Privacy%20Whitepaper/downlo... [2] https://wire.com/resource/Wire%20Security%20Whitepaper/downl...
Oh, I'll give that a go, thanks! I should try Signal again too, hopefully audio quality has improved from the Redphone days.
Yeh it definitely has come on a lot since then
Can you provide some details as to what SC does differently?
I'm a web developer, so I don't really know much, but I know it has to do with our SIP guys losing their minds if the echo canceller is a bit too aggressive on a specific device. They're just very detailed-oriented and want things to be perfect. I swear, one of them is a bat, he can tell I switched phones just because the mic sounds different.
I'd guess both SC and WhatsApp use opus, whereas Signal at the moment is using speex. There is an issue open at github, but it does not seem to be a priority.
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.
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.
I've never noticed a quality issue... because I've never had a call connect at all (to be fair, it's been a while since I accidentally clicked the "call" button and checked, since I've long given up on trying to use it deliberately).
Agreed. WhatsApp calls are near flawless when connections are good, I'm sure WS can reach audio quality parity.
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.
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.
Did FB/WA clarify that they use the OW audio encryption algos, or did they just put the OW 'trophy' on the wall without the actual implementation?
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 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.
Looking at WhatsApps security whitepaper:
"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)
"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)
SRTP and ZRTP is only for negotiating what to use. You can still use different codecs. I'd guess Wire, WA and SC use opus (since it is by far the best), while signal is still using speex.
ZRTP makes negotiation possible, so a roll-out of opus should be possible without breaking older clients.
ZRTP makes negotiation possible, so a roll-out of opus should be possible without breaking older clients.
Unless this is some non-standard variant, ZRTP only negotiates a key exchange for use when encrypting the audio packets (the 'S' in 'SRTP'). Neither of those protocols has anything to do with codec selection, which is done via a SDP sent over SIP, or some other signaling protocol.
Sorry. I should just shut up about things I don't know much about. I thought the rtp part did negotiation, since they specify a "payload type" field and remembered the zrtp config in jitsi where you can specify codecs, and jumped to conclusions.
The payload type field ends up just letting you do stuff like send RTP events (like DTMF tones) over RTP by sending a different payload type that the other end can interpret in a different way than as being part of your main audio stream. Either way tho, all the payload types that you should expect to see over the channel should be negotiated beforehand, using another protocol.
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.
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.
Forgive me for being a layman in these matters
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.
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.
Over the past year, we've been progressively rolling out Signal Protocol support for all WhatsApp communication across all WhatsApp clients. This includes chats, group chats, attachments, voice notes, and voice calls across Android, iPhone, Windows Phone, Nokia S40, Nokia S60, Blackberry, and BB10.
https://www.whispersystems.org/blog/whatsapp-complete/
https://www.whispersystems.org/blog/whatsapp-complete/
My Signal phone audio issues went away after I upgraded hardware. Not a great solution (obviously) but something worth noting.
that's interesting. I'm running a 2 year old Xperia Z3 and it never occurred to me that my CPU might be the issue, but SC seems to handle audio quality just fine
edit - what did you upgrade to/from?
edit - what did you upgrade to/from?
LG G2 to a Nexus 5X.
> Hexadecimal isn't compatible with all alphabets, so it left a lot of people out.
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.
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.
How to donate to Signal!
http://support.whispersystems.org/hc/en-us/articles/21294015...
http://support.whispersystems.org/hc/en-us/articles/21294015...
I'm not sure that this is a benefit. It gives users a false sense of security. Screenshots or pictures can always be taken on the other end.
Didn't signal used to be explicitly against this feature.
Didn't signal used to be explicitly against this feature.
"Disappearing messages are a way for you and your friends to keep your message history tidy. They are a collaborative feature for conversations where all participants want to automate minimalist data hygiene, not for situations where your contact is your adversary — after all, if someone who receives a disappearing message really wants a record of it, they can always use another camera to take a photo of the screen before the message disappears."
This should be strictly a recipient controlled option, only affecting the recipient's view then. Anything else is still a misleading UX for the sender, and assumes people read the fine print. They don't.
This is horrible logic and ignores important opt-in/opt-out dynamics which are critical to our conception of privacy. By enabling "self-destruct," (or "disappear") the sender merely forces the recipient to "opt-in" and take affirmative action in order to archive the message (i.e. Screenshot). This is how telephone conversations generally work -- no recording unless one party takes action to tape it. Despite this ability to tape, we certainly still consider telephone to be more "secure" due to this archival distinction. Very often it is the advice of lawyers to avoid putting something in writing, and communicate it in person or over the phone instead. Disappearing messages brings us closer to this desirable ephermerality.
If you want a recipient controlled option that already exists as you can set the number of messages you want to save before old ones are deleted.
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.
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.
It's very simple. In the same feature as pruning old messages by count, add by time. Allow this on a per-conversation level. Done.
If their sense is that -- after configuring 1 week self destruct, the people they're talking to likely won't be keeping months and months of chat logs on their phone anymore -- it's a very true sense of security.
At least until the Jailbreak tweak is released with patches out this feature, allowing people to retain everything they want.
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 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.
There's no need to jailbreak anything. The code for the client is open source; you merely have to remove the code that obeys the remote request to delete, and rebuild and reinstall.
Yeah: I kind of want to release such a hack just to make the point (even though I do not use this program nor do I know anyone else who does). This is simply lying to users :/.
[deleted]
[deleted]
What good is a seatbelt if the person sitting next to you can stab you? The blog post makes a point of this not being secure if the person you're messaging is malicious and that's not what it's for.
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-...
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-...
Yes, this is a very insightful comment, and I think it should have been mentioned in the blog post. Many people don't use security passwords on their phones, and people can also be coerced into providing that information. Providing the option for automatically expired messages is a nice redundancy measure.
Great job on the app! It's one of the few apps I use every day.
Great job on the app! It's one of the few apps I use every day.
> 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.
Relying on this user to not have disabled your self-destructing messages seems like a really dumb move.
Relying on this user to not have disabled your self-destructing messages seems like a really dumb move.
With all due respect, Open Whisper Systems might ought first consider fixing Signal's multiplicate message problem, especially silent (to the sender) group chat spamming.
Actually, my biggest "bug" is where the recipient uninstalls or switches to a new phone and Signal allows you to keep sending messages to what amounts to the ether before you finally realize that they aren't getting the messages.
As a Signal user, I've experienced this issue as well. I work around it by deleting the message, then re-sending it, but that's clunky.
I don't think that's the problem that jpt4 is talking about. I believe he is talking about how sometimes a group message will be received 20 times or more, and yet the sender will still see "message not sent" for some recipients.
That is the issue I'm referring to.
How does re-sending the message help? Everybody in the group has already received the message a dozen times or more.
It doesn't but the sender does not know that everybody has the message a dozen times so he resends it.
That's the only big complaint I've got about Signal.
>multiplicate
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?
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?
There's something weird about that marketing angle coming from a dictionary; it seems somehow at odds with the notion of completeness that we associate with reference materials. Like "there are secret words that only paying customers get to know about", or something?
Less- and more-comprehensive versions of dictionaries is a long-standing thing. And you've usually had to pay for all of them—I think it's weirder that you'd expect to have a fully-complete version of something that takes a lot of expert knowledge and time to put together for free.
It's interesting to think about it this way. I do have dictionaries of different sizes that I've paid for, yet somehow the differences between them didn't strike me the same way this marketing campaign does.
With an abridged dictionary, there's no notice when it omits information. The web site's presentation makes it very clear that you're missing out on the full experience, and the tone seems a little like the company's holding the information "hostage". The realities haven't changed, but perception changes along with the presentation.
Good point, the internet does make the upsell much much much more in-your-face.
It's more than that; I'm old enough to have carried a compact Spanish-English dictionary while traveling. An unabridged dictionary was heavy enough that you couldn't hold it in one hand.
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.
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.
They still vary greatly in quality and (accordingly) price.I have several chinese/english dictionaries installed through Pleco (on my phone). With a couple exceptions, they're not free.
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]".
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]".
I remember the complete Oxford dictionary in my school library because it stretched over many large volumes. Forget holding it, you need a trolley!
More expensive unabridged dictionaries and less exepensive abridged veraions have been the norm for nearly as long as commercially published dictionaries have been a thing. That one of the cheaper abridged ones is now free on the web doesn't really change that.
To the best of my knowledge, I've never heard the word "multiplicate" either, and I wouldn't have been surprised if there were no dictionary entry for it at all.
If you know the word "duplicate", though, you should be able to figure this one out.
If you know the word "duplicate", though, you should be able to figure this one out.
I'm not sure I like the UX for the disappearing messages. Having a little hourglass after every message breaks the flow up. I'd rather see the message bubbles be black instead of blue.
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...
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 was thinking that too.
I actually want my messages to just be deleted every month, but w.e. I'll take it.
I actually want my messages to just be deleted every month, but w.e. I'll take it.
Everytime there is an update, I become more emboldened to continue to push my friends from whatsapp to Signal.
I just wish we had way to see what's going on in their server.
I just wish we had way to see what's going on in their server.
The fact that their phone server isn't free makes me somewhat more concerned as time goes on. I used to think it was just because they were busy, then I thought maybe they just wanted more time to refine things, but now it's been nearly two years since they released the current re-vamped Signal 2.0 for iOS and over a year since releasing Signal for Android. At this point I'm running out of justifications for them for why their phone server is still proprietary & closed source.
I keep thinking about this concept of a "glass 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.
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.
Hmm that's an interesting idea. I'm assuming their phone server is Java, same as their text server, so the builds should theoretically be identically reproducible for both. It seems like it should be possible to include a field in each response with some sort of signature so users can verify which build is serving requests. It'd have to be in every response so that they can't just reverse-proxy /status to the valid build and serve other requests from a modified build, and it'd have to be somehow dependent on some changing external factor or input so they can't just hard-code the valid build's signature.
Now if they would drop the ridiculous requirement of having a phone number and go with usernames and not require access to my contact list like most other services, you could actually be safer and not rely on _their word_ alone.
The app is open source and you could do something like a proxy or similar if you really want to be sure of what get sent from your client. The server is also open source too.
As moxie said, it's about raising the defaults of the world, not about making it secure for the crypto nerd.
As moxie said, it's about raising the defaults of the world, not about making it secure for the crypto nerd.
> 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.
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.
With the approach that Signal has taken, it doesn't require you to register a username. The app just registers you with the server as a Signal user using your already unique ID - your phone number. While not the most secure and privacy-protecting method, it allows anyone to just install it and start using it as a secure alternative to plaintext SMS.
Regarding SMS - it's not always an alternative to SMS since it uses data. I know data is more popular than SMS in many countries, but when you hit your monthly limit, you want to disable all data.
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.
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.
> when you hit your monthly limit, you want to disable all data.
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).
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).
Yes, I should clarify what I mean as an alternative to SMS. The experience on Android is quite nice as it will replace your default SMS app and will work similar to Messages on iOS where it will send using data via Signal if the other user is a Signal user or fallback to SMS if they aren't a SMS user. Unfortunately it's not as nice on iOS since Apple apparently doesn't allow Messages to be replaced as the default SMS app.
Furthermore, if you are registered with username+ password, I think you will want to have a password recovery method as well, so you're back to giving a phone number or an email address to the server.
Indeed. It's not just crypto nerds would want to use the service without having to have a smartphone with a phone number.
The phone requirement is beyond ridiculous. How did Signal get the reputation it enjoys in the tech community anyway?
The phone requirement is beyond ridiculous. How did Signal get the reputation it enjoys in the tech community anyway?
> 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:
https://whispersystems.org
You can thank Edward Snowden for that. In fact, they have his picture and testimonial on their front page:
https://whispersystems.org
moxie, the founder of OWS, was already well-known before Snowden. SSLstrip, for example: https://moxie.org/software/sslstrip/ and this DEFCON talk where he presents multiple attacks on cert validation: https://youtube.com/watch?v=ibF36Yyeehw
Wire (http://wire.com) does not need a phone number (register with email on a desktop browser at http://app.wire.com, then login to mobile) and does not need a copy of your contacts. Supports text, image, files, audio, video. E2E encryption is based on Signal protocol. Funded by Skype founder.
Wire does not use Signal Protocol, they used some of our code to create a protocol of their own devising that we do not recommend.
Interesting. Which code of yours are they using now?
After the last flare up on Twitter, I thought they wrote their own implementation, using the Signal code as a reference.
After the last flare up on Twitter, I thought they wrote their own implementation, using the Signal code as a reference.
Why do you not recommend? Hopefully you're not just saying that because they aren't Signal..
------------------------------------------------
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.
------------------------------------------------
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.
Correct, built with Electron like our Windows and macOS apps. Glad you're enjoying it.
Possible reason: https://medium.com/@wireapp/axolotl-and-proteus-788519b186a7...
Possible reason: https://medium.com/@wireapp/axolotl-and-proteus-788519b186a7...
What are their protocol's shortcomings?
I almost installed Wire this afternoon. Unfortunately this part
> does not need a copy of your contacts
is not quite correct if you read the fine print.
From https://wire.com/legal/
> 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.
> does not need a copy of your contacts
is not quite correct if you read the fine print.
From https://wire.com/legal/
> 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.
That's completely optional and not the default. It does what it says, makes known users easier to find,but you can still search for them without that.
This is either new or wrong.
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.
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.
There'a a on/off switch to share contacts under Wire Settings/Options and it's off by default at installation, (it was at the end of August when I started using the service).
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.
[1] https://wire.com/privacy/
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.
[1] https://wire.com/privacy/
Interesting. That implies that they changed that behavior in less than a month after I opened a ticket, which is actually very nice to read.
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.
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.
> There'a a on/off switch to share contacts under Wire Settings/Options and it's off by default at installation, (it was at the end of August when I started using the service).
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.
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.
Wire uploads your contacts to their service by default (on Android before M, because you nodded at the installation or something). No post installation popup asking you if you want to share them. (August 2016)
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.
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 use Apple iOS, where the operating system allows users to default deny contact access to all apps, with explicit whitelisting from Settings. Wire worked perfectly without access to my contacts on iOS. Signal refused to work without contact access, when iOS prevented Signal from accessing contacts.
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.
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.
And Wire is multi-platform with multi-device sync (like Telegram, except that on Wire all messages are E2E encrypted, not just secret chats), which Signal does not provide in a similar way.
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.
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.
What's a trustworthy alternative?
Wire [1], which I've been trying for the past few months, seems so. It's quite rich in its feature set compared to Signal, all messages are E2E encrypted and provides multi-device sync and multi-platform support.
[1]: https://wire.com
[1]: https://wire.com
If you really want to be secure, get a disposable prepaid phone and use its phone number with signal.
That is increasingly hard to do these days. Verified addresses etc are now minimum requirements to get the handset.
Of course you can pay cash and make up an address
Of course you can pay cash and make up an address
Where I live they make a copy of your ID when you buy a SIM. So you'll also need a fake ID. And then there will be a copy of your fake ID with a photo of you on file somewhere, which could lead to some issues if the authorities discover you used a fake ID.
Where I live (USA), it's as simple as walking into a Walmart, pulling a plastic encased kit off the shelf and paying for cash.
No muss, no fuss. Just activate it at the on-prem McDonalds and you're golden*.
No muss, no fuss. Just activate it at the on-prem McDonalds and you're golden*.
What's more bothersome: If you withdraw access (after they've already scanned your contacts) they'll disable the app. That's why I deleted the app and won't use it again.
If a privacy-focused app makes you nervous about privacy they've already lost the war, haven't they?
If a privacy-focused app makes you nervous about privacy they've already lost the war, haven't they?
Seems reasonable that an app that's used for messaging my contacts has access to my contacts. What exactly are you nervous about?
Only a small subset of people will be messaged with the app, it does not need access to the entire address book.
They have explained what the permission is needed for http://support.whispersystems.org/hc/en-us/articles/21253585...
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?
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'm not the poster who you replied to, but - Just because someone explains their reasoning, doesn't mean you have to agree with them :)
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.
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.
For those who do not understand the economic incentives associated with social graphs, have a chat with Facebook, LinkedIn and Palantir. Or read about the reasons why mobile platforms were forced to implement access control policy for contacts, after apps began bulk-uploading valuable social graph data.
They (OWS) were recently subpoena'd for someone's data and all they could provide where rough timestamps when that user registered and when they last contacted the servers. Unless you think they're lying in response to a subpoena (which would be very serious from a legal perspective), then they really don't store that data.
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).
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).
I don't understand why it still doesn't support landscape mode on iPhone.
It's on the roadmap https://github.com/WhisperSystems/Signal-iOS/issues/937 The iOS version didn't have a dev for a while after Frederic Jacobs went to Apple, but Michael Kirk recently took over so things are happening again.
Great. One of the most requested features is finally here. I think all that's left now is video calling (on the desktop, too).
I would like to be able to re-register a new number without having to de-activate the account thereby not losing all of my chats.
Is there a way from preventing certain contacts from knowing I'm on Signal? Like, it is embarrassing that Jason from college knows I'm on Signal. I know you guys will disagree and say it is not embarrassing, but it seems that a privacy-focused app would respect this notion. Obviously being a member of certain apps (grindr) can be seen as negative. I think I should be able to Whitelist my contacts.
This is a feature I would like not only in Signal, but also in platforms like Telegram and Wire. There are several valid reasons not to announce one's presence on a messaging platform to everyone who somehow has your phone number or address.
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.
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.
I don't disagree with your general point, but I'm curious, why would having a privacy-focused app be embarassing? I'm curious what kind of attitude you have for it, or what you expect some of your contacts to think of it.
Because it makes me look like a drug dealer. Which is to say it is easy for me to guess why most the people in my contacts who use Signal, use Signal. Some are journalists. Some are tech researchers. The guys with bad jobs who aren't good at computers make me wonder...
Sounds like the image we should move away from, so it gets better for everyone. While I don't disagree with your previous point, I think part of the reason for OWS to do this might be to nudge people like you towards this being mainstream, instead of okay, so why is this guy using this?
Many of my contacts use Signal because some computery person that wants to talk to them kept telling them to use it. They're not techy themselves, but it's not suspicious at all in my opinion.
Is there a way to export chart history and then import it to the new account?
> Is there a way to export chart history and then import it to the new account?
Another feature that I would like to see (Chat backup and restore). If it's there, I can't find it.
Another feature that I would like to see (Chat backup and restore). If it's there, I can't find it.
This comment says it's unavailable on iOS and Chrome, but there on Android:
https://news.ycombinator.com/item?id=12689695
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.
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.
Cool feature, though it'd be nice if Signal fixed the message delay and message dropping problem. But Signal uses the proprietary GCM service (because "it's impossible to do message sending correctly, so let's force people to use proprietary software") so they probably can't fix it...
No one is forcing you to use proprietary software. See this comment from moxie
https://news.ycombinator.com/item?id=10665520
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.
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.
Actually, Moxie has threatened to shut LibreSignal down if they allow LibreSignal users to message normal Signal users, and refused to even discuss alternative solutions.
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.
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.
Could it be because some of your information is spun/misleading?
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...
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...
> LibreSignal was abandoned according to their github, first of all.
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.
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.
You're cherry-picking the bits of Jarwain's response that you like to respond to, ignoring the others, yet complain about the discussion culture and being down-voted (which is not appreciated on here) in your original post.
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).
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).
Forking and using your own servers is exactly one of the things about XMPP Moxie hated si much that he created Signal in the first place!
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)).
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)).
> Moxie has threatened to shut LibreSignal down if they allow LibreSignal users to message normal Signal users, and refused to even discuss alternative solutions.
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?
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?
> Please cite this.
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.
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.
> 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?
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.
https://news.ycombinator.com/item?id=12689352
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.
https://news.ycombinator.com/item?id=12689352
Also, regarding
> 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.
> 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.
> 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.
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.
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.
> 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.
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.
> 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.
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?
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?
topkeks(1)
Downvoting this comment without offering a counterpoint is very bad etiquette. Can someone provide a counterargument? Otherwise it's just pretty much censorship.
I do not think "censorship" means what you think it means. Censorship would be moderators deleting something. Making claims without citations is fully in play to downvote.
I guess you're right about the censorship part, but still, just downvoting comments without replying is not useful to anyone. The comments above that reply clarifying the situation are much more informative.
> 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.
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?
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?
I've been receiving a bunch of "Bad encrypted message..." lately. Wonder what's up with that.
Tons of those, plus repeats, and "random" delays. Sometimes it takes a few minutes for messages to go through (single check). Last week was really bad. I don't know how multiple messages can happen; shouldn't they have a unique ID?
> and "random" delays. Sometimes it takes a few minutes for messages to go through (single check).
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.
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.
Last week was due to server issues https://whispersystems.discoursehosting.net/t/intermittent-m...
I saw the mailing list post, then got the bad messages a day later. Probably the same issue, still curious about the technical details though.
Yeah. My understanding is the message key used to decrypt first copy should be immediately deleted after decrypting it, so how can the second copy be decrypted successfully? Seems to fly in the face of forward secrecy unless it's purely a client side bug.
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.
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.
> They're relatively compact. Users compare 12 groups of 5 digits with each other, which is half the size of our previous hexadecimal format.
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?
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?
No, since you presumably want to match a specific user's key, not just find two users with the same key.
It is a similar problem, however: https://en.wikipedia.org/wiki/Birthday_problem#Same_birthday...
That's still not the problem considered here. You're not asking "does anyone have the key I'm seeing here", you're asking "does this person next to me have the key I'm seeing here". No birthday paradoxes of any kind involved.
Forgive me, as I haven't used signal, but I don't see how whether they are sitting next to you or not changes the problem.
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.
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.
Right, sorry, I misunderstood. A preimage attack (that's the technical term for this) could indeed be modeled as a birthday problem with a fixed day ("someone with the same birthday as me"). This is much harder than finding a normal collision (two objects with the same hash, two people with the same birthday), though.
>reducing it to 98 bits?
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. :)
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. :)
No, hashes generally require twice as many bits in order to avoid birthday attacks — that's why one uses SHA-256 for 128-bit security.
98 bits is still plenty, of course, but it's not 128 bits.
98 bits is still plenty, of course, but it's not 128 bits.
If we're talking about the actual hash signal uses for this value, then sure, but talking about the number of digits displayed isn't even the right thing to care about, since they're using SHA1 for the hash AFAICT: https://github.com/WhisperSystems/Signal-Android/blob/3.0.0/...
SHA1? SHA1 SHA1‽ I'd always thought that OWS had incredibly good crypto — why are they using SHA1? If it's to support relatively short hashes … I just can't even.
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?
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?
SHA-1 is fine in this context. SHA-1 isn't as collision-resistant as it was once thought to be, but that's not a property that you care about for this use-case.
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 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.
[deleted]
How do they make money?
From wikipedia:
"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://en.wikipedia.org/wiki/Open_Whisper_Systems
"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://en.wikipedia.org/wiki/Open_Whisper_Systems
Why isn't this on their site?
... this is just thinking out loud, not directed at you.
If you want to implement the signal protocol for your own company (see WhatsApp, Messenger, Allo, ...) you will probably have to buy a license ($$$), and ask for their help ($$).
* https://whispersystems.org/blog/whatsapp-complete/
* https://whispersystems.org/blog/allo/
* https://whispersystems.org/blog/facebook-messenger/
* https://whispersystems.org/blog/whatsapp-complete/
* https://whispersystems.org/blog/allo/
* https://whispersystems.org/blog/facebook-messenger/
[deleted]
Who exactly uses Signal? Why do you think it's secure?
Edward Snowden, Bruce Schneier, Matt Green and a few more. I think it's secure because it's been audited, because I trust the experts who say that it is secure, because of http://support.whispersystems.org/hc/en-us/articles/21247776... and because of https://whispersystems.org/bigbrother/
SIgnal is basically getting the full feature set of TigerText.
I had an idea a few days ago where you authenticate your identity (i.e. numeric fingerprint) on-demand by sending a pic of yourself where the QR code is overlayed as blacked-out pixels before being transmitted. Then the recipient can look at the photo to see it hasn't been manipulated, and use the app to verify the QR codes match.
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.
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.
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.