ntucker

Agree with other commenter. Stellar landing page, and this seems like a good business idea. Best of luck.

This looks fantastic. I played with spleeter, but the UX was a bit raw. Will give this a try. Note to self: more RAM.

I have two recreational programming projects active now.

The first is a deterministic password generator [1] which is designed to be easy to use and manage. I've been using it myself for a couple months and have a couple UX improvements in my head that need to be done before I'd recommend it to anyone else. [1] https://bitbucket.org/nealtucker/whose/

The second is an infrastructure project which my brother and I are building as an opportunity for him to learn about automated infrastructure and security. Terraform starts by instantiating an automated private CA for the purpose of securely issuing certificates to all instances, and then all other instances come up with an agent that generates keys and calls the CA (along with a signed auth blob provided by the terraform run) to obtain certs. Nomad server also comes up, using the same certs, and controls all the other nodes. All communication is MTLS from the start and I'm in the process of adding ssh hostkey signing to the CA so at the same time the instances get certs, they get their hostkeys signed so we don't have to TOFU the ssh hostkeys. We have no idea what we'll do with it, but it's fun to build and teaching both of us a lot.

I love this kind of stuff. The fact that we (people in our field; not me specifically) had to and could do stuff like this must seem crazy ancient to the younger folks here. I did boot my first computer from a cassette tape, and I can still remember what it sounded like and it's so, so very nostalgic. And many of us did get our first internet access via these crazy noises as well. I'm sure I could also listen to a modem connecting and tell you what speed it had negotiated from 1200baud all the way up to 56k, since each new sound was, at one point, the pinnacle of excitement since I'd just upgraded to something new (and then I heard it thousands of times).

So write the license this way. I think it's a fabulous idea.

This is a great observation about the home inspector being more likely to give you an impartial diagnosis. There's an old guy who's a semi-retired home inspector down the block from me and it makes me think I should hire him for consultation when thinking about big projects.

The original goal of PDF was to create documents that could "view and print anywhere" (literally the original tagline of the Acrobat project), substantially the same as how the document creator intended them. What Adobe was trying to solve was the problem of sending someone a document that looked a particular way and when they rendered it on their printer or display, it looked different, e.g. having a different number of pages because subtle font differences caused word-wrapping to change the number of lines and thus the page flow. It wasn't about it being "pretty," it was about having functional differences due to local rendering and font availability. In this regard, the format is an emphatic success.

I do wish they had focused a bit more on non-visual aspects such as screen-reader data, but to say the whole point is "because it's pretty" is a bit uncharitable. The format doesn't solve the problem you wish it solved, but it does solve a problem other than making things "pretty."

> I do trust the team of 1Password to be competent and not evil, but there are many things that can go wrong anyway.

Very much this. I don't benefit in any way from having a copy of my sensitive data in their cloud, so as a very basic security principle, I don't want them to have it.

And that's just for my personal use. If they drop support for local vaults, I have to stop using it for work, too, because my employer prohibits password managers that store passwords in the cloud. My understanding is that these policies are specifically designed to keep us in compliance for government contracts, so I don't think they're changing.

Please tell me local support is coming. I'm a longtime 1Password user who only uses local vaults and I feel like 1Password is increasingly showing me they aren't interested in me as a customer.

Paywall didn't let me read it, but as I clicked, I thought "this article should be one sentence about doing backups."

I wouldn't go so far as to say "the real crime," but I wholeheartedly agree that zoom should share some responsibility here. If we're going to routinely put children in a virtual space, that virtual space should be able to be secured for them. If an after-school children's program put children in a position where, say, sexual predators easily had access to them, we'd not only blame the sexual predators, but also the system that put the kids within reach to them.

I've always been very surprised zoom has an easily-guessable meeting ID namespace. It's a user experience tradeoff, but in my opinion, either the meeting IDs should be sparse and hard to guess, or there should be passwords (or possibly both).

For what it's worth, I knew immediately what this was for but read your entire page looking for some kind of explicit confirmation and/or clear description of the use cases. The info given almost seems intentionally coy, as if you're even trying to maintain plausible deniability on the website.

I think anyone who's used a lawnmower knows the concept but not necessarily the name.

I want photoshop about once a year and I am literally still using photoshop 6 on windows. It's over 20 years old. Works fine, installs in about 5 seconds.

Yes, but attached much more solidly than a traditional one. They slide onto the pegs and stay put perfectly without any sort of adhesive and are actually tricky to remove due to the precision with which they snap in.

I effectively have an "all-on-4" situation but where the 4 are my natural teeth. I have a genetic condition which caused very few of my adult teeth to grow, so the ones that did grow in nice and solid have been capped with machined gold cylinders and used as the receivers for a full denture (google "telescopic copings"), which fits perfectly on them and also acts as a retainer for those teeth. It's actually quite nice and comfortable and my teeth went from being a painful horror show to functional and trouble-free in a relatively short timeframe.

My point is that you don't have to do the encryption on the device. You can send/store encrypted data via compromised devices and channels.

Also of interest is the fact that they settled on using a multi-host NIC to share a single NIC between four single-CPU servers.

The really interesting thing about point 1 is that with encryption, there's really extremely little personal risk to being unlawful when it comes to encryption. That's why this is a losing game of chess for them. Encryption is just math, and you don't need anybody's permission to do math. You can take a system that the government has mandated be broken and you can do good encryption inside that system by layering it. And good people who simply want to be safe will do this. And so will terrorists. Outlaw good encryption and a whole sub-industry of deniable encryption tools will emerge. And they will have achieved nothing except that our companies won't be allowed to officially support strong encryption, so they'll be disadvantaged in the marketplace. It's a really backwards move.

Since the spread between the strike price and the current market value gets a tax treatment like income, it can pay off to exercise options early if you want to hold the stock and are confident the price is going to go up. He just paid $3.5M for stock that is worth $102M, so he's got to pay taxes on about $98M of something income-ish.* If hypothetically he waited and the stock doubled, he'd have to pay tax on a much larger spread.

* I say something income-ish because whether it's actually called income depends on the option type and AMT complexities that I can't really rattle off off the top of my head, but suffice it to say the spread is taxed in a very income-like way.

In addition to the general principle that your government shouldn't be collecting dirt on its constituents, there's also the very real possibility that back doors will eventually be exploited by bad guys and reduce everyone's security.

Even if you think you don't have anything to hide from the government, you probably have plenty of stuff you want to hide from criminals.

I think it's reasonable to be somewhat outraged due to the fact that there are actually very few end-users who would have had the skills to prove the metering problems. This guy was advanced enough to be gathering traffic statistics at the modem (way beyond 99.9% of users already) and he still got told the measurements were "probably" legit. He didn't get any consideration until, knowing full well that their numbers were off, he unplugged his LAN for an entire week to prove it.

If we're going to give them a pass on accidental billing, you can't make correcting the problem this user-hostile.

You guys might want to see if you can do a better job of publicizing the LastPass import. I googled for it and found some of your support forum threads where users had contributed scripts to do it, and I thought that was a bit iffy, so I resolved to deal with it later. I then saw another comment here that clued me in to the fact that LastPass has an 'export' feature that you guys can import from. 60 seconds later, it was done.

I'm sure you're getting a lot of new users today. Good luck! :)

See my other comment in this subthread about my own version of the deterministic password generator concept. It allows passwords to have site-specific rules for how they're generated and also allows rotating individual site passwords.

I've been using something similar of my own making, and I've been meaning to clean it up and publish it at some point. Since I have enough side projects going that I have no idea when that will be, I'll share a couple features of mine that I think make it unique and which I think should be incorporated into the others.

The general concept I stole from somewhere else -- you've got a stored list of sites and when you type your master password in a field, each site in the list then gets a "copy password" button based on the site name + master password. But this isn't quite flexible enough for general use, so I added some features:

First, each site has a 'version' field which becomes just another piece of data input to the hash. This makes it so you can rotate passwords on a particular site without changing your master password: increment this number and you get a whole new password.

Second, each site has a password 'scheme' which allows for disparate password requirements on different sites. The underlying generation algorithm is the same, but rather than converting the hash output to a base64 number and using it directly, the hash output is used to deterministically select characters based on the rule set. Roughly, each scheme has an arbitrary number of character "classes" that may be included (e.g. "numbers", "letters", and "symbols") and each scheme may specify a minimum number of characters from each class (a typical rule being that that min=1 for numbers and symbols). So the class-specific minimums are satisfied, then the rest of the characters are selected from all classes equally, then a few more bytes of hash are consumed to deterministically change the order of the selected chars (otherwise you'd always end up with your minimum two special characters at the front, for example, which technically weakens the password). Each site also can have a distinct password length setting. Currently I only have three or four different "schemes" defined and haven't had the need to add one in a while so they're all hardcoded, but one could easily imagine having a "password scheme editor" which lets you define new ones with a few primitive rule types.

And third, each site has a "last changed" date which helps me keep on top of which site passwords haven't been rotated in a while. If you change your master password every time you need to roll one site's password, this probably isn't an issue for you, but I definitely prefer to avoid the ritual of changing passwords on every site I use at once.

My impetus for all the password scheme complexity is that I found that more straightforward password generators simply don't work on all sites, and I hated having exceptions. The site where I pay my electric bill, for example, doesn't allow exclamation points in passwords, and they must be between 6 and 8 characters. Lame to be sure, but I really have no choice but to go along, so my password generator must too.

All that said about my password generator, I think this is a fundamentally different approach to the problem and I think the cbcrypt approach is ultimately more interesting if we can get it incorporated into browsers. I've long thought we should expose some sort of modified SSH-agent functionality to the browser JS API so sites could do public key auth for login (with the appropriate user prompting, of course -- just allowing websites unfettered access to your SSH agent would obviously be a terrible idea).

I'm not the person you're asking, but in our system, our secret access is tied to an SSH identity, not an SSH agent. This means that you have flexibility to require a personal user's ssh agent to be present for access to some things, or an identity file (optionally encrypted) stored on the server for less-sensitive things. In the case of things that need to happen unattended, we use an in-the-clear identity file, which might seem a little counterintuitive since security-wise, it's basically equivalent to just having the secret sitting there, but the indirection adds ease of rotating secrets along with revocability if we were to suspect we lost control of such a machine. But for most of our secrets, we tie them to individual user's identities which must be forwarded via an agent. We consider this an acceptable constraint because deployment and app restarts are always driven by a human in our operations.

It's not a perfect system or a panacea, but it's far better than having a bunch of passwords directly stored in config files, in my opinion. We also have a wrapper tool that uses your SSH agent access to fetch secrets for the mysql suite of tools as needed, so nobody is ever tempted to create a personal .my.cnf on prod servers. Anybody who actually has access to a given mysql password is still on the honor system not to fetch it and write it down somewhere, but removing the need to ever even see them eliminates the temptation to put it in a .my.cnf or in your clipboard, which eliminates a whole class of mistakes you can make in handling them.

This is similar to what we do at my company. I wrote about it a bit here: https://news.ycombinator.com/item?id=8826300

Would be interesting to hear more details of yours for comparison.

The recommendation is to make it as slow as you can tolerate, which is based on how fast your web servers are.

So after a breach, you have our (currently) 2 million hashes, and let's say you recover only the weakest few percent of the passwords, which is 60000 known good passwords. Instead of owning 60000 accounts now, you have 60000 passwords, each of which is going to require on average one million attempts before you guess the correct username. Is this not self-evidently better?

Hmm, interesting suggestion. We wouldn't want to encrypt the entire row since we want to be able to query on specific columns (version in particular). My only excuse otherwise is that the goal was "disassociate the hashes from the users" not "encrypt the hashes." :) You're right that we could have done more, although whether that makes meeting the original goal a "half measure" depends on your perspective. :)