Comment by dmix | Hacker News Reader

Comment by dmix | Hacker News Reader

> Some hires came directly from coding schools that specialize in quick boot-camp-style training courses. One adviser recalls being surprised to learn that some Zume coders had last worked at the porn-and-hookup site Adult FriendFinder, known for a security breach that exposed the data of 412 million users.

I kinda get the bootcamp concerns, but what's wrong with being a programmer at a porn site?

I also highly doubt the problems were with the software team either.

After the robotic delivery truck problem failed, which I think was a critical piece of the puzzle as they were essentially replacing retail pizza stores with mobile robotic food delivery machines. Which is something new - and critically something actually scalable with VC funding.

Instead this ended up requiring a sophisticated infrastructure if it was going to compete with pizza stores on every corner, who already have ovens and drivers close to the last mile customers + these old pizza companies already have central marketing funnels from mobile apps, phone calls, and online orders which then distributed "leads" to the various local franchise locations. So an Uber-style play is pretty pointless.

I'm curious if they should have tried a bit harder to solve the robotic pizza truck problem, so they didn't need to build out a centralized facility or a bunch of smaller delivery shops. Especially on the cusp on automated driving, these could just automatically pick-up food restocks at the central location and stay mobile as long as possible.

I'm convinced too many startups give up too easily as soon as they face hard problems then pivot to boring old-industry style companies that aren't real startups/VC companies. Replacing minimum wage workers with robots will never be exciting by itself.

Pizza chains haven't even displaced the local pizzeria who make a higher quality product. It's inherently a resturaunt business and resturaunt are a terrible proposition.

In SF the chains have terrible quality, but in other places you can actually get pretty good pizza from a chain, if the style you want is in their lineup.

Where I moved from the chain pizza was all pretty good. One day after I moved here I needed something quick and familiar so I ordered the same thing I used to get, and it was awful.

So it comes down to the local management, and in areas where management is sound, the pizza is fine and robots add no value in time or quality.

I read the article as more concerned with the “known for a security breach that exposed the data of 412 million users” part.

Well, 412M learnings for them. I would consider that experience quite valuable.

I’d assume this has also been quite the “learning experience” for softbank, too.

Nothing. I spent 4 years working at the largest ones in San Francisco and it was an amazing experience. =)

I don’t think the issue they worked on adult sites. I think the issue is they worked on AdultFriendFinder, who basically didn’t care about user privacy.

Having previously been in the adult biz it is now considered a black mark on your resume. It was all mostly black hat work at one point or another.

That is a load a bs. If anything, it has been enabling for me. Any business that wouldn't want to hire me based on the incredible scalability experience I gained from working on a super high traffic/revenue project, isn't a company I would want to work for anyway. Nothing I did was black hat.

I was in the business pre-tube. I learned a lot too.

It’s probably very different now but affiliate shaving, spamming, cpc fraud were all ubiquitous in the late 90s/early 2000s.

May 2006 - April 2010

Yes, we had to deal with all of that as well. Also built a lot of automated tools to deal with those sorts of things. My favorite one, I named 'the cockblocker'. ;-) This sort of experience you just can't get elsewhere and has been extremely valuable for me.

That sounds crazy to me. I'd be much more interested in a conversation with a devops engineer from pornhub than one from YouTube.

I was in web hosting, we hosted over 120k sites at our peak. Rent a /21 for a week? No problem. Interesting times for sure.

I still think that's a silly reason not to hire their programmers, unless they played a role in creating weak security.

Security is often a whole company exercise that needs to be prioritized by management, putting blame on some individual programmers seems to show a lack of understanding of how infosec works.

>needs to be prioritized by management

If the attitude of these engineers is "we don't emphasize security unless management tells us to" maybe they don't deserve to be hired elsewhere?

Management are not omniscient; they depend on their staff.

Yeah, that's not how infosec works. You've almost certainly written code that has exposed user information (unless you've written no user-facing code).

Are you, as an engineer, going to organize a pentest for the software? Even if you encourage management to do so, it's still up to management to actually book the deal.

>Are you, as an engineer, going to organize a pentest for the software?

Are you, as an engineer, going to sit back and watch the project you built (containing very personal information in this case) get compromised? Even if you know management isn't paying proper attention?

See, that's the problem with every developer in Silicon Valley calling themselves an "engineer"; they want the title without the obligations that a professional engineer has. "Not my problem" would cost you your designation.

> Are you, [...] going to sit back and watch the project you built get compromised?

How does this work? Do you rip off your glasses, strike a manly pose and run for the data center, stopping only to force the infra team to give you the credentials?

More seriously...

Organize your own IR tiger team outside of management channels? Congrats, you're unemployed tomorrow, together with anyone silly enough to buy in.

Start making rogue code changes you think are appropriate? That would run in to "want[ing] the title without the obligations". Oh, and also probably end up with you unemployed.

So, really, what are you proposing?

> Organize your own IR tiger team outside of management channels?

This gave me a good laugh, thank you

> See, that's the problem with every developer in Silicon Valley calling themselves an "engineer"; they want the title without the obligations that a professional engineer has. "Not my problem" would cost you your designation.

All engineers make mistakes and misjudgements, even the ones working in long-established fields, as we can see from the 737MAX saga. It's management's job to design a organizational structure that puts enough safeguards in place that mistakes get captured before the product rolls out. That's what management literally means.

> Are you, as an engineer, going to sit back and watch the project you built (containing very personal information in this case) get compromised? Even if you know management isn't paying proper attention?

I'm glad I'm not the only one who feels like this.

I nearly got fired by digging my heels in on a privacy/infosec flawed design... until CTO/CIO layer gleaned what I was freaking out about and the energy (angry, "wtf", etc) suddenly pivoted to the original architect and engineers who cooked up some half-baked stuff.

You don't want your name attached to bad stuff in life. You only have one reputation. Don't mis-spend your social (political) capital by letting dummies bully you into ignoring tangible security issues.

At minimum, I'm going to design a user-facing system as correctly as I am able and to the maximal extent of my abilities, because holding data in trust for a user is a profoundly serious responsibility and it wouldn't be right to do otherwise. And, when user-identifying information is involved, every place I've ever worked has had an understanding that that kind of sensitive work will be done when it's done and they can fire my ass if they don't like it. Whether they've been happy about it or not, nobody has ever tried to fight me over it, let alone take me up on the "fire me" bit.

And when it is done, I will endeavor to hit it as absolutely hard as I can to break it. I will advocate for regular penetration tests and audits, and I will throw an absolute goddamned fit when they don't happen. (My current company retains very little personal information and we still put ourselves through a pretty rigorous security audit at least once a year. A measure of "do thou likewise" is fair.)

The fun part is I don't even call myself an "engineer", because I'm not and I can't be with the tools and practices I have at my disposal. I'm a software developer, just like about 99.9% of this industry. I just happen to care a little, and I just happen to try to do better.

The only part that matters is the penetration test bit. And it's out of your control as a rank-and-file engineer.

Those who don't accept this are like doctors who don't accept that washing their hands is the important part, not the care and emotional sensitivity that goes into treating a patient.

That's not true. Testing is reinforcement of that competence and that good design, it does not replace it. Relying on penetration tests to secure your systems has an implicit dependency on the completeness of those tests--and putting armor over the bullet holes isn't how you keep a plane in the air.

A pentest reports findings, and then regardless of how incompetent the programmers are, they are required to fix them. Then a retest happens, which verifies that the findings were fixed.

I've seen a trading application go from "typing ' will result inn SQL injection" to "basically bulletproof" due to this process.

Devs can become remarkably competent when their smugness is wiped away by finding some crucial vulnerabilities they overlooked.

I know it's tempting to believe that the design part matters, but it's also tempting to believe that a doctor's emotional support matters just as much as washing your hands.

Do a stint in the pentest industry. It's eye-opening. (Look into my eyes. I've seen things. Terrible... things...)

The AFF back to back breaches were interesting because there were faults to found at every level.

* The breach included PII from a property they had already sold, but held onto for some reason.

* SHA1. A good choice if you want to slightly inconvenience somebody with a GPU, while also increasing the odds of your hashes getting uploaded in full to one of many distributed cracking projects.

* No effective user input validation. The exploit was one step in sophistication beyond those ancient IIS ../../hue.txt attacks.

* No attempt at anything resembling principles of least privilege, exec whatever wherever.

So, everyone failed - executives to DBAs. Screw pentests, start by implementing best practices that have been around for 40 years.

Reply on news.ycombinator.com