Sharing with visibility

polx

Hello Cryptpad Artisans,
The software really is a simple and convicing piece that is staying accross the waves of privacy breaches... This is amazing.
I learned to share the link with the share button... that took a while.
But while we're at it, the sharing dialog could add something that would make cryptpad usage much more visible and inviting: microdata/opengraph.

When I share a cryptpad-share-link on a social network, the html is called by whatever http client is there and the meta-tags are interpreted. In order to invite for collaboration, seeing the title, a description and possibly a picture of the rendering is an effective method; this can be delivered by the meta-tags.

So far the HTML is static. It could be, however, when sharing-link-creators want it, activating a server that verifies the signature then renders the HTML with the title, top text, and even image from the URL-parameters.

WDYT?

I know it would encourage, for example, my family members to click the link which they barely differentiate from a google or office doc link but for which cryptpad shines (in particular: no login required for the basic functions).

Fabrice

Hello polx

Thanks for your interest in CryptPad and your proposition.

However, due to end-to-end encryption it’s not feasible for the moment (with a sharing link, the server does not have access to the fragment (the part after the # containing the document keys)) and as such cannot decrypt the document (including its title).

I note that your feature proposal would be with the agreement of the person sharing it (meaning that if they are aware that they are giving access to the document to the instance they are hosting this specific file), however as is, nothing could prevent someone you shared your document to share it “with opengraph enabled” and thus breaks the security for all contributors. We cannot allow this.

You also proposed adding an authentication layer via a signature, however due to the collaborative nature of works in CryptPad, the signature would become invalid once the document changes (henceforth the server will reject it), you can also sign your “preview” and have it stored by the server somehow but as these data are user issued, nothing can forbid a malicious actor to send a “fake preview” misleading people into clicking the link.

As enticing as your proposal seems, it does not look feasible within our threat model at the moment.

Thanks for your understanding,
– Fabrice

polx

Dear Fabrice,
I disagree.

Signature: I was meaning here that it checks a signature of the server alone. It is not imperative but it would make sure that the server has issued such a link.

That parts of the contents (title, start) is shared is, of course, not possible to deliver from the server by decrypting the contents (we know it cannot). It would be included in the link!

Thus the role of the sever of the shared link would be, besides executing the sharing link with javascript functions to get you to view or edit as desired, to represent the information given in the URL (before the "#") within the meta tags if the checkbox "add title and description" was checked.

I really believe that this function is important to invite non-techies.
Paul

polx

however as is, nothing could prevent someone you shared your document to share it “with opengraph enabled” and thus breaks the security for all contributors. We cannot allow this.

Why would this be a problem? The same problem occurs if someone shares an editing link, for example: everyone accessing the URL can edit.

Paul

Fabrice

Signature: I was meaning here that it checks a signature of the server alone. It is not imperative but it would make sure that the server has issued such a link.

I don’t get what you mean by that. Our server is only manipulating encrypted data, it does not know the content of the file which doesn’t leave collaborators’ computers. Basically: what do you propose to sign?

Which comes back to your further remark:

however as is, nothing could prevent someone you shared your document to share it “with opengraph enabled” and thus breaks the security for all contributors. We cannot allow this.

Why would this be a problem? The same problem occurs if someone shares an editing link, for example: everyone accessing the URL can edit.

The server is not aware of the key and cannot derive anything besides the document type (to load the correct app). There is extra information that a semi-honest server can try to derive, but nothing compromising.

In your proposal, upon deriving a “link with preview”, you have to give access to (part) of the plaintext to the server for it to be able to serve these data, which can contain sensitive data (such as the document title). Indeed sharing the link gives access to those with the link (except when using an extra password on the document), however the server remains oblivious to which data it’s serving.

I understand that you want it to be “upon request”. However, my point is that once shared, it’ll be hard to avoid one of the collaborator having the link from creating such a link. As such, it may potentially be leaking sensitive data to the server without you knowing the better.

That parts of the contents (title, start) is shared is, of course, not possible to deliver from the server by decrypting the contents (we know it cannot). It would be included in the link!

The information have to be encoded somehow in the link, which is already pretty long…

Thus the role of the sever of the shared link would be, besides executing the sharing link with javascript functions to get you to view or edit as desired, to represent the information given in the URL (before the "#") within the meta tags if the checkbox "add title and description" was checked.

Unfortunately, as I already said, providing these pieces of information to the server breaks our threat model as it gives potentially sensitive information to the server.

I agree that it would be an interesting feature from a UX perspective, however we cannot compromise on data privacy for that.

Regards,
– Fabrice

polx

Hello Fabrice,

The threat is broken if you share the link. It is further shareable (just as any editing link). As the current UI says "an irrevocable and shareable link"; any recipient of the link can access the content (and that is intended).

The proposal is to include all information necessary to display in the meta-tags in the link. Yes, it would make it longer but that bothers few people (onedrive links are already 2-lines long for example).

Why signature? I only want that the server who renders this to a series of meta tag does not do so for arbitrary links it gets sent but just for those the server has produced. The signature would be offered as a service for users that are already editing; I am not very sure how to implement that but the rest is pretty easy to implement to my eyes.

Paul