stophecom

I'd recommend the following options. Both platforms offer enterprise solutions, but also provide free starter plans:

https://www.storyblok.com/

https://www.datocms.com/

From own experience, the developer experience is awesome. Both are based in Europe, which is probably why those were not mentioned here before :)

No, unfortunately not at this point. I got often issues with bigger files in Chrome for some reason. (network error) But Firefox worked. I try to improve the stability in the meanwhile.

Was about to say. Domain is great. I created scrt.link some time ago, which does the same thing as well :)

Well, fair questions. So as mentioned in the footer. The service is powered by scrt.link, which encrypts the url on the client. That means br3f never knows what link you intend to redirect to. Read more on https://scrt.link/security.

Agree on the email part. Obviously you don't want sensitive information inside emails. But with br3f you have additional security, since a link can only ever be accessed once.

With br3f you can create disguised and disposable redirect links. Use it whenever you have to share a sensitive URL in a chat or email.

> If you want to quickly commit something really small and trivial in master/a branch/a PR without having to do the whole stash/checkout/pull/change/commit/push rigmarole (like if you're in the middle of doing something else).

Agree, except code formatting (e.g. w/ Prettier) is missing - which would make it extremely helpful to do small PRs.

Issue is resolved. Using DELETE request now, which feels a bit more accurate. Blocking crawlers is no longer needed, which also benefits page speed! Thanks again for the input. C.

Thanks again for all the feedback. Short update: I'm using DELETE now, since it feels a bit more accurate. As a side effect, the page is way more responsive. :)

Have fun sharing secrets. C.

Yes, this is a joke. Not sure it's a good one to earn trust ;). C.

Oh wow :) Do you know, by any chance, what type of filter/firewall your institution is using? I'd be interested in the reasoning behind the flagging/blocking. C.

> email security services do click on links before delivering to the client's email inbox

True. This may be a problem. Like mentioned, common bots are being blocked currently, plus, I will be testing POST instead of GET requests (Since bots apparently don't do POST). An another obvious solution is to include some kind of user interaction before the secret is fetched. Although I don't like that solution so much. C.

The part of the URL holding the encryption key is not sent to the server. https://stackoverflow.com/questions/14462218/is-the-url-frag...

Don't take my word for it :) You can check all code that runs in your browser and check all requests made within the network tab.

Not exactly. Sure, if your email is compromised someone could access the secret link, and ultimately your password. But now, you will know that someone else had access to your password, since the link won't work for you anymore. This is crucial information.

Btw. You can encrypt your secret with an optional password (which may be shared via a different channel).

Very good point! Thank you. I'll look into this.

It is done entirely on the client. You can check the source code. Read more on scrt.link/security.

Thanks for the feedback. Appreciate it.

I believe you can earn the necessary trust by being transparent. For this kind of service two things are essential:

- Open source software: Let everyone review your code

- Encryption in the browser. Sensitive information should never leave the browser in plaintext.

I'm considering file transfer - but there are some challenges to meet :)

C.

Thanks for the feedback. Much appreciated - I'll look into the consistence naming issue.

> Features like delete after N visits or by X date might be useful too.

Indeed this is an often seen feature. I'll consider it.

About the use cases. Not sure I agree - I believe sharing credentials is one of the main purposes of the service. But like you said, it's limited to "transmitting" the secret in a secure way and not meant to act as a "storage". In other words, yes, a recipient should copy the password and store it in a password manager.

About the trustworthiness. Yes, trust has to be earned. Without affiliation to Mozilla, Google or other trusted brands it's not an easy task. That said, I think what makes the service trustworthy is the fact that:

- It's open source, which means full disclosure - all code and all dependencies can be accessed and reviewed.

- The encryption is happening on the client (browser). All code that is executed within the browser can be viewed. You'll notice in devtools that your secret never leaves the browser unencrypted (and the key doesn't get stored). Which means, even if the server infrastructure got compromised, or seized by the government, there is no way of decrypting the messages. tl;dr: It's safe to share "credential to access a production database" :)

Good question! Bot traffic from common apps/services is beeing blocked. But let me know if you run into a problem. C.