[HN Gopher] Signal on Android: Images sent to wrong contacts
___________________________________________________________________
Signal on Android: Images sent to wrong contacts
Author : jiripospisil
Score : 516 points
Date : 2021-07-25 16:55 UTC (6 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| herpderperator wrote:
| A lot of people are talking about the bug but not the fix.
|
| Is anyone else incredibly surprised that the fix was just adding
| auto_increment to the primary key column for two tables[0][1]?
| Not having these as auto_increment seems like incredible
| oversight to me. In what common scenario would you want a setup
| like that?
|
| [0] https://github.com/signalapp/Signal-
| Android/commit/83086a5a2...
|
| [1] https://github.com/signalapp/Signal-
| Android/commit/b9657208f...
| xirtam wrote:
| Can we get a better understanding of the root cause and blast
| radius?
|
| You say, "if someone had conversation trimming on, it could
| create a rare situation where a database ID was re-used in a way
| that could result in this behavior."
|
| Is this someone user A or user B? Where is this database and what
| is it storing? Are these images previously sent or received from
| either A or B, or are they possibly from some thread between
| users C and D? How does this agree with end-to-end encryption?
|
| How can you expect people to use your product with a bug this
| severe and no analysis of the impact or a statement as to who
| might have been affected?
| eternalban wrote:
| I'm not up on my signal protocol but using PGP, sending encrypted
| messages to the wrong person would result in them getting an
| encrypted message they can not decipher. If a bug in signal
| allows a third party to decrypt a message intended for another
| person, does that means that signal servers see plaintext
| messages?
| Santosh83 wrote:
| Is this some kind of cache bug? Pretty serious, whatever it is,
| and judging by the linked issue, they either haven't taken it
| seriously, or worse, they aren't able to pinpoint the bug.
| hypertele-Xii wrote:
| Re-using of message IDs.
| lopatin wrote:
| I have no horse in this race. I don't use Signal or any of its
| competitors, so allow me to ask some basic questions.
|
| Could some users explain why you currently use Signal, and
| additionally, why you would continue to do so? It appears to me
| that not only this bug, but more importantly, the laissez-faire
| resolution of it is the opposite of what a privacy based app
| should do.
|
| Based on their homepage, it looks like they're proud of the fact
| that Snowden uses the app. I'm interested if he, as a person with
| "real shit" to hide, still does.
| afroboy wrote:
| I live in authoritarian country. so yeah Signal is the answer
| and my country does fear it and trying to block it. They don't
| fear whatsapp, telegram or facebook but they do fear signal.
|
| And weird this bug never encountered with me.
| ghoward wrote:
| Personally, I use it because it was the best choice a couple of
| years ago, and I (somewhat recently) managed to convince family
| to use it too.
|
| However, after this, I am probably going to set up my own
| Matrix server and use that as much as possible, encrypted of
| course.
| beermonster wrote:
| Fixed in 5.17, though I only have 5.16.1 available to me despite
| the fact it's supposed to be available from a few days ago.
| kiwijamo wrote:
| My Android phone has 5.17.3. What platform are you on?
| beermonster wrote:
| iOS
| proactivesvcs wrote:
| This bug seems to only have affected Android. 5.17 is still
| in beta for iOS.
| jerkstate wrote:
| Signal has been adding lots of silly social media like features
| lately, not surprising that they are messing up the core value
| prop. I'm shopping for a new encrypted messenger. They used to
| say every program expands in scope until it can read email, now
| every app expands until you can add Snapchat filters to your
| selfies.
| hkt wrote:
| Delta chat starts from reading email and theb works backwards:
| https://delta.chat/en/
| maqp wrote:
| Cool, my contacts can keep using their gmail account and leak
| all communication metadata to Google without me having any
| say on that if I want to talk to them. Where can I sign up?
| hkt wrote:
| Maybe gently encourage your contacts to use another
| provider?
| maqp wrote:
| Nah, easier to get them to Signal when a large portion of
| their peers is already there. Plus Signal's more secure
| than Delta-Chat that's not even forward secret, that
| isn't audited, and that's using 30 year old PGP.
| godelski wrote:
| Personally I want to have secure communications with _all_ my
| friends and family, not just the paranoid tech nerds and people
| I can pressure into it.
|
| If this is what the masses want, give it to them. Encryption
| only works if people use it.
| dunefox wrote:
| Threema seems great so far. Not many users though, sadly.
| Element (matrix.org) is good as well, but it's not polished and
| lacks users as well.
| tgsovlerkhgsel wrote:
| The only possible competitor (from a network effect
| perspective) is Matrix/Element.
|
| The UX is completely unpolished and at least 5 years behind
| Signal.
| jMyles wrote:
| Every time something like this comes up, I say something like,
| "Who wants to switch to Matrix (ie, Element, and before that,
| Riot Chat)?"
|
| But then, I myself don't end up doing it, largely because of
| the network effect on Signal.
|
| I think we need to just remember to always keep 3-5 of them
| open so we can have some horizontal evolution.
| beermonster wrote:
| I've tried Element. I think Signal is probably easier to
| setup and use for most non-technical people on comparison.
| JohnJamesRambo wrote:
| I hate the new ability to add emoji responses to message chat
| bubbles. It has turned my conversations (especially group ones)
| into a Facebook like experience where everyone expects a cry
| face emoji or heart on everything they say. It gives me that
| same feeling of dread I used to get when I had a Facebook. I
| just want to send and receive text messages, not be engaged
| constantly to my phone.
| beermonster wrote:
| Which makes it like using Slack!
|
| I for one would rather they spent less time on these
| 'features'.
| TheChaplain wrote:
| It's necessary if you want to attract the mainstream users, who
| could not care less for e2e security but values stickers,
| filters and stories above all else.
| jchook wrote:
| I use delta-chat (chat over imap) and it's fantastic.
|
| Decentralized / federated e2e chat, running on the Internet's
| most well-known, resilient, universally supported, self-
| hostable infrastructure: email.
| jeroenhd wrote:
| How does delta deal with new chats, fallback and other
| standard email client stuff? Does it allow mixing encrypted
| and unencrypted messages? What happens if I use an
| alternative mail client, will I still be able to read email
| from people after the project dies and the clients stop
| working?
|
| I don't think people will appreciate it when I suddenly start
| using email as a standard communications method, but it's
| worth a shot. The client looks like a copy of Telegram (a
| good thing, in my opinion) and everyone already has email, so
| I'm willing to give it a shot I guess. I'm currently on the
| Matrix camp but it's not like that's a protocol many non
| techs use in the real world.
|
| I'm just wary of using email for this because of all of the
| previous failures to secure email, like PGP, S/MIME and
| variations thereof.
| jchook wrote:
| > Does it allow mixing encrypted and unencrypted messages?
| What happens if I use an alternative mail client, will I
| still be able to read email from people after the project
| dies and the clients stop working?
|
| Yes. It uses the AutoCrypt standard, which exists
| independent of delta chat and has standalone software, +
| plugins for various email clients. I use a plugin for mutt
| so I can read my delta chat messages without the official
| client. You can issue new key pairs or turn off e2e as you
| like.
|
| > I don't think people will appreciate it when I suddenly
| start using email as a standard communications method, but
| it's worth a shot
|
| Fair, though perhaps technically simpler than getting
| others to download Yet Another Chat App(tm).
|
| > ...previous failures to secure email, like PGP, S/MIME
| and variations thereof.
|
| Did PGP and S/MIME fail? Services like ProtonMail use that
| tech to great effect. IMO it never hit the main stream
| because mainstream mail providers, etc want to read your
| email. There's some argument about usability but after
| using ProtonMail I don't buy those arguments.
| jeroenhd wrote:
| > Did PGP and S/MIME fail? Services like ProtonMail use
| that tech to great effect. IMO it never hit the main
| stream because mainstream mail providers, etc want to
| read your email. There's some argument about usability
| but after using ProtonMail I don't buy those arguments.
|
| In my personal experience, I've never seen anyone use PGP
| extensively for more than a month or so. The lack of PGP
| in most common mobile mail clients certainly doesn't
| help; switching email apps is annoying.
|
| I don't think companies reading your email is the main
| incentive for companies to not implement PGP. It's
| perfectly possible to do PGP server side for free mail
| accounts like Gmail or Outlook, with proper PGP support
| in Outlook, Thunderbird, Apple Mail, etc.
|
| PGP is complex, especially for people who don't know
| cryptography, and the lack of cloud sync of private keys
| and central account management makes it much harder to
| use than modern chat applications even for non-novice
| users.
|
| I've never used ProtonMail and I don't know anyone who
| does, so my experience may not be representative. Then
| again, the fact I don't know anyone who uses ProtonMail
| might also indicate that PGP still hasn't gained that
| much market share.
| FabHK wrote:
| It seems to use E2E encryption with some trust-on-first-use
| protocol called Autocrypt:
|
| https://delta.chat/en/help#encryption
| dividuum wrote:
| I really like the idea of delta chat, except that I cannot
| bring myself to allow it access to my full imap mailbox. And
| most providers do not offer a way to scope access to only
| selected folders.
| jchook wrote:
| You can use a separate mailbox just for delta chat
| dividuum wrote:
| Sure. But that throws away the advantage of already
| having an identity.
| [deleted]
| hellcow wrote:
| Matrix is a solid replacement. Element isn't as easy to use but
| it's coming along. Quality-of-life features normal users expect
| like stickers, gifs, etc. are woefully lacking, but the
| important stuff (y'know, actual messaging) is solid.
|
| The most important thing to me is if Element screws up like
| Signal and starts pushing a shitcoin, I can swap clients
| without affecting my network.
| dindresto wrote:
| Also, Matrix supports other client implementations than
| Element, like https://fluffychat.im/
| markzzerella wrote:
| Fluffychat is my go-to for getting normies on matrix.
| pxeboot wrote:
| While I hate these features as much as everybody else on HN,
| they are likely necessary if they ever want the app to go
| mainstream.
| pantalaimon wrote:
| Wouldn't XMPP fit the bill?
| brobinson wrote:
| Threema is worth a shot. Signal looks promising but isn't quite
| there yet.
| egberts1 wrote:
| Matrix, in non-federated mode, is by far the toughest messaging
| protocol to crack.
|
| Still dependent on proper UI engineering, like Signal failed to
| do.
| maqp wrote:
| >by far the toughest messaging protocol to crack.
|
| Citation needed.
| Barrin92 wrote:
| is Wire still around and does somebody know if it's good? I
| remember reading about it because it used Haskell but I never
| tried it out.
| FabHK wrote:
| I used it and found it excellent, fully featured
| (chat/voice/video), use phone or email as identifier, and
| supported on all devices (iOS, Android, Mac, Win, Linux).
|
| I don't understand why it didn't take off - seems like a
| modern version of Betamax/VHS to me.
| antihero wrote:
| They can't even be bothered to do 2FA
| FabHK wrote:
| Which messenger apps can be bothered to do 2FA?
| pgalvin wrote:
| Signal requires a PIN and an SMS code. WhatsApp has the
| option to add a password in addition to the SMS code.
| There are probably others.
| Rd6n6 wrote:
| It's not enough for signal to work for tech people. You have to
| be able to convince your family and friends to use it, it's a
| network effects problem. They are adding features so that
| ordinary people can have private communications
| GuB-42 wrote:
| If that's the case, why did they remove SMS import?
|
| It used to be "just install that, you will be more secure and
| won't notice the difference". To "you will lose all your
| messages".
| ikiris wrote:
| ordinary people don't give a flying f** about being able to
| send someone crypto currency via their messaging app.
| ViViDboarder wrote:
| Though many of their competing apps support this feature.
| Facebook, Apple, WeChat, etc.
| renewiltord wrote:
| But everyone wants to send money or money-equivalents. I
| use Venmo almost every other day.
| alksjdalkj wrote:
| This is a good reminder that no matter how security and privacy-
| focused a project is, we still don't know how to reliably develop
| software without bugs - and all it takes is one bug to negate all
| of those security and privacy features.
| yawaworht1978 wrote:
| Do users se wrongly sent images in outbox/sent?
|
| Did the transfer always happened immediately or with a delay?
|
| Did the transfer or chat always had to have a gif sent?
| greysonp wrote:
| Hi there, Signal-Android developer here. I updated the issue to
| reflect this, but this bug has been fixed. I was tracking it on a
| separate issue, and had forgotten to close this one.
|
| We do, in fact, take issues like this very seriously. This bug
| was extraordinarily rare, and because we have no metrics/remote
| log collection, there was an initial period where we had to spend
| time adding logging and collecting user-submitted logs to try to
| track it down. As soon as we were able to pick up a scent, it was
| all we worked on, and we were able to get a fix out very quickly.
| GekkePrutser wrote:
| One thing I wonder is: how could this happen at all?
| Considering the E2E Encryption in place, I would expect the
| incorrect recipient simply wouldn't be able to decode the image
| considering they never have exchanged keys with the sender?
| runarberg wrote:
| Not a signal developer, but I would imagine it would be
| fairly simple that the same bug also encrypted the message
| with the eventual receiver's key (as opposed to the
| _intended_ receiver's key). Resulting in a message which the
| eventual receiver could decrypt but not the intended
| receiver.
| rasengan wrote:
| You should have shut down the servers while this was happening
| - especially because you couldn't track it down. Shame on you
| for not caring about your users or their privacy when they were
| specifically using Signal for privacy.
|
| Edit: Anyone downvoting this also simply doesn't understand how
| serious this privacy leak really is. Shame on you too.
| NavinF wrote:
| It's pretty much impossible to distinguish rare bugs from
| user error if you don't have logging/telemetry.
| jraph wrote:
| > Edit: Anyone downvoting this also simply doesn't understand
| how serious this privacy leak really is. Shame on you too.
|
| Wouldn't showing a warning suggesting not to post sensitive
| images while the bug is being investigated be better than
| straight up shutting down the service while solving the
| privacy issue?
|
| Wouldn't closing the service have made people leave for other
| (probably worse) services, the one relying on privacy,
| privacy-minded people and "regular users" alike, and have
| worse consequences for privacy than this bug?
|
| (not currently a Signal user, and I did not downvote your
| comment)
| [deleted]
| miken123 wrote:
| I find this quite concerning and am really wondering if there
| are any privacy advantages to Signal if these things happen.
|
| Could you say something on:
|
| 1. Have any defend in depth measures been applied in the
| Android and other clients to make sure this issue does not
| happen again? E.g., an additional check when sending/encrypting
| a message to make sure it is absolutely meant for the person it
| is being send to? 2. Why did it take 8 months to fix this if
| some users could reproduce it consistently?
| reinforcedpaper wrote:
| From the explanation of the bug on github it seems to me like
| this is a client-side database issue and nothing was actually
| leaked. Database ids were reused so random images that were
| previously received were displayed in newly received messages.
|
| Is this correct? If it is then it's probably worth mentioning.
| tgsovlerkhgsel wrote:
| My understanding is that the database issue caused your
| client to send pictures A, B and C to person X, when you were
| trying to send picture C to person X (where A and B are
| pictures that were previously sent to someone else).
| reinforcedpaper wrote:
| The person reporting the issue specifically said that they
| couldn't find those pictures on their phone and don't
| remember ever sending them to anyone.
|
| The recipient also wouldn't be able to find those images
| anywhere else because they have chat trimming enabled. The
| result is that because a newly received message happened to
| share the id of an old deleted message, the new message is
| now displaying pictures from the old message.
|
| This does require the recipient to have received those
| pictures and also not remember them but I believe it is
| easier to forget a random picture you received than one you
| sent.
|
| Again, this is me speculating with very limited knowledge
| of client internals but it makes sense to me. I would like
| to see a developer confirm this.
| TekMol wrote:
| Can you provide a link to the commit that fixes it?
|
| Shouldn't there have been an announcement to inform users what
| has been leaked and under which circumstances?
|
| How can user A send an image to user B that neither of them
| took? Isn't everything end-2-end encrypted? Then how can
| unencrypted data from user C end up on the device of user B?
| agilob wrote:
| No PR with name that would suggest the fix in the client
| https://github.com/signalapp/Signal-
| Android/pulls?q=is%3Apr+...
|
| and no PR from OP in the opensource part of the server
| https://github.com/signalapp/Signal-
| Server/pulls?q=is%3Apr+i...
| seg_lol wrote:
| *edit, I think this issue was specific to the Android
| client, the desktop client has a totally different sqlite
| schema.
|
| The child comment to your comment is deleted, but I think
| autoincrement IDs shouldn't be used under an ambient
| authority context.
|
| It would make more sense to have IDs based on an LSF or
| Feistel sequence, perhaps split into a master ID and a
| conversation sequence.
|
| Autoincrement on this field makes it easy for off by one
| errors. Even just moving to guids and maintaining a proper
| parent child relationship would have prevented this.
|
| Or maybe there should be a database per conversation (set
| of all parties).
|
| https://github.com/signalapp/Signal-
| Android/commit/83086a5a2...
|
| https://github.com/signalapp/Signal-
| Android/commit/b9657208f...
|
| Row IDs shouldn't have so much power.
| WesolyKubeczek wrote:
| The good thing about autoincrementing unsigned 64-bit
| integers is that 1) it's insanely fast, 2) SQLite is
| doing it automatically, 3) seriously, why don't they have
| it on all tables yet? SQLite guarantees no collisions
| within a table.
|
| Doing homegrown ID generation is how such bugs are being
| introduced in the first place. Your application level
| trigger got bypassed, oops. Your check was experimentally
| disabled and left like that for a year until people
| started noticing, oops.
|
| If you make an SQLite-backed application and it has a bug
| like this, I can safely bet $500 it's not going to be
| SQLite that has the bug.
|
| Just don't expose the numeric IDs in links, and generate
| your UUIDs in tables where you need to point to rows in
| an outside-accessible link. This is database 101, for
| crying out loud.
| [deleted]
| tomudding wrote:
| > Can you provide a link to the commit that fixes it?
|
| If I understand the issue [0] correctly, these two commits
| should be the fix:
|
| https://github.com/signalapp/Signal-
| Android/commit/e90fa05d6...
|
| https://github.com/signalapp/Signal-
| Android/commit/b9657208f...
|
| The former updates how recipients (or really threads, I
| suppose) are merged (the issue occurred when trimming
| threads) and the latter changes the way how thread ids are
| generated (now automatically incremented). Together they
| should prevent unrelated recipients (threads) from being
| merged.
|
| [0]: https://github.com/signalapp/Signal-
| Android/issues/10247#iss...
| [deleted]
| winrid wrote:
| I love the terrible commit name. "Updating recipient
| merging."
| hackinthebochs wrote:
| Using incrementing ids as your source of ownership is just
| asking for trouble. This just means a programming error can
| have a high probability of ids lining up and leaking
| resources. Guids make this practically impossible.
| Popegaf wrote:
| From the explanation [0], this looks like the commit [1].
|
| I do have to say though, the commit messages are very barren
| and barely any reference an issue directly. My guess is that
| they develop on private branches with an internal issue
| tracker and decide not to reference issues as that would be
| confusing. It would help a bunch if they referenced the
| public issues and made it clear which issues they're working
| on. They don't seem to use Github Projects [2].
|
| All in all, the communication / transparency of the project
| is lacking - even though I'm glad they're providing something
| usable. Hopefully Matrix will be able to provide something as
| easily usable as well.
|
| [0]: https://github.com/signalapp/Signal-
| Android/issues/10247#iss...
|
| [1]: https://github.com/signalapp/Signal-
| Android/commit/83086a5a2...
|
| [2]: https://github.com/signalapp/Signal-Android/projects
| konschubert wrote:
| If it's a client bug that just switches out recipients, then
| the messages will just get encrypted for the wrong recipient.
| lwhi wrote:
| I appreciate that this was a difficult and rare bug, but for an
| app that sells itself as 'secure', it feels like this isn't
| acceptable.
|
| How can users be assured that this type of issue won't occur
| again?
| hnarn wrote:
| Users are not entitled to a guarantee that this will never
| happen again, because Signal is free and open source software
| provided free of charge and without warranty.
|
| The Android app is GPL licensed. The license clearly states:
|
| > For the developers' and authors' protection, the GPL
| clearly explains that there is no warranty for this free
| software.
|
| If you feel let down by open source software, you have many
| options available to you to make that software more reliable.
| ghoward wrote:
| Moxie Marlinspike is famously belligerent against Signal
| forks, so no, the license does not really help here.
| sneak wrote:
| It does. You are allowed to fork or reimplement the
| Signal client, and even distribute it, with the official
| Signal servers configured, so long as you do not infringe
| the Signal trademark.
|
| They don't like forks using their servers, but it's the
| _users_ who connect to their servers, not the fork
| publisher. Those users are permitted to connect via the
| TOS, which is independent from the GPL.
| lwhi wrote:
| They also refuse to open source their server software.
|
| This is the problem in my mind. Open source in words, but
| not spirit.
| tablespoon wrote:
| > How can users be assured that this type of issue won't
| occur again?
|
| By not using software.
|
| And I mean software in general, not this software in
| particular. You're basically asking for assurance that they
| won't have any more bugs, but _no one_ can actually provide
| such an assurance in the real world.
| lwhi wrote:
| I disagree. If that really is the choice, they should drop
| the secure moniker without further debate.
|
| --
|
| If you produce a product that claims to be secure, the onus
| is on you to back up those claims.
|
| Off the top my my head there are many ways to implement
| measures that can help to encourage security going forward.
|
| One of the benefits of coding in the open, and ascribing to
| opens standards and protocols is transparency and the
| ability for all to interrogate the code.
|
| Can that work? It's obviously partly also down to the
| culture of the product team. As another poster in this
| thread has highlighted, the commit messages are terse and
| not as helpful as they could be. Perhaps more openness re.
| intention would help.
|
| Also, why are we finding out about this bug over 7 months
| after it was reported? Transparency regarding
| vulnerabilities needs to be at the forefront of the
| products communications if the team really are serious
| about security.
|
| In terms of isolating bugs; what kind of testing is in
| place. TDD, functional testing, beta testing?
|
| There are so many avenues which _could_ be discussed in
| relation to my initial question.
|
| Your response, is unfortunately not providing anything
| helpful.
| asdfasgasdgasdg wrote:
| > One of the benefits of coding in the open, and
| ascribing to opens standards and protocols is
| transparency and the ability for all to interrogate the
| code.
|
| They already do all of those things.
| https://github.com/signalapp/Signal-Android
| lwhi wrote:
| You need to reread my post.
|
| The situation is far more complicated than your link to
| the GitHub repo would indicate.
| hellcow wrote:
| In word but not in spirit. They stopped updating their
| repo for an entire year while integrating a crypto
| shitcoin in secret.
|
| These actions betray trust, and trust is Signal's entire
| reason for being.
| asdfasgasdgasdg wrote:
| What does it mean for it to "not be acceptable?" Accepting or
| not accepting the bug is not an option on the table. It
| happened. The options you have open to you are to use or not
| use the freely provided software, or donate or not donate to
| the foundation providing it. Users _cannot_ be assured that
| future bugs will not occur. That is an assurance that is not
| available with most consumer software, and certainly not with
| software delivered for free by a not-for-profit.
| goodpoint wrote:
| > How can users be assured that this type of issue won't
| occur again?
|
| By writing code defensively. Despite the other comments, it's
| possible.
|
| The key is to be redundant: for example, off-by-one errors
| are very common when accessing an set of indexed items by
| number.
|
| Yet you can split the set (e.g. an array) in multiple ones to
| make it more unlikely that you pick the wrong item (e.g.
| picture vs users).
|
| You can also "tag" the outgoing image with some attributes,
| e.g. the recipient and a sent/not-sent flag.
|
| You can cross-check and stop if something is inconsistent.
| Many other things are possible e.g. to protect from RAM bit
| flips.
|
| It's not a matter of language or tooling, it's a matter of
| mindset.
| eganist wrote:
| > By writing code defensively. Despite the other comments,
| it's possible.
|
| I'm going to tack onto this and suggest that signal
| drastically slow down the pace of feature development. They
| don't have the same profit motivations other companies
| have. The messaging market, at least in its current state,
| is largely _known._ These both give Signal an advantage in
| that they can slow down and harden the product while baking
| security into their DevOps practices as a first class
| citizen.
|
| Tl;dr: signal needs to slow down.
| renewiltord wrote:
| The answer is that you can't be assured. Act as you will with
| that info.
| nerbert wrote:
| 'Many forms of secure messaging systems have been tried, and
| will be tried in this world of sin and woe. No one pretends
| that Signal is perfect or all-wise. Indeed it has been said
| that Signal is the worst messaging except for all those other
| forms that have been developed from time to time...'
|
| Winston S Churchill, 11 November 1947
| geofft wrote:
| Sure, but there's a small theoretical difference with
| democracy. You have to live under some system of
| government. You don't _have_ to use a secure messenger. You
| can choose to have sensitive conversations in person or not
| have them at all.
|
| I agree that in practice, a lot of people are going to use
| their phones for relatively sensitive conversations, and in
| practice, Signal remains the best choice for doing so. But
| there are a few real threat models where the options aren't
| Signal vs. SMS / Google Chat / Discord / etc., the options
| are Signal vs. nothing. For instance, you could be a
| journalist deciding whether to ask clarifying questions to
| a government whistleblower via Signal or meet up with them
| in a park. You could be an activist/demonstrator under a
| repressive regime deciding whether to coordinate some
| action this weekend via Signal or hold off on it entirely
| and tactically preserve your freedom. And so forth.
|
| For those people, _if_ (and to be clear this is a big
| "if," while this issue is one serious piece of evidence it
| is nonetheless inconclusive) Signal isn't trustworthy, it
| doesn't matter if Signal is the least-bad of the options.
|
| (Also, it's not like Signal is the only e2e messenger
| around. There's iMessage/FaceTime, for instance.
| Churchill's claim was that the abstract idea of democracy
| was good, not that any concrete implementation like the
| British government was good.)
| helmholtz wrote:
| You make some fair points. But even from the eyes of
| those people, what is the alternative? Is iMessage
| guaranteed to not have any hidden exploits out there? And
| on the flip side, what do they lose out on by _only_
| having those conversations in person? Well, I 'd argue
| that their world becomes a lot smaller, and there sources
| are instantly at a higher risk.
| geofft wrote:
| If iMessage were sending photos to the wrong people (even
| with extremely low probability) for over half a year,
| there would be serious negative publicity to Apple for
| it, even if they had never implemented end-to-end
| encryption. Apple also has more software testers and more
| willingness to use telemetry. So while there are no 100%
| guarantees, I think the incentives are aligned with
| iMessage at least as well as they are with Signal.
|
| Apple suffered negative publicity from the 2014 iCloud
| photo leaks, even though those were "just" phishing and
| not a vulnerability/bug in the strict sense. Tim Cook had
| to give statements to the media, and in fact Apple
| stepped up its phishing protection by pushing two-factor
| authentication and notifying users about additional
| iCloud logins.
| godelski wrote:
| > You can choose to have sensitive conversations in
| person or not have them at all.
|
| I don't think this is fair. Most of the solution to this
| is "not having them at all." That's not a good solution
| and still doesn't solve your problem since you can still
| be listened to.
|
| > There's iMessage/FaceTime, for instance.
|
| Which also has gotten in trouble recently with Pegasus as
| there was a 0-click exploit in iMessage. Honestly, that
| is a far more serious issue than the one here. That being
| said, I still trust iMessage and that the devs are doing
| the best that they can. I just recognize that security is
| difficult and will always be a cat and mouse game. There
| is no such thing as perfect security.
| geofft wrote:
| I think what I'm trying to get at is that _incorrectly
| believing_ you have access to a secure messenger can be
| worse than acting as if you don 't, if those are your
| options. The whistleblower might choose not to make
| contact, but if the alternative is making contact and
| immediately going to prison (because someone else on your
| contact list saw a classified screenshot from you and
| told the authorities), maybe that's better. The activists
| might choose not to protest, but if the alternative is
| being caught before they even start their protest
| (because your group was forwarding a little advertisement
| image or annotated map around among trusted people, and
| someone untrusted got it), maybe that's better.
|
| Take Reality Winner, for instance (the mechanics of that
| case were entirely unrelated to secure messengers, but it
| makes a relevant example overall). The effect on the
| world of her whistleblowing seems to have been minimal,
| and the cost to her was significant. Was it worthwhile?
| If she had been told the risks of the government
| identifying her were higher and decided not to leak
| anything, wouldn't that have been a better outcome?
|
| I'm not saying there's perfect security. Vulnerable users
| absolutely need to be making risk assessments and
| deciding what they're comfortable with, and we should be
| clear nothing is risk-free. I'm just saying my sense of
| Signal's risk, in absolute terms, is higher than it was
| before I learned about this, and that matters to
| vulnerable users, not just the fact that it probably
| remains the lowest-risk messenger of the various options.
|
| I agree with you overall, and the Pegasus exploit does
| reflect badly on Apple (and probably should reflect more
| badly on them than seems to be happening).
| godelski wrote:
| > I think what I'm trying to get at is that incorrectly
| believing you have access to a secure messenger can be
| worse than acting as if you don't, if those are your
| options.
|
| For the average person, I do not believe this is true.
| For the non-average person, I believe you are correct but
| most of these people are aware and should be constantly
| trained.
|
| I'm not saying you're wrong, I'm saying that there are
| two different conversations to be had and we need to know
| which one we're having. To me it looks like Signal is
| about as good as you get without loads of complication
| and for what it is meant to do.
|
| > he Pegasus exploit does reflect badly on Apple
|
| And same with this on Signal. I do believe we should hold
| these companies to high standards. But the point I'm
| trying to make is that these also aren't reasons to
| abandon the platforms completely (as many users are
| suggesting here). That's throwing the baby out with the
| bathwater.
| geofft wrote:
| Yeah, to be clear, I only mean this from the point of
| view of non-average Signal users.
|
| It's a little weird that Signal is both the "baseline
| security that everyone should have" product (a la HTTPS
| or WPA2) and the "you are literally hiding from the
| government" product. Of course, the target market for the
| latter, when you are not another government yourself, is
| by definition mostly illegal activity (whether or not the
| laws are _justifiable_ ), so it makes sense that there
| isn't a good product just for that.
|
| In this particular case, it also complicates things that
| people who are literally hiding from the government also
| have normal ordinary conversations with lots of people,
| and it helps things for those ordinary conversations to
| happen on Signal, but this bug is particularly bad if you
| do that.
|
| (I'm also not really sure where, say, people buying
| recreational drugs fit on the "average"/"non-average"
| axis. Is it a reasonable precaution to not text
| incriminating information to your drug dealer over
| Signal? It feels like it shouldn't be necessary, but I
| can see the argument for it.)
| osobo wrote:
| How much did you pay for it again?
| okdjnfweonfe wrote:
| Probably by installing some hardened memory on your phone to
| prevent cosmic bitflips or the such.
|
| Unless you are going to go to NASA lengths of hardware
| reliability, you can't really hope much for the software that
| has to deal with the issues of... how many different android
| phones are there?
| geofft wrote:
| The available evidence indicates that this was due to a
| logic error, not to cosmic rays and/or Android ecosystem
| diversity.
| eganist wrote:
| Question: do you guys have a software or product security team?
| I suggested the roles to workwithus @ Signal on 5/18/2018 and
| have never seen a public follow-up in the form of career
| postings.
|
| Asking because such a team may be best equipped to serve as
| both the support and internal accountability function for such
| while minimizing business conflicts when engineering is facing
| challenges integrating security into DevOps natively.
|
| At this point, it's probably warranted; the last time I asked
| was when Signal was seeing its spree of XSS defects in the
| desktop app. If Signal has one, a simple "yes" will suffice,
| but without a reply, I have to assume not.
| azornathogron wrote:
| Given Signal's raison d'etre, I would think nearly their
| entire team is the "security team".
|
| I'm not being entirely facetious either - security is _the_
| USP of the product, I really would expect security knowledge
| and a feeling of responsibility for the product 's security
| to be pervasive throughout the whole team.
| andrewguenther wrote:
| > This bug was extraordinarily rare, and because we have no
| metrics/remote log collection, there was an initial period
| where we had to spend time adding logging and collecting user-
| submitted logs to try to track it down.
|
| Without telemetry, can you actually back up the claim that this
| issue was extremely rare?
| hnarn wrote:
| Some details on how this assumption was made would be nice,
| but I think it's pretty obvious that any developer involved
| in a project can make a reasonable assumption of how rare a
| bug is depending on the technical details on what is required
| for the bug to happen. For example, if we say for the sake of
| argument that a hypothetical bug requires you to have more
| than ten contacts of the exact same name and these also need
| to share the same country _and_ area code, one can make the
| assumption this use case is very rare without knowing the
| exact number of users that this applies to, just based on
| common sense regarding how the application is normally used.
|
| edit: The linked github issue says:
|
| > The TL;DR is that if someone had conversation trimming on,
| it could create a rare situation where a database ID was re-
| used in a way that could result in this behavior. It was very
| difficult to track down, with earlier phases involving
| getting additional logging into builds. Once we had some more
| information, it did in fact become our top priority, a fix
| was made, and we got it out as quickly and as safely as
| possible. The fix itself should make it so that database
| issues like the one that caused this bug can't happen again.
| WesolyKubeczek wrote:
| > a hypothetical bug requires you to have more than ten
| contacts of the exact same name and these also need to
| share the same country and area code
|
| Sounds like the village a part of my family tree comes
| from.
| z3t4 wrote:
| > The fix itself should make it so that database issues
| like the one that caused this bug can't happen again.
|
| I've said that a few times, and been wrong about it. :D
|
| I don't know what they mean by "where a database ID was re-
| used", but I guess it had to do with caching, and cache
| invalidation is one of the hardest part in computer
| programming.
| NullPrefix wrote:
| >for the sake of argument that a hypothetical bug requires
| you to have more than ten contacts of the exact same name
| and these also need to share the same country and area code
|
| This is only rare if you have a small social circle. My
| circle has multiple first name-collisions of at least 5
| participants, but my circle is not very big and the area
| code is also quite small.
|
| Some countries do not use area codes for mobile phone
| numbers, which are used for Signal, meaning country code is
| the only area limiting factor.
| desine wrote:
| >for the sake of argument
| NullPrefix wrote:
| Yes.
|
| And for the sake of the same argument I made a counter
| argument, stating that some initially believed to be rare
| circumstances are actually not that rare.
| johnisgood wrote:
| There is no argument, and it did not require a counter-
| argument, because that is not the point. He could have
| used literally anything else, it just has to be rare.
| hnarn wrote:
| "For the sake of argument" does not mean "I invite you to
| debate this", it means the exact opposite: "let's assume
| this is correct/we agree/etc. for a while and debate what
| comes after". So in this case you are doing the exact
| opposite of what the phrase "for the sake of argument" is
| requesting.
|
| https://idioms.thefreedictionary.com/for+the+sake+of+argu
| men...
|
| > I know you want to go to Stanford, but just for the
| sake of argument, let's talk about what some of the other
| schools you got into have to offer.
|
| This does not mean "I invite you to make a counter-
| argument as to why no other schools than Stanford are
| worth going to".
| NullPrefix wrote:
| OKay, M[rs] English-as-a-first-language.
| hnarn wrote:
| English is my second language.
| qu4z-2 wrote:
| It sounds to me like NullPrefix accepted the hypothetical
| bug, for the sake of the argument, and then addressed the
| rarity assumptions made about that bug. "For the sake of
| argument" doesn't mean "No debating" it means "Let's
| assume some thing x is taken as a given and go from
| there."
| hnarn wrote:
| The whole point was that "given this assumed rare bug,
| one can know it's pretty rare". Whether the example is
| actually rare enough is completely beside the point. If
| it's not rare enough for you, replace it. The argument
| comes next: given a rare bug, a developer can make an
| assumption of _how_ rare it is. Debating the example of
| rareness is splitting hairs.
| hutrdvnj wrote:
| Well he just wanted to make an example. One could also
| construct an example, where the bug only occurs for
| people with a rare sequence of unicode symbols (e.g.
| U+2600 U+2601 U+2602) in their username and have a
| specific date (e.g. 05.04.1920) as their birthday.
| NullPrefix wrote:
| Your argument depends on Signal implementing username
| support, because we do not support unicode in phone
| numbers.
| hutrdvnj wrote:
| My argument depends on an alternate universe in which
| signal supports it, everything else being equal, because
| _why_ not.
| NullPrefix wrote:
| Does that alternate universe support phone numbers with
| unicode characters too?
| ChrisKnott wrote:
| You are arguing against a hypothetical situation of your
| opponent's creation. This is like when Ross tried to beat
| Chandler at Cups
| NullPrefix wrote:
| I am curious how different that alternative universe
| needs to be for my argument to be invalid.
| hutrdvnj wrote:
| I go to bed now and dream of a universe in which
| NullPrefix is Ross and continues to argue endlessly.
| [deleted]
| NullPrefix wrote:
| I'll argue with anyone about anything. For free.
| johnisgood wrote:
| It is a hypothetical scenario for the purpose of an
| example. It could have been literally anything, the point
| is for it to be rare.
| NullPrefix wrote:
| Yes, but the fact that scenario is hypothetical doesn't
| counter my argument that whatever the developer thinks is
| rare is actually rare.
| Griffinsauce wrote:
| > just based on common sense regarding how the application
| is normally used
|
| Just based on assumptions of how the application is used.
|
| "falsehoods programmers believe" comes to mind. The
| uniqueness of names in your example could be false in some
| (or many? No idea) cultures.
| varispeed wrote:
| Why would anyone think that re-use of ID was a good idea?
| hnarn wrote:
| I'm not defending the practice of re-using a database ID,
| but it's absolutely something that can happen (or change)
| as an oversight rather than an active choice from the
| developer.
| doctor_eval wrote:
| Perhaps that's why it was a bug?
| CoryAlexMartin wrote:
| If you know the reproduction steps and you can look at the
| code, you should be able to make an estimate of rarity.
| saagarjha wrote:
| Even with telemetry, would you be able to back up the claim
| that that the issue was rare? All too often, people add
| telemetry to something in an attempt to try to find things
| like this, but they end up leaking things elsewhere and not
| accounting for them. Bad statistics are more dangerous than
| no statistics, and all that.
| gsich wrote:
| If this is the first instance of this bug being reported,
| then yes it's rare.
| johnisgood wrote:
| The rarity of a bug is independent from reports of it.
| barsonme wrote:
| That also depends on the severity of the bug. :)
| gsich wrote:
| No, those are directly correlated.
| gsich wrote:
| Even with, what telemetry would allow you to determine how
| many pictures (and presumably content) you sent to whom?
| tylermenezes wrote:
| > we were able to get a fix out very quickly.
|
| Is 6 months really what Signal considers quick for a bug that
| leaks private data?
| hutzlibu wrote:
| Selective quoting?
|
| "As soon as we were able to pick up a scent, it was all we
| worked on, and we were able to get a fix out very quickly."
| nathan_phoenix wrote:
| Does it change anything tho? They prolonged investigating
| this issue for months and only put mayor work behind it
| when they "pick[ed] up a scent on it". Although they knew
| about it from day one (one Signal staff replied on the same
| day the issue was posted).
| tylermenezes wrote:
| It's not at all selective. This should have been "all they
| worked on" from the moment they got several confirmations,
| not from the moment people beat them over the head with
| data. If they couldn't fix it they should have pulled the
| app.
|
| This is a company that aggressively markets itself to
| people needing privacy, and mistakes can ruin lives. And
| before you say it, they have tens of millions of dollars in
| funding.
| hutzlibu wrote:
| Well yes, maybe they should have put more people on it,
| from day one. But even though they have solid funding,
| doesn't mean they can throw it out the window.
|
| And non reproducible bugs can be hard, even when you
| throw money at them.
|
| But your quote was almost a textbook example of selective
| quoting, because you said, that they said they did a
| quick fix, when it really took over 6 months. But they
| did not say this - they said "once they pick up the
| scent" they delivered a quick fix. This is something very
| different.
| tylermenezes wrote:
| "But even though they have solid funding, doesn't mean
| they can throw it out the window."
|
| This is a product which is advertised as private,
| marketed extensively toward people requiring privacy.
| Knowing they're accidentally sending images to the wrong
| people is a HUGE, priority 1 problem.
| spicybright wrote:
| Just wanted to say, thank you so much for your contributions.
| Signal is an amazing product, and things like these happen to
| the best of projects.
| nathan_phoenix wrote:
| > we were able to get a fix out very quickly.
|
| I'm not sure if 8 months can be categorized as fast... The
| issue was posted on Dec 4, 2020, and the fix (5.17) was
| released on July 21.
|
| Also, sounds like quite a big issue considering that Signal is
| all about privacy...
| hutzlibu wrote:
| Selective quoting?
|
| "As soon as we were able to pick up a scent, it was all we
| worked on, and we were able to get a fix out very quickly."
| nathan_phoenix wrote:
| Oh sorry, I interpreted it differently. Tho it still
| doesn't change anything, they prolonged investigating this
| issue for months and only put mayor work behind it when
| they "pick[ed] up a scent on it". Although they knew about
| it from day one (one Signal staff replied on the same day
| the issue was posted).
| hutzlibu wrote:
| Yeah but he explained, that they could not track down the
| bug, without having the luxory of default user tracking
| and metrics. So what can you do, when you have a non
| reproducible bug, but limited ressources(and other
| problems around)? You wait for the bug to show up again
| and then have more data to work with.
| [deleted]
| alerighi wrote:
| And they say that I don't value privacy since I use Telegram and
| not Signal... in reality Telegram may not be end to end encrypted
| like Signal, but I never recall doing a think like that. It means
| poor attention to the security of the application, and poor
| testing.
| maqp wrote:
| So let me see if I got this straight...
|
| You will never use an app that HAD 0.000000001% chance of
| outputting a file on your phone to wrong peer over 100% end-to-
| end encrypted channel...
|
| but...
|
| You knowingly use an app that leaks 100% of your group chats,
| including attachments, 100% of your 1:1 desktop messages to the
| service provider, who can be bought, or hacked at any time
| without you (or them) knowing, and that doesn't provide any
| kind of active protection mechanism against similar bugs than
| this one...
|
| ...on the grounds...
|
| ...that such bug hasn't happened, yet?
|
| Is that what I'm reading?
| MacD83 wrote:
| I'm rooting for Delta Chat [1] which puts a nice chat UI on top
| of email. It is such a brilliant and simple solution. It is
| decentralized unlike Signal which recently had big reliability
| problems when new users flooded in.
|
| [1] https://delta.chat
| sschueller wrote:
| Isn't this going to pollute my mail server with thousands of
| individual chat "emails" instead of a few large emails?
| detaro wrote:
| Dealing with thousands of messages in a folder somewhere is
| not really problem for mail servers.
| [deleted]
| spinax wrote:
| I had to dig a little bit to get a better view of "will this
| make a mess of my email if I try/test it without commitment?";
| the tl;dr is basically:
|
| (a) there is a DeltaChat subfolder in your IMAP storing the
| messages;
|
| (b) the app looks for a "Chat-Version" header on emails to know
| to move it to (a) folder (and you can set a server side rule to
| also do that);
|
| (c) a number of popular email providers (IMAP is used) are
| listed with some notes to help you get started:
| https://providers.delta.chat/; and
|
| (d) it's using the Autocrypt/PGP standards and you can
| apparently import your existing PGP key if you want
|
| It's all in the FAQ or other docs, just highlighting the things
| which I wanted to know straightaway before making a mess by
| accident just to give it a try.
| Forbo wrote:
| Which unfortunately suffers from the same metadata leaks as
| email.
| Sytten wrote:
| I like signal but having to explain to my parents why they cant
| use it on their android tablet or that they cant register without
| a phone number makes me reconsider if I should just use another
| software.
| 63 wrote:
| Several years ago I had this same issue occur in Facebook
| Messenger. I was using a pretty slow outdated device even for the
| time. I went to take a picture to send with the in-app camera. I
| actually pressed send before the picture rendered on my screen
| and somehow what was sent was not the picture I took, but a
| picture of some man's forehead who neither of us had ever seen
| before. It seemed like a pretty huge bug that could be a serious
| problem if anyone could reliably recreate it, which I could not.
| I went about trying to report it but ran into so many problems
| and broken links searching for Facebook's bug reporting that I
| gave up. Here's hoping it's been fixed, though I haven't used
| Messenger for at least a few years now anyway.
| proactivesvcs wrote:
| It also happened to Skype around 2011ish. IIRC it was so
| frequent that I simply stopped using the software until a fix
| was released.
| wizzwizz4 wrote:
| https://news.ycombinator.com/item?id=27951529 appears to be the
| same bug.
| cube00 wrote:
| That's a lot of faith that you'll never log anything sensitive by
| making the user's debug logs public if they want to report an
| issue.
| MrAwesome wrote:
| Several years ago, when I worked at FB, I ran into a similar bug
| on an early internal version of a Messenger rewrite. Sent
| pictures to one chat, showed up in another.
|
| My bug report on it kicked off an absolute maelstrom of dev
| activity and investigation. High level engineers showed up in the
| comments. Lots of immediate followup. The severity was clearly
| understood and resolving it was clearly prioritized.
|
| I exclusively use Signal now, but the discrepancy between what I
| see here and what I saw there is pretty disheartening. This kind
| of bug is not only a massive privacy risk, but it also massively
| erodes user confidence and trust.
| swiley wrote:
| The older software probably spoke xmpp which meant people could
| just leave when it misbehaved. Signal has been against this
| from the beginning, it's against the ToS and the owner has
| asked devs of alternative clients to stop developing them.
|
| No "apps" are ever good.
| godelski wrote:
| I don't think Signal has many devs[0] and if you look at the
| contributors[1] you can see that Grayson is pretty much the
| only dev for the Android app. So seeing a second dev get
| involved is probably them freaking out.
|
| [0] Personally I believe this is a big bump in the road for
| Signal and is why a lot of people are frustrated. About
| promises about things like usernames (it is no longer early
| 2021), channels, and everything else. A few devs can only do so
| much. A dozen (maybe 2 dozen?) devs can still only do so much.
| How do you compete with other platforms like Telegram that has
| hundreds of employees or WhatsApp with far more than that?
|
| [1] https://github.com/signalapp/Signal-
| Android/graphs/contribut...
| dunefox wrote:
| I mean, they invested a year into covert development of a
| crypto wallet inside Signal. Maybe that time could have been
| spent better.
| godelski wrote:
| From the commits I only really saw Moxie adding this and he
| hasn't been doing as much dev work in the last few years.
| So I don't feel that this took much away. It's hard to tell
| if it is a good move or not since Telegram and WA are both
| adding payments to their platforms and there is a need for
| feature parity. But regardless, MOB probably wasn't a good
| fit and we've seen no update since.
|
| My complaint is more than Signal moves far too slow. I'm
| not saying to move fast and break things, that's far from
| what I want. But I am saying maybe add a few more devs.
| dunefox wrote:
| > But I am saying maybe add a few more devs.
|
| Absolutely, then such an important issue probably
| wouldn't stay open for this long.
| woxko wrote:
| Bug report is eight months old now. I don't think they're
| freaking out much.
| godelski wrote:
| But the issue is fixed. Forgetting to close a bug report is
| different than not fixing the bug
| jeroenhd wrote:
| True, but the issue was fixed in 5.17, which was released
| only 10 days ago [1]. For an issue opened December last
| year, that's still quite a lot of time before a fix could
| be found.
|
| [1] https://github.com/signalapp/Signal-
| Android/commit/a47448b6c...
| croes wrote:
| Try fixing a rare bug quicker without constant user
| metrics.
| Arnt wrote:
| Yes, indeed.
|
| This kind of bug is an argument for having metrics.
| godelski wrote:
| I'm not convinced. The bug is rare and requires a
| specific set of circumstances that not many people are
| going to perform. That is not an argument to collect
| metrics, or in other words, change the entire paradigm of
| Signal (no collection of Metadata). It does propose an
| argument for more audits, more eyes, and more care. But
| we do not expect Signal to be perfect, as no software is.
| Systematic failure, on the other hand, creates worry
| about Signal. But not individual.
| aadjklskljads wrote:
| No, Signal does _not_ get to play the limited resources card
| when they so firmly discourage 3rd parties from working on
| their project.
| LurkersWillLurk wrote:
| Could you explain what Signal is doing to discourage
| contributions?
| afroboy wrote:
| By not allowing 3rd parties apps to coexist with official
| signal app. (Using same servers)
| maqp wrote:
| No, contrary to common belief, coordinating with multiple
| client projects to release features simultaneously etc, is
| not easier. The number of meetings does not drop, the
| quality will not improve if you now have to check that
| multiple clients are safe. You won't magically get more
| eyes on your code, when people are working on their code,
| not yours. And at that point you now have to deal with
| people who think they have as much say as you have because
| their fork is "equally important". And trying to explain to
| a non-cryptographer hobbyist why some change needs to be
| done, or why some feature can/should not be implemented, is
| not speeding things up.
| rococode wrote:
| They've just posted an update saying that the issue was fixed
| on July 21. It's certainly good that it's fixed...
|
| But that's still over _7 months_ before it was fixed, including
| a 2 month period where people were still bumping the issue
| asking for help with no response from maintainers (afterwards,
| the issue went quiet until ~2 weeks ago). And there was at
| least one other issue on the same problem a few months later
| that received no response [1].
|
| I understand the team is probably understaffed given the vast
| number of open issues (1300+) they have, many with no response,
| and I can sympathize with the challenges of being a small team
| developing an app used by millions, but they probably need to
| figure out a better way to triage...
|
| [1] https://github.com/signalapp/Signal-Android/issues/11137
| spullara wrote:
| It was fixed a long time and only closed recently, see the
| message from the dev.
| rococode wrote:
| No, the dev writes on GitHub that "this issue was fixed in
| 5.17 (which hit 100% production on 7/21)". Releases show
| 5.17.0 was released on July 15. They've also linked the
| commits that fix the bug - the fixes were committed 10 days
| ago.
| rplnt wrote:
| This happens to me all the time in Messenger. Just locally
| though. Like if I sent an image and delete it from the phone,
| the app shows some other random image instead.
| colesantiago wrote:
| Signal is becoming a joke that we should reconsider using, and
| now has dangerous bugs that is at the edge of compromising
| people's privacy.
|
| Has this app/service really been audited properly?
|
| We now need to consider serious alternatives that we should get
| behind like Element [0] or Session [1] but I am open to user
| friendly alternatives other than Signal (at worst even Quill [2]
| or Delta Chat [3]).
|
| [0] https://element.io
|
| [1] https://getsession.org
|
| [2] https://quill.chat
|
| [3] https://delta.chat
| egberts1 wrote:
| Quill? Why would we want to use Quill that needs all of our
| private data?
|
| Have you not seen over at Apple App Store what they're sucking
| off of your phone from your Quill app?
| colesantiago wrote:
| Which is why I said _at worst_. Please read.
|
| Could you recommend a better chat app that is user friendly
| enough for regular people to use that is not Signal or
| WhatsApp and is cross platform?
|
| Quill are at least working on E2E, not introducing a
| cryptocurrency like Signal and don't require your phone
| number.
| dunefox wrote:
| That is idiotic. It's strictly, objectively worse than
| Signal and not even acceptable in the _worst case_.
| colesantiago wrote:
| How can you be so sure if you haven't tried it?
|
| I'd rather use a chat app that takes security matters
| seriously and urgently and will eventually have E2E.
|
| What's more 'idiotic' is prioritising and bolting on
| cryptocurrencies [0] than fixing urgent security issues,
| leaving it for months unfixed, while also claiming to be
| private and secure, and also requiring your phone number.
|
| [0] https://www.wired.com/story/signal-mobilecoin-
| payments-messa...
| dunefox wrote:
| I agree that adding a crypto coin the way they did it is
| idiotic as well. But I wouldn't ditch an encrypted app
| for one that will 'eventually' be E2E encrypted.
| matrix.org is E2E encrypted and secure _now_ and it 's
| being used by France and Germany.
| colesantiago wrote:
| Matrix / Element is unfortunately just far too technical
| for end users and the general population, but it is
| better than IRC.
|
| A mistake was the naming, for example you refer to the
| name of the protocol 'Matrix' instead of the name of the
| client 'Element'. Having a naming issue risks confusing
| lots of people, other than that I have already mentioned
| it as an alternative.
| maqp wrote:
| >I'd rather use a chat app that takes security matters
| seriously and urgently and will eventually have E2E.
|
| Deploying messaging app without E2EE being the first four
| chars on the security design paper -- even before the
| product name -- is the opposite of taking security
| matters seriously.
| maqp wrote:
| >are at least working on E2E
|
| So they're in the process of moving it from 1995 to 2004.
| That's great!
|
| If all you have on Signal is opt-in feature for payment,
| and an issue of usernames that's being worked on -- but you
| want to offer as a solution a product that's for now,
| completely insecure by design (but it's being worked on),
| you're in dangerous waters. This is especially condemnable
| because the issue with Signal here is confidentiality of
| sensitive data.
|
| You'd replace a one-in-a-billion database key collision
| problem with 100% of content leaking to service provider
| that literally offered the Telegram defense "The AES256 key
| is on a DIFFERENT computer". It's not. It by definition of
| how computers work, can not be. The database key sits in
| the RAM of the database server doing the database commits.
| The CPU can't perform AES operations without the key, and
| the key isn't being quantum teleported from another
| machine's RAM to the registers of the computer doing the
| encryption. These guys have no idea how computer security
| works, yet you deem them worthy of your attention. This
| makes me question your expertise on the subject matter too.
| soziawa wrote:
| I've been on Threema ever since I learned that WhatsApp did not
| even use TLS. It's a great chat app and nothing else (which is
| a feature in my book).
| maqp wrote:
| >serious alternatives
|
| How is Quill Chat that's proprietary and not E2EE a serious
| alternative?
|
| Element's UX is behind Signal but at least the encryption is
| E2EE by default.
|
| Session is a Signal fork with bad metadata protection: There's
| 60 entities owning Loki nodes, and top three players own 80% of
| nodes.
|
| Delta chat leaks metadata to email providers, and PGP has no
| forward secrecy or deniability.
|
| Element is the only one that's even remotely fixing the issue.
|
| The issue here was client side, and no architectural design,
| not even hardware system can prevent the "wrong contact
| receives plaintext message" vulnerability categorically.
|
| The fix is now in place, and I'll eat my shorts if they don't
| have a unit test in place to detect reintroduction of this
| issue.
| h_anna_h wrote:
| > Delta chat leaks metadata to email providers, and PGP has
| no forward secrecy or deniability.
|
| Signal leaks metadata to the signal server. Deniability is
| useless. Forward secrecy is cool as long as you are not using
| more than one device.
| [deleted]
| eganist wrote:
| > Has this app/service really been audited properly?
|
| Yes, _repeatedly:_ https://community.signalusers.org/t/wiki-
| overview-of-third-p...
|
| Edit: that said, this did make me revisit a question I asked
| signal via their Careers portal a long while back. Reposted
| here: https://news.ycombinator.com/item?id=27952315
| soziawa wrote:
| The protocol has been reviewed plenty of times. The rest of
| the app has not. At least according to your list.
| colesantiago wrote:
| And yet there are serious bugs like this that slip through
| the net, a simple benchmark of any chat app should not be
| showing other people's messages like what Signal is doing.
|
| I would expect that an app that has repetitive audits would
| have resulted in this bug being fixed already.
| detaro wrote:
| At least the main audits are clearly described as auditing
| internal components, so it's not surprising app-level
| errors aren't covered by them.
| colesantiago wrote:
| Which this bug was left open for months while users were
| experiencing this privacy issue.
|
| How can I recommend a chat app that does this and claim
| they are a privacy based app? and also does not respond
| to urgent bugs in this manner?
| godelski wrote:
| The bug wasn't open for months, the dev just forgot to
| close it and he's in the thread.
| detaro wrote:
| He forgot to close it _10 days ago_.
| colesantiago wrote:
| Where is the original issue for this, if that is the
| case?
|
| Otherwise I see signal developers closing duplicates [0],
| towards the main issue [1] which leads me to believe it
| was open for months.
|
| Even if the bug was fixed at 7/21 on the original thread
| and this main one, this issue was still open for months.
|
| [0] https://github.com/signalapp/Signal-
| Android/issues/11137
|
| [1] https://github.com/signalapp/Signal-
| Android/issues/10247
| detaro wrote:
| I'm not saying you should recommend Signal, just pointing
| out that "there are audits, why does it have such bugs"
| doesn't tell the entire story.
| colesantiago wrote:
| > just pointing out that "there are audits, why does it
| have such bugs" doesn't tell the entire story.
|
| So? Isn't that the point though? Having _regular audits_
| should have caught this issue? I thought this being
| 'open source' this would made this even easier.
|
| Which leads me to believe a team that has $60M~ in
| funding is unable to fix this issue in a matter of
| urgency.
|
| Remember this issue was open for _half a year_ with users
| noticing this, no matter how you slice this, this issue
| does not give me any more confidence in Signal being
| secure.
| maqp wrote:
| >So? Isn't that the point though? Having regular audits
| should have caught this issue? I thought this being 'open
| source' this would made this even easier.
|
| You have it the wrong way. Testing, audits, and open
| source are all best practices. They should be done. None
| of them are guarantees of security.
|
| Open source is not guarantee of finding all bugs, it's a
| necessity to allow anyone to look for bugs (and
| backdoors).
|
| Audits can not be passed. They can only be failed. Kind
| of like how RNG tests can not be passed, they can only be
| failed. Example: Use SHAKE256 to extrude any keystream on
| initial value 0x00. It will not be secure, but it will
| pass any statistical test.
|
| >this issue does not give me any more confidence in
| Signal being secure.
|
| No application can actively prevent a bug like this. As
| an author of high assurance comms system, see what I
| wrote under threat model:
|
| "If hardware such as computers/optocouplers user has
| bought is pre-compromised to the point it actively
| undermines the security of the user, TFC (or any other
| piece of software for that matter) is unable to provide
| security on that hardware."
|
| This also applies to software issues that actively
| undermine the security of the user. So the thing is, a
| software bug that outputs sensitive data to wrong
| contact, can not be absolutely prevented. You would need
| a friendly MITM-guard node that runs a Google-grade image
| recognition algorithm that detects you're trying to
| output a legal document to the wrong client, or a nude to
| not-your-SO.
|
| Again, bugs are unavoidable, what matters is the incident
| response, and is Signal actively trying to protect you
| from everyone, including themselves.
|
| Another PoV: If you punitively fire people that get
| caught in social engineering pentests, you're replacing a
| person who now has real-life experience with social
| engineers, with someone who may or may not have such
| experience.
|
| Sure, if the person fails multiple times, it's time to
| let them go, but Signal's reaction is indication of a
| good employee who takes personal responsibility in making
| sure it won't happen again.
|
| I'm extremely careful about what I recommend, and I have
| serious trouble finding a way to agree with your
| assessment that just because a rare bug is open 6 months
| is of serious concern. It wasn't being sat on for six
| months. But you're very keen on giving that idea. Would
| you care to elaborate?
| maqp wrote:
| So what ingenious method should they have deployed to
| prevent all programming errors beforehand, and how should
| they have handled it? Advice users to fall-back to non
| E2EE SMS?
|
| The team deployed logging as fast as they could,
| successfully detected the issue as soon as it happened
| again, and deployed fix as fast as possible. What should
| they have done?
|
| If you only recommend chat apps with perfect track
| record, you're basically recommending chat apps with
| internal policy of not disclosing vulnerabilities, and
| ones that downplay any revealed vulnerabilities.
| hellcow wrote:
| I don't think anyone takes issue with the fact that the
| mistake was made or that it was really hard to track
| down. Shit happens.
|
| How you handle it is everything. No communication on it
| and issuing no warning to their users for a critical bug
| that risked user privacy in a substantial way for 7
| months is unacceptable for an app that calls itself
| secure, full stop.
| hrjfjjfjfjd wrote:
| How can an unencrypted copy of some media end up at the wrong
| user? Isn't that supposed to be end-to-end encrypted, especially
| when stored on the signal servers?
| drexlspivey wrote:
| It was a bug on the client that encrypted and sent the message
| to the wrong user. If it was a bug in the server that messed up
| the routing it would be impossible for the wrong recipient to
| see the message.
| jeroenhd wrote:
| The chat client misinterprets _something_ and attaches a file
| to the message. The encryption works fine, the business logic
| of the app failed.
|
| E2EE won't protect you from a client accidentally encrypting
| and submitting files in the wrong chats.
| hrjfjjfjfjd wrote:
| But what exactly went wrong with signal here?
|
| Could someone remotely instruct my signal client to share
| media? Previously sent or arbitrary files?
| jeroenhd wrote:
| The app accidentally attached seemingly random media to
| messages. The other end has no control over what images
| they receive when. There was no hack or remote control at
| play, just a bug.
| maqp wrote:
| They would have to compromise your client which is in no
| way different from compromising your device. The NSO /
| Pegasus systems do just that. They allow arbitrary command
| execution, which includes sending any file on your phone to
| any contact over Signal. Nothing software can do to protect
| from that. If you need 100% guarantee something doesn't
| leak over electronics, don't store it electronically. Ask
| them Slavs
| https://www.theguardian.com/world/2013/jul/11/russia-
| reverts...
| maltalex wrote:
| I love Signal and have advocated for its use. But I have to say
| that this issue is trust-breaking.
|
| I lovingly forgive the occasional bug or unpolished feature and I
| understand that the team behind Signal are human and that
| programming is hard. But sending messages to the wrong people is
| very high on the list of things a messenger should never ever
| ever do!
|
| Having an issue like this remain open for 7.5 months hints at a
| systemic issue, which is probably be related to Signal being
| underfunded/understaffed. But regardless of the reason and of
| everyone's good intentions, the fact remains that similar issues
| can and probably will happen again, and may again take months to
| fix.
| godelski wrote:
| FWIW the problem did not remain open for 7.5 months (GitHub
| issue did, but not the problem). The dev is in the thread and
| explains.
| detaro wrote:
| Bug reported 2020-12-04, fixed release tagged 2021-07-15 (if
| I'm identifying the commit correctly, same day the fix is
| merged, which one would hope for a high-priority bug like
| that). That's _technically_ 7. _3_ months, not 7. _5_ , true,
| but ...
| johnchristopher wrote:
| > [..] his Signal randomly sending images to me that he didn't
| intend to, even without initiating the addition of any
| attachments on the GUI... he even sees one of my messages
| displayed on his side with a random image attached to it, as if i
| have sent that image to him, even though that image is not even
| present on my phone.
|
| https://github.com/signalapp/Signal-Android/issues/10247#iss...
|
| Yikes.
|
| > [..] I've also recently had a probably unrelated issue where my
| mic was still audible to the other party after I hung up the
| call.
|
| https://github.com/signalapp/Signal-Android/issues/10247#iss...
|
| Double yikes.
| rvz wrote:
| > I've also recently had a probably unrelated issue where my
| mic was still audible to the other party after I hung up the
| call.
|
| That one there is a cataclysmic security land mine. Absolutely
| unacceptable.
|
| That was the last straw after [0]. I don't think I can
| recommend Signal at this time.
|
| To Downvoters: So these bugs are all fine then? They are not
| security issues then? Not only having images being sent to the
| wrong contacts but also having the microphone still on after
| ending the call and being audible to the other party? That's
| fine right?
|
| If this happened on any other messaging app, I would expect a
| massive outcry and urgency to fix these critical issues.
|
| [0] https://news.ycombinator.com/item?id=27951076
| ubercow13 wrote:
| Yes. Signal's only selling point is privacy. Both of these
| bugs are huge privacy breaches that kill its value
| proposition.
|
| Which type of privacy breach is more likely to have tangible
| and direct negative effects on an average user's life - a
| nation state storing their communications in a database,
| Facebook graphing their contacts and using them for friend
| recommendations, or their friends/family/boss/acquaintances
| being sent random private photos from their phone and audio
| of private conversations they have in their home, without
| them knowing?
|
| One of the main worries with companies having access to your
| unencrypted private data is that no matter how careful they
| are with it, it can still end up in the wrong hands. Signal
| is directly sending your data into the wrong hands.
| maqp wrote:
| >Yes. Signal's only selling point is privacy. Both of these
| bugs are huge privacy breaches that kill its value
| proposition.
|
| Absolutely agree. However, you should always look at the
| bigger picture
|
| a) How was the issue handled? What was the priority? Did
| they try to downplay it? Was the type of vulnerability
| patched altogether?
|
| b) If a) merits for change, what's the alternative that has
| better overall security, UX, existing userbase, and track
| record.
|
| Personally, I'd rather take a product with good public
| incident handling track record, than one without anything
| on public record.
|
| >One of the main worries with companies having access to
| your unencrypted private data is that no matter how careful
| they are with it, it can still end up in the wrong hands.
| Signal is directly sending your data into the wrong hands.
|
| Categorical label of "wrong hands" is unnecessarily
| ominous. Company with access to your private data can lead
| to that data being sold, or stolen by nation states /
| organized crime. You sending nudes / sensitive documents to
| your friend on Signal is less dangerous, although it can be
| much more embarrassing. Your peer probably isn't going to
| sell it to the highest bidder (or was it the case the
| recipient could be any Signal user? IIUC that was not the
| case)
| dmosley wrote:
| I agree these bugs that Signal has are serious. With hat
| said, your examples aren't that great for counters.
|
| "a nation state storing their communications in a database"
| - The power differential and historic missteps of
| governments makes this ludicrous to think of as "OK" in
| comparison.
|
| "Facebook graphing their contacts and using them for friend
| recommendations" - but, it's not just for friend
| recommendations and possibly more importantly, it's not
| just their users, is it? Not to mention it's ignoring the
| purposeful opinion-biasing they have openly taken part in
| to manufacture consent for any number of issues.
|
| While these bugs are bad and should be prioritized for fix,
| they are seemingly random. Sure they can possibly be
| exploited (possible, haven't seen proof of concept for
| purposeful exploitation), but random bugging vs clear and
| present danger on current and historical precedents of
| governments and technocratic oligarchs? Me thinks your
| trust may be a bit misplaced or you're just being obtuse
| for sake of obtuseness.
| [deleted]
| markovbot wrote:
| >The power differential and historic missteps of
| governments makes this ludicrous to think of as "OK" in
| comparison.
|
| wasn't that kind of the point?
| qwertox wrote:
| Laurens Cerulus @laurenscerulus Feb 20, 2020
|
| News: The EU Commission told its staff to start using
| @signalapp to chat to friends and contacts. The move is part
| of an effort to fix the holes in EU cybersecurity. Story (for
| Pros for now)
| https://twitter.com/bendrath/status/1230455295018766337
| mdoms wrote:
| Why on Earth are people downvoting you? This is an absolute
| dealbreaker for any messaging app, much less one whose raison
| d'etre is privacy and secure messaging.
| hypertele-Xii wrote:
| So which app _would_ you recommend?
| fsflover wrote:
| Matrix.
| qwertox wrote:
| This isn't a valid argument.
| hn8788 wrote:
| Probably because the common mindset here is that anyone can
| make a mistake, and that the person who did it learned
| their lesson and will never do it again.
| saurik wrote:
| And to verify, the "mistake" is seeming to not actually
| care that this was a serious bug for 7 months ( _cough_
| while they launched MobileCoin)? That is an attitude
| issue--and one endemic to Signal (which, most charitably,
| simply doesn 't have the resources to sufficiently care
| sometimes)--not a "mistake" I expect to be easily
| rectified.
|
| (And as I mention on a nearby post: you don't have to fix
| it to widely disclose it; like, you don't work in the
| dark to fix an issue like this for seven months as, even
| if it were your "top priority": you quickly time box it
| and then disclose the issue so people can mitigate their
| exposure or help better crowdsource finding the
| information you need to fix the issue.)
| dmix wrote:
| It also sounded like a very difficult bug to track down,
| even as a top priority. Requiring a combination of
| certain settings plus a rare database ID intersection.
|
| Combine that with not logging user behaviour heavily for
| privacies sake makes this a very tough one to replicate.
|
| All of which was addressed in the bug report.
|
| The realities of software development on a large scale
| with a privacy focus are sometimes hard to grasp.
| Although I do admit 7 months for a production release is
| quite a long time, even factoring in the pandemic and
| mobile app Play Store release cycles.
| saurik wrote:
| So, did they disclose the issue? Were people using Signal
| warned somewhere that this was a known issue that they
| were hunting down? (I am guessing not as no one here has
| been like "oh yeah: everyone using Signal knew to be
| careful with this feature".) It being a difficult bug to
| _fix_ doesn 't mean that's your only recourse for
| something this serious.
| dmix wrote:
| Does any app push bug report notifications to users?
| Should Microsoft Windows or Google Chrome warn users
| every time there's a bug that can compromise their whole
| system just by visiting a certain website or downloading
| random pieces of software only a tiny subset of users
| will ever be exposed to?
|
| I get the motivation with a security/privacy critical app
| like Signal but this would also be a UX and customer
| support nightmare that IRL could grind a project to a
| halt.
|
| Not to mention expecting users to know how to balance the
| risks of said bugs vs not using the app at all because
| they were scared off it. Back to using far less secure
| options.
|
| I think having public forums to report and track the bugs
| for more advanced users is probably the right balance.
|
| The better solution is internal fixes and triaging the
| serious bugs appropriately so they get the attention they
| need. Instead of just offloading highly technical
| information barrages to average users.
|
| Temporarily blocking features until a patch is released
| is something that could make sense. But again only in
| certain circumstances. You can turn off photo sharing
| here but other cases it's not so straight forward without
| crippling the entire app for a rare bug. It's a difficult
| balancing act without a uniform solution.
| qwertox wrote:
| Usually when there are serious bugs in Windows, these get
| notified.
|
| Latest example: https://msrc.microsoft.com/update-
| guide/vulnerability/CVE-20...
|
| Released Jul 1, 2021
|
| Workarounds:
|
| Option 1 - Disable the Print Spooler service
|
| Option 2 - Disable inbound remote printing through Group
| Policy
| bakoo wrote:
| The first issue was fixed and just closed, and seems like it
| was very difficult to track down.
| FabHK wrote:
| It was closed 4 minutes ago; when was it fixed? ETA: Ah, 4
| days ago (more than half a year after it was opened).
| johnchristopher wrote:
| It's fixed in 5.17 and this is the release number I see on
| the Google playstore.
|
| Unfortunately for my ubuntu 18.04 LTS and this is in no way
| Signal's fault (but maybe the desktop version doesn't have
| that bug ?): $ apt-cache policy signal-
| desktop signal-desktop: Installe : 5.10.0
| Candidat : 5.10.0 Table de version : ***
| 5.10.0 500 500
| https://updates.signal.org/desktop/apt xenial/main amd64
| Packages 100 /var/lib/dpkg/status
| 5.9.0 500 500
| https://updates.signal.org/desktop/apt xenial/main amd64
| Packages 5.8.0 500 500
| https://updates.signal.org/desktop/apt xenial/main amd64
| Packages
| maqp wrote:
| Would rolling into the beta help here?
| https://support.signal.org/hc/en-
| us/articles/360007318471-Si...
| johnchristopher wrote:
| I don't think so: $ apt-cache policy
| signal-desktop-beta signal-desktop-beta:
| Installe : (aucun) Candidat : 5.11.0-beta.1
| Table de version : 5.11.0-beta.1 500
| 500 https://updates.signal.org/desktop/apt xenial/main
| amd64 Packages
| maltalex wrote:
| > webworxshop opened this issue on 4 Dec 2020
|
| Triple yikes.
|
| Though it looks like the issue was finally closed minutes ago:
|
| > Hi there, sorry, this issue was fixed in 5.17 (which hit 100%
| production on 7/21). There was another issue tracking this and
| it looks like I forgot to close this one.
|
| Still, that's a lot of time for such a bug to exist!
| Multicomp wrote:
| I've not experienced reports of this for myself. I'll ask my
| driend group to do a comparison between our shared room and see
| if there are any problems. to be fair i mostly use groups so
| maybe the behavior is limited to 1x1 messaging?
| piaste wrote:
| The bugfix comments says:
|
| > The TL;DR is that if someone had conversation trimming on, it
| could create a rare situation where a database ID was re-used in
| a way that could result in this behavior.
|
| How is this bug even possible with E2E encryption?
|
| If picture.png exists on user A's phone and gets sent to user B,
| shouldn't it be client-side encrypted in such a way that user C,
| even if they receive it via some database ID screwup, are unable
| to view it (because it was encrypted with user B's public key)?
| okdjnfweonfe wrote:
| its probably not using chat keys for the db, for the sake of
| being indexable
| rvz wrote:
| I was just talking about Signal one hour ago whether if it was
| available on PinePhones or the Librem 5 which seems very unclear,
| and now this happens on Android devices.
|
| Does this mean that not only I can't yet recommend a PinePhone or
| Librem 5 yet, but for current Android users I can't even
| recommend Signal to anyone due to this issue?
| CodeGlitch wrote:
| Email. Why are we still trying to push these instant messaging
| apps that are a privacy and security nightmare? (I realise
| email has security issues too).
| Santosh83 wrote:
| Email has weaker EtoE encryption than these IM solutions.
| Even with GPG. Too much metadata is leaked. However the
| decentralised nature of email is one crucial advantage it has
| over these apps.
| CodeGlitch wrote:
| I agree about the EtoE encryption weaknesses. However since
| I can send email from my own email server to another email
| server without it touching a 3rd party (not including the
| ISPs and DNS servers) means EtoE is not such a massive
| issue.
|
| I can't make phone calls or video calls over email, but for
| text, small files and images it's perfect (given how long
| email has been around it goes to show how good it is).
| h_anna_h wrote:
| "Weaker E2EE" as in "PFS is not commonly used with email".
| As for the metadata, no metadata is leaked that signal does
| not also leak.
| maqp wrote:
| >As for the metadata, no metadata is leaked that signal
| does not also leak.
|
| Signal does not leak to third party servers with whom I
| talk to. There's encrypted comms to the server, and
| that's it. I try to talk to someone who has gmail
| account, Google now has access to 100% of my metadata
| with that contact. I trust Signal more than I trust
| Google with my metadata.
|
| Also, there's precedent from TWO court cases Signal
| doesn't collect your metadata. Show me one email vendor
| that has such real-life proof about not collecting
| metadata about their users.
| beermonster wrote:
| You _could_ in theory (but this is like putting plasters on
| a colander) relocate some of the MIME meta data (Subject:,
| To:, From:) to the email body and then encrypt it.
|
| So basically obfuscate the MIME headers and use some kind
| of guid@domain type addresses for the MTA routing.
| intellix wrote:
| I really enjoy the email chains that have about 1mb of HTML
| for a footer. The chain ends up being 100s of MB for about 6
| paragraphs of text. Very inefficient
| jayavanth wrote:
| Fixed: https://github.com/signalapp/Signal-
| Android/issues/10247#iss...
| TekMol wrote:
| A rather vague explanation. Sounds a bit evasive.
|
| Where is the commit that fixes it?
| jayavanth wrote:
| He replied to the Issue here:
| https://github.com/signalapp/Signal-
| Android/issues/10247#iss...
| lwhi wrote:
| Looks like this was fixed [1]. Doesn't fill me with confidence if
| this type of issue can occur though.
|
| [1] https://github.com/signalapp/Signal-
| Android/issues/10247#iss...
| m1r3k wrote:
| A non-techie relative of mine told me about images being sent to
| wrong people and them asking why they sent the photo. I first
| assumed it was just user error but apparently that's quite a bit
| data leak on signals side.
| muststopmyths wrote:
| Well, from a glass half-full perspective this provides a user
| with perfect plausible deniability about any illegal content
| found on Signal on their phone, or a message claiming to be from
| them to another user.
|
| Maybe it's a feature, not a bug ? :)
| tag2103 wrote:
| Fixed on 7/21. Forgot to close the issue:
|
| https://github.com/signalapp/Signal-Android/issues/10247
| johnchristopher wrote:
| While I suppose the protocol is not at fault and it's a UI and
| client bug it's still a huge problem.
|
| Just today I was thinking "it's been weeks since they moved the
| GIF button to a different place but there's still the old button
| at the old place and when you click on it there's a pop-up
| "wrong, the button is somewhere else now"".
|
| Why even keep the old button in the old place ?
|
| And it led me to thinking "what else could be wrong/buggy in the
| UI and the UX that is not obvious to them ?".
|
| edit: according to this comment
| https://news.ycombinator.com/item?id=27951648 there is only one
| dev working on the Android client ? Hats off to that person, it's
| incredible.
|
| So I should have written: And it led me to thinking "what else
| could be wrong/buggy in the UI and the UX that they haven't had
| time to catch and fix yet ?".
| mdoms wrote:
| This is the same app that only 6 months ago had an outage
| lasting more than a full day[0] - an outage that to my
| knowledge remains unexplained. The protocol is one thing but
| these clowns are obviously not careful or reliable engineers.
|
| [0] https://www.theverge.com/2021/1/17/22235707/signal-back-
| app-...
| kitsunesoba wrote:
| This underscores why it's important to allow third party
| clients to connect. When only the first-party client is
| allowed, the failings of its UI drag down the core, too -- it
| doesn't matter how good the core is if it's permanently mated
| to a half-baked UI.
| ViViDboarder wrote:
| With this party clients, you don't avoid this. The failings
| of a third party client will still reflect on the whole of
| the core product as well. Articles would still talk about a
| bug like this breathing a Signal issue, even if limited to a
| third party app.
|
| Additionally, I find it quite a stretch to call the app
| "half-baked". I think it's pretty great.
| rakoo wrote:
| And when third parties can connect, the protocol can't evolve
| because every change becomes "good to simplement" but it
| takes an enormous amount of time, resources And influence to
| change to "mandatory to implement". As always it's a delicate
| balance between security And ease of use, and Signal has
| always been up front in favoring the former.
| nmlt wrote:
| That would be the case if they'd standardize the signal
| protocol. Letting third parties connect has nothing to do
| with that. Signal can still change their API any time they
| want.
| retrac wrote:
| And Microsoft could in principle choose to do a hard
| break with all backwards compatibility in the next
| version of Windows. But they won't. Eventually, the
| third-party base may be so large and varied, that it
| becomes quite painful to actually make such a change even
| if the letter of the law says you can.
| lwhi wrote:
| In which world does Microsoft conform to open standards
| or protocols?
|
| Your point simply doesn't make sense.
| rakoo wrote:
| I replied in another comment, but letting third parties
| connect widens the surface area of the potential attacks.
| If that bug happened in a third party, from a security
| pov you must block them from accessing the service, at
| which point you need to decide if you want to police
| every single possible client or focus on one and make it
| widespread.
| [deleted]
| sschueller wrote:
| This doesn't have to be the case. Look at how stripe does
| it with their API which would be a disaster if older
| versions just stopped working. Versioning is doable even
| with chat apps.
| rakoo wrote:
| But Signal isn't just a chat app, it's an app with a very
| strong focus on security, and you can't have backward
| compatibility with security. Otherwise you end up with
| some servers still implementing SSLv3 years after its due
| date, or GPG with settings that make it insecure by
| default. You _must_ force everyone in the ecosystem to
| use the latest version of the API, but even that is not
| enough: if there 's an issue with the client (the issue
| in the article could happen with a third party) you must
| find a way to force it to upgrade; if they dont want to
| it's better to block them, but at this point if you need
| to choose where to best spend your resources you might as
| well block everyone else.
|
| Opening the service to other clients widens the potential
| surface area of attacks. It must be considered with a lot
| of care.
| lwhi wrote:
| I'd go further than this.
|
| It underscores why open standards and protocols are essential
| for a more secure world.
| deanCommie wrote:
| > Just today I was thinking "it's been weeks since they moved
| the GIF button to a different place but there's still the old
| button at the old place and when you click on it there's a pop-
| up "wrong, the button is somewhere else now"".
|
| That's actually a UX FEATURE. Google Maps did exactly the same
| thing when they reorganized and move the toggle between
| maps/satelite/traffic layers.
|
| The answer is pretty straightforward: Users get used to a
| certain UX. If you do a reorganization (to introduce new
| features, to improve performance, whatever), and move a button,
| a meaningful percentage of your users won't read the blog post,
| the release notes, or hunt for a new "Intuitive" location for
| the feature. They'll just assume you removed the feature and
| either panic or get mad.
|
| Leaving the old button in the old place is actually kind of a
| clever way to "Deprecate" a UX feature.
| carstenhag wrote:
| I agree. Am an app dev myself and the weird maps relayout of
| gestures got me dozens of times... Can't imagine how condused
| my mum or some not phone-savy person is.
| johnchristopher wrote:
| It has certainly not trained me to reach for the new way
| since it was introduced considering I strangely still reach
| for the usual and visible old way every time despite being
| treated with "lol, no". But I may be the exception.
| greysonp wrote:
| Yep, this was the intent. It's a relatively common pattern.
| We kept it that way for a few releases so people could see
| it, and we removed the button in the latest release.
| lostlogin wrote:
| > Leaving the old button in the old place is actually kind of
| a clever way to "Deprecate" a UX feature.
|
| That would drive me demented in 5 minutes.
| renewiltord wrote:
| Yeah, I actually like this UI feature. I would have been very
| frustrated if they had just changed it over on Google Maps. I
| use Timeline all the time and it was important to me.
___________________________________________________________________
(page generated 2021-07-25 23:00 UTC)