Rami114's comments

I can't believe people still read that stuff I wrote :o

Is the second problem domain web perhaps? So people can learn that <script> tags can not be self-closing, and so they won't break the JS includes so bootstrap.min.js doesn't load and their burger menu in mobile-view actually works!

Hint-hint-nudge-nudge

/endOCDpost

Judging from http://hillbrad.typepad.com/blog/2014/02/trusted-proxies-and... it looks like opportunistic encryption is not meant to convey security, but rather add obscurity to in-transit plain-text traffic from the perspective of any in-between listeners (and he has no qualms pointing the finger at governments there).

Sadly he now seems to have changed his mind about the validity of this approach, mostly because users and devs alike dislike complexity in their decision process as to what is secure and what is merely obscured.

Crazy, we're used to probation periods here with a short notice time, that protects both sides. I assume you have to negotiate any notice period for being fired, or do you simply get no statutory notice period?

Don't stop, thanks to the two public programs you've run so far I've:

* Got into Ruby and Go (trying to get a feel for what language felt most comfortable for bit manip.)

* Got into assembly (for fun so far)

* Got a good appreciation for bit-level operations

* A bazillion more little facts and insights that help in daily work life

I bet if you polled how it's helped other people there'd be all kinds of great examples. For work, I'd say the best impact has been a personal drive to pentest our own product, resulting in a lot of bugs found and fixed. That included managing to root our servers via a product flaw, which was scary and amazingly fun.

So yeah, thumbs up, don't stop now (please).

As for the above catering to newcomers, sure but it ramps up incredibly and pushes some boundaries if you've never touched that stuff before.

What kind of experience does the average applicant have? As a 27 year old dev the process you've described sounds as terrifying as it does exciting.

For instance on the challenges I liked that you put (largely paraphrased here) 'If you breeze through these we might want to talk to you.'. Having ploughed/struggledto set 5 now it's almost daunting to think people DO breeze through that. Granted, the stats you've published so far indicate those people are far and few between. It kind of puts you in your place, but the exciting part comes from knowing there's so damn much to learn still.

Agreed, unless you have some extremely appealing concept going you're not going to get interest with below-market salary offers even with average equity offering. I'd put it more brusquely: "You pay peanuts, you get monkeys".

When we have jobs - infrequently mind you - at slightly below-market salary we always offered a phased increase to slightly-above market salary over the 6 month trial period.

That being said, I'm seeing a lot of mentions of single week or single month trials. Is this a US trend? Across the pond here, in the UK, I've certainly not seen them.

If you need to ask why it is bad to route traffic through an untrusted third party over HTTP, for the love of god stop building web applications. This is not the right tool for the problem it's trying to solve.

I used to think I was ok at it but then:

* I've never beaten my dad in a game in 20 years * I took up the offer from a guy in a NY park and got my ass royally whooped (not to mention the 20 dollars heh)

The previous reply wasn't to hack on your comment, just wanted to make that clear.

It seems to me a lot of people want totally secure email... in a pretty box handed to them. I don't see how you can achieve end to end security while relying on a middleman. Even if you control the middleman, it shouldn't be able to tell anything about your message (it has no reason to, so it shouldn't).

So you have to do the work yourself. Making that easier to do would be great as long as it doesn't add obscurity to the process.

Tl;dr I don't see totally secure email services provided by an external entity as a feasible thing.

Or, you're going to use something rock solid to encrypt your message and use some sensible approach to obscure your signals.

Not an expert here, but if you don't want to give out signals by the mere fact that you're sending an email with encrypted content, set something up to send encrypted messages regularly, at scheduled intervals, and allow a real message drop in on the queue. As long as your encryption method reveals nothing about the cleartext you can put something in the cleartext to notify your recipient this one is real. I say this in the hope nobody who needs these things for life and death situations will look at HN for advice.

> no system can ever be secure as long as the host has some way of intercepting messages.

Erm, that's only the case for systems that use cleartext in transit. If you encrypt and decrypt (and we assume you're doing it right) at the endpoints then the intermediate can't do anything with the content.

Your 'no matter how' bit is correct, and it was flawed to rely on SSL for transit only and hope the law would protect the keys. Hence tqbf's point that using cleartext in-out is just plain bad to begin with.

Can I call nonsense on that? Nothing prevents you from encrypting your actual message and there are plenty of options available to secure transit.

The reason such a platform may not yet exist is that it security is HARD (or cumbersome, or both).

Not having had a need for this kind of secure email I didn't hear much of Lavabit until it went under. That being said, didn't it raise alarm bells with any of its users when the security model is essentially a black box (as Moxie points out) and the message in transit is only secured using SSL (turned out to be suboptimal there too).

What's the demographic for people who actually needed this service, and why didn't they spot those glaring errors earlier? Is it for lack of other services?

Just seems strange to me it took someone experienced like Moxie to be the first to finger this (and that's in hindsight).

So the moral is: tailor your CV to the type of corporation you're applying to?

Agreed on giving them a break in the end. I do tell them straight on that fluffing skills isn't a good idea as it sends the wrong message. We do have a technical component and group discussion stage to try and coax out the talent.

It's amazing how some people completely fumble the interview and sometimes even technical component, yet convince people in the group chats.

That followed up from asking if they knew what Bash was. Is it wrong to expect them to know it's the shell and it's generally the default? I suppose my post must make me come across rather horrid, but I'm generally quite nice in interviews! :) It's not about looking stupid, I gladly take 'I don't know' or 'good question, I want to look that up' as an answer. It's embarrassing for everyone to ask what are generally easy questions on the topic that was on the CV and get a total blank stare.

Is the extra portability worth it with the Air? I still have a chunky 15" MBP with 16GB RAM (despite supposedly being limited to 8) but it's relatively heavy in the backpack.