Do not expose "Shared notes" via sharing API by default

[ifsmirnov]

Describe feature

Each shared note is by default accessible by a (seemingly) random URL. It may give a false sense of security: it looks like one has to know the id of a note to access its content.

However, a call to /share/api/notes/share yields meta-information of a root "Shared notes" note. In this way it is possible to enumerate all shared notes. I think that "Shared notes" should be password-protected or even inaccessible by default.

I know about #shareCredentials attribute. This issue addresses the case when one does not protect the note because expects its URL to be secret enough already.

Additional Information

No response

[zadam]

Hi,

I think that "Shared notes" should be password-protected or even inaccessible by default.

That would kind of defeat the purpose of being a quick / easy way to share the notes.

I think it's "just" a perception / documentation problem - this feature is meant to publish the notes openly and the random-looking URL is just incidental, because it uses note IDs which are random strings.

Even without the share index, any kind of URL-based authentication is pretty unsecure - URLs tend to leak in various places.

I updated the https://github.com/zadam/trilium/wiki/Sharing to make this more explicit.

[ifsmirnov]

Hi zadam,

That would kind of defeat the purpose of being a quick / easy way to share the notes.

I suggest protecting only the root itself, i.e. the note "Shared notes" itself. It will not affect other shared notes anyway except for disallowing obscure discovery mechanism.

Even without the share index, any kind of URL-based authentication is pretty unsecure - URLs tend to leak in various places.

Google Docs with "anyone who has the link can view/edit" disagrees :) When I share a link to a certain document to someone I don't expect him to be able to enumerate all my other shared documents. It tends to be pretty secure when the link is shared to a small number of trusted co-editors. Although I wouldn't share really sensitive data this way, it is well enough for medium-level security (e.g. preparing tests for students). Are Trilium shared notes secure in this sense if I do not leak the note IDs AND protect "Shared notes" root with credentials or there are other potential loopholes allowing enumeration?

I appreciate the remark in the docs. However, the sharing mechanism looks very similar to the one of Google Docs (you click a button and receive a randomly looking link) thus one might expect similar security guarantees. The "Share" button is obviously placed, so I might expect at least someone using this functionality without even having read the docs. That's why it seems dangerous to me and I decided to highlight the issue.

After all, I understand and respect your vision of the project and of course by no means will insist on anything.

[zadam]

Hi Ivan, to be honest, I wasn't reading your first comment attentively enough (e.g. didn't notice you talk about share API) and responded without deeper analysis.

I agree that there is an inconsistency between what was possible in the API and on the "website" which is just bad as it sets bad expectations. I fixed this - as you suggested, the share root is now accessible only when the share index is published (which is opt-in via #shareIndex), thus making API and "website" equivalent - without being able to retrieve the share root, the API client can't traverse to the children (which are shared subtrees).

Google Docs with "anyone who has the link can view/edit" disagrees :) When I share a link to a certain document to someone I don't expect him to be able to enumerate all my other shared documents. It tends to be pretty secure when the link is shared to a small number of trusted co-editors. Although I wouldn't share really sensitive data this way, it is well enough for medium-level security (e.g. preparing tests for students).

That's true, there is a trade-off between security and comfort. The trouble with URLs is that they are often not treated as sensitive by various applications able to access them - e.g. they are stored in browsing history, often in various proxy access logs, harvested by web extensions, sent by clients in REFERER header etc. But it's true that the "secret url" level of security is often enough for some use cases.