HN user

umbrae

95 karma
Posts2
Comments29
View on HN

Good questions.

- In the past month and a half or so since we’ve launched, about 20% of published profiles have had a reveal request. That varies heavily based on profile quality, some have gotten 4 in a row.

That said, even though it’ll be pretty low volume it should be very high signal. Our accept rate is around 70% right now. This is primarily because people have to pay outright to contact you (excepting the first free one), so only folks with pretty good matches should be reaching out.

- Tech only right now and also heavily biased towards US, probably 95% US. Startups and Agencies have been the primary target and market. You’re less likely to find a Facebook on Limbo and more likely to find a small team that is a pretty precise match for you. There are a couple larger companies on there though, like Mozilla.

I am certainly biased, but I built a job platform because I felt all the existing job boards were lacking, called Limbo.

https://www.limbo.io

The long and short of the problem is that great folks are often employed and finding your next ideal role is too time consuming and emotionally taxing, and that great folks with diverse backgrounds are unfairly discriminated against at resume review time. Limbo attempts to solve those problems with an anonymous job platform.

More on the concepts behind it here: https://medium.com/@chrisdary/introducing-limbo-ddb97a67ff63

Elon Musk AMA 12 years ago

Was that mentioned anywhere in the AMA? I can't seem to find a thing on that.

This is correct, I'm the creator of jsonlint. It actually uses zaach's implementation of jsonlint in JS, now.

Fun fact: jsonlint uses an html5 cache manifest, and can be used even while offline.

They aren't calling our servers. And that was a European backbone (Tiscali) having trouble - if you're in the EU or small fractions of the east coast you may have seen that hiccup. Unrelated to our servers.

Yeah, sorry about that guys. We've had about 2 hours of downtime in the past three months, both network related issues at Slicehost - pretty aggravating, but otherwise they've been great.

jcnnghm, you should check out Kindling. (Disclaimer, I'm the founder - but I still find this problem very interesting.)

What we've done is provided each user with a set number of votes - by default 10 per room - and each user can put as many votes into one idea as they'd like. This forces them to make hard choices about which ideas are the most valuable to them.

This economy of votes has worked out surprisingly well for us in practice, and people become very thoughtful about how many votes they want to expend on an idea. I'd be curious your thoughts.

Couple this with the fact that many professionals don't even have speakers on their machines and can't use headphones at work and you've got a real problem.

(a) I wrote in haste. Obviously it's a one way hash and unreversible. Additionally, I meant the first 20 characters, which is half of the full hash.

(b) Obviously. Still extraordinarily difficult given this implementation IMO. But I take your point genuinely.

(c) Agreed.

If you weren't so friggin inflammatory I'd think we could come to a conclusion here. I could definitely be using a more lossy visualization to be more secure. This is something I'll look into, even though I'm sure you'll still consider it 'retarded' even if it helps your grandma login to her googles more often, making you get less phone calls to fix it as a result. She's got that palsy you know.

Well, as the author, I feel I better defend myself here.

A: It only uses the first 20 bytes of the hash. You could narrow it down from this if you were really determined, but you'd not be able to reverse it.

B: The visualization of the sparkline doesn't have the fidelity to determine between characters 6 and 7. So you'd have a range of possible characters.

C: The alternative being suggested by Jakob Nielsen is no masking at all ( http://www.useit.com/alertbox/passwords.html ) - which is less secure? I know this isn't the best argument, but it still is -an- argument.

With that out of the way, my paranoid mind agrees with you in this context: just masking the passwords is the more secure solution. But that doesn't mean that experiments to provide a more usable approach with (arguably) equal security should be avoided.

This is a good thought - I had implemented character set matching (uppers to uppers, numbers, etc) before, but I worried that it made it almost too hard to read for the user.

You'll notice that I'm only using lowercase letters currently - that was an intentional choice as it seemed too obscured when using a fuller character set.

I'll give this another look though and see if there may be a good middle ground.

I don't agree, from the blog it makes it sound like it really became an arms race - he was more interested in 'winning' than in serving his users.

Once he was outed, he realized what he'd done and came to his senses.

So what's the best way to migrate a site that's using sha1 without salts to one that does use salts?

I expect it involves checking users' passwords two different ways (with salt, without) for the foreseeable future.

For a less TOS breaking solution, you could set up a dropbox client on your server and let it refresh your web content automatically. You're hosting it yourself, but you still get the benefit of no file transferring necessary.

I went to a Fog Creek open house year before last with this pay-scale transparency in mind (Joel had talked about it in an article about 6 months beforehand) and nobody I spoke to had any idea what I was talking about.

It was pretty disappointing.