Google Hands Over $3M in Bug Bounties as Payouts Soar For New Android Flaws (zdnet.com) 28
Google paid researchers over $3m last year for their contributions to its vulnerability rewards programs. From a ZDNet report: Payouts in 2016 take Google's total payments under its bug bounty schemes to $9m since it started rewarding researchers in 2010. In 2015 it paid researchers $2m, which brought its total then to $6m. It's not uncommon for tech companies to run bug bounties these days, but while many rely on third-party platforms, Google has been responsible for verifying bugs for over six years now. Occasionally, Google expands its program to cover new products, such as Android, and new devices such as OnHub and Nest. Facebook, Microsoft, and most recently Apple are also running their own bug bounties.
Translation (Score:1)
Translation: Android is full of holes, so Google has to recruit an army of underpaid consultants to fix it for them.
Security (Score:3)
Re: (Score:2)
Google's lack of care for security is institutionalized. It is part of their MO.
Yeah, that's why we so often hear about security breaches at Google leaking millions of users' private data.
Oh, wait... that's never happened.
Actually, I was a software and systems security consultant for 15 years before I joined Google. In that time I worked for many fortune 500 companies, financial institutions, even government and military organizations. Based on that experience and on my six years working on security at Google, I'll tell you that Google is better at security than any private company
Re: (Score:2)
Re: (Score:2)
It really depends if you are an H1B or not.
Actually it doesn't matter in the slightest. If you can pass the interview, Google will attempt to hire you. If you're a citizen, that'll be easy. If you're not, it'll be harder, but Google will work through whatever visa options are available.
Re: (Score:2)
The people writing code for Google are third world south asian foreigners with no foundational training in IT. Their "degrees" are equivalent to a community college certificate of completion, not even equivalent to an associates degree. They are trained to bang on keyboards and generate code. They are not engineers; they are code monkeys.
This is a troll, but I'l respond anyway, just because some might find the response interesting.
The majority of Google engineers have masters degrees, the largest portion of them from top tier universities. Not that Google particularly cares about degrees; it's entirely possible (though rare) to get hired as a Google software engineer without any degree at all, assuming you get an employee referral or have something on your resume that convinces the recruiters that you have a shot. Assuming that's the case
Re: (Score:3)
Security is not something that can be tacked on as an afterthought, it has to be designed in from the beginning. If programmers don't worry about security, if managers don't give time in a sprint to do a security check, then your software will have more and more security holes.
This is all true. In Google's Android team, all designs must go through security and privacy reviews before implementation, and all code must be reviewed first by a peer before it can be submitted to the code repository, and then by a security reviewer after completion, on a feature-by-feature basis. Automated security testing and fuzzing tools are also applied, and there is a dedicated attack team that is focused on trying to (a) find vulnerabilities and (b) systematize architectural and procedural counter
Re: (Score:2)
Re: (Score:2)
So then......what sort of bugs are getting by these 'conscientious developers'
Various; check the CVEs.
(I'm seriously doubting that tbh, I've seen a lot of crap in Android osp.
For example? If you find something that's exploitable you can get paid for it, you know.
But it's good at least at a management level you are pushing these things)? It is true that Android is big, but that's not an excuse for insecurity, because there are a lot of people working on it, also.
Increasing the number people working on a project doesn't decrease security bugs, it increases them. Some security bugs arise due to simple developer mistakes, reviews can catch those and more staff helps there. But many other security bugs are ultimately the result of miscommunication, and the opportunities for that increase as the number of people working on a project increases.
In addition, an
Re: (Score:2)
For example? If you find something that's exploitable you can get paid for it, you know.
There's one bug that gives a warning if you compile it. Because it hasn't been fixed, I know crappy Android developers aren't even checking their warnings. More generally, I get annoyed at all the giant refactors for no particularly good reason.
But many other security bugs are ultimately the result of miscommunication, and the opportunities for that increase as the number of people working on a project increases.
Sounds like Google has improperly partitioned developers into silos. Oh yeah, that brings up another problem I have with Android: in some places, the documentation sucks and the metaphors aren't well-thought out. Which of course, leads to more refactoring when things
Re: (Score:2)
For example? If you find something that's exploitable you can get paid for it, you know.
There's one bug that gives a warning if you compile it.
There are a few warnings, but none that represent actual problems, AFAIK. Point me to the on you're mentioning?
Because it hasn't been fixed, I know crappy Android developers aren't even checking their warnings. More generally, I get annoyed at all the giant refactors for no particularly good reason.
You're surmising there isn't a good reason, but you don't know.
But many other security bugs are ultimately the result of miscommunication, and the opportunities for that increase as the number of people working on a project increases.
Sounds like Google has improperly partitioned developers into silos.
Not any more than is unavoidable.
Oh yeah, that brings up another problem I have with Android: in some places, the documentation sucks and the metaphors aren't well-thought out. Which of course, leads to more refactoring when things get uncomfortable.
I can't respond to this without more detail. But... of course. Like all software (and perhaps more than some), Android grows organically and stuff that seemed to be a good idea turns out not to be.
Oh yeah, and the build process starts with a giant 'find' command. What a joke.
Yeah, the build system is terrible. It's especially bad when compared with the system used by the rest of Go
Re: (Score:2)
1) For as long as I've followed Android, Googlers have said, "Android is really big! You have no idea how to handle such bigness!" Which is frankly, ignorant. Android isn't the biggest project out there, not particularly complex (which goes to show it's not entirely po
I wonder... (Score:2)
Do they dock the salaries of the programmers who made those bugs?
"Hey you just made us pay out a $5000 bug bounty!"
And if not.. how long before Google and other tech companies DO?
Re: (Score:3)
This is a good thing... (Score:1)