4 ms·

|This should have been caught at a security review stage during design, it should have been caught at the code review stage, it should have been caught by autom

|This should have been caught at a security review stage during design, it should have been caught at the code review stage, it should have been caught by automated tests, it should have been caught by QA, it should have been caught once live by data tests, it should have been seen once live by analysts, it should have been fixed at so many different points.| If the very first people (presumably the "higher ups"/more prestigious designers) in the design process miss such things, it is very hard to call them out in a societal construct that is the business construct that has become Xiaomi and the Chinese Government. It's hard enough in some companies for QA to question software engineers and not catch backlash in the US when making games. Companies like EA, Atari and Nintendo are notorious for it. Apple used to shitcan QA who didn't treat "the talent" nice enough, and they weren't a quasi governmental entity. You're right, of course. But man, that's a big frog in your throat to go up to your manager and say, "Sir, I'm sorry but this whole process has issues. Here's the fix, but it means a redesign of a core process." That's tough. That's double tough.

danpalmer 6y ago
This is something that a company with a mature security posture needs though. Yes it's hard, but that's the point. There are many ways to work around this, having teams whos incentives are tied to finding issues, maybe in a different reporting chain or office or country to those writing the software is one way.
- UnpossibleJim 6y ago
  I think incentivizing and anonymizing issue finding by restructure sound like amazing ideas, to be honest. Having batch issues come in to the devs via bug tracking software and conversations be labeled with a user ID rather than name would make a world of difference; so would basic professionalism. An understanding that it isn't team against team. Sdets (and manual testers) are not adversaries to devs or management... Though, I think a lot of devs realize this but project management/producers have a harder time understanding this. This is where I think a basic understanding of coding and the development pipeline would help a lot. But, here we are. In the real world =/
thw0rted 6y ago
If your design is "accidentally" indistinguishable from intentional state-sponsored surveillance, does it really matter whether you arrived at it through malice or incompetence?

danpalmer 6y ago

This is something that a company with a mature security posture needs though. Yes it's hard, but that's the point. There are many ways to work around this, having teams whos incentives are tied to finding issues, maybe in a different reporting chain or office or country to those writing the software is one way.

UnpossibleJim 6y ago
I think incentivizing and anonymizing issue finding by restructure sound like amazing ideas, to be honest. Having batch issues come in to the devs via bug tracking software and conversations be labeled with a user ID rather than name would make a world of difference; so would basic professionalism. An understanding that it isn't team against team. Sdets (and manual testers) are not adversaries to devs or management... Though, I think a lot of devs realize this but project management/producers have a harder time understanding this. This is where I think a basic understanding of coding and the development pipeline would help a lot. But, here we are. In the real world =/

thw0rted 6y ago

If your design is "accidentally" indistinguishable from intentional state-sponsored surveillance, does it really matter whether you arrived at it through malice or incompetence?