Web clients

[jernst]

Perhaps write a user story do that effect?

[evanp]

I think you just did!

"As an ActivityPub user, I want to use a web-based client, so that I don't have to install any software to send messages."

[bobwyman]

"As an ActivityPub user, I want to use a web-based client, so that I don't have to install any software to send messages."

What assumptions can or should be made about the capabilities or composition of "web-based clients?"
For instance, might we assume that a "web-based client" that supports HTTPS could use those components which are necessary for its HTTPS support to also support other uses of encryption?

[nightpool]

I'm pretty worried about this one, since application trust is a very major issue with e2ee deployments that use web browsers. I strongly think we should reconsider having this in scope. Because server owners can send different code to different users, there is (to my knowledge) no safe way currently to use web technologies to deploy e2ee without exposing your data to a malicious server owner.

[bobwyman]

@nightpool If we can make OAUTH work, why not something similar for signing and encrypting? Have the message signed and/or encrypted out-of-band and then submitted to the application as a potentially opaque object or object containing opaque components.

[nightpool]

because the UI for composing and viewing the message is provided by the application (which is untrusted), so it can mitm the message.

This is in contrast to native apps, which are signed, public and auditable in a way that means you can trust & verify that e.g. the version of Signal you downloaded from the app store is the same one researchers have spent years decompiling and investigating for backdoors.

[evanp]

@nightpool How do you feel about a protocol that makes it possible to have Web clients, but a non-normative section that talks about the downsides of Web clients?

• Web server can serve different code to different clients
• No way (that I know of...?) to digitally sign a Web app
• Browser extensions or plugins could interfere even if the Web app is honest

I think a protocol that can't be used with a Web app is a problem. We have too many Web apps on the Fediverse today that will want to integrate E2EE.

[evanp]

What assumptions can or should be made about the capabilities or composition of "web-based clients?" For instance, might we assume that a "web-based client" that supports HTTPS could use those components which are necessary for its HTTPS support to also support other uses of encryption?

Do you mean something like the Web Crypto API?