You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
Sometimes I'd like to get feedback on a draft before I make it public. The easiest way to circulate a draft is by putting it on the website without announcing it, as an unlisted page -- it's not in the feed and it's not linked from any other page and doesn't appear in the graph. It's only accessible through the URL. Additionally, if the content is sensitive, I may want to password-protect it.
Describe the solution you'd like
Two new properties in the front-matter:
unlisted: boolean flag. This sits alongside the existing draft and publish flags and doesn't affect their workflow. It only removes autogenerated links to and from this page (graph view, backlinks, explorer).
password: a string password or a list of passwords. This will cause the static page to have encrypted content (AES 256 or whatever is reasonable), needing one of the passwords to decrypt it client side.
Since encrypted content still leaks (a) content length information and (b) is vulnerable to offline brute forcing, the implementation could store the encrypted content in a separate file with a randomised name, only storing this filename in the page, also encrypted.
Build process, if password is present in front-matter (could be a plugin that does this):
Generate a random encryption key.
Encrypt page content using this key.
Store this content as JSON in the page, or generate a random UUID and store JSON blob in original-file-name-random-uuid.json in the same folder.
For each password, encrypt the random random encryption key and the data JSON filename with the password and store these as a JSON list in the page.
Generate static page including a script that implements content decoding.
Render process:
Included script renders a password dialog in the page.
If the URL has a password (eg, /secret-page#password=secret-key), autofill the dialog and submit.
On submit, test the password against the stored list sequentially, looking for a match. If one of the lines can be decoded to retrieve the encryption key (and data filename, if stored externally), fetch the JSON blob (from within current page or from server), decrypt contents and render the page.
The author can share distinct passwords with different collaborators and revoke them anytime by removing them from the front-matter. When the password field is removed, the page is no longer encrypted. Password protected pages may or may not be unlisted – those flags are separate.
Describe alternatives you've considered
My current workflow is to share .md files over chat for review, which is sub-optimal. Most people will read it as unrendered plain text, I have no control over the file's subsequent life, and it's hard to keep sharing revisions. When I need interactive collaboration, I copy the content in a Google Doc, but after this it's no longer Markdown and no longer lives in the vault, so there's a final reverse copy and reformat to Markdown required.
Additional context
WordPress supports password-protected pages and this has long been used for similar workflow needs.
The text was updated successfully, but these errors were encountered:
I really like the password protection idea - there is a lot of content that I would like to have hosted that I wouldn't necessarily want everyone to read.
Is your feature request related to a problem? Please describe.
Sometimes I'd like to get feedback on a draft before I make it public. The easiest way to circulate a draft is by putting it on the website without announcing it, as an unlisted page -- it's not in the feed and it's not linked from any other page and doesn't appear in the graph. It's only accessible through the URL. Additionally, if the content is sensitive, I may want to password-protect it.
Describe the solution you'd like
Two new properties in the front-matter:
unlisted
: boolean flag. This sits alongside the existingdraft
andpublish
flags and doesn't affect their workflow. It only removes autogenerated links to and from this page (graph view, backlinks, explorer).password
: a string password or a list of passwords. This will cause the static page to have encrypted content (AES 256 or whatever is reasonable), needing one of the passwords to decrypt it client side.Since encrypted content still leaks (a) content length information and (b) is vulnerable to offline brute forcing, the implementation could store the encrypted content in a separate file with a randomised name, only storing this filename in the page, also encrypted.
Build process, if
password
is present in front-matter (could be a plugin that does this):original-file-name-random-uuid.json
in the same folder.Render process:
/secret-page#password=secret-key
), autofill the dialog and submit.The author can share distinct passwords with different collaborators and revoke them anytime by removing them from the front-matter. When the
password
field is removed, the page is no longer encrypted. Password protected pages may or may not be unlisted – those flags are separate.Describe alternatives you've considered
My current workflow is to share
.md
files over chat for review, which is sub-optimal. Most people will read it as unrendered plain text, I have no control over the file's subsequent life, and it's hard to keep sharing revisions. When I need interactive collaboration, I copy the content in a Google Doc, but after this it's no longer Markdown and no longer lives in the vault, so there's a final reverse copy and reformat to Markdown required.Additional context
WordPress supports password-protected pages and this has long been used for similar workflow needs.
The text was updated successfully, but these errors were encountered: