Instagram's Million Dollar Bug - <AUTHOR> http://www.exfiltrated.com/research-Instagram-RCE.php <comment><USER3> Thank you to everybody who cautioned against judgment before hearing the whole story. Here is my response: [https://www.facebook.com/notes/alex-stamos/bug- bounty-ethics...](https://www.facebook.com/notes/alex-stamos/bug-bounty- ethics/10153799951452929)

<comment><USER4> I think the root cause of the problem is the unclear policy by FB. Privilege escalation can be hard to catch, and can be a separate bug in and of itself, even if it requires a separate exploit to get the initial privileges.

The published policy didn't say anything about not doing what he did. I'm not going to argue that what he did should or shouldn't be ok, but FB has no control over what other people do. Yeah, maybe it'd be better if people asked for clarification first instead of asking forgiveness, but there's no way to force them to do that. FB does have control over what their policy says and allows/disallows. If you don't want people to exfiltrate any data and look at it on a local machine instead of just keeping a session on the exploited machine, then put that in the policy. If you don't want people poking around for other exploits after gaining access, then spell that out in the policy.

The point of the policy isn't to stop everyone. Sure it will stop some/most people, but some people don't listen. The point is that when it happens again you can point to the clear policy and say "you're an asshole, we're not paying you because you violated our explicit policy, and we are reviewing what you did with our lawyers to see if we should notify law enforcement".

Yes, doing this fix/policy update now doesn't fix this situation, but it prevents anyone else from doing something similar and claiming ignorance of this situation and FB's position.

<comment><USER5> Why do the policy specifics matter? A blackhat won't be respecting those rules, and won't need to negotiate a reasonable payday with facebook.

The real issue here is facebook's poor infrastructure security and slow response time. If the exploit had been previously reported, why was the privilege escalation still possible? Why did a (supposedly) known-to-be- vulnerable host have access to secret information at all?

The exfiltration of data may have been unethical, but facebook has no one to blame but themselves for it even being possible.

<comment><USER6> > Why do the policy specifics matter?

Companies take big risks in running bounty programs. They are giving hackers permission to test their _live site._ This isn't something that is popular with everyone inside a company. Bounty hunters need to respect that bounty programs are a two way street. If you find a serious issue like remote code execution you need to be extra careful. Wineberg was an experienced hunter. He should have known better.

</comment></comment></comment></comment><comment><USER7> In stories like this, try first to remember that Facebook isn't a single entity with a single set of opinions, but rather a huge collection of people who came to the company at different times and different points in their career.

Alex Stamos is a good person† who has been doing vulnerability research since the 1990s. He's built a reputation for understanding and defending vulnerability researchers. He hasn't been at Facebook long.

To that, add the fact that there's just no way that this is the first person to have reported an RCE to Facebook's bug bounty. Ask anyone who does this work professionally: _every_ network has old crufty bug-ridden stuff laying around (that's why we freak out so much about stuff like the Rails XML/YAML bug, Heartbleed, and Shellshock!), and _every_ large codebase has horrible flaws in it. When you run a bug bounty, people spot stuff like this.

So I'm left wondering what the other side of this story is.

Some of the facts that this person wrote up are suggestive of why Facebook's team may have been alarmed.

It seems like what could have happened here is:

1\. This person finds RCE in a stale admin console (that is a legit and serious finding!). Being a professional pentester, their instinct is that having owned up a machine behind a firewall, there's probably a bonanza of stuff they now have access to. But the machine itself sure looks like an old deployment artifact, not a valuable asset Fb wants to protect.

2\. Anticipating that Fb will pay hundreds and not thousands of dollars for a bug they will fix by simply nuking a machine they didn't know was exposed to begin with, the tester pivots from RCE to dumping files from the machine to see where they can go. Sure enough: it's a bonanza.

3\. They report the RCE. Fb confirms receipt but doesn't respond right away.

4\. A day later, they report a second "finding" that is the product of using the RCE they already reported to explore the system.

5\. Fb nukes the server, confirms the RCE, pays out $2500 for it, declines to pay for the second finding, and asks the tester not to use RCEs to explore their systems.

6\. _More than a month after Facebook has nuked the server_ they found the RCE in, they report another finding based on AWS keys they took from the server.

So Facebook has a bug bounty participant who has gained access to AWS keys by pivoting from a Rails RCE on a server, and who apparently has _retained_ those keys and is using them to explore Instagram's AWS environment.

So, some thoughts:

A. It sucks that Facebook had a machine deployed that had AWS credentials on it that led to the keys to the Instagram kingdom. Nobody is going to argue that, though again: every network sucks in similar ways. Sorry.

B. If I was in Alex's shoes I would flip the fuck out about some bug bounty participant walking around with a laptop that had access to lord knows how many different AWS resources inside of Instagram. Alex is a smart guy with an absurdly smart team and I assume the AWS resources have been rekeyed by now, but still, how sure were they of that on December 1?

C. _Don 't ever do anything like what this person did_ when you test machines you don't own. You could get fired for doing that working at a pentest firm even when you're being paid by a client to look for vulnerabilities! If you have to ask whether you're allowed to pivot, don't do it until the target says it's OK. Pivoting like this is a bright line between security testing and hacking.

This seems like a genuinely shitty situation for everyone involved. It's a reason why I would be extremely hesitant to ever stand up a bug bounty program at a company I worked for, and a reason why I'm impressed by big companies that have the guts to run bounty programs at all.

† _(and, to be clear, a friend, though a pretty distant one; I am biased here.)_

<comment><USER8> I think you're right on most points, but after reading the write up and response I do think Alex reached out to the employer first instead of the researcher as an intended act of intimidation. That was a mistake.

If it was not done for the purpose of intimidation, then Alex simply would have asked the CEO if the researcher was acting on the company's behalf and after hearing "no" would have ended the call and contacted the researcher directly.

Seems simple doesn't it? Perhaps you are not seeing it due to your friendship, but it seems like a dirty move and only serves to call into question how Alex handled other aspects of the situation.

<comment><USER9> > If it was not done for the purpose of intimidation, then Alex simply would > have asked the CEO if the researcher was acting on the company's behalf and > after hearing "no" would have ended the call and contacted the researcher > directly.

Then the CEO is going to contact the researcher and he's screwed either way. God knows what the CEO would have say to the researcher privately. Having a middle man to translate is a bad idea in an emergency.

Let's face it, when you used your work email and made another company paranoid, you are putting people on the spot. Employer needs to know (they have legal responsibility), and given the prior research they did and the researcher's claim, I think the reach out is absolutely correct.

Instgram's infrastructure has flaw. That's bad but everyone's infrastructure has flaw. Shit has to be fixed. Doing more than what was needed is bad. If I am told to stop dumping data, I would stop.

</comment></comment></comment><comment><USER10> As a security researcher and engineer, I'd like to point out the following, without taking sides:

1\. Facebook is _not_ going ballistic because this is a RCE report. They have received high and critical severity reports many times before and acted peaceably, up to and including a prior RCE reported in 2013 by Reginaldo Silva (who now works there!).

2\. The researcher used the vulnerability to dump data. This is well known to be a huge no-no in the security industry. I see a lot of rage here from software engineers - look at the responses from _actual_ security folks in this thread, and ask your infosec friends. Most, perhaps even all, will tell you that you _never_ pivot or continue an exploit past proof of its existence. You absolutely do not dump data.

3\. When you dump data, you become a flight risk. It means that you have sensitive information in your possession and they have no idea what you'll do with it. The Facebook Whitehat TOS explicitly forbid getting sensitive data that is not your own using an exploit. There is a precedent in the security industry for employers becoming involved for egregious "malpractice" with regards to an individual reporting a bug. A personal friend and business partner of mine left his job after publicly reporting a huge breach back in 2012 (I agree with his decision there), and Charlie Miller was fired by Accuvant after the App Store fiasco. Consider that Facebook is not the first company to do this, and that while it is a painful decision, it is not an insane decision. You might not agree with it, but there is a precedent of this happening.

I'm not taking sides here. I don't know that I would have done the same as Alex Stamos here, but it's a tough call. I do believe the researcher here is being disingenuous about the story considering that a data dump is not an innocuous thing to do.

I'm balancing out the details here because I know it will be easy to see "Facebook calls researcher's employer and screws him for reporting a huge security bug" and get pitchforks. Facebook might be in the wrong here, but consider that the story is much more nuanced than that _and_ that Facebook has an otherwise _excellent_ bug bounty history.

Edited for visibility: 'tptacek mentioned downthread that Alex Stamos issued a response, highlighting this particular quote:

 _At this point, it was reasonable to believe that Wes was operating on behalf of Synack. His account on our portal mentions Synack as his affiliation, he has interacted with us using a synack.com email address, and he has written blog posts that are used by Synack for marketing purposes._

Viewed in this light (and I don't believe Stamos would willfully fabricate a story like this), it is very reasonable to escalate to an employer if they seem to be affiliated with a security researcher's report.

<comment><USER11> Running a bug bounty is not a suicide pact. A team had to convince a finance group that it was valuable to give money away to people who might be assholes. Bounty hunters are not a community- but if you are a bounty hunter, you should understand that many of your peers are total assholes. The company that wants to pay you a reward has to figure out if you are going to make them regret offering you a reward.

There are 4 categories of reporters: great, good, shit and crazy. Again- if you are a reporter, you should be trying to make it easy for the team to distinguish you in one of the first two categories by being simply being polite & respectful.

I will take a side- it's Facebook. Dumping data is the end of the Proof of Concept. Trying to determine if there is more data you can access through a single vulnerability chain is over the line.

Boats sink. The engineers know it. If you sink a boat in order to prove the boat had a hole, you will not get your payout.

And one final thought-

In my experience, bounty hunters almost never realize the full consequences of a vulnerability that receives a reward. Most of the time, the "Bad thing" that they identify is just the tip of the iceberg.

The choices of the researcher reflect inexperience and immaturity. The researcher has a significant misunderstanding about what is happening in the bug bounty marketplace. I think they need to apologize if they want a future in the infosec world.

Publishing this blog post was a huge error. Going to the journalist was another huge error. I don't see how this person could ever be considered employable by a reputable company.

<comment><USER12> Are you saying that if Wes hadn't pointed it out, than Alex wouldn't have to refresh all those keys? That if Wes hadn't dumped the keys than they were 100% secure?

<comment><USER11> Good lord no.

I am saying explicitly- Wes went past the point at which he should have stopped.

He also should have known better, and the fact that he didn't is a problem in itself.

</comment></comment></comment></comment><comment><USER13> Summarizing what I've seen here in analogy form:

      Researcher: "I found a way to unlock your door"

      Facebook: "Thanks, here's $2500. We've now fixed the problem."

      Researcher: "Oh, BTW when I unlocked your door I rifled through
        your stuff and found your passport, your banking details, and a
        lot of personal information. I've kept copies of these. I also
        found the keys to your car and looked inside, where I found a box
        in the trunk. That box contained sensitive documents including an
        employee badge / proximity card. I used this card to gain access
        to your workplace. In doing this, I also managed to get into the
        janitor's closet which had a set of keys. I used these keys to
        get access to the complete building and took a look at all the HR
        files and rifled through a bunch of corporate contracts."

      Facebook: <gobsmacked>

      Researcher: "Can I have my million bucks now?"

Where the researcher stepped over the line is using the door attack to escalate further attacks. It's little different than finding a way to reliably impersonate Mark Zuckerberg's credentials in such a way that others will 100% believe it. That finding is worthy of a reward. But then using that vulnerability to social engineer others to reveal passwords, using that as a launching point for mounting further attacks is going way too far.

<comment><USER14>
       Oh by the way, when I looked in your open front door, I noticed all your
       computer terminals had their passwords written on post-it notes by their
       monitors, and the big safe in the back room had its key hanging right
       next to it on a chain.

</comment></comment><comment><USER15> Note to self: Don't report any chained attacks to any large companies bug bounty programs. Alex Stamos contacting the employer of the bug reporter is completely out of line.

This is the fastest and easiest way for Facebook to stop good submissions to their bug bounty program.

</comment><comment><USER16> In my opinion, the author is feigning shock...

He claims to have downloaded the content listed below. And he is surprised that Facebook responds coldly? Note the string "private keys" in this list... Doesn't the author know how long it will take them to recover from this breech? How much it will cost them?

On the other hand, it does sort of re-enforce the idea that he should be paid handsomely, doesn't it? :)

        * Static content for Instagram.com websites. Write access was not tested, but seemed likely.
        * Source code for fairly recent versions of the Instagram server backend, covering all API endpoints, some image processing libraries, etc.
        * SSL certificates and private keys, including both instagram.com and *.instagram.com
        * Secret keys used to sign authentication cookies for Instagram
        * OAuth and other Instagram API keys
        * Email server credentials
        * iOS and Android app signing keys
        * iOS Push Notifications keys
        * Twitter API keys
        * Facebook API keys
        * Flickr API keys
        * Tumblr API keys
        * Foursquare API keys
        * Recaptcha key-pair

<comment><USER17> I would tend to agree.

Facebook's point is that he found a vulnerability, and exploited it instead of stopping there. I kind of understand their point of view though. "See you have a vulnerability there, and then I can get access to this, and then this, and see now I have the password of your user, and then I'm just one click away from accessing all the instagram pictures I want."

Although Facebook's handling of the problem is poor (why didn't the CSO call the author directly to get things squared out? He does not talk to people who are not C*O?), they do have a point.

I think the author acted in good faith, but got carried away by his findings unfortunately.

<comment><USER18> Exploiting the bug would have been downloading the actual contents of the S3 bucket (the instagram source and other things). He specifically says he did not do that.

<comment><USER19> He clearly made a big effort not to violate privacy. The problem is that he made their security look like a joke by getting the keys to the kingdom without anyone noticing. Did that big expensive IDS catch him? Nope. Did any of the log watchers babysitting the AWS logs? Nope. One researcher made the CSO look incompetent in the matter of minutes.

If he had found a bug with something a developer wrote that would be a different story. What he found was layer after layer of Operations (particularly Security Operations) failures. This is something you hire a CSO to think about (or at least hire/manage others to think about).

</comment></comment></comment></comment><comment><USER20> Facebook's calling his employer could be slanderous, possibly even criminal harassment.

Between stories like this demonstrating companies' apparent lack of understanding of whitehat infosec, and Weev's incarceration demonstrating the American legal system's apparent lack of understanding of whitehat infosec, it's hard to believe people still participate in such endeavors.

<comment><USER21> Also remember that the story we have here is a one sided narration from a bug bounty researcher.

The story tells us his side of things but what specifically Facebook perceived as threat is still unknown ? Why would a CSO get involved unless they specifically think that the data has been accessed violating the goodwill of the bug bounty research in the first place.

<comment><USER20> That's true, there could be large portions of the story that are omitted or inaccurate. We may never even get the full story.

Assuming the story as stated is truthful or even plausible, what options do whitehat hackers have to defend themselves in such a scenario? I mean the whole point seems to be to try to penetrate a secure system, and the consequences of that action seems to be fairly obvious from the start. If a whitehat hacker is successful, that carries with it the inherent potential that they will have some sort of access to some sort of sensitive data, right?

Surely telling Facebook "I was able to access these exact things" means he expected Facebook to update passwords and change keys accordingly, making the possibility that he retained those keys moot.

<comment><USER22> It almost seems like Facebook wanted to know about the issue, but not have to update the keys.

</comment></comment></comment></comment><comment><USER23> I think the solution here is to pay $100k+ for RCE exploits and explicitly forbid pivoting access after the first vulnerability is discovered. Facebook offered $2,500 for a security vulnerability that could do much greater damage. What kind of vulnerability is a "million-dollar bug" if not RCE? How would you possibly have a "million-dollar bug" that is a single-point-of-contact bug and how would you verify that Facebook is paying you fairly? They didn't seem to in this case.

</comment><comment><USER7> Alex responds:

[https://www.facebook.com/notes/alex-stamos/bug-bounty- ethics...](https://www.facebook.com/notes/alex-stamos/bug-bounty- ethics/10153799951452929)

Critically:

 _At this point, it was reasonable to believe that Wes was operating on behalf of Synack. His account on our portal mentions Synack as his affiliation, he has interacted with us using a synack.com email address, and he has written blog posts that are used by Synack for marketing purposes._

Alex's timeline seems like it matches what I wrote earlier:

[https://news.ycombinator.com/edit?id=10754627](https://news.ycombinator.com/edit?id=10754627)

<comment><USER10> Assuming that's true (and I personally don't believe Stamos would flagrantly fabricate a detailed story like this publicly), this is a game changer. It's fully reasonable to escalate to an employer if they seem to be affiliated with the security researcher's report.

Also worth noting that this is frequently done in the security industry - folks will often credit not only themselves but also the companies they work with and are associated with in a security report.

<comment><USER12> No, Alex just assumed. Why didn't he just ask Wes if he was doing this for Synack?

<comment><USER7> He "assumed" because the researcher signed up for the Facebook bounty program _as an employee of Synack_ and _used his Synack email_ to communicate with Facebook.

He wasn't guessing. He didn't look the guy up on LinkedIn.

<comment><USER24> > He didn't look the guy up on LinkedIn.

I don't really see how else you can interpret the defense "he has written blog posts that are used by Synack for marketing purposes".

And it's pointed out all over the thread, but no part of "the researcher signed up for the Facebook bounty program as an employee of Synack and used his Synack email to communicate with Facebook" is uncontested, nor is it supported by the text of Alex Stamos' response. You've just read in what you want to see.

</comment></comment></comment></comment></comment><comment><USER25> So if I'm reading this correctly, this massively compromising attack was made possible by doing a little research? e.g. Knowing about one of the admin services used by Instagram, looking in that admin's public repo, and musing whether Instagram had bothered to change the secret key from the default entry in the repo?

We'll probably never see a post mortem on this but it'd be interesting to hear how this got moved to production...: was the Sensu admin panel a nice scaffold for internal use and by the time they decided to make it remote, everyone just assumed the secret key had been changed at some point?

<comment><USER26> I can tell you from experience working at another similar company that this is not surprising at all. Especially as startups transition into larger companies (with formal security controls and policies), a lot of things can get missed or forgotten. Your primary production servers may be completely up-to-date and secure, but somewhere along the way, there's a high chance that an engineer deployed an internal admin tool or a test build somewhere that ends up being public, but ultimately lost and forgotten. The problem is, that kind of "lost" infrastructure often contains keys, credentials, or network access to other more critical parts of the infrastructure, and no one realizes the severity of the mistake until it's too late.

</comment></comment><comment><USER27> The thing that gets to me is the lack of gratitude on Facebook's end. Instead, they turn him into the villain for breaking imaginary rules. What would have been the harm in slapping him on the wrist and giving him some sort of reward for exposing a huge vulnerability? Instead, they eat the reward and shit on the guy who produced it. Real classy FB.

<comment><USER7> Did you read the whole post? He got paid on the RCE.

<comment><USER27> Yea I did and I realize he got paid out a little, but it was short of the $1 million.

I realize a million is a bit unrealistic, but if you're going to make a public statement, at least back it up or prove to the guy why his findings don't constitute a "million-dollar bug". It's not right to just cold-shoulder the guy and hide behind vague rules that were never clearly outlined. In fact, you might even conclude Facebook brought his behavior on themselves by making such a statement as "if a million-dollar bug is found, we'll pay it out." $2500 is nothing when you're thinking $1,000,000

<comment><USER7> Nobody is going to pay you a million dollars in 2015 for the 2013 Rails YAML bug in a stale server. Nobody is going to pay you a million dollars for a reliable Firefox RCE, and those take months to prove out and develop, _and_ there's a liquid market for them.

<comment><USER27> But that's not going to stop Facebook from publicizing that they will. You're glossing over the details and attributing an aire of "old news" to the bug. Well, yes / no. If he didn't find such an ancient bug but instead someone devious did, they could have dumped all the private user photos. If that happened, what do you think the financial implications might have been?

<comment><USER7> He got $2500 for that bug. I will venture a guess that that's the most any bug bounty program will pay for that Rails YAML bug in 2015.

<comment><USER28> How much do you suppose blackhats would pay for instagram's ssl keys, mobile app signing keys, push notification keys, etc?

Yeah, the researcher went deep into the grey area, but I find Alex Stamos's reaction barely short of unbelievable - it's almost as though he's so new to the internet he's never heard of the Streisand Effect... (Either that, or he's just so accustomed to bullying and intimidating people who might embarrass him that he's now got that corrupt politician "Waddaya mean I'm 'abusing my power'? We grant multimillion dollar contracts to old school buddies all the time? What's the problem?" look on his face.)

<comment><USER7> Not much. Probably much less than $2500.

A script to create new bogus accounts on Facebook is probably worth more than mass Facebook account compromise.

People _really_ don't seem to understand how the "black market" works.

<comment><USER28> I was thinking more of the Zerodium/Gleg/BoozAllenHamilton class of buyers - who'd on-sell it to, say, the Egyptian or Thai Government, rather than run-of- the-mill carders or identity thieves.

(But yeah, I'm perfectly happy with my life where I have no real understanding of how the black market for this kind of thing works...)

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER29> Sort of an interesting conflict these bug bounties create. You have someone who wants to hack as deeply as possible to have a bigger bug bounty based on stated rules, but at the same time they will invalidate your bounty if they arbitrarily determine it as too much?

I imagine the initial report by his friend that the server was accessibly would not be a very high paying bounty compared to one accessing the server. But how deep is too deep?

<comment><USER30> Right? If he left it at the RCE he would have gotten the $2,500 split between him and his friend... but he continued and was able to get access to all the S3 buckets which you would assume would warrant a much higher payout. Instead he got a huge amount of backlash.

<comment><USER31> Right, this feels like a way for Facebook to simply not payout a bigger bounty after they realized how big an appropriate bounty would be.

If the author submitted the RCE, and nothing else: is someone at Facebook actually going in and trying to simulate what he actually did? Who knows, because the process is pretty opaque. If you argue with Facebook's assessment, and go and further exploit the system to say "no, this is actually how bad the RCE is, in the grand scheme", you've now actually gone and proved what can be done, against their guidelines, which potentially disqualifies your initial discovery altogether.

</comment></comment></comment><comment><USER6> > With the RCE it was simple to read the configuration file to gain the > credentials necessary for this database. I connected and dumped the contents > of the users table.

This was his mistake. This is a huge no-no. You never dump data unless you have permission. It's against the terms of most bounty programs.

<comment><USER32> But like he said in the article, he was unable to find a clear policy that gave him the "Stop, no further" point. It may have been a bad assumption to think Facebook was going with the Tumblr stance of "give us a thorough POC," but where should he have drawn the line in his hack and why here instead of where he did?

<comment><USER33> Getting the credentials is clearly enough to prove the point. Digging through user data is just celebrating.

<comment><USER34> Whereof one cannot speak, one should be silent. Dumping the user table is the literal next step in a standard vulnerability assessment (in order to acquire reused credentials), wasn't prohibited by the terms of FB's bug bounty program, and was crucial to the development of the bug.

<comment><USER7> No, that's the next step in an _external penetration test_ , which is not the same thing as a vulnerability assessment.

In an external pentest, you get a set of netblocks and rules of engagement, and you get as far as you can. That's why it's called a "penetration test".

In a vulnerability assessment, you get a target (usually an application), and you find as many flaws in that target as you can.

Big annual pentests often have wide-open rules of engagements, where you (as a consultant) win big by, for instance, dumping the CEO's mail spool. But those projects also start with several meetings worth of negotiating rules of engagement.

Vulnerability assessments virtually never have those rules of engagement!

Nobody that I know of runs a bug bounty program on pentest norms. To do so would be grossly irresponsible, because on every network with more than 1000 hosts I've ever tested, ever, RCE behind the firewall is gameover for the whole test: you can get everything.

<comment><USER34> You're HN's anointed expert, so I suppose all I can say is that's not my experience.

Among the many reasons bug bounties are bad ideas is that they generally fail to write clear rules -- as Facebook did. As written, what he did is not against the rules and while it may fall into some best-practices bucket you assert to be universal, that's hardly sufficient for a field in which participants can come from any background. But please, continue to defend your friend whose multi-billion company had a month to cycle their popped keys and failed to do so, then responded by threatening a researcher's employment after multiple conciliatory e-mails.

<comment><USER7> _then responded by threatening a researcher 's employment after multiple conciliatory e-mails._

That is NOT what happened. Look at the timeline again.

* He popped the server.

* He submitted the RCE.

* He submitted dumped file from the compromise as a finding.

* They fixed the RCE.

* They told him not to dump files.

* They paid out the RCE finding.

* A month later, they declined to pay out on the dumped file.

* In response, he submits _a new finding, with AWS creds that he stored for more than a month after they shut down the server_

* (Whatever else happens that day)

* Stamos calls Synack.

<comment><USER34> The "then" isn't temporally proximal. The quoted e-mails (unless you feel like asserting that they're fake, which I think is the next step in your arguments in this thread) demonstrate that he's trying to work within the unwritten rules of the program and asking for clarification in good faith. Then after that, rather than attempting any communication with his, Stamos threatens his employment.

I agree with you that something seems off, but you're happily giving all the charity to FB and none to this guy, which is your prerogative but hardly makes for good conversation.

<comment><USER7> Read the timeline again and then the post.

1\. Second finding is declined.

2\. New third finding, which includes AWS credentials that this person should not have had, is written and submitted.

3\. Stamos calls Synack.

I believe the relative timing of these events is, in fact, established.

Now: stipulate that I'm right, even if you're not sure. Does your opinion of the story change?

<comment><USER34> Not really, no. Your _should not have had_ is still presupposing a set of bug- bounty-hunter-professional-guidelines that don't actually exist unless they're specified in the program guidelines, and from a philosophical perspective the actual security vulnerability under discussion now is that their sec team is so lackluster that they can't or won't change out a credential set known to have been externally accessible (and, the critical point, to anyone who could have found this not-particularly-obscure vuln, not just this researcher).

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER32> How likely is it that this sort of a thing stopped being a technical item of discussion and turned into a political one by the security contacts at Facebook?

I'm always curious about what sort of internal pressures would lead people to take a well-reported bug that the author did not take malicious action on and blow it up to the point that the CSO is getting involved.

<comment><USER35> Only way I can see this happening would be finger pointing and finding others to blame. Eventually, the problem starts with a few people then becomes inter- team issue. Then higher ups start to get involved.

</comment></comment><comment><USER26> Not only did this person make several large and irresponsible mistakes in the process of uncovering and reporting the bug (dumping tons of private user information without permission, going far beyond simply discovering and reporting the bug, etc.), but they also keep referring to Ruby ("running Ruby 3.x, which is susceptible to code execution via the Ruby session cookie") as the vulnerable piece, when in reality, it's the version of _Rails_ that had the vulnerability.

<comment><USER36> Well, that's the point. An unexperienced person with half an hour on Google got full access to Instagrams systems.

And the bug has been existing for 2 years.

Wonder where the person who tipped him off had the info from – could very well have been a common target in the black hat scene.

</comment></comment><comment><USER37> @secalex I believe that the researcher clearly fulfilled the primary objective of bug bounty programs by exposing a weakness of yours which you, inspite of having large and competent teams, weren't aware of and had not sealed yet. And he did nothing to use that information with a malicious intent.

Your actions are detrimental to your relations to such good mannered external security researchers who are helping you keeping you infrastructure safe from the bad guys. You should have been a little more sensitive and a lot more generous that you have been.

</comment><comment> shawn-butler Wow what happened to Instagram?

Facebook really needs to go the way of myspace if they keep this sort of behavior up.

How can a CSO at Facebook legitimately tell a CEO of another organization that a vulnerability of "little value" was found when the researchers has your signing certs? Does he lack relevant info or is he just incompetent?

This is tantamount to mafia tactics. Hint, hint, we're facebook so get your people in line or else.

</comment><comment><USER38> If companies are going to keep trying to get out of paying bounties for insane vulnerabilities like this, white hat researchers will just move onto something else, leaving the bounties to be paid out by the black market. Bounties aside, contacting his employer is a disgusting move.

</comment><comment><USER39> The fact that Alex Stamos from Facebook contacted this researchers employer talking about potential lawsuits to threaten the employee via a proxy is probably the single most damning thing in the entire article.

That to me is entirely unacceptable, if you want to threaten someone then have your legal team send them a cease and desist. Don't go after their livelihood.

<comment><USER40> I'm gutted cause of that, i can not believe the FB CSO contacted his employer , it's such a disrespectful thing to do. Another reason to hate facebook.

</comment></comment><comment><USER41> This is as clear cut a case of full exploit with escalation of privilege all the way to full services source code read access, SSL private keys, full admin AWS credentials, services API keys from Twitter to analytics, email server logins, the list goes on.. all of this without even looking at a single user profile or violating user privacy, and it's not a legit security bug? This has to be worth more than $2500, and I think Facebook sets a bad precedent where folks won't disclose big security issues because of how unclear the TOS are, so that they can avoid embarrassment.

</comment><comment><USER42> October 22nd: Weak passwords found and reported. Also grabbed the AWS keys from the config file.

October 24th: Server no longer reachable. Tested keys and they still worked, assumed to have went on a download spree.

Seems like this is the biggest issue with how Facebook handled this case. No one looked to see what Wes accessed when he logged in with the weak credentials? No one realized he could have accessed the AWS key?

To treat what Wes found as a minor bug and then fuck up like that is sort of hilarious.

</comment><comment><USER43> Ridiculous.

This is why many security professionals become disillusioned with bounty programs. This story is not uncommon at all.

Bounty programs, while presenting a tempting incentive to practice one's skills are a very poor income strategy.

You are essentially working, unpaid, for organizations who are just as likely to ignore you (or report you to law enforcement) as they are to pay you for your findings.

No wonder so many young talented security pros are easily tempted to trade their findings for the safety of a crypto transaction with an anonymous buyer than they are to submit them through official channels.

</comment><comment><USER7> Wait a sec.

Look at his timeline again.

He tested the AWS creds in October.

They shut the server off on October 24.

He reported the AWS creds in December.

Did he tell them about the AWS creds before then? His mails don't say that he did.

If he didn't, _why didn 't he?_

<comment><USER44> Exactly. This is extremely shady behavior, I'm sure if he (a) reported the S3 creds as soon as they were discovered, and (b) did not start randomly downloading everything accessible onto his personal device, this would have turned out a lot differently.

</comment></comment><comment><USER45> My two cents.

It seems that people defending Facebook's behaviour in this thread have collectively lost sight of what the point of a bug bounty is to begin with - to encourage people to report issues, rather than sell them.

We now have people arguing that "it is not acceptable to pivot beyond the initial intrusion for a bug bounty", even though _a malicious attacker would have done the exact same thing_. As long as standard no-damage rules are followed, where's the problem?

The bug bounty program is working exactly as intended, but the researcher is getting dinged over arbitrary rules. As somebody else here mentioned already: the reason blackhat work still pays, is because such arbitrary and bureaucratic rules _do not exist there_.

We should not forget that bug bounties are a tool, not a goal - the goal is to convince researchers to report rather than sell, and _every_ part of a bug bounty and its rules must be designed accordingly.

Also: Why the hell were those AWS credentials not revoked immediately after compromise? This constitutes a grossly negligent failure on Facebook's part to assess impact, _on top_ of their existing failure to have the "keys to the kingdom" on a single server to begin with.

And frankly, that failure only reinforces the need for the researcher pivoting into further systems, rather than just keeping it to a PoC - <USER2> evidently, _nobody_ is going to assess impact at Facebook, if the researcher doesn't do it himself.

<comment><USER46> This is an excellent point, but there's a good answer to it.

The purpose of a bug bounty is _not_ to encourage a particular individual to report an issue rather than sell it. The purpose is to encourage _more_ people to get into the business of finding and reporting bugs _before_ the people who are in the business of selling bugs to criminals find them and sell them. If, in the process, some black hat researcher _also_ decides to report some particular bug rather than facilitate a crime, so much the better - but you can't rely on that, and you shouldn't design a bug bounty program around it.

In other words, you're not _competing_ with the black market. Instead, you're _paying_ to improve your security, and accordingly, you want to get the most bang for your buck. Finding previously-unknown entry points is high-value. Finding internal pivots is extremely _low-value_ because they are ubiquitous, and your infrastructure is already designed around the assumption that they are ubiquitous.

Which isn't to say that you aren't interested in finding the internal vulnerabilities and eliminating them. You are. Which is why you conduct penetration tests. But pen tests are big deals, with rules of engagement around them. You deliberately give the testers elevated internal access so they can test under the assumption that there may be an entry point you don't know about. You establish ongoing communication between the testers and the clients, especially at any potential pivot or escalation point prior to proceeding. You don't run a pen test by opening it up to anyone who wants to give it a whack and hoping that they'll tell you about it afterwards (i.e. a bug bounty program). That's an insanely high-risk, low-value way to discover your internal vulnerabilities.

</comment></comment><comment><USER47> It's clear to me after reading _between the lines_ of both sides of the story, that Instagram/FB sec team screwed up not acknowledging the severity of the bug and paying accordingly to the researcher.

Why get mad about a "low level bug"... I mean, if you can dump private user pics from a photo sharing app, how is this low level? really?

It's also pretty clear that the researcher shouldn't have dumped data although most likely he reserved this hidden card for later since he was expecting the lowball... but there are smarter ways to reply to lowballing.

IMO poorly managed on both parts.

</comment><comment><USER48> An interesting decision on Alex's part to only pay the $2500 for the RCE bug.

On one hand, this signals to anyone else who might want to disclose security issues that Facebook bounties don't pay out anywhere proportionally near the full potential damage impact of the issue.

On the other hand, if they pay out a lot more now, they're signalling that if you find a vulnerability, you need to dig deeper in order to have insurance in case Facebook gets stingy.

Probably the best outcome would have been to pay out a more proportional bounty, even though Wes' exploration was beyond what's generally acceptable, so that Facebook's bounty program reputation is preserved.

That or press criminal charges to discourage any other researchers from going over the line.

</comment><comment><USER49> It's not the main point of the post, which is Facebook's response to the researcher, but I'm really surprised that they're storing unencrypted secret keys and source code on S3. They trust Amazon a lot and have no fear that somebody could eavesdrop Amazon servers (if I were a black hat I'd go for the accounts of the big guys, not for the one of a random guy)

[http://www.exfiltrated.com/research-Instagram- RCE.php#One_Ke...](http://www.exfiltrated.com/research-Instagram- RCE.php#One_Key)

I wonder what any claim of protecting user's privacy is worth when they leave their credentials unprotected in that way.

[https://www.instagram.com/about/legal/privacy/](https://www.instagram.com/about/legal/privacy/)

"We use commercially reasonable safeguards to help keep the information collected through the Service secure [...]"

Ops.

I can imagine why they didn't appreciate the efforts of the researcher. Hopefully they'll change their current practices.

</comment><comment><USER50> The initial bug in Ruby/Rails is striking in its stupidity.[1] You can send something to Ruby/Rails in a session cookie which, when unmarshalled, stores into _any named global variable in the namespace of the responding program_. It's not a buffer overflow or a bug like that. It's _deliberately designed to work that way_. It's like doing "eval" on untrusted input. This was on YC years ago.[2] Why was anything so idiotic ever put in Ruby at all?

Something like this makes you suspect a deliberate backdoor. Can the person who put this into Ruby/Rails be identified?

[1] [http://robertheaton.com/2013/07/22/how-to-hack-a-rails- app-u...](http://robertheaton.com/2013/07/22/how-to-hack-a-rails-app-using- its-secret-token/) [2] [https://news.ycombinator.com/item?id=6110386](https://news.ycombinator.com/item?id=6110386)

<comment><USER25> I think you're overextrapolating here, though I admit my knowledge on this isn't totally up to date.

As I understand it, Ruby's Marshal function, which takes text data and deserializes it, _is not safe by default_. So, is that a flaw of Ruby? I _guess_...except that this kind of serialization seems to be a standard feature in languages (well, Ruby and Python, the two things I currently use):

[https://docs.python.org/3/library/pickle.html](https://docs.python.org/3/library/pickle.html)

> _Warning The pickle module is not secure against erroneous or maliciously > constructed data. Never unpickle data received from an untrusted or > unauthenticated source._

So the true bug seems to be that in Rails ActiveSupport (in a deprecated class, which uses some of Ruby's fun meta magic to deal with missing methods -- so basically, the classic obfuscation of functionality as a tradeoff for some sugary magic, all in a deprecated function that likely no one revisits), you can trigger a set of functions and routines in which the final decoding step, for whatever reason, ends up invoking Ruby's Marshal (via Rack: [http://www.rubydoc.info/github/rack/rack/Rack/Session/Cookie...](http://www.rubydoc.info/github/rack/rack/Rack/Session/Cookie/Base64/Marshal#decode- instance_method))

<comment><USER51> Also, only the server is allowed to put things into the session cookie, which is enforced by checking the cookie's signature which is generated from a key that only the server is supposed to know. Using a "native object" serializer (like Marshal or pickle) for session data and storing the secret token in a file that is easy to accidentally check into source control are both _stupid_ things to do, but they're also common mistakes and you have to do both at the same time for this attack to work, so it seems quite overboard to suggest it was done deliberately.

<comment><USER52> Completely right. If the secret server token is compromised, it is presumed that you can fake any data. Should that allow for RCE? That's where Ruby steps in and provides the double whammy.

</comment></comment></comment></comment><comment><USER53> Posting this write-up might be the last thing the researcher should have done --from a criminal liability perspective. First, the negative press might serve to piss off Facebook (who could have some perspective we are not privy to here). From Facebook's angle, the criminal aspect here may be a much closer issue, and this write-up could serve as the tipping point. Second, as a party admission, this post is could very well be admissible against the researcher at trial. Without a doubt, it can be used to contradict any testimony he might provide in defense of his actions here. (So, you HAD read the ToS, correct?) Even without Facebook's "pressing charges", a US Attorney with political aspirations might just decide she has enough here to move forward against the researcher in an effort to appear "tough on cybercrime". This whitehat stuff is murky territory for sure.

<comment><USER54> I can't see Facebook ever pursuing the criminal angle in this situation. I actually wonder if Alex's boss isn't a little unhappy with his response because it will make people think twice about their bug bounty (just look at the backlash here). The bug bounty was put out there so that people don't use or sell exploits as blackhats.

<comment><USER53> Facebook doesn't have to "pursue" criminal charges, however. It's the Government that brings criminal charges. In this case, Alex would just be a witness (willing or otherwise) the Government used to produce evidence of the researcher's crime. There is a mistaken understanding that if the "victim" of a crime doesn't "press charges", then there is no criminal liability. However, the "victim" is really only a witness to the actual crime in the eyes of the law. Here, the researcher has arguably confessed to a number of computer crimes, and if a DA/USAO or the DOJ were interested in making a statement, they might have enough evidence to indict the researcher on the strength of this post alone. Facebook, while perhaps not interested in "pressing charges", would have to comply with a criminal investigation here.

</comment></comment></comment><comment><USER55> I don't see how the CSO's response makes sense for Facebook's security interests. As CSO, it is in your interest to allow a researcher to exploit an RCE to its furthest. Otherwise, you would only ever allow researchers to inoculate your outest layer of protection, while leaving any inner level untested and thus less secure.

If indeed only credentials and technical information were obtained, all aimed at finding more security issues, Facebook should be thankful for finding all the vulnerabilities across all their security layers.

</comment><comment><USER56> If accurate (which it seems to be), a very disappointing handling by Facebook.

<comment><USER57> Either way, it's awesome for the world. This kind of attack is great to tell people one more reason why they should not trust Facebook, WhatsApp, Instagram, etc. It'd only have been better if someone malicious had done it and made some data public (perhaps slightly redacted).

In particular, it might help with Signal vs WhatsApp.

</comment></comment><comment><USER44> When reading the author's article, it would certainly be easy to grab the pitchforks. It is actually a pretty interesting/useful vulnerability that some low-level AWS keys were able to be escalated to some highly privileged keys, and that none of these keys where IP-whitelisted.

However, the biggest issue I see here is that the author (in their own timeline at the bottom of this post) says that they discovered the AWS keys on October 24, yet they did not report this to Facebook until December 1 (in the meantime, they were having various discussions with Facebook about whether their other submissions were valid). That is seriously concerning behavior, if you find come across some live AWS keys this should be reported immediately, you should absolutely not just sit on them for over a month as if they are some sort of bargaining chip.

</comment><comment><USER58> If accurate, seems like a pretty counterproductive way to handle this.

</comment><comment><USER59> Alex Stamos (Facebook CSO) just posted an official response:

[https://news.ycombinator.com/item?id=10755060](https://news.ycombinator.com/item?id=10755060)

</comment><comment><USER60> Cached version: [https://webcache.googleusercontent.com/search?q=cache:vR9o3U...](https://webcache.googleusercontent.com/search?q=cache:vR9o3UYqgIoJ:exfiltrated.com/research- Instagram-RCE.php&hl=en&gl=us&strip=1&vwsrc=0)

</comment><comment><USER61> Why call the CEO and not his Mom?

</comment><comment><USER62> On the one hand I got a little squicked in the story when he started cracking passwords, but on the other hand I kind of assumed that bug bounty systems would want the tester to find out how deep the bug goes. Otherwise the depth of your security isn't being tested.

</comment><comment><USER63> The lessons i learned here are: 1) any RCE vulnerability of Instagram leads to unrestricted access to user data. Facebook knows it, does nothing about it. 2) facebook will not pay you your bug bounty reward, but will complain to your employer.

</comment><comment><USER64> I really don't want to imagine what would of happened if he wasn't part of the bug bounty and instead after malicious intent how bad things would of gone.

</comment><comment><USER65> Looks like the sites' down. Mirror/Google cached page: [http://webcache.googleusercontent.com/search?q=cache:vR9o3UY...](http://webcache.googleusercontent.com/search?q=cache:vR9o3UYqgIoJ:exfiltrated.com/research- Instagram-RCE.php+&cd=2&hl=en&ct=clnk&gl=us)

</comment><comment><USER66> It's really simple. This is the beginning of the end of Facebook. With their fake clicks on their ads and what not.

</comment><comment><USER67> imo Facebook should be grateful for people like this instead of burning them

<comment><USER18> Indeed. I can somewhat understand the fearful reaction, but ultimately it hurts the company's rep.

</comment></comment><comment><USER68> I'd like to see a service where a company's source code/database/confidential info is placed in escrow pending the payout from a bug bounty. Or, perhaps more likely, some sort of 3rd-party arbitration.

<comment><USER69> Good luck finding an escrow to not only trust, but would be willing to take the heat for that one.

To be a trustworthy escrow, you must have a good reputation or track-record.

There's near no anonymous escrows that could provide a service trustworthy enough to handle this. And going the non-anonymous route would be near impossible, Facebook would litigate an entire country over this.

</comment></comment><comment> henley-cs that's a lot of posturing on both sides. FB had some severe vulnerabilities that the author certainly pointed out. And the author could have read the bucket contents without downloading them. FB clammed up. The author overreached. Neither ends up really winning anything here. Tis a shame.

</comment><comment><USER70> Nerd owns FB and wants to rub it in their face. FB power plays nerd. Nerd publicly pawns FB in retaliation.

</comment><comment><USER71> CSO slaps a legal threat to a security researcher and talks about ETHIC? Good job man, gooooooooooooooooooooooooooooooooood job.

</comment><comment><USER72> Bad form on Mr. Stamos' part.

edit: if it's indeed true, but I have my doubts that's the case. Hard to say either way.

</comment><comment><USER73> I thought their stack was django?

</comment><comment><USER74> > Ruby 3.x

Rails 3.x _

</comment><comment><USER75> Is it normal for security researchers to use Windows for their OS?

<comment><USER76> Not good ones!

</comment></comment><comment> guard-of-terra Once again we see how people act hard-ass in sight of gaping vulnerability in their system. Be it law system, computer system or moral system, you will see denial and intimidation.

We should have "pastebin hat" list and Facebook should definitely be on it.

The problem with humans is that they will rather go extinct over such things than behave properly. You could try to teach us by painful example but death will probably come first.

</comment><comment><USER77> "As a researcher on the Facebook program, the expectation is that you report a vulnerability as soon as you find it. We discourage escalating or trying to escalate access as doing so might make your report ineligible for a bounty. Our team accesses the severity of the reported vulnerability and we typically pay based on its potential use rather than rely on what's been demonstrated by the researcher."

Well, FB feels your bug bounty is worth $200? Strike that figure. We feel like your bug bounty is worth a $100 advertising credit, if you buy $100 in advertising? Next time just report the bug. Thanks!

(I don't know if my innate dislike of FB, or I feel it shouldn't be up to a company to determine what they feel a bug is worth? If you are going to have a bug program--put in some Very solid rules? They shouldn't be just winging it at this point? It's not some cute little start up? It's a huge machine that's making a fortune off it's victim?

I'm still not sure if FB really cared about this hacker's escalation of a potential attack, or it's about money? Would I want a hacker to show me my vulnerability with my clients information--no, but make that crystal clear in the TOS.)

</comment><comment><USER78> Am I the only one mildly annoyed that the author constantly conflated Rails and Ruby?

<comment><USER79> nope I was too. Interesting illustration (assuming it wasn't just a typo) that exploitation of vulnerabilities doesn't necessarily require deep understanding of the tech. stack in question.

<comment><USER80> And on the flip side, deep understanding of the technology stack in question doesn't necessarily lead to implementing it securely. This is division of labor at work.

</comment></comment></comment><comment><USER12> In general, if you have a green handle, you shouldn't be commenting on things like this. Otherwise we'll have sock puppets galore muddying the waters.

<comment><USER81> What does a green handle indicate by the way? I checked the FAQ and there's nothing there.

<comment><USER82> _green handle_

New account, IIRC less than 2 weeks old. The name is colored green. But I've seen it not be consistent, where some posts are green, others aren't. All in the same thread.

<comment><USER83> It's more complex than just creation date. Somewhere in there it involves votes cast on your posts, which is why you might see someone's name switch colors from one post to another in the same thread (the system doesn't go back and switch name colors on previously-created posts). IIRC the exact mechanism isn't public.

<comment><USER84> No, it's simpler than that—just a function of account age.</comment></comment></comment></comment></comment>


The Usability of Passwords - <AUTHOR> http://www.baekdal.com/tips/password-security-usability <comment><USER2> Off-line attacks (when the password database has been dumped) are much faster than on-line attacks (depending on how the passwords are stored). For example, unsalted, non-iterated md5 hashed passwords can be tested at a rate of 600 million guesses a second on a modern video card with the right software.

<comment><USER3> Off-line attacks typically target the entire password file rather than a single password in the file. It goes without saying that only hashes should be stored in the file. Simple hashes are still susceptible to rainbow table attacks, so one should use a different random salt for each password. Algorithms like MD5 and SHA1 are also kind of weak with today's computing power, so something like SHA256 should be used. A hash that requires repeated application of the algorithm is also useful since it requires more CPU power to generate.

</comment></comment><comment><USER4> You can also try Password Gorilla ( <https://github.com/zdia/gorilla/wiki> ) to create, store, manage, and make use of all your passwords.

</comment><comment><USER5> Nice writeup. I used to call passwords with multiple words a "pass-phrase."</comment>


Your advertising makes me think you hate me. - <AUTHOR> http://esm.logic.net/2010/07/08/advertising-and-respect/

<comment><USER2> I think hatred is a strong word. Most advertising is simply brain-dead. Most marketers are Internet-clueless. Mainstream sites (who ought to know better) are the worst offenders. The people handling ad inventory for mainstream sites (cough cough NYT YouTube Huffington CNN cough cough) should simply be fired and repeatedly beaten with a rubber chicken.

Encourage people to:

\- Use an adblocker (always). Never turn it off for any reason.

\- Use plugins like Readability.

\- Prefer RSS feeds to front pages (less ads)

\- Shun and avoid sites that carry obnoxious advertising

\- When you come across a piece of advertising obnoxious enough to make you angry, send the site owner an email. These emails matter. Site owners obsess over them.

We want to get to a point where the ads-for-content business model is broken. If your company (let alone your personal blog) can't figure out how to create useful, compelling content with tasteful advertising, your company doesn't deserve a place in the new market.

One more thing: if you ever see a site that uses double-underlined hyperlinks that spawn an obnoxious floating popup dialog from hell on hover, simply navigate away without reading another word. No legitimate content provider uses this hellishly offensive advertising form, and authors who use it deserve not to be read.</comment>


Beepi Winding Down After Burning Through $150M - <AUTHOR> https://www.wsj.com/articles/beepi-winding-down-after-burning-through-150-million-1487203816 <comment><USER2> There's an instructive lesson here in how both valuation and annual run-rate are meaningless numbers without a sound fundamental business underneath.

Beepi was valued at $500MM and had an almost $200MM annual run-rate, yet evaporated and is now worth absolutely nothing.

Who else out there has 9, 10, or even 11-figure valuations and high revenues but is actually a worthless business?

<comment><USER3> Oh weird, this exact comment was also posted on reddit (r/business)

What's going on?

<comment><USER2> Wasn't by me.

</comment></comment></comment><comment><USER4> Learn from this. High Level Strategic planning & market research is often underrated by the Investors & Founders, that is why so many fail. And I can say this definitively because the reasons for failure can often be traced to one of these two reasons:

1) We expanded too fast - the result of poor stragetic planning

2.) The market for our products was weak - the result of of limited or no market research

In Beepi case it was reason (1) they expanded too fast. Can't imagine what they were doing with 300 employees, technology should have been used to make them more efficient.

Investors are more concerned with college pedigree yet that has not limited failures. They don't know what they need to know until it is over.

<comment><USER5> In many cases, you don't really know #2 when you start, and #1 is a matter of timing and funding. I view this as a failure in the Venture funding process. Companies do #1 before validating #2.

<comment><USER4> Yes you do know #2 when you start. If I'm working on a cure for (name your sickness) you know there is a market. You're doing it wrong if you don't know #2 when you start. Don't be a solution looking for problem/market see: Is Your Product a 'Vitamin' or 'Painkiller?' [https://www.entrepreneur.com/article/230736](https://www.entrepreneur.com/article/230736)

<comment><USER5> Many startups haven't figured out monetization at the beginning, that's why they search for Product Market Fit. If you do MVPs properly, you won't have burned much money on the way.

<comment><USER4> Not figuring out monetization at the beginning is a problem, typically leads to issues see "Inside Medium's meltdownMedium's meltdown", most smart founders have figured it out they are just being coy. If one of your monetization scheme involves selling your company you're not going to announce that to everyone. Monetization is not hard to figure out if you're solving a problem, having no strategic monetization plan early is poor strategic planning.

</comment></comment></comment></comment></comment><comment><USER6> I hate seeing things like this.

As an entrepreneur it's frustrating that I've built a business, in a growing space, $300k ARR, consistent growth, a few employees, no debt and a well defined path to 10x growth that's not built on any (bulshit) models that VC seems to love. And for some reason it's very hard to find funding that's not from Wall Street guys (who love models that earn).

Hey VCs! I can burn less of your money a little slower!! Hit me up!

<comment><USER7> VCs invest in people they know and people who know people they know. Need-ta fix that first, but those peeps might not be the type of peeps you wanna know.

"The game is the game."

<comment><USER8> I think this is an underappreciated fact... SV (but not exclusively SV, it's worse in academic science, for example) runs a pretty insidious narrative of how the entrepreneurship game works, that I don't think is at all accurate.

</comment></comment></comment><comment><USER9> I bought a car on Beepi, and it was a great experience, much better than buying a used car from a traditional dealership or a private party (e.g., Craigslist). One thing that struck me as particularly crazy, though, is that they allowed you to charge your entire purchase to a credit card! That was great for me, since I got a ton of credit card points out of it, but it didn't seem very sustainable, and I guess it wasn't.

Shift (one of their competitors) also seemed quite nice, but they didn't allow you to charge your car to a credit card, so that was one factor in my decision to choose Beepi instead.

<comment><USER10> I also bought a car from Beepi, and it was also a wonderful experience for me. I chose them because all of the local car dealers scoffed when I offered to pay them in Bitcoin. So I went online, pressed a few bottons and bought a car online from Beepi with Bitcoin, which completely eliminated one of the most painful parts of buying a car (dealing with the bank).

Of course at the time I thought it was incredible that in 2015 I could purchase AND PAY FOR a new car without leaving the comfort of my couch. But in retrospect if I would have paid in dollars and kept the Bitcoin, or waited until 2017, I could have bought a Lamborghini!

</comment></comment><comment><USER11> Their "we will buy your car if it doesn't sell in X months" guarantee was the most egregious unforced adverse selection I've seen.

<comment><USER9> That's a good point. Beepi seemed like they were just way too generous, in general. (See my comment elsewhere in this thread about them allowing you to charge your entire car purchase to a credit card.)

</comment></comment><comment><USER12> Founded in 2013, winding down in less than four years. There's a lesson about burn rates here.

<comment><USER13> How the hell do you burn through $37.5M a year? It's a used car marketplace? How...?

<comment><USER14> A ton of ads on FM radio would be my guess, based on on how often I heard them.

<comment><USER15> Interesting... I never heard or saw a single ad for them. Literally the first time I am ever hearing about Beepi.

<comment><USER16> The industry is pretty geographically fragmented. Beepi was apparently mainly in California, though they didn't seem to have much of a presence here in Socal. The competitors they mention in the article - Vroom and Shift - I've never heard of, so I assume they are centered elsewhere. I know someone who works for Carvana, so I know they are also regional and expanding (ATL and PHX mostly, I think).

The industry is used cars, so it's a product buyers generally want to see in person and it has to be delivered to them. So physical location is more important than many tech startups.

</comment></comment></comment></comment></comment><comment><USER17> Sad to see them go, there are so many things wrong with the way Americans are treated when buying and selling a car. Even though I work for a company in the same space it was great to have a company like them around to keep us on our toes.

<comment><USER18> Most people understand that like trading in anything used, you get what you bargain for. The quality varies, prices vary and you risk buying crap sometimes. Don't like that? Pay a bit more and buy extended warranty or precertified cars.

To sell your car, there's KBB, carmax, cars.com and any dealer you want to buy a car from.

Beepi was just one of the many options (no hassle no haggle). However, instead of being a marketplace like cars.com, it took ownership of the transaction probably with hopes to take a bigger chunk of the transaction but effectively became a dealer. Car dealer margins are like 2%. At a 5x multiple, it would be worth 10% of Sales.

</comment></comment><comment><USER19> What is their business model? What's their monetization pipeline?

</comment><comment><USER20> Was this just Ebay for cars?? Not really that clear. "The Mountain View, Calif.-based startup, founded in 2013, was operating an online marketplace for used cars."

<comment><USER21> The eBay of cars is eBay. eBay Motors is hugely popular.

</comment></comment><comment><USER22> How's Shift doing?

<comment><USER23> I hope they're doing well. We got a car from them few months ago, it was so much better than going to the dealer.

<comment><USER24> Same, sold my car through them, and recommended a friend to the same. Great experience all around.

The fact they were willing to deal with cars older than 6 years was the only reason I looked at them over Beepi.

<comment><USER25> I heard they're burning 2-3M/month and on a lifeline at this point. SF is "close" to breaking even.

</comment></comment></comment></comment><comment><USER26> That is too bad. I was strongly considering them for my next car purchase.

</comment><comment><USER27> Beepi's business model is not scalable at all. I would be very surprised if any experienced investor has a dime in it.

</comment><comment><USER28> Paywall workaround

[https://www.facebook.com/l.php?u=https://www.wsj.com/article...](https://www.facebook.com/l.php?u=https://www.wsj.com/articles/beepi- winding-down-after-burning-through-150-million-1487203816)

<comment><USER29> Not sure why, but this paywall workaround goes through facebook. It does work, but it goes through facebook.

<comment><USER30> Because WSJ wants to have their articles shared on facebook viewable, but throw a paywall on other attribution sources.

Like, I also do not have a WSJ subscription, but my email subscription to the Volokh Conspiracy gets me links to readable articles.

</comment></comment></comment><comment><USER31> Question: now that the Google workaround no longer works for WSJ links, are they even allowed on HN? @dang has implied that paywalled articles without workarounds aren't allowed.

<comment><USER32> Use this bookmarklet someone posted in HN a few days ago:

javascript:window.location="[https://m.facebook.com/l.php?u="+encodeURIComponent(window.l...](https://m.facebook.com/l.php?u="+encodeURIComponent\(window.location.href\);)

<comment><USER31> For those that read this, here [1] is a draggable bookmarklet that will instantly unlock WSJ articles based on the above code:

[1] [http://salzeko.com/wsj](http://salzeko.com/wsj)

But 99% of HN users are not going to see this and the whole reason the "web" link exists is to aid in the Google workaround, because that was the gold standard until now. WSJ has now put itself into a special class of sites. Unless I post my link on every single WSJ story submitted to HN, non- subscribers (the vast majority of people seeing it here) won't be able to read it, which means they can't discuss it etc. Therefore it would make sense to me that WSJ links should be blocked here.

</comment></comment></comment><comment><USER33> Silicon valley mental bubble. I've never heard of this company (not a problem), but there seems to be a SV problem I see constantly repeating:

\- Some people like this thing. There could be a market.

\- Investor cash gushes in; fast fellation or get no orgasm!

\- Startup uses up all of the money somehow on bullshit or self-payment of execs.

\- turns out a good thing is now shit because VC's jizzed them full of undeserved cash, the founders sucked up the money, and the staff no longer has any incentive to deliver.

\- Hacker News article.

Venture capital is a major problem here. Rich idiots keep giving out money to people that want money, hoping that one of them will become a unicorn. News flash: the bubble is gonna pop again because venture capitalists are basically all idiots. They gamble money they can lose. However, the average person can't handle those fluctuations.

<comment><USER34> > _VC 's jizzed them_

Please don't do this here. It's kind of gross. Also, please don't post overheated rants to HN. It lowers the signal/noise ratio, which is what we're hoping to optimize for.

Thoughtful critique is welcome. One method for turning overheated rants into thoughtful critiques is to (a) edit out name-calling and pejoratives and (b) add information, such as specific examples.</comment></comment>


'Learn Ruby on Rails' is free today - <AUTHOR> http://learn-rails.com/download-offer.html

<comment><USER2> It's been almost three years since I began spending nearly every available evening and weekend learning code and web dev. It's been a great adventure. However, contrary to the advice I was given I believe Ruby on Rails is not an effective place to start learning web dev, it certainly wasn't for me.

When I started, I had limited knowledge of HTML and almost no experience with CSS, Javascript, SQL or HTTP. I felt bombarded going through Michael Hartl's book (ruby.railstutorial.org), for example, trying to pick up all the concepts mentioned above plus the ideas of Unit Testing, ActiveRecord, the MVC paradigm, Rake, GIT, Migrations, layouts, partials and UNIX, to name a few. Nothing was sticking.

After now learning some programming fundamentals through an awesome Coursera course, learning C++ and Python to make small game mechanic, digging into PHP and launching a few fun websites, building a few projects with raw HTML and CSS while having lots of fun with jQuery and Javascript I feel I am ready for and can appreciate Rails. I'm now approximately 4-6 months from launching my first commercial product and this book will be perfect for my current purposes. I'm 25 pages in and can say that I love it's narrow focus (not including unit tests, for example) and also it's thorough explanation of all core concepts. I've backed the Kickstarter and can't to keep learning! Sorry for the long post HN! Long time lurker, big fan.

<comment><USER3> That's interesting to hear. I'm a system administrator and would like to learn web development. I was planning on starting with Rails. I know the basics of HTML and CSS and am pretty experienced with SQL. Do you have a route of learning you recommend?

<comment><USER2> If you have experience with SQL you might be far better off than I was. Try starting with the book in this thread; it seems like an excellent starter book and covers many concepts that frankly, myself and others had to piece together from Stack Overflow questions. The best advice I can give you is to start with a project; what do you want to make? If you're set on Rails, jump into Ruby using the nice online book Learn Ruby the Hard Way. Consider checking out Rails for Zombies for a nice, fun intro into Rails and then dive into the book listed in this thread. Best of luck! Feel free to reach out if you have any questions!

<comment><USER3> Thanks for the reply. I do have a couple pretty simple projects in mind. This may be the impetus I need to go ahead and get started. Thanks!

</comment></comment></comment></comment><comment><AUTHOR> Don't miss the "name the cat" contest. On the cover of the book, there is a fluffy white cat who has no name. Rails developers are often playful and light-hearted. The book (and the cat) reflects that spirit, not just to make Rails less intimidating for beginners, but to give newcomers a feel for the community.

[http://learn-rails.com/name-the-cat.html](http://learn-rails.com/name-the- cat.html)

You can suggest a name for the cat until the Kickstarter campaign ends, Saturday at 5pm Pacific Time.

</comment><comment><USER4> Thanks for this. I already have tons of experience in Rails, but I learned by doing and not through a book so I reckon I have some holes in my knowledge here and there.

I'm experimenting with hybrid learning of both doing "learning by doing" by doing projects and "learning by the textbook" by getting the foundational ideas behind Ruby and Rails, and seeing if there is a benefit to combining these two systems, for my own purposes of learning languages and learning in general, and to have something to say to the many friends that I have that want to learn Rails :)

This looks like a pretty comprehensive beginner doc, so thanks for that! Backed it on KS.

<comment><USER4> Turns out I don't really have any holes in my knowledge that needed to be plugged from this doc, but this is a solid resource for those learning Rails. Very detailed.

</comment></comment><comment><USER5> This is a really good book for teaching beginners Ruby on Rails. But, in my opinion, what makes it stand out compared to a lot of other books on this topic is the following:

I'm using Rails for a few years now and I still have problems to figure out where to start when I have to explain it to somebody who doesn't know anything about it.

Many books just throw their readers into a topic. This causes a lot of confusion early on, which will (hopefully) be reduced while reading the book. I don't like that approach very much.

I think, this book here does it the right way: It first explains the web and by which technologies it is driven. Then it tells how Rails fits into the picture.

What I also really like are the short explanations of user stories, software development methodologies and agile methodologies. I think it is important that new developers have at least heard about those topics even though they may not know how to use them in the beginning.

Good work!

</comment><comment><USER6> I started working with rails a few months ago. I skimmed the book in about 3 hours from start to finish while skipping the parts I knew I was comfortable with.

The book is really good and 100% worth reading if you're new to rails. I hope the author gets his money from kickstarter because he deserves it.

</comment><comment><USER7> I backed the KickStarter near the beginning of this campaign to get access to alpha version of the book so I could review it for a few "new to web programming" friends of mine. I thought it was a really good resource for my friends that already program in something (say Windows Forms) and wanted to make the leap to doing web applications. Thanks Daniel!

</comment><comment><USER8> Thanks, would it be possible to get it in MOBI format. (I have bad experience converting coding books in calibre)

<comment><USER9> second this - I would like all my books to be readable on the computer, phone and the kindle. PDF is really bad for this and would really prefer .mobi

<comment><AUTHOR> The mobi version will come with the final release. I'm not happy with the formatting of the code samples in mobi so I'm looking for good production tools (I'm using the kitabu gem now).

</comment></comment></comment><comment><USER10> I'm a backer of Daniel Kehoe's Learn Ruby on Rails ebook on Kickstarter. While I'm certainly not coming from a background of vast experience, I've tried other resources such as Treehouse (which is great by the way), it is VERY approachable and would lend itself to newbies and Product Managers who are learning to become more technical. After a break from Treehouse, I forgot most of the concepts as the stuff I learned had atrophied. When I needed to start fresh, and from a different perspective, his ebook is a great starting point for the absolute beginner.

I think it's awesome that Daniel opened up for people to download the ebook for free. I don't mind the $18 that I ponied up because I believe the value I've received is far beyond that.

</comment><comment><USER11> Why in the book there is not even a paragraph on how to create an authorization system and session management?

<comment><AUTHOR> Sad to say, based on my experience teaching weekend classes, it's difficult to introduce authorization or sessions in a book that's designed for beginners to read in a weekend. "Learn Ruby on Rails" is intended to prepare newcomers for more advanced books. Michael Hartl's book covers authorization so it is a good follow-on.

</comment></comment><comment><USER12> the largest barrier to entry for newcomers wanting to learn rails is getting a dev environment setup

<comment><USER13> This is where tools like [https://www.nitrous.io](https://www.nitrous.io) are awesome. We just hosted a RailsBridge-type event and we used Nitrous. Highly recommend this for teaching.

<comment><AUTHOR> Here's my article about getting started with Rails on Nitrous.io:

[http://railsapps.github.io/rubyonrails-nitrous- io.html](http://railsapps.github.io/rubyonrails-nitrous-io.html)

Nitrous.io is a great way for any beginner to get started, especially for those using Windows.

</comment></comment></comment><comment><USER14> Daniel, how far will you go with TDD on this book? What resource will you recommend to continue learning TDD after the intro in this book?

Will you consider writing another book in the same spirit as this one (for beginners & kept up-to-date) for rails with TDD?

<comment><AUTHOR> TDD is one of the big issues in the pedagogy of teaching Rails. Teach it from the start (Hartl)? Ignore it (most lightweight intros)? Or find a way to introduce it without intimidating beginners? My approach (in a forthcoming chapter) is to encourage testing literacy, that is, to show beginners how to read test code and run tests, so they will be prepared for further study. Michael Hartl's book is good to read after "Learn Ruby on Rails." I also recommend these three books (the first is the newest):

* Aaron Sumner, "Everyday Rails Testing with RSpec" [https://leanpub.com/everydayrailsrspec](https://leanpub.com/everydayrailsrspec)

* Noel Rappin, "Rails Test Prescriptions" [http://pragprog.com/book/nrtest/rails-test-prescriptions](http://pragprog.com/book/nrtest/rails-test-prescriptions)

* Chelimsky and friends, "The RSpec Book" [http://pragprog.com/book/achbd/the-rspec-book](http://pragprog.com/book/achbd/the-rspec-book)

Other resources? How did you learn TDD for Rails?

<comment><USER14> I didn't :)

I use Python/Django and thinking of learning Rails, preferably with TDD. Thanks for the list, I'm sure it will be useful!

PS. I backed your campaign.

</comment></comment></comment><comment><USER15> Thanks! I'm a Rails newbie and this seems to be extremely useful. :)

</comment><comment><USER16> to be honest, this is a just ok book. For ROR beginners, stick with Micheal's tutorial. [http://ruby.railstutorial.org/](http://ruby.railstutorial.org/)

<comment><USER17> Disagree, tried to get my brother to learn Rails using this tutorial and got stuck configuring Git and his remote Github repository. It introduces waaaaay too much information that a beginner doesn't really care about.

Git repositories, test driven development, etc are all things a beginner doesn't care about and doesn't really need to know about when starting out.

<comment><AUTHOR> Just to clarify. My "Learn Ruby on Rails" covers git and GitHub. Readers tell me they like the "time traveler" analog I use to introduce git in a gentle way. My book is for beginners who want to learn real-world Rails, so it covers professional practices including git, user stories, project management, configuration, using APIs, and more.

</comment></comment></comment><comment><USER18> for anyone who hate registrations for downloads ^_^ [http://learn- rails.com/ebooks/learn-rails.pdf](http://learn-rails.com/ebooks/learn- rails.pdf)

<comment><AUTHOR> Here's why I ask you to register to download the book:

1) After working on the book for six months, I'd like to be able to follow up and ask you to contribute to the Kickstarter campaign if you like the book.

2) You are downloading an advance edition of a book that contains code that is likely to change. Within the next week or two, I will release an updated version. I'd like to be able to notify you when the update is available.

3) I am only giving the book away for free for one day, to promote the Kickstarter campaign. If you are willing to provide your email address in exchange for a free copy of the book I am grateful. If you are not, Michael Hartl offers an excellent introduction to Rails that does not require registration or an email address:

[http://ruby.railstutorial.org/](http://ruby.railstutorial.org/)

<comment><USER19> Yes, but why do I have to create an account? I don't want another one off account somewhere.

<comment><USER20> So they they can send you unwanted emails. There is no such thing as a free lunch. In order for you to get the book, you have to give away your contact information.

<comment><AUTHOR> "They" is me, a solo author who gave up six months of consulting income to produce a book to help Rails beginners. Would you care to contribute to the Kickstarter campaign so the book can reach the people who need it? What do you wish to offer in exchange? How about even offering a thank you? Or do you feel you are entitled to enjoy my work, offering nothing in exchange, and encouraging other people to act with no respect or thanks?

<comment><USER21> I understand why you want an E-mail address in exchange for the book. What I don't understand is why, in addition to that E-mail address, do people have to create an _account_ of some kind? Why not just the E-mail address?

The "Get the Book" page does not explain any of this, and left me puzzled as to what I was creating an account for.</comment></comment></comment></comment></comment></comment>


Emacs Artist Mode - <AUTHOR> http://www.cinsk.org/emacs/emacs-artist.html <comment><USER2> How far can we take this? What is literate programming at the extreme?

I often draw when I need to work out an algorithm in my head. I wish there were a way to embed my doodles in code comments. Stuff like circle geometry are hard to explain without dense pixels. I've tried using various literate programming pre-processors that let me write comments in Markdown/HTML and embed whatever, but it makes my UNIX-minimalism-sense freak out, and it's super awkward having to render my source code to HTML and open a web browser to be able to read the comments properly…

<comment><AUTHOR> Emacs org-mode supports a lot of languages [1] and you can mix and match within a file. Howard Abrams literate devops is an interesting example of what org-mode code blocks can do. [2][3]

Org-mode also allows embedding images or source blocks in languages like LaTeX that resolve to rendered images.

[1]: [http://orgmode.org/worg/org- contrib/babel/languages.html](http://orgmode.org/worg/org- contrib/babel/languages.html)

[2]: [http://www.howardism.org/](http://www.howardism.org/)

[3]: [https://www.youtube.com/watch?v=dljNabciEGg](https://www.youtube.com/watch?v=dljNabciEGg)

</comment></comment><comment><USER3> I've used artist-mode with my tablet PC, which works surprisingly well. You can draw with the stylus and everything!

For other ways to produce graphics from text (especially within Emacs), check out the examples in [http://doc.norang.ca/org- mode.html#Publishing](http://doc.norang.ca/org-mode.html#Publishing) : ditaa, graphviz, plantuml... Cool stuff. =)

<comment><USER4> +1 for plantuml integration in org-mode. I have a university class teaching UML and it has been very helpful.

To get the true plantuml "UML IDE" experience, have the exported png open in a window (in the emacs sense) side-by-side with the code. Enable 'auto-revert- mode' on the image so that whenever you eval it it gets refreshed. If you run into problems where the image shows up in binary mode after reverting just enable 'auto-image-file-mode' (keeps it in image-mode).

You can also make it more "responsive" by setting the auto-revert-mode interval to something shorter (by default it checks every 5 seconds if the file has changed). I just defined a new 'fast-auto-revert-mode' function where it turns the mode on after let-ting the interval be 1 second, then added that as a hook for 'image-minor-mode-hook'.

</comment></comment><comment><USER5> You can also combine this with picture-mode[1] which gives a little bit more customisation of characters used. I'm always a bit sad that neither seems to allow you to achieve an extended ASCII 3D look though, e.g:

        ┌╖
        ╘╝

Otherwise emacs would be a brilliant level-designer for various ASCII RPGs of my youth.

[1]: [http://www.gnu.org/software/emacs/manual/html_node/emacs/Pic...](http://www.gnu.org/software/emacs/manual/html_node/emacs/Picture- Mode.html)

</comment><comment><USER6> It feels strange that I need to install Adobe Flash Player to watch a screencast on Emacs.

Wait... is there an Emacs mode for this?

<comment><USER7> I'm surprised people still use it, what is Flash still usefull for ? deploy malwares ?

<comment> david-given Homestar Runner.

Also, Orisinal: [http://www.ferryhalim.com/orisinal](http://www.ferryhalim.com/orisinal)

</comment></comment></comment><comment><USER8> I'm more interested in knowing what was used to toggle in and out of the mode that made everything but the comment disappear!

<comment><USER9> I love Emacs

<comment><USER10> Don't, you may catch something. RSI appears to be going around.

<comment><USER11> Are we doing the flame war thing on Friday night? I mean if we are, I'm up for it. Are we?

</comment></comment></comment></comment><comment><USER12> I have used ditaa[1](warning: sourceforge) with artist-mode to mark some pretty-darn-good-looking system diagrams. It's a pretty impressive piece of work!

[1] [http://ditaa.sourceforge.net/](http://ditaa.sourceforge.net/)

</comment><comment><USER13> I couldn't watch the video on my tablet (video is flash), but I found this youtube video that also talks about artist mode:

[http://www.youtube.com/watch?v=cIuX87Xo8Fc](http://www.youtube.com/watch?v=cIuX87Xo8Fc)

</comment><comment><USER14> This reminds me of TempleOS

[https://youtu.be/sm-W4Tzg9-o?t=662](https://youtu.be/sm-W4Tzg9-o?t=662)

</comment><comment><USER15> Somewhat off-topic: I have been looking for an ANSI art editor for the terminal (Linux or OS X).

Anyone know of anything?

<comment><USER16> Um... that's what this post is about? artist-mode is an text art editor.

You don't need to use Emacs as an editor to use the "applications" built on Emacs, if that's your concern. Just as with any new application you'd have to learn how to use it.

</comment></comment><comment><USER17> Does anybody know of a similar vim plugin? I personally love ASCII diagrams, but there's quite a bit of friction involved in including them in docblocks.

<comment><USER16> I'll say what I said in another comment: Isn't it fine to just use Emacs for this purpose? You don't have to use it as a general-purpose text editor if all you want to do with it is make ASCII art. Just as with any new thing, you'd have to learn a bit, but not that much...

</comment></comment><comment><USER18> Thought many people already knew it well. A convenient feature of Emacs no doubt.</comment>


"Adventurous Female Human" Needed to Give Birth to Neandertal - <AUTHOR> http://www.genomeweb.com/blog/adventurous-female-human-needed-give-birth-neandertal

<comment><USER2> Given it has been proven that up to 4% of the DNA of all humans outside of Africa can be traced to "Neanderthal" origin, this is not as much of a stretch than it first seems.

But this scientist may be crazy to believe his particular dream would ever be realised in somewhere like Europe.</comment>


Microsoft's CEO: Sharepoint is next big operating system. - <AUTHOR> http://bits.blogs.nytimes.com/2009/08/07/microsofts-sharepoint-thrives-in-the-recession/?ref=technology

<comment><USER2> I'm not sure whether the makers of the current OS get to determine what the next OS is.</comment>


From zero to hacker. Our business co-founders' quest to conquer coding - <AUTHOR> http://zerotohacker.tumblr.com/post/34786076426/zero-to-hacker

<comment><USER2> Hats off, man, from another business co-founder who has been doing the same thing for some time. It was surprising to me how quickly I could become competent. Sure, I'm not worthy to unlatch the shoes of our company's technical co-founder, but at least we speak the same language now.

</comment><comment><USER3> I also recommend for node Guillermo Rauch's Smashing Node.js. Also Javascript the Good Parts by Crockford is the cononical language resource for Javascript, once you've reached your inevitable local maximum in just having knowledge of node.js and not much Javascript per se.

<comment><USER4> Awesome, I'll check it out. (I'm the business co-founder in question btw)</comment></comment>


Ask HN: Any problems with the new TLDs? - <AUTHOR> Since I can't find a good .com I'm thinking about using one of the new TLDs.
Is there any disavantages in getting something like mycompany.money or mycompany.services?
Spam filters that will block it for no reason? People who will try to access mycompany.money.com? Are they safe, like, are they all managed by the same company that deals with the .com (ICANN?)? Any TLS/SSL problems?
Another question, is namecheap any good? I found about about them on the github student pack and they offer whoisguard and a free PositiveSSL. Unfortunately it's not a wildcard and who knows when letsencrypt will be ready. I'm not affiliated just want feedback.
Thanks! <comment><USER2> I've never had any major problems with a gTLD and email but I have had colleagues have spam filtering issues. I have used a .io domain and I haven't had a problem, although we don't email too frequently. I must say it is somewhat fashionable with startups now to get gTLDs or cute ccTLD. However, there is an ethical issue with io specifically. [1]

As for my own personal opinion, I'm getting far more used to seeing startups and other services on TLDs other than .com. I think consumers are getting used to it now as well, in fact a lot of clients I work with won't even type the address into the browser anymore. They navigate to it via Google. Also, if you need to change TLDs at some point there are plenty of successful companies that have done so. [2]

Namecheap, it's great. I like using it. I also use Google Domains which is surprisingly nice.

[1][https://gigaom.com/2014/06/30/the-dark-side-of-io-how- the-u-...](https://gigaom.com/2014/06/30/the-dark-side-of-io-how-the-u-k-is- making-web-domain-profits-from-a-shady-cold-war-land-deal/)

[2][http://mashable.com/2013/01/08/business-domain- names/#eBSI4O...](http://mashable.com/2013/01/08/business-domain- names/#eBSI4OgkBqkI)

</comment><comment><USER3> The recent Paul Graham essay (and discussion) is worthwhile reading on the topic of naming and .com domains:

[https://news.ycombinator.com/item?id=10030863](https://news.ycombinator.com/item?id=10030863)

<comment><AUTHOR> I'm not really convinced. About changing my company name I mean, unfortunately I don't have a $ 250,000 spare right now (that's the price they asked!)</comment></comment>


Extortionware is bad but it never killed anyo- never mind - <AUTHOR> https://www.theregister.com/2020/09/18/ransomware_germany_hospital/ <comment><USER2> actual, factual, and no-clickbait source; [https://abcnews.go.com/International/wireStory/german- hospit...](https://abcnews.go.com/International/wireStory/german-hospital- hacked-patient-city-dies-73069416)</comment>


Learning Styles Debunked - <AUTHOR> http://www.sciencedaily.com/releases/2009/12/091216162356.htm

<comment><USER2> Um no. Validity of learning styles research questioned. Less exciting but far more accurate. This is crap journalism.</comment>