Explains why I was having issues this morning. Was receiving messages on the desktop app, but not my phone, and none of my messages where bring received regardless of where I sent them from.
More like: "When it's down, it's just down for everyone and there's nothing you can do"
If most messaging systems were IRC, XMPP or Matrix then and the status quo was not that Facebook Messenger and Whatsapp were the most popular instant messaging solutions, then Signal being so centralised would look quite odd and we might have cause to criticise them.
The situation is not that, however we can still fault them for this.
I presume it might be them struggling to deal with increased traffic from the quarantined crowd? Although I'm not sure how many users Signal has now and how much of an increase it's experienced.
this only serves to highlight how critical it is for signal to switch to a distributed design. Its a great technology, but worthless if regimes can just QoS it into oblivion or block it entirely.
Signal won't switch to a distributed or federated model because it does not serve Moxie's interests. This has been brought up again, and again, and again, but a centralized design gives Moxie more power so it doesn't matter if it cripples security, privacy, or reliability.
Signal and Moxie specifically have outlined their reasons in detail and, by all indications, in good faith. You might not agree with these reasons or think they are outright mistaken but constantly insinuating that they are acting nefariously is something you should stop doing, at least on HN.
I have written at length to enumerate the many indications that Signal and Moxie's engagement on the subject has not been in good faith. Exactly what does it take for you to give up the presumption of good faith? How long will you allow yourself to be gaslit by their self-serving lies?
I think a reasonable reading of your argument is: "I told Moxie that Signal should be federated and that the Signal application should be deployed officially on the F-Droid app store. He disagreed. Here is why that makes him a bad person..."
I stand by my analysis, which is derived from a re-reading of your pointless 2018 post and the ensuing HN thread, and welcome any substantive rebuttal you'd like to generate.
By the way: you get a million extra points for ghost editing your Matrix recommendation out of your post after being called out on the fact that it didn't even do E2E by default. It's still right there on Archive.org. If you flip through the Archive snapshots, you even had a changelog on this post at one point!
>By the way: you get a million extra points for ghost editing your Matrix recommendation out of your post after being called out on the fact that it didn't even do E2E by default. It's still right there on Archive.org.
I issued a correction and I'm still the bad guy? You simply can't even pretend to engage me in good faith today, can you?
Until November of 2019 your post recommended Matrix (and, a few weeks after you originally posted it, Tox, which recommendation was accompanied by a changelog entry noting the inclusion of Tox). When you decided to stop recommending Matrix, you simply removed the recommendation and the changelog from the post.
It's a blog post, not a work of journalism, but I don't think you get to use the words "issued a correction" here.
How about that? Any more language you'd like to nitpick? At any time you're welcome to rebuke the actual points I made in my article, by the way.
There were no longer any recommendations so there was no longer any need to show why the list was changing. It's my blog and I can put what I want on it. Again, at any time you can feel free to level any good faith rebukes whatsoever about the actual content of my arguments.
I'm happy to address any substantive rebuttal you come up with to my original argument. I'm sorry that the argument is so simple that it only takes a sentence or two, and thus may seem superficial. It is not. I think it's well articulated in the comment upthread.
In fact, the Signal team has been explicit about why they won't federate, and, unsurprisingly, you're doing your level best to avoid being charitable to their explanation and to instead substitute your own reasoning.
Moxie's "interests" are in ensuring that that every aspect of the Signal ecosystem serves the goal of deploying cryptographic privacy to the largest number of people. This is why Signal didn't even have user profiles until recently, why it won't be until this year at the earliest that they have non-phone-number identifiers, and why even the GIF sharing feature of the application has its own purpose-built tunneling scheme. Signal simply takes privacy a lot more seriously than other tools --- especially the tool you yourself recommended, Matrix, which (while a fine and worthy project) didn't even enable E2E by default when you recommended it.
The problem federation poses to Signal's goal is the same problem Matrix faced: it forces the system into compatibility compromises with lowest-common-denominator clients. Right now, the Signal team can deploy a new privacy-preserving feature universally to all its users without negotiating with any third parties. With a federated design, they obviously could not do that. Since these kinds of features are essentially all Signal works on (much to the consternation of Hacker News), that issue is important.
But you know all this, because we've had the same "debate", with the same points made, ever since you wrote the "I Don't Trust Signal" article that derived from first principles Moxie Marlinspike's malign goals from the fact that Signal didn't support F-Droid.
The fact that you're not disclosing any of this context in your random snipes at Signal on unrelated threads is much better evidence of your bona fides than any of your arguments have been about Moxie's.
I am under no obligation to repeatedly help you resurface your ridiculous arguments in every thread about Signal. You consistently disregard most of my points, latching on only the ones that you think you can use to paint my opinion in a bad light. I have rebuked you in exhaustive detail many times before, and I have no intention of entertaining your ravings again.
One of the points in the older threads was "e2e by default". According to the github issue [1] it looks like E2E is now enabled by default in Riot.
The "compatibility with the least common denominator client" point still stands though. I'm curious whether Signal is likely to add features that Riot will fail to add.
Signal is basically built out of features Matrix doesn't and won't have.
Think of Signal this way: Signal is an effort to build an Internet scale messaging system that is end-to-end encrypted by default and that maintains the smallest possible metadata footprint. Core messaging application features have been absent from Signal for years as they work out how to get them deployed without turning their servers into repositories of valuable metadata, which is why we only just recently got user profiles.
Similarly: the Signal feature most hated by message board nerds (myself included!), its reliance on phone numbers, is a straightforward consequence of that project goal; using phone numbers allows Signal to piggyback on people's local contact databases instead of maintaining that directory serverside. It seems like an inconsequential difference not worthy of the UX debacle of having to ask for people's "Signal number" until you realize that Signal's competitors are forced to maintain plaintext databases detailing every pair of users that have communicated with each other.
Eventually, Signal will get all this stuff worked out. We'll have a reference design for how to do privacy-respecting Internet-scale messaging with modern cryptography. At that point, it will make a lot of sense to start asking about federating Signal; I would not be surprised to see Marlinspike himself opening up to it. But we are not there yet: we're still using phone numbers with it! Signal is aggressively evolving, and that's it's job, and people shouldn't demand Signal do things that retard that job.
Riot will no doubt get a whole bunch of cool messaging features Signal won't have, because it is much easier for Riot to add features, because they operate without the security and privacy constraints Signal has opted into. Which is fine! It's how this should work. Let a thousand flowers bloom. I just get to make fun of the people who choose the plaintext-by-default flowers.
(Yes, my understanding is that Matrix either is or soon will be all E2E by default, this year... 2 years after DeVault recommended it as a secure alternative to Signal, in his post attributing malign intent to Moxie Marlinspike.)
I would take it as a favor if someone were to explain how to make Signal stop pestering me to fill out a profile. After I have said "maybe later" a half-dozen times, it could maybe take the hint.
"Kings and dictators can also deploy new features faster than democracies, and they don't need to negotiate with anyone. Thus autocratic societies are simply better." This is literally how you and Moxie sound to everyone rational when you spout these opinions on centralization.
Nobody as far as I know, is arguing that a dictator ran software can't effect change faster. We are simply arguing that we would rather take a less effective system that has to compromise on certain aspects, over a unpalatable centralized solution. These arguments about 'We want the greatest amount of privacy for the largest number of people' are straight out of Plato's Republic.
In this case, the parent commenter would rather recommend that people use a less secure messenger so that he can sysadmin his own phone, and the Signal project has taken the eminently reasonable alternative position that getting cryptographic privacy into the hands of the vastly larger set of people who would never even imagine configuring an alternative app store takes precedence over satisfying the noisome demands of nerds on message boards.
You are of course welcome to use an alternate secure messenger for your own communications (I like Matrix just fine for what it is), or, for that matter, to stand up another instance of Signal, which is open source; there's a whole community of people who apparently do this.
The problem isn't simply that people disagree with Signal. Disagreement is fine (though recommending a "secure messenger" that isn't E2E by default is security/privacy malpractice, for whatever that's worth to you). The problem is when people can't metabolize disagreement and insist, repeatedly, over the span of years, that any disagreement must be evidence of malign intent.
" This is why ... it won't be until this year at the earliest that they have non-phone-number identifiers ... Signal simply takes privacy a lot more seriously than other tools"
If they took privacy seriously they would have never asked for people's phone numbers.
If by "other comments" you meant your own single comment which defended Signal's use of phone numbers by claiming "using phone numbers allows Signal to piggyback on people's local contact databases instead of maintaining that directory serverside", that does not prevent Signal from keeping a database of contacts serverside.
Further, they could have simply let users find and verify each other out-of-band, as PGP did with key distribution and fingerprint verification.
There is absolutely no need for Signal to know my phone number, and it requiring one has been the main reason why I haven't used it.
Using phone numbers doesn't prevent Signal from storing a database of who's talking to who serverside. Not using phone numbers would require them to do so, and, as you can see from other secure messengers that made different tradeoffs (like Wire), that's exactly what ends up happening.
It's pretty funny to try to use PGP as an example of a system that doesn't centralize and leak metadata.
How is PGP (now gpg) centralized? Out of band, I can exchange keys and verify fingerprints with whomever I want to communicate with, then send then a pgp/gpg encrypted email directly (or use some other means of sending the encrypted message). No centralization required.
As for Signal, there's no requirement for them to keep any kind of directory, with or without phone numbers. Just let people discover each other in some way not under Signal's control.
Whether other services have made the same mistake as Signal is irrelevant. It's still a mistake.
This point is so straightforward that at some point your inability to acknowledge it will become willful. It is simple:
People expect to find their acquaintances to talk to in a messaging application.
Most messaging applications solve this problem by keeping a serverside contact database. You see the same thing with Signal's competitors.
Signal refuses to keep that database, because it is practically as valuable to adversaries as message plaintext.
So, instead of having users register handles and maintaining a database, Signal uses phone numbers --- like the most popular messaging applications, including WhatsApp, iMessage, and SMS --- so that it can take advantage of contact databases users have locally and not need to store a contact directory globally.
"Just letting people discover each other some other way" doesn't work, and PGP is a good example of why: the "other way" PGP came up with is (wait for it) a global directory of key metadata.
You are free to disagree with the tradeoff Signal made here. What you cannot reasonably do is suggest that there was no tradeoff, or that their use of phone numbers is somehow obviously flawed and privacy-hostile. It is, as I said, the opposite: phone numbers are an instance where Signal sacrificed uptake and UX in favor of privacy, because they do not care what random people on message boards have to say about their decisions as much as they care about the fact that they're the world's most important and effective secure messaging design.
"People expect to find their acquaintances to talk to in a messaging application."
That hasn't been the case in my use of Skype, for instance. I'm not sure if it's changed, but when I used it it had no real name requirement, and the people I communicated with over it had to tell me their Skype usenames out-of-band, like through email or by phone. There was no directory that would have been useful to us, as we didn't use our real names (or phone numbers).
So your assertion that people on messaging applications expect to find their acquaintances (through it) is simply false in the case of Skype, which is one of the most popular messaging applications in existence.
Discord is another extremely popular messaging application that didn't require me to give my name or phone number.
"Signal refuses to keep that database, because it is practically as valuable to adversaries as message plaintext."
And a database of phone numbers is not?
"the "other way" PGP came up with is (wait for it) a global directory of key metadata."
If you're talking about pgp/gpg keyservers, those aren't necessary for communication via pgp/gpg, as keys can be exchanged and verified by other means. Furthermore, the entities (plural) most people communicate through using pgp/gpg (ie. mail servers) don't control the keyservers, so they're not centralized like Signal is. This is a distributed system.
"What you cannot reasonably do is suggest that there was no tradeoff, or that their use of phone numbers is somehow obviously flawed and privacy-hostile."
I can't believe that you can't see that requiring people to hand over their phone numbers is a violation of privacy, or that it could in fact be objectionable to people who care about their privacy. It's even more mind boggling that you'd argue that handing over one's phone number offers more privacy than not doing so.
This is akin to Facebook's real name policy, and arguably even worse, as so much tracking is tied to one's phone.
> That hasn't been the case in my use of Skype, for instance.
You have misread his point. He's not saying that users expect to see their contacts on their "first load". He's saying they expect to see their contacts after adding them.
Skype does fulfill that expectation, by keeping metadata about your contact list on their servers. Signal fulfills that expectation without keeping the metadata, by deferring to your phone's (local) contact system.
What a horrible status page, for a project of 1 person or 1 million persons, this is slightly above useless.
Stripe [0] and Segment [1] have pretty useful status pages, which provide, in my opinion, the real reason for a status page -- to confirm there isn't a problem on your end or that an issue you're facing is or isn't a problem with the service so you can escalate accordingly.
Has it ever not been? I've been unable to receive messages on desktop for 6+ months. The mobile app constantly loses message history and fails to receive notifications as well.
I've submitted multiple detailed support tickets with screenshots, steps to reproduce, etc, to no avail, never even got a response.
I've used it across three different mobile phones and countless desktop devices over the years without any issues. Did you accidentally set the messages to expire after a short time? Are you using more than one mobile phone? I also recommend submitting an actual github issue to either their Desktop or Android/iOS repo with those detailed instructions.
Most definitely not using expiring messages, each message shows up as "Error handling incoming message" instead of the message text, but otherwise looks the same as a normal message.
Yeah, and a buggy clock works twice a day... I'm not going to recommend people use an app that's so fundamentally broken on multiple devices for so long, even if it works fine for some people.
I've been a Signal user on Desktop, iOS, and via the old chrome app for many years out of necessity, and I contantly encounter frustrating bugs that I've never seen on iMessage or WhatsApp.
I also have never had issues. (if mobile = Android) That sounds like you either didn't set it as the os default messaging app or some "battery saver" optimization is running wild. If you can truly reproduce the issue, you could always create your own patch (assuming you're a software dev since hn).
You can also set up automatic backups of conversations into an encrypted database. Certainly not a fix for whatever your problem is, but could be a workaround.
This is on desktop and iOS, I don't use Android. Incoming messages appear as "Error handling incoming message", and the automatic backups are unusable because you can't import the backups on another device. I shouldn't have to patch my messaging app to have it be usable...
Signal's quality issues are why I switched to telegram. The performance, quality, and UX are years ahead of Signal. Plus, I've never had a message drop on telegram, very much unlike Signal.
The one drawback is chats aren't e2e encrypted by default, but there is an option to have "Secret Chats" which are e2e encrypted.
"Private messaging" ala Signal. Step 1. Give us all your contacts. Step 2. Send you an SMS to immediately alert anyone monitoring traditional communications systems that you are a person of interest. Step 3. Maintain traditional E.164 telephony network identifiers, increasingly unavailable without government issued ID and permanently linked to location records, as the primary account identifier for discovery. Step 4. Ensure software refuses to work without said identifier. Great job guys.
And yet, click on their website and you get these positive reviews from Snowden, Poitras, Schneier. What gives?
There's an interesting fork of Signal, called 'Session', that aims to remedy many of the flaws in Signal's infrastructure/strategic choices. It's young - needing a lot more analysis & track record before earning serious credibility – but you can check it out at: https://getsession.org/
Some of its Signal-contrasting goals include:
* no phone numbers needed
* onion-routed messages
* multi-device sync
* no central point of failure
I also don't see anything in Session's materials that they're placing Intel™ SGX™ at key points in mandatory introduction/contact-uploading/cloud-backup steps – as Signal likes to do.
Many people don't trust Intel & the SGX technology.
Intel controls the initial attestation keys – so you're dependent on their goodwill. Much of the world will view Intel as being as cheerfully compliant with US government requests, including undisclosed & arguably-illegal requests. (That's just like how some in the US view Huawei as being compliant in undisclosed ways with the Chinese government's requests.)
Sophisticated, high-budget/state-supported attackers may be able to compromise SGX units, via physical analysis/disassembly/reassembly. (This might happen before a unit is placed in service, or just show up to the outside as a temporary service outage.) So any secrecy/security features provided by their qualities could be a false promise.
Some security experts deeply distrust both SGX specifically, and the general idea that such a piece of hardware could provide the touted benefits against sufficiently-sophisticated attackers.
I have mixed feelings about that aspect - as the Australian government has often seemed more encryption-hostile than other countries, almost to the extent that it might be rehearsing limits that other countries would like to impose later.
But it does seem the Loki Foundation & Session project are attempting to engineer-around surveillance threats from local jurisdictions.
63 comments
[ 3.8 ms ] story [ 153 ms ] threadOh well, had they're working on it.
If most messaging systems were IRC, XMPP or Matrix then and the status quo was not that Facebook Messenger and Whatsapp were the most popular instant messaging solutions, then Signal being so centralised would look quite odd and we might have cause to criticise them.
The situation is not that, however we can still fault them for this.
I can't wait for Matrix to gain more traction as its UX gets friendlier with time with Mozilla pouring a bunch of resources into that.
https://news.ycombinator.com/item?id=17723973
By the way: you get a million extra points for ghost editing your Matrix recommendation out of your post after being called out on the fact that it didn't even do E2E by default. It's still right there on Archive.org. If you flip through the Archive snapshots, you even had a changelog on this post at one point!
I issued a correction and I'm still the bad guy? You simply can't even pretend to engage me in good faith today, can you?
https://drewdevault.com/2018/02/05/Introduction-to-POSIX-she...
I don't think you're the bad guy here, but the criticism was that you ghost-edited, not that you issued a correction.
Of course, your blog is publicly version-controlled, so it probably wasn't intentional on your part.
It's a blog post, not a work of journalism, but I don't think you get to use the words "issued a correction" here.
How about that? Any more language you'd like to nitpick? At any time you're welcome to rebuke the actual points I made in my article, by the way.
There were no longer any recommendations so there was no longer any need to show why the list was changing. It's my blog and I can put what I want on it. Again, at any time you can feel free to level any good faith rebukes whatsoever about the actual content of my arguments.
Moxie's "interests" are in ensuring that that every aspect of the Signal ecosystem serves the goal of deploying cryptographic privacy to the largest number of people. This is why Signal didn't even have user profiles until recently, why it won't be until this year at the earliest that they have non-phone-number identifiers, and why even the GIF sharing feature of the application has its own purpose-built tunneling scheme. Signal simply takes privacy a lot more seriously than other tools --- especially the tool you yourself recommended, Matrix, which (while a fine and worthy project) didn't even enable E2E by default when you recommended it.
The problem federation poses to Signal's goal is the same problem Matrix faced: it forces the system into compatibility compromises with lowest-common-denominator clients. Right now, the Signal team can deploy a new privacy-preserving feature universally to all its users without negotiating with any third parties. With a federated design, they obviously could not do that. Since these kinds of features are essentially all Signal works on (much to the consternation of Hacker News), that issue is important.
But you know all this, because we've had the same "debate", with the same points made, ever since you wrote the "I Don't Trust Signal" article that derived from first principles Moxie Marlinspike's malign goals from the fact that Signal didn't support F-Droid.
The fact that you're not disclosing any of this context in your random snipes at Signal on unrelated threads is much better evidence of your bona fides than any of your arguments have been about Moxie's.
https://news.ycombinator.com/item?id=17723973
I'm pretty comfortable with how it represents what I said today.
The "compatibility with the least common denominator client" point still stands though. I'm curious whether Signal is likely to add features that Riot will fail to add.
[1] https://github.com/vector-im/riot-web/issues/6779
Think of Signal this way: Signal is an effort to build an Internet scale messaging system that is end-to-end encrypted by default and that maintains the smallest possible metadata footprint. Core messaging application features have been absent from Signal for years as they work out how to get them deployed without turning their servers into repositories of valuable metadata, which is why we only just recently got user profiles.
Similarly: the Signal feature most hated by message board nerds (myself included!), its reliance on phone numbers, is a straightforward consequence of that project goal; using phone numbers allows Signal to piggyback on people's local contact databases instead of maintaining that directory serverside. It seems like an inconsequential difference not worthy of the UX debacle of having to ask for people's "Signal number" until you realize that Signal's competitors are forced to maintain plaintext databases detailing every pair of users that have communicated with each other.
Eventually, Signal will get all this stuff worked out. We'll have a reference design for how to do privacy-respecting Internet-scale messaging with modern cryptography. At that point, it will make a lot of sense to start asking about federating Signal; I would not be surprised to see Marlinspike himself opening up to it. But we are not there yet: we're still using phone numbers with it! Signal is aggressively evolving, and that's it's job, and people shouldn't demand Signal do things that retard that job.
Riot will no doubt get a whole bunch of cool messaging features Signal won't have, because it is much easier for Riot to add features, because they operate without the security and privacy constraints Signal has opted into. Which is fine! It's how this should work. Let a thousand flowers bloom. I just get to make fun of the people who choose the plaintext-by-default flowers.
(Yes, my understanding is that Matrix either is or soon will be all E2E by default, this year... 2 years after DeVault recommended it as a secure alternative to Signal, in his post attributing malign intent to Moxie Marlinspike.)
Nobody as far as I know, is arguing that a dictator ran software can't effect change faster. We are simply arguing that we would rather take a less effective system that has to compromise on certain aspects, over a unpalatable centralized solution. These arguments about 'We want the greatest amount of privacy for the largest number of people' are straight out of Plato's Republic.
You are of course welcome to use an alternate secure messenger for your own communications (I like Matrix just fine for what it is), or, for that matter, to stand up another instance of Signal, which is open source; there's a whole community of people who apparently do this.
The problem isn't simply that people disagree with Signal. Disagreement is fine (though recommending a "secure messenger" that isn't E2E by default is security/privacy malpractice, for whatever that's worth to you). The problem is when people can't metabolize disagreement and insist, repeatedly, over the span of years, that any disagreement must be evidence of malign intent.
If they took privacy seriously they would have never asked for people's phone numbers.
Further, they could have simply let users find and verify each other out-of-band, as PGP did with key distribution and fingerprint verification.
There is absolutely no need for Signal to know my phone number, and it requiring one has been the main reason why I haven't used it.
It's pretty funny to try to use PGP as an example of a system that doesn't centralize and leak metadata.
As for Signal, there's no requirement for them to keep any kind of directory, with or without phone numbers. Just let people discover each other in some way not under Signal's control.
Whether other services have made the same mistake as Signal is irrelevant. It's still a mistake.
People expect to find their acquaintances to talk to in a messaging application.
Most messaging applications solve this problem by keeping a serverside contact database. You see the same thing with Signal's competitors.
Signal refuses to keep that database, because it is practically as valuable to adversaries as message plaintext.
So, instead of having users register handles and maintaining a database, Signal uses phone numbers --- like the most popular messaging applications, including WhatsApp, iMessage, and SMS --- so that it can take advantage of contact databases users have locally and not need to store a contact directory globally.
"Just letting people discover each other some other way" doesn't work, and PGP is a good example of why: the "other way" PGP came up with is (wait for it) a global directory of key metadata.
You are free to disagree with the tradeoff Signal made here. What you cannot reasonably do is suggest that there was no tradeoff, or that their use of phone numbers is somehow obviously flawed and privacy-hostile. It is, as I said, the opposite: phone numbers are an instance where Signal sacrificed uptake and UX in favor of privacy, because they do not care what random people on message boards have to say about their decisions as much as they care about the fact that they're the world's most important and effective secure messaging design.
That hasn't been the case in my use of Skype, for instance. I'm not sure if it's changed, but when I used it it had no real name requirement, and the people I communicated with over it had to tell me their Skype usenames out-of-band, like through email or by phone. There was no directory that would have been useful to us, as we didn't use our real names (or phone numbers).
So your assertion that people on messaging applications expect to find their acquaintances (through it) is simply false in the case of Skype, which is one of the most popular messaging applications in existence.
Discord is another extremely popular messaging application that didn't require me to give my name or phone number.
"Signal refuses to keep that database, because it is practically as valuable to adversaries as message plaintext."
And a database of phone numbers is not?
"the "other way" PGP came up with is (wait for it) a global directory of key metadata."
If you're talking about pgp/gpg keyservers, those aren't necessary for communication via pgp/gpg, as keys can be exchanged and verified by other means. Furthermore, the entities (plural) most people communicate through using pgp/gpg (ie. mail servers) don't control the keyservers, so they're not centralized like Signal is. This is a distributed system.
"What you cannot reasonably do is suggest that there was no tradeoff, or that their use of phone numbers is somehow obviously flawed and privacy-hostile."
I can't believe that you can't see that requiring people to hand over their phone numbers is a violation of privacy, or that it could in fact be objectionable to people who care about their privacy. It's even more mind boggling that you'd argue that handing over one's phone number offers more privacy than not doing so.
This is akin to Facebook's real name policy, and arguably even worse, as so much tracking is tied to one's phone.
You have misread his point. He's not saying that users expect to see their contacts on their "first load". He's saying they expect to see their contacts after adding them.
Skype does fulfill that expectation, by keeping metadata about your contact list on their servers. Signal fulfills that expectation without keeping the metadata, by deferring to your phone's (local) contact system.
Stripe [0] and Segment [1] have pretty useful status pages, which provide, in my opinion, the real reason for a status page -- to confirm there isn't a problem on your end or that an issue you're facing is or isn't a problem with the service so you can escalate accordingly.
0. https://status.stripe.com/
1. https://status.segment.com/
I've submitted multiple detailed support tickets with screenshots, steps to reproduce, etc, to no avail, never even got a response.
I've been a Signal user on Desktop, iOS, and via the old chrome app for many years out of necessity, and I contantly encounter frustrating bugs that I've never seen on iMessage or WhatsApp.
You can also set up automatic backups of conversations into an encrypted database. Certainly not a fix for whatever your problem is, but could be a workaround.
The one drawback is chats aren't e2e encrypted by default, but there is an option to have "Secret Chats" which are e2e encrypted.
And yet, click on their website and you get these positive reviews from Snowden, Poitras, Schneier. What gives?
Edit: Why is this flagged?
Some of its Signal-contrasting goals include:
* no phone numbers needed
* onion-routed messages
* multi-device sync
* no central point of failure
I also don't see anything in Session's materials that they're placing Intel™ SGX™ at key points in mandatory introduction/contact-uploading/cloud-backup steps – as Signal likes to do.
What difference does this make (genuine question)?
Intel controls the initial attestation keys – so you're dependent on their goodwill. Much of the world will view Intel as being as cheerfully compliant with US government requests, including undisclosed & arguably-illegal requests. (That's just like how some in the US view Huawei as being compliant in undisclosed ways with the Chinese government's requests.)
Sophisticated, high-budget/state-supported attackers may be able to compromise SGX units, via physical analysis/disassembly/reassembly. (This might happen before a unit is placed in service, or just show up to the outside as a temporary service outage.) So any secrecy/security features provided by their qualities could be a false promise.
Numerous flaws have been discovered, and more are likely to be discovered, in SGX. Try: https://www.google.com/search?q=SGX+flaws
Some security experts deeply distrust both SGX specifically, and the general idea that such a piece of hardware could provide the touted benefits against sufficiently-sophisticated attackers.
This is awesome.. Looks like its Australian as well.. even better!
But it does seem the Loki Foundation & Session project are attempting to engineer-around surveillance threats from local jurisdictions.