Looks like someone just changed the title of this HN submission. For the record, it originally said: “Full name and email for every Flickr invite ever sent can be viewed by anyone”, which was accurate at the time of posting.
I changed the title in accordance with the HN guidelines.
Flickr: Invitations disclosure (resend feature)
81–90 of 93 posts
Re: Flickr: Invitations disclosure (resend feature)
#82Earlier quoted context omitted.
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
Re: Flickr: Invitations disclosure (resend feature)
#83Earlier quoted context omitted.
That's great, but you were aware of this issue for a month. If the whole point of having a bug bounty program is that you benefit from the distributed intelligence of the community you should perhaps place a bit more faith in your unpaid and unrewarded labor. Do you really receive thousands of invalid security reports every month or is user Schofield way out of their depth. Why should another dev ever bother submitti…
> Do you really receive thousands of invalid security reports every month or is user Schofield way out of their depth. Although our project is much smaller, we also run a bounty program through HackerOne, and publish aggregate results every month. You can see them under the "Security" headers of the changelog for the last few months to get a quick sense of the overall composition of reports that come through a channe…
Basically doing a bug bounty right is very hard.
Stuff like this will happen. By running a bug bounty at all you are opening your company up to situations like this but the bigger picture is that you care about security enough to still do it for the valid security issues bug bounties find. It is a strong signal to me that a company actually cares about security and we shouldn't lose focus of that in the midst of pitchfork-waving "but yahoo was WRONG".
We recently released some stats that support all this here: https://www.facebook.com/notes/facebook-bug-bounty/bug-bount...
Re: Flickr: Invitations disclosure (resend feature)
#84I have no idea why anybody would do business with a company as awful as Yahoo in 2014.
Should this have never happened? Absolutely. Does it display that Yahoo is "awful," absolutely not.
Re: Flickr: Invitations disclosure (resend feature)
#85Earlier quoted context omitted.
I changed the title in accordance with the HN guidelines.
Which guideline in particular? “Otherwise please use the original title, unless it is misleading or linkbait”? The new title is definitely not as clear IMHO.
I agree that it isn't as clear, but (a) it isn't misleading, and (b) we use the original title unless there's a strong reason to change it.
Re: Flickr: Invitations disclosure (resend feature)
#86Earlier quoted context omitted.
> Do you really receive thousands of invalid security reports every month or is user Schofield way out of their depth. Although our project is much smaller, we also run a bounty program through HackerOne, and publish aggregate results every month. You can see them under the "Security" headers of the changelog for the last few months to get a quick sense of the overall composition of reports that come through a channe…
To echo this sentiment: In 2013 facebook received 14,763 submissions which lead to 687 paid issues, 1 : 21 signal to noise. Facebook errs on the side of paying out as often as possible even for lame bugs (apache shows its version number in some talent acquisitions blog), code we didn't write, defense in depth type stuff, instances where the reporter was wrong and there wasn't actually a bug but in the process of inve…
Re: Flickr: Invitations disclosure (resend feature)
#87Earlier quoted context omitted.
What about spoofing? http://en.wikipedia.org/wiki/Email_spoofing
I think 'ars is saying that these are "personalized" email addresses: there is a separate one for each person from whom 'ars wants to receive email. Assuming these addresses aren't easily guessable/enumerable, and aren't on any lists stolen from or sold by service providers, the spammer must have have gotten them somewhere else .
Someone has likely been hacked or sold/leaked data, but he should assume that those addresses have been spread quite a bit voluntarily by his friends/associates.
Re: Flickr: Invitations disclosure (resend feature)
#88Earlier quoted context omitted.
I think 'ars is saying that these are "personalized" email addresses: there is a separate one for each person from whom 'ars wants to receive email. Assuming these addresses aren't easily guessable/enumerable, and aren't on any lists stolen from or sold by service providers, the spammer must have have gotten them somewhere else .
The problem is that pretty much every one of them have probably given one or more services access to download their contact data to connect them to their friends, so any number of services other than their e-mail likely contains these personalized e-mail addresses. Someone has likely been hacked or sold/leaked data, but he should assume that those addresses have been spread quite a bit voluntarily by his friends/asso…
Re: Flickr: Invitations disclosure (resend feature)
#89Earlier quoted context omitted.
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
Re: Flickr: Invitations disclosure (resend feature)
#90I have no idea why anybody would do business with a company as awful as Yahoo in 2014.
Yahoo has roughly 12,000 employees, so you can imagine controlling what those 12k employees do on a daily basis is next to impossible. Should this have never happened? Absolutely. Does it display that Yahoo is "awful," absolutely not.