OMEMO Tracking about dino

[wilhelmy]

Petition to tackle MUC encryption next? :)

[rugk]

You say "security" and then speak of usability.

Exactly. Because both are very closely connected, nowadays.

And yes, you cannot prevent anybody from doing something insecure. That's not my point. My point is, you have to prevent users from doing insecure things, because they are just users… Users will click through SSL warnings e.g. That's why they are not dismiss-able in modern browsers, depending on the circumstances.
In many e2e encrypted messengers, users sometimes send the verification code (or however it is called) through the same channel as they want to verify.

With the UI you should discourage that behavior. Make clear it is optional and so on… Or e.g. provide a mechanism, which usually can only be used when the contacts meet in person (that's why I've mentioned QR codes). And yes, if they want, they can screenshot the QR code, send it to the contact, the contact can print them and scan them; but hey… that's the case of shooting in the foot. As a dev you have done everything you can do.

But I think there is not much need to discuss this further. I trust the Dino devs that they do UI+security design etc. correctly. This tickets is about OMEMO, after all, not about "How to design secure systems, which are usable?" 😉

[rugk]

IMHO you should use this trust model by default as it is also used by Conversations. First "blind trust" and when they are verified (preferably via QR-code scanning), then disable "blind trust" and always show notifications. This is a reasonable trade-off of usability and security IMHO.

[devurandom]

@mar-v-in What is OMEMO v2? Searching the web I can only find rather vague references from a few years ago.

[tdemin]

@rugk,

Because of the usability aspect involved. You usually only scan

Don't mess things up. You say "security" and then speak of usability.

It can(!) just be dangerous for some users.

Yes! Life is dangerous too, let's save them from living at all!

If the user wants to shoot himself in the foot, there's nothing we can do. Such user will eventually shoot out his foot even if every safety system in the world protects him from doing this. And "safeguarding" all the users that way just hurts the ones who simply want to verify themselves with simply comparing codes.

[ainola]

It works well! But I'm getting the fallback message with every picture upload (for conversations, 'I sent you an OMEMO encrypted message but your client doesn’t seem to support that. Find more information on https://conversations.im/omemo').

[rfc-2549]

Remove devices from own devicelist

Someone is working on that?

Only colorizing fingerprints can be problematic, better have more contrast than just color, maybe

• font-weight
• size
• brightness
• background
• spacing
• indicator icon
• ...

[mar-v-in]

@mray The idea is to colorize in 4 hex character chunks, similar to OpenKeychain and group 2 chunks together (so that there are 8 groups of 8 characters, which is how OMEMO fingerprints are displayed in Conversations)

Oh, Ok. I expected coloring like Gajim does:

The colorizing you have in mind works fine of course.

[NicoHood]

I guess image/file sharing is not implemented yet? I got an URL like this: aesgcm://share.conversations.im/<user>/<a lot of numbers and chars>

[NicoHood]

Can't I receive pictures because its not implemented or because my server does not support it? I think its the first one. Because people send me picture all over and I need to tell them that I cannot decode them because of my client :(

[mar-v-in]

If you receive links with aesgcm://, this is the non-standard way of conversations to share omemo-encrypted files via http file upload. This is not implemented in Dino yet, neither is Jingle file transfer (which the other client shouldn't even try to use, because support is not announced by Dino). You are able to receive unencrypted or openpgp-encrypted http file uploads though.

[NicoHood]

So this means I should open an issue at conversation bugtracker?
Thanks for the information. I will try to send it encrypted then, even though its not the best idea.

[NicoHood]

I am willing to donate 50€ to the project if OMEMO gets implemented completely. I wont open any bugbounty program to avoid any additional fees, more for you guys. We will get in touch once its done :)

Keep up the great work!

[tdemin]

@rugk how do you scan a QR code on a desktop computer?

[rugk]

On Laptops with webcams that is no problem… But of course you may offer a way for users to manually enter the string for verification or so.

[tdemin]

@rugk all the messy ways to compare the codes instead of simply looking at them and tapping "Verified"? No way!

[rugk]

Well… QR code scanning is more secure and still convenient… with a webcam… well more or less. Typing manually is not so nice, I agree, but just letting users tap on things labeled "it's ok" is often dangerous. Many many users will not verify anything and just tap things away.

[tdemin]

@rugk,

QR code scanning is more secure

WHAT?

Many many users will not verify anything and just tap things away.

This only happens if verification is blocking the users from sending messages. The suggested model of trust, if you allow them to compare fingerprints by hand, doesn't bother the users (even doesn't suggest to do anything) and is still OK for the users who can't or don't want to scan codes.

[rugk]

WHAT?

Because of the usability aspect involved. You usually only scan

This only happens if verification is blocking the users from sending messages.

Maybe, maybe not. Some users would still verify anything they can – even if it is just to get a green tick…

But yes, I don't say this "click to verify" should not be implemented. It can(!) just be dangerous for some users. It could also be "hidden" and only available for users, who know what they do. That's all possible. It just depends on how it is done.

[BadPractice]

Would you kindly focus down Un-/trust devices. This is the only think preventing me from using dino :(

[stevenroose]

What is the status of encrypted images? gthumb seems to be the only app that can open it and it gives me segfaults on Arch Linux, so I can't open them at all.

Why are sub issues for each separate aspect not allowed?? #419

[albjeremias]

Is there a bounty for this issue?

[minils]

Is there a bounty for this issue?

https://www.bountysource.com/issues/44025760-omemo-tracking

[albjeremias]

Ok... added more 50$ :) I'd love to be able to see encrypted images... 🐈

[Echolon]

@mar-v-in List can be updated or?

[NicoHood]

Encrypted File up/download seems to be supported now:
#339 (comment)

[marmistrz]

• Option to disable Blind Trust (GSoC)

It shouldn't be marked as done. Currently, there seems to be no way of disabling blind trust globally (or at least it's not hooked to the UI)

[fiaxh]

@marmistrz The option is marked fine, as it doesn't say "globally". You can disable blind trust per-user: Go to the contact's details > OMEMO Key Management > Automatically accept new keys. #484 is an issue for globally disabling blind trust.

Given that Dino's OMEMO implementation is - besides some bugs - mostly done, I will close this tracking issue. Bugs and further features can be discussed in separate issues.

It seems to me OMEMO has broken. Was working perfectly not long ago. Then it just disappeared when I upgraded. I have compiled it with the OMEMO plugin.

[wilhelmy]

It seems to me OMEMO has broken. Was working perfectly not long ago. Then it just disappeared when I upgraded. I have compiled it with the OMEMO plugin.

I had the same issue when I was running dino from outside the build directory (I didn't make install). If I cd to the build directory, OMEMO is available.

[Neustradamus]

Good news:

• #265 (comment)