There are multiple patches for tmux floating around. One of them is even correct, if you want 24bit tmux. My arch and nix machines are both running it.
I get your point in these threads, but unless I'm misunderstanding, who cares about stolen, potentially undeleted Amazon creds? Revoke the key in the portal and be done with it?
Given who I'm replying to, I'm assuming that I'm missing some key piece of the puzzle.
(And I totally acknowledge it doesn't change the circumstances of what either side has done, I'm just curious)
The point is, having those is a prosecute-able offense, if Facebook chose to prosecute. So it's a big threshold to cross legally, even if not meaningful from a programmer's perspective.
Facebook's terms say they will not prosecute /report whitehats to law-enforcement. Facebook could prosecute, at the price of some goodwill from the security industry (or part of it). I'm sure a competent lawyer to mount a robust defence for the security researcher (beyond reasonable doubt, IMO).
You're missing my point and talking about something entirely different from what I'm talking about. I'm not talking about whether Facebook will prosecute and what the consequences of that will be (whether they'll win or lose whatever).
I'm just pointing out that taking AWS keys is a big deal, because it's legally a big deal.
>If you give us reasonable time to respond to your report before making any information public, and make a good faith effort to avoid privacy violations, destruction of data, and interruption or degradation of our service during your research, we will not bring any lawsuit against you or ask law enforcement to investigate you.
IANAL: but it could be argued (in court) that he had Facebook's permission to getting the AWS keys. In his opinion (and mine) he made good faith efforts to avoid privacy violations.
Facebook's official disclosure policy has legal weight. There is legal concept (whose name is escaping me) that could apply that in laymen's terms say the official disclosure policy gives him Facebook's tacit approval - I first heard about it in the Oracle v Google where Google argued a blog post congratulating Google provided tacit approval.
The part you emphasized is dependent on the first part of that sentence, however. In this hypothetical lawsuit Facebook's lawyers would easily be able argue that they would not have done anything for the initial exploit or even demonstrating that he had recovered valid AWS keys but that attempting to hoover up data from S3, etc. violated the “good faith effort to avoid privacy violations” part.
1. This assumes his description of his actions is completely accurate
2. This assumes that he was perfectly accurate in his assessment of an unfamiliar project's naming conventions, data structure, etc.
3. This assumes that he was perfectly reliable in making the actual copies and didn't accidentally include potential personal data (e.g. who knows what might be in a log file?)
The problem is that we're talking about someone who already decided to exceed the bounds of what was clearly protected under the bounty program. He'd already reported the initial vulnerability and been paid for it but waited until later to mention that he'd copied a bunch of other data, had access to critical infrastructure, and wanted more money.
It seems fairly likely that this wasn't malicious but rather just poor judgement, but that makes it very hard to assume that outside of that one huge lapse in judgement he did everything correctly. It's really easy to see why Facebook couldn't trust his word at that point since it's already far outside normal ethical behaviour.
To your first point: There's being skeptical and then there's calling someone a liar without actually calling them a liar because you don't have any justification for doing so. This is far from the first time I've seen this on HN and it's really not okay. There's no point in speculating about the veracity of this person's statements until there's a reason to.
To the second and third: They only require that a researcher "...make a good faith effort to avoid privacy violations..." and I'd say he met that. You can argue that the entire endeavor wasn't in good faith but he certainly made a significant and conscious effort to avoid private data.
I think his biggest lapse in judgement was that he brought security operations issues to light in a bug bounty program run by the people that would be most embarrassed by them. Application security bugs are created by the engineering team and the CSO's application security team fixes them (or advises or whatever). Security operations issues are entirely the responsibility of the CSO's department.
Facebook (as an organization) should be thanking him. While he didn't expose application security bugs he exposed significant operational issues and blind spots. Keys with far too much access, lack of log inspection, lack of security around what IP addresses a key can be used from, etc. Operational issues and lapses in operational security are what got Twitter in hot water with the FTC in 2010. It's not as easy to play cowboy with operations as it used to be.
The CSO hasn't been around for long but by all accounts he poured a lot of effort into hiring an application security team. Perhaps that's his specialty but even one experienced technical manager hired for security operations could have caught these basic issues. They probably wouldn't have addressed the lack of least privilege in that time frame but they could have easily spun up logging to catch some rando on an unknown IP address using their keys.
But like I said, he hasn't been there for long so I don't blame him for the failure. What I do blame him for is calling up the employer to threaten them as leverage to shut up the researcher. I blame him for posting a thinly veiled justification for doing so. He could have addressed this openly, talked to the guy directly and went to the other C-level execs with it as a justification for getting everyone on board with fixing it but he tried to keep it contained to his department.
I understand how he must feel being the new guy who's responsible for the outcome but not for creating it. I know he'll get questions that he might not be able to answer since they probably aren't logging bucket access. Questions like, "Who else got a copy of these keys and what did they access?" Saying "I don't know and we may never know" in response to that, even if you weren't in charge more than three months ago, is rough.
Again, you're quibbling about legal details that are not relevant to my point. I'm pointing out that his actions are a big deal because they crossed a legal threshold where a company would have a somewhat decent case to prosecute you. I don't care whether or not they would succeed.
It was a best seller before Juniper started using JunOS on their new firewalls (SRX) and it continued for a while due to being rock solid and their ability to do pretty much anything in a fairly easy way.
I remember working with my first SRX in 2009 and nowadays I still talk to customers rocking ScreenOS devices. I've lost any trust on them due to this news, of course, but boy their OS and feature set was awesome... I did like them so much that I bought a tiny NetScreen 5GT a few months ago for £10 only to gather dust on my desk for weeks, until I gave it away to a colleague that had a better use for it :)
Anyway, I derailed. They were everywhere and they're probably still around in many SMBs.
What a ridiculous thing to say. Firstly, the amount of cash the company has is irrelevant. Secondly, it was mentioned elsewhere in this thread, if WhatsApp has no presence in Brazil (i.e. no physical offices, the service is just 'offered' there because it is on Google Play/App Store) then why should they have to comply with local laws in a foreign country?
If my website gets ruled to turn over logs by some local jurisdiction in Brazil. Why should I feel compelled to comply? I am not Brazilian and I have no Brazilian business presence. It's the Internet... to be policed by every local jurisdiction in the world is ridiculous.
I'm sorry, I've scoffed at other valuations and investments, but I'm just completely beside myself. Why does a chat room need "apps"?
It's kind of weird actually. There's two sorts of people that defend these announcements, I've found:
The first thinks that they are going to build an "amazing" platform some day and that they'll follow this model for "growing revenue". So of course they defend it.
And then there's the second group that has some "great idea" who plans to build on Slack's platform. Personally, I look forward to 2 years of stories about how Slack was unfair to them, or changed the rules on them, or broke an API. Or didn't review fast enough, or any of the other complaints that pop up monthly about other closed platforms.
1) Take 300m in VC money.
2) VCs want their money back
3) Pull your hair for a a while.
4) Figure out a genius plan. Now you are an ecosystem! Nobody ever thought of that. You are a true silicon valley legend!
5) Profit
Have you ever even USED Slack? The apps are amazing, it's 50% of why people use Slack. There have been apps since I've known about it which has been almost since it launched.
Slack's integrations are less powerful than many alternatives. Every chat system has integration options. They have very little to do with Slack's popularity.
Parent didn't say 50% of interactions were integrations, just that the integrations are 50% of the reason people use Slack and I agree. There are other somewhat comparable products that are a lot cheaper, yet don't deliver the same value with regards to integrations.
Huh? In the AMA they hinted that the thing can boot other OSes.
Whatever the convergence plan is, Pixel C is the test hardware. The bootloader bits are in the ChromeOS tree. It uses Coreboot.
It's a ChromeOS device and I suspect it's future will include a return to its roots.
ARC in Chrome will be a better way forward for Android than trying to fix all of Android's insidious problems on the "desktop" and making mobile Chrome more fully featured. It just seems painfully obvious that Chrome is going to win.
This (well, *BSD) is what I'm interested in. It'll be interesting to hear from the Linux/BSD pioneers what the networking, gfx, and touchscreen support are.
I like Google Voice and I use the functionality. Should every single Firefox user have a Google Voice extension pre-installed?
It's just painfully stupid in every way. If it was a built in extension that by-default talked to a Mozilla hosted open source Pocket clone, we might be having a different conversation.... but I'd still be annoyed.
Just as annoyed as I am that Chromium (yes, Chromium, not Chrome) comes with a god damn Google Docs extension.
Even for weird little side projects, it's always feels safer to me to get changes upstreamed than keep carrying around "special snowflake" vendored copies that diverge.
