Believe you can change   - <AUTHOR> http://www.aaronsw.com/weblog/dweck <comment><USER2> An experience I had as a teenager really drove this lesson home for me, and is partly responsible for successes I've had since.

My Dad had copy of 'Drawing on the Right Side of the Brain' by Betty Edwards lying around. I'd always been really bad at drawing - never progressed beyond the kids-drawing phase, got bad feedback on drawing at school, so stopped.

Anyway, Edwards's theory is that 'bad' drawers don't look at the thing itself and draw its shape, they translate reality into abstract concepts first and then draw what that concept visually looks like. So I'll look at a face, then decide I'll draw the 'eye' first, query my mind to see what an 'eye' looks like, then draw the generic 'eye' shape that everyone draws.

Whereas a skilled artist looks at the eye in front of them - which looks nothing like the standard symbol for 'eye' - and draws THAT.

Edwards has a bunch of exercises to prove this, and one of them triggered a massive epiphany for me.

She had a Picasso sketch in the book which was printed upside down on the page. Her instructions were to copy the drawing, keeping it upside down, and never naming the limb/whatever you're drawing, and never turning your drawing right-side-up until it's complete.

I was sceptical, but decided to test her theory. So I started copying this upside-down drawing, fully expecting it to turn out even worse than usual.

When I finished, I couldn't believe it. The drawing was AMAZING. It looked like someone else had done it. The figure I'd drawn looked alive.

I went on to learn to draw pretty well. So after that, my mind always looked back and thought - well, if I can learn to DRAW, and I was so BAD at drawing initially, I can pretty much learn to do anything.

<comment><USER3>
        ... well, if I can learn to DRAW, and I was so BAD
        at drawing initially, I can pretty much learn to do
        anything.

I used to think like that. If I tried hard and applied myself I could do just about anything...until that sort of thing stopped working. It certainly helped but it won't take you to the stars. It just seemed that no matter how hard I tried, I never got better at what I had in mind.

I think this kind of thinking is helpful but it has its ultimate limits, which seem to be set to 'low' for me.

<comment><USER4> Well I think most of it is time, the whole 10,000 hours thing.

Since we are talking about drawing take a look at MindCandyMan on conceptart.org (His journey sketchbook <http://www.conceptart.org/forums/showthread.php?t=870>)

Post of an example of how far he has come: [http://www.conceptart.org/forums/showthread.php?p=1789531#po...](http://www.conceptart.org/forums/showthread.php?p=1789531#post1789531)

His website showcasing his work: <http://www.jonathanhardesty.com/paintings.htm>

<comment><USER5> >Well I think most of it is time, the whole 10,000 hours thing.

Please stop repeating Gladwell's pseudo-scientific BS.

Putting in a lot of hours is necessary but not sufficient to become excellent at something.

<comment><USER4> I'll be honest I've never read his book but the 10,000 hours fits as an analogy to the hard work that one must put in to be an expert.

Sure 10,000 hours isn't going to make you excellent but focused hard work can and most of the time does.

You can become good in under 10,000 hours I just used it for reference. Maybe you would have preferred this: <http://norvig.com/21-days.html>

</comment></comment></comment></comment></comment><comment><USER3> I think this isn't a good demonstration of trying hard. These little puzzles only went on for a few hours so a person who is highly intelligent but perhaps not so diligent over a long time won't see bad results in this test. The comments here demonstrates survivor bias.

Furthermore, it's easy to quote Alan Kay about perceiving reality, or non- verifiable comments about 80 IQ points, etc, but what about all the Alan Kay-s who failed that you never heard of, that tried harder or were smarter? What about them? What if no matter how hard you try, how long you try, you still fail?

What about people with learning disabilities? What about people who might be mutants? I.e., in the same way our nearest primate relatives are a few percentage points of DNA different from humans, what if having a few hundredths of a percentage point difference in the right direction, away from me, makes the difference? A thousand years of chimp intellect won't produce an aircraft. A thousand hours of me contemplating won't be the same as someone else who is smarter and contemplates for just ten hours. That's just the way it is. I feel like I know this because I'm on the wrong side of that few- hundredths of a percentage points.

Trying hard _is_ important, and trying hard over many years is also important. But for someone like me, the window is permanently shut as far as what ever biology I have been born with compared to people who excel in ways I simply cannot. Not that I haven't tried. It's just that there are limits on all of us, and this method. Some people, fortunately, have less limits on what they can do.

<comment><USER6> There are limits. You cited some very obvious ones.

I have no idea why you think that you are among the "catastrophically limited" as I will call them.

You presumably can program a computer based on your comment history. This puts you firmly in the "not really limited by IQ" camp. You may never be a Terrance Tao of John von Neumann, but every other level of achievement is probably available to you.

Even your own self knowledge of skills puts you above most people I work with. When it comes to overall competency, knowing that you aren't very good at programming puts you above many programmers I know.

Just browsing through your comment history it really seems more like you lack direction for getting better.

You didn't even answer someone's direct question toward you, a question that can really help you focus and find the direction you need to improve: "What are you working on now?"

Assuming that you don't have an answer for that question: I think I found your problem.

<comment><USER3> > You didn't even answer someone's direct question toward you, a question that > can really help you focus and find the direction you need to improve: "What > are you working on now?"

I didn't see it.

My day job leaves me pretty drained. Aside from that, I've been learning more about web-app programming. I allegedly do embedded and kernel work now for a large network hardware vendor so I realized a while ago I need to spread my wings so to speak.

<comment><USER7> Embedded and kernel work? I do web-app programming because I thought I wasn't smart enough to do that stuff!

<comment><USER3> It's mostly commoditized work where I am as well as throughout industry. The glory days of being a branch maintainer are over but there are still device drivers to be made for custom hardware, but a lot of consumer hardware is covered.

But it's mostly patch slavery. You ever wonder why old android phones don't get newer versions of android on them? One reason is that maintaining device drivers across kernel patches is a serious problem. I know of a product that is still using the 2.6.10 kernel because they have changed so much code they can't port it. iPhone doesn't have this problem since there are only, what? Five of them at any time? I guess they could but that's too much effort (slightly above 'breaking a sweat') so OEMs won't do it.

Doing anything with an embedded system always takes a long time. Even moving, adding or changing a single file into a packaged file where a bootable system lives can take a good 20-30 minutes depending on how much has to be rebuilt and how crappy the build system is (always). The deadlines are always short and immediate, too.

My job is mostly herding patches with an antiquated versioning system that never makes any sense, trying to herd machines to duplicate a 1:10,000 bug. Stuff I could have done when I was in school. I think I made a mistake agreeing to work here.

</comment></comment></comment></comment></comment><comment><USER8> Sometimes I believe, Hacker News should have more of this kind of "self hacking" articles. It may seem more like reddit, but it is surely not.

I normally hate self respect, self development books. I feel they are mostly bullshit. HN main page is a great filter for bullshit so I really like these more.

And thinking about change, I also had the introvert/extrovert change for myself. But this was not just me, my friends helped me a lot. If they were not telling me that I was not a problem, but my attitude is a problem. I would never have enough self confidence and would not ever change.

Sometimes I get more introvert, but I know, this is just because I want to be. And whenever I want, I can change.

<comment><USER9> I've also gone through the same process of being a strong introvert and learning to be more sociable. And I thought that was a really excellent application of the idea of the growth mindset for the article to point out. But I've gotta take issue with the idea that learning to be sociable is the same as learning to be an extrovert. It's just learning good social skills and learning to enjoy using them _despite_ being an introvert.

I'm pretty well convinced that introversion vs. extroversion is just a part of everyone's neural anatomy, as much as being right-handed or left-handed is. That is somewhat plastic, but it takes fantastic levels of effort to fundamentally change. In/extroversion is a matter of how you think and what drains or recharges your mental energy, not how good you are at interacting in social groups; those things happen to be correlated, but there are some really awkward extroverts as well as really sociable introverts.

<comment><USER8> I believe you have pinpointed the issue here. I learned to be more sociable and I'm still introvert. Making the distinction is important. Thank you.

But while having transitions, sometimes I really became extrovert. Mostly I like to hold my issues to myself. But sometimes - with the help of booze - letting go of my thoughts is easier.

</comment></comment></comment><comment><USER10> These findings should not be misinterpreted, since it is indeed impossible to reach any goals. A person in their late 20s is extremely unlikely to become an olympic swimmer or a squash player because of physical limitations. And some people will relentlessly try and never succeed.

But believing that you can change is useful because it makes it easier to persist in my efforts to change. Because if I believed that change is impossible, I'd give up on the spot.

I found that I simply cannot believe a statement like "I can get much smarter" or "I can get much better at X", but I found that I can easily (fully, honestly, without reservations) believe that "I can get a bit more smarter", or "my intelligence is sufficient for mastering this material, so I need to push harder", or "I can get at least a bit better socially." These beliefs motivate me and make it easy for me to do the work even when it looks like progress is nonexistent. This is the meaning of believing that you can change.

</comment><comment><USER11> I wonder if the phenomenon of growth-mindset vs. fixed mindset is related to an ability to delay gratification, (another trait with a high correlation to succes in children [1]). That is, the "growth-minded" individuals are willing to slog through frustration and failure, because they know the payoff will be greater in the long run, while the "fixies" can't look past the immediate sense of frustration

[1][http://www.newyorker.com/reporting/2009/05/18/090518fa_fact_...](http://www.newyorker.com/reporting/2009/05/18/090518fa_fact_lehrer?currentPage=all)

<comment><USER12> I think it's not just slogging through it, but associating the slogging through it with success. That is at the end to enjoy slogging through it, or at least embrace it as part of the process. That way you don't have to delay gratification completely, just change your attitude towards what is gratifying.

</comment></comment><comment><USER6> I actually just read this book due to you, aaronsw. Your post on LessWrong where you mentioned it caused me to go out and read it.

I am now aware that ~90% of the people I associate with are very much in the "fixed mindset". It is kind of sad, honestly, because they are all bright people, but you can tell they have essentially stagnated because of their mindset. This includes myself, of course, but I have been slowly realizing the usefulness of the "growth mindset" over the last several years. Now I have a name for it.

Thanks for this. I will be sending your write-up to several of them.

</comment><comment><USER13> "Mindset" by Carol Dweck is one of the greatest books I've ever read. Sadly though, I didn't discover it until the age of 41.

Of equal value is "the War of Art" by Steven Pressfield.

In my opinion, these are the only two "self help" styled books anyone needs.

<comment><USER14> What's the latter book about?

<comment><USER15> The creative process of writing, which trends to anything creative which needs "shipping." The difference between an "amateur" who dabbles at writing, and a professional, the power of pushing through and consistency to complete projects (ship). Additionally, a theory on why we try to hard to procrastinate away from the things we either know, or want, we would do.

Very direct, a bit of "muse" hokiness which most readers I've given the book to can deal with or understand (it is a foil for the author, not a belief). He was a man who failed until his late 40's? or some such, and it is extremely motivating and direct in its instructions.

from Amazon:

"Drawing on his many years' experience as a writer, Pressfield (The Legend of Bagger Vance) presents his first nonfiction work, which aims to inspire other writers, artists, musicians, or anyone else attempting to channel his or her creative energies. The focus is on combating resistance and living the destiny that Pressfield believes is gifted to each person by an all-powerful deity. While certainly of great value to frustrated writers struggling with writer's block, Pressfield's highly personal philosophy, soundly rooted in his own significant life challenges, has merit for anyone frustrated in fulfilling his or her life purpose. Successful photographer Ulrich (photography chair, Art Inst. of Boston; coeditor, The Visualization Manual) explores the creative impulse and presents an approach to developing creativity that, like Pressfield's, will be relevant to artists and others. He identifies and explains seven distinct stages of the creative process: discovery and encounter, passion and commitment, crisis and creative frustration, retreat and withdrawal, epiphany and insight, discipline and completion, and responsibility and release. He also develops his view of the three principles of the creative impulse, which include creative courage, being in the right place at the right time, and deepening connections with others. Rooted in Eastern philosophy, Ulrich's fully developed treatise nicely updates the solid works of Brewster Ghiselin (The Creative Process), Rollo May (The Courage To Create), and Julia Cameron (The Artist's Way). It also supplements Pressfield's inspirational thoughts on overcoming resistance through introspective questions and practical exercises that further elaborate the creative process. Both books are recommended for public libraries needing additional works on creativity."

</comment></comment></comment><comment><USER16> Of the dozens of articles on Carol Dweck that I've read, this is by far the best one. Awesome writeup Aaron.

</comment><comment><USER17> When I read about this research, it changed the way I raise my kids. Given our society's emphasis on intelligence (and the fact my kids are smart), it was natural to complement them on that. I now go to great efforts to make sure they know that smart alone isn't enough and, when they are putting good effort into something, I acknowledge the effort and not the results. Hopefully it is pushing them towards being "growthies".

</comment><comment><USER18> Aside from the book recommended in the post, Learned Optimism by Seligmen is another dealing with "learned helplessness" and how to combat pessimism. It frames the struggle as optimist vs pessimist instead of growth vs fixed mindset.

</comment><comment><USER19> I don't know if anyone else has had this experience, but for awhile in my teens to early 20s, I strived really hard to be a good musician. Everytime I would notice a marked improvement, I would have this almost excruciating sense of being overwhelmed. It was like almost forcing me out of reality, because I couldn't simply believe it. Sure enough, though, the next day I'd work on music I would be at a different level of sorts and would be on to tackling the next challenge.

Due to the fact that music doesn't really pay all that well, and I went for a comp. sci. degree, I've ended up as a software developer. What I'm starting to notice now, though, is that I haven't really had the same experience with developing my technical chops as a developer. I think I need to find more interesting projects outside of work to really scratch that creative itch.

<comment><USER20> This is where the "learn a language in a different paradigm" advice comes in. And do a non-trivial project in it. It shouldn't be _enormous_ , but it needs to be non-trivial.

<comment><USER19> Yep, I just started diving into Clojure. It's really been a shift for me, even though I took a class in Haskell. I still haven't totally internalized the functional paradigm. I'm really eager to see how it changes my understanding of the current crop of languages I use (C#, Java, Ruby).

</comment></comment></comment><comment><USER21> This is a great read, and I believe it's spot on. It's also a perfect example of what Alan Kay means when he says, "We see things not as they are but as we are"..."We can't learn to see until we admit we are blind"..."A change in perspective is worth 80 IQ points."

Humility is a key ingredient because it saves you from the mindset of "Success comes from proving how great you are. Effort is a bad thing — if you have to try hard and ask questions, you obviously can't be very good."

</comment><comment><USER22> The most important meme for success is agency: you can make a difference in your life.

But this one -adaptability- is not far behind it. You can make a difference in yourself.

</comment><comment><USER23> Awesome article.

I started learning to program when I was in middle school and since that I've pretty much always messed around in the same programming language and it was always fun because I was always learning new and challenging things. Recently though I've found that I wasn't learning as many new things (as frequently) as I once used to and no longer had the same level of excitement that I used to have doing it, so I decided to make a change.

I've always been somewhat afraid of learning new programming languages because it's "new" and "different" and "I might not understand or be able to get it the first time around" but what made me do it is remembering back to when I didn't know anything about computers and how without any books or any help I was able to learn some really cool stuff. I'm now taking that same approach to learn Ruby on Rails, Python, and iOS and plan to go back to school next year to get a degree in Computer Science.

As the saying goes: "If you're not learning, you're dead"

</comment><comment><USER24> This reminds me a lot of what I learned from the book, Flow. That author talks about what makes people happy and the common thread is intrinsic motivation to continually learn and grow. This current article isn't saying that anything is possible if you work hard. I like to think we all have an achievement continuum given to us by our genes that is unfortunately then artificially restricted when we say "I can't" or "I never had a good rememory". If you set your personal goals somewhere outside your physically possible achievement continuum, no amount of work will ever result in success. But identifying your continuum and then being aware enough to approach roadblocks as growth opportunities will result in great success. I think the chance of ever reaching the end of your physically capable achievement continuum is far more rare than those of us who spend large amounts of time artificially restricting that continuum by not even trying.

</comment><comment><USER25> I think it's important for a lot of people to realize that it's possible to be a growther in certain aspects of your life and a fixie in others. As I was reading the article, I thought about how I approached problems like learning new programming languages and solving logic puzzles and such and I thought to myself "cool, I'm totally a growther!" But as I read on and read about the authors social growth and realization that "introverted" is not a permanent state of being, I realized that in this area I'm a complete fixie. My next growth project should probably be to convince myself that a compiler error message is no less offensive than acting awkward in a group of people you don't know.

</comment><comment><USER26> I keep an image in my Pinboard that reminds me of this whenever I begin slipping into the fixed mindset. I think it succinctly summarizes Dweck's observations.

<http://i.imgur.com/QUsvJ.jpg>

</comment><comment><USER27> _You know how some people just seem to succeed at everything they do, while others seem helpless, doomed to a life of constant failure?_

I never noticed that, except in greek tragedies.

</comment><comment><USER28> Great summary and how to apply it to your own life. I find this particularly relevant for entrepreneurs where you must either love the challenge of learning/failure or you will be miserable.

</comment><comment><USER29> _Carol Dweck was obsessed with failure. [...] So she began watching kids [...]_

Scientists rarely proceed that way.

</comment><comment><USER30> This article precisely explains what John Carmack was like as a kid.</comment>


Delta Flight 15, a true story about 9-11 - <AUTHOR> http://mytnnews.com/blog/2012/10/11/delta-flight-15-a-true-story-about-9-11/ <comment><USER2> A story that has the makings of a book/movie in it</comment>


How do you find integer solutions to x/(y + z) + y/(x + z) + z/(x + y) = 4? - <AUTHOR> https://www.quora.com/How-do-you-find-the-positive-integer-solutions-to-frac-x-y+z-+-frac-y-z+x-+-frac-z-x+y-4?share=1 <comment><USER2> Previous discussion (with non-mangled title): [https://news.ycombinator.com/item?id=14943528](https://news.ycombinator.com/item?id=14943528)

</comment><comment><USER3> perhaps one should link to this thread instead [https://mathoverflow.net/questions/227713/estimating-the- siz...](https://mathoverflow.net/questions/227713/estimating-the-size-of- solutions-of-a-diophantine-equation/227722) ? When it comes to Math, the quality of discussion on Quora is usually much lower comparing to on Mathoverflow or artsofproblemsolving

<comment><USER4> Well it depends on what you mean by quality. On Quora the discussion is meant for the general public, and terms like diophantine equations are defined in common language before delving into their mathematical details. While mathoverflow is for mathematicians, for a layman it's mostly gibberish. So imho it's unfair to even compare the two, they're different things and both have their place.

</comment></comment><comment><USER5> Again, "and" should be "+" two more times in the title.

<comment><USER6> Yes. Became very confused attempting to solve for all three fractions = 4.</comment></comment>


How to Change the World: My Visit to Google Germany - <AUTHOR> http://blog.guykawasaki.com/2008/09/my-visit-to-goo.html <comment><USER2> Is this meant to be sarcastic? If not, then I really don't get it. How is this in any way world changing?

It's just some pretty pictures from a standard google office complex.

<comment><USER3> "How to change the world" is the name of his blog. But I agree, this are basically just the dude's vacation photos. Yawn.</comment></comment>


A common, deep mistake in polymorphism - <AUTHOR> http://tmsh.posterous.com/a-common-deep-mistake-in-polymorphism <comment><USER2> I'd rather see Vector<Fruit> than Vector<AppleOrOrange> or Vector<TreeBearingFruit>

The point is first to change the code s.t. you're dealing with a superclass vs the subclasses. The name of the classes is not spectacularly important, it's just important that it is understandable. Fruit with a comment about the nature of said fruit is imho more readable than some obscure but specific class name.</comment>


New face of the Bank of England's £50 note is revealed as Alan Turing - <AUTHOR> https://www.bbc.com/news/business-48962557 <comment><USER2> [https://news.ycombinator.com/item?id=20439425](https://news.ycombinator.com/item?id=20439425)

</comment><comment><USER3> This is very exciting. Hope there's a means to get one of the bills when it's circulated in 2021.

The US could take a lesson about whom they put on bills.</comment>


Who Owns the Moon? (2019) - <AUTHOR> https://www.politico.com/agenda/story/2019/06/13/space-travel-moon-resources-000899/ <comment><AUTHOR> I checked out the original link after a friend of mine sent me the site [0] where you can but a plot on the Moon. It felt like a hoax, but the truth is, again, stranger then fiction.

[0] [https://www.lunarland.com/](https://www.lunarland.com/)

</comment><comment><USER2> Whoever is willing and able to create, maintain and defend facilities there.</comment>


Police Use of Facial Recognition with License Databases Spur Privacy Concerns - <AUTHOR> https://www.wsj.com/articles/police-use-of-drivers-license-databases-to-nab-crooks-spurs-privacy-concerns-1529233200 <comment><USER2> The link from Drudge Report shows the full story. I didn't realize until I clicked through it from HN that it threw up the paywall. Sorry.</comment>


Barnacle Ventures – A barnacle on the hull of progress - <AUTHOR> http://barnacle.vc/ <comment><USER2> Can I get an introduction please?</comment>


Show HN: ShiftCals – get any shift worker's schedule into fav calendar app - <AUTHOR> https://www.shiftcals.com <comment><AUTHOR> OP/creator here. My wife is a CNA, and her shifts are delivered via a printed out piece of paper. She then has to manually put them into our shared family Google Calendar. I'm a software engineer, so it drives me crazy every time I see her spending time doing this :)

I decided to make a tool that enables her to quickly get shifts into an online calendar from her phone.

If your employer already has a digital calendar that integrates with Google/Yahoo/Apple/Outlook, awesome. If not hopefully this can save you some time. Just open the following (it's free, no login, no catch):

If you have any comments/suggestions/feedback I'd love to hear them. There are other tools out there (ex: NurseGrid), but I challenge you to find one that gets this job done faster. Other apps/websites require you to create a login or divulge personal information (like location where you work).

If you like it, best thing you can do for me is tell your co-workers. Thanks!</comment>


Isolation Is Bad For Your Startup - <AUTHOR> http://blog.stuffbymatt.ca/2011/12/02/Random/Isolation_Is_Bad_For_Your_Startup.html

<comment><AUTHOR> I don't think I've written anything extraordinary about running a startup in relative isolation but I am curious to know what other people think of the idea.

I'm definitely on the "it's better to be closer" side of the fence but I'm willing to be converted and hear what other people have to say about their startup experiences vs. proximity to other like-minded people.</comment>


Looking with Cassandra into the future of Atlas - <AUTHOR> http://metabroadcast.com/blog/looking-with-cassandra-into-the-future-of-atlas? <comment><USER2> Database system combining two published technologies battle-tested by two of the largest Internet websites performs better under real world conditions than database written by amateurs, news at 11!

(In all seriousness, what did they expect? Have they looked at the MongoDB code? Do they seriously believe that the 10gen folks are smarter or better at solving problems than the masses of engineers Google and Amazon have thrown at this problem?)

<comment><AUTHOR> I appreciate the sentiment, but it's worth distinguishing between the design and implementation here. Cassandra does take a lot of inspiration from the Bigtable and Dynamo papers, so we benefit from the thinking of a handful of very smart engineers at Google and Amazon, respectively, but the actual code is our [Apache's] own and for the battle testing you need to thank companies like Netflix, Reddit, Spotify, and others. [1]

That said, part of the reason Cassandra was attractive to me from the beginning is that unlike master-slave designs like MongoDB (or Bigtable/HBase, for that matter), a p2p design doesn't have the many corner cases around failover and recovery that complicate troubleshooting so badly. This is a primary reason Cassandra has had a very good reliability story since very early on.

[1] <http://www.datastax.com/cassandrausers>

<comment><USER2> Sorry, I didn't mean to imply that Google or Amazon engineers implemented Cassandra (though it's notable, of course, that it was initially implemented by Facebook, adding a third Internet behemoth to its pedigree).

What I really meant to say is that it's clear that the engineers behind Cassandra have done their research and chosen an extremely well tested design, while the engineers behind MongoDB seem to be completely winging it, ignorant of the literature and writing (based on my last examination) extremely amateurish code.

</comment></comment></comment><comment><USER3> Where Cassandra REALLY shines and is often overlooked is ease of maintenance. Cassandra's ability to bootstrap new nodes, replicate, reshard and handle down nodes (w/ hinted handoff) is almost magical. I use it in production and it works very reliably.

Sure, it's got some cool big data stuff, but try doing any of those "maintenance" operations on other databases without ripping your hair out. For example, even bringing up a new MySQL slave is a huge pain in the ass, let alone doing something non-trivial like promoting a new master.

<comment><USER4> Interesting. I thought sysadmin operations like MySQL sharding and master- promotion are usually automated/scripted? Not to say it makes it conceptually easier, but it limits the opportunities to lose hair to 1.

<comment><AUTHOR> If it's complex enough you need to script it, it's complex enough to make troubleshooting a bitch when something goes wrong in that script...

</comment></comment></comment><comment><USER5> Did you guys investigate any other choices such as DynamoDB, or HBase? I know that Facebook (inventors of Cassandra) have moved off of Cassandra over to HBase for its back-end messaging services due to its inherent consistency problems.

<comment><AUTHOR> "Consistency problems" is a red herring; Cassandra can be easily asked to sacrifice availability for consistency [on a per-request basis], if that's what you want: <http://www.datastax.com/docs/1.1/dml/data_consistency>

Facebook never used modern Apache Cassandra, so when they tasked a team of experienced Haddop/HDFS engineers to build Messaging, it was natural for them to choose HBase. But the things they've had to do to deal with the problems in that architecture (e.g., sharding into "cells" to deal with namenode SPOF) [1] make me think that they would have done better with Cassandra.

[1] [http://www.slideshare.net/brizzzdotcom/facebook-messages- hba...](http://www.slideshare.net/brizzzdotcom/facebook-messages-hbase/23)

<comment><USER6> If you have three replicas in casandra and you want your reads to be consistent, you would have to read from at least two replicas . This doubles the number of iops to the disk subsystem. Most disk based storage systems are bottlenecked by random iops, and a solution that requires double-the-iops is a non-starter.

<comment><USER7> I don't think that's strictly true.

With cassandra you choose where the extra reads (or writes) to ensure consistency occur as best suits your use case:

* At write time (write quorum) like a traditional replicated datastore

* At read time (read quorum)

* In the background (read one, with a non-zero chance of read repair)

This is quite nice to be able to bend Cassandra on a use case by use case basis (NB: these are not cluster wide approaches, for different columns / circumstances i can choose different patterns).

</comment></comment></comment></comment><comment><USER8> I think in the near future Mongodb will no longer have a global write lock. Yeah but I feel their pain. Given my still limited experience with it, Mongodb may be great for reads, but not so much for writes.

<comment><USER9> EDIT: deleted b/c I didn't make my point clearly.

<comment><USER10> Call me stupid but I can imagine that losing data is a problem for a database company.

That said MongoDB has a simple flag which allows you to choose how to handle writes. The app can 'wait' for writes to be applied to one node, all nodes, some number of nodes etc.

<comment><USER9> Heh, that probably wasn't phrased well. Let's try again:

Dynamo (and thus Cassandra) is designed for write speed and durability. What is MongoDB designed for?

</comment></comment></comment></comment><comment><USER11> The problem of course with Cassandra is getting results you will believe out of it. Also I understand Cassandra to be a Trojan. Use at your own risk. When Atlas lets you down and AJAX has gone crazy (like slaughtering all your cows in a fit of drunken pique), and your city is in flames don't say I didn't warn you. But you won't believe me either ;-)

(ok, sorry for the obligatory Illiad joke there.)

</comment><comment><USER12> <http://news.ycombinator.com/item?id=3984642></comment>


The most popular subreddit r/science is now on Twitter - <AUTHOR> https://twitter.com/rslashscience <comment><AUTHOR> Only reposting the top 20 most upvoted post of the day.</comment>


GCC tiny - <AUTHOR> http://thinkingeek.com/gcc-tiny/ <comment><USER2> I appreciate the series of articles on Tiny and think they are fine, but I have a few minor points:

1\. Missing "string" types in Tiny?:

In Part 8 a "bool" and "string" type were both first introduced. Tiny's type system was extended with "bool" in Part 9.

But the "string" type (not to be confused with string-literal), was never added to Tiny's type system.

I assume an array of "char" would cover that "string" type if "char" is added as an extension of the type system.

2\. Expressions in Tiny:

The rule "unary-op" shows that unary "plus", unary "minus" and "not" are all unary operators in Tiny. In Part 4, the rule is confirmed with a statement that "not" is a unary operator.

But in the table of op priorities in Part 1 "not" is placed in with "and", "or" instead of in with unary "plus" and unary "minus", so it has the incorrect prority there.

3\. In the git-hub file for Tiny's grammar, the rule for expression is:

expression -> primary | unop op expression | expression binop expression

I believe this should be changed to:

expression -> primary | unop expression | expression binop expression

<comment><USER3> I'm not really sure what a string type is because, mathematically, a string consists of letters which are part of an alphabet which are accepted or rejected by a state machine. The entire alphabet might consist of 0 and 1 (and in computing _practice_ that's what everything boils down to eventually). In a language like, C a char is just a convenient abstraction over a byte and a byte is just an abstraction over bits...sometimes 8, sometimes not.

A difficulty arises when, as is often the case, "string" is used to denote human readable text. That this happens is understandable due to the use of char as an abstraction for byte and consequently arrays of char being able to represent human readable text in the several spoken languages common among programming communties of yore.

The high level abstraction missing from most languages is a text type that expresses the idea of human readability and is free from the ambiguity of string types. Or to put it another way, Unicode strings will always be problematic because the organization of characters of human alphabets is not always entirely logical.

<comment><USER4> ""I'm not really sure what a string type is because, mathematically, a string consists of letters which are part of an alphabet which are accepted or rejected by a state machine.""

A C string is a chunk of memory containing either bytes or words, that is terminated with a null (byte|word) at the end.

A UTF-8 string uses the same transport, but it is blocked into "Codepoints" (Groups of 1 - 4 bytes, dictated by _n_ high bits being set to a specific configuration).

A UTF-8 "Grapheme" (The actual character that gets printed) is a number of Codepoints that are interpreted as being grouped together, as per the NBNF given in the Unicode spec.

All of this takes place in a block of memory of a number of words or bytes.

That's all.

A string type that conforms to C Strings is basically just a block of memory of a certain size that happens to have things in it that conform to what we would consider graphemes to be. Some String types have the block of memory in a struct with a number and sans the last null byte, some string types use blocks of lists, or a list of characters. But the most prevalent is the C String.

<comment><USER3> I agree and apologize for not being clearer.

What I was getting at is that as a Type within a type system and independent of a particular language, it is not clear what the words "string type" mean. As you point out, in C, the string type is an abstraction over a contiguous memory block and allows addressing by bytes -- Addressing blocks of memory by bytes is often convenient when processing the values stored in the block with a state machine.

UTF-8 strings exist because the string type as an abstraction over bytes fed into a state machine became conflated with the idea that strings had an intrinsic relationship to human readable text.

Erlang is a programming language that does not conflate strings with human readable text. Perl6 is a language that handles human readable text better than average.

<comment><USER5> Well, if you want a completely general definition of what a string type is, you could get one by following an axiomatic approach and considering the set of (abstract) operations, or functions, that are allowed to be done on strings: concatenation (a binary operation with the neutral element called "the empty string"), taking a substring, having a string-to-integer map "length", etc. From this general perspective, it would be incorrect to say, for example, that a string consists of "individual characters" \- instead you might say that the smallest substrings of any (non-empty) string all have the length 1; in this sense the notion of a "character" does not even appear in the abstract definition of the string...

<comment><USER3> I don't disagree, and I should have said 'symbols.'

After I wrote what I wrote I went for a run and I suppose another way of making the distinction I am making between strings and text is that a machine can necessarily decide what is and is not a valid string and a mchine cannot decide what is and is not a valid text (unless we conflate strings and text).

Or to put it another way the recursively enumerable languages are closed under union, intersection, concatination and Kleene star. That's the realm of strings. Text is not closed under those properties, e.g. 'hello*' is not guaranteed to produce a valid text.

<comment><USER5> You are right: a text is not a string - because it is subject to completely different axioms (the "grammar"). I guess, this is similar to, say, groups, in mathematics, and sets being different _categories_ , and even though the usual naive definition of groups is based on sets, this is only possible because of the existence of the "forgetful functor"... In fact, in computing, a string is not considered a (valid representation of a) text until it has been successfully _parsed_ and, often, translated into its "true" representation which is not a string at all!

</comment></comment></comment></comment></comment></comment></comment><comment><USER6> Does it provide interesting advantages over "transpiling" to C?

<comment> le-mark This is my question as well, seems like a boat load more work than writing c to a file and calling gcc on it.

One thing I can think of; if the language you're implementing has exceptions, you'd have to implement these the naive way wiht setjmp/longjmp if you target c. Supposedly if you used gcc in the way this article shows, you could use gcc to generate "real" excpetions.

</comment></comment><comment><USER7> This is so ugly.

> The next step is telling GCC configure that we are going to build GCC with > tiny support. This will fail. Do not worry, this is expected.

Back in the 2.9 - 3.8 LLVM days there was a lot of API breakage between releases. A lot of people I knew who worked with LLVM detested this, but would you rather deal with this kind of cruft?

<comment><USER8> Wait, so has it stopped breaking? Because their breakage essentially killed the LLVM-based JIT compiler project for GNU Octave. Someone wrote it based on the C++ "API" and we spent time trying to keep up with it and then we gave up. Nobody really understood it well enough to rewrite it for the C API or knew if it was even possible, so we abandoned it.

<comment><USER7> The changes in the LLVM JIT were definitely a disappointment. IIRC it used to be a lot more lightweight the API was simpler to use.

But in hindsight it's hard to argue that the LLVM devs shouldn't have messed with it. Before you couldn't get symbolized stacktraces or use C++ exceptions. LLVM's primary goal has always been to produce the best code, and not necessarily try to be the fastest at doing it [1].

In the 3.x days, it was a fast evolving project. I remember projects I managed that used LLVM would no longer compile between releases because e.g. they would rename a header file.

"Just to rename a header file??" one might say; it's a subjective question whether this philosophy hurt or helped the project in the end. It might take years until that answer is forthcoming.

I'm sorry to hear about what happened with GNU Octave. Maybe after LLVM proves to stabilize someone new will write up the code :)

[1] Tangentially related: [https://bellard.org/tcc/](https://bellard.org/tcc/) Compiler Time(s) lines/second MBytes/second TinyCC 0.9.22 2.27 859000 29.6 GCC 3.2 -O0 20.0 98000 3.4

<comment><USER8> > But in hindsight it's hard to argue that the LLVM devs shouldn't have messed > with it.

Not that hard, software stability is a very desirable property:

[http://stevelosh.com/blog/2012/04/volatile- software/](http://stevelosh.com/blog/2012/04/volatile-software/)</comment></comment></comment></comment>


Waymo heads to Atlanta to test its self-driving cars - <AUTHOR> https://techcrunch.com/2018/01/22/waymo-heads-to-atlanta-to-test-its-self-driving-cars/ <comment><USER2> It seems like Waymo is well ahead of everyone else, but they had a mass talent exodus 2 years ago (many went to Nuro, Aurora, Otto, Argo, etcetera). I can't imagine that many smart engineers, already making good money even by Bay Area engineering standards, would quit to compete unless they really thought they had a chance.

There's just so much about the competition in this space I find fascinating.

<comment><USER3> Many were bored - they'd been working on it 5 years already.

Some thought the direction was wrong - not gathering enough test data (unlike Tesla).

Some thought they didn't have a big enough slice of the pie, and by moving to a startup and replicating the work they could earn way more through an acquisition by a carmaker.

Some saw the tech as fairly old. Remember much of Waymo's code was written by Urmson 10 years ago. Probably all C/C++. Not very nimble and quick to extend.

Some saw the fundamental approach wrong. Why not use neural nets for path planning and decision making rather than hand coded rules which will never cover enough cases to be good enough?

Some didn't want to be part of Googles risky approach. Too much pressure to get the cars on the road could kill people, and killing people, or the threat of it, is rather bad for morale. The leaders had this "even if it isn't perfect, it's better than current drivers" approach. Thats little comfort if it was your off by one error which caused the car to plough into a group of schoolchildren.

<comment><USER4> > Some thought the direction was wrong - not gathering enough test data > (unlike Tesla).

FWIW if you gather a ton of data and don't have simulation it's pretty much useless. Also it's expensive to keep around large amounts of data. Tesla didn't even have a simulation team until relatively recently.

> Some saw the tech as fairly old. Remember much of Waymo's code was written > by Urmson 10 years ago. Probably all C/C++. Not very nimble and quick to > extend.

Do you work in autonomous vehicles? Most teams are using C/C++. If you're not waymo you probably use ROS.

If you've ever worked at Google you'd know their C/C++ stack is among the most pleasant to deal with because much of the bad cruft from those languages is abstracted away in stable libraries.

<comment><USER5> If you're not Waymo you probably use ROS. If you _are_ Waymo, then what do you use?

<comment><USER6> I don't know if they've changed, but in 2013 they were using a modified Ubuntu:

[https://youtu.be/7Yd9Ij0INX0?t=9m25s](https://youtu.be/7Yd9Ij0INX0?t=9m25s)

</comment></comment></comment></comment></comment><comment><USER7> If they can navigate which of the 800 Peachtree-named streets the car is on and which one it should go down next (minding all the crazy one way streets in downtown) without crashing into anything or anyone, they'll be doing better than most humans.

</comment><comment><USER8> As an Atlanta resident, I can say that they have chosen some of the most challenging roads in the nation. The roads in Atlanta are a classic lava pattern. Many are literally the cow paths from town to town.

And we have some of the most aggressive drivers in the US.

edit: spelling.

</comment><comment><USER9> I recall taking an Uber once and hearing the driver mention that he wished he could remotely drive the car. Was this idea ever taken seriously? I'm sure latency and creating the actual interface would be big problems.

[/digression]

From a political perspective, what's necessary until the safety drivers are no longer legally required? I believe there are a couple places that don't require them now, actually.

<comment><USER10> your visual system is finely tuned to be able to judge things like "how far away is that child in the crosswalk?"

you possess an internal IMU that provides instant and accurate feedback on acceleration and rotation.

you lose out on both of those when you perceive the world through any kind of display, whether that be a screen or even a VR headset.

think about your field of view when you look out the windshield of a car. including peripheral vision that's a 150° field of view. compress that fov to a screen, even a really good one. maybe three of them set side by side. can you still make out a street sign with 6" tall text from 200 feet away?

</comment></comment><comment><USER11> This should be interesting. I'd like to see the "driver profiles" created for each city, assuming that's possible to create from observing traffic in different cities.

<comment><USER12> Like a self driving car that honks a lot in Rome or Mumbai?

<comment><USER11> Change the classic saying: "When autonomously driving in Rome..."

</comment></comment></comment><comment><USER13> That's nice but when are they launching to the public in Phoenix?

Everytime I see Waymo news I hope it's about that Phoenix launch and then am disappointed when it isn't.

<comment><USER2> Supposedly they're launching in February, but I guess we'll just have to wait and see.

<comment><USER14> Where did you hear that?

</comment></comment></comment><comment><USER15> I am hoping that partnerships with ridesharing companies help with the data collection aspect. If Lyft/Uber could lease a few cars from all/some of these companies, which would probably pay them to be driven around, it might be a win-win for both the consumers and the companies.

Also, faster data collection at scale might reduce the time taken to "learn a city"

<comment><USER16> Not really. Uber has its own stake in self-driving so it wouldn't make sense for them to help competition with data collection for short term gains.</comment></comment>


How the NSA's Firmware Hacking Works and Why It's So Unsettling - <AUTHOR> https://www.wired.com/2015/02/nsa-firmware-hacking/ <comment><USER2> Any reasonable HIDS/HWIDS, beyond physical PCB auditing, x-ray verification and supply-chain chain-of-custody documentation, needs to include continuous monitoring firmware using end-to-end public key-verifiable signatures.

Also, open-source hardware, including the firmware, would alleviate some of the downsides of closed blobs.

</comment><comment><USER3> [2015]</comment>


H.P. Lovecraft – Against the World, Against Life (by Michel Houllebecq) - <AUTHOR> http://chunk.io/f/3bdc0fe122594277808291a42f1fb758 <comment><USER2> name's wrong, that would be Michel Houellebecq [https://en.wikipedia.org/wiki/Michel_Houellebecq](https://en.wikipedia.org/wiki/Michel_Houellebecq)</comment>


Ask HN: Is there any opensource database of cities that provide city population? - <AUTHOR> I'm particularly interested in European cities. Data I need is: city country lgn ltd
I need to query like: "SELECT * from cities WHERE population > x"
I didn't manage to Google anything.
(sorry for using "provide" instead of "provides" in title, but it had 81 characters with "s") :) <comment><USER2> You might try searching for Census data for the country in question.

<comment><USER3> That (census data search) has worked for me in the past.

<comment><AUTHOR> thanks & thanks</comment></comment></comment>


OAuth Has Ruined Everything - <AUTHOR> http://developer.telerik.com/featured/oauth-has-ruined-everything/?imm_mid=0dac54&cmp=em-web-na-na-newsltr_20151021 <comment><USER2> There was a fantastic protocol that really could have replaced much of the problems that OAuth has, while providing its users more privacy: BrowserID, aka Mozilla Persona.

Sadly, it got effectively gutted by the Mozilla Foundation due to lack of use, and even Mozilla has stopped using it most places in favor of Firefox Accounts.

<comment><USER3> I'm really sad Persona got abandoned so quickly. Mozilla made some strange decisions in how it marketed and supported it, too: "Persona" was already the name of their browser themeing engine (or was it the other way around?), I don't remember there being a Chrome or IE plugin for it, I don't think any of the Mozilla-branded sites (like addons.mozilla.org) ever used it, and after just a year it got unceremoniously dumped.

Everyone I talked to said it was a great solution and they were really interested to see where it would go. Why did Mozilla make so many weird decisions on what could have been a revolutionary technology? Is there any way to breathe life back in to it?

When it came out I personally considered implementing it for Scribophile , but decided not to because I didn't want to invest a lot of time in an unproven technology. If I had seen it active and lively a few years down the road, I would have been more than happy to bite the bullet. Maybe my attitude was a common one, and doomed Persona to a chicken-and-egg situation. Who knows.

<comment><USER4> > _I don 't think any of the Mozilla-branded sites ever used it_

You're right that AMO never used Persona, but a _ton_ of Mozilla's other sites used (and still use) it. MDN, Bugzilla, Etherpad, the Firefox Marketplace, most of our metrics dashboards, etc. It wasn't a complete sweep, but we did see pretty solid internal adoption.

> _after just a year it got unceremoniously dumped._

Longer than that. I think Lloyd and Mike hashed out the first version of the protocol back in March 2011. The bulk of the team came together around March 2012. Most of us were moved off the project in around November 2013, so we had closer to two years as an official project.

...wow, it really _felt_ longer than that.

> _I didn 't want to invest a lot of time in an unproven technology._

That was a big reason we didn't go further than we did. People loved the idea, but relatively few folks were willing to actually back up that belief with action.

We also share some of the blame: We thought we had more time to experiment with the core protocol and product design, but with Mozilla Labs' somewhat sudden dissolution, we were unexpectedly asked to demonstrate traction and commercial adoption that simply wasn't there.

<comment><USER5> Dan, I know you are not to blame for this but I hope you can at least forward the sentiment.

I was at MozFest last year, with one of the execs on stage talking about Mozilla's efforts to "free the web". He went on and on for 15 minutes about it and I swear, the only thing on my mind at the time was how Persona had been gutted. Today's web isn't "free" if a core part of it is behind Facebook and Twitter.

> _People loved the idea, but relatively few folks were willing to actually > back up that belief with action._

Either Mozilla is full of it when they say they fight for the free web, or they _massively_ misunderstand how important it is to get rid of proprietary authentication.

If this is Mozilla's stance, Mozilla's belief, then Mozilla is the one not backing it up with action.

Edit: Followup thoughts: I cannot get behind the way Persona was dumped. Firefox had an atrocious market share for many years, but devs didn't dump it. Persona can't revolutionize the web by taking down Facebook and Twitter in 24 months, and it's not good enough? Grr, there were at least a dozen other ways to stop spending as much effort on it without outright killing it.

> _Maybe my attitude was a common one, and doomed Persona to a chicken-and-egg > situation._

Yuuuup: [https://bazqux.uservoice.com/forums/190752-general/suggestio...](https://bazqux.uservoice.com/forums/190752-general/suggestions/4832985-allow- authentication-via-mozilla-persona)

<comment><USER4> In these cases it's really helpful to recognize the distinction between the Mozilla Foundation (MoFo), the Mozilla Corporation (MoCo), and the broader, open source Mozilla project that binds everyone together.

The non-profit Mozilla Foundation exists to support the project, and does truly wonderful, pure work on keeping the Web open. Advocacy, education, grants, etc. They also own the for-profit Mozilla Corporation, which is in trenches directly competing with other browser vendors to ensure that the project has sufficient influence to fulfill its mission.

Persona was housed in MoCo, which afforded it greater resources at the cost of greater organizational risk.

> _Either Mozilla is full of it when they say they fight for the free web, or > they massively misunderstand how important it is to get rid of proprietary > authentication._

The Mozilla project is too small to fight effectively on every front; we have to focus on areas of greatest urgency and where we have the greatest leverage. In the instance of Persona, two major things changed: (1) Persona became less urgent, and (2) we discovered that we couldn't credibly leverage Firefox to boost Persona adoption.

To the first point, back in 2012 we were seeing _huge_ startups, including Spotify and Pinterest, run without offering any means of authentication besides Facebook Connect. The lack of traditional authentication on these sites looked like an ill omen for the freedom of the future Web, but that didn't come to pass. Both sites now offer email-based authentication in addition to Facebook Connect. It's not as slick as it would have been with Persona, but the immediate threat to user autonomy isn't there anymore. If I had to guess, it seems like the tide started turning in late 2012 / early 2013, around the time of Mailchimp's "Social Login Buttons Aren't Worth It" blog post at [http://blog.mailchimp.com/social-login-buttons-arent- worth-i...](http://blog.mailchimp.com/social-login-buttons-arent-worth-it/).

Secondly, Persona's passwordless design wasn't suitable for use in Firefox Accounts, the development of which had become quite urgent. So not only could we not use Firefox Sync / Accounts to boost Persona's active userbase, the Persona team suddenly found itself with domain knowledge that was quite valuable to the Accounts and Sync efforts. Oops. :)

That said, just because we're not fighting as visibly on this front doesn't mean we're out of the fight altogether. Firefox Accounts has an active userbase orders of magnitude larger than Persona's. We may be able to reintroduce a notion of federated identity into FxA at some point in the future, which would help us break out of the "three-way cold start" that Persona faced.

But that's all hypothetical. If anyone wants to run with these ideas, _do it!_ For the sake of longevity, I'd recommend any spiritual successors to either establish themselves within independent foundations, or design the protocol without the sort of centralized bootstrapping that Persona had.

<comment><USER6> > _Firefox Accounts has an active userbase orders of magnitude larger than > Persona 's._

> _We may be able to reintroduce a notion of federated identity into FxA at > some point in the future_

As a member of the team working on Firefox Accounts, here's one (hypothetical!) way that might play out in practice:

* grow FxA userbase to significant size, integration with Firefox to significant quality

* allow websites to add "log in with Firefox" via OpenID Connect and get a really slick experience for Firefox users

* influence OpenID Connect ecosystem to be more of a level playing field for smaller IdPs (e.g. increasing adoption of IdP discovery and dynamic registration)

* a win for openness on the web!

Not as _big_ a win as widespread adoption of Persona would be, but a win nonetheless.

This sort of thing isn't exactly on our concrete roadmap, our short-term focus remains on supporting Mozilla's own service ecosystem. But be assured that it's on our minds.

<comment><USER7> Why fallback to just OpenID Connect? You could use a multi-pronged approach to prop up BrowserID using (continuing to use) OpenID Connect as bootstrapping fabric. Maybe along these lines:

* Merge the login.persona.org fallback login provider and Firefox Accounts (grows both userbases!); you'd probably need a nice path forward to FxA users with Persona-supported email accounts, but that may just be a matter of selling "Connect your FxA account to your Gmail account for easier password management; Here's how FxA will (not) use your Gmail information"; (worst-case you need to figure out the BrowserID protocol changes to allow individual email opt-out to a different provider. Maybe easy enough to do in the case of the bridge providers to Gmail/Yahoo as login.persona.org is already mediating that...)

* Use the Firefox Accounts "brand" for the fallback provider; this gives potentially a needed distinction between the fallback provider and the platform/tooling (so long as you can do user acceptance testing to maybe avoid confusing users), so that Persona <=> OpenID Connect as a developer brand and FxA as the consumer brand

* Setup an OpenID Connect proxy _to_ Persona/BrowserID and call that the "Login with Firefox"...

A proxy could drop in to existing OpenID Connect workflows, but really be a wrapper around the BrowserID navigator.id. With Firefox Accounts as the main fallback this is still seen as "Login with Firefox" button This would require fewer changes to the auth code of existing websites (drop in next to your Google/Facebook buttons), but then as people get used to it you can start to encourage websites to "skip the middleman" of the Proxy and directly use Persona/BrowserID navigator.id to back that "Login with Firefox" button.

Maybe the only twist here would be a way for other browser manufacturers/plugin-providers to play in this space and keep the branding friendly. An idea might be to add a navigator.id.branding spec that if implemented could override "Login with Firefox" to show a "Login with Chrome" or "Login with Edge" button. The trick of course there would be balancing site CSS abilities and browser branding abilities. Doing so, however, would further reduce the need of consumers to know/learn/interact with the Persona brand and at that point they are just associating that button as the "browser login button". On the other hand, if FxA is the fallback provider it seems fine to just always have it say "Login with Firefox" and it may be less confusing that way, but with the original goals of BrowserID it might be nice to have it be browser/plugin-configurable solely for that reassuring "Login with my Browser" feel.

</comment></comment></comment></comment></comment></comment></comment><comment><USER8> I don't think this is a good critique of OAuth at all.

First of all, the majority of complaints aren't even about OAuth, they're about (a specific implementation of consuming) OpenID Connect, which it doesn't seem like the author realises he's using. JWTs aren't in OAuth 2.0.

If the author had realised this, surely when looking for libraries to assist with the project he would've looked for an OIDC or JWT library instead of something specific to Google. There are plenty of library recommendations on the JWT website[1], including .NET.

It's not like OAuth 2.0 or OIDC are trivial to use, but these aren't easy problems to solve. OpenID Connect is young, and there's still a lot lacking in terms of library support and (probably more importantly) documentation.

I'd rather deal with the rough edges of OIDC than use SAML any day of the week.

[1]: [http://jwt.io](http://jwt.io)

<comment><USER9> Agree. SAML is crazy complicated.

<comment><USER10> The entire spec, yes, is big, but the part you actually _need_ is not that complicated. I implemented the IdP for the new york times (there's quite a bit of third party shit plugged into the nytimes.com web experience that we wanted to be transparent to users) in a few weeks as I recall, and I'm not some coding super-genius. (It was kinda hacktified and minimalistic, but it worked at scale. ¯\\_(ツ)_/¯) Most of our counter-parties were up and running in a week or so. Compared to the abysmal quagmire that was our ecommerce code, SAML implementation was a total milk run.

</comment></comment></comment><comment><USER11> I have deep, deep objections to OAuth, and I hoped this article would espouse some of them, but it doesn't. Instead, this article is basically whining about "programming is hard" which is true but also something anyone trying to solve serious problems got over somewhere between high school and getting a real job.

OAuth is hard because it's _pretending to solve_ a hard technical problem (logging in and sharing some private data securely) while _actually solving_ an easy business problem (how do we (a big company) get smaller companies to outsource as much of their user data as possible to us). It _kind of_ solves the hard technical problem (because bigger companies are better at hiding the data you give them from other companies who don't pay for it, and have all your data anyway). But if that half-assed solution to the hard problem is good enough for you, you aren't actually trying to solve it, you're just to persuade uneducated users you've solved it. In short, OAuth For Dummies would be a tautological title for a book.

I've heard it said that it's okay and even desirable to outsource everything in your business to other companies _except_ your core service. But what service exists without users? If you can't get users to sign up for _your_ service and give _you_ their information, then I'd argue you don't even have users. You might as well quit. This isn't a question of "what's the best way to authorize users?" question it's a "do I even have users?" question.

<comment><USER12> Your comment is dead on. OAuth2 provides a way for people to log into your service without really telling you who they are. Instead, you outsource the task of asking them who they are to another company. But if you don't care who your customers are, _why are you asking them to log in_?

The whole concept makes no sense. And then when you consider that OAuth2 isn't even a protocol, but a "framework for a protocol," whatever that means. But sites use it, and will continue to use it, because it makes signup easier for new users.

Here is what the author is missing from is "programming is hard" angle. Yes, programming is hard, but that in itself is not a bad thing, and it's even a good thing if the program itself is a good idea. But OAuth2 is not a good idea. It's not even a bad idea -- it's a framework for a bad idea.

<comment><USER13> > But if you don't care who your customers are, why are you asking them to log > in?

I may not care who they are, but I do care how their identity maps to information in my system. Simple functionality such as favorites or saved preferences doesn't require any information about the user, other than them being able to identify themselves as someone who has previously used the site.

<comment><USER12> Cookies or browser fingerprinting should do the trick, with gentle reminders to register. It's how most online shopping carts work.

I'm not saying no one should ever use OAuth2, ever. Sometimes websites have to jump through weird hoops to get conversions. But as a web developer, it annoys me a _lot_.

<comment><USER13> Cookies and fingerprinting tell me that the same browser is coming back to my website, but I don't care about the browser I care about the user. As a user if I go to a website on my work machine, my home machine, and my phone then I'd like my data to be available on each.

I don't have strong opinions on OAuth or any other federated identity solution, I just think it's a specious claim to say that just because a system doesn't care about who a user is then that system doesn't care about the uniqueness of that user.

</comment></comment></comment></comment></comment><comment><USER14> Totally agree OAuth sucks. Want a simple way forward? [https://passwordless.net/](https://passwordless.net/)

For profile info: [https://en.gravatar.com/](https://en.gravatar.com/)

Why do you need someone to sign in with their third party service account? If it's just because you want a low friction sign up / sign in think again, it is not low friction. If its to prevent from having yet another account and password? This could be a great option.

With OAuth There is a lot of friction on the flow and privacy concerns. "What kind of data are they going to suck out of my account?" Last time I looked at OAuth years ago I had huge reservations. In mobile apps it uses a web-view in the middle of the flow. Is that web-view logging my key presses? Is it using HTTPS? Is the cert good? You'll never know.

I ran some of these concerns by Eran Hammer (brilliant, great guy) and he had no great consolation to give me. Not long after came his epic departure from OAuth (Not implying any correlation.)

I went on to "invent" a new auth system for mobile based on push notifications. I got mired in trying to patent this and realized that was stupid. TL;DR of that project, push notifications are an amazingly secure and targeted way to deliver auth tokens try it out! But in the end, nothing beats the simplicity of letting go and just going with passwordless and gravatar IMHO.

<comment><USER15> I dunno - I get the privacy concerns, sure. But passwordless requires the user have an email address to receive the nonce, and it requires the developer to deal with that flow. It also requires transactional email, which can be laggy at times - I know sometimes (rarely, but not never) my mandrill outbounds can take minutes to actually resolve. If I'm sitting waiting for a login token to get to my emails and it's not Right There, I'm walking.

I don't see passwordless fixing anything new that OAuth doesn't fix. Use the basic profile grant, and the user sees the consent screen where you're just asking for a small grant.

Passwordless works for users whose email providers are not also major OAuth providers, which is nice, but also pretty niche.

<comment><USER4> > _Passwordless works for users whose email providers are not also major OAuth > providers, which is nice, but also pretty niche._

You're making a flawed assumption that just because a major email provider offers OAuth, that websites themselves will also integrate with that OAuth provider. Yahoo Mail supports OAuth, but that's not worth a damn if sites don't explicitly integrate with Yahoo and provide a "Sign in with Yahoo" button.

 _That 's_ why we need email-based authentication. Because, in practice, sites are going to integrate with Gmail and Facebook and call it a day.

(On the flipside, there's a great opportunity for Passwordless to offer optional, transparent integration with major OAuth providers, while falling back to an email loop for everyone else so people don't get locked out. That's what we did for Persona, and it mostly worked wonderfully.)

<comment><USER16> > That's why we need email-based authentication. Because, in practice, sites > are going to integrate with Gmail and Facebook and call it a day.

So what? That covers like 95% of web users right there and if some users don't like it they can go through the full signup flow.

<comment><USER17> That's a very Western centred view. We really seem to be losing sight of the internet as a global shared infrastructure, which was the point of the whole thing and where the benefits have come from. On the present course we might as well be going back to the arid experiences of fido and minitel.

</comment></comment></comment></comment></comment><comment><USER18> The post complains about the dearth of resources for authenticating an ASP.NET application to Google via OAuth 2 but ... Microsoft do that for you [1].

[1] [https://www.nuget.org/packages/Microsoft.Owin.Security.Googl...](https://www.nuget.org/packages/Microsoft.Owin.Security.Google/)

I think it's thinly veiled advertising.

        At Telerik, we're all about making the developer experience better,
        and I can't think of a worse development experience than OAuth.
        Telerik Backend Services was designed to mitigate this sort of nonsense.
        Let's take a look at how it works.

<comment><USER19> A typical low quality Telerik rant followed up with product placement. After being forced into using Kendo UI, I will never willingly use one of their products.

<comment><USER20> Got a good alternative to Fiddler? Wireshark doesn't have a headers view, does it?

<comment><USER21> [http://www.charlesproxy.com](http://www.charlesproxy.com) is great — http, ssl, throttling, decoding, filtering, replays, substitutions... It has it all. Works everywhere.

</comment></comment></comment></comment><comment><USER15> So I guess I'll be the goose at the party, or whatever the metaphor is for the person who disagrees with the headline.

First of all: author complains about spec and then pitches their in-house (non-free) solution. This is something like [https://xkcd.com/927/](https://xkcd.com/927/) in spirit, at least.

Second of all: .NET notwithstanding, there's plenty of other decent libraries for handling OAuth. Personally, I use hapijs/bell.

Third of all: I _like_ OAuth. I like the way they handle scopes, I like the way I can just authenticate a user by grabbing an identifier from some third- party provider (and link together multiple social logins). I like how I can ask for other stuff via scope grants.

I also like how I have lots of control over what my applications do. I can grab the oauth token from [provider] and generate my own token-based authentication system for accessing my API. I can do it all in the client, or I can use a client-server workflow. I can grab refresh tokens and _keep_ the oauth grant alive for longer if needs be (for example: I let my identity tokens expire and only refresh them when the user needs to open the attach file from drive widget, and I do that refresh request on the back end).

I'm not super-wild about relying on a single OAuth provider, which is why I typically allow different IdPs, and depending on the project will also do regular username / password, but man I love when I don't have to worry about dealing with authentication. Let google handle "I forgot my password" errors, let me focus on the rest.

I have to be careful, as there are pitfalls: you can't do token auth if you're not always on https, since OAuth basically falls down if someone gets on your transport stream. You have to understand how the system works and how to use it. In other words: you have to be a programmer to use it.

That's not to say OAuth is perfect. But it by no means has ruined everything. For example: would I rather have a better, more intuitive federated authentication and ID validation system, or would I rather Apple allow multiple browsers on their iOS platform so I can start using modern web tech instead of dealing with mobile safari's foibles? I'd say mobile safari is ruining things far more than OAuth, at least IMO.

<comment><USER22> Yea. I found Oauth to be pretty straight forward and easy to figure out. I'm also pretty new to this game, so I couldn't imagine people with more experience than me having difficulty implementing it properly. The blog posts seems more like a clever marketing scheme than a real rant against setting it up.

</comment></comment><comment><USER23> OAuth2 isn't a spec. It's merely loose guidelines.

I've worked with dozens of OAuth2 providers, and I am yet to see two implementations that are interchangeable. That's the point of a spec! All implementations required custom code. It's absolutely insane. We need a better way. Whatever replaces OAuth2 needs to be much more strict in how it should be implemented.

<comment><USER24> In what way is OAuth2 not a spec? Both your comment and the article leave me wanting some concrete complaint…

<comment><USER23> The definition of a spec is "an act of describing or identifying something precisely or of stating a precise requirement."

OAuth2 is really just a collection of suggestions. Here's some examples:

      * What field should the token be passed back as?
      * What are the token + auth URLs?
      * Should there be a separate profile URL, or is user data passed back with the token?
      * What field is the email address passed back as? The user's name?
      * Are refresh tokens used? How?

These are just things I literally ran into today. There's hundreds more things like this.

And on top of that, pretty much every single OAuth provider requires custom code: [http://passportjs.org/](http://passportjs.org/)

<comment><USER25> Yep- don't get me started:

* Do access token expire and need to be refreshed at all?

* Are scopes used?

* Appropriate header values?

* Can redirect URI be overrided in auth request (my personal favorite)?

<comment><USER26> * Do access token expire and need to be refreshed at all? => [https://tools.ietf.org/html/rfc6749#section-4.2.2](https://tools.ietf.org/html/rfc6749#section-4.2.2)

* Are scopes used? => [https://tools.ietf.org/html/rfc6749#section-3.3](https://tools.ietf.org/html/rfc6749#section-3.3)

* Appropriate header values? => [https://tools.ietf.org/html/rfc6749#section-7](https://tools.ietf.org/html/rfc6749#section-7) as well as [https://tools.ietf.org/html/rfc6750](https://tools.ietf.org/html/rfc6750)

* Can redirect URI be overrided in auth request (my personal favorite)? Sth. like [https://tools.ietf.org/html/rfc6749#section-10.6](https://tools.ietf.org/html/rfc6749#section-10.6) ?

<comment><USER27> while you're technically right, did the implementers knew and followed the spec as well? now THAT's the real problem.

most of them did, but there are quite some gaps.

then you extensions and shit to complicate matter further: [http://hueniverse.com/2012/07/30/on-leaving- oauth/](http://hueniverse.com/2012/07/30/on-leaving-oauth/)

I like OpenID efforts to making a OAuth 2.0 subset that works and is authoritative, but to be honest implementing OAuth dialect isn't that much of an issue.

now, having a single consistent user id across services beyond their email, that's an interesting problem to solve.

but for everything OAuth one can find out libraries in many languages.

</comment></comment></comment></comment></comment></comment><comment><USER28> Bring back Mozilla Persona: [https://www.mozilla.org/en- US/persona/](https://www.mozilla.org/en-US/persona/)

</comment><comment><USER29> I've arrived at the opinion that users simply cannot be trusted to keep their own credentials safe. It's literally impossible to secure a system based on trusting the user.

There are very successful businesses (mint.com) built around the concept of sharing extremely sensitive credentials for some reward.

In the tutum intro video I watched yesterday, the pitchman is asking developers within the first minute of video to enter AWS credentials into his website I've never heard of.

If _anyone_ would balk at that suggestion, I would expect it to be developers, yet they are so successful, Docker is buying them for meeellions of dollars.

I'm really surprised no one in the thread has yet mentioned yubico as a solution. I like yubikeys because they are something users can't upload. Keys are a concept everyone understands, and despite what I'm told by friends, I've yet to lose mine. I've never lost my car/house/mailbox keys either though.

Maybe I'm odd in both respects. I keep my credentials and keys close to me.

<comment><USER30> I found keeping my Yubikey Neo on my actual keychain to be a bit inconvenient, but wearing it around my neck like a dog tag has worked great.

Sadly, I've been unable to convince my wife that it's worth it. She won't wear it as a necklace or bracelet, almost never has pockets, and rarely has her keys near her when at home. I might just have to stick an Edge-N in her laptop and slip an Edge onto her keychain, so that when she inevitably calls complaining she can't log into GMail from a friend's computer, I'll be prepared...

From a development perspective, I've read through the U2F spec, and it seemed quite reasonable. I haven't had a chance to try implementing it in anything, though.

</comment></comment><comment><USER31> > Registering for applications is a tax that nobody really wants to pay

It's quite the opposite for me. I vastly prefer a simple signup than being offered to sign in with an account on a 3rd party site _that I don 't have_ or don't want associated to another site.

I like to wear more than one hat.

</comment><comment><USER32> Authentication on the web is not going anywhere until browsers implement native identity support.

The constant focus on authentication and "identity providers" in discussing this stuff misses the fact that sites and apps, above all, are concerned with continuity: The next time I'm visiting foo.com, I'm the same person that visited yesterday. It's the good old session cookie.

Right now, most sites ask you to sign up with an email address because that's the constant; but that leads to a proliferation of accounts strewn across the Internet, each with its own password and identity data. On the other hand, the whole idea of authenticating through a third-party provider such as Google just centralizes identity with what ends up being a very small pool of select providers, because nobody wants to show 42 different "login in with..." buttons.

But all we really want is that browser can prove (cryptographically) to foo.com that I'm "user #2048203", and foo.com can prove that it is privy to that information. foo.com shouldn't get anything but a opaque identifier, and anything else it wants (my email, my name, my address) can be divulged through an API dedicated to this purpose.

The whole login problem was derailed because of _authorization_ ("site foo.com wants to access your contacts"), which OAuth was originally designed for, was abused for authentication. But authorization is a completely orthogonal use case, and it's a fairly limited compared to login; I authorize an app maybe once a month, but I login every day.

We don't need or want Google or Twitter or any third-party authority to manage our identities. What we do need is to be able to store our sets of identities somewhere so that all our devices can share them — Apple could offer that through iCloud, for example, and browsers could easily give you different options.

Apple already invented ApplePay, which is exactly this for payments. Isn't anyone working on something like this for login?

</comment><comment><USER33> For fun: Why I Love Basic Auth:

[http://www.rdegges.com/why-i-love-basic-auth/](http://www.rdegges.com/why-i- love-basic-auth/)

<comment><USER34> But how does the consumer get the credentials in the first place? That's the main or only purpose of Oauth!

<comment><USER35> I like _Simple Value_. It was a concept that a lot of people have stopped using. You either allow a user to use your site without signing in, with extra value for them if they do OR just provide the value proposition up front so that they will be willing to sign in.

Obviously, this won't work if you are hocking sluggish blogspam with less content than the titanic had lifeboats and enough javascript to track my cross atlantic voyage. Just make shit that doesn't suck and users will sign up if it is necessary. If there is no need to have users sign up don't have it.

Super Simple Value. Build on Super Simple Auth ^TM.

<comment><USER36> This earned a hearty chuckle. +1 Insightful to boot.

</comment></comment></comment></comment><comment><USER37> One of the folks behind OauthBible.

Have you looked into Kong [1]? We built it as Open-Source proxy (based on NGINX) that has many out-of-the-box plugins for Authentication: including JWT [2], HMAC and the tedious OAuth2 [3]. For example, Kong reduces the complexity of adding OAuth2 to your services in just a restful POST request, similar to this:

$ curl -X POST [http://kong:8001/apis/{api}/plugins](http://kong:8001/apis/{api}/plugins) \

        --data "name=oauth2" \

        --data "config.scopes=email,phone,address" \

        --data "config.mandatory_scope=true"

Another alternative is Auth0.com but it's cloud based and Kong is obviously a fully featured API Gateway that does many other things so it might be too heavy if all you need is authentication.

[1] [https://github.com/Mashape/kong](https://github.com/Mashape/kong)

[2] [https://getkong.org/plugins/jwt/](https://getkong.org/plugins/jwt/)

[3] [https://getkong.org/plugins/oauth2-authentication/](https://getkong.org/plugins/oauth2-authentication/)

</comment><comment><USER38> I'm curious what people's opinion of Oz is as it was created by the "Fuck OAuth" guy aka Eran Hammer that the article refers to. [http://hueniverse.com/2015/09/19/auth-to-see-the-wizard- or-i...](http://hueniverse.com/2015/09/19/auth-to-see-the-wizard-or-i-wrote- an-oauth-replacement/)

</comment><comment><USER39> Has anyone worked with or have a strong opinion regarding CAS?

[http://www.yale.edu/tp/auth/cas10.html](http://www.yale.edu/tp/auth/cas10.html)

It's very similar to OAuth, except way simpler to understand, and very easy to implement (I'm working on a standalone go server that will perform authentication, but have been dragging my feet a bit so it's not done yet -- basically the only reason it's not shipped is that it's failing tests)

<comment><USER40> CAS is not federated. If your CAS authenticated wiki detects you're not logged in, it redirects you to what it knows as _the_ CAS url, not YOUR CAS url.

This makes it wonderful for universities and large institutions that deploy lots of small applications and buy third party hosted services, as you can keep the passwords local while proving identity and providing relying parties limited data they may need for authorizations.

But if you don't have an account my CAS setup recognize, you'll need to make one first. And if you have one with another institution, we won't recognize it.

<comment><USER39> Yes, CAS is primarily for that usecase, but could you explain what stops Facebook (or some other current oauth provider) from running a CAS server and enabling me to register a callback URL and using it to authenticate a user visiting my site?

Maybe I'm misunderstanding something fundamental

<comment><USER40> Well, I mean, a lot of the complaints about OAuth2 revolve around how the system was designed for high scalability over security; OAuth tokens never expire.

Beyond that, I'd have to think a bit. I haven't studied OAuth2 in sufficient detail really.

</comment></comment></comment></comment><comment><USER41> OMG. Give me a frickin break. OAuth is hard? Get serious, get a CS degree, then come back here and tell us OAuth is hard.

Complaining that it is a weak standard, however, is an argument that holds water.

</comment><comment><USER42> The author has actually just described a standard called Open ID Connect, which is built upon OAuth 2.0 and JWT. Those same steps can be used to authenticate with Microsoft accounts.

</comment><comment><USER43> OAuth might not be good but this "article" is just a commercial for their product.

</comment><comment><USER44> > only after lifting code from what's got to be the most obscure message board > on the internet. So obscure that I can't find it anymore.

Side note, but this is one of the reasons I always put in a comment with a source URL when I lift code from somewhere.

</comment><comment><USER45> [https://tools.ietf.org/html/rfc6749#section-1.8](https://tools.ietf.org/html/rfc6749#section-1.8)

```

       OAuth 2.0 provides a rich authorization framework with well-defined
       security properties.  However, as a rich and highly extensible
       framework with many optional components, on its own, this
       specification is likely to produce a wide range of non-interoperable
       implementations.

       In addition, this specification leaves a few required components
       partially or fully undefined (e.g., client registration,
       authorization server capabilities, endpoint discovery).  Without
       these components, clients must be manually and specifically
       configured against a specific authorization server and resource
       server in order to interoperate.

       This framework was designed with the clear expectation that future
       work will define prescriptive profiles and extensions necessary to
       achieve full web-scale interoperability.

```

So what are we waiting for? I don't think OpenID Connect is the answer here, maybe something more in the direction of IndieAuth ([https://indieauth.com/](https://indieauth.com/)).

</comment><comment><USER46> Implementing OAuth 2.0 client and server code in a .NET stack this summer for a job makes me inclined to agree that OAUTH has confusing points. It definitely is not precise enough to be called a specification, but more just guidelines. I am quite impressed with how the author overblew the whole thing to show off their solution, it was an interesting fusion of technology and selling their idea.

</comment><comment><USER47> Similar read[0] with an actual proposal replacement for OAuth at the end. Thoughts?

[0] [http://hueniverse.com/2015/09/19/auth-to-see-the-wizard- or-i...](http://hueniverse.com/2015/09/19/auth-to-see-the-wizard-or-i-wrote- an-oauth-replacement/)

</comment><comment><USER48> If you feel it's boring to learn how to authenticate your users, from a security point, you should probably not do it.

Meteor.js has a very beatiful way of solving this and I strongly recommend everyone who wants to authenticate users but don't want to know how it works to try Meteor.js.

<comment><USER49> OAuth is for authorization, not authentication.

<comment><USER50> That may have been the intent, but in a (very, very) large portion of cases the developer simply wants a way to verify identity claims. That is, verify that you are who you claim to be. 3rd party identity providers (Facebook et. al.) are a convenient way to do this, for both the user and the developer (maintaining your own passwords is a pain etc). It's coincidence that these providers choose oAuth for this, but you still end up with oAuth for identity, not auth'z.

<comment><USER49> The phrase "verify identity claims" just means "authorize". There has never been a version of OAuth that would _authenticate_ an identity.

edit: Sorry, it's easy to understand how "verify identity claim" does sound like authentication. What it means for OAuth, is that a system authorizes access based on delegated authentication. So "verifying an identity claim" is binding a local authorization event to a remote authentication event. Or something.

</comment></comment></comment></comment><comment><USER51> I made a Facebook and Twitter OAuth libraries, and I can see it sucks. Twitter's PHP library that is linked on thier documentation is based on a really heavy OAuth library and it's old a bit that most things their aren't need and it seems to care that as long it works it's fine.

Facebook OAuth isn't complicated since they don't look to care about "security" as much as Twitter do (or just Twitter trying to implement every OAuth specification blindly). But again Twitter trust you with thier Token for life while Facebook is for a while...

So I agree with the author except on the part when he said he came up with a good alternative which is just a step behind.

</comment><comment><USER52> OAuth is broken by design. Among many other serious issues, it's ridiculous that Twitter and other major OAuth adopters still implement it in a manner that relies on native/mobile client applications uniquely identifying themselves with "secret" keys that are trivially easy to extract.

It's deeply unfortunate that so many of the people involved with the spec chose to shout down critics and hand-wave away serious concerns until it was too late to fix the problems. OAuth 2 should have provided an opportunity to address the issues, and instead it just rubber-stamped many of the worst practices used by implementors.

</comment><comment><USER53> So no mention in the article of Open ID Connect?

<comment><USER54> It's even more inexcusable because half of what he's complaining about (id_tokens, JWT, aud, etc.) is actually OpenIDConnect and isn't even part of the OAuth2 spec.

<comment><USER55> It seems like the author doesn't realize that. OpenID Connect fills the specification holes in OAuth 2.0 that he is complaining about.

If he had used an OpenID Connect library, his life would have been a lot easier.

</comment></comment></comment><comment><USER56> You shouldn't have to "Allow" a big provider like Facebook or Google to share your first name, last name and sex with a website, just so they can display it back to you.

Fred Wilson spoke about the rise of decentralized identity:

[https://www.youtube.com/watch?v=R43OKYmGbhU#24:00](https://www.youtube.com/watch?v=R43OKYmGbhU#24:00)

Do you think such a thing exists successfully yet? Anyone heard about good implementations?

</comment><comment><USER57> From implementation standpoint, I frequently use Google Auth and a bunch of their APIs. At least for Python, I can confidently say that they are not at all painful. Yes, there is fragmentation between different oAuth providers but unless you are writing oAuth library yourself, you may not need to face these problems ever. Fyi, I am not using any oAuth lib but then I only use google auth for my app, not fb or twitter.

</comment><comment><USER58> I'm surprised I don't see more buzz about Steve Gibson's SQRL authentication system during discussions like this. It seems lightweight, simple, and fairly well thought-out.

[https://www.grc.com/sqrl/sqrl.htm](https://www.grc.com/sqrl/sqrl.htm)

</comment><comment><USER59> "It's a sentiment that's so common, it has it's own Twitter account."

So does Texts from Dogs.

Twitter is not a good measure for anything.

</comment><comment><USER60> See, and here I was thinking that people who whine about technical complexity without understanding it just to push their company's product was "ruining everything".

Don't get me wrong - OAuth is neither fun nor straightforward. But making "yuck" faces at the details isn't helpful.

</comment><comment><USER22> lol.... I implemented both Google and Facebook's Oauth as a complete noob. It was super easy. Like literally its a button and a few lines on the client and a few GET/POST requests to double check the user says who they say they are on the server side.

</comment><comment><USER61> Deal with it. Want to use a framework, learn how to use it properly, especially if it's authentication/security related.

Programming is hard. You won't learn anything about the technology by only using high level point-and-click libraries and IDEs.

best regards, Steviee

</comment><comment><USER62> Will anyone that is interested in authentication protocols participate at the Chaos Communication Congress late this year?

I might present a new solution to this OAuth madness, and I will be looking for people to help me finish the project.

</comment><comment><USER63> See Homakov edition of OAuth, it's simpler and more secure [http://www.oauthsecurity.com/](http://www.oauthsecurity.com/)

</comment><comment><USER64> And if you think it ruins the user experience when a person is involved, it's even worse when if you need to automate api calls.

</comment><comment><USER65> Disappointing article. The executive summary could be "software development is hard". Well, we knew that.

</comment><comment><USER66> Isn't OpenID Connect supposed to solve this? (don't know if it actually delivers though)

</comment><comment><USER67> I hate OAuth [2.0] as well.

So how do you do twitter? They don't have a full JS client side implementation..

</comment><comment><USER68> I for one, am very happy about this. Difficulty with centralized logins encourages sites to maintain their own ID system, which, along with mailinator and tools like 1password, allows people to trivially generate separate logins/email accounts/passwords for each site that they visit.

<comment><USER2> That seems rather like throwing out the baby with the bathwater. If there was a strong federated identity provider, there would be less crappy passwords out there.

Despite what it might seem like from HN users, the vast majority of people don't use password managers.

<comment><USER69> If there was a strong federated identity provider, there would be one massive target for abuse and attack.

If there was a well written protocol and library to help with the independent federation of identities, that could be used by anyone, that would truly help the security of the vast majority of people.

<comment><USER70> Oh, do you mean like the massive target for abuse and attack that are password managers?

<comment><USER49> Password management software centralizes the credentials of a given user. But each instance of the credential database is highly decentralized.

So it's only a massive target if you then recentralize those credential databases on a cloud storage service, for example.

Attacking the security of a password management system is different than stealing the credential database.

</comment></comment></comment></comment></comment><comment><USER71> Damn, and I was so busy hating SAML and hoping next system would use OAuth.

</comment><comment><USER72> While I have my issues with OAuth, I think it depends on the use case more than anything. For example, I have written a custom ticket system for my current company, and since they have drank the google coolaid, everyone has a google apps account, so using OAuth2 to provide an easy login that doesn't require the often clueless users to remember yet another password. (working on pushing pass management, yubico integration and other two factor). It was simple to implement, gives me information that is helpful (the person who submits the ticket doesn't have to tell me who they are, I already know.), and just works.

On the other hand though, I have two side projects at the moment. A reddit/hn- esque news site dedicated to logical analysis of stories, and an Unreal Engine 4 FPSRPG game.

For the game, I really want to encourage good security, both for accounts (the game website accounts) and for game login (game login accounts). Looking at the issues that the major MMO providers ran into, and for example, Blizzard finally come out with the Battle.net authenticator, but adoption was fairly low, but the important part is for the people who valued their account greatly, it was often worth the overhead. Besides that though, there was just a simple in-house auth. I don't think anyone would want OAuth to login to an MMO, so there it's not even an option. The alternative I have thought of is instead of a physical dongle authenticator, having some sort of two factor built into the login portal. While it doesn't offer the same protection as a dongle, it would be more than the simple user/pass combo to help reduce compromised accounts.

For my news site on the otherhand, I am struggling to decide what kind of logins to allow/seek. Since it would be a social type of site, OAuth could be useful for people who want an account but don't want to sign up for yet another thing. As a privacy conscious person though, it raises lots of privacy and user identity concerns. Reddit free-for-all style user-creation though seems to be too apt to be abused in all kinds of ways, but then HN has a similar system but then prevents that with restrictions on top. (which I think would falter under the same user-load as reddit). In the end I think the free- for-all is probably inevitable, especially if I want to allow tor connections, and restrictions will, like hn, have to be placed on top.

A lot of that is design related. Stories would be wikipedia-esque in that some users could edit, and comments would be a separate section, and I think that's where slashdot style random mods and perhaps user points over time would give good commenting users ability to then do edits... I still haven't ironed all that out yet.

The bottom line is that it's all about use case. And while OAuth isn't perfect, sometimes it works just fine, and in others it won't. Use the right tool for the job.</comment>


BlueHost, HostGator and HostMonster down - <AUTHOR> http://mashable.com/2013/08/02/bluehost-down/ VPS with multiple client websites hosted on HostGator. Should I move or should I stay? <comment><USER2> Our VPS plan was down all day today, with only a claimed attack yesterday, then Server update issues claimed today. Anyone know what really happened?</comment>