Does it concern you that ultimately the way the OP got your attention is by posting to MZ's account? Are you sure you'd have ever "discovered" it if he hadn't? I agree that the OP didn't do a great job, but if he's submitting a vulnerability that you really want to hear about and you're ignoring him because of some miscommunication and you ding him for doing the one thing that gets your attention, you're creating an environment where you're less likely to find out about these things.
I think there's a spectrum between letting whitehats do anything (including violating privacy, hurting real user accounts, etc) vs. suing everyone who changes a GET param somewhere. Having a whitehat program with (IMO reasonable) guidelines around not impacting unsuspecting real users seems to me like a good balance and is fairly close to the first part of the spectrum.
Obviously I don't love the end outcome, and this would have gone better for all parties if he had used a test account and included some kind of repro instructions (like that video) in the initial report.
>this would have gone better for all parties if he had used a test account and included some kind of repro instructions
Clearly, but that's not really something you can control. From your perspective, the other side of the tradeoff with "hurting real user accounts" is "leaving open a huge security hole", not "being mean to whitehats when they screw up". I don't disagree that the guidelines seem quite reasonable prima facie and perfectly fair to to the whitehat in some moral sense, but it's unclear if they're actually working. It boils down to, if you had to choose between finding out about this security hole the way you did or not find out about it at all, which would you choose? How many not-quite-so-aggressive versions of this guy are out there, and how many holes are you leaving on the table? Edited to add: If an important way of finding vulnerabilities is people breaking the rules, then the rules suck, regardless of their intrinsic fairness.
It could well be that keeping not-great-communicator/guideline-follower whitehats from reporting some number of bugs through questionable means is actually worth those flaws sticking around. Of course I don't see the daily flow of vulnerability reports to FB (or all the ones that don't ever get reported), so I don't know. But it sounds like a harder question than you make it out to be.
Again: how exactly do you propose that they write a policy that compensates people for violating the security of their users? Not the security of Facebook, but the integrity of their actual users.
We all know this person had good intentions. But good intentions aren't always enough. Facebook doesn't appear to be freaking out at him. They just can't pay him for having demonstrated a vulnerability by hacking someone's account.
Firstly, no idea how you can conclude he hacked an account. A bit strong of language there? Second, does reason not come into play here? You don't have to write a policy to compensate people for violating privacy - however if you have a human making decisions, and not just a drone following written orders, then the ability to make compromises exist. Just no one at Facebook wants to engage and be human it seems.
In as much as he posted on another account's timeline without permission, he "hacked" it in the "unauthorized access" sense of hacked.
re: reason; where does his reason come into play? It does not seem reasonable to post to M.Z.'s timeline, I'd guess he did that because he was P.O.ed at being dis'ed by the support people.
In the bureaucratic theory I am aware, if you have rules (policies, proceudres, standards etc.) you need to apply them consistently. Sometimes the rule will allow for discretion, sometimes not. I don't see room for discretion here.
I believe you're comprehending his actions wrongly. He stated before he'd be able to post even onto M.Z.'s timeline, to announce that this isn't a narrow scope issue, and that it was to gain attention. I see no malicious or angered. If of course M.Z. all of a sudden sees some guy, who isn't a friend, posting to his wall - you think he might actually look into it, right?
Yeah, rules that don't take into account reason are inhumane. Similarly why we don't just give everyone 10 years in prison because they committed a crime - you take into account all aspects - and not just apply "oh but he committed a crime, so this is the result."
> Firstly, no idea how you can conclude he hacked an account. A bit strong of language there?
This is like... the textbook definition of a hack.
> however if you have a human making decisions, and not just a drone following written orders, then the ability to make compromises exist. Just no one at Facebook wants to engage and be human it seems.
I love that this statement is downthread of a Facebook engineer's comment that states he considers the guidelines reasonable. It's as if you're just a drone following written orders without the ability to make compromises.
>> Firstly, no idea how you can conclude he hacked an account. A bit strong of language there?
>This is like... the textbook definition of a hack.
Perhaps of "hacking FB", but he didn't "hack an account".
I don't see what the problems are for FB here. They have a moral obligation to reward him for reporting this bug, especially since their ToS are apparently not available in Arabic. Claiming that he showed any sort of malicious/inappropriate behavior is a really bad tactic to save some money when they clearly handled this very badly from the start, while his intentions were obviously good.
All they are achieving by reacting this way (including the apologets) is that next time, such people will just sell their exploits on the blackhat market.
I don't think has anything to do with saving money. It really seems like a case of trying to take human judgment out of the equation. Strict adherence to rules is easy for bean-counters to push but frequently problematic for dealing with real world situations because rules are never perfect.
Facebook really doesn't need to save $10k by not paying this guy. It's about upholding the terms and not setting a precedent.
The blackhat market for Facebook exploits is not huge because the product is centrally controlled and can be patched at any time. It's not like 0-days for products with individual installations that aren't centrally controlled with forced updates - those are clearly valuable.
What incentive does the engineer have to look deeper, and more holistically at the situation? None, especially if he doesn't want to create friction within the company - he can just sit comfortably having followed written protocol. A human with compassion can make compromises, someone following orders can't.
> They just can't pay him for having demonstrated a vulnerability by hacking someone's account.
I don't see why that is. They already provide the following caveat:
> When you are unable to reproduce a bug with a test account, it is acceptable to use a real account, except for automated testing.
So I don't think there's some kind of legal issue there, if that's what you mean. And you could provide other caveats, like, "you can use a real account if no one is listening to you" (I grant that this may not have helped here either).
I'll reiterate what I said above, which is that the policy is fine, as long as everyone recognizes that it has a strong potential to reduce the security of Facebook. And that ought to raise some sort of alarm, right?
"Can't pay him" sounds like bureaucracy BS. I'd argue that it's in their best interest to find a way to pay him. Why make people jump through hoops to report an exploit in your product?
However, it also sounds to me like an opportunity for a bug / exploit reporting proxy business that validates, reproduces, and polishes reports in bulk. You most certainly could extract a much higher bounty per report.
"Can't pay him" doesn't sound like bureaucracy BS, they don't pay him because he violated the TOS, it's on purpose. We could argue this is stupid and the TOS should be changed, but I can understand why they specify that in the process of reporting a bug you use a test account. Violating a real user privacy to report a bug isn't the proper way to report a bug. If they made an exception with this guy then they would have to make more exceptions and possibly set a bad precedent.
I disagree. I don't think that making a case by case assessment is opening the floodgates (that argument is exactly what I would call bureaucracy BS). For an exploit of this severity I would expect them to be grateful to someone who was obviously not being malicious regardless of some silly policy.
Well, we don't need to assess fictional scenarios, we can take a look at what this hacker has achieved.
1) Lots and lots of negative press. (we wouldn't talk about this if this wasn't true)
2) Embarassing the CEO of a company and thereby also hurting the reputation of his company
3) And on top of that he breached his privacy
And you still think that they treated him too harsh by withholding payment?
I mean couldn't he have waited a few more days or reopen the ticket - or maybe just use Facebooks test accounts?
It's not like he waited for ages, he brought this bug to attention last friday.
But yeah, waiting a whole weekend was probably too much for him to take, so he obviously had to post on MZs wall.
It would be great if they said "We can't pay him" publicly then just cut him a cheque privately with the understanding that he not tell anyone he got paid. This way, they can go on with the TOS saying you can't affect real users with your hacks, and the dude that blew the whistle gets the reward.
Otherwise, you should make some good faith effort to not assume devious intentions on someone making a good faith effort to report problems.
> They just can't pay him for having demonstrated a vulnerability by hacking someone's account.
Technically, according to the security person at Facebook, it wasn't a bug. When he did the same thing again on Mark Z's account, it suddenly became hacking. Yeah, he didn't follow a procedure that wasn't available to him in his native language, but he made a good faith attempt to report the bug, and did so several times.
> But good intentions aren't always enough.
Several attempts to contact them despite being told the actions he was taken was not a bug despite clearly explaining why it was?
Slightly off topic, but it would be nice if the test accounts really worked all the time. I've seen a number of cases where entire sections of the site (e.g. http://developers.facebook.com) that error out (return 500's) when using whitehat test account's auth info. This leaves us with little choice but to use real accounts in some cases.
I hope that the fb'er who replied to him saying "this is not a bug" has been retrained to use the words "we are unable to reproduce this issue, please provide further information or perhaps a video demonstrating the bug".
It's plain simple corporativism. The guy escalated the issue to their boss and they are not happy. Since this is probably a failure at multiple levels, they will fight back. It really sucks but it's all very unexpected.