Hacker News Reader

Comment by mkjones | Hacker News Reader

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.

View on HN

>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."

Rules that are not applied consistently are arbitary.

No one said anything about a crime. Denial of the bounty is not brutal.

> 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.

Not sure what you mean by "again".

> 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.[1]

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?

[1] https://www.facebook.com/whitehat

Immediately following that quote: Do not interact with other accounts without the consent of their owners.

He didn't try to reproduce the bug with a test account though. If he had and it hadn't worked, the fact that he then used a real account would've been acceptable.

> 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.

In the appropriate language: https://news.ycombinator.com/item?id=6231153

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?

"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.

How would you feel if he found an exploit that allowed him to make all your private messages public and proceeded to report this by leaking your inbox?

I'm no fan of Facebook, but even I can see why they can't ever encourage such irresponsible behaviour.

As stated, a case by case assessment would most definitely capture this fictional scenario appropriately.

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.

The bug bounty won't cause others to report bugs if they pay in secret.

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.

> Obviously I don't love the end outcome,

If only you could do something about it to make the end outcome more ideal.

But a member of your team was in control of the outcome and messed up. This guy really wanted to make sure that you guys saw the issue in spite of a member of your team screwing up.

You should be rewarding him, not discouraging him.

I know arguing with someone as stubborn as you is useless, but what can I say?

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".

So no one reasonable is allowed to actually make a decision eh? Must be shitty working at Facebook if decisions don't have a human-compassionate influence to them.

Is creating test accounts even allowed by the Facebook ToS?

I assume he means whitehat test accounts which are created in the whitehat console, and can only interact with other whitehat accounts

Reply on news.ycombinator.com