6 ms·

I'm not sure if that's such an unsolvable problem. For example, Firefox Send [1] also provides E2E encryption, but that's practically transparent to the user. T

by Vinnl 7y ago

I'm not sure if that's such an unsolvable problem. For example, Firefox Send [1] also provides E2E encryption, but that's practically transparent to the user. The key is added as a hash to the URL, which the browser never sends to the server. The user just has to copy the sharing URL (which they do anyway) do obtain and share the key. Jitsi might have an additional challenge in that their URLs are often human-readable and user-picked, so not everybody might be used to copy-pasting the links, but then they have the advantage of encryption probably being optional. Or they might think of a whole other solution that provides good UX that doesn't require users to manage keys. (Which, again, might be optional anyway.) [1] https://send.firefox.com/ https://send.firefox.com/

shadowgovt 7y ago
Yeah, it shouldn't be unsolvable; my key thought is that it's actually the hard part of the story now (encryption client-side is pretty well-understood) and is under-solved. Even still, having more options in the world is better than having fewer, so I'm excited about this demo.
- Vinnl 7y ago
  I disagreed with "you can't solve the UX", but I definitely agree that it's a hard problem. Looking forward to seeing what they come up with.
  - shadowgovt 7y ago
    I think my choice of words left me open to misinterpretation: the "you... and...." phrasing was meant as synonymous with "If you... then...", not as a categorical claim that I believe the UX is unsolvable.
    - Vinnl 7y ago
      Ah, I see now! Definitely agree; if it hampers UX, users will switch.
hiq 7y ago
In this case you still trust Mozilla and the JS code they serve to your browser every time you visit this URL (in contrast to e.g. mobile apps), so I don't think it solves much: you still trust a third-party. Of course it's still better than the default, since your data sent at time t_A won't be compromised by an attacker compromising Mozilla's servers at time t_B with t_A < t_B (well, you try to retrieve your data and they steal your passphrase by serving some new JS code).
- Vinnl 7y ago
  Sure, but that's a different problem than the one about UX for E2E encryption, no?
  - hiq 7y ago
    The post you answered to said: > As service provider, you could keep their keys, but if they trust you with their keys, why aren't they trusting you with being MITM on encryption? Especially since if you have their keys you already could. I understood that you meant that Firefox Send solves this problem and does not handle users' keys. My point was that the trust model is still the same, so you might as well just stick to the current model where you already trust Jitsi. Firefox Send solves the UX problem because it doesn't completely address the encryption key handling problem. To be fair, I still think Firefox Send is slightly better than traditional file hosting, just not significantly.
    - Vinnl 7y ago
      Yeah I guess you're right, in the sense that it's still a web application. Still, I don't think the general approach is limited to that. For example, Jitsi also has an Electron app. I haven't tried that, but I presume that would work in a similar way to e.g. Zoom, i.e. you paste an invitation link in there. That could just include the key, without it being sent to the server, and without it being a significant extra hurdle to the user. Note that I'm not saying that that's necessarily the best solution; just that I don't believe that > You can't solve the UX on that is true, i.e. that there's nothing particularly inherent to the problem that results in there being exactly 0 good solutions to it.

by Vinnl 7y ago

shadowgovt 7y ago

Yeah, it shouldn't be unsolvable; my key thought is that it's actually the hard part of the story now (encryption client-side is pretty well-understood) and is under-solved. Even still, having more options in the world is better than having fewer, so I'm excited about this demo.

Vinnl 7y ago
I disagreed with "you can't solve the UX", but I definitely agree that it's a hard problem. Looking forward to seeing what they come up with.
- shadowgovt 7y ago
  I think my choice of words left me open to misinterpretation: the "you... and...." phrasing was meant as synonymous with "If you... then...", not as a categorical claim that I believe the UX is unsolvable.
  - Vinnl 7y ago
    Ah, I see now! Definitely agree; if it hampers UX, users will switch.

hiq 7y ago

In this case you still trust Mozilla and the JS code they serve to your browser every time you visit this URL (in contrast to e.g. mobile apps), so I don't think it solves much: you still trust a third-party. Of course it's still better than the default, since your data sent at time t_A won't be compromised by an attacker compromising Mozilla's servers at time t_B with t_A < t_B (well, you try to retrieve your data and they steal your passphrase by serving some new JS code).

Vinnl 7y ago
Sure, but that's a different problem than the one about UX for E2E encryption, no?
- hiq 7y ago
  The post you answered to said: > As service provider, you could keep their keys, but if they trust you with their keys, why aren't they trusting you with being MITM on encryption? Especially since if you have their keys you already could. I understood that you meant that Firefox Send solves this problem and does not handle users' keys. My point was that the trust model is still the same, so you might as well just stick to the current model where you already trust Jitsi. Firefox Send solves the UX problem because it doesn't completely address the encryption key handling problem. To be fair, I still think Firefox Send is slightly better than traditional file hosting, just not significantly.
  - Vinnl 7y ago
    Yeah I guess you're right, in the sense that it's still a web application. Still, I don't think the general approach is limited to that. For example, Jitsi also has an Electron app. I haven't tried that, but I presume that would work in a similar way to e.g. Zoom, i.e. you paste an invitation link in there. That could just include the key, without it being sent to the server, and without it being a significant extra hurdle to the user. Note that I'm not saying that that's necessarily the best solution; just that I don't believe that > You can't solve the UX on that is true, i.e. that there's nothing particularly inherent to the problem that results in there being exactly 0 good solutions to it.