Would Telegram and others please stop using phone number as a primary source of identity? It's 2018, I have a data only sim and I have no desire to have a phone number.
If I could only upvote this more. I still want someone to take signal's protocol and do a BYOK approach. Let me use Keybase or something similar to handle identity management. Additionally, each device (or app instance) gets its own key. Signal and WhatsApp already do encrypted group messages. Treat each of my devices as different "users", who present with the same name.
It's a tractable problem.
(NB: Not necessarily keybase, but they do have a technical solution to the problem in place already.)
Proprietary? The backend maybe, but the keybase clients are open source. Some of the code is a little rough, and completed API docs would be nice, especially concerning KBFS, which is still missing. It's still under heavy development though, so these shortcomings should be understandable. (I personally won't use it much until I can actually develop my own non-reverse-engineered client, but that's just my requirement.)
No, the server implementation is proprietary. Therefore, it's a walled garden that relies entirely on them. Supporting federation would be going above/beyond just releasing the server implementation's source under a permissive license. As it stands today, you have no choice but to rely on their proprietary server implementation, since the clients are useless on their own.
Considering the whole point of end-to-end encryption is to reduce or eliminate necessary trust in the middleman, this seems like a minor, but still valid concern. Open sourcing the backend code wouldn't allow you to attest to what's running on the server. If the clients also allowed you to point to a custom server URL, which I would support, then the source availability might matter.
Without the proprietary server backend, you cannot use the clients. It's a walled garden. If keybase goes away for whatever reason, you're stuck. You cannot host it yourself, others cannot host it, and even if they released binaries, you'd have no idea what it is doing with the unencrypted 'metadata'.
I didn’t dispute the description of Keybase being labeled a walled garden. I opposed it being too-broadly called proprietary, when it’s not — only the backend is. And for anyone only using the official keybase servers, that’s irrelevant from a trust perspective, which is the reason people usually (mistakenly) bring up source code availability.
Now I’ll also partially dispute the accusation of it being a walled garden, since walled gardens don’t have open specifications and documented APIs for third-party client implementations.
The backend source code would be good to have, for the prudent reason you pointed out, as well as for private instances, but that’s not enough: you also need client code modifications to allow configuration for custom servers.
About binaries: anyone who thinks source code is required for determining program behavior probably shouldn’t be auditing software in the first place. (Often having just the source code makes it more difficult, not less.)
> And for anyone only using the official keybase servers, that’s irrelevant from a trust perspective
Gosh, not really. They completely control who can use the service, and any information they 'require' to register for the service.
> since walled gardens don’t have open specifications and documented APIs for third-party client implementations.
I'd like to point out that walled gardens will still openly invite folks to join, and give them tools that they could reproduce, but give them no way to experience the garden outside the walls.. including the tools previously given that are also useless outside the walls. That's exactly the case with keybase.
> About binaries: anyone who thinks source code is required for determining program behavior probably shouldn’t be auditing software in the first place. (Often having just the source code makes it more difficult, not less.)
Huh. I'm interested in hearing how having source code makes autiting more difficult, since that has not been my experience.
I agree with you that Keybase should release their backend code. My comment about (server source code- derived) trust was made in the context of users who would remain using the official keybase.io API servers, which would probably be the vast majority of Keybase users.
It’s not all of the time, or even most of the time, but frequently there are reasons for preferring binaries:
- build systems which are more annoying to setup than just straight reading the assembly / IL dump (ex: android)
- you might want to reverse and/or edit the binary anyway — to look at compiler output, as one example
- it’s sometimes faster to understand the asm than it is to go over the code, compile it, and compare [non-]matching binary outputs (this is regularly true for smaller programs)
- the tools for analyzing binaries are often more advanced than code tools
Many people don't realise that they don't own their phone number! It is possible to own a phone number but it is not widely available just like domains are. Hence it is a stupid idea to use it as an identity.
There is an infinite supply of numbers. You can just add extra digits. Mobile phone numbers used to be 8 digits in NZ, then became 9 digits when they needed more numbers.
Same. I'm nomadic at the moment, and have to change sims with each country. I don't have a permanent phone number (or address). I know I'm in a minority, but still... it's like
things businesses assume about people:
1: they have a phone number.
2: they have an address.
3: the country they are in at the moment is the country they live in
Project Fi from Google has been a lifesaver for me while traveling. I get to use the same number everywhere I go and don't have to do the new SIM dance in every country I visit. It can also be very handy sometimes to have internet access minutes after hitting the tarmac.
They've also expanded it to support more phones recently. I think having a Fi phone, even if it's not your primary device, makes a lot of sense for nomads.
Agreed that such services should stop using phone numbers. In the meantime, you can get inexpensive numbers from https://jmp.chat/ - useful for 2FA as well.
This is possible? Or do you technically have a phone number but just don't use it? Also, don't lots of situations require you to give a phone number? How do you handle that?
It's a Google Fi data only sim, so nope no real phone number. I do have a number through Google Fi and Google Voice, which usually works for 2fa but not always. The phone number goes directly to voicemail always.
Using a phone number does let the app quickly build a social graph of your friends using it. But email could do the same thing, with higher risk of fake accounts.
It could be worse, an app could say "You must sign up with Facebook"
In cases like these I usually buy a pre-paid SIM for a few cents, verify the account and throw the SIM away. I can continue to use my main data SIM then.
I’m not sure if I’d really trust any platform to store my personal documents without encrypting them myself before the upload.
But I’m always amazed at the pace at which Telegram keeps improving its feature set and UX. I haven’t experienced a messaging platform that’s anywhere close to it on these aspects. And for these reasons alone, it still remains my primary messaging application (while I keep checking the competition to see where they are).
Personally I don't trust telegram because of their funding source.
Additionally their first encryption protocol was extremely wonky and most people I know would correctly call it unsafe for use in a chat messenger.
Their second version is a tiny bit better but neither has been verified by any proper cryptographer I know.
Additionally Telegram as an App seems more like a Toy rather than a proper chat app, the stickers are big and completely destroy the flow of a conversation last I checked it. Other features are like this too.
Lastly, to my knowledge, end-to-end encryption is not enabled by default, neither for private messaging or groups. That's just a no-go for any chat application for me.
> Personally I don't trust telegram because of their funding source.
You could say the same for Signal (before Signal Foundation was created this year) or Wire (created by the people who created Skype) too.
> Lastly, to my knowledge, end-to-end encryption is not enabled by default, neither for private messaging or groups. That's just a no-go for any chat application for me.
The “secret chats” are always end-to-end encrypted. The normal chats are encrypted only in transit and not end-to-end. But secret chats are also tied to a single device (currently only phones), unlike Wire, which offers end-to-end encryption and synchronized conversations across devices.
I can't help not to trust telegram with my data, just gut feeling. You cannot use their service without giving your telephone nr. Now they like to have your ID's too. How can they honestly advertise "anonymus chat"? And the double ICO, over a billion fetched. So much money and data, where does that lead to?
I have a similar distrust of Telegram just because of where they started. (and I admit that isn't logical) But I think I trust someone with lots of data AND lots of money than someone who only has lots of data.
I wouldn't remember a time where telegram claimed anonymous chat. Sure encrypted chat, private chat, not collaborating with fbi for chat history are good things.
But telegram never advertised anonymity as a takeaway.
Wonder if this was influenced in part by the fact that Telegram is the messaging service used by most ICO organizers. Could help in the KYC process that is becoming more commonplace.
The unintented consequence of this will be that now any website can easily demand real life ID. Ordinary, non-financial websites (think Reddit, Twitter, Hacker News) will require ID to log in, to protect against spam and make the community safer.
This implements the dream of authoritarian governments that internet access should never be anonymous. Russian government officials have long wanted to establish a similar authentication system.
I feel that your post is being a bit dishonest, as it ends with the following:
> UPD: The story ended well. Vulnerability is corrected, documentation and applications are updated, treasure hunters of bugs are motivated, which has already yielded results (1, 2). It is necessary to pay tribute to the developers of Telegram, who immediately reacted to the article.
It's hard to say that it's not a mistake when the author of the article itself describes their response as "immediate".
Durov and Telegram have more or less shown their mettle; there was no money or profit in standing up to Russia, but they went ahead and did it anyways when it would have been easier to buckle. Yes, it has flaws in its implementation, but so far they've proven that when push comes to shove, they're willing to fight for their politics and to keep on fighting against such regimes. Once this changes, sure, it's fine to lay into them, but right now it really looks like they're true to their word.
> It's hard to say that it's not a mistake when the author of the article itself describes their response as "immediate".
It is an obvious backdoor.
They justified XORing in arbitrarily string into the key you have established with DH with the fact that your phone may have bad random number generator. But it obviously gains you nothing. If the server is honest, then it does not read your secret chat anyway. And if the server is malicious or compromised, it knows the string.
So even if it is possible to overlook the possibility of XORing in the difference of keys and evading MITM detection, it is very unlikely that no developer (for example, someone who coded it into the server or one of the clients) have seen that it gains you nothing in any scenario you can think about.
When users started to asking developers for the explanation in the comments, W_K (main developer of the protocol, brother of Pavel Durov) stated that they "don't know" who added this feature in its current form. Shortly after, he stopped using his account or answering any questions at all: https://habr.com/users/W_K/
Upd: regarding the remark in the end of the https://habr.com/post/206900/ that "the story ended well", Telegram team is responsive etc.
Keep in mind that they paid this guy. Adding such updates to articles and publicly confirming that the bug was fixed is almost surely a part of the bug bounty agreement.
This looks rad. Unfortunately, I won't be able to use Telegram Passport. I can't even read this post without a proxy because my government actively blocks Telegram without a publicly given reason.
I wish they'd spend more time figuring out how to get around the domain fronting problem.
Their messaging application had horrible security in past, and there have been many discussions on HN about Telegram vs Signal. Why would I trust them for ID when their messaging was suspicious....
I'd more happy if they would implement an option to turn-off link fetching and also ability to use their service without phone number.
As for this Passport - I'm not interested in this feature and I can't see where it would be useful for me. Not mention the security with just their assurances that nobody would have an access to my personal info - it's ridiculous to say least.
If this is to deliver your ID for the purposes of KYC laws, then that’s somewhat sensible, I suppose.
If, however, this is targeted at the providers who are actually collecting IDs as part of their AML compliance strategy, then there’s a much simpler solution here: just become the ID equivalent of a Certificate Authority. Dedup Telegram accounts by using a unique constraint on accounts’ validated ID documents’ extracted creds; and then allow sites to use Telegram for Single Sign-On. Boom—instant surety that each of your users is a real person, and not fifty bots laundering one person’s money; and no need for anyone besides Telegram to actually see your ID (i.e. a much lower chance of identity theft.)
Plus, if enough sites require SSO through an ID-document verifying identity provider, then even sites that ha d no legal reason to require it can free-ride off the benefit in user-deduplication it provides. Imagine, for example, a Reddit or a 4chan where users are still pseudonymous or anonymous, but where banning a user truly works, permanently, with no routing around it (unless you have the criminal connections required to buy yourself a new real-world identity.)
Even governments are willing to use SSO if it's SSO using entities both they and their customers trust with their money, e.g. major banks. (At least, that's how it is here in Canada with https://securekeyconcierge.com.)
Given that Telegram is already a payment processor (i.e. something people trust with their money), it could serve a similar role, no?
