Video calls for Signal now in public beta
whispersystems.org
whispersystems.org
> But anyone testing the beta who links their iPhone to iCloud and wants the same level of privacy Signal has always offered should consider an extra step, too: Disabling a setting that uploads a call’s metadata to Apple. The beta upgrade to Signal will use CallKit, Apple’s framework for allowing VoIP calls like Signal’s, to be integrated more completely into the calling functionality of the phone. But that also means calls will be recorded in the iPhone’s call log and, for iCloud users, shared with Apple’s server. “iOS treats CallKit calls like any other call, however that also means some information will be synced to iCloud if enabled,” Open Whisper Systems warns. “This information includes who you called and how long you talked.”
https://www.wired.com/2017/02/encryption-app-signal-enables-...
Given the recent shift from data to metadata protection, which is the only justification for messaging centralization, this vulnerability effectively reduces security to almost zero.
I expect this is another case of UX/Security tradeoffs considerately made by OWS. Having native OS integration is nice, and probably the right answer for most users.
Signal isn't about being perfect (it's already made tons of concessions that make it useless to anyone "serious" about privacy). Instead, it helps raise the bar against bulk collections.
Bulk collection concerns the envelope, knowing who you spoke to and how long for is _exactly_ the kind of information NSA was tracking 5 years ago. Content was never the issue, content can be encrypted by default with non-centralised systems. What's the point of a centralised system now, that was its only justification.
As it stands, Signal is good for voice calls where one doesn't usually have a need to retain content of the conversation. For text messages, it becomes useless after sometime (when the user changes devices).
http://www.macworld.com/article/3142400/data-center-cloud/ap...
I imagine the value for a Signal user to have his calls logged in iCloud is quite low, if not zero.
Also, it's quite frustrating how Apple doesn't allow granular control of what gets synced to the iCloud. It's all or nothing. There's no good reason to do it this way, other than them not wanting to do the work required to make that change.
I have a technical question:
> We immediately realized that protocols like SIP, which traditionally required holding open long-lived connnections in order to receive incoming calls, were not going to be compatible with the mobile environment.
Ok, so far so good.
> Instead we built our own simple REST-based signaling protocol [...], and used push notifications instead of long-lived connections to notify the client of incoming calls.
So, no long lived connection but a "simple REST-based signaling protocol". How is that supposed to work without a long lived connection?
> Actual push notifications hadn't been invented yet, though, so we created our own push infrastructure by sending encoded SMS messages that the app would silently intercept and interpret instead.
OK, that's pretty clear again.
> Over time, we switched to push notifications when they were created by Google and Apple [...]
But don't push notifications basically work over a long lived connection? Of course it's better to have just one long-lived connection to Apple instead of one for every communication App, but in the end if you want real time signalling in a mobile environment you won't get around a long lived connection, don't you? At least that is my understanding, but I'm always happy to learn something new.
I think part of the convenience is on the server side. The server also only maintains a single connection to Google/Apple, instead of keeping millions of idle ones.
Android users like me can enjoy it too ! :)
What they're mainly talking about, however, is that it's inappropriate to have a persistent connection (as would be required with SIP) continuously running in an app while the app is doing nothing but waiting for a call. Once that notification comes through and the call is accepted, then of course a persistent connection is required for the duration of the call. When the call is over, the Signal app can shut down all network traffic and wait to be reactivated via a mobile push notification when the next call comes in.
It took me a while to understand this, and while other people have answered the question, I want to chime in in hopes it helps other people understand.
Yes, push notifications work over a long-lived connection. The way push notifications in iOS and Android work is that all of your push notifications for all of your apps get sent over one long-lived connection, instead of one per app. Also, (at least on Android), the notifications can be held and batched, so that the device doesn't have to wake up as often to receive notifications. And finally, push notifications are handled by a system service that can wake up other applications, so that messaging applications can be aggressively hibernated to save power, and still receive notifications.
The downside is that your notifications are all centralized. And while a well-designed app like Signal will only send a "wake-up" packet over the push notifications channel, it's still a worrying dependency for some people.
There's a proposed RFC called webpush that would let you implement/choose your own push to be used by multiple apps: https://datatracker.ietf.org/wg/webpush/documents/
On the other hand, Signal SMS support is broken (datastore and MMS issues), they don't want to bring SMS support to their "desktop" app (which STILL needs you to install Chrome to work) and they still don't support the use of multiple devices. Instead they're wasting resources implementing video chat which noone really asked for and won't help the adoption nearly as much as having a secure drop-in replacement for SMS client. Even worse, enabling SMS support will prevent any other SMS apps that let you have conversations via the computer from working.
It seems like they're actively trying to shoot their own foot.
The best Signal can do is to make a proper desktop application (even Electron would do now, even though Telegram's approach is significantly better UX wise) and make SMS seamlessly integrated into it both on the phone and on the desktop. Video chatting is nice, but it's not where the most important requirement for cross-platform private communication is.
The common denominator where I live is Whatsapp. If you send an SMS to someone, they will very likely not reply. In other countries it can be WeChat, LINE, Kakaotalk, ... and Signal is competing in this space.
I still believe we should get rid of it and use something encrypted.
And it does this. On Android. Where the API allows it to do so.
On iOS, where Apple shuts out everyone not them from the interesting APIs, this is not an option. I was severely surprised when I got an iPhone and discovered I had to relate to several messaging-apps due to this restriction.
Still though: This is IMO not Signal's fault. They're just being limited by what Apple is willing to support.
I consider Signal an imperfect but extremely useful option for a very specific use case: getting my family and friends to send me (and each other hopefully) encrypted messages, just cause.
And after having done that, I can say I see the genius of the approach Signal has taken.
[1] https://blog.cryptographyengineering.com/2016/03/21/attack-o...
I'm also really tired of seeing the SMS argument for all new chat applications that appear. SMS is a dinosaur and it deserves to disappear. A lot of people don't rely on it already (likely over a billion, or virtually all WhatsApp users, and there are more apps like it). New apps shouldn't be held back just because some users still rely on it.
SMS is the IE6 of the carrier world. To see the same people decry email insecurity, but at the same time want to use SMS by the carriers that are "tight partners" with intelligence agencies all over the world, and in a world where the police is increasingly using more phone-spying tools without a warrant is really mind-boggling.
I do fully agree with you that Signal needs a proper desktop application that works (I still can't seem to be able to import phone numbers from the phone to the Chrome app - it always fails for me).
If we actually take a moment to heed what history taught us is: noone gives a damn about security. It's a nice tick on the feature list, but it's a low-priority tick. It'll always be trumped by convenience and networking effets. Without understanding that, Signal is on its way to the garbage dump of history together with PGP, XMPP and countless other secure protocols.
SMS integration is a great trojan horse to make people use it - just replace the existing messenger and you can message to people via your computer! As the userbase grows, Signal switches to secure communication anyway until you can finall y drop the SMS support. But without that user growth, it's exactly what I wrote above - a shitty version of iMessage and WhatsApp.
good luck sending more photos at once, you can send photos only one by one
these basic case scenarios really make it look like it's made by some teenager
You'd have better luck with Matrix, which is designed for this kind of use case.
Matrix is great and I really hope it takes off, but security is bolted on, and the clients aren't really on par with Signal. I'm going to wait a bit before I switch to Matrix, but hopefully I will, at some point.
It's a fork from the old Signal (nee TextSecure) code that retains the SMS capability. It was called SMSSecure for a while, but the name was changed to avoid trademark confusion or something.
I use it for my main texting app every day. It's really nice! I think I'd still use it even without the crypto, just because the interface is nice and it doesn't upload my data into anybody's cloud. I only have secure sessions set up with a very small number of my contacts, but oh well. More and more of them are getting on Signal these days, so I do have a secure option for talking to them.
Could you expand on this? What data are you basing this on?
Video was very smooth as well.
iOS: https://github.com/WhisperSystems/Signal-iOS/issues/new
Android: https://github.com/WhisperSystems/Signal-Android/issues/new
And it still frequently happens that I get the same text message from Android users six times. Where are the priorities of this project?
As for the bug; If projects shouldnt add features before all bugs are fixed I dont think we would see much releases...BTW ive never encountered that bug.
I will be interested in doing Video calls in a bigger screen, like iPad for example, is there any plans to expand this ? or is there any technical limitation like the phone number ?
This config works for me with other VoIP apps. I tried earlier but was not able to get a call through...
I understand that the Matrix.org/riot.im team have some interest in working on this.
If you read into Signal's group chat, it ends up being indistinguishable from standard chat in the sense that the server is unaware of any "group" abstraction. The clients figure out how to thread messages based on encrypted message headers. From the outside, it just looks like N simultaneous outgoing messages from one user.
This is nice, as the server doesn't have to remember who you were in a group with, and it's only a bit worse than the obvious (single message to server + broadcast to group members) approach because only the sender has to pay the cost of sending the N messages. All receivers still just receive 1.
Extending to video chat, this would be quite difficult. To keep the necessary streams open and preserve the group-ignorant server design, each client has to open N connections to all other participants. That's a rough way for video streams to scale especially when routed through the same central infrastructure.
Group calls would probably need server side group-aware logic to mux the feeds together, which would sacrifice some of the server's data minimalism. I predict that we won't be seeing group calls anytime soon.. Might be wrong though!
Anyways, interesting to think about :) Seems like a pretty fascinating job to have.
https://github.com/WhisperSystems/Signal-Android/issues/4577...
https://github.com/WhisperSystems/Signal-Android/issues/4577...
Sometimes I'll MMS from other people inside other chat windows where they don't belong.
It's also really annoying that I have to attach a an item BEFORE I enter the message. Gets old after while.
Apps crashes quite frequently.
Using T-Mobile Wifi Calling feature makes MMS inconsistent, though at least it allows me to use.
Signal should add support for Windows 10 Mobile as an app for all platforms, and SMS/MMS should carry over, not just Signal-to-Signal.
I know there's a few other bugs, but I can't think of them at this moment.
BTW, I use the LG G4 unrooted, custom recovery, and unlocked bootloader