Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Introducing Telegram Passport

telegram.org

Post reply on HN
Print view View original

61–70 of 85 posts

Re: Introducing Telegram Passport

#61

Post by reustle »

yosito wrote: post #49
reustle wrote: post #3

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.

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.

Re: Introducing Telegram Passport

#62

Post by shub »

ryanlol wrote: post #27
csydas wrote: post #10

Earlier quoted context omitted.

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…

None of this addresses the fact that there's no other realistic explanation for this besides an intentional backdoor.

Hanlon's razor?

Re: Introducing Telegram Passport

#63

Post by twr »

craftyguy wrote: post #53
twr wrote: post #50

Earlier quoted context omitted.

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.)

Re: Introducing Telegram Passport

#64

Post by craftyguy »

twr wrote: post #63
craftyguy wrote: post #53

Earlier quoted context omitted.

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…

> 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.

Re: Introducing Telegram Passport

#65

Post by twr »

craftyguy wrote: post #64
twr wrote: post #63

Earlier quoted context omitted.

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…

> 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 t…

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

Re: Introducing Telegram Passport

#66

Post by dvfjsdhgfv »

reustle wrote: post #3

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.

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.

Re: Introducing Telegram Passport

#67

Post by cdmckay »

Kadin wrote: post #45
swirepe wrote: post #9

Earlier quoted context omitted.

I think everyone wants phone numbers to prevent people generating billions of accounts to spam people with.

That seems like a pretty crummy way to solve that particular problem.

So crummy that WhatsApp built a billion dollar company on it. It seems like a good-enough solution to me.

Re: Introducing Telegram Passport

#68

Post by derefr »

wmf wrote: post #31
derefr wrote: post #14

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’ extrac…

Companies that deal with money aren't going to use SSO; they want to own their login system.

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?

Re: Introducing Telegram Passport

#69

Post by ryanlol »

shub wrote: post #62
ryanlol wrote: post #27

Earlier quoted context omitted.

None of this addresses the fact that there's no other realistic explanation for this besides an intentional backdoor.

Hanlon's razor?

Can you maybe explain to me how that could be applicable here?

I’d like to know of a vaguely plausible thought process that would result in this implementation.

Re: Introducing Telegram Passport

#70

Post by zaarn »

procinct wrote: post #34
agentdrtran wrote: post #4

I really wish telegram would focus on being a messaging app and not whatever this is. I'm not going to trust them with my info.

Any reason in particular you choose not to trust Telegram? Or you're just (rightfully) distrustful of sharing that info in general?

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.

Post reply on HN