Video calls for Signal now in public beta(whispersystems.org)
whispersystems.org
Video calls for Signal now in public beta
https://whispersystems.org/blog/signal-video-calls-beta/
85 comments
> This information includes who you called and how long you talked.
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.
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.
At the same time, metadata collection via a gag-ordered pen register on Signal is still possible in principle, this would just make it slurpable by existing prism type tools potentially already operating on iCloud. Those truly concerned with metadata should go to Tor, and not use signal, independent of this feature.
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.
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.
How feasible is call setup correlation when there are 10000 calls per minute going through the servers?
Signal allows my (non-technical) friends and family to help raise the bar while providing a chat client that offers basic calling features.
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.
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.
Except the parent is right, if you don't have metadata protection by default, then it is no different than running something that's federated but secures it's transport or secures its payload end to end.
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.
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.
If you have a Trojan on your phone that steals all your call info, remove the Trojan instead of not calling people. If signal isn't seamless and doesn't provide a good experience, nobody will use it, making it useless. If you don't want Apple to track your calls, get an Android phone or disable iCloud. What are you doing with iCloud if you're privacy-conscious, anyway?
And yet Signal has not and does not allow retaining messages when moving to a new device (essentially, migrating messages to a new device) because it explicitly marks its data with the do not backup attribute to avoid leaking data. I find this sort of design decisions unappealing. If it put up a message on first launch and allowed the user to decide that, or even kept the current design on data backup as the default with a hidden setting to allow it, the app would be more useful.
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).
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).
You can actually do a plaintext import / export of all of your chat histories from the menu in the conversations screen (at least in Android.) It won't use OS level backup/restore, but I feel like that would've taken flak on HN anyways :)
But is that information not encrypted in iCloud by Apply? I thought they were encrypting everything by now, and if so, as long as you use an iPhone you are probably already trusting Apple to keep things safe, so in theory, it's still secure.
If you're not syncing to iCloud, do you still need to disable CallKit to keep your current levels of privacy?
At a glance, it looks like no. It appears that if you have iCloud Drive enabled, Apple will store call history there for the purposes of syncing across devices. If iCloud Drive is disabled, it appears the call logs never leave the device.
http://www.macworld.com/article/3142400/data-center-cloud/ap...
http://www.macworld.com/article/3142400/data-center-cloud/ap...
Thanks!
Why not disable that syncing by default?
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 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.
This is great news. I'm on iOS but I hope it will come to Android soon.
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 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.
Apple and Google make exceptions for their blessed push-notification services - just those services get reliable long-lived connections (and also have re-connection of course). Other applications, even with processes using some official API to run in the background, can be suspended or otherwise cut off to save power.
> But don't push notifications basically work over a long lived connection?
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/
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/
> 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?
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.
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.
> Today's Signal release for Android and iOS includes beta support for video calls.
Android users like me can enjoy it too ! :)
Android users like me can enjoy it too ! :)
Yes, if you want real-time signalling you're generally going to need a persistent connection, long polling, or at minimum near-continuous regular polling depending on how "real-time" you want to get. For example, if your phone polls Apple/Google for any new push notifications every 3 seconds, does it matter that a Signal call takes 1.5 seconds (on average) to start ringing on the recipient's end?
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.
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.
My read was that the SIP protocol was just less well suited to a mobile environment. Not merely that long-lived connections are bad, but that it would be inappropriate to use a long-lived connection that requires keepalive packets or loses user data every time the user goes underground (SMS queues up for delivery when the connection is re-established, and APNS will at least deliver the most recent push). Technically even the SMS solution requires a persistent connection, it's just the device's persistent connection to the cell network, which is presumably better tailored for the mobile use case.
SIP is unsuited for any environment. It is a disgrace of a protocol and a hot mess at that. At it's foundation it was designed to be 100% NAT incompatible and since it's inception bandage has been added to address this and it's other shortcomings. Faster we replace it with some/any alternative the better. From protocol design standpoint, SIP is so bad that it makes H.323 feel like a sane VoIP protocol (which it isn't). </rant>
I really don't get the direction of the Signal project. iMessage got a huge following because it allows you to trabnsparently send both SMS and encrypted messages (significantly lowering barrier to entry) and brings that functionality even to the desktop. Hence using it means that average user doesn't have to explicitly think about which channel to use and with spread of use more and more communications are secure.
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.
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.
> I really don't get the direction of the Signal project. iMessage got a huge following because it allows you to trabnsparently send both SMS and encrypted messages (significantly lowering barrier to entry) and brings that functionality even to the desktop
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.
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.
You are right. But lets not kid ourself. It would be better if everyone just moved away from SMS.
To what? A proprietary channel controlled by an US company?
Well, moving away from SMS doesn't mean you're stuck with just Signal of course... what about XMPP for example?
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.
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.
XMPP is looking better these days than it did not long ago. OMEMO makes encrypted messaging a lot simpler, Conversations provides a reasonable mobile client, and Prosody makes deploying your own server easy. Still a ways to go on some things (push notifications), but a lot better than it used to be.
It doesn't (I use Android) - it hijacks the datastore (breaking other apps that read it and backups), it doesn't work well with MMS at all and it doesn't sync conversations with the desktop app. It's a significantly subpar experience in comparison to iMessage.
It's really quite easy to get. SMS is not secure. They want their app to be called secure. And iMessage is not secure either, and not just because of SMS, but because the whole protocol is flawed [1]. So you're basically comparing two classes of apps: one insecure, and one secure, and you wonder why they don't both work the same way.
[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).
[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).
This is the exact same issue PGP and other secure communicators face: noone will use them if they're INCONVENIENT. At this point Signal is just a worse version of proprietary WhatsApp and a significantly worse version of iMessage. It doesn't offer anything better or anything new. SMS might be insecure, but its integration offers convenience which makes for a great stepping stone to making Signal widely used and available.
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.
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.
But except for the shitty MMS support (MMS groups never seem to work for me), Signal's SMS support seems just fine.
UI is quite horrible, good luck forwarding whole conversation to someone else, you need to select all messages one by one
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
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
I for one would love to finally move away from Skype. I even got my Mom to install and use Signal for texting between US<->EU, granted 98% of her friends use iMessage or the default SMS app, but at least our messages are secure. As soon as this update goes live, I can have her remove Skype.
Nobody in my country really uses SMS, because it costs. Instead, what I'd like from signal is an open source client library, so I could build bots and use Pidgin to talk to my contacts. Is that too much to ask?
https://github.com/WhisperSystems/libsignal-protocol-java or one of the other things at
https://github.com/WhisperSystems would seem to be what you need.
[deleted]
That basically exists, but AFAIK you can't use it with OWS's servers, which means you can't interoperate with regular Signal users.
You'd have better luck with Matrix, which is designed for this kind of use case.
You'd have better luck with Matrix, which is designed for this kind of use case.
Yeah, the fact that you can't just text your Signal phone is really constraining :/
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.
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.
I guess they aim to be the next Skype. Which actually is a very good move as Skype has become so shitty after MS acquisition, that it's simply begging for replacement and even common users loathe it now. Signal can't remain "just another messenger" as it has no chance to stand against Facebook Messenger and Whatsapp among common users.
It sounds like you want Silence https://silence.im/
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.
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.
> they're wasting resources implementing video chat which noone really asked for
Could you expand on this? What data are you basing this on?
Could you expand on this? What data are you basing this on?
SMS and MMS are almost completely irrelevant outside of North America.
Dozens of my customers SMS me, as well as many friends and family, and several friends send me MMS from time to time. UK here.
That's not even remotely true. It's the only common denominator on the mobile network that ensures delivery to everyone and it's still widely used everywhere.
I'm not saying it's not used, but it's mostly used one way (I receive SMS's but never send any) and irrelevant for modern instant messaging.
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.
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.
What the? ... Oh, you mean on that alternative Earth where America is the only country.
Well, where I live, in the Netherlands, SMS is indeed completely irrelevant.
It's used widely all over the world each second. In Denmark, its used by everyone including public and private institutions for sending e.g. doctors visit notice, notice about garbage pick-up and so forth. I don't have statics on hand but in 2015 it was around 97% of Americans that send at least one SMS each day.
I still believe we should get rid of it and use something encrypted.
I still believe we should get rid of it and use something encrypted.
I live in Europe and SMS is very much relevant as unlimited number is included in my subscription fee. Data, on the other hand, is capped, so it definitely makes sense to use SMS.
Your country is an exception in Europe then, not the norm.
Not really. The GSMA did some research on this - see https://www.gsmaintelligence.com/research/2016/12/ip-messagi...
That study just proves my point :)
[deleted]
Tried it today with a relative, the audio quality is significantly better, almost no stuttering.
Video was very smooth as well.
Video was very smooth as well.
Yeah, they use Opus and VP8, AFAIK, which are both fantastic codecs. The quality is great, although there's no echo cancelation yet, so you want to be using it with headphones.
Would you mind filing an issue about the echo on the corresponding tracker with your device details?
iOS: https://github.com/WhisperSystems/Signal-iOS/issues/new
Android: https://github.com/WhisperSystems/Signal-Android/issues/new
iOS: https://github.com/WhisperSystems/Signal-iOS/issues/new
Android: https://github.com/WhisperSystems/Signal-Android/issues/new
Sure thing, although I think the issue was gone with the latest release (but I used headphones so it might not have been). I'll retest and file.
This is great, might actually use it for calls now.
So I still cannot send a voice message in the chat (like Android users can), but I am now able to do video calls. Shouldn't a feature be fully completed before moving on to the next one?
And it still frequently happens that I get the same text message from Android users six times. Where are the priorities of this project?
And it still frequently happens that I get the same text message from Android users six times. Where are the priorities of this project?
I guess thats a matter of perspective. Voice messages seem important for you but I dont care much for them. Dont assume your priotities are also the priotities for the rest of the world.
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.
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.
Does this change mean that the server is open source too ? I remember that server for voice (redphone) wasn't open earlier.
Well, there's this: https://github.com/WhisperSystems/Signal-Server
Is there plans to bring Video calls to Desktop also ?
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 ?
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 ?
Has anyone tried Signal with CallKit enabled and iCloud disabled as well as seeing if it leaks metadata in this form?
This config works for me with other VoIP apps. I tried earlier but was not able to get a call through...
This config works for me with other VoIP apps. I tried earlier but was not able to get a call through...
Great. Signal doesn't do group calls though, right? Is there any app that does end-to-end-encrypted group calls?
This is tricky as the server needs to mix audio and video streams for group calls, which can't easily be done if they're encrypted.
I understand that the Matrix.org/riot.im team have some interest in working on this.
I understand that the Matrix.org/riot.im team have some interest in working on this.
Speculating for fun:
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.
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.
For small groups, client side muxing is fine (i.e. I call both Alice and Bob, and my device handles merging the streams).
Setting up your own Jitsi Meet server is as close as it gets.
I would pay for this feature.
Seriously, I would pay for being able to retain messages and conversations when changing to a new device (just through a simple restore of the device backup from the old one to the new one). That's the biggest selling point I can use with other non-tech people to get them to move to apps like Signal. Right now that's a huge drawback.
You can. On the Android app - Menu - Import / export. Allows to you to create a (non-encrypted) backup of your messages. I've used that when moving between phones.
After a lot of digging I found this which worked for me. It's definitely not for non-tech people but in a pinch it can be done.
https://github.com/WhisperSystems/Signal-Android/issues/4577...
https://github.com/WhisperSystems/Signal-Android/issues/4577...
https://github.com/WhisperSystems/Signal-Android/issues/4577...
https://github.com/WhisperSystems/Signal-Android/issues/4577...
which would mean some interestingly tasty meta data would be served up...
Signal is a pretty polished app, more than expected. However I'm annoyed that they're adding large features without fixing small things.
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
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
You can add attachments after starting to type a message by hitting the three dots at the top right.
Eh, doesn't work for me. I turned the beta on for two android phones, then called one from the other. No video options, audio quality unchanged.
Strange. Could you follow up with [email protected]?
> 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-...