> Google refused to pay bounties for valid reports because I was a contributor to libxslt
Huh?
Huh?
The argument is less convincing when the bugs are a couple years old. There could be an exemption for that, but it’s also more work to verify (Git histories can be fabricated).
But doing any of this repeatedly without getting caught seems hard.
I don't think that's how it works. I mean, how many problems did you ever fixed by dictating how others should spend their own money?
Also, apparently some of these issues exist for over a decade. That alone tells you how serious the problem is, and how urgent it needs fixing.
The "serious problem" is that they've known about bugs for 20 years and not committed resources to fix it. The problem is the money.
Who is "they"? Project maintainers? Project users? You?
> The problem is the money.
So this is a project that didn't require any funding for decades in order to exist. Explain exactly why you believe money is an issue.
Even still, you're responding in a thread about someone who is trying to do legitimate work on this project and google is not honoring the bug bounty system.
A problem google could fix if they just assigned someone to manually review the case, it would take like 15 minutes.
Particularly for a dep they've chosen to ship in their browser.
on edit: because obviously you probably become aware of bugs in your own projects before other people do.
Plus, pushing intentionally buggy commits in a way that's subtle enough to be noticed, but not so subtle that it seems intentional (once the bug is revealed to be fixed) doesn't sound like the easiest way to make money. Especially on repeat. Wouldn't this be a little suspicious the third time around?
In cases like this though, if it involves code from before 2005-2010 the author shouldn't matter since people put very little thought into security back then.
Where is the "unfair" in knowing about more bugs to get fixed?
"Fair" (or unfair) isn't a concept which is relevant to this.
Do you have more hot takes?
It is my experience that even much smaller companies than Google would have a Lawyer or multiple lawyers go over the details of how such a program would work.
The lawyers would of course talk to the developers and the project managers and interested parties and define risks. The risk of someone pushing in bugs to then report really seems like a programmer defined risk, but the unfairness thing is a lawyer defined risk. The first you conceive of thinking like a programmer, the second thinking like a lawyer.
But the risk I would assume a lawyer would see is - determining the severity of bugs is somewhat up to the developers and managers at our company, therefore we may encounter a situation in which a person reporting a bug thinks their bug is very severe but we think it is less severe, furthermore there may even be similar bugs in the past that we have paid out large amounts for but in this case we pay out a smaller amount, this will create an appearance of unfairness. The people pursuing the bug bounty have put in work to get the money, we of course will structure our contracts about bug bounty work etc. so that they cannot expect the process to be fair and that this is not a form of employment therefore the payout is not guaranteed, but that only goes so far, and if things look unfair then the shield our contracts offer may be blown apart.
The ability of someone to work on a project, and find bugs in that project quicker than other people gives them an advantage in reporting bugs therefore they need to invest less time to get a potential reward, they can report more bugs quicker etc.
Depending on jurisdiction, and we cover the damn world, this might be a problem because hey can someone who is not part of a project able to sue someone who is part of a problem somewhere because that person got more payoffs based on their access to the codebase of a project. Can our communications be requested to see if we evaluated things in any way unfairly?
What about if we have people on the same project as the guy that is reporting bugs for that project, can it be argued that we favor someone we "potentially" work with? This is another aspect of unfairness. Will they be able to sue and get access to communications regarding bug bounties in any case regarding unfairness - will our contract hold up against this?
For safety's sake let's just disallow these potential pieces of unfairness in the rules of the bug bounty, thus keeping from having any conflict of interest. Oh the developers said maybe someone could put in bugs in projects and then report it, seems legit also good reason we don't allow it. But yes, seems like a nasty can of worms all over, let's not open it.
The point of worrying about the unfairness is not that one thinks even that one would lose the case, but to avoid the case altogether, To have a contract that says essentially you can't do anything about it because we don't have to be fair, but then also remove anything that might look unfair.