New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

OMEMO Tracking #36

Open
mar-v-in opened this Issue Apr 11, 2017 · 19 comments

Comments

Projects
None yet
7 participants
@mar-v-in
Contributor

mar-v-in commented Apr 11, 2017

This is a feature tracking issue for the OMEMO plug-in. Please report bugs as seperate issues.

  • Encrypt/decrypt messages
    • Single user chat
    • Multi user chat (GSoC)
  • Display own fingerprint as text in account settings
  • Extended account OMEMO UI
    • Display own fingerprint as text
    • Copy own fingerprint to clipboard
    • Display own fingerprint as QR code (GSoC)
    • Display other devices' keys
    • Un-/trust other devices (GSoC)
    • Remove devices from own devicelist
  • Contact OMEMO UI
    • Display devices' fingerprints as text
    • Un-/trust devices (GSoC)
  • Colorize displayed fingerprints to allow easy comparison
  • OMEMO Encrypted Jingle File Transfer (depends on Jingle File Transfers, current ProtoXEP)
  • OMEMO Encrypted HTTP File Uploads (ProtoXEP missing)
  • Option to disable Blind Trust (GSoC)
  • Notify on new own devices (GSoC)
  • OMEMO v2
@ghost

This comment has been minimized.

Show comment
Hide comment
@ghost

ghost Apr 17, 2017

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

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

ghost commented Apr 17, 2017

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

This comment has been minimized.

Show comment
Hide comment
@mar-v-in

mar-v-in Apr 17, 2017

Contributor

@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)

Contributor

mar-v-in commented Apr 17, 2017

@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)

@ghost

This comment has been minimized.

Show comment
Hide comment
@ghost

ghost Apr 17, 2017

Oh, Ok. I expected coloring like Gajim does:
image
The colorizing you have in mind works fine of course.

ghost commented Apr 17, 2017

Oh, Ok. I expected coloring like Gajim does:
image
The colorizing you have in mind works fine of course.

@NicoHood

This comment has been minimized.

Show comment
Hide comment
@NicoHood

NicoHood May 7, 2017

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 commented May 7, 2017

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

This comment has been minimized.

Show comment
Hide comment
@NicoHood

NicoHood May 7, 2017

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 :(

NicoHood commented May 7, 2017

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

This comment has been minimized.

Show comment
Hide comment
@mar-v-in

mar-v-in May 7, 2017

Contributor

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.

Contributor

mar-v-in commented May 7, 2017

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

This comment has been minimized.

Show comment
Hide comment
@NicoHood

NicoHood May 7, 2017

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 commented May 7, 2017

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.

This was referenced May 8, 2017

@NicoHood

This comment has been minimized.

Show comment
Hide comment
@NicoHood

NicoHood May 9, 2017

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!

NicoHood commented May 9, 2017

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!

@rugk

This comment has been minimized.

Show comment
Hide comment
@rugk

rugk May 31, 2017

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 commented May 31, 2017

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.

@tdemin

This comment has been minimized.

Show comment
Hide comment
@tdemin

tdemin Nov 4, 2017

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

tdemin commented Nov 4, 2017

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

@rugk

This comment has been minimized.

Show comment
Hide comment
@rugk

rugk Nov 4, 2017

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 commented Nov 4, 2017

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

This comment has been minimized.

Show comment
Hide comment
@tdemin

tdemin Nov 4, 2017

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

tdemin commented Nov 4, 2017

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

@rugk

This comment has been minimized.

Show comment
Hide comment
@rugk

rugk Nov 4, 2017

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.

rugk commented Nov 4, 2017

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

This comment has been minimized.

Show comment
Hide comment
@tdemin

tdemin Nov 4, 2017

@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.

tdemin commented Nov 4, 2017

@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

This comment has been minimized.

Show comment
Hide comment
@rugk

rugk Nov 4, 2017

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.

rugk commented Nov 4, 2017

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.

@tdemin

This comment has been minimized.

Show comment
Hide comment
@tdemin

tdemin Nov 4, 2017

@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.

tdemin commented Nov 4, 2017

@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.

@rugk

This comment has been minimized.

Show comment
Hide comment
@rugk

rugk Nov 4, 2017

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 commented Nov 4, 2017

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?" 😉

@wilhelmy

This comment has been minimized.

Show comment
Hide comment
@wilhelmy

wilhelmy Jun 29, 2018

Petition to tackle MUC encryption next? :)

wilhelmy commented Jun 29, 2018

Petition to tackle MUC encryption next? :)

@BadPractice

This comment has been minimized.

Show comment
Hide comment
@BadPractice

BadPractice Jul 17, 2018

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

BadPractice commented Jul 17, 2018

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment