Great question Freemade, we use https://crypto.stanford.edu/sjcl/ for the encryption. It is pretty straighforward. The password (as per my main message) is saved suffixced on the url with #. E.g. #mysecretpassword. This is because hashes are never sent to the server.
Thanks Raed, We are changing it to "Messages are encrypted in your browser to ensure they are not even accessible to us" per your suggestion on Monday :)
I am a part of a small IT business and like many of you, we face the constant problem with securely sharing passwords between clients and between coworkers.
Of course, there are systems for this, but with busy schedules or mere complacency, it's a challenge to get all involved to set up these services accordingly. Failure to do so means that the passwords to accounts with critical user data often end up as contents of non-encrypted email messages or other equally unsafe means of communication. Confidential files share the same fate.
We decided to take a different approach instead, which we think balances ease of use with security.
We named the service Duckist.com and with it, you can generate self-destructing messages containing either text or media, that are encrypted on the client-side. This means the server never actually sees the unencrypted message.
# Technical
This is only relevant if you'd like to know what's under the hood, which I know many of you guys here, certainly are :)
What we do is use the browser to create a password that is then used to encrypt the message on the client-side. The encrypted message is sent to the server and on the frontend side we generate a URL such as this:
How is that beneficial? When a person visits this URL, then the browser won't send anything the hash to the server. This means that when someone reads the message, Duckist.com never sees the password.
To see this is actually true, pop up the terminal with `netcat -l -p 9001` and input http://localhost:9001/hello#mysecret into your browser.
You'll observe that `mysecret` was never sent to the server.
To see we are sending/receiving the messages encrypted you can use the browser's inspect functionality.
We saw the benefit of the tool's existence and decided to turn it into a public project hence I'd love to get your feedback. I am thick-skinned so just come at it in full HN style :)
I understand the no js/plugins, but why not a static site generator?
Static site generators (at least most) are the only "new" technology that seems to make things simpler instead of more complicated, and SSGs are a massive time saver regarding themes, sitemaps, robot, optimization, etc.. and there are no dependencies at all.
It also helps me writing.
I run `hugo serve` that autorefreshes in the background, then I have split up my screen with right being my vim and right my browser.
Takes 1 second to see the result of what I am doing.
This... I just found a plugin for the static site generator Pelican that is 7 years old that still works.
After running Pelican you get plain HTML that can be hosted anywhere.
I like Netlify, but other options like GitHub pages are also great.
The author recommends not putting on GitHub Pages because they haven't found a working business model and might not be here in the future.
But... GitHub has been taken over by Microsoft which is most likely not going bankrupt soon and Microsoft loves their backward compatibility so I am confident they won't screw GitHub up too much.
You can say the same about geocities when it was acquired by yahoo. But it didn't last and then now it's happening with yahoo-groups. So I am not hopeful if GitHub becomes a liability microsoft will keep it.
Thanks for taking the time to read and go write this super beneficial feedback Jetti!
1.) The reason why I choose httpie over curl is that it is a lot shorter and just show the essential instead of setting the applicaton/json and having json as a string, but you're right.
I'll translate all the examples to curl in the next coming time.
2.) The APIs do not fit the standard CRUD/Resource (Rest) approach.
Our small team discussed a lot about how to do it and tried different ways but it made it harder to remember was it with a POST, or GET?
Both kinda made sense, and what when you wanted parameters with as GET?
3.) We will be adding a tonne. First, we wanted the platform up and running as basic as possible.
We got inspired by the "API Marketplaces" where everyone can upload an API, but we want to address the problems with poor quality, latency, and documentation.
The idea is to have one place to use/pay/do.
Almost nobody signed up compared to the visitors we got from HN.
Can I ask you if you signed up or not and how come?
As for number 2, I think it may be more confusing for potential users since it doesn’t follow a pattern that is typical.
I did not sign up. I don’t have any need for anything you provide at the moment. I think some of the endpoints are going to be very niche. I have never needed to post anything to pastebin. Most languages provide functionality for a UUID as well.
Maybe you are like us, tired of spending hours on complicated APIs with incomprehensible documentation. We decided it was time to fix this.
We are trying to make it easier to be a developer in 2020 and beyond, by making functionality available through an API. This way, you won't need to implement it yourself or use a library that might break upon updates or other weird stuff.
What do we do for you?
* Lots of reusable things to use to make your own software faster
* The API will always be compatible with previous issues
* Technical Support - talk with our engineers whenever you need us
* Provide you with documentation just the way you want it
