LOL
- status and visibility could be controlled for each contact at a granular level
- locally-stored, fully searchable chat history that gave results in a sensible manner and which you could migrate to new computers
- notification intrusiveness (ding, flash, etc) could be adjusted with one or two clicks
- dense UI (less whitespace meant more information packed into a smaller window that took up less of my screen)
- hitting X actually exited the program
Yesterday's thread about DECUS and HP's OpenVMS hobbyist program opened a can of nostalgia worms so I remembered that my first laptop was a late-Digital era 11"-screen laptop with a pretty low-res screen (800x600, I think?).
I used ICQ on it and its interface was about as awkward as Skype's is today -- except today I'm running Skype on a laptop with about twice the screen estate. It's a little silly that all that research work in the industry -- and all that money I've paid -- went into screens that I now use just to display more whitespace.
I know it's supposed to help with touch screens but a) my laptop -- like most laptops currently in use -- doesn't have one and b) this isn't 1997 anymore, UI toolkits today make it trivial to adjust element sizes and paddings so that they're appropriate to whatever pointing device is currently in use.
That being said, the window in that screenshot is about 200 x 320 px. It would have taken about a third of the horizontal space of the screen, and about 2/3rds of the vertical space of a 640x480 screen. It was certainly usable -- way, way more usable than Skype on a full HD monitor today -- but lots of stuff was claustrophobic in 640x480.
(Then again, most modern apps are practically unusable if you resize their window to 640x480...)
Yes to Slack! Ask whoever manages your organization to enable XMPP or IRC gateway connection, then add the appropriate type of account to Trillian. You won't have access to rich cards or shared files from within Trillian, but you will be able to read and send messages to channels and individuals.
How is that good UX for a chat app?
Though it looks like exact copy of Telegram minus the core and most important feature. :D
* https://telegram.org/faq#q-how-secure-is-telegram
* https://telegra.ph/Why-Isnt-Telegram-End-to-End-Encrypted-by...
* https://telegra.ph/Why-you-should-stop-reading-Gizmodo-right...
This debate has taken place over and over again on HN, there's nothing new here.
Surely, that doesn't mean that expert were wrong, but at least mentioning that in Telegram vs WhatsApp debate doesn't look like a strong point.
And like heinrich5991 said, there's no need for backdoor or vulnerability when the data leaks by design to the server.
And no secret chats aren't an option. E2EE needs to be cross-platform and enabled by default. Signal can do it, Wire can do it. Telegram can't, because the developers are completely incompetent.
For a good UX impl, check out Keybase. It's encrypted chat feels just as good as Telegram's unencrypted chat.
"GPG isn't that hard! You see, you just..."
I still remember my 7 digit invisible vanity number.
Its just propaganda move to ban Telegram to make it look independent
(not the E2E ones)
Also, people don't really want to use secret chats because they aren't cross platform. Sure, some people only own phones, but those that switch to laptop/desktop computer don't want to whip out phone hundreds of times a day, but opt-in for the insecure cloud chats that are accessible with simple alt+tab.
So yeah. Sure, secret chats can be mostly secure, the problem is the E2EE isn't practical to any reasonable extent and again, using it leaks metadata.
E2E encryption is _practically required_ if you want to build an app that doesn’t get bad press from security professionals. Just look at Zoom.
Want a fast server-side archive search? Forget it, you're using e2ee.
Want to add a new device and load all your chat history? Forget it, you're using e2ee.
Now, by downloading and decrypting it on another device, you are adding a THIRD end where is is accessible. To achieve that, you have basically two options: one is to pass over decryption keys to a new device (potentially breaking E2EE security model for another guy who does not expect you to use 2 devices without his explicit authorization), and another approach is to do an own encrypted archive to store data and sync between your devices. You basically encrypt data and store it on a server, decrypting it with your password or certificate or something that you share between devices. It's not E2EE at all, actually, cause you'll be breaking the security model for some convenience, because the idea of e2ee is to communicate only with devices, each and every one of which were authorized by you. If you don't follow this rule, you make a travesty out of E2EE, basically stating that all you really need is a nice and cozy feeling of being secure, not true security.
You have to face it: true E2EE is not achievable without significant sacrifices of user experience.
You're not thinking straight. End-to-end encryption does not refer to two devices, it refers to two parties. If you have two devices that can receive the message, that's still only accessible to you.
>one is to pass over decryption keys to a new device (potentially breaking E2EE security model
That's just stupid, you can scan e.g. public key of the other device and then have your device send packets to that
>and another approach is to do an own encrypted archive to store data and sync between your devices.
Which is perfectly valid provided the user has to create sufficiently secure password.
> It's not E2EE at all
The reasoning how you came to claim this is beyond moronic.
>actually, cause you'll be breaking the security model for some convenience
You aren't breaking anything. Claiming things without reason is moronic.
>because the idea of e2ee is to communicate only with devices
No the idea is only you and your peer have access to the data. You can't be serious.
>each and every one of which were authorized by you
Yeah that is kind of what happens with proper E2EE, only you have access to your data on devices you've authorized by e.g. scanning the QR code of the trusted instance.
> basically stating that all you really need is a nice and cozy feeling of being secure, not true security.
Geez, maybe start by learning how cryptographic protocols work before making such claims.
>You have to face it: true E2EE is not achievable without significant sacrifices of user experience.
Majority of them are with smart cryptographic design. The claims you made were more hand waving than I've ever seen before. Incredible.
ICQ New: has entered the chat
Good opportunity for Apple to step in and open up the message/facetime platform imo.
People can't threat model because they don't really know what the governments consider interesting and a threat to their exercise of power.
So always use E2EE.
I'm one of those people that refuses to accept that "privacy is dead"; but there's also a lot of casual/low-stakes communication that I treat like a personal conversation in an IRL public setting, operating on the assumption that a stranger can/will overhear it.
>I'm one of those people that refuses to accept that "privacy is dead
I never claimed it was. I was making the point that you should protect everything so you don't leak metadata about when you're having private conversation. That's exactly what happens when you e.g. enable secret chats in Telegram. You're telling the company "I'm now talking to Bob, and I'm intentionally making the decision to not share that data with YOU". That's really, really valuable metadata to governments.