Hacker News new | ask | show | jobs
by joshuamorton 2682 days ago
>No, if your software has a security issue, it's refundable. Write good software.

There are 0 companies that can provide consumer software on the lifecycle consumers have come to expect without any bugs. You write software. Are you willing to claim that you can just "write good software" and never ship anything with a security issues?

Because otherwise you're advocating for consumer tools that use nasa's release cycle. Which like, that's cool and all but I don't want to rely on hardware from 2012 or 2005 running software that was developed from 2010-2014 and has just finished its verification process. You're advocating for a world where we just got the verifiably bug-free Nokia 3310.

And that doesn't even begin to discuss the clusterfuck that would be open-source in this situation. Am I liable for heartbleed because I use OpenSSL? Are the openSSL devs?
1 comments
WrtCdEvrydy 2682 days ago
Same bullshit argument was made about GDPR and we survived that... there's just too much money to be made by outsourcing your shitty code's security bugs onto the customer.
link
joshuamorton 2682 days ago
Those aren't the same though.

GDPR is basically "you are liable if you are actively exploited and data is stolen". You're saying that a company is liable if they ship bugs, which the GDPR absolutely doesn't care about.

link
WrtCdEvrydy 2681 days ago
> you are actively exploited and data is stolen

Not even close, you are liable for keeping the data you collect as a data processor or controller safe.

link
joshuamorton 2681 days ago
And "encrypt data at rest" is most of what you need to do to comply with the GDPRs data security stuff.

Which again, is nothing like "write bug free code or you're liable".

link
WrtCdEvrydy 2681 days ago
> encrypt data at rest

What? No, you have to have a DPO, provide clear language on what you do with data, who it's shared with and no intrusive prompts having opt-in by default just to have a few.

link
joshuamorton 2681 days ago
None of those things have to do with the actual security of your code/data storage. They're procedural.

The GDPR focuses on procedural liabilities. You're asking for application level liabilities, which like I've said 3 times now, are a whole different ballgame.

Since you're so deadset on this, I'll just ask again: Who is liable for Heartbleed or for Meltdown? Who gets sued, and for how much, and why?

link