Post AsRKsREXpeiECdMbRY by veronica@mastodon.online
(DIR) More posts by veronica@mastodon.online
(DIR) Post #AsRKsREXpeiECdMbRY by veronica@mastodon.online
2025-03-25T19:09:32Z
0 likes, 0 repeats
Whatever it is those incompetent clowns are doing over there in 'murica, I got multiple contacts who weren't on Signal popping up there in the last day or two.It's good advertising for the service at least!#Signal
(DIR) Post #AsRKsST7Exxi27BknI by veronica@mastodon.online
2025-03-25T19:17:23Z
1 likes, 3 repeats
Haha, good one!#Cryptography
(DIR) Post #AsRKsXaODLkdu7d8KG by veronica@mastodon.online
2025-03-25T21:33:26Z
0 likes, 0 repeats
Not sure who made the edit, but the original illustration is from Wikipedia.
(DIR) Post #AsRKsZ1MsWvSM5GC12 by veronica@mastodon.online
2025-03-25T19:17:59Z
0 likes, 0 repeats
CC @turid 😁
(DIR) Post #AsRgPNLLPoGCjN5hqK by divVerent@blob.cat
2025-03-26T11:48:37.570308Z
0 likes, 0 repeats
@veronica From the news I seen about this, it's actually _different_ from Eve or Mallory, as the Atlantic was added by accident, and didn't even actively try to attack. A scenario cryptographers usually don't even think of... but that is worth talking about in cryptography context as well.Although, most solutions of that are not cryptographic in nature, but more... user interface questions. I do wonder if cryptographic solutions exist though... a dumb idea could be "topic keys" that represent e.g. one's security clearance, that are used to wrap the encryption keys of the messages themselves, in addition to user or room keys - so even if someone invited someone to a classified room by accident, the person wouldn't be able to read conversation unless they actually get the necessary clearance.Although neat, this does seem to be unnecessary as this can just as well be managed by not inviting them to the room in the first place (and e.g. having serverside safeguards for that). Or even pure clientside solutions, like grouping contacts in a room by whether one knows them, what department/organization they work in, what clearance they have etc. so even if someone were to be added to a room in error, someone else is soon gonna notice.
(DIR) Post #AsRlLLUSrVCJb3Fqkq by veronica@mastodon.online
2025-03-26T12:13:13Z
0 likes, 0 repeats
@divVerent You forgot the "well, actually". It's required for these kind of replies.Edit: Never mind, saw the "it's actually _different_". Good to go!
(DIR) Post #AsRlLMk6CrIXTpZqlM by divVerent@blob.cat
2025-03-26T12:43:54.450403Z
0 likes, 0 repeats
@veronica Maybe yes, but I am truly interested in whether any chat service will actually add any countermeasures for an "not really attack" like this.I actually find it kinda sad how Signal deflects. It seems to me the actual vulnerability was Android's though, with showing default avatars of user's initials.Maybe we should go back from those two letter avatars, and move back to showing e.g. user identifiers such as email addresses?
(DIR) Post #AsRnDkhnQf4pOJzu0O by veronica@mastodon.online
2025-03-26T12:53:27Z
0 likes, 0 repeats
@divVerent Someone pointed out somewhere that the reason Signal is not secure in this context is that it is run on non-secure devices and doesn't restrict who can be added to the chat. It's less about the E2E itself.The secure communication services provided for this level of discussions already covers all of these additional points. But they also have an audit trail, which I guess is one thing these people don't like.
(DIR) Post #AsRnDlhpi0hUUj1RhY by divVerent@blob.cat
2025-03-26T13:04:56.734922Z
0 likes, 0 repeats
@veronica > doesn't restrict who can be added to the chatYeah, and Signal also doesn't try to provide that. That doesn't make the app less secure.I do have some constructive user interface ideas though how this could at least be improved. Even if a pure clientside thing. Imagine as a user you can put your contacts in groups. And when in a group chat, you see an overview about how many users of which group are in there, with their avatars or something.Then if _any_ participant in the group chat had done this, they'd have seen an entry like "Press (1)" and that'd have been obvious...
(DIR) Post #AsRwZlkh7JnAb0vUf2 by niconiconi@mk.absturztau.be
2025-03-26T14:44:03.006Z
2 likes, 0 repeats
@veronica@mastodon.online More like this.
(DIR) Post #AsS2NEnSPzY0dWctg8 by jsit@social.coop
2025-03-26T15:50:39Z
0 likes, 1 repeats
@divVerent @veronica An accidental bystander will now be referred to as “Jeffrey”
(DIR) Post #AsS2kMGknlRgTMM1nE by divVerent@blob.cat
2025-03-26T15:58:55.498120Z
0 likes, 0 repeats
@jsit @veronica
(DIR) Post #AsSERF2Ag17nysBUDQ by kris@outmo.de
2025-03-26T14:30:01.306876Z
0 likes, 0 repeats
@divVerent @veronica The actual solution is to use a messaging service that is designed for such usecases. Signal's security is rather weak. XMPP for example offers security lables as a possible solution, so that even if you accidentially mess up something, the messages can only be recieved if you have the right security clearance: https://xmpp.org/extensions/xep-0258.html
(DIR) Post #AsSERGBmNmP9YxgfpY by divVerent@blob.cat
2025-03-26T18:09:51.282921Z
0 likes, 0 repeats
@kris @veronica Indeed. Even #Matrix, which doesn't even have a defined _extension_ for such things, could be made to work for this, simply by having per-clearance instances and having them not federate with each other.In Signal none of this was an option, simply because Signal is centralized.