paulfurley

FWIW I recently evaluated a few DNS companies after Namecheap ballsed up our MX records in a similar way.

I actively looked for someone we could pay money to, so we are their customer (as opposed to being a free tier user, effectively a cost)

The winner was DNSimple[1], who do exactly 1 thing, and they do it extremely well. And they are small enough to not take themselves too seriously[2], which I really appreciate.

Oh and their normal support channel is email, and everyone in the company takes a turn. I tested out their support before signing up and quickly heard back from a competent engineer, so they passed that test too.

[1] https://dnsimple.com [2] https://dnsimple.com/dnsound <— bonkers

Philosophically, sure, but this is a straw man argument.

The practicalities and cost of putting cameras in every room then monitoring them are clearly absurd, so it undermines your case.

An APL is a very compact programming language, from Wikipedia:

> APL (named after the book A Programming Language)[2] is a programming language developed in the 1960s by Kenneth E. Iverson. Its central datatype is the multidimensional array. It uses a large range of special graphic symbols[3] to represent most functions and operators, leading to very concise code.

Took me some time to realise what I was even reading about, let alone the content!

I’d suggest that running a vulnerable production service is asking for trouble!

My web logs are full of automated scanners. Once when I ran a vulnerable version of Wordpress it got discovered and pwned very quickly. No need to enter the URL in any website ;)

The first URL I entered (coop.co.uk) was actually pretty awesome, it detected Varnish and showed a critical CVE from last week. That’s cool.

I hope that if you subscribe, the site regularly rescans your stack and realised if it’s changed. Otherwise it’s just a mailing list subscription that becomes out of date and therefore not useful.

This site immediately presented an alert dialog with a single button “OK” which, when pressed, redirected me to some shitty spam site saying I’d won something.

Agreed:

“argumentation”, “pro & contra lists”, “dialectical relations” “premise-conclusion structures

..all appear within the first 100 words and I don’t know what any of them mean. I’m a a native English speaker with a technical education and I am lost!

Is the site aimed at some profession where these words are commonly used?!

Not sure exactly how but I’ve mostly avoided places where being an asshole is acceptable. This could be to do with actively avoiding bro-fest type places, looking for high-impact rather than high-pay kind of work, but I can’t really take credit.

Separately, I’m quite shocked reading this HN thread seeing people defending the behaviour the article describes. I suddenly feel like I don’t really know the tech industry at all!

What sort of road building / improving did you have in mind?

We’re talking about city centre slow (<12mph) driving, I’m really not sure what road improvements could improve safety of silent cars?

I know the folks behind this and I think they’ve approached it thoughtfully and realistically.

It’s using a modern OpenPGP implementation and language (Sequoia, Rust) which is a big win. Despite it being centralised, I’d encourage folks to have a look.

On that issue, SKS has become so troublesome to run that the number of peers has steadily decreased to the point where there are only 2 entities running the HKPS (“secure”) pool, so in reality SKS is centralised too, as well as unmaintained. Source: I run a key server and a key expiry reminder service.

Keen to get folks' feedback on this. I'm all ears! Here or privately, I'm paul at fluidkeys dot com.

I hear this sort of thing so often, the probability of it happening once during spring break (which I presume is several weeks) would be pretty high, if it were me.

A few bits of feedback:

* I was confused by the idea of making a “keyword” (no explainer) and why I then had to “create account” (I thought I already made an account by verifying my email?)

* I love the concept of burner emails and i’m a happy user of 33mail.com for this purpose, particularly because you get [anything]@[someusername].33mail.com. I tend to sign up for things with an email like amazon.com.274652@[myusername].33mail.com

* using my own domain is critical since I can’t be sure how long your service will be around for: if you shut down tomorrow at least all the emails won’t bounce (which could be a nightmare)

* something I don’t currently have a solution for is self-deleting forwarders. I’d like to be able to sign up with eg petition.30d@[whatever] and have it make a forwarded that will self destruct

* your story / background is really important for a service like this: who are you? Where are you based? Why do you care? I couldn’t find this easily

* if you don’t know it already check out Michael Bazzell’s podcast on inteltechniques.com. I wouldn’t have tried 33mail or MySudo without his thorough background research

Thanks for working on stuff like this!

Thanks for the excellent discussion last time we posted here - this release is based entirely on people's feedback :)

If you're curious where we going next with Fluidkeys we've put together a preview site that spells out the vision:

https://www.fluidkeys.com/fluidkeys-v1-preview

Keen to hear your thoughts :)

Thanks for pushing back on this.

> We (and everyone else I know that uses Keybase) use it for passing around sensitive information, either through chat, their encrypted Git repos, encrypted messages plopped into emails, etc.

That is interesting. I'm gonna put my hand up and admit I haven't done my homework here. It's been a while since I used it properly and I've relied too heavily on their website:

> Keybase is for anyone. Imagine a Slack for the whole world, except end-to-end encrypted across all your devices. Or a Team Dropbox where the server can't leak your files or be hacked.

> I think Fluidkeys is cool and all, but I definitely wouldn't switch off of Keybase for it,

Thanks, and I wouldn't expect you to have to switch. We're gonna think properly about where we're competing. I appreciate your input.

That's a thoughtful analysis, thanks. I appreciate the lack of sugar coating :)

That's cool, and I'm going to give it a go: thanks for raising it.

> The two endpoints are identified by using identical "wormhole codes": in general, the sending machine generates and displays the code, which must then be typed into the receiving machine. > The codes are short and human-pronounceable, using a phonetically-distinct wordlist. The receiving side offers tab-completion on the codewords, so usually only a few characters must be typed. Wormhole codes are single-use and do not need to be memorized.

I love that they've put some thought into usability here: that's nice.

Ooh this looks awesome, thanks for sharing.

I can't see Gmail doing it :)

But mostly teams control their own mail domain, so they can do what they like (for example, use Fluidkeys, and we'll do WKD for them!)

Yes! We're working on it, both client side and server side.

We've got WKD working on our own [email protected] email address using a rather cheeky hack[1].

Server side, we're adding this to Fluidkeys Server soon.

That way, teams that use Fluidkeys could redirect `<team-domain>/.well-known/openpgpkey/(.*)$` to our server, and voila, we'll serve their keys via WKD

[1]: https://github.com/fluidkeys/web-key-directory/

Ha! Yeah. I must admit I've accidentally committed a Github access token before. It was in a `secrets.sh` file which I mistakenly thought was in `.gitignore` and carelessly added to a WIP commit.

Github was amazing, they detected it, saw that it was valid, and revoked the token. Big love.

On private repos: it would be a sad, sad thing if all those half-baked pet projects went away, there's an awful lot of valuable random stuff in public repos.

Thanks!

Yes, we're currently hosting public keys.

> Is a self-hosted version of the same possible?

The honest answer is, we're not sure yet. It's our strong ambition to make Fluidkeys into an honest, you're-the-customer business, and we aren't sure how we'll license the server. Is self-hosting something your team would be willing to pay for? If so, that might help our business model development! :)

> a) Some sort of "paranoid" mode whereby it would show me peer's key (in some form) so that I could, if really wanted, manually verify it.

This is a great idea. In that mode, it could output the key fingerprint and prompt before sending. Would that work for you?

> b) An option to cache peer keys locally. I assume this is done already and that the local cache lookup is given a priority over the registry search. Correct?

Not yet, mostly for simplicity of getting this release shipped. It's currently pretty naive (and I'm not thrilled about it): the key lookup API call is done every time you send a secret. Thinking of fimiliar patterns, perhaps we should take the SSH trust-on-first-use approach, where we record the fingerprint we saw last time, and warn if it changes? That would make it significantly harder for us to subsequently serve you bad keys.

Somewhat related, there was a good discussion about how to deal with multiple key discovery mechanisms (e.g. local cache vs server response) at the latest OpenPGP summit. Prioritising local cache (say, your GnuPG keyring) can be quite scary too, if you downloaded a key from the keyservers and subsequently realised it was a fake (and don't use web-of-trust which, well, enough said).

Thanks for thinking about this and taking the time to share your ideas.

I'm a user but no expert about keybase. As far as I can tell they've pivoted to taking on Slack & friends with zero-knowledge team-chat, but global. Good luck to them!

We're not in a hurry to try and move people off Slack or GnuPG: teams have their existing services (Slack, G-suite) and other workflows like Thunderbird + Enigmail, git signing etc. We think complementing those existing flows is the way to go.

The longer term vision is that your team can sign up to Fluidkeys, download it and it sets up everyone's email client, git, pass etc according to your team's configuration. Then it quietly keeps everyone's keys updated when people join and leave the team. (and we rotate encryption subkeys every month)

Back to today: 0.3's sending secrets feature is a small diversion from that goal, but we hope a useful feature in its own right :)

I'd love your feedback on the vision above!

That's cool!

We were doing similar things ourselves with GPG. But ultimately we'd forget the exact command, or the copy-pasting in then out of Slack was enough of a barrier that we'd basically never bother.

Curious how such a small barrier was a blocker. Our hypothesis is that, if we can make `fk secret send` easier than literally everything else, people will default to it, and it'll be a win for security. We shall see!