OMEMO Tracking #36
Comments
|
Only colorizing fingerprints can be problematic, better have more contrast than just color, maybe
|
|
@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: |
|
I guess image/file sharing is not implemented yet? I got an URL like this: |
|
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 :( |
|
If you receive links with |
|
So this means I should open an issue at conversation bugtracker? |
|
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! |
|
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. |
|
@rugk how do you scan a QR code on a desktop computer? |
|
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. |
|
@rugk all the messy ways to compare the codes instead of simply looking at them and tapping "Verified"? No way! |
|
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. |
WHAT?
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. |
Because of the usability aspect involved. You usually only scan
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. |
Don't mess things up. You say "security" and then speak of usability.
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. |
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. 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?" 😉 |
ghost
mentioned this issue
|
Petition to tackle MUC encryption next? :) |
|
Would you kindly focus down Un-/trust devices. This is the only think preventing me from using dino :( |
|
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 |
|
Is there a bounty for this issue? |
|
|
Ok... added more 50$ :) I'd love to be able to see encrypted images... 🐈 |
|
@mar-v-in What is OMEMO v2? Searching the web I can only find rather vague references from a few years ago. |
|
@mar-v-in List can be updated or? |
|
Encrypted File up/download seems to be supported now: |
|
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'). |
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) |
|
@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. |
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. |
Someone is working on that? |
|
Good news: |
This is a feature tracking issue for the OMEMO plug-in. Please report bugs as seperate issues.
The text was updated successfully, but these errors were encountered: