CryptPad @cryptpad@social.weho.st

Last minute I had to step in and make a presentation about @cryptpad project at OW2con. I used CryptPad #markdown slide deck. Very productive. Here is my presentation: https://www.youtube.com/watch?v=1CxtFBcOdDU

@cjd @dr1ft @cryptpad you forgot blockchain

@dr1ft
For @cryptpad project we use business buzzwords:
agile
bigdata
competitive
drilldown
enterprise
...

@christianbundy Yes, this is the weak link. There are 3 solutions that can work:
1. Forever-Cache the index.html -> Trust on first use model, browser reload resets it though...
2. Secure bookmarklet ( https://wiki.ripple.com/User:Justmoon/Secure_Bookmarklet ) which hash-checks index.html before loading it
3. A browser extension such as Signed Pages ( https://github.com/tasn/webext-signed-pages ) but this one is not blocking the page load so keys can leak while you're being notified that the site is insecure...

@cathal @christianbundy
Yes, the code-integrity branch which I demoed in the presentation uses subresource integrity as well as Signed Pages to verify the index.html https://github.com/xwiki-labs/cryptpad/commits/code-integrity

@cathal @christianbundy
Would be cool to have a hash in the URL spec, something like: `sha256:<base64>:https://path/to/resource`

@cjd @christianbundy
Now, it would be interesting to have a companion feature for anchor/link elements, where you could say "the document at this URI must match this hash": if the referenced document used sub resource hashes (in turn, verified by the link hash), then you could in theory get full rendered document verification from the initial link. Not confidentiality, though. And if dynamic responses are trusted from server, security ends there, too.

@christianbundy
@cjd
If the server controls the HTML, they can do as they like. I think the idea of this feature is that HTML often references resources that are outside the server's control: JQuery etc. are often loaded from CDNs under the control of companies you shouldn't trust. Using a hash to verify means you can reject content you don't expect.

@cjd Could the server send the wrong index.html and circumvent this check (or use their own hash)?

Just demonstrated a @cryptpad experimental branch using subresource integrity and code signing to deal with the problem of server providing wrong javascript.
You can checkout the branch here: https://github.com/xwiki-labs/cryptpad/commits/code-integrity but careful, it's very alpha...