1,101 karma · joined October 6, 2010
FWIW, the average amount is sort of meaningless: we pay between $3k and $20k for high-impact bugs.
There are also some researchers who prefer quantity over quality, and go after low-hanging fruit in acquisitions and isolated, non-sensitive services - often using custom automated tools. These findings usually pay around $100, skewing the total.
We welcome all reports of security vulnerabilities, we try to fix them quickly, and we credit the researchers - but we offer rewards only for higher-impact flaws. You can check out this page for more info:
http://www.google.com/about/appsecurity/reward-program/
In this context, phishing issues are tricky. Because many of our products simply have to do things such as displaying snippets of potentially attacker-controlled text and multimedia, we try to evaluate phishing concerns on a case-by-case basis. In essence, we ask ourselves how easy it would be to exploit a particular behavior to mount a convincing attack.
My take on this bug is that the attack vector is severely constrained in well-behaved e-mail clients; and that in badly-behaved clients, the existing exposure is already considerably worse than any incremental hazard caused by this flaw. It's valid and worth fixing - but does not quite meet the bar for the reward tiers set up for higher-impact bugs.
I am one of the co-founders of the Vulnerability Reward Program at Google. It's one of the longest-running and most generous programs of this kind: since 2010, we have paid out around $1M in rewards for more than 1,500 qualifying bug reports in web applications alone. We take great pride in keeping the process responsive, friendly, and hassle-free.
Of course, it takes just one bad experience to undo much of that. Tom's report is a valid issue. The reward panel - of which I am a member - decided that it did not meet the bar for a financial reward. I stand by this decision, but I think we should have been more forthcoming, precise, and responsive when communicating that. In other words, I think we messed up.
PS. If you ever run into any problems of this type - or just want a friendly soul to chat - please do not hesitate to poke me at lcamtuf@google.com :-)
For example, we don't want physical security or the police second-guessing the intent of someone trying to sneak into one of our buildings - so we set a very clear scope for the program, pragmatically focusing on our user-facing applications and excluding things such as attacks on our facilities and corporate infrastructure. It's a broad exclusion, but it's hard to come up with something finer-grained yet clear enough.
In the same vein, we ask researches that they don't go after any systems unless it's perfectly clear that the application is owned and operated by us - for example, because it's in an IP range registered to us. Again, while this may be more limiting than we'd like, it protects the community against overly litigious parties if the system proves to belong to somebody else.
In several unusually serious cases, we have made case-by-case exceptions and have paid external researchers for nominally non-qualifying bugs; but it's a tricky balance, and we use this power very cautiously.
Source: I authored a good chunk of the current rules for Google VRP ;-)
http://lcamtuf.blogspot.com/2012/06/this-page-is-now-certifi...
1) The improvements in the output of FDM printers is in good part due to switching to lower-strength materials (e.g., ABS -> PLA). It's great news if you want to make casting molds - but not so great if you want to directly fabricate durable parts.
2) There is no gradual progression from the familiar FDM extruders to SLS, SLA, and similar technologies that produce high-accuracy parts or can work in metals. These technologies are inherently messy and have other surprising trade-offs, and are suited chiefly for very dedicated hobbyists and for quasi-industrial applications.
1) The culture of knowledge- and-design sharing has been prevalent in the DIY community for decades, but hasn't produced anything comparably grand. This is despite the fact that we can already easily source or make custom parts of all sorts. Will this suddenly change? Who knows.
2) There is extremely little emphasis on materials science and mechanical engineering in the 3D printing community at this point - which makes it difficult to reach a "critical mass" of good, practical CAD models to reuse (there's plenty of Yoda figurines to choose from, though). The success of the open source community owes a lot to the broad availability of high-quality reference materials and the self-documenting nature of most of the existing code.
3) The dominant FDM approach produces inherently crappy parts, which makes it poorly suited for direct manufacturing. There is no clear path to fixing it. The alternative technologies work better, but aren't as simple to operate. Of course, better approaches will eventually arrive at some point - but would require major breakthroughs, not incremental tweaks.
4) There is very little "portability" of designs not only across printing technologies, but even between individual printers - which again, is an interesting handicap.
http://www.rolanddga.com/products/milling/imodela/