
Wrong signal - flevo
https://it-kollektiv.com/wrong-signal-das-falsche-signal-engl/
======
cwmma
It sometimes feels like the security community is a bucket of crabs where any
time something starts getting traction due to ease of use a lot of others try
to pick at it due to it not being perfect even if many of those things are
trade offs

\- phone numbers allow for signal to be a drop in replacement for other
messaging apps with minimal to no registration required, I doubt I could have
gotten my mother to use signal without switching from texting being so low-
friction.

\- lack of federation means ows can control spam better unlike in a federated
environment where lazy/malicious operators can cause lots of problems. Take a
look at the 2 big federated protocols email and irc where due to spam and
other issues they are both increasingly centralized.

~~~
tptacek
This isn't the security community. The security community is pretty much
unanimous in supporting Signal over all other secure messengers. That's not to
say that security people aren't critical of Signal, which isn't perfect for
all the reasons this blog post points out --- Grugq is a pretty good source
for these kinds of criticisms through the lens of an infosec person. But
security people tend to deliver these criticisms as, you know, criticisms ---
not angry appeals for people to abandon Signal.

The entities most harshly critical of Signal are supporters of other messaging
applications and protocols.

I think the most important thing to understand about secure messengers is that
messaging in general is a back-ally knife fight of a market, one of the most
vicious I've seen in my career. Perhaps it's because of the WhatsApp outcome
and a general belief that there's another such outcome for some other
messaging app. Or it could just be the network affect. Messaging applications
themselves are interesting UX challenges, but as programming challenges
they're pretty close to socket projects. So there are a lot of entrants in the
market. Whatever the reason, the knives are out for Signal.

I don't so much care what messaging system you use to talk to your friends or
chat with your gaming guild. But if you have real adversaries, the _security_
part of your messaging system has to work, even more than the _messaging_
part. For that situation, Signal is the only messaging system I'd recommend
unreservedly.

~~~
aftbit
How can you reasonably suggest trusting a mobile device if you have "real
adversaries"? If you define your threat model to include any serious
governmental interest, you cannot trust a cell phone. They have an always on
network connection, remote auto-upgrade capability (at least for the baseband,
if not the user software), and built-in microphone, cameras, gps, and other
sensors.

~~~
tptacek
Some of these concerns aren't valid (for instance: the baseband of your phone
is less powerful, in its systems design, than is supposed by open hardware
advocates), but mostly the issue is: security is about costs and
prioritization, not absolutes. The systems people propose instead of Signal
are likely to cough up secrets directly to adversaries; switching from Signal
to something else reduces security.

If you believe people with state-level adversaries should exclusively use
transparent and open hardware, that's fine; you should see Moxie's comment on
this thread to learn how you might go about ensuring that the tiny minority of
users with that hardware have access to Signal on it.

------
burnbabyburn
I'm happy to use Signal today.

In the long run federated protocols and servers demonstrated their resilience
regarding third parties and time, see irc for example.

Probably Signal is just a reference implementation, the big deal is
implementing Signal protocol in different systems (whatsapp, allo, fb
messenger..).

Having said that, I would be happier to not give my phone number for
registration, and contact discovery but this is today a user interface well
understood and accepted outside geek communities that's hard to eradicate.

~~~
mrbiber
I'm surprised to see that matrix.org / riot.im is not mentioned as an
alternative to Signal. They have a federated, open protocol, usable open-
source apps for web/Android/iOS, registration without a phone number (even
email is optional), do not require Google Play, and support double-ratchet
encryption (in beta, it's not activated by default yet, but it will be
activated by default in private rooms in the future).

~~~
vertex-four
Because, frankly, the UX around encryption in Matrix is dire, as well as being
beta. I've never seen someone actually use the same keys for two conversations
over as many days, due to switching devices, logging out of the web interface,
etc.

------
jfindley
Given that we've seen exactly how little information Signal maintains about
its users [0], this seems to me to be alarmist spreading of FUD, potentially
to advance the author's agenda of dfederation in Signal, which the developers
have already addressed at length already [1].

For example, their assertion that "... metadata is abundantly available here"
appears to be patently false, given [0].

0: [https://www.aclu.org/blog/free-future/new-documents-
reveal-g...](https://www.aclu.org/blog/free-future/new-documents-reveal-
government-effort-impose-secrecy-encryption-company)

1: [https://whispersystems.org/blog/the-ecosystem-is-
moving/](https://whispersystems.org/blog/the-ecosystem-is-moving/)

~~~
Freak_NL
Regardless of the merits of Signal, much of the criticism voiced in that
article is nonetheless valid. Signal and other chat platforms employing the
protocol are run as data-silos by design, using strongly identifying codes
(phone numbers) as the required identifier — i.e., it is nearly impossible to
create a throw-away account, because getting an anonymous phone number is no
longer a practical possibility in a lot of (Western!) countries.

Whether or not such metadata is available to adversaries (either through OWS
or gathered elsewhere) depends on who your adversaries are and whether or not
a corporate entity can be trusted to be completely transparent about what kind
of data they retain.

As for [0]; even if no relevant metadata is collected today by whoever owns
the servers, nothing stops the party providing the service from doing so
tomorrow.

~~~
jfindley
> As for [0]; even if no relevant metadata is collected today by whoever owns
> the servers, nothing stops the party providing the service from doing so
> tomorrow.

This is a point I see bought up a LOT. I don't believe it to be useful however
- proceeding down this rabbithole rapidly leads us to a place of advanced
paranoia where we can't get anything useful done. Once you start assuming
actual malice on the part of the software developer, even open-source code
with the ability to run your own service doesn't protect you - there's
multiple ways backdoors can be inserted in sufficiently subtle ways it's
extremely unlikely they will be spotted before it's far too late for you.

> using strongly identifying codes (phone numbers) as the required identifier
> — i.e., it is nearly impossible to create a throw-away accoun

Identifiers are only valuable if there is something to link that identifier
to. Account creation time and last active time are very unlikely to be
valuable to your adversary (for any definition of "your adversary" you had a
chance at defending against in the first place). In other words, as long as
the only data they have is your phone number, then that's not helpful. All
that is is a record of a) this phone number exists (which is not secret) and
b) this phone number uses signal (which isn't a secret either to any even
mildly motiviated attacker).

~~~
zeveb
> proceeding down this rabbithole rapidly leads us to a place of advanced
> paranoia

When it comes to security, today's advanced paranoia is next year's common
sense. Remember that folks used to think that telnet over the Internet was
harmless.

Would OWS refuse to implement a court order directing them to collect and
forward metadata? I don't know.

------
mi100hael
I love Signal. I use it as the primary means of contact for several close
friends and have contributed patches. However, it drives me nuts that OWS
won't allow federation or LibreSignal and requires phone numbers as user IDs.
In the past, their justification has been that their primary goal is thwarting
dragnet surveillance and none of these proposals further that goal (which is
debatable in itself). I wish they would move more in the direction of an
actual open source standard like they sort of purport to be rather than just
an open source library with a closed implementation.

~~~
lorenzhs
You probably already know this, but OWS detailed their reasoning for not
supporting federation at this time in their blog a while ago:
[https://whispersystems.org/blog/the-ecosystem-is-
moving/](https://whispersystems.org/blog/the-ecosystem-is-moving/)

~~~
mi100hael
I've seen it, I just disagree with it. IMO it's a dick move to say "no
federation" and to also say "no 3rd-party clients." What's the point of GPL if
you're completely locked to their official clients & servers anyway?

~~~
frandroid
Code auditing.

~~~
mi100hael
lol no. You could accomplish that with an all-rights-reserved copyright.

~~~
frandroid
You're thinking of free software.

------
agd
There are always security trade-offs (especially when it comes to ease of use)
but until you can show me a better app, _which I can get my non-techy friends
to use_ , Signal remains the best option for the mass market.

~~~
forgotpwtomain
Phone-number as identifier is pretty terrible user-experience choice. I am
traveling and my phone-number has changed half-a-dozen times in the past year
alone, my email has been the same for over a decade.

I tend to use Whatsapp because other people already have it but I have
absolutely no motivation to use encourage other people to use Signal.

Edit: Whoever down-voted this, want to explain how this isn't a huge user-
experience regression from giving your email and using gchat?

~~~
resonanttoe
You also have the reverse problem which is alluded to in the article, that a
Phone number for a non-traveller, is pretty static and unlikely to be changed
by the user often. However Email is more disposable and I can spin up and shut
down email accounts that I could register with Signal et., al. for what I
believe to be sensitive communications.

I feel that providers that use number-as-identity know this and use it as a
way of assuring they have greater confidence of knowing their user, especially
after everyone failed so spectacularly at real names policies.

~~~
forgotpwtomain
> Phone number for a non-traveller, is pretty static and unlikely to be
> changed by the user often. However Email is more disposable

I entirely disagree. Even without traveling outside the US - my US phone-
number has changed several times (change of carrier etc.); while it is
possible to spin-up and shutdown email accounts (e.g. dummy accounts for
services requiring registration) -- by this time _most_ individuals should
have a single _serious_ account (and a larger percentage in the future):
online bank statements, online bills, online shopping -- do you really not
have a single primary account?

------
MrZongle2
_" After Donald Trump’s victory in the US presidential election in particular,
many tweets recommended using hard disk encryption and the ostensibly secure
messenger app Signal while discouraging the use of competitor apps Threema and
Telegram."_

Oh FFS. We've seen a continuation of invasive, Bush-era policies under
Obama...but now _Trump_ is terrifying?

Spoiler alert: it has _been_ a problem for quite some time, and given the
alternative to Trump it was going to _still_ be a problem regardless of who
won the election: freedom ponies and rainbows were never an option.

Get a damn grip, people. Can we end the partisan pity party?

~~~
dragonwriter
> We've seen a continuation of invasive, Bush-era policies IRT the NSA under
> Obama...but now Trump is terrifying?

Uh, yeah. The Bush/Obama surveillance policies have largely been seen as
dangerous not because of actual concrete harms that have materialized, but
because if continued they raise the prospect of a much worse (because of the
increased scope possible with modern tools) version of the kind of political
targeting based on surveillance that was done by Nixon (prompting legal
limits, notably the original FISA act.) And perhaps even beyond that, to the
kind of retaliation for dissent seen in authoritarian regimes.

Trump is seen as the kind of figure that would be more likely than a more
conventional candilate of either party to make those theoretical risks into
concrete harms.

~~~
MrZongle2
I'm not buying it.

The house is already on fire, and people are wringing their hands because the
new owner might have a can of lighter fluid in his pocket.

~~~
dragonwriter
I would say that many people view the Bush/Obama surveillance policies more as
unreasonably dangerous highly flammable fuel stored in the house than an
actual fire, and Trump as more analogous to someone carrying an ignition
source than additional fuel.

I don't think many serious observers think that, whatever the potential, the
actual substantive harm has yet been even close to Nixon levels, though the
potential scope of intercepted communication (and hence, potential for harm
with simply a change of intent at the top) is much broader.

------
padraic7a
This is a fairly clear and level headed criticism, while I think the 'problem'
of centralisation is over stated and the accusations about Signal's motivation
are unfounded I do appreciate that the author(s?) understand why Signal is
popular - "The success of OWS can also be attributed to elitist and
bureaucratic positions in the open source community. "

I don't see the federation issue as being particularly relevant - at least not
until someone else actually sets up a non-OWS server and gains some users for
it.

~~~
qznc
The article also shows the problems with federation, although they do not
acknowledge it:

> The drafted protocol is called OMEMO and combines the advantages of jabber
> and Signal. Even though the XEP Process will still take some time, the
> protocol is stable and can already be used today. On Android devices, users
> have the ‚Conversations‘ client [8], which offers an experience comparable
> to Signal, and on the desktop there is a plugin for ‚Gajim‘ [9, 10] under
> active development, which still has room for user experience improvements.
> Using one of the readily available tutorials, it is possible today to get
> started on Linux and Windows. iOS users will have to wait some time due to
> license issues.

------
cypherpunks01
Has anyone else noticed a huge uptick in their contacts signing up for Signal
this month? I've added 12 contacts just in November bringing me to about 30
contacts subscribed to Signal total, which is a large increase. None of these
new contacts know each other, and only 25% of them know how to write software.

Does Signal publish registration numbers?

~~~
Joeboy
I imagine it's maybe down to the new Investigatory Powers bill in the UK, and
maybe Trump in the US. The former at least seems to have led to some
journalistic recommendations for Signal.

------
moxie
I'm repeating myself on many of these points, so I've cut and pasted some of
my previous responses:

> Signal uses servers controlled by OWS. Other organizations could conceivably
> operate their own servers because OWS open sources the software, but because
> OWS strictly opposes federation (meaning the interconnection of
> independently operated servers which the XMPP protocol (jabber) or e-mail
> allows), only the users connected to the OWS-run server can communicate with
> each other.

I've tried to write about why I don't feel like this is going to be a part of
our future here: [https://whispersystems.org/blog/the-ecosystem-is-
moving/](https://whispersystems.org/blog/the-ecosystem-is-moving/)

However, I would love it if someone proved me wrong. The Signal clients and
server already support federation, so there shouldn't be any technical hurdles
stopping the people who are really into federation from using our software to
start their own federated network that demonstrates the viability of their
ideas.

If anyone needs help doing that, let me know. I'd be happy to help.

> If a government does not approve of the use of Signal, it can simply block a
> single server farm, solving the problem for the state actor, and resulting
> in total loss of service to the users.

The authors of this article conflate a lot of things with federation.
Federation = anonymity, federation = metadata protection, federation =
censorship circumvention.

I don't think any of those are true. Email is federated, and I run my own mail
server, but almost every single email I send or receive has GMail at the other
end of it -- so running my own server does not provide me with any meaningful
metadata protection, even though it is a federated protocol. The idea that
everyone in the world is going to run their own mail server (or messaging
server, or whatever) has not born out in practice, even in environments that
natively support federation.

I think serious metadata protection is going to require new protocols and new
techniques, so we're much more likely to see major progress in centralized
environments that can change rather than federated environments that are stuck
in time (in the same way that Signal Protocol is now on over two billion
devices, but we're unlikely to ever see even basic large scale email end to
end encryption).

In the case of censorship circumvention, I think it's much more common that
people use censorship circumvention tools like VPNs or Tor rather than
changing their entire federated identifier (and somehow re-discovering their
entire social graph doing the same) every time a service gets blocked,
particularly since censorship isn't just as simple as host-level filtering
these days.

Again, I think we're more likely to see the incorporation of these types of
censorship circumvention techniques into centralized rather than federated
services.

> The community reacted to this by developing a version that does not rely on
> GCM, however, OWS refused to merge the changes into the Signal code.

I don't believe this is true. To clarify this for casual readers, no data at
all is transmitted over GCM. GCM is only used as a push event to tell the
Signal Android client to wake up and connect to the Signal server to retrieve
messages from the queue if the app isn't in the foreground.

This is pretty fundamentally just how Android works. However, people who want
to use Google's OS without any Google services flash custom ROMs onto their
devices that are missing this dependency.

I have said many times that I have no problem with supporting these custom
ROMs. But I would like someone from that community to submit the PR: "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."

Nobody has done it.

> The final point of criticism is that OWS distributes the Signal app
> exclusively via Google Play while actively preventing the distribution of
> independent builds.

We'd love to distribute Signal outside of Play, and have written about what we
would need to be able to do so. As of yet, nobody from the FOSS community has
stepped in to help.

We'll get there eventually on our own, but we have a lot of work on our plate,
and have to set our priorities according to what we think is important for
Signal as a whole.

> The community’s demands for decentralized web services controlled by the
> users themselves, or by designated professionals elected by the users, seems
> like a burden to them.

I do not feel like the FOSS community is a "burden," however I do wish they
recognized that many of their desires are unique to a very small minority of
Signal users. I wish that they'd take more responsibility for manifesting
those desires themselves.

This is the second time in two months that someone from the FOSS scene has
written up a list of complaints, but as far as I know, in neither case have
the authors ever contributed anything to Signal in an effort to meet their own
needs.

~~~
eggie
> I do not feel like the FOSS community is a "burden," however I do wish they
> recognized that many of their desires are unique to a very small minority of
> Signal users. I wish that they'd take more responsibility for manifesting
> those desires themselves. > This is the second time in two months that
> someone from the FOSS scene has written up a list of complaints, but as far
> as I know, in neither case have the authors ever contributed anything to
> Signal in an effort to meet their own needs.

I think that the interest in the FOSS community is relatively low given the
centralized format in which Signal is offered. I know many people who are
deeply into FOSS who would love an alternative to IRC but cannot be found even
using Signal. But "their own needs" are completely out of bounds for you, and
it seems pretty clear that this isn't something that's going to be fixed in
patches and code, so expecting them to come and fix it because you have an
open code base is rather disingenuous.

If you started by promoting Signal as a generic protocol or backend to other
projects, it would get much more traction in the FOSS community, as they are
attracted to components on which other things can be built.

You can claim that this is a reason to ignore the criticism. But, you will
always be right in dismissing critiques like this as you've set up the
environment in a way which limits the kind of constructive collaboration that
is the hallmark of FOSS.

You will probably say this is not true and cite existing public contribution
to the project. But what I am saying is that the interest and contribution
would be orders of magnitude larger if you really ran the project in a
traditionally open way. One hallmark of this would be federation. Whether or
not this makes sense practically (the gmail metaphor applies obviously), it is
something that people want an need to order to feel they have ownership of
their work on a messaging platform. You're simply not going to talk your way
out of this.

For human and community reasons, the upside to federation is probably a lot
higher than you appreciate. I hope you consider it. You have built a nice
platform, but for your work to make a lasting impact you need to share it with
others.

~~~
moxie
> _But "their own needs" are completely out of bounds for you, and it seems
> pretty clear that this isn't something that's going to be fixed in patches
> and code, so expecting them to come and fix it because you have an open code
> base is rather disingenuous._

Many of the things listed in these articles, such as making GCM optional, or
supporting distribution outside of Play, are not "completely out of bounds."
We've expressly indicated support for them and enumerated the work required,
but nobody has committed to doing the work.

I don't expect anyone to do the work, but I do think it's strange when someone
from the FOSS community complains that we haven't done it for them.

> _If you started by promoting Signal as a generic protocol or backend to
> other projects, it would get much more traction in the FOSS community, as
> they are attracted to components on which other things can be built._

Signal is broken into three layers, two of which are designed to provide
exactly that:

A crypto protocol that can be incorporated into other projects:
[https://github.com/whispersystems/libsignal-protocol-
java](https://github.com/whispersystems/libsignal-protocol-java)

A service protocol that can be pointed at any back end:
[https://github.com/whispersystems/libsignal-service-
java](https://github.com/whispersystems/libsignal-service-java)

The service protocol even includes support for federation. I don't think it's
a good idea for the reasons I've enumerated, but anyone can use this code to
start their own federated network and prove me wrong.

> _For human and community reasons, the upside to federation is probably a lot
> higher than you appreciate. I hope you consider it. You have built a nice
> platform, but for your work to make a lasting impact you need to share it
> with others._

We've done more than consider it, we've done it. We started Signal as a
federated service, and it was kind of a disaster.

I'd definitely reconsider if people have a plan for avoiding the problems that
we encountered the first time, beyond "federation is good." In the mean time
I'm happy to help anyone deploying Signal in their own federated environment.

~~~
eggie
> Many of the things listed in these articles, such as making GCM optional, or
> supporting distribution outside of Play, are not "completely out of bounds."
> We've expressly indicated support for them and enumerated the work required,
> but nobody has committed to doing the work.

> I don't expect anyone to do the work, but I do think it's strange when
> someone from the FOSS community complains that we haven't done it for them.

The linked article notes that you have not been so supportive of such
developments in the past:

> The community reacted to this by developing a version that does not rely on
> GCM, however, OWS refused to merge the changes into the Signal code. When
> the project was forked, they prevented the newly established LibreSignal
> project [5] from connecting to Signal’s servers and prohibited the use of
> the term “Signal” in their name.

Reading through the comments that are linked it looks like you mostly had
technical concerns about the work. Is that correct?

Clearly the perception of your actions is different than you intend. In your
comment here you make it sound like no one had even attempted to do resolve
these issues. But that's not what the author of the article believes, and
given the public record I'm inclined to agree.

> I'd definitely reconsider if people have a plan for avoiding the problems
> that we encountered the first time, beyond "federation is good." In the mean
> time I'm happy to help anyone deploying Signal in their own federated
> environment.

Your key point is that you're content if people do federation in their own,
outside of your domain. That's fair. But what I'm saying is the dream of a
federated secure messaging system that's also popular is something which you
have the power to chase if you commit to it by making it a core feature of
Signal.

~~~
moxie
> _Reading through the comments that are linked it looks like you mostly had
> technical concerns about the work. Is that correct?_

> _Clearly the perception of your actions is different than you intend. In
> your comment here you make it sound like no one had even attempted to do
> resolve these issues. But that 's not what the author of the article
> believes, and given the public record I'm inclined to agree._

From that original discussion on LibreSignal:

"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, since we still don't have the things we need to be
comfortable distributing software outside of Play."

I have repeated that many times. That was June. Nobody has done the work, but
plenty of people have written articles like this. The latter is definitely
easier.

> _Your key point is that you 're content if people do federation in their
> own, outside of your domain. That's fair. But what I'm saying is the dream
> of a federated secure messaging system that's also popular is something
> which you have the power to chase if you commit to it by making it a core
> feature of Signal._

Again, we already committed to making it a core feature of Signal, and it was
a disaster. We've learned from our mistakes.

If it's something that you think is important, please get involved in the
project and come up with a plan to introduce federation in ways that actually
deliver on the promise of metadata hiding, anonymity, and censorship
circumvention as well as avoid all of the problems that we documented based on
our initial attempts.

------
gfodor
My main beef with signal is that they release their encryption libraries as
GPLv3 not LGPLv3, preventing the use of them in any commercial product that
doesn't want to open their source code.

Yet, they "worked with" Facebook and WhatsApp to incorporate their protocols
presumably providing them with an alternative license. It sure would be nice
if companies who wish to add encryption to their messaging products, but
didn't have the pull of the bigger guys to warrant OWS's attention, could just
use an LGPLed library to do so. If OWS's mission is to bring about widespread
encrypted communications, playing favorites with a few larger messaging
companies seems to send the wrong message.

(The points made in the article, while valid, seem to be splitting hairs
relative to the overall net good Signal has provided.)

~~~
skndr
Why do you think that might be? I can imagine that requiring others to open
their source makes their implementation verifiable.

~~~
gfodor
Exactly, which is why they should have required Facebook and WhatsApp to
comply with the GPL. Alternatively, they should have created a more flexible
license that could be used by Facebook, WhatsApp, or other companies to
integrate their software. My point isn't about the GPL per se, but about the
unfair playing field they are creating.

~~~
dublinben
I think the GPL is actually a perfect license in this case. Anyone who wants
to use their cipher in another GPL project is free to. Commercial entities who
won't do this can pay OWS for their time, expertise and IP in order to get a
different license.

~~~
gfodor
That makes sense -- I guess what it boils down to is it would be nice if OWS
were more open about their commercial licensing options, and make it easy for
a company to license + integrate their work. As it stands right now it feels
like you have to be a Facebook/WhatsApp level company to be able to be worth
their time to work with.

------
bikamonki
I do not see any comments to tackle the weakest link: exploits on the OS.
Federated or not, the tunnel can be encrypted. On the servers static data can
be encrypted. How can a _regular_ user know his/her device's OS is not
compromised? That is the problem to solve now and it seems that a formally
verified OS code is the only long path.

~~~
lorenzhs
That's not an argument for or against Signal, though, as it affects all
messenger apps in the same way. While OS trustworthiness is an interesting
topic, it's not really the one being discussed here.

~~~
bikamonki
It seems you did not read the article thoroughly. The argument being made is
that Signal is sending the WRONG signal by making the user think/feel that
encrypting the tunnel and passive data is enough to guarantee privacy and
security.

Quoting:

 _There are many things users can and maybe should be concerned about:
Hackers, providers, promoters, crooks, spooks, shareholders or maybe the
person on the next seat in the bus. Do they want to prevent their data from
being used for other purposes than communication itself? Maybe they want their
messages to be tamper-evident, or perhaps they want plausible deniability or
immunity against eavesdropping? What is the use of end-to-end encryption when
there could be a key logger or a rootkit on their device, transmitting
everything they do to a remote entity? Encouraging users to believe in a
general sense that Signal makes their communication safe, will tend to promote
a false sense of once-and-for-all security (regardless of the indisputable and
substantial increase in end-to-end encryption). It is very important to
remember that even though encryption will increase security, some information
should not be stored in IT systems at all – and especially not if they are
provided by a third party.

However this is no argument against the use of the Signal messenger or
protocol itself. We instead want to think about the problems created or
supported by OWS‘ promise of security._

------
45h34jh53k4j
Im surprised nobody has mentioned Quellen-TKÜ -- is there any evidence that
governments can force handset vendors to push malware to devices?

I don't believe this, as it would make programs like QUANTUM* unneeded. Why
subvert global internet infrastructure if the providers do the dirty work?

This would be explosive if true

