Embedding decryption in a data: scheme

[franco-giordano]

Hi! I found your project really interesting. I read the discussions about it in Hacker News and one comment got me thinking about another potential feature: embed the decryption code in a data:// url, instead of relaying on gh-pages (or other mirrors).

I'm guessing that the URL may end up being too long, so another solution would be to use a CDN: the data:// url simply contains an html with the cdn import, and the package would decrypt the rest of the URL. It would still have a single point of failure (CDN may fail) but I think it's a bit more versatile than the gh-pages approach.

Is this possible? Is there something I've missed? I don't know the limitations of the data: scheme, nor those of the CDN approach.

[jstrieb]

Hi, thanks for taking a look at the project and starting this discussion!

The timing of you bringing this up is interesting, since I have just developed (but haven't yet had a chance to release) a way to do decryption without connecting to any external site. The approach I am using involves dynamically creating JavaScript bookmarklets that do the decryption step. These are essentially javascript: URLs to do what you propose (as opposed to data: ones).

With regards to the URL being too long for data: URLs, I doubt this would be an issue for most browsers. Another project of mine, URL Pages, stores entire pages in URLs similarly to data: URLs, and I have not witnessed any limitations on URL length. This is even after having 5MB+ URLs. Note that URL Pages was created when browsers dropped support for the ability to click on <a> tags with a data: URL as the href destination.

Hope this insight is useful!

[franco-giordano]

Awesome! I haven't thought about javascript: URLS. I used this project for a particular use-case, you may find it interesting:

I had to send some stuff to my partner (i.e. clothes) and thought about hiding a secret message inside. The problem was that many people would carry these things, so it couldn't be a letter (someone might open it and read the message). What I did then was to write an URLpage, protect it using link-lock (with a hint+pswd that only my partner would guess) and print the QR code linking to the link-lock. I then hid the printed QR code and voila: a special and real-life message "e2ee".

My partner loved it, no one else could read it, and didn't leave a trace on the web :)

In that sense, do you know if javascript: urls work with scanning QR codes? I know my case was super specific, but just wanted to tell you how I found your project useful.

Cheers!

[jstrieb]

Thanks so much for sharing your use-case. I love hearing about stuff like this, and that one is particularly nice!

My guess as far as javascript: URLs and QR code scanners is that most scanners can probably read the links, but actually having them be opened correctly will depend on the scanner and the device. I just tried it with the following QR code on my phone, and my reader wants to "copy as text" rather than open as a link, but it can still definitely read the data.

You mention that you read the HN comments related to Link Lock. Out of curiosity, did you find this via HN, or find the comments linked in the README?

[franco-giordano]

No problem! It's a really cool concept.

My guess as far as javascript: URLs and QR code scanners is that most scanners can probably read the links, but actually having them be opened correctly will depend on the scanner and the device. I just tried it with the following QR code on my phone, and my reader wants to "copy as text" rather than open as a link, but it can still definitely read the data.

I thought the same. My phone's camera (Samsung) opens the QR as a link, but doesnt show the alert.

I found your project in reddit a few months ago (I think you posted about it) and yesterday I found the HN link in the readme.