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

make omemo default when available #1350

Closed
pravi opened this Issue Aug 23, 2015 · 25 comments

Comments

Projects
None yet
8 participants
@pravi
Copy link

pravi commented Aug 23, 2015

I think encryption should be the default option when the contact has it available. An option in settings could be provided to change it to plain text. With surveillance so pervasive encryption should be default for privacy.

@andersruneson

This comment has been minimized.

Copy link
Contributor

andersruneson commented Aug 23, 2015

This won't work for us since we always use multiclient and the other
clients don't support OMEMO. Also e2e-encrypted is not at all that needed
for our use case with private server.
On 23 Aug 2015 17:44, "Praveen Arimbrathodiyil" notifications@github.com
wrote:

I think encryption should be the default option when the contact has it
available. An option in settings could be provided to change it to plain
text. With surveillance so pervasive encryption should be default for
privacy.


Reply to this email directly or view it on GitHub
#1350.

@pravi

This comment has been minimized.

Copy link

pravi commented Aug 23, 2015

@andersruneson, it will be default only when omemo is available. So in your case, it will remain the way it is right now.

@andersruneson

This comment has been minimized.

Copy link
Contributor

andersruneson commented Aug 23, 2015

How's that logic suppose to work? OMEMO will "work" between two
Conversations but carbons and mam to other clients that don't support OMEMO
won't.
When is OMEMO suppose to be default?
On 23 Aug 2015 18:37, "Praveen Arimbrathodiyil" notifications@github.com
wrote:

@andersruneson https://github.com/andersruneson, it will be default
only when omemo is available. So in your case, it will remain the way it is
right now.


Reply to this email directly or view it on GitHub
#1350 (comment)
.

@pravi

This comment has been minimized.

Copy link

pravi commented Aug 23, 2015

You could select plain text from the drop down in that case to turn off omemo. It is just changing the default from plain text to omemo.

@h-2

This comment has been minimized.

Copy link

h-2 commented Sep 7, 2015

I think @pravi means that it should be on by default if all clients by all participating parties are known to support it. I agree.

@andersruneson

This comment has been minimized.

Copy link
Contributor

andersruneson commented Sep 7, 2015

Which clients are participating? One who is offline and wants to read the
log with mam when it comes back?
On 7 Sep 2015 12:29, "Hannes Hauswedell" notifications@github.com wrote:

I think @pravi https://github.com/pravi means that it should be on by
default if all clients by all participating parties are known to support
it. I agree.


Reply to this email directly or view it on GitHub
#1350 (comment)
.

@h-2

This comment has been minimized.

Copy link

h-2 commented Sep 7, 2015

Which clients are participating?

All clients that bob used within the last month and all clients that alice used in the last month, or whichever arbitrary timeframe you define. The point is that it should be encrypted by default if possible.

edit: you could just say "if the peer's client supports omemo, and an omemo-non-supporting client has not be seen for that user in the last 30 days, turn on omemo by default for that conversation".

@strb

This comment has been minimized.

Copy link
Contributor

strb commented Sep 7, 2015

Well the point is you can't know whether all clients by all participants support OMEMO. All you can check is how many clients that support OMEMO your client has. You don't even know if those are online right now.

@pravi

This comment has been minimized.

Copy link

pravi commented Sep 7, 2015

May be each account can announce their encryption preference like key announce keys. If I say always encrypt to me, all clients with encryption support should encrypt with me.

@strb

This comment has been minimized.

Copy link
Contributor

strb commented Sep 7, 2015

It's not entirely clear to me how this would/could work in detail. Should this be OMEMO-specific or for any e2e encryption method? What if two different devices want to announce different preferences? You can't really resolve conflicts in a meaningful way here. You can't go with "use the preference of the client that's online", because then you're back at square one. So do they overwrite one another? If so, how do you handle this? If somebody else overwrites your preference, should you re-overwrite them, so as to prevent malicious tampering? Then you have infinite loops with people overwriting one another. And if you don't, then the setting becomes kinda useless.

As you can see it's not really that simple. No approach to automating this will work for everyone. We will not introduce complexity and automation which doesn't actually improve the situation. While this might work for your use case, there are just as many people for whom this won't work at all. And what's more, such automatic setting of preferences is only going to confuse a lot of users.

It's a lot easier to just switch OMEMO on once. What's wrong with that? It's not like you'll ever have to turn it off if you don't want to. Adding a lot of additional complexity for such arguably marginal benefit is not really a good idea IMO.

@h-2

This comment has been minimized.

Copy link

h-2 commented Sep 8, 2015

I would propose:

  • omemo specific
  • once a contact has one identified omemo device, they are marked as "auto-omemo"
  • once a non-omemo device is detected for a contact marked as "auto-omemo" the user is asked "Conversation has automatically activated Omemo encryption for Bob, but Bob seems to have devices without Omemo in use. Do you want Omemo to still be default? Yes / No"
  • if the user clicks Yes they won't be asked again about it.

-> secure by default, minimal impact on usability

@strb

This comment has been minimized.

Copy link
Contributor

strb commented Sep 8, 2015

First of all, you'd need to define how you would "detect a non-OMEMO device". You can't query resources on whether they support OMEMO or not. The only way I can come up with of even approximating such a detection would be counting how many devices are announced for a particular user versus the maximum number of resources you've seen online at the same time at some point, which is a pretty terrible metric. It will also fail if someone has old, disused devices that weren't cleared from PEP. I guess you could "solve" this by only considering announced devices that have sent a message in the last X days or something, but that's a bad workaround to fix an already terrible approach. Not to mention the ridiculous amount of complexity this introduces for what I still maintain to be pretty marginal benefit.

Presenting users with confusing pop-ups is not really what I would consider "minimal impact on usability" either. Basically, in order to understand the implications of this pop-up, the user would have to already have an understanding for what the client ecosystem in this conversation looks like (i.e. what other clients do I/my contact have and do they support OMEMO?). Remember that OMEMO has only been released around 2 weeks ago. Most people don't even know what it is yet. I'm all for secure-by-default, but this is just not the way for now. It will only confuse users.

This is something we may want to -- and will -- reconsider when OMEMO is more established. More clients need to support it first, and we really want to be sure our implementation is solid, before we implicitly force it on our users. If we do this right now, we lock our users in to only talk to other Conversations users. The opposite of what XMPP is all about.

@h-2

This comment has been minimized.

Copy link

h-2 commented Sep 8, 2015

You can't query resources on whether they support OMEMO or not.

Ah, I was confused about this, because in another thread you said:

OMEMO will discover whether your contact supports it. If they don't it will not be selectable.

So I thought it is possible to detect whether your contact has omemo support or not.

[...] Not to mention the ridiculous amount of complexity this introduces [...]

Hm, I don't know. To me it seems like using a ton of different clients is a border case, and most people use 1-2 devices and 1-2 client softwares at most. But, maybe I am mistaken.

Presenting users with confusing pop-ups is not really what I would consider "minimal impact on usability" either.

Well I based this claim on the assumption that only few users see this, and not very often.

This is something we may want to -- and will -- reconsider when OMEMO is more established. More clients need to support it first, and we really want to be sure our implementation is solid, before we implicitly force it on our users. If we do this right now, we lock our users in to only talk to other Conversations users. The opposite of what XMPP is all about.

I understand these points and if you will reevaluate this at some point in the future than thats already a good enough answer for me :)
I was just nagging you to keep in mind that anything not default just isn't used by the masses(tm) which would be a shame considering the amount of work you guys are putting into it.

@knoy

This comment has been minimized.

Copy link

knoy commented Oct 21, 2016

I think this needs to be revisited. A lot of the points brought up by @strb such as recent release are no longer valid. Conversations is supposed to be secure by default in its design. In most cases users only have 1 or 2 devices maximum.

@ChristianTacke

This comment has been minimized.

Copy link

ChristianTacke commented Oct 24, 2016

Please consider the other use case as well: People having a private server, using Carbons and/or MAM, but using clients that don't support OMEMO. Having a "I sent you an OMEMO encrypted message but your client doesn’t seem to support that. Find more information on https://conversations.im/omemo" on your other devices is very unhelpful.

I curenntly consider filing a wishlist issue "Please allow me to not announce OMEMO support".

@h-2

This comment has been minimized.

Copy link

h-2 commented Oct 25, 2016

Please consider the other use case as well: People having a private server

I agree there might be cases where you wouldn't want this, but how many users does this effect? If you run your own xmpp server you will be skilled enough to opt-out by visiting the settings or pressing some extra buttons. On the other hand opt-in encryption is an absolute show-stopper for installing this on the phone of non-nerds.

@ChristianTacke

This comment has been minimized.

Copy link

ChristianTacke commented Oct 28, 2016

[…] you will be skilled enough to opt-out by visiting the settings or pressing some extra buttons.

That's what I am asking for: A setting to disable OMEMO, so that my client doesn't even announce support for OMEMO.

@h-2

This comment has been minimized.

Copy link

h-2 commented Oct 29, 2016

Maybe we could have a field in the options

Security Behaviour (OMEMO)

  • Require
  • Opt-Out
  • Opt-In
  • Deactivate

Currently the default is Opt-In. I would recommend moving the default up to Opt-Out. You could still set it to Deactivate.

@h-2

This comment has been minimized.

Copy link

h-2 commented Oct 29, 2016

Actually, I thought about it and it might make more sense to have

Encryption Mechanisms (multiple selectable)

  • Unencrypted
  • OpenPGP
  • OTRv3
  • OMEMO

Default Encryption Mechanism (one selectable out of the selected above)

  • Unencrypted
  • OpenPGP
  • OTRv3
  • OMEMO

This way you can (de)select the protocols you don't want. You could select only plain-text or only OMEMO. And you can choose what the default should be. It is also easier to understand than "opt-in" "opt-out"...
I would then recommend to turn OMEMO on by default and maybe start making OTR unavalable at version 2 of Conversations (with the possibility that people turn it on in the options again).

@iNPUTmice

This comment has been minimized.

Copy link
Member

iNPUTmice commented Oct 29, 2016

I'm closing here. This discussion is leading nowhere.
I don't think we need a setting to pick the default setting for another setting. That's ridiculous. How many new contacts does the average user add every day? 1? 0.5? 0.1? I don't buy into the assumption that it is too much trouble to pick the encryption setting once for every new contact. You only have to do that once and it will remain that way for ever.
Making OMEMO default just doesn't fit every ones use case. There are hundreds of users who use Conversations on their own private server. There is no reason your mum who is on the same private server should ever be bothered with end-to-end encryption. Same goes for the company wide network. There is no reason to use e2ee.

To quote from the Conversations Mission statement:

Conversations will not force its security and privacy aspects upon the user.

Those crypto selections you mention @h-2 can be made at compile time. This will also give you @ChristianTacke the ability to not even announce OMEMO if you don't want to.

Forcing e2ee end especially OMEMO isn't for everyone. Some people might prefer PGP, some people might prefer not to encrypt at all. Conversations is trying to be a messenger with multiple use cases and not just a messenger for privacy advocates.

@iNPUTmice iNPUTmice closed this Oct 29, 2016

@jkufner

This comment has been minimized.

Copy link

jkufner commented Oct 29, 2016

One critical regression which would come with E2E encryption enabled by default: It breaks MAM.

Encrypted messages are not stored on server, so server-side history stops working, which makes use of multiple clients much harder as they don't sync chat history anymore. Therefore, E2E encryption MUST be opt-in.

... and as @iNPUTmice already wrote, private/trusted server is good enough for most use cases.

And honestly, when I install Conversations to someone technically unskilled (the mum use-case), I would like to disable the whole E2E encryption feature completely, so the lock button would disappear from UI and encryption support would not be announced to other clients, so the encryption cannot be turned on accidentally.

@ChristianTacke

This comment has been minimized.

Copy link

ChristianTacke commented Oct 29, 2016

And honestly, when I install Conversations to someone technically unskilled (the mum use-case), I would like to disable the whole E2E encryption feature completely, so the lock button would disappear from UI and encryption support would not be announced to other clients, so the encryption cannot be turned on accidentally.

That's exactly my use case. I have to ask my contacts to disable OMEMO again, if they enabled it my accident. I even stopped my Conversations for a while to not have OMEMO-data on the server, so that people couldn't use OMEMO towards me.

Not to mention, that I have to explain to people, that "unencrypted" isn't really unencrypted, but TLS-encrypted towards the server.

@iNPUTmice

This comment has been minimized.

Copy link
Member

iNPUTmice commented Oct 29, 2016

@ChristianTacke I respect your usecase (and I kinda regret the semi-auto enabling of OMEMO for that reason and I'm even kinda thinking about to revert that change but that's the opposite of what this issue is about). For the time being I suggest you compile Conversations yourself and disable OMEMO. It's really simple. Just change that line: https://github.com/siacs/Conversations/blob/master/src/main/java/eu/siacs/conversations/Config.java#L15

@ChristianTacke

This comment has been minimized.

Copy link

ChristianTacke commented Oct 31, 2016

@iNPUTmice

I respect your usecase

Thanks!

but that's the opposite of what this issue is about

Maybe the issue should be retitled to something "Reconsider encryption defaults, automation and options"?

@iNPUTmice

This comment has been minimized.

Copy link
Member

iNPUTmice commented Nov 13, 2016

It's no longer default. Detailed reasons in commit message: 035d0c7

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