Reserving the fragment for a password prevents us from using for other purposes

[wspringer]

We don't really care too much about including the password as fragment. We do however care a lot about using the fragments as they are normally used: linking to specific parts of the page. Because of the current mechanism, we no longer have the option. The fragment is getting removed from the URL.

[Greenheart]

Thanks for the feedback. This would be a good option to preserve the URL hash to allow for these use cases.

One idea for how to implement it in pagecrypt would be to add a custom HTML attribute data-preserve-hash to the <pre> element in the encrypted page, similar to how the data-i (for password iterations) is set here: https://github.com/Greenheart/pagecrypt/blob/main/src/core.ts#L76

This would also need a change to the condition in decrypt.ts (https://github.com/Greenheart/pagecrypt/blob/main/web/decrypt.ts#L40) to preserve the hash if the data-preserve-hash attribute is present.

To the users of pagecrypt, this should be both a CLI option and possible to send in via JS arguments. It might also be worth refactoring the pagecrypt JS API to include an options object for all configuration instead of positional arguments, since they are starting to become too many.

Welcome to submit a PR for this and I'd gladly help review and merge!

---

Update

Another potential solution could be to only autofill the password from the URL hash if a prefix is present. For example, magic links would start with #autofill=PWD, where PWD is the password string. This would fix this issue, while still allowing password autofill for those who want it. And we wouldn't need a configuration option for it. It would be a breaking change though.

https://www.w3.org/TR/media-frags/#processing-name-value-components