pinehqcom

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

Hey ibdf, great suggestions. I think the "If not visited delete after" is lot better wordwise!

Ps. what does your name stand for? ibdf?

That's a good point. I'll find another way to express it. Thank you mtmail

I considered building something similar OnlineOrNot for many years now since I needed to validation of e.g. json.

I'll definitely check it out!

Hey HN!

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:

https://duckist.com/msgs/messageID#password

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

This is actually an old project that we decided to rename, revive and improve. I previously wrote about it here: https://news.ycombinator.com/item?id=21513362

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.

Thanks again Jetti!

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?

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

Try it for free without having to submit any credit card details. You can signup here https://app.apijack.com/accounts/signup/ and see our documentation here: https://apijack.com/docs/

I'd love to hear from you - what can you use, what can't you use?

Did you find any bug? Is there anything that you'd love us to add? Any specific API you'd like to have integrated in apiJack?

Don't be shy! Send us your feedback!

I setup this alternative for Medium, https://bun4.com. Make a Pull Request on https://github.com/pinehq/bun4 and it automatically compiles. Stop complaining and start writing ;)

Many complain about Medium and static site generators and would love just to write technical articles. Now you can get your article on https://bun4.com by just making a PR on https://github.com/pinehq/bun4 . The service is free, without ads, Hacker News inspired design, and you can make your articles in your own editor.

I setup this https://bun4.com for you. Make a Pull Request on https://github.com/pinehq/bun4 and it automatically compiles. Stop complaining and start writing ;)

Thanks :)

I am not following, could you elaborate a bit more?

Yep. Right now I just override any message securely. I was thinking of doing something like having all the messages in memory and just wipe the memory there, but the problem with that approach is I can't tell people if it expired and thus you can't see if people eavesdrop.

Woa https://paste.sh is awesome. I love it. Super minimalistic. I wouldn't use it for sharing passwords, but using it for sharing notes and permanent things could be pretty nice. Right now I use Google Docs and hackmd, but they are not encrypting stuff. How does it work with multiple users online?

Thanks bko! You're signing up for newsletter and get's notified when there's a version 2.0 and also get 2 months paid.

Great suggestion, I'll rephrase it.

Didn't know it existed when I made https://instapass.io privnote looks nice and I would definitely use it before I made my own service. I am planning to add more features that hopefully will be useful for you guys.

Exactly. Either a message expires or it get's viewed.

All the encryption part is javascript and visible in the browser. Go nuts

KeyBase seems nice but a total different usecase I would argue.

Very nice. I love your Dory mascot!

Woaa yea very similar and even the name is similar. It didn't exist when I started the project. Looks nice.

It's not a perfect solution. As @dfalfndfk says you will know that you're eavesdropped.

Exactly exactly. I made sure to be resilient to Google bots/Virus Scanners by doing some fancy javascript tricks

It is secure. The password is not sent to my service. Try setup an `netcat -l -p 8000` and go into your browser and write `http://localhost:8000/#hi` You will see the hi is never sent to the server

For this reason I host all the JS/CSS myself and don't have any other JS running. I.e. no google analytics or ad shit.

That's actually not a bad idea. You could add different kinds of auditors and see who approved it. I'll add that to my never-ending list of "Good Business Ideas When I have time"

All my JavaScript is self-hosted and easy to read. If you don't trust my service then you can just keep the password in Instapass and the other login info (url to login, email, username, etc..) inside the email. How should I know what you sent a password to? I think that's a better choice than sending login info in clear text.