OTR + telegram-purple = phone number leak

[n0toose]

Steps to reproduce

• Leave OTR turned on by accident, since you tend to use encryption in your casual XMPP-related communications.
• Your "account name", also known as the phone number which isn't meant to be public unlike an XMPP address, gets shared with the other party.
• Congratulations, you've now inadvertently leaked your phone number to a stranger on the internet.

._.

[EionRobb]

Unfortunately this is hard-coded into the OTR plugin to use the account username during negiotiations, as it makes the assumption that usernames are public (which, for the built in protocols it normally is)

[n0toose]

Yeah, that sounds normal to me, but why does the plugin also proceed to throw a phone number under the field where things are presumptively public? Despite it being a login method, it is not quite infallible either, as multiple accounts can be technically registered under one phone number (see: MTProto applications with tokens).

[BenWiederhake]

I can absolutely see how this bothers you. However, changing this would be a large effort, and I don't quite want to do this with telegram-purple.

Can you give tdlib-purple a go? It also uses the own telephone number as an ID, so maybe it has the same issue? If it has to be implemented anyway, I strongly suggest implementing it for tdlib-purple. (Maybe the internal ID could be an account setting that must be set during account creation? Or possibly even some nonsense like a UUID?)

[bodqhrohro]

I posted an issue about it in the pidgin-otr bugtracker almost a year ago:

Though from that on, they removed the issue, and probably my account too. AFAIR, I logged in via OAuth, which is now missing.

[n0toose]

I posted an issue about it in the pidgin-otr bugtracker almost a year ago:

Though from that on, they removed the issue, and probably my account too. AFAIR, I logged in via OAuth, which is now missing.

Sounds a bit hostile, although I'd see why they wouldn't like to make specific exceptions for whichever Pidgin plugin pops up. Maybe a feature request involving allowing developers of other plugins to exclude themselves from OTR support instead could fair a bit better?

[bodqhrohro]

Sounds a bit hostile

I doubt it was intentional. Maybe they just dropped all OAuth accounts along with content created by them, as there was too few of them and it was easier to sacrifice them rather than properly migrate the content to the anonymous account. Though I'd better try to contact them for clarifications than guess.

Also, I see at least two newer issues about leaking the username, but via other channels.

to exclude themselves from OTR

Why? The good side of OTR is that it transparently works through any plaintext medium, be it picture metadata, SMS, or pigeon mail ;) Locking it out from some protocols would be rude.

[n0toose]

@bodqhrohro It assumes that:

a) Both users are communicating through Pidgin by default, while sacrificing the privacy of the user in a very, very horrible and unexpected manner.
b) Since this add-on is built on top of MTProto and Secret Chats are supported, why is an implementation that's basically VERY flawed in this case scenario and could only work as an additional layer of security turned on by default? Additional encryption is supposed to protect the user, but the takeaway here is that it can be more compromising than anything, sane defaults count!

Giving developers the ability to opt-out, rather than either being forced in and having to use it everywhere or nowhere is basically the most sane response to this, although it's probably out of the scope of this project for the time being.

[bodqhrohro]

and Secret Chats are supported

I guess it's a matter of trust: for some persons, OTR is more trustful than Telegram's self-invented E2EE. I definitely know that some persons use OTR over Telegram, as they requested OTR support in Zhabogram (by default, Zhabogram prepends a header to the content of every message, which breaks OTR).

BTW, I reached @DrWhax on IRC, and they told that the account/issue deletion was probably a spam misdetection, and also that pidgin-otr may get frozen, for the slow development pace of Pidgin and its security being a mess, so the issue will barely get fixed anyway.

[bodqhrohro]

Oh, and I encountered a reason to use OTR over Telegram: unlike native Secret chats, OTR-encrypted messages in plain chats can be stored on the server and synced across devices.

[n0toose]

I guess it's a matter of trust: for some persons, OTR is more trustful than Telegram's self-invented E2EE. I definitely know that some persons use OTR over Telegram, as they requested OTR support in Zhabogram (by default, Zhabogram prepends a header to the content of every message, which breaks OTR).

Yeah, the truth is that you're absolutely right with this. I spoke through the lens of my own frustration, I'll probably consider using this but it's barely possible in its current state, as a person who also uses Telegram for groups and to talk to people on the internet that probably have no business of knowing my personal phone number anyways.