Web clients - Githubissues

swicg / activitypub-e2ee

Coordination of work on end-to-end encryption with ActivityPub

13 stars 0 forks source link

Web clients #22

Open jernst opened 3 months ago

jernst commented 3 months ago

Perhaps write a user story do that effect?

evanp commented 3 months ago

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 commented 3 months ago

"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 commented 3 months ago

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 commented 3 months ago

@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 commented 3 months ago

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 commented 2 months ago

@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 commented 2 months ago

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?