3 ms·

From the homepage: > Send and receive extensible messages with optional end-to-end encryption Why would encryption ever be "optional"?

by derf_ 12y ago

moheeb 12y ago
Back in the day it was often optional due to the additional processing that it required.
- derf_ 12y ago
  That was indeed a thing in the days before AES-NI or simply having 1.4 billion transistors on a chip. But in my day we've been spending years fighting this sort of short-sightedness: https://www.ietf.org/mail-archive/web/rtcweb/current/msg02747.html https://www.ietf.org/mail-archive/web/rtcweb/current/msg0274...
ara4n 12y ago
Because we don't want client implementers to be forced to have to jump through end-to-end crypto hoops if they don't want to. The simplest way to send a message in matrix is: curl -XPOST -d '{"msgtype":"m.text", "body":"hello world"}' "https://matrix.wherever.com/_matrix/client/api/v1/rooms/$roomid/send/m.room.message?access_token=$token" https://matrix.wherever.com/_matrix/client/api/v1/rooms/$roo... ...and we'd like to keep it that way. But you can always insist on only ever communicating with folks who are on E2E crypto clients if you so desire.
- derf_ 12y ago
  Is that the same way I can always insist on only ever receiving PGP-encrypted e-mail?
  - Arathorn 12y ago
    Not quite - as PGP is a pita to use, and not a formal part of the SMTP spec. So refusing to read non-PGP would be suicide. But if it was considered table stakes to implement the crypto option of the spec, and all the decent Matrix clients out there did so and sent end-to-end encrypted by default, then it'd naturally become the default. In other words, if you gracefully upgrade chats between capable clients to be end-to-end by default, everybody wins.
    - derf_ 12y ago
      If you really believe that, then I feel sorry for your users. Privacy is a public health issue: https://www.theguardian.com/technology/2013/may/21/privacy-public-health-surveillance https://www.theguardian.com/technology/2013/may/21/privacy-p... In the absence of some forcing function, the trend is for it to get worse, not better.

From the homepage: > Send and receive extensible messages with optional end-to-end encryption Why would encryption ever be "optional"?

by derf_ 12y ago

From the homepage: > Send and receive extensible messages with optional end-to-end encryption Why would encryption ever be "optional"?

moheeb 12y ago

Back in the day it was often optional due to the additional processing that it required.

derf_ 12y ago
That was indeed a thing in the days before AES-NI or simply having 1.4 billion transistors on a chip. But in my day we've been spending years fighting this sort of short-sightedness: https://www.ietf.org/mail-archive/web/rtcweb/current/msg02747.html https://www.ietf.org/mail-archive/web/rtcweb/current/msg0274...

ara4n 12y ago

Because we don't want client implementers to be forced to have to jump through end-to-end crypto hoops if they don't want to. The simplest way to send a message in matrix is: curl -XPOST -d '{"msgtype":"m.text", "body":"hello world"}' "https://matrix.wherever.com/_matrix/client/api/v1/rooms/$roomid/send/m.room.message?access_token=$token" https://matrix.wherever.com/_matrix/client/api/v1/rooms/$roo... ...and we'd like to keep it that way. But you can always insist on only ever communicating with folks who are on E2E crypto clients if you so desire.

derf_ 12y ago
Is that the same way I can always insist on only ever receiving PGP-encrypted e-mail?
- Arathorn 12y ago
  Not quite - as PGP is a pita to use, and not a formal part of the SMTP spec. So refusing to read non-PGP would be suicide. But if it was considered table stakes to implement the crypto option of the spec, and all the decent Matrix clients out there did so and sent end-to-end encrypted by default, then it'd naturally become the default. In other words, if you gracefully upgrade chats between capable clients to be end-to-end by default, everybody wins.
  - derf_ 12y ago
    If you really believe that, then I feel sorry for your users. Privacy is a public health issue: https://www.theguardian.com/technology/2013/may/21/privacy-public-health-surveillance https://www.theguardian.com/technology/2013/may/21/privacy-p... In the absence of some forcing function, the trend is for it to get worse, not better.