[Feature Request] Direct links to Cryptee docs from outside of Cryptee

[dhda]

This is related to #127 but with a use case that is not covered by the existing document linking functionality. I’d like the ability to link to specific Cryptee docs using a URL that can be opened from outside the app.

Currently I use Google Docs to maintain a long journal of time-stamped entries. I have an iOS shortcut set up that formats the date (so this is tangentially related to #115), and then automatically opens the right Google Doc and goes to the specific header in that doc where I insert the journal entry. This is possible 1) because Google Docs has direct urls for each document, and 2) because it supports bookmarks within a doc that have an associated anchor that is #appended to the end of the URL.

I would love if Cryptee supported links similarly. Naturally it probably can’t support fully public links in way GDocs can, but the ability to open Cryptee with a url like https://crypt.ee/docs#hash-of-document, and then having that document be automatically opened once I am logged in and have entered my encryption key, would be super useful for me!

It seems like there could be concerns about leaking the existence of a particular document, especially in the case of potentially ghosted docs. I feel like just having a message in the hypothetical copy-url dialog about the possible risks of leaving such urls laying around would be sufficient.

[johnozbay]

Hi there 👋🏻

Thanks a lot for filing this.

We've been thinking about bringing this functionality, and v2.0 actually had this under the hood, but we decided to never use this, and in fact removed this for security / privacy.

Like you guessed, there are many ways these can cause leaks, especially in browser history entries, things like monitored office networks, or university network access logs etc etc

i.e. it can leak things like : – docs in ghosted folders – doc IDs / existence of docs – how frequently you open a doc – at what time of the day you open certain docs – potentially the length of the doc (if we expose things like in-document anchor-links to headings etc)

We will however add a somewhat similar functionality when we have sharing / collaboration & public links [ coming soon™ ] – but until then this opens the doors to lots of different potential leak vectors I'm not sure if we're comfortable with addressing just yet.

While I do get that we could always add a warning message pop-up in the copy url box, I'm also 100% sure a "copy URL box" would cause many people to mistakenly think they can share documents using these URLs, and cause a lot more frustration / confusion = more leaks.

So until we enable sharing / collaboration, I'm afraid I don't think adding this in is a good idea. I'll close this for now – at least until we have sharing / collaboration – but feel free to chime in thoughts / ideas here, and we can make it happen when we're ready to ship sharing & collab!

Thanks 🙏🏻

[dhda]

I mean… I have some needlessly complex Bad Ideas for how it could work:

• Encrypt URL #doc-ids with a time-based OTP, which would mitigate most of the leaked metadata concerns. The con being that you need special software on the client to generate the URL (though probably doable in an iOS shortcut).
• Pass the doc-id to be opened as an HTTP header. Still needs special client software.
• Add fixed URL “pins” like https://crypt.ee/a, https://crypt.ee/b where “a” and “b” are in-app settings corresponding to slots for pinned docs that you want URL access to. This would at least reduce the specificity of any attacks on leaked metadata.

And then some more reasonable ideas:

• Add a setting for a default document that gets opened on startup, every time. (Potentially runs into the same issues we discussed in #90 though?)
• Add a list of globally pinned documents parallel to the “recent documents” list on the welcome page. One extra tap instead of zero, but not bad.

Sharing and collab features sound like the best approach though.