Implement "secret chats" in Webogram

[thomasfr]

At the moment secret chats are completly missing. It would be great if one could create new secret chats with all options (self destruct timer, etc) and security features known from the official telegram mobile clients

[GameScripting]

+1, start with encryption, implement other features later as end-to-end encryption is what makes telegram cool ;)

[thomasfr]

yep you are right @GameScripting . I really miss this feature on my laptop...

[zhukov]

To tell the truth, Webogram is currently very far away from this feature. It doesn't use any sql storage which is required by secret chats. So this feature may be implemented in future, but it's not that easy.

[thomasfr]

How can we help? IMHO a good starting point would be to extract the mtproto implementation to a seperate repository. This way the protocol api could be independently developed. see this https://github.com/zhukov/webogram/issues/124

[zhukov]

@thomasfr I don't understand how this is connected to secret chats. The mtproto.js library is completed and I don't see any things that can be significantly improved in it right now. So what's the point?

[GameScripting]

@zhukov I haven't looked deeply into telegrams API, but it seems like one just has to use the secret messages api and thats it (https://core.telegram.org/methods#working-with-secret-chats) Why is a SQL like storage required? How does it differ from the normal non-encrypted api exept that you have to encrypt the messages? :)

[zhukov]

In secret chats we have to store all the history on client side, because server deletes it after it's downloaded by client.

[thomasfr]

@zhukov sorry, i thought it has to be implemented yet in the mtproto itself. But anyway, making an seperate library from mtproto, would be still an improvement imo.

[staltz]

This should be a priority, because it's a core feature of Telegram. "Taking back our right to privacy". I can imagine that it's a lot work, though.

[jumoog]

store everything in sql seems not good read: https://developers.google.com/chrome-developer-tools/docs/resource-panel

you can access sql db from developer tools :-1:

You cant hide your key since we use javascript

[stefan-niedermann]

is it important to hide it? I think it's your machine, your browser, so it is okay, if you view your keys and chat-data. Thought the problem was to implement the encryption, not storing the messages?

[jumoog]

it is ..because connection is not safe anymore ??

@ pc its not protected

@ android the data folder is special protected and can only read by system, root, or app itself

[stefan-niedermann]

@ android the data folder is special protected and can only read by system, root, or app itself

many people are root at their own system. this is the way it should be, so i can read my data on my android device, and i should be able to read the data on my notebook. i don't see this is important.

[staltz]

@stefan-niedermann , who said people only access webogram from their own computer and browser? And even so, what about malware? If encrypted conversations are to be implemented, let's at least do it right. There's no point in making fake secret chats.

[jumoog]

we can use web sql but firefox cant handle it :-1:

[GameScripting]

How is the identity/session id of the user stored? Isn't those information also security critical?

[jumoog]

you can read the messages sure but thats all

my idea was a native keystorage written in NaCl

[GameScripting]

I guess we only have two options here:

1. Don't encrypt anything and store it at localstorage/indexeddb/websql
2. Have the user enter a password every time she opens webogram and use the password to decrypt the secret stuff

Personally I'd say that we don't need that level of protection here, if one can read the browsers data (escape from the browser sandbox) one could also read the data on the phone (escape the app sandbox)

[jumoog]

firefox dont support websql

[nukeador]

websql is NOT a standard.

IndexDb is the way to go:

http://caniuse.com/#search=indexdb

[jumoog]

same problem safari dont supports it. we can use https://github.com/axemclion/IndexedDBShim "you can use a single offline storage API across browsers (Opera, Safari, Firefox, Chrome and IE10) and even mobile devices (Phonegap on iOS and Android)."

[Dinduks]

This should be a priority, because it's a core feature of Telegram. "Taking back our right to privacy". I can imagine that it's a lot work, though.

:+1:

[rafaelmr2]

@zhukov And now with IndexDB support this functionality is closer?

[yajo]

My 2 cents about local storage options: https://hacks.mozilla.org/2014/02/localforage-offline-storage-improved/

[timkuijsten]

I would really like to use secret chats since only end-to-end encryption fulfills the promise of "taking back our right to privacy". Unfortunately, as a Firefox OS user, I can't use any other client that supports this feature, as suggested in #652.

@zhukov What are the performance related issues you mention in #652 and might they be mitigated by using the WebCrypto API?

[nukeador]

I don't know if this could also help while WebCrypto is implemented in all browsers:

https://github.com/vibornoff/asmcrypto.js

[zaxebo1]

@zhukov with reference to https://html5test.com/compare/feature/storage-indexedDB.basic.html

VERY IMPORTANTLY (for SQL storage in browsers): indexedDB is now supported in Chrome version 26+ (current version is 39) , Firefox version 17+ (current version is 35), Internet explorer 10+ ( current version is 11), Opera version 18+(current version is 26), Safari version 8.0 (current version is 8.0)

also refer: http://www.w3.org/TR/IndexedDB/ Hence, indexedDB is "Official" recommendation by W3c since 8 january 2015 - for SQL storage in webbrowser .

HENCE, if indexedDB (Sql storage) is now supported in all the browsers(chrome,firefox,IE,Opera,Safari), then obviously it can be implemented such that -> "webogram can sniff that if indexedDB supported version of browser version is there, then only it will support secretchat."

[zaxebo1]

@zhukov Even if (say) secret chats can be held only on different client device "without any syncing between secret chat sessions devices", still with that limitation the secretchat will be great feature to have . Just show that limitation of"no syncing" as warning in-red-color above the secret chat window. Even then with this limitation too, Everybody is just dying to have this feature in webogram.

Also, When native OSX version client can have this feature, then why not webogram?

IMHO, this is the topmost requested feature in around my all known users group. If this secret chat functionality in webogram too comes , then Telegram popularity will beat Whatsapp,Snapchat in "very very short time". This should be prioritized above any other feature request, in my humble opinion. It will be very easy for "us" to push/evangelize/dictate usage of telegram to a large number of users due to webogram secret chat support. The entire humanity of millions and billions will thank you a lot, just for this "one single feature-request" implementation. Trust me. Please, make it number 1 priority, when indexedDB is here in every browser.

[zhukov]

I was really disappointed with IndexedDB support in Safari right now. It's much slower than in any other browser. So I supported caching Telegram files for Safari and then disabled it by useragent sniffing. It's pretty raw for now, IMHO.

As for the overall question I've already expressed my opinion in some other thread:

For now I don't have any plans to implement this feature. I like secret chats as it is right now -- on mobile device, which is private in most cases. Desktop is usually shared, especially its browser, so I don't like implementing Secret Chats in Webogram. Apart from this one, there are a lot of other important problems which we need to solve. Most of them are related to performance.

[timkuijsten]

As a stopgap, would it be possible and easier to implement self destructing messages without the crypto? So that at least I can make sure the messages created on FxOS are removed from Telegram's servers at some point. Or is this something that MTProto does not support (can't find it while glancing over the docs)?

[zhukov]

@timkuijsten I'm afraid, no. Self-destructing messages is a feature, which is available for Secret Chats only. But you can delete cloud chats manually in Webogram.

[timkuijsten]

But you can delete cloud chats manually in Webogram.

@zhukov but in order to get the chats from the servers you have to ask every participating party to do the same which is a bit cumbersome imho.

[zhukov]

@timkuijsten yeah. I think, the power of Telegram is in both Cloud Synchronisation and Secret Chats. At the moment Telegram Web is focused on the first one, since it's a Web App. However we may support Secret Chats later.

[wp9015362]

Hello,

I was about to use Webogram and expected it to support secret chats.

But then I noticed that it currently does not support secret chats.

That is extremely unfortunate.

Please add support for secret chats to Webogram and please make it a number one priority.

This is really needed IMHO (and apparently others seems to agree).

Could you please make it happen?

It would be much appreciated.

Regards

[BreadMaker]

A little more than one year have passed, any updates on this?

[timkuijsten]

Even if this were implemented, the fact that with Telegram keys are session bound and not person bound makes it a real hassle to use in practice. You have to verify the key each time you start a new conversation with someone, instead of just once for a particular user account. This makes that the TG secret chat feature is really cool for the TG marketing department, but not so much for real practical security.

[BaseMax]

this will never happen.

On 05/08/2015, Felipe Peñailillo notifications@github.com wrote:

A little more than one year have passed, any updates on this?

---

Reply to this email directly or view it on GitHub: https://github.com/zhukov/webogram/issues/126#issuecomment-127733619

[zaxebo1]

@timkuijsten : whatever be the logic, but that does not explain that "telegram official client for Mac Desktop" supports encrypted chat, then why does the "officlal Generic Desktop client " does not support it. Why linux and Windows using persons only are the people who have been "officially" kept away from this?

If we go by your justification , then secret chat facility on 'Mac OSX official telegram client' should also not have been implemented !

[timkuijsten]

If we go by your justification , then secret chat facility on 'Mac OSX official telegram client' should also not have been implemented !

It's just that since I'm really using the secret chat (via the OS X Desktop client indeed), I realized that it's not as good as I thought it was. And this has nothing to do with a particular client, but with the protocol itself. Every time I start a new secret chat with my friends they frown upon me why I'm doing that, even without out of bound key verification. And this is something that needs to be done for every new session which happens once in a while, not once per friend.

I think if they didn't give it a special name and didn't use the word secret and renamed the normal chat to something like "public chat", a lot of the frowning would go away. If then the protocol designers would abstract away the session keys and make users only interact with long lasting person bound keys, we would have some practically usable secure communication.

[TJC]

I continue to be very disappointed that there's no end-to-end encrypted chat available for most clients. (Sounds like mobile and OSX only support it?)

If I just wanted a regular chat client, I would have stuck to an established system like Jabber, or hell, even facebook messenger or google's hangouts.

[TJC]

Tim -- while I can understand your frustration with the new session keys, I think it's probably an important security feature. By creating a new session key each time, it means that your older chats will not be revealed even if someone gets hold of your current session key for a future chat. Maybe your friends can just be a bit less judgemental?

[timkuijsten]

I think it's probably an important security feature.

@TJC long lasting user bound keys can have this feature as well if something like forward secrecy is used. Then you still have per session keys and the advantages you describe, except you don't have to bother the users with it every time.

[timkuijsten]

ps. just stumbled upon the following statement from Matthew Green, a respected cryptography researcher:

\ Telegram is missing from this list because their protocol doesn't handle long term keys at all. Every single connection must be validated in person using a graphical key fingerprint, which is, quite frankly, terrible.

http://blog.cryptographyengineering.com/2015/04/how-do-we-build-encryption-backdors.html

[AchoArnold]

@hebrew878 Thanks for the very helpful comment :wink:

[programizer]

Would it be possible/a simplification to implement secret without history for now? So one reads only the last message and sql isn't needed?

[FacundoAcevedo]

+1 !!

[hkrahi]

G

[mangas]

+1 for a simplified/no history secret chat implementation

[haevalencia]

As other similar services -especially Wire in my opinion- Secret Chat feature should be available in webogram. The E2E encryption is a key feature in Telegram. Any update?

[JaredPotter]

A friend of mine convinced me to switch from WhatsApp to Telegram but as soon as I found out that the web/desktop clients do not support secret chats, I went right back to WhatsApp. Plus Telegram does not have voice calling support with no intention to add it.