Webogram: 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 [email protected] 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.

[FacundoAcevedo]

I do no think that using WhatsApp is better than using Telegram, even if the say that all is encrypted. Because it's privative and closed source. Btw for calling you can use Ring.

In my opinion Telegram used encryption as marketing to get users, right now they have a lot of users, so it's not a priority. We are getting stickers, and other cool features that make us happy but not secure.

[purplesrl]

@FacundoAcevedo

the problem is not with Telegram itself, but with the developer of telegram desktop, he is against this feature for some reason, many people have tried to persuade him to implement it, he said it is low priority.

@JaredPotter

you can use telegram-cli for this, or cutegram

[stek29]

he is against this feature

Wat? Any proof?
Secret chats would be extremely hard to implement, and they're not top priority because IMO telegram tries to satisfy housewives more than geeks like you.

[purplesrl]

@stek29

you can search for yourself for the issues that were opened and can see his replies, arguing it is not an important feature or a priority

about the housewives, well telegram was intended to be different, i guess they realized there are more housewives than geeks

also, secret chats are already present in telegram-cli, cutegram, so maybe hard but not impossible to implement

a final argument would be that the client is incomplete without that feature, its a core feature of the protocol, it is not like OTR, some fancy plugin for geeks as you say

[purplesrl]

@zhukov

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

I am sorry but I do not understand this logic. Isn't this the whole purpose of the secret chat? For messages to be deleted after they are viewed by the other side?

[stek29]

@paulmillr

its a core feature of the protocol

No, it's just an addition to it, a second part. See https://core.telegram.org/api/end-to-end.

some fancy plugin for geeks as you say

I don't think that security is "some fancy plugin for geeks". But it looks like telegram thinks so.

you can search for yourself for the issues that were opened and can see his replies, arguing it is not an important feature or a priority

Which does not mean that Dev is against that feature.

[stek29]

@paulmillr Zhukov says that messages are deleted from server when client gets them.
So there is no way to retrieve message history from server.
App has to store whole history locally.

Here you can see:

All messages acknowledged as delivered by the client, as well as any messages older than 7 days, may (and will) be deleted from the server.

[purplesrl]

@stek29
the whole point of secret chats is to keep NO HISTORY

[stek29]

@purplesrl The whole point of secret chats is end to end encryption.
Deleting the messages isn't crucial part. I personally NEVER EVER delete messages, especially files.

[purplesrl]

@stek29

it seems you have opinions about everything, you seem to know also exactly what the developers had in mind when they designed Telegram, secret chats, and what decisions they took and why, so no use continuing this.

Cheers :)

[elKaZe]

The most interesting thing of Telegram, I though, is that gives cryptography to the masses. But if it's not a priority, nor a goal, I will give a chance to LibreSignal

PD: Libresignal is dead :P, XMPP?

[Ryuno-Ki]

@elKaZe Keep an eye on OMEMO.

[diazbastian]

@elKaZe and @Ryuno-Ki is relevant to mention other protocols in this thread? Please focus in this problem.

[stek29]

@purplesrl actually you were the first who started claiming that he knows "whole point of secret chats" without any proofs. (So you shared your opinion and called it Telegram's opinion).

@elKaZe @Ryuno-Ki what about Tox?

[purplesrl]

@stek29

Probably you misunderstood my comments, is English your first language?

[stek29]

@purplesrl No 🙃

[TJC]

Perhaps I can offer another way to resolve the argument?

_Aim for feature parity with the mobile client_

Since the mobile client supports encryption, timed-delete messages, etc, then the desktop client must too.

The desktop apps for Signal and WhatsApp manage it, so if there's some technical hurdle, perhaps you can look at the code for Signal and see how they do it?

[chrismc]

Is there any objection to using localstorage to resolve the history issue? I'd like to take a crack at this. It looks like it was shot down earlier for not being supported by firefox, but it seems like they've added it since.. @zhukov

[Ryuno-Ki]

Keep in mind, that localStorage has some size restrictions

[chrismc]

Whoops, sorry, I've been out of town. I may have actually been thinking of
IndexedDB, which also has a storage cap, but modern browsers will happily
remove it with the user's permission. The browser itself would display a
correctly localized dialog once the cap is reached. It's designed for
larger datasets like the kind I think you'd expect to see in webogram.
Thoughts?

On Sat, Feb 25, 2017 at 2:59 PM, André Jaenisch [e-mail]
wrote:

Keep in mind, that localStorage has some size restrictions

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/zhukov/webogram/issues/126#issuecomment-282512007,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AFudoeJvlaob3vqT3tlOKSCV7n31mEzUks5rgJZBgaJpZM4BnJuJ
.

[aurium]

It's designed for larger datasets like the kind I think you'd expect to see in webogram. Thoughts?

As the client is where secret chats are stored, i believe you are right. It also may allow to search in chat history without load all chat in memory.

[cr7pt0]

It would be great to have this feature. So one benefit of using localstorage is for the Chrome and Firefox extension you should be able to have the data sync between multiple browsers. Here are the details for Chrome - https://developer.chrome.com/extensions/storage and for Firefox - https://developer.mozilla.org/en-US/Add-ons/WebExtensions/API/storage/sync
I really hope this feature is given a high priority its definitely possible and would be be a great addition.