[cge]

As some details:

TeleMessage is/was an Israeli company [1], but was acquired last year by Smarsh [2], itself a subsidiary of K1 Investment Management, both US companies. It me whether the company moved. While not necessarily related at all, their terms of service also seem to explain specific arrangements for messaging in China that appear to involve disclosures to the Chinese government.

It's unclear to me how the app works. It appears to be advertised as a fork of the Signal client which uploads all content to a remote server, thus, of course, breaking the E2E encryption, unless the archive is considered an end and the connection to it is secure. It also appears to be advertised as being the same interface as Signal.

However, both the iOS and Android Signal clients are AGPLv3. I can't find any indication that the TeleMessage clients are anything other than proprietary. So are they going the route of giving the software and source only to paying customers under AGPLv3 (with those customers then free to distribute it)? Did they completely reimplement the client? Or are they an illegal proprietary fork?

The first option seems unlikely, and the latter two seem rather ominous for the security of the app.

[1]: https://en.wikipedia.org/wiki/TeleMessage [2]: https://en.wikipedia.org/wiki/Smarsh

[tptacek]

Smarsh is apparently a big deal in the compliance space. They're not randos. That doesn't take away the hilarity of using a Signal clone that defeats the whole purpose of Signal, though.

[defen]

Additional hilarity provided by their name being one letter different from the latinisation of a Soviet spy agency / Bond supervillain organization.

[schoen]

It looks like it was originally meant as a reference to the username of the founder (Stephen Marsh).

[wisemang]

Lousy smarsh weather

[diamondage]

Seems like an odd choice of name from an apparently low attack surface, cybersecurity aware company...

[cwillu]

> breaking the E2E encryption

E2E doesn't mean what I think you think it means; specifically, it has nothing to do with what the intended recipient (or their software) does with the message.

[cge]

That very much depends on who is running the archive system, and how it is implemented.

But more generally, your point is why I mentioned "unless the archive is considered an end and the connection to it is secure."

[IgorPartola]

The point of E2E is only to make sure that Alice is talking to Bob and nobody else can pretend to be either of them or eavesdrop. There is no reason whatsoever to include where else the message may be sent, encrypted or not.

Consider E2E protected email service. You send me the final designs over this encrypted channel. Then I put the designs onto a USB drive and give them to my printer to print. Then I hang them as billboards all over town. This is a valid use case for E2E. Yet the contents of the message ends up visible from the freeway.

You are confusing Snapchat mechanics for encryption.

[cge]

>You are confusing Snapchat mechanics for encryption.

I think we're talking about this from two different perspectives. You're considering a user in someone's conversation with a modified, archiving client. Yes, you obviously can't prevent that from a technical side, and it doesn't break Signal's E2E. It would be even simpler to do this with the unmodified Android Signal client, which essentially allows message exports.

I was assuming (possibly incorrectly) that TM's client was being used as an overall messaging system by the government groups involved here, which is how TM seems to advertise it: not a single user running their client, but every (or every internal) user communicating with each other using their client. In that case each user's client would be sending each message to some recipients by Signal Protocol and other recipients by, if other comments and some parts of TM's advertising are correct, SMTP. Yes, some sender-recipient pairs are E2E in that case, but that seems a bit besides the point, as there are others that aren't, and those could be vulnerable to eavesdropping and modification.

I do realize that what I wrote in the initial comment could easily be read as something other than what I meant (it isn't E2E for the messages through Signal that is broken, but separate likely non-E2E messages); I suppose I should have expected here that doing so would result in replies focusing on that interpretation.

[IgorPartola]

Yeah I mean clients that auto-delete messages are a very useful tool in communicating between people. It’s that they aren’t really meant for anything actually sensitive because (regardless of if they have E2E or not) they can’t guarantee that someone isn’t archiving or exporting the messages. It is the wrong mechanic for anything sensitive.

If you want to make sure nothing is ever archived, there is no software-only solution. If you control the hardware, in theory you can mandate that everything from the OS level-up is a reproducible build and you know for a fact that the messaging client does not allow any export feature. But also, you still have the problem of someone taking a picture of the screen. The real way to do this would be to control the software, hardware, and environment, aka a SCIF. If you want me to see classified war plans, confiscate all my electronics then show me what I need to see in a controlled environment where I can’t make copies. Messaging apps just simply can’t do any of that.

[cwillu]

Precisely. The security of a message endpoint ends at the point that the opposite party's leverage runs out.

If I care more about my snapchat account than I do about saving your disappearing message minus your ability to leverage snapchat into banning my account or apply outside social pressure, then your disappearing message may actually disappear. As the stakes go up, so does the leverage required for “endpoint security” to be a meaningful security boundary.

[UnreachableCode]

Is there a term for any application which offers full control of your messages then, ie, I send you messages on Signal, but I can make them self destruct and you cannot screenshot them? (Pretty sure Signal allows this?). Nothing stopping a user from taking photos of the screen using another device, of course. Or running their own fork of Signal (which, when run from the open source for Android at least, runs on production).

[IgorPartola]

Taking photos of your phone screen is the main loophole and is completely undetectable. Exactly what happened to Waltz and what caused TFA.

If you really need to, you can combine this with a rig that holds the phone and the camera just right, controls the lighting, and interacts with the phone via a hotdog mounted on a gantry. Come to think of it, any 3D printer can be adapted to archive Signal/Snapchat/etc. messages in a completely undetectable way. Could even reply if you rig up another phone to talk to your hot dog finger + camera robot.

[cwillu]

Dunno. Like I said, there's no way to do this effectively without some form of leverage over the counter-party. This sort of thing is why SCIF's exist, and is an example of the more extreme ends of leverage, but it still ultimately comes down to leverage: they can make you delete the message and will throw you in jail if you figure out a way to evade it.

One-time secret, maybe?

[guappa]

How can this exist?

[fluidcruft]

Just wondering... if you work for a company and your employer provides you with modified GPL software, it's not considered distributed to you in ways that GPL would apply (so you are not free to further distribute it). At least that's how GPLv2 used to be explained as as business friendly--"private" modifications remain private and employees are not considered exterbal distribution. I'm not familiar with AGPL though.

[giancarlostoro]

AGPL is essentially GPL but over the network, if you can reach the service (be it website, or any other protocol) you should be able to receive a copy of the source code. TruthSocial was based on AGPL'd code, they had to comply.

[sterlind]

if your company itself modified the GPL software, you can't demand the modified source code from your boss. if your company purchased modified GPL software from a third party vendor, your company's legal department could force the vendor to cough up the source code.

[wmf]

The realpolitik here is that you can get fired if you leak the code, legal or not.

[giancarlostoro]

> Or are they an illegal proprietary fork?

As long as their clients can redistribute it, its not illegal, especially if their clients have 0 interest in leaking the source code, the real trick is, has anyone who is NOT using that client hit any of the AGPL relay servers?

For context, I worked for an employer that sold a custom software solution, which used GPL'd software, client was in the military space, so I guess DOD, anyway, for over a decade nobody asked for any of the code, till some years back. I am guessing they just wanted to have it evaluated, but it was a workhorse of many many things, good luck trying to fork it, LOTS of moving pieces involved.

Nothing illegal unless someone who touches a TM SGNL server (somehow) requests the source and they reject you from having it.

[cge]

Yes, that's what I meant by the possibility of them only offering source under AGPL to paying customers. Oddly enough, I'm familiar with that in the completely different context of davisr's reMarkable Connection Utility, and the model can work reasonably.

But from their website, which has terms of service for each app, it really seems that they are presenting them as standard proprietary closed-source offerings.

[Hobadee]

> unless the archive is considered an end and the connection to it is secure

LMAO NO! I have quite a few clients using Telemeasage, and most of them use Global Relay on the backend. It's a little terrifying actually, as Global Relay just ingests everything via SMTP. I haven't checked if they have DNSSEC or MTA-STS set up, but with how Global Relay operates I would be surprised if they did. I suspect a well-placed proxy or DNS poisoning could siphon off a good chunk of sensitive emails being sent to Global Relay.