81–89 of 89 posts
Earlier quoted context omitted.
That covers the 3 million phones a year that Google sells what about the other 1.2 billion plus? https://www.forbes.com/sites/chuckjones/2018/03/10/apples-io...
If you are worried about Google's security practices, why look at things other than Google's products?
No one would say that if you want a PC that is secure, buy a Microsoft Surface.
Earlier quoted context omitted.
What's worse that thousands of pieces of throwaway hardware that don't get updates? How about thousands of enterprise systems where the security updates are hidden behind support contacts? > when I push out improvements No, if your software has a security issue, it's refundable. Write good software. > release a new model every month with ANY improvement Good, but that doesn't remove your liability from your last mode…
>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 cycl…
Earlier quoted context omitted.
>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 cycl…
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.
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.
Earlier quoted context omitted.
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.
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.
Not even close, you are liable for keeping the data you collect as a data processor or controller safe.
Earlier quoted context omitted.
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.
> 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.
Which again, is nothing like "write bug free code or you're liable".
Earlier quoted context omitted.
> 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.
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".
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.
Earlier quoted context omitted.
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".
> 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.
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?
Earlier quoted context omitted.
> 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.
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?
Anyone who doesn't make an effort to update. If your hardware is still Heartbleed fucked and you're selling it, you deserve to lose money.
> Meltdown
Intel and AMD.
> Who gets sued
Noone. Here's your product back, it's defective, please cut me a check, that's all.
Earlier quoted context omitted.
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?
> Heartbleed Anyone who doesn't make an effort to update. If your hardware is still Heartbleed fucked and you're selling it, you deserve to lose money. > Meltdown Intel and AMD. > Who gets sued Noone. Here's your product back, it's defective, please cut me a check, that's all.