Skip to content
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

Adapt existing setting to only send to verified devices for cross-signing #11808

Open
jryans opened this issue Jan 9, 2020 · 7 comments
Open
Labels
A-E2EE A-User-Settings O-Occasional Affects or can be seen by some users regularly or most users rarely S-Minor Impairs non-critical functionality or suitable workarounds exist T-Enhancement X-Needs-Design X-Needs-Product More input needed from the Product team

Comments

@jryans
Copy link
Collaborator

jryans commented Jan 9, 2020

We have the existing setting "Never send encrypted messages to unverified devices from this device" which should be adapted for cross-signing as below:

2020-01-14 at 12 18

Open questions:

  • What happens when send a message with this enabled? Are you prevented from sending entirely?

See also the related https://github.com/vector-im/riot-web/issues/11807.

@jryans
Copy link
Collaborator Author

jryans commented Jan 10, 2020

@nadonomy, please review the questions above with your product hat on.

@nadonomy
Copy link
Contributor

  • What happens when send a message with this enabled? Are you prevented from sending entirely?

Yep, this is a fairly advanced "I never ever want to encrypt a message for an untrusted device" setting for the more extreme security conscious use cases.

We'd likely want some feedback on the composer to explain why it's disabled, but this supporting this feature in general is definitely low priority compared to us getting everything else working, and I don't believe to be table stakes for e2e by default even.

@jryans
Copy link
Collaborator Author

jryans commented Jan 10, 2020

@nadonomy, okay that makes sense.

I suppose one thing to make clear is that for this issue, we already expose a very similar (if not identical in function but differing in label) setting for "Never send encrypted messages to unverified devices from this device", which remains in place unless we take some action. Is it okay to leave that alone for now, which is what would happen leaving this as low priority?

@jryans jryans added story:4 and removed story:3 labels Jan 10, 2020
@nadonomy
Copy link
Contributor

Yeah for sure. I'd advocate for us leaving existing settings as is for now while we're in the bulk of cross-signing etc— allocating some time to clean up settings as probably the last 'greenfield' e2e changes in the e2e-by-default dev cycle.

@dbkr
Copy link
Member

dbkr commented Jan 10, 2020

So to clarify message sending behaviour, it should be:

With this setting disabled:

  • Regardless of room shield colour: Send message to all devices in room

With it enabled:

  • Room has green or black shield: Send message to all devices in room
  • Room has red shield: disable composer

When we introduce this setting it should inherit the value of, and replace, the old, "Never send messages to untrusted sessions" setting.

@dbkr
Copy link
Member

dbkr commented Jan 10, 2020

agh, also we shouldn't forget that the old setting could be set at both the account and room level. Which of these settings are we planning on allowing the user to set per-room as well as per-account?

@florianjacob
Copy link

Had some troubles with the old setting and initial cross-signing:
#13656

@kittykat kittykat added X-Needs-Design T-Enhancement O-Occasional Affects or can be seen by some users regularly or most users rarely S-Minor Impairs non-critical functionality or suitable workarounds exist and removed X-Needs-Community-Testing labels Dec 21, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-E2EE A-User-Settings O-Occasional Affects or can be seen by some users regularly or most users rarely S-Minor Impairs non-critical functionality or suitable workarounds exist T-Enhancement X-Needs-Design X-Needs-Product More input needed from the Product team
Projects
None yet
Development

No branches or pull requests

6 participants