Hi, I am one of the core members at Sniptt - we recently made the decryption key part of the fragment precisely for the above reason. I believe the GIF in the README is outdated :) - the newer versions of the CLI ought to place the decryption key in the fragment, but please let me know if that's not the case! Thanks.
Hi, yes we've got basic rate limits in place, as well as other protective measures as this is pretty much an open endpoint. Please let me know if you'd like to learn more about how we're protecting the API as this is indeed quite an interesting topic in itself. Thanks!
Great. Are you considering removing your call to google fonts ? It gives way too much data to google for something that is privacy oriented.
Also, do you have a grace period for your burn after reading URL so that it can safely be sent by chats and emails system that visit any link you post ?
Great question - we will likely be looking at G Fonts alternatives as we are planning to revamp the entire website over the coming weeks/months.
As for "grace period", are you asking about URL/link previews and whether those have any effect on reading the secret? If so, the answer is no - the secret will only be read once the client-side JavaScript code is loaded and executed, only certain layout components are rendered server-side.
But I may have misunderstood your question, in which case please do not hesitate to ask again :)
Well, if you receive the url using gmail, google will visit the link, and execute the JS code. If you don't have a grace period, your secret will be unreadable before the human as a chance to get to it.
Just saying that because, while at 0bin we have a 1 day default expiration delay, users can chose burn after reading. But we had to add a small grace period to allow for user to check the URL, reload by listake, send vua gmail, etc.
I thin ots burn after reading by default so it could affect you.
I have run into this problem as well, my webapp sends one-time login/unsubscribe/etc links via email and bots like Office365 click on them, and, yes, they execute JS as well.
A standard workaround is to serve a page with a submit button on HTTP GET, and actually perform the login/unsubscribe/whatever on HTTP POST.
In case of emails, one can also observe the email scanner bots run almost immediately after the email goes out. We can use this as a bot detection heuristic, and make life a little easier for human users:
* if the login link is clicked within 5 minutes of email being sent, treat it as a possible bot activity and require the extra button press
* otherwise, assume the visitor is human, and auto-click the button via JS on page load
