Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I love how publicly posting bugs shifts the balance of power. "schofield" probably though it was just a conversation between Yahoo and the submitter. Now it's a conversation between Yahoo and Hacker News.

Welp, the verdict is schofield is being dense. Of course user relationship pairs are potentially sensitive. Therefore enabling attackers to discover them by enumerating your tiny key space is an issue.

Either schofield needs to wisen up or Yahoo needs to put someone better in charge of their security issues.



Companies need to send out an email to all employees every morning reminding them of the most basic law of corporate communications:

"When you speak to a customer, reporter, friend, or any other person not employed by $Company about $Company-related matters, you are acting as a public representative of $Company.

Regardless of whom you speak to or in what context, you must assume your words will be repeated to the entire world as $Company policy.

Your words will be read/heard and interpreted by people of every conceivable level of intelligence and education, in every conceivable cultural context. Even people who have never heard of $Company before and know absolutely nothing about $Company or the matters you are discussing will form opinions based on your words.

People more intelligent, better educated, and more experienced than you in the matters you are speaking about will also read and interpret your words. Then they will speak publicly about them, and further influence others' opinions of $Company.

There are no exceptions."


Also, maybe my time zones are wrong, but it seems like the engineer changed the bug status to "disclosed" late in the day Friday?

A corollary: Don't do sh*t late Friday that will fester over the weekend.

It makes me mental when people want to "close their week" by deploying a change to a public-facing system. Yes it feels great to check it off your list and start your weekend. But unless you're prepared to deal with it over the weekend -- and got buy-in from the rest of your team they're prepared to deal with it -- please don't.


I run ops at my current ship, and my counterpart is our lead developer.

I'm not sure how it works elsewhere, but together we have a very strict "We DO NOT deploy production changes on Friday". New chef script? Monday. Change to how we're sending writes or reads to different DB clusters? Monday.

I do not know why this isn't the norm in more places.


s/ship/shop


I quite like the idea of calling one's workplace a ship. I'll take that expression on board, sea if it floats.


Definitely. Ship that shit.


I haven't used hackerone myself, so this is just based on limited observation, but it looks to me like it was automatically disclosed one month after the reporter made the request. Otherwise, I believe it would have said something like "schofield agreed to make this public".


That is correct. The reporter requested public disclosure after the report was closed. The bug automatically gets disclosed publicly 30 days after the report is closed, unless the team requests more time by re-opening the bug. You can read more about the disclosure philosophy here: https://hackerone.com/guidelines


Thanks for explaining that.

So maybe a feature-request for hackerone would be, don't auto-disclose on Fridays; instead bump to Monday. :)


Another interesting feature might be notifying the engineering team that a following list of bugs will be automatically disclosed in x days and give them a chance to review them with a fresh pair of eyes.


> It makes me mental when people want to "close their week" by deploying a change to a public-facing system. Yes it feels great to check it off your list and start your weekend. But unless you're prepared to deal with it over the weekend -- and got buy-in from the rest of your team they're prepared to deal with it -- please don't.

My favorite is the deploy right before the vacation. The internal pressure is even higher in that case (the dev doesn't want anything on their mind during their vacation—totally understandable), but the outcome/cleanup is even worse—they're not there to fix their code (and possibly not even available since they might be on a plane).


Correct

I once worked in a company that had a manual for communications/dealing with the media, etc. And this was given to engineers.

(it was a company that did a product that was bought by governments and had an impact on people, so the chance of being interviewed by the press was higher than average)


where I work they do and they require online training and signing (electronically) a statement to the effect that you understand. of course that doesn't mean it doesn't happen all the time. Your suggestion is about as useful as a chocolate fireguard I'm afraid.


To be fair the 'schofield' has been diligent before: https://www.google.com/search?q=site:hackerone.com+schofield

Are the relationship pairs actually being exposed? All I can see are the email / name pairs - not who invited the user (and you have to be logged into a Yahoo account).


Leaking someone's email address and associated name is bad enough. If Yahoo don't see that as sensitive it places the ability of miscreants to entirely own and abuse Yahoo Mail accounts in some kind of institutional context.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: