Possible tags: Security, Privacy, Product Safety and Integrity.
To be added once undrafted.

I have opened a separate RFC T417141 to request a strategic validation from the Product Safety and Integrity team.

Its not entirely clear how you plan to integrate this into mediawiki. There is no concept of private messaging in mediawiki currently, so its unclear how this fits into the design of mediawiki.

Is it just an external messaging system using mediawiki/wikipedia for identity management?

[That said its a hackathon, don't let me stop you]

In T417140#11626221, @Bawolff wrote:

Its not entirely clear how you plan to integrate this into mediawiki. There is no concept of private messaging in mediawiki currently, so its unclear how this fits into the design of mediawiki.

Is it just an external messaging system using mediawiki/wikipedia for identity management?

[That said its a hackathon, don't let me stop you]

Hi, sorry for the confusion. The idea is to build an external webapp that uses MediaWiki as an Identity Provider.
Specifically:

• Encryption flow: I am not reinventing the wheel; implementing a simplified version of the Signal protocol (3XDH, Double Ratchet).
• Identity & Trust: The app uses MediaWiki OAuth/OIDC for authentication. This allows users to leverage their existing Wikipedia/MediaWiki reputation to verify their identity.
• Key Management: Private keys are stored locally (IndexedDB). I plan to use some public on-wiki pages to store public keys (or fingerprints), ensuring the Wiki acts as a verifiable discovery service. Also the IndexedDB may be protected by a password stored in mw API:Options only accessible once the user has succesfully logged in.

So far I do not understand why this ticket is called "E2EE Messaging for MediaWiki".
All recent comments sound like "some external stand-alone app, which only uses MediaWiki for auth or as a source for some stuff" instead.

In T417140#11626296, @Aklapper wrote:

So far I do not understand why this ticket is called "E2EE Messaging for MediaWiki".
All recent comments sound like "some external stand-alone app, which only uses MediaWiki for auth or as a source for some stuff" instead.

Hi, you're right to point that out. And I'm sorry if that was misleading.

Any name proposal is welcome :). Proposed Name Changes:

• Wiki-E2EE: Secure Messaging Tool for Wikimedia Identities
• Wiki-E2EE: Identity-Based Secure Messaging for Wikimedians

Fwiw, i think that is a fine thing to work on at the hackathon. Just keep in mind that adoption by wikimedians would probably be an uphill battle as they will probably view it as just some other website.

That said, i never understand how a webapp can be e2ee. If the service provider is a potential attacker they can just replace the apps code. (This is a criticism that applies to a lot of alleged e2ee systems)

In T417140#11628412, @Bawolff wrote:

That said, i never understand how a webapp can be e2ee. If the service provider is a potential attacker they can just replace the apps code. (This is a criticism that applies to a lot of alleged e2ee systems)

These edge cases are exactly what I think would be funny/interesting to discuss at the hackathon :-)
My idea is that if we opt for Trust on First Use, the server can serve headers to keep the files cached indefinitely.
The client can then check for updates by sending a separate request with Cache-Control: no-cache to bypass the local cache. It would then compare the new file's fingerprint with a trusted source (like a wiki or a public repository). If they match, the client updates the cache and reloads the page; otherwise, it flags the mismatch.

In T417140#11626315, @valcio wrote:

In T417140#11626296, @Aklapper wrote:

So far I do not understand why this ticket is called "E2EE Messaging for MediaWiki".
All recent comments sound like "some external stand-alone app, which only uses MediaWiki for auth or as a source for some stuff" instead.

[...]

Any name proposal is welcome :). Proposed Name Changes:

• Wiki-E2EE: Secure Messaging Tool for Wikimedia Identities
• Wiki-E2EE: Identity-Based Secure Messaging for Wikimedians

My 2cents, I think the first option is better than the second.

In T417140#11628412, @Bawolff wrote:

That said, i never understand how a webapp can be e2ee. If the service provider is a potential attacker they can just replace the apps code. (This is a criticism that applies to a lot of alleged e2ee systems)

I think that the point of such an E2EE messaging system is also for the provider to say "we can't know what is inside these messages", if they receive requests from national or foreign authorities, which may be a realistic/legitimate use case for Wikimedia and this argument has been used by companies in some high-profile cases.

Update: I originally scoped this task as hands-on prototype work during the hackathon. After thinking about it more, I realized the most valuable use of a room full of Wikimedians isn't watching me write Go, but it's getting input on the questions I can't answer alone.

So I've replaced the coding session with two focused discussions:

• T421727 — Who Needs Private Messages on Wikipedia? — open to everyone, no technical background needed. Requirements gathering, use cases, trust questions.
• T421728 — Identity Binding Brainstorm — high-level technical session on the hardest open problem: how to tie cryptographic keys to wiki accounts. No coding, just systems thinking.

Prototype work continues outside the hackathon. These sessions are about making sure it's building the right thing.

Thanks for participating in the Hackathon! We hope you had a great time.

• If this task was being worked on and resolved at the Hackathon: Please change the task status to resolved via the Add Action... → Change Status dropdown, and make sure that this task has a link to the public codebase.
• If this task is still valid and should stay open: Please add another active project tag to this task, so others can find this task (as likely nobody in the future will look back at the Hackathon workboard when trying to find something they are interested in).
• In case there is nothing else to do for this task, or nobody plans to work on this task anymore: Please set the task status to declined.

Thank you,
Phabricator housekeeping service