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.
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.
> 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. :)
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.
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).
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" :)
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 :)