Yep, that's what we do with https://0bin.net.

Also you must avoid client side 3rd party scrips, so no analytics. Also no cdn. I hope ots will self host their google fonts at some point, since you basically slink all secret URL to you google account (albeit without pwd) if you are logged in.

We also had several demands for an url shortener but couldn't find a sustainable way to do it. 3rs party have rate limits and hosting our own would get us back to step one.

DMCA also gets really interesting when you get a request but they don't include the hash because some of their tooling strip it along the way.

Anyway, even with all that, you still trust us since we could inject a rogue script at any time in the page.

So the process really protects only us as host (see our faq), but if you want real security, use pgp or signal. Or if you like the cmd thingy, magic wormhole is kinda awesome.

Still better than sending a password using plan text of course :)

Yeah guess you'd have to write your own client if you really wanted to be sure nobody could read the message in transit. But not sending the password to the server should at least remove the obvious

And credit to the Sniptt team, apparently they do actually put the password in the fragment in newer versions (and presumably you could build your own client for it using this repository if you're extra paranoid).

Yes, I think if they remove the cdn call it will start to be quite nice

The alternative is to do file transfers through WebRTC which is supposed to be end-to-end from my understanding.

If you use a webclient, it doesn't matter, you trust the server no matter what you use. Ots cli has the advantage of being auditable once, and remain on your computer.

True, I was thinking about the problem from a web only perspective, since WebRTC tries to do a direct connection between peers and only uses a third party server when one or both connections are behind a NAT.

If you initiate the session from your browser it doesn't matter. At best you get better cryto since it's native, but nothing more, and you can't store the result, so the receiver has to be connected.

If you don't, then the point is moot, and the problem has been solved with the excellent magic whormhole cli.

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.

Is there a rate limit ? Because the convenience the cli gives would make it really easy to create a FUSE driver for it and store abitrary files.

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

More context in this StackOverflow question: https://stackoverflow.com/questions/59281750/strategies-to-p...

Ouch. Google will visit the url and exec the js code. I did not know it sounds insane.

Oh, nice to see you're on top of things. Looks like the online version does indeed include the decryption key separately in a fragment.

This is what firefox send did. The code is still maintained here: https://github.com/timvisee/send