Password protection for a single collectives page when synced

I have no support/technical question and have seen the support category. (Be aware that direct support questions will be deleted.)

on

Which general topic do you have

My suggestion is to protect the reading and editing of a single collectives page/subpage with a password.

Scenario:

When a Collectives page is synced, it is stored on the clients device as a readable md-file, its graphics are stored in an attachments-folder. Anyone who has access to this device (user-login-account) can read the md-file.

Suggestion:

Add another optional security-level to collectives pages by protecting them with a password. A protected page could be shared as a ZIP- or TAR-file, protected by the entire password.

If a page is password-protected, it shows up in collectives with its title and a password-marker. To open and edit the page the password has to be entered.

Maybe a user can set a personal default password that is used as a suggestion when he protects a page.

Use-cases:

We have Collectives that need pages with extra information only for special team-members. We do not want to create extra teams for these pages. This makes the data-management more complicate.

Data-protection on the devices collectives are synced with is a challenge, if a device is shared by some people. Yes, there are device-login-accounts and you can increase security by organizing data on the devices. But everyone knows, unexpected things can happen.

In addition:

I saw a similar solution in Synology NoteStation. A note can be protected inside NoteStation by a password. We want to replace NoteStation by NC collectives, but the internal password-protection in NoteStation is a nice feature we have used for many notes.

I know this feature request might collide with the basic sharing-concept of Collectives, sorry if this is the case.

Peace
Supernaut

Hey @supernaut welcome back :waving_hand: and thanks for your valued suggestion.

while we really appreciate it… we’re just an open community of fans with limited influence on development, we love to hear your suggestion.

however if you’re not keen on a discussion with the community folks, you can post a feature request on the development Github.

You could use an e2ee folder, and then use the readme.md file for this. This way you can slectively choose who can access that specific folder. It might not be collectives, but it would get the job done…?

Actaully, you could also use the “secrets” app, and then set an expiry for that one secret (or for each “permanent” secret) to something like 9999-12-31. Then you just adds a link to that secret in the collective page and in the secret body, you have written the extra messages and/or instructions. [EDIT: This will not work. Secret deleted after opened once]

This topic was automatically closed 8 days after the last reply. New replies are no longer allowed.