Access to fetch at 'file:///D:/Users/maggie/Google%20Drive/portable-secret/creator/secret-template.html' from origin 'null' has been blocked by CORS policy: Cross origin requests are only supported for protocol schemes: http, data, isolated-app, chrome-extension, chrome, https, chrome-untrusted.

I understand keeping the UI clean, but the encryption even though you didn’t write the algorithm you choose the implementation details. AES and keysize with PKCS padding options should be explained in the README because THESE ARE implementation details important to users.

You’re documenting the html very clearly but I would like to see it outside of the code.

Some browsers automatically save and fill in the form field contents when it's not a type="password", showing the password in plain text when navigating to a previously-used secrets page.

Plain text could be a toggleable opt-in.

Hi,

You could add this to the end of the secret-template file, within the script tag, to allow that.

document.querySelector("#password").addEventListener("keyup", event => {
if(event.key !== "Enter") return;
decrypt()
event.preventDefault();
});

Hi,

Nice work:
Maybe a suggestion for delivering a specific message when the entered decryption password is incorrect:
Instead of Decryption failed: OperationError: The operation failed for an operation-specific reason something like a basic Wrong password, try again!

When testing my first thought was that the failure was that of the code itself ...

This is a really useful and simple tool. Thank you!

In regards to usability while traveling, sometimes authorities at an authoritarian country may coerce the visitors to decrypt the files on on a USB drive. It would be nice to have a plausible deniability feature linked to a second passphrase where the second passphrase would decrypt some dummy data of the user's choosing (e.g., another PDF file). Just a thought.

UNFINISHED DRAFT, please do not complain it is not actionable, I will get back to it hopefully in January/February 2023

1. press "decrypt" automatically changes the Salt and IV
2. one can add arbitrary number of messages, files, images in the specified order!
3. maybe: message could be replaced by "rich text" which would be simply djot to support formatting, tables, and embedded images - see #1 (comment)
4. redo UX based on clarified use cases (some way to "amend" existing file - under the hood a full regeneration would of course happen)
5. make it work with JsShelter's strictiest settings ever
6. team up with USB key storage open source projects (Signet etc.)
7. make it easy (one click!) to share the resulting file through several free hostings at the same time (if small enough, maybe store it in URL itself!)
8. make it easier to audit the encryption web page (e.g. make a release signed by a well-known certification authority so that the browser can check it on its own)
9. add password strength estimator visual indicator (e.g. a bar) - e.g. zxcvbn from Dropbox

Hi, this idea seems lovely, but currently the implementation has some painful moments:

• Encyrpting doubles file size, it will be probably super hard to avoid, if not impossible, but at least you should note that in README. I don't know if hacks like that: https://news.ycombinator.com/item?id=12262470 would make it possible to read the contents of the binary data, probably not, but that's something I remember reading, further research is needed

• Encrypting freezes the browser. Opening a encrypted 9MB file (so 18MB HTML) freezes the browser. Chrome wants to kill the page when I try to focus input box - super bad UX here, not sure how could you embed this data within HTML without this. Encrypting could be moved to web workers, but with file:// protocol you have when you open local html file this is impossible. But you can at least have this for hosted HTML files I guess?

• The encryption & decryption pages could use some nice UI design and UX. It's currently quite ugly and after using it once when decryptin all I care is the password box, yet most of the screen is covered with explainations, huge password hint, advertising product name and very cryptic (haha! a pun!) Details section

Proposed easy solution to UX:
Because there is no chance that all the people in the world would like my approach to decrypt page, which for me should look like that: https://dribbble.com/shots/5757939-Password-requirements (without the characters counter, and the text below input would be a password hint, OPTIONALLY I could display some text above the password field for first time users):

• add a way to customize CSS
• add a way to customize texts

Not sure how it'd be the best way to save my customizations so I don't have to copy/paste them each time.

Tell me what do you think about my thoughts

While the core of Portable Secret uses the W3C Web Cryptography APIs (which is great!), the specific choices of cryptography parameters matter and can drastically affect the security of the implementation. These should be called out in the README.md so they can be more easily assessed by those with enough knowledge of cryptography primitives.

Specifically, this is what I found in the source:

• The secret is encrypted using a derived key, not directly with the password.
• This key is 32 bytes long and derived from the password using PBKDF2 with 1,000,000 (1 million) iterations.
• A 16 byte salt is used.
• The derived key is configured to be non-extractable.
• The derived key is used for AES-GCM.
• AES and the IV use a block size of 16 bytes.

Hi,

thanks for this interesting project. While I was 'playing' with it, i noticed that every generated secret file has the same filename, thus when saving overwriting the previous saved file.

Maybe it is an idea to add a date/timestamp/uuid kind a thing so that every generated file has a unique filename by default? OR make the filename configurable and not just 'secret' for that may scare people off or does not adhere to a policy of a kind. And not everybody speaks/reads English ;-)

Thanks for your considerations!

Hi,

When I use chars like the german-umlaute "öäü" they will get Replaced with ���

Maybe the secret.html is exported with ASCII encoding and not UTF-8 so that the chars are lost when JS is handling them?

Is this website: https://portablesecrets.com/ hosted by the author?

https://gitlab.com/smondet/hscrypt (Uses gpg for encryption and OpenPGP.js for decryption)

2 things that is has that are nice and could be suggestions:

1. little shell script to generate the secret html pages from the command line
2. the decryption attempts to grab the password from the URL selector (a.k.a. the #… part, which the browser should never send to the server), you can pass document + password, over encrypted chat like Signal or Matrix.org for instance like this https://smondet.gitlab.io/hscrypt/hscrypt-test.html#test-pass-phrase.

When trying to decrypt secrets on my homepage, having accessed it with http instead of https I got the rather unhelpful error:

Decryption failed: TypeError: Cannot read properties of undefined (reading 'importKey')

Only after checking your example with an incorrect password did I realise the error was not related to my password (which I was sure I had correct).

Then I realised I was using http and that might cause Crypto APIs to not work, which was indeed the problem. It might be helpful to warn users that this only works over an SSL connection.

Saving encrypted data on public servers is a great idea,
but there is no assurance of data persistency ,
my suggestion is store the data on an Ethereum transaction ( using calldata args) , this way the data will be persistent in the chain forever , and the data will be replicated on thousands of servers in a decentralized manner

If I try to generate a secret using the downloaded index.html file I get a TypeError. Is this normal/expected?

I suspect this isn't too difficult, but it would be cool if there was a 4th option beyond: file,image,text
"image from camera"

I think the correct API is the ImageCapture API: https://developer.mozilla.org/en-US/docs/Web/API/ImageCapture