Some HNers seem to hate Rails. I want to know why. - <AUTHOR> http://joncanady.com/2010/09/13/when-has-ruby-on-rails-failed/

<comment><USER2> <rant>

If I'm a good C programmer, if I grok Lisp, if I'm fluent in Python, if I can accomplish damn near any file munging task from a bash prompt, and if I have an understanding of component-based development, then I should be suitable for the vast majority of programming jobs. Yet something like 90% of job postings require X years of experience in Ruby, PHP, Java, or some Microsoft-specific language. Many of the interesting programming jobs have chosen to select for a language that I could learn in a couple hours, work with in a couple days, and use well in a couple weeks, but because I don't know it _right now_ , I'm not hire-able.

 _Background, intelligence, and work ethic be damned, you need Ruby and Rails experience to work here, because after all we have many applicants and someone is bound to fit all our criteria. And while we're on our soapbox, why-oh-why are good programmers so hard to find?_ Because you're not even trying. You have too much other crap to do, and you're just looking for a quick, safe reason to reject everyone else and have a couple people conveniently left over to choose from. And no, I don't know the ins and outs of b-trees anymore, but give me some time with Google and vim and I'll have a C solution ready to be tested. You know, the way real work is done.

So yeah, I suppose I do find myself bitter that I'm expected to pick up a trendy language and platform (and recall every data structure I learned 4 years ago) to even have a chance on the job market. From the outside it just looks like a giant Ruby/Rails clique (or PHP/Cake, or Java/Spring, or whatever technology your company has happened to fall into). We're all forced to learn something that we don't _actually_ need -- we can already get it done with similar effort in another way -- just for you to consider hiring us. And everyone has a slightly different stack that I have to go teach myself just to avoid looking like an idiot in the application process.

And it's not just Rails and the languages I don't know (yet!). Even the Python job postings I find almost without fail require experience with Django or some other framework _du jour_. I mean geez, how long does it take to learn a freaking framework, especially with a bit of early guidance? Stop selecting for the wrong criteria!

I'm not one of the ones typically "bashing" Rails, but I understand the frustration of being forced to learn a bunch of crap as part of an elaborate mating game of inefficient, badly-designed hiring practices. Just throw some work my way, give me the email of a knowledgeable employee who can answer occasional questions, start me out at a below-market rate, and evaluate my role and contributions in a month or two when I've had a chance to get acclimated. The filters that employers use are such bullshit, and then to make it worse they slap us in the face by claiming that it's impossible to find good programmers.

</rant>

What was the question again?

<comment><USER3> I'm not saying I disagree with the principle (I very much agree that it shouldn't be this way), but this seems like a rather impractical argument.

 _a language that I could learn in a couple hours, work with in a couple days, and use well in a couple weeks

...

I do find myself bitter that I'm expected to pick up a trendy language and platform (and have arbitrary recall of every data structure I learned 4 years ago) to even have a chance on the job market._

Are you saying you feel you don't have a chance on the job market, and that you'd really like to have a shot at all the Ruby jobs out there? Why not spend a couple days becoming proficient hacking together a couple OS projects (or contributions) to show your proficiency (hint: the majority of Rails devs I know don't have any OS work to show)? I guarantee this will trump all the "X years experience" requirements and give you a legit shot at all these jobs.

<comment><USER2> > Why not spend a couple days becoming proficient hacking together a couple OS > projects (or contributions) to show your proficiency (hint: the majority of > Rails devs I know don't have any OS work to show)? I guarantee this will > trump all the "X years experience" requirements and give you a legit shot at > all these jobs.

That's a great suggestion. But why does no one put that in the requirements? "Fill this arbitrary criteria -OR- show us that you're a good programmer."

There's even a problem there in that if you've been working with a security firm or just in internal software for long enough, it can be impossible to show all the amazing shit you've done. Everything is "For an extra-good chance at getting hired, show us your GitHub and StackOverflow presence." If we want to get paid, it seems we first have to be willing to work for free. For those of us who have been out of college for a few years, are paying back $60K in debts, and have settled into a soul-sucking tech job that leaves you wanting to nap in the sun by the time you get home, it can be hard to break out of the cycle.

What I'm really saying is that "the Ruby jobs out there" should in actuality be "the programming jobs out there. Oh, and we happen to use Ruby, but since you clearly understand analogous languages, that shouldn't be an issue."

<comment><USER3> It's worth noting that when you submit your resume/cover-letter/application for a job, it goes to 1 of 2 people. It either goes to some administrative assistant whose sole job is to filter through all the resumes that don't meet some arbitrary requirement (simply a function to arbitrarily cut down the number of resumes they actually have to read). Or it goes directly to the executive hiring for the position. If your resume makes it to this person, pretty much nothing is set in stone (including their own requirements).

Case in point, when I first graduated from college, I landed an engineering job that had "10 years industry experience" as a hard requirement.

<comment><USER2> Thanks a lot for the data point. I guess the real lesson is to show an interest in and affinity for a position and just apply for it, requirements be damned.

<comment><USER4> I got my first job in programming by simply applying to _every_ IT job at a company where I worked in the mailroom.

Because it was an internal interview they had to do it (some kind of rule they had to follow) and finally they gave up and gave me a chance with the testy remark that if I failed they never ever wanted to see my face again.

Worked fine :)

</comment></comment></comment></comment></comment></comment><comment><USER5> When I first used Rails, I was frustrated by two main things:

* Files everywhere! I like starting simple, and you generate all these folders with things I just don't want to deal with yet.

* Lots of things were implicit, making it difficult for a newbie to the framework to understand the flow (How do we get from the controller to the template? was one, I think).

Now, that was several years ago (a little over 3, now), and both Rails and I have changed. I've been waiting for Rails3 to give it another chance, but haven't found the right project yet.

My current gripes with Rails are this:

* DHH is a prick.

* It's damned difficult to find a good Ruby feed that doesn't get polluted with Rails stuff.

My first issue is, of course, not very valid, but I have to admit that it exists.

For the second one, yes, I program in Ruby (and love it!), but I'm not using Rails. Even when I do web development in Ruby, it's with Sinatra. So, I don't want to see your frackin' "Ruby tips" that are actually Rails tips!

</endrant>

</comment><comment><USER6> I think the problem with MVC web frameworks in general is that it makes it makes the easy/boilerplate stuff really easy, but the hard stuff harder. Sure, if you doing a simple CRUD app that is only updating a single table it is fine. Beyond that, you waste so much time trying to figure out how the frameworks wants you to represent composite objects, and debugging the default model binders, then thinking you might have to write your own binder, then just saying screw it and reverting to Request.Form[] and parsing your own requests.

<comment><USER7> I absolutely agree that a complex, n-table, n-page site does not scale with MVC in general. Simplistically, [n-tables] X [n-pages] = n^2 controller methods for n controllers. So trying to make the controllers nice and OO just means each controllers complexity expands excessively.

I would be really curious. What pattern do people think scales in this general situation?

<comment><AUTHOR> In the simple case, Rails likes you to have seven controller methods and one controller per table. Realistically I usually end up throwing a few more methods on each controller.

This is actually part of the reason I like Rails: it guides the developer towards what I consider to be better application design. I understand that a lot of folks don't agree, and that's cool for them, but I still like hearing why.

<comment><USER6> I can see that working if each of the 7 tables was their own individual entity, but I am talking about a composite object here. Normalized data.

How do you manage a transaction across 7 different controller methods?

I am not saying their isn't a nice way to do this, merely using this as an example of why people may not like Rails. It forces you to figure out the Rails way of doing things. And that may not always be the best way for you, especially if you are an experienced developer.

<comment><USER8> You're describing a problem that arises as a consequence of using an ORM, any ORM, which is not at all Rails specific.

<comment><USER6> when you have to spread your updates across 7 different controller actions (methods) to make it work the Rails way, it most certainly is a rails problem.

<comment><USER9> You're assuming that there is a hard coupling between Controllers and Models. There isn't.

Rails suggests a CRUD pattern, but doesn't enforce it. You can quite easily (and elegantly) update 14 different tables from one form, using one request and one controller method.

<comment><AUTHOR> _You can quite easily (and elegantly) update 14 different tables from one form, using one request and one controller method._

You can very transparently do it with ActiveRecord associations, so that you're operating on only one instance of a model, or you can do it very opaquely, where you instantiate and update several models. Or you can just run an UPDATE statement; those haven't gone away.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER10> I think Rails is great, and it hasn't ruined any of my projects.

Once in a while, however, the magic can be a bit tiresome - you have to _know_ a lot of things. For instance that if you change the routes file, it may make a series of functions named in a certain way to appear in your views. Or just how to name everything in the right way to make Rails happy.

Often times it's a time saver, but once in a while you kind of wonder if it has to be quite so magic.

Also, sometimes those things are dynamically put together, so you can't grep for them in the source code.

<comment><USER11> _you have to know a lot of things_

 _sometimes those things are dynamically put together, so you can't grep for them in the source code_

I completely agree.

Also: the rails guides are helpful, but the generated api docs suck.

</comment></comment><comment><USER12> I really like Rails - for all the CRUDish apps of the world there's nothing better: you'll avoid reinventing a lot of boring wheels.

Perhaps the reason some HNers are Rails-phobic is that Rails is rightly designed to be precisely the opposite of tool you want for hacks: convention over configuration, config opaquely doing as much as possible for you, and development being as far as possible snapping together canonical bricks (Devise, WillPaginate et al).

If it didn't get in your way for hacks with very different requirements to the apps Rails was designed for, it wouldn't be doing its job. Right tool for the job, as ever!

</comment><comment><USER13> I don't want to be surprised by a framework.

<http://dev.rubyonrails.org/ticket/10919>

The above bug report (while incredibly funny) was a symptom of what turned me off while learning rails. Why would tables be pluralized automatically? A model might change to a word I didn't even know is the correct plural. ( I didn't go any deeper than tutorials. )

Overall I prefer Django as nothing comes as a surprise, and the shortcomings aren't a huge bother for what I do.

<comment><AUTHOR> _Why should be tables be pluralized automatically?_

Because that's frequently how you'd do it anyway. I deal in a lot of legacy data stores, and I have a lot of "set_table_name" calls.

That said, Rails is opinionated, and not agreeing with those opinions seems like a perfectly valid reason to not like it.

</comment></comment><comment><USER14> Some issues I think come from the early hype that it was the 'one framework to rule them all'. I personally love Rails but it is a bit heavy and shouldn't be used for smaller projects. But that's not Rails fault it was more a misunderstanding of Rails' sweet spot. For those smaller projects I now use Sinatra.

That said when I first started using Rails, four years ago, it should have come with a warning sticker about deployment issues. A smaller VPS that could handle dozens of PHP apps could be only really handle one maybe two Rails apps. Litespeed, Passenger, JRuby, etc. have made these issues go away, but I can see how it might have left a bad impression of the framework.

P.S. You think people hate Rails try being a Flash developer on here.

</comment><comment><USER15> Some people don't like Rails. This isn't a problem. It's not a personal insult to you or to your skills or to anyone else who likes or uses Rails. It's sometimes useful to discuss the limitations (in some subset of people's views) of software.

I say this as someone who quite likes Rails but doesn't use it at the moment. It just so happens that the bit of web work I do at the moment tends to fit Django better. But don't worry, we don't need to hate each other :)

I've flagged this article because I really can't see anything of worth coming out of it. Holy wars are very rarely that interesting.

<comment><AUTHOR> My intent wasn't a holy war.

I've used Rails for over a year. I keep hearing people say that it's slow, or it doesn't scale well, or that after the first 80% of the application is finished it gets in your way.

I haven't found that to be the case, but my experience is limited. So I'm looking for any cases where any of these things have actually happened. I want to know if these claims have any substance.

<comment><USER15> Of course there are cases where Rails isn't the right solution, that's true of absolutely everything. It's probably fine for all your uses (and for mine too) though. You are not going to get a useful discussion of them with that blog post though. You use an antagonistic tone and target a group of people who largely only exist as a group in your head, that's not going to produce good stuff!

</comment></comment></comment><comment><USER16> I'm pretty sure the general direction of the comments weren't bashing on Rails specifically, just the idea that they thought the honeymoon wouldn't end (it always does).

They went from a very heavy django background, where they saw the shortcomings of the framework (or every framework, really), dabbled in Rails for a day, loved its magic for trivial tasks (protip: most frameworks make trivial tasks easy and magical), and somehow concluded it was superior to django and that they had stumbled on a hidden gem (pun intended).

Frameworks have limitations. You will always reach a point in your career working with them that you disagree with one or more design choices, and you will have to deal with a problem the developers never accounted for. Sometimes that problem is easy to solve using your existing framework, and sometimes the framework (in solving 95% of other use cases) makes handling and solving that problem a pain in the ass. It isn't unique to django, Rails, Zend, or whatever else you happen to be using. But pretending that the framework you just discovered is perfect is just silly. Take the language you enjoy working in, find a framework that suits your style and doesn't get in your way too often, and run with it.

My apologies for still giving vague, sweeping statements, but I haven't worked deep enough with Rails for it to get in my way yet (I've only done a few simple proof-of-concept sites with it).

</comment><comment><USER17> I preferred Nitro over Rails when they both arrived in 2004. Nitro made it far easier to evolve an application from a single static HTML file to any degree of complexity (plus it was faster, thread safe, and more modular). Rails seemed better suited to a very specific genre of application. Great when you're building that app; less so when you needed to color outside the lines.

Ramaze picked up where Nitro left. All software is opinionated; I prefer the opinions built into Ramaze. Whatever tool you pick, whatever language you use, make sure the opinions it embodies align with yours, or you'll find yourself frustrated way too often.

But I really think the alleged hating on Rails has more to do with how some people perceive its more vocal proponents. Sadly, it all feels like being back in high school again. It's the "rock star" and "hero" nonsense that grates.

People would do better to scope out the various languages and tools, learn to appreciate the good stuff, steal the better ideas for their own preferences, and ignore the personalities and drama.

Code talks, bullshit walks.

</comment><comment><USER18> I moved away from Rails because the data model didn't fit my app. But I still use it for all the management applications.

Here's a writeup I did for EngineYard about the move from Rails to JRuby and my own app 'framework': <http://bens.me.uk/2010/jruby-in-practice>

<comment><AUTHOR> Fascinating. I'd love to hear about the data model mismatch -- having done mostly CRUD webapps, I'm not really in a position to see that.

<comment><USER18> Well, the main problem is that the user data we store is multi-valued. So each attribute can have multiple values in the same 'record'. As you can imagine, Rails doesn't help much in this situation, as it assumes that each column in the databas table has just one value.

<http://www.oneis.co.uk/technology/object-store>

Oh, and each application on a multi-tenant app server can have a completely different schema. Again, there's not much that Rails can do to help.

Rails was good to get going, and it helped for the relational stuff in the app. But unsurprisingly, if you try and use it for something it's not designed to do, it's not going to work terribly well. This principle applies to everything.

</comment></comment></comment><comment><USER19> I first experimented with Rails in the 0.7 days, and stuck with it until sometime in the early 2.x series. The general complaint you mention about "it got in my way and I had to abandon it" is basically at the top of my list.

As Rails evolved, it picked up a _lot_ of cruft, and when things went subtlely wrong (or I was trying to track down a "magic" method) it was just a big pit of morass to dig through. About that time (nearly 3 years ago) I switched to Merb, the new kid on the block. That's had its own share of pain to deal with, and at work we're now figuring it'll be worth it to migrate back to Rails 3. The Rails/Merb "merger" has resulted in a lot of good architectural cleanup, and being able to live within the regular plugin ecosystem has a lot to say for it (namely, we won't need to maintain the dozen-odd forks for merb support anymore).

</comment><comment><USER20> >it's completely won me over, replacing almost every single place I'd use PHP

which it should, php is terrible. It's OK for many purposes, but there aren't that many spectacular libraries for difficult things, lack of sophisticated IDE support, etc.

<comment><USER4> Some HN'ers seem to hate PHP, I want to know why :)

I couldn't care less about a platform someone else uses that I don't use.

Familiarity breeds contempt. So I think I'm qualified to rant on PHP because I wrote an awful lot of it over the years and am still maintaining one large PHP project that was written in the PHP2 days, so you can imagine what that's like (we're re-writing that at the moment).

If you're happy with rails, more power to you. If you're happy with python, great!

Whatever you use, if you're happy with, I'm happy for you. Meanwhile, live and let live.

So, PHP may be 'terrible' for you, but it has made me more money than all the other programming languages that I know _combined_ , in spite of all its shortcomings.

Spectacular libraries for difficult things? Not on my wishlist. Lack of an IDE? I use vi(m).

It's all just work, and work needs to be done. Use the tool that's best for you and move on, don't look back too much and kick at where you came from.

And if you didn't 'come from there' you shouldn't be having an opinion on the subject anyway, then you're just parroting.

<comment><USER21> PHP has a long documented list of shortcomings, but y'know what? Just like shell scripts, it is absolutely fantastic at small one-off but long-lived programs.

<comment><USER4> > it is absolutely fantastic at small one-off but long-lived programs.

Like facebook? ;)

</comment></comment></comment></comment><comment><USER22> Frameworks have limits, the same guys who loved rails had a previous experience with Django where they loved it then they hit a wall and started replacing all of its components.

Of course Rails is 100x better than php.

I suspect it exhibits the same characteristics of frameworks that make a lot of people turn against Django after some time. It is, after all, an _opinionated_ framework.

If people never hit a wall with it, I'd be a bit concerned; perhaps they're probably not trying hard to push their apps beyond limits of the framework.

</comment><comment><USER23> Avi Bryant answered this here ([http://python.mirocommunity.org/video/1186/django-is- obsolet...](http://python.mirocommunity.org/video/1186/django-is-obsolete-but- so-is-e)), but on Django form. For the projects he mentions, sinatra is more than enough.

</comment><comment><USER24> "7 reasons I switched back to PHP after 2 years on Rails"

[http://www.oreillynet.com/ruby/blog/2007/09/7_reasons_i_swit...](http://www.oreillynet.com/ruby/blog/2007/09/7_reasons_i_switched_back_to_p_1.html)

</comment><comment><USER25> There's a major python slant here. I don't know why, but it always feels that way to me as a regular reader here.

</comment><comment><USER26> I think this is a great question to ask. I feel the same way, and unless I missed it in the comments so far, I don't see any specific examples that would give me pause.

I'm loving Rails so far, especially after being able to start from scratch and build a viable, working, commercial, revenue earning app in just a week. I'm sold, but scanning the horizon cautiously.

<comment><USER24> [http://blog.leosoto.com/2008/12/on-really-disliking- monkeypa...](http://blog.leosoto.com/2008/12/on-really-disliking- monkeypatching.html)

</comment></comment><comment><USER27> perhaps the theory is one day your site will blow up and you'll need to scale... or hire additional programmers. at which point these things are probably easier with a php app...

there's a certain safety in choosing the more popular language.

</comment><comment><USER28> My two guesses:

\- more job opportunity at higher billing rates for Rails

\- it's easy to hate on smug people, unless you're on their team

I'm perfectly happy with Rails, because we've now invoiced several million dollars on cool projects that we never would have worked on had we stuck to [in our case, .NET].

</comment><comment><USER7> Every system I've seen that has some "magic" also has the potential for that magic to reverse itself and become something that seems to work against you. And when that happens, it's easy for the magic to become something you "hate".

Rail and Ruby each a lot of this magic.

No matter what you say, Twitter is relevant. No matter what Twitter says, Twitter is a Rails _success_ story because Rails got a major, major site up and running fast. And naturally when the magic stopped working, everything about Rails just seemed to work them. It was what they needed until they grew into a site that wasn't well served by Rails.

Imagine if I said, "San Francisco is a terrible place to start a business and what proves it is that we experienced wild success and then couldn't rent any more office space, had to split our headquarters and eventually moved to Omaha". How convincing is that?</comment>


Unbounded High Dynamic Range Photography Using a Modulo Camera - <AUTHOR> https://www.media.mit.edu/research/highlights/unbounded-high-dynamic-range-photography-using-modulo-camera

<comment><USER2> Previous discussion: [https://news.ycombinator.com/item?id=10053691](https://news.ycombinator.com/item?id=10053691)

</comment><comment><AUTHOR> More material at [http://web.media.mit.edu/~hangzhao/modulo.html](http://web.media.mit.edu/~hangzhao/modulo.html)

</comment><comment><USER3> So this thing, instead of doing multiple successive shots like in standard HDR, it integrates over multiple shots of single pixels. Integrating AD converter comes to mind. I am sure this improves on standard HDR but it just moved the turtles one step down. With this technique you may still get motion blur, albeit only on the otherwise saturated, washed out parts of the picture.

<comment><USER4> I don't think that's what they are doing.

They are simply throwing away the most significant bits, and recover those in post processing.

</comment></comment><comment><USER5> Finally we're getting started in that direction, I knew it was possible. Sometimes I wish I were a freaking hardware engineer :)

</comment><comment><USER6> [http://web.media.mit.edu/~hangzhao/images/modulo_teaser.png](http://web.media.mit.edu/~hangzhao/images/modulo_teaser.png)

Recovered image looks a bit blurry and the edges of the building look a little bit like they are merging in the background.

But I guess it's better than having a white bright light in the middle of a normal day.</comment>


Ask HN: Help me find or build this simple mobile photo app - <AUTHOR>

I want a really simple mobile app, to take pictures and upload them to my server. I don't need any additional features.
Is there any existing app I can use to do this? I don't mind using any app, as long as it can upload the photos to my server.
Or as a mobile newbie, how can I learn to build this quickly?
I would like it to work on both iOS and Android. Is PhoneGap a good option? <comment><USER2> Upload to your server and what...? Dropbox will let you take and upload pictures, and you can install Dropbox's linux client on your server.

There are also probably dozens of ftp apps that let you take photos, or pull from your photo library.

<comment><AUTHOR> I mean take a photo with the phone camera and upload that to my server.</comment></comment>


Sense, a New Sleep Tracker with a Kickstarter Campaign, Has Raised $10.5M+ - <AUTHOR> http://www.strictlyvc.com/2014/07/23/sense-new-sleep-tracker-kickstarter-campaign-raised-least-10-5-million-investors/

<comment><USER2> I like the product but just like most of the web I don't like that they're hiding their funding sources and making Kickstarter users believe it's because of them the product will come to market.

Building a bootstrapped company is significantly harder than taking outside money. If they're not bootstrapping they shouldn't pretend to because it's _cool_.</comment>


Why Mastodon Can't Fail (2017) - mkr-hn https://medium.com/@shelraphen/why-mastodon-cant-fail-351fa7800034 <comment> mkr-hn >> _" If we define a social network's success by its ability to form and maintain strong bonds, and it's ability to be a forum for discussion, then Mastodon has already succeeded."_

This is still true in 2019.</comment>


Automattic Purchases .blog TLD for $19M - <AUTHOR> https://ma.tt/2016/05/blog/ <comment><USER2> How this process actually works is you apply to carry a gTLD (ie .blog) this application fee costs $185,000. If no one else applies for the same string, you are good to go. If they do there is an auction. The auction works like this. N parties participate and must provide an escrow account (to bid in good faith) they may bid up to what they want (and whats in escrow) and the winning bid pays out to the auctioneer (a minor fee) and the losing parties.

IE 3 parties to this auction (making this up)

automattic - 19 million paid Party 1 - 9.5 million earned Party 2 - 9.5 million earned

You are essentially paying off your competition to go away. There are some other details and this was the initial process a few years ago, I have not heard if there are any significant adjustments now.

<comment><USER3> Any idea how this process manages abuse?

What prevents me from bidding just $500,000 (if I had $500,000) to a TLD that I know is popular just to make money from the winner?

<comment><USER4> Did you read?

The fact that you pay a $185,000 fee first. And then in order to make your $500,000 bid, you have to put that money in escrow.

And then, you might accidentally remain the highest bidder and lose all that money in exchange for your shiny new tld.

<comment><USER5> $685,000 for .blog is a steal. Companies have paid millions for single domains. It was a _very_ safe bet.

Sounds ripe for abuse if you ask me.

On top of that, think about how many people inside Automattic knew about their bid. The board at least. Any one of those people could have told a friend that WP was going to bid for it. Would you not have instantly put in a small bid of $200,000 if you'd known about this and had the cash?

<comment><USER6> You pay for the privilege to be a registry. You don't own the domain in the same sense that you would own mydomain.com.

<comment><USER5> Yes, you own it in an even greater sense... because you basically own an almost infinite number of names under .blog.

As the registrar, you can choose to not sell any domain names at all other than the ones you choose to use yourself.

<comment><USER6> What makes you say that? And what do you mean with "own in a greater sense", specifically?

I'm far from an expert but I can't see how what you say is compatible with the ICANN's TLD Registry Agreement (especially section 2.9 and the whole of article 5).

</comment></comment></comment></comment></comment></comment></comment><comment><USER7> It's amazing that in the age of Google Search that anyone places any value on the TLD for a domain. Browser vendors have run dozens of studies that indicate that most people do not enter fully qualified domains in the address bar, which is why all address bars are wired into a search provider.

I feel like the the explosion of TLDs is a very thinly veiled money grab aimed at exploiting two groups of people:

1) Trademark owners

2) Unsophisticated internet marketers

<comment><USER8> TLDs give a business credibility. People are much more likely to shop at foo.com than foo.info.

<comment><USER9> The question is if people are more likely to visit foo.blog than blog.foo.com. I don't think that is the case.

<comment><USER9> OTOH, having the ".blog" TLD allows you to start a blogging website (like Medium), and hand out domain names to your clients.

<comment><USER10> ... Which literally describes why Automattic bought it. They own Wordpress.

</comment></comment></comment></comment></comment><comment><USER11> Why does everyone has such high hopes for ICANN go be correct and ethical? Their track record reads like the equivalent of a digital mafia.

ICANN raises prices abrtrary regularly. You tell me why a .COM costs suddenly $0.22 cents more this year. It sure shouldn't be for bandwidth or storage space regarding the administration of the domain name. In fact, you would think it would become cheaper.

<comment><USER12> A few years ago 95% of the bandwidth was malign or useless (ie things like ddos attacks or endless looks around DNS lookups). If that's increased to 96% that'll counter any savings cheaper traffic.

ICANN may not be terribly nice, but please be fair.

</comment></comment><comment><USER13> This has made me realise I have no idea what the answer to these questions is: who did they buy it from? Where does that money go? Who mines/forges/lays new tlds?

<comment><USER14> ICANN.

<comment><USER15> Who can basically make new TLDs whenever, can't they? At no real cost to themselves. By what authority to they derive that privilege, why are they allowed to make such huge sums without doing anything useful for the money?

<comment><USER16> "Who can..." ICANN. Yes it can be whenever they want. No one ever stops them. They added several in 2001. Now they've opened the floodgates.

"At no real cost..." True. Except the cost of running one of the 13 server addresses. And IMO it could be a dog and no one would notice. I think the A server (220.127.116.11) is really all anyone needs. The cost of a new TLD to ICANN is the cost of editing a text file.

"By what authority..." None.

", why are they allowed..." A question I have been asking for over 20 years. Answer: Because we let them?

You can say no to ICANN. Run your own root on 127.x.x.x. You can edit the root.zone to be just as you want it. Want to delete a silly TLD (e.g., .loans)? Edit a text file. Want to add your own new TLD? Edit a text file. The cost? Editing a text file.

I recall a former Board member of ICANN admitting he himself ran his own root for many years.

ICANN's ability to make millions in profit from TLD's relies on an interesting prerequisite. All DNS admins have to use a root.hints file that points to the (13) addresses serving ICANN's root.zone. Often they have no idea this root.hints file even exists, let alone have the guts to edit it. The root server addresses to use are chosen by the authors of the DNS software, e.g., the software automatically downloads root.hints from ICANN to bootstrap itself.

If admins or users choose to use a different list of root server addresses (e.g., 127.x.x.x, 10.x.x.x., etc.), all bets are off.

So how do you stop ICANN from making millions posing as a pseudo licensing authority for registries? One way is to stop using ICANN's root.hints and use a different root.zone that you control. If enough people do this then one day ICANN has no relevance.

Right. Not gonna happen. I'm probably one of only a small number of users who will ever run their own root.

<comment><USER17> Namecoin tries to break that monopole by using a p2p database with a blockchain like bitcoin.

So far without any success :)

<comment><USER18> That is because it still relies on paying for the domain.

The Tor network can "register" and address ( call it a pointer, because it's basically a hash ) for .onion. That means if you run the the tor service, you have a pointer, and this is probably a good solution.

So if we'd all had a distributed global "dns"-like network, where each and every system gets a unique id this would partially be solved, for free, but the requirement for master nodes (like tracker servers for torrents ) would probably still be present.

The problem with this approach is that obviously you can't make a choice for xyz.mydomain, because there will be at least someone else who wants xyz.mydomain, and in this case, who and how would decide which of you can have it? Right now this decision maker is money, which of course is an issue, but at least a solution.

So: does anyone have a distributed, fair solution, that is able to solve disputes and act as a replacement for dns? So far I'm not aware of any.

</comment></comment></comment></comment></comment></comment><comment><USER19> > We wanted to stay stealth while in the bidding process and afterward in > order not to draw too much attention

Why, because a major blog host owning the .blog TLD would appear anti- competitive?

<comment><USER20> It could be worse. Google (DBA "Charleston Road Registry") had a bid in to purchase .blog and make it only usable for Blogger (= Blogspot) blogs:

> This Google Registry service causes the domain name to be associated with > the Blogger service, so that DNS for second-level domains (SLD) within the > TLD will automatically resolve to the relevant Google service. [...] Client- > initiated updates to the name servers for the domain name will not be > accepted and the server will respond with an error type 2304 - "Object > status prohibits operation".

[https://gtldresult.icann.org/application- result/applications...](https://gtldresult.icann.org/application- result/applicationstatus/applicationdetails/527)

<comment><USER21> So would WordPress/Automattic be able to limit .blog to only be used for WordPress sites?

<comment><USER20> No. The terms that the TLD was created under ([1]) effectively establish it as public.

[1]: [https://gtldresult.icann.org/application- result/applications...](https://gtldresult.icann.org/application- result/applicationstatus/applicationdetails/1746)

</comment></comment></comment></comment><comment><USER22> Huh:

"How much will a .blog domain cost?

While not yet finalized, domain registration prices will be in the standard range for new top-level domains, with some premium pricing for higher-value names."

No longer 'first come, first served', now "How much you got?". Isn't registration supposed to be egalitarian?

<comment><USER23> I've seen several "new TLD's" do this pricing scheme. Typically they come up with some kind of pricing algorithm for "premium" domains by seeing if the word is in the dictionary and how often it's used in everyday language.

Things like "business.blog" will fetch a price that'll likely be in the 4 or 5 figures a year for the registrant.

<comment><USER24> This makes sense to me. Some domain names are worth more than others. gaming.blog will probably have a lot of value, while ilikegrasshoppers.blog is not worth very much. I see no reason why these things should be assigned the same arbitrary value when it is clear their values are not equal.

<comment><USER25> > gaming.blog will probably have a lot of value

I'm not sure about that; many everyday users I know are now wary of 'general' domain names and see them as spammy or suspicious.

In the UK B&Q has to remind us that diy.com is actually their retail website and not some ad-ridden "answer aggregator"

<comment><USER26> Elan is a credit card provider in the US, and the domain name for their web panel is "myaccountaccess.com". This is not as cool as they think.

</comment></comment></comment></comment></comment><comment><USER27> What does it mean they purchased .blog TLD?

Does this mean they bought every single domain that ends in .blog?

<comment><USER28> Effectively yes. Basically, they own the TLD and can sell any domains under that. So, if you want thechthrowaway.blog, you've got to pay them to purchase it. In reality, you will probably purchase this from godaddy or similar, but ultimately they own the namespace and set the price on the cost of the domains.

<comment><USER29> One way to combat this kind of thing is to just not own any domain names whose tlds are owned by private corporations.

<comment><USER30> You prefer state controlled?

<comment><USER29> Yes. If one country tld is unacceptable you can use a different one. There's lots of options.

<comment><USER30> Couldn't you apply the same principle to TLDs controlled by private companies? There are lots of options.

</comment></comment></comment></comment></comment></comment><comment><USER31> I would assign anything hosted on .blog a _huge_ reputational hit. But the fact that so much money was put behind it makes me think of two possibilities:

1) Auttomatic has far more money than sense, or 2) I am out of touch with the way other internet users assign value to domain names.

It's entirely possible that the second one is true. I've been using the internet for twenty years now, so I really have no idea how meaningful other people find particular gTLDs.

<comment><USER32> I think that in your head you're comparing this to buying a single domain name, e.g. playing 19 mil for blog.com or something, but it reality Auttomatic is really paying to be the registrar for .blog domains. I can imagine a lot of reasonable people paying $19 a year for a myname.blog website.

<comment><USER33> > I can imagine a lot of reasonable people paying $19 a year for a myname.blog > website.

Why would a reasonable person do that when they can do something similar with blog.myname.com (and the like)?

I don't know how the new TLDs have been perceived, but I certainly would prefer a nice sounding myname.com than a website on any of these newfangled names.

</comment></comment></comment><comment><USER34> This also means that automattic can take down your .blog if they don't like you.

<comment><USER35> This is true for any TLD. Just instead of Automattic it's either another company, a country, or some overreaching US agency (FBI took over .com domains in the past)

<comment><USER36> Just look at Sweden taking down ThePirateBay.se

</comment></comment></comment><comment><USER37> Wow 19 million for a couple of characters, that are an impish abbreviation of 'web log', for virtual placeholders. Does anyone even use the word blog anymore? It sounds soo last decade. How very odd. These vanity domains just don't do it for me, and this is one of the better ones.

<comment><USER38> Should we start other TLDs for .vlog and even .wlog?

<comment><USER37> .diary, .journal, .thoughts, .musings might be a better choice ;).

</comment></comment></comment><comment><USER39> I recall a while back that based on this new TLD scheme, it was mentioned that ICANN pocketed a tidy +USD100M from it.

What ICANN needs this money for, I'm not sure...

</comment><comment><USER40> They should send a bottle of wine to Peter Merholz :) [http://www.peterme.com/archives/00000205.html](http://www.peterme.com/archives/00000205.html)

</comment><comment><USER41> Is it possible to create 2-letter TLD's instead of .mycoolbutreallystupidtld or just plain .bullshit TLD's?

There are plenty of unused 2-letter TLD combos around, why bother with .blahblah ?

<comment><USER42> All unused two letter combinations are reserved for country-code top-level domains. This is to ensure future countries have the ability to have their own TLD. New countries are created perhaps more often than you may think, on average about one per year or two.

</comment></comment><comment><USER43> What is wrong with wordpress.com?

Is that the best use of funds?

Why not put at least 1/10th of that money into just providing a sliver of love to their big breadwinner Wordress VIP?

</comment><comment><USER44> Charging more for some domains than others. I am disappointed.

<comment><USER24> Why? What intrinsically makes the value of all domains equal?

<comment><USER15> Intrinsically they cost less per instance for each new one registered. It's externalities - like demand, marketability, pronouncability, fashion, coincidence with trademarks - that allow them to be sold at high prices.

The web has been historically very democratic and ICANN's dicking about with internet domain names is one of many things that seems to be moving increasingly away from that ideal.

</comment></comment></comment><comment><USER11> Hooray! More Wordpress websites

</comment><comment><USER45> Heh, I don't know why it's at all surprising but I, for some reason, expected there to be some kind of restrictions regarding TLD ownership/providership.

I really dislike this, that a single entity owns a TLD when they don't have any justification for it other than 'we bought it'.

At least 99% of other TLD's are maintained by countries/orgs/etc. who at least have an arguably justified ownership.

Private entities owning all TLD's here we come.

Here comes the end of any potential anonymity that DNS provided.

<comment><USER46> ICANN began the process for this in 2008 and the first gTLDs were sold in, I think, 2012(?). However, yes, you're right, private entities will end up owning all of the TLDs and it will put likely startups at a disadvantage to incumbents as they become more common.

</comment></comment><comment><USER47> Neat: a new way to waste 19 million dollars. Silicon Valley just keeps innovating.</comment>


Jaw-Dropping Pen and Ink Cityscapes That Seem to Sprawl into Infinity by Ben Sack - <AUTHOR> http://www.thisiscolossal.com/2014/04/the-sprawling-pen-and-ink-cityscapes-of-ben-sack/ <comment><USER2> What is mind-boggling is that it is done manually by hand, and not automatically generated in any way.</comment>


Google Top Stories Serves Breitbart Bullshit on Climate Science - <AUTHOR> https://gizmodo.com/google-top-stories-serves-breitbart-bullshit-on-climate-1793541647 <comment><USER2> I'd like to point out something - I admit Breitbart is biased, but a little balance is needed here;

My google news suggestions are full of liberal news articles, not just WaPo, but random blog-like articles from sites I've never heard of, buzzfeed clones that could have been created just the previous week.

I wonder why, because my you-tube suggestions are mostly Milo, Ben Shapiro etcetc - no suggestion I'm a Jezebel reader, yet I keep getting HuffPo articles put before my; Why is this? Are there just more of these sites on the internet, or is it a bias in google news?

<comment><USER3> I up-voted you because I didn't think you deserved to be down-voted and because I believe that there is a problem with including blog articles in news results because I think it waters down the word as few blogs do original reporting. Rather they just add spin.

(I also don't think there is "liberal news" or conservative news. Rather there are different interpretations of facts. And because those generate so many arguments I think an interesting browser plugin would be one where readers could engage in a Lincoln-Douglas debate about questions raised by news.)

<comment><USER4> what's the difference between a blog and news?

<comment><AUTHOR> Journalism is a discipline of verifying your sources. A news agency would be expected to do this but a blog may not.

</comment></comment></comment></comment><comment><AUTHOR> Umm, just ban Breitbart? Seems pretty simple! :)

<comment><USER5> This helps build the business case for a conservative-leaning Google clone.

<comment><AUTHOR> meh. People can already filter their searches with search operators, for instance, "-washingtonpost -jezebel -theguardian #makeamericagreatagain" for those on the right.</comment></comment></comment>


Want to Improve Efficiency? Stop Doing Low-Value Work - <AUTHOR> https://medium.com/the-mission/want-to-improve-efficiency-stop-doing-low-value-work-41ad87e5c640 <comment><USER2> I find an interesting contradiction between the recommendations to

a) check your email only at scheduled times

b) when you are working, say no to interruptions

c) instead of replying with an email, walk over to someone's desk [and assume that they are ready to chat with you at any moment instead of sending them an email that they can read on their own schedule]

<comment><USER3> You've omitted the immediately preceding qualifier: "if something can't be resolved quickly on email, suggest a meeting or simply walk to your colleague's desk to confirm a plan."

The party sending the email has already 1. signalled importance and 2. your own filter has indicated your agre,ent.

If 1. was in fact false, there's the (perhaps remote) possibility that the sender(s) will come to realise that "send email" corresponds to "I will be interrupted in return".

As an organisational norm, this is likely a Good Thing to cultivate.

</comment></comment><comment><USER4> My struggle is with interesting but low value vs boring but high value.

The energy cost or effort cost of a task is inversely related to how much interest the task holds for me.

<comment><USER3> Keep a log or diary of what you're spending time on.

I'm a fan of the Bullet Journal model. Paper & pen, but organised.

Note your important tasks/goals, and actual time allocations.

Learn to say "no" to the trivial, or, better, structure your environment such that they don't present themselves.

Also recognise the limits to, and robbers of, yor attention and focus.

It's still a struggle, but most of us can manage some improvement.

<comment><USER5> "Keep a log or diary" ...another low value work

<comment><USER3> You are labouring under a severe misapprehension.</comment></comment></comment></comment>


Please stop using Twitter Bootstrap - <AUTHOR> http://notes.unwieldy.net/post/43508972396/please-stop-using-twitter-bootstrap <comment><USER2> > _Let's be honest: a great many of us are tired of seeing the same old > Twitter Bootstrap theme again and again. Black header, giant hero, rounded > blue buttons, Helvetica Neue.Yes, you can customize the header to be a > different color, maybe re-color some of the buttons, use a different font. > Ultimately, however, that doesn't change anything—it still looks like > Bootstrap._

Well, your blog still looks like a me-too minimal one column, design, like another 50,000,000 blogs out there (half of them on Tumblr), but you don't see me complaining, do you?

<comment><USER3> I was thinking the other day how annoyingly common the one column minimal design has become. Half the time it sucks in terms of user experience because a bunch of these themes are designed as if a visitor isn't going to be interested in reading more articles or getting some background info on the author. And since they all look the same you won't even realize that you visited a particular author's site before.

</comment></comment><comment><USER4> "And not just the same general layout, but the exact same components."

Funny how on the desktop designers demand HIG compliance and standard UI widgets, while on the web they want us to get all Kai's Power Tools on every button and widget.

<comment><USER5> I'd say the difference is two-fold. First, desktop applications generally still have unique icons and branding. Second, desktop applications have much more freedom as to how they combine the elements. Usually you can tell which application it is from a distance, because the layout has been designed to suit the app's specific needs and functions. The OS chrome itself is meant to be invisible, in favor of what makes it unique.

For example, Firefox, Safari and Chrome all look identifiably different on OS X, despite all implementing the same overall style.

Twitter bootstrap isn't just a CSS style, it's a rigid layout and UI pattern. The author is decrying the use where bootstrap is the only kind of design being done. In that case, people typically haven't considered what layout they want to use or which elements to emphasize and how. They just go with the standard 960 grid and its simple divisions, regardless of how much content there is, and take something that's meant to be invisible and emphasize it visibly by not adding anything new.

While bootstrap gives the appearance of being well designed, often the content inside it fails to live up to that promise.

</comment></comment><comment><USER6> > It has a time and a place, but you wouldn't use Times New Roman on your > startup's website, would you?

Only because I have a thing about using serif fonts in html, otherwise it might well be one of my fallbacks.

And besides, arguing that people should put more effort into restyling Bootstrap is different than arguing they should abandon it altogether. In terms of providing a framework for layouts, I think it does its job quite well, and that users will probably intuitively understand a Bootstrap site because they've encountered them a hundred times before. This in turn gives your site an implied sense of stability and trustworthiness since it "looks like twitter/etc etc."

</comment><comment><USER7> Yes, the Bootstrap components are obvious and the internet is starting to look like Bootstrap. I totally agree, I can tell in a glance whether a site is Bootstrapped or not... it's everywhere. And I also agree that this makes the experience seem less personalized, the product ends up feeling like all of the others once you make the connection, etc. (but in the end, I think this might mostly be designers / developers).

But he notes that it's 100% customizable and says "most people do not bother". That's the real problem. As long as you bother with that, you can't tell it's Bootstrapped (<http://diehlgroup.com/>) and his whole argument collapses. It's not JUST a design package for developers. It's also a basic reset and browser- compatibility package, taking away so many headaches and days and days of work.

To me, the best argument against Bootstrap is purely the weight. But even then, I can strip it down to only components I need, literally even it's just one file of LESS mixins (which is what I pretty much end up doing).

Interesting and true, though. Shits taking over.

</comment><comment><USER8> Aren't all native desktop apps effectively "bootstrap" and doesn't that consistency convey a level of affordance that only comes with standardization/popularization?

Are you going to ask iOS developers to stop using the Master-Detail Application, Tabbed Application, Cards-based Application or Page-based Application templates next?

Hate on it all you want because you think it is boring and generic, but at least acknowledge that it provides value, especially in circumstances when the alternative is an interface created by someone who likely lacks the chops to create a well-designed coherent interface.

</comment><comment><USER9> The problem here is that before Bootstrap, the only way for a non-designer to get something decent was to hire a designer. Now thanks to Bootstrap there's a whole new middle-ground of gets-the-job-done design that doesn't suck but is also very, very generic.

I still think on the whole we're better off than before because in most cases Bootstrap replaces things that were even uglier.

It's just a little disappointing sometimes when you see a company that clearly has the means to develop its own identity and design settle for generic Bootstrap.

</comment><comment><USER10> The only people who feel this way are the ultra-early adopters. Assuming most sites aren't meant for that audience, I don't think it's actually worth worrying about in the process of getting an early iteration out the door. Sure, as a site/app scales it should think more about branding but early on it's more likely a net benefit to have the kind of UX clarity that Bootstrap provides for most web users.

</comment><comment><USER11> As a developer, I find using bootstrap to lay out a project before a designers hand's touches the project really nice. It gives the project a much better look then I would normally put effort into doing and allows the designer flexibility to quickly and easily style it.

As a designer, would you rather take spaggetti html code from a developer or one compliant already with a framework like bootstrap to start working off?

</comment><comment><USER12> Sorry, but F design. Wikipedia, Google search, HN, Craigslist - they're essential - they are real value - and they're not winning any design contests.

</comment><comment><USER13> instead of complaining, sum up some alternatives.

And wrapbootstrap or bootstrap themes? :-)</comment>


Render Props vs. Hooks - <AUTHOR> https://www.reddit.com/r/reactjs/comments/h7kb92/render_props_vs_hooks/ <comment><AUTHOR> Here is the twitter discussion on the same topic.

[https://twitter.com/moubi/status/1271429303574556672](https://twitter.com/moubi/status/1271429303574556672)</comment>


There is no WhatsApp 'backdoor' - <AUTHOR> https://whispersystems.org/blog/there-is-no-whatsapp-backdoor/ <comment><USER2> Color me still-unconvinced.

This retort does not address the fundamental point made in the Guardian piece:

> "[Some] might say that this vulnerability could only be abused to snoop on > 'single' targeted messages, not entire conversations. This is not true if > you consider that the WhatsApp server can just forward messages without > sending the 'message was received by recipient' notification (or the double > tick), which users might not notice. Using the retransmission vulnerability, > the WhatsApp server can then later get a transcript of the whole > conversation, not just a single message."

<comment><USER3> This allows WhatsApp to MITM. Whatapps can rekey both Alice and Bob, decrypt both their messages from that point onwards (incl unsent messages) and forward them re-encrypted with their real keys. The only notification might be that rekeying warning, if the users have turned it on. In this scenario even the double-checkmarks are present. This is contrary to WhatsApp's claim that even they cannot snoop.

PS: I just check on my phone if those notifications were turned on. There were not. And I'd never turn those off myself, which leads me to conclude that the rekeying notifications are off by default (in their android app)

<comment><USER4> > _This allows WhatsApp to MITM. Whatapps can rekey both Alice and Bob, > decrypt both their messages from that point onwards (incl unsent messages) > and forward them re-encrypted with their real keys. The only notification > might be that rekeying warning, if the users have turned it on. In this > scenario even the double-checkmarks are present. This is contrary to > WhatsApp 's claim that even they cannot snoop._

You've just described a "man in the middle" attack. It is endemic to any public key cryptosystem, including Signal and PGP, not just WhatsApp. The notification that you see in WhatsApp, Signal, SSH, PGP, or whatever is the defense.

> _PS: I just check on my phone if those notifications were turned on. There > were not. And I 'd never turn those off myself, which leads me to conclude > that the rekeying notifications are off by default (in their android app)_

Key change notifications are off by default in WhatsApp. That's probably going to be a fundamental limit of any application that serves billions of people from many different demographics all over the world.

Even if they were on by default, a fact of life is that the majority of users will probably not verify keys. That is our reality. Given that reality, the most important thing is to design your product so that the server has no knowledge of who has verified keys or who has enabled a setting to see key change notifications. That way the server has no knowledge of who it can MITM without getting caught. I've been impressed with the level of care that WhatsApp has given to that requirement.

I think we should all remain open to ideas about how we can improve this UX within the limits a mass market product has to operate within, but that's very different from labeling this a "backdoor."

<comment><USER5> > That's probably going to be a fundamental limit of any application that > serves billions of people from many different demographics all over the > world.

Moxie, some of us are of the opinion that [that] (implied) goal is certainly noble but ill-considered.

Modern state surveillance has 2 general unstated goals:

1) Create an atmosphere of fear to affect self-censorship. Some states (such as China) announce this as a matter of state policy. Others (such as US) drop hints. UK is somewhere in between.

2) Identify emerging memes, clusters, and thought leaders. This information is then used to counter, disrupt, and discredit/isolate (respectively).

(And yes, the stated public goals are to prevent terrorism, child pornography, and crimes.)

From the political angle -- activist angle, if you will -- the goal of "serving billions of people from many different demographics all over the world" is minimally misguided, and counter productive, and maximally a hazard.

<comment><USER6> I don't understand. How is it misguided, and who is it a hazard to? Are you saying the unstated goals of state surveillance are good ones which conflict with popular use of crypto, and therefore popular use of crypto is bad?

<comment><USER7> I THINK the commenter was saying that "serving billions of people from many different demographics all over the world" is inviting all of those different people together so you can betray them all at once.

</comment></comment></comment></comment></comment></comment><comment><USER8> I take this blog post as confirmation that:

1) _ANY_ one message can be intercepted even if the sender exhibits ideal levels of alertness [Whatsapp server drops message to recipient; sends a rekey request with a fake key; message is intercepted since fake key was generated by server. Sender will see a warning if they turned on that setting (default is to show no warning), but it's too late].

2) Only Whatsapp has this vuln, not Signal app.

3) Depending on sloppiness of sender, more extensive interception is possible. [E.g., server not supplying delivery reports + sender doesn't have warning for key changes + sender sloppy about noticing lack of double check mark => full transcript can be generated]

<comment><USER9> Best summary I've seen. There are two significant facts here that surprised me: 1\. The double checkmark has security implications. How would a typical user know that? 2\. Even if you are completely vigilant, follow best practices, etc, Whatsapp messages can be intercepted. They claim this is a "wontfix" UX choice. I'm skeptical why the non-default feature cannot even provide the protection that almost everyone assumed it would.

<comment><USER10> > How would a typical user know that?

I think that's basically the main problem: there is no way to get a typical user to understand security implications of anything without having that user give up before reaching that point...

</comment></comment></comment><comment><USER11> I think all this is by-the-by. The gist of The Guardian's article was that WhatsApp has full control of when, if and how your messages are encrypted, and if you're a dissident working against an oppressive regime and you use WhatsApp to collaborate with your allies, your ass is grass, because there isn't anything physically preventing security agencies from getting hold of your communications.

That such security agencies have the power to force WhatsApp (or anyone) to comply with their demands is without doubt. A really secure system for activists would be one that makes it impossible even for the provider to read your messages, under any circumstances. WhatsApp is not just not that, it is also ridiculously easy for them to read your messages, if they so choose and you use it at your own risk.

<comment><USER12> Isn't Signal in the same boat?

They are a US company and they control what version of the app is in the play/apple store. They could be force to push a version of a flaw and no one could verify it. The source looks good but the app that has been distributed is not.

<comment><USER13> I was actually perplexed, after reading about signal, that I couldn't just download an APK.

Are play services required for signal? If so, can I even install signal on a cyanogenmod phone? Can you do so by rebuilding it yourself? Does the build match the shipped binary on the play store?

To me, Signal _does_ look exactly in the same boat as whatsapp. The fact that WhisperSystems didn't cooperate harder to ship Signal in F-Droid is also a major let-down.

Is any other app sharing the same protocol?

<comment><USER14> Used to be, called LibreSignal. They ran into legal issues.

[https://github.com/LibreSignal/LibreSignal](https://github.com/LibreSignal/LibreSignal)

There is a bounty for modifying the signal app source to drop play services.

[https://www.bountysource.com/issues/35722527-create- proper-p...](https://www.bountysource.com/issues/35722527-create-proper-pull- request-to-add-libresignal-s-websocket-support-to-ows-signal)

<comment><USER15> They can't use the name LibreSignal because it has the word Signal in it?

Wow, even Microsoft didn't behave that juvenile about LibreOffice.

<comment><USER16> Yeah, they just sued some high school kid because of the domain name he chose:

[https://en.m.wikipedia.org/wiki/Microsoft_vs._MikeRoweSoft](https://en.m.wikipedia.org/wiki/Microsoft_vs._MikeRoweSoft)

<comment><USER17> I don't know about Canadian trademark law, but at least in the States, if you don't put effort into defending your trademark, you lose it. Completely different country, I know, but perhaps there's something similar in their law.

</comment></comment></comment></comment></comment></comment></comment><comment><USER18> I love this post for the in-depth explanation of the UX challenges around e2e encryption and why they made the decisions they did. It's educational.

I think Moxie highlights a very good point that is commonly underrated among "security Dunning-Krugers": Opening yourself to the possibility of an attack is often OK if the attack is easily detectable, and if the identity of the attacker would be obvious upon detection. Yes, Facebook _could_ intercept and decrypt a message without your advance knowledge. However, you would be able to detect it after the fact. And if you detected an attack, the attacker could be no one other than Facebook. You could then expose them and ruin their reputation. Given this, it's unlikely that Facebook would risk carrying out such an attack in the first place.

Security is not binary, it's risk management. The goal is to minimize the risk of an attack, not to rule it out entirely (hint: you can't). I think WhatsApp has made the right choices here.

<comment><USER19> In most cases, I'd much rather disallow Facebook from MITMing my messages than try to "ruin their reputation" (hint: I won't, because Facebook already does far worse things on a regular basis without so much as an eye-bat from the world).

In other words: I care about the confidentiality of my messages far more than the promise of some sort of dubious ability to shame Facebook for simply fulfilling its business model. Sure, there are some cases where allowing security to be exploited in one area protects the security of another, but those are called "honeypots", and I sure as hell hope my private communications are not a part of that.

Transparency is a dependency of trust. WhatsApp is not transparent; therefore, it is not trustworthy. Simple as that.

</comment></comment><comment><USER20> At the end of the day, it comes down to trusting WhatsApp. Even without a backdoor in their protocol, they can easily do all kinds of things.

For instance, it could instruct specific clients to encrypt and send each message twice: one for the recipient, and one for the WhatsApp server. As long as this was off for 99.9% of users, it's unlikely that security researchers would ever detect this.

<comment><USER21> Trusting WhatsApp == trusting Facebook

I can't think of a company I trust less than Facebook.

<comment><USER22> What about...Walmart, Glencore, Phillip Morris, Blackwater, Palantir...

<comment><USER23> > _Walmart_

I can use cash at Walmart

<comment><USER24> And be sure to smile at the cameras watching you in the store, and the ones in the parking lot that recorded you driving in.

<comment><USER25> It's shared physical space. I'm OK if they video me. I'm OK if they share that video with law enforcement if there is a reason of substance to do so and as long as they make it publicly known they asked for it within a reasonable timeframe, say 45 days. I'm NOT OK with broad sweeping requests and would only allow them if circumstances required it and the request for the data was disclosed within 90 days.

</comment></comment></comment></comment></comment></comment><comment><USER26> >The WhatsApp clients have been carefully designed so that they will not re- encrypt messages that have already been delivered. Once the sending client displays a "double check mark," it can no longer be asked to re-send that message. This prevents anyone who compromises the server from being able to selectively target previously delivered messages for re-encryption.

Can this be verified? Can this be verified to be the case 100% of the time? Is there anything stopping the client from lying to a user [0] with this interface, saying one thing (i.e. "this will not be resent") and doing another (i.e. resending)?

[0] - Or being triggered to lie to a particular user at a particular time.

<comment><USER27> If your threat model includes using a malicious app to send messages then you lose anyway. Nothing can ever be done to send messages securely using whatsapp if the client is neither trusted nor verified. This is true for basically _all_ software that you use.

<comment><USER28> Open source software can be verified.

<comment><USER29> Source code can be verified. Binaries distributed via app stores may or may not have behavior different from the published code.

<comment><USER2> Certainly it's possible to remedy this situation simply by having the app author sign a checksum of binaries in the app store. Why this is not currently an option (to my knowledge) is a mystery to me.

<comment><USER30> It kinda is - you could add it to the description.

App stores seem to be getting progressively more hostile to this kind of thing though - you can't just download an APK / iOS app, you have to do it through a device. This lets the stores do "app slimming" (and per-country / per-carrier customized apks) to remove resources you don't need (like binaries that don't match your architecture), which would change the checksum. Which is useful, but inconvenient for this goal.

Something like fdroid may be supportive of this, which would be cool. But I wouldn't expect the mainstream ones (or Apple) to ever embrace it - it'd be a bad user experience / wasted UI space in the vast majority of cases.

<comment><USER31> It's been a while (a couple of years) since I last tried this, but I remember it being reasonably straightforward to get APKs of apps that were on the Google marketplace. Not through official user interfaces, of course. I can't remember if I ended up using some Chrome extension or a third-party app that needed root.

Not a particularly useful comment sorry, just "it was possible two years ago if you jumped through some hoops."

<comment><USER30> You can probably still get the one that'll install on your device(s), but if there's customization for e.g. carrier X in country Y (or app slimming) you're unlikely to know or be able to find it from the infinite "download APKs free now!" sites.

And the last time I looked, all the apk-downloaders required your device ID, because Google's API does (for customization reasons) - it's much more of a "you can do this if you emulate a device" than "you can download it". I'm also not sure if the ID works unless you have gplay installed, which you may not have if you're being careful/paranoid enough about security to manually validate apps.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER32> It actually doesn't matter. They are talking about comprimising the servers. The government has the power to force a backdoor (remember Lavabit?). All Whatsapp has to do is update their client, and all the beautiful encryption schemes are ruined.

If you need a truly secure communication system, it has to be open source and self-hosted. You still have to trust the hardware though.

<comment><USER33> To expand on this argument a bit, if you think the Government/Whatsapp are specifically out to get you (eg. willing to mount an active attack against you specifically), then WhatsApp is propably the wrong messenger for you.

If on the other hand you want a reasonably secure Messenger that you can use to chat privately with everybody and their Grandma then maybe you should not expect that it does super complex security thingys that 99% of its users just don't care about and don't want to be bothered with..

</comment></comment><comment><USER34> This main flagrant or off-topic, but something that nags at me when thinking about truly secure messaging apps from the App Store:

Even with perfect e2e encryption protocol added, what's preventing WhatsApp developers (FB) from adding in a feature of the app:

if local.user is "TargetUser007" { takeDeviceSnap(); sendDeviceSnapshotToFBOverSameEncryption(); }

Wouldn't this not be ever verifiable unless you ARE that specific user and it's too late?

<comment><USER35> You'd also have to make sure they were the only user that received that binary.

Otherwise you'd have to hope that no one reverse engineered the binary and noticed the oddly specific comparison there.

<comment><USER34> Are reverse engineering techniques currently greater than known ability to obfuscate compiled iOS code?

<comment><USER36> And it'd have to work for other platforms, too. Android is Java right? Which is even easier to RE.

<comment><USER37> Android apps can also contain native code. Indeed, WhatsApp includes such libraries, to help with Curve25519 encryption, video encoding, voice over IP, and other functionality.

<comment><USER36> But it should be straightforward enough to see if text messages or UI elements (suppress key change notification) are being change depending on the output of those libraries.

</comment></comment></comment></comment></comment></comment><comment><USER38> > That would leak information to the server about _who has enabled safety > number change notifications and who hasn 't_, effectively telling the server > who it could MITM transparently and who it couldn't; something that WhatsApp > considered very carefully.

I am not convinced. Why should this option exist at all? Even worse, it is disabled by default. Just enable notifications for everyone and demand verification. If you don't want to verify, just ticking "veryfied" without actual verification is not that bad, it is just a trust-on-first-use principle in action. Actually it is how SSH works and nobody complains about SSH being backdoored.

<comment><USER39> If we're talking about key change notifications, isn't SSH the thing that throws the following error when a key changes?

      @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
      @    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
      @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
      IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
      Someone could be eavesdropping on you right now (man-in-the-middle attack)!
      It is also possible that a host key has just been changed.
      The fingerprint for the RSA key sent by the remote host is
      51:82:00:1c:7e:6f:ac:ac:de:f1:53:08:1c:7d:55:68.
      Please contact your system administrator.
      Add correct host key in /Users/user/.ssh/known_hosts to get rid of this message.
      Offending RSA key in /Users/user/.ssh/known_hosts:12
      RSA host key for 126.96.36.199 has changed and you have requested strict checking.
      Host key verification failed.

<comment><USER40> Yeah, SSH is at the complete opposite end of the scale in how it handles unexpected key changes - it won't even let you connect unless you manually edit known_hosts, whereas WhatsApp automatically uses the new key without any possible way for the user to stop it from doing so until it's too late.

</comment></comment></comment><comment><USER41> Moxie claimed: > "The choice to make these notifications "blocking" would in some ways make things worse. That would leak information to the server about who has enabled safety number change notifications and who hasn't, effectively telling the server who it could MITM transparently and who it couldn't; something that WhatsApp considered very carefully."

Surely if WhatsApp cared about the server not being able to detect this, they could just get the client to "retransmit" an encrypted blank message in place of the original under these circumstances. Then the server wouldn't be able to tell who has enabled blocking mode and who hasn't.

</comment><comment><USER42> WhatsApp should make three hanged:

1\. handle new keys the same way Chrome handles expired SSL certs: a big warning with the option to continue anyway if you want

2\. Don't automatically resend a message with a new key (require the user to manually resend, like when iMessage falls back on MMS)

3\. enable the key change notifications and make disabling them an "advanced" setting

WhatsApp is making the right choice by designing for ease of use, I think they just landed a little too far away from a secure implementation.

</comment><comment><USER43> tl;dr to me seems: Since users can change devices, they'll need to reissue key material, this needs to be supported. WhatsApp reports key changing optionally, but doesn't tell the server that happened.

If WhatsApp tries to backdoor a channel and one of the users has key change notification, they'll find out about it, and WhatsApp has no idea whether the warning was shown.

<comment><USER2> > If WhatsApp tries to backdoor a channel and one of the users has key change > notification, they'll find out about it

The problem is that the might not find about out retransmissions. You are trusting that the "double-tick" means that the message won't be resent, but presumably WhatsApp can indeed retransmit those messages with the new key under pressure from a state actor.

They need to specifically address this point; it's the only thing worth talking about. The rest is just a discussion of implementation of key exchanges generally.

<comment><USER44> That would require the client to be compromised though right? My understanding is that the client is making the decision whether to retransmit with the new key.

Now it's fair to question whether you can trust the client, but if you can't then there's no limit to what they could do.

</comment></comment></comment><comment><USER45> Of course there is a backdoor. Why not? Under what law whatsapp and whispersystems live? The one with secret courts and secret court orders?. How to trust someone under this umbrella?

We need to spread technology companies. Everything but a bunch of things comes from this law.

And what starts in another country, magicaly gets bought or dismissed. Take Symbian as an example...

</comment><comment><USER46> 'Given the size and scope of WhatsApp's user base, we feel that their choice to display a non-blocking notification is appropriate. It provides transparent and cryptographically guaranteed confidence in the privacy of a user's communication, along with a simple user experience. The choice to make these notifications "blocking" would in some ways make things worse. That would leak information to the server about who has enabled safety number change notifications and who hasn't, effectively telling the server who it could MITM transparently and who it couldn't; something that WhatsApp considered very carefully.'

Why not have every client show up as having safety number change notifications on and just choose whether to display them client side depending on user settings? i.e. if you have them off, no message will display and the message will automatically be resent using the new key?

<comment><USER47> You quoted the answer to that already. If these change notices are "blocking", then the sending device won't re-send the message until the user has verified it. If the user hasn't enabled the notification, then the sending device will re-send immediately. This makes it trivial for the server to figure out who's actually enabled the notifications and who hasn't, which means the server can be confident about when it's actually safe to MITM.

<comment><USER46> You could send a dummy message for those with blocking turned on and screen it out at the receiving client.

</comment></comment></comment><comment><USER48> What is the user supposed to do when they get notified of a "safety number changed" message? How do they verify they've not just been MITM? Honest question... I don't use whatsapp or signal at all.

<comment><USER49> I would simply ask if they got a new phone or re-installed WhatsApp.

A few would inquisitively ask "Yes, how did you know?", then I would explain them to them the notification I got.

<comment><USER50> This can be triggered by the other side changing phones/devices. How do you explain this to the stupids?

</comment></comment></comment><comment><USER51> There seems to be a pretty clear war going on between engineers and journalists lately.

\- Chris Latter [1] vs Business Insider [2]

\- Elon Musk vs (Bunch of outlets)

\- Moxie vs The Guardian

I feel like journalists want to write a compelling story and engineers are on the other side like "No, those aren't facts!" I don't follow a lot of media outlets but it seems like journalists either lack the skills or don't care about doing any technical due diligence.

[1] - [https://twitter.com/clattner_llvm/status/819974025371787264](https://twitter.com/clattner_llvm/status/819974025371787264)

[2] - [http://www.businessinsider.com/how-apples-culture-of- secrecy...](http://www.businessinsider.com/how-apples-culture-of-secrecy- wears-down-its-top-developers-2017-1)

<comment><USER28> I don't know what happened here, but ...

Let's avoid our own bias of automatically believing the engineers are in the right; they are fallible people, no more or less honest or prone to error than journalists.

Every news story that breaks, involving any person or industry, gets the same response: It's false, they didn't ask us, etc. etc. Therefore, that response is not an indication that something is wrong (or right); the response tells us nothing in itself.

<comment><USER51> You're right. Everyone is fallible and I'm all for mistakes being made — We are all human. I also agree that the immediate snap response tells us nothing.

Based on the BI story, I know a few people that have actually already uninstalled WhatApp for fear of a backdoor. What I wish is that there was a better way for these two entities to communicate rather than finger pointing and name calling so that we as consumers of both media and technology can read a better more comprehensive narrative.

<comment><USER25> Name calling results in reassigning fear. People are afraid of the unknown and so try to box it up in something digestible they can fear less. We tend to blame others because it's easy and cheap to do so. If you are wrong, that means I'm right and so then I wasn't wrong about it and don't have to think about it anymore. And you are wrong, so why would I think about it again?

I think it's interesting the entities are not two, but many and one at the same time. Elon Musk is an individual and he is also part of the press process. My rationale is that the press includes everyone in the press, including the people writing the stories and the people _in_ the stories.

We know Musk. He doesn't know us.

<comment><USER28> > We know Musk

I know this isn't your point, but we don't know Musk; we know his (intentionally, carefully curated) public image

<comment><USER25> Yes, I agree. That part of him is his image in the public. It is both him and us at the same time, if you think about it from one perspective.

</comment></comment></comment></comment></comment></comment><comment><USER52> Oh give me a break

7.7 billion people in this planet are not part of ISIS.

Nice business model though.

Even if WhatsApp or Telegram or Signal are not compromised, you realky should assume the kernel or baseband are.

When I was a kid, I did an experiment cracking Apple] [ software.

Turns out forget the disk encryption, just hook up the NMI interrupt and you are golden... snapshot whenever you want.

Seriously, security is a joke. Nothing is safe. Get over it.

</comment><comment><USER53> Call me paranoid, but the thing which is strange to me is that Whisper talks about this defending Facebook/WhatsApp.

This makes me highly suspicion my usage of Signal :-(

<comment><USER40> Facebook's payments to use the Signal protocol pay the bills. Same reason why Moxie was fine with Google disabling E2E by default so they could use chat for ad targeting, after attacking other software for doing this, and with them tying enabling it to inconvenient behaviour like disabling the chat log that discourages all but the most paranoid from using it.

</comment></comment><comment><USER54> The real "Whatsapp Backdoor" is that, by default, the app stores a backup of all your messages on "teh cloud". On android, that's google.

So google can play "eve", and every run of the mill script kiddie that can get your google credentials may "restore" your messages. How convenient.

And that's the default settings. So, even if you turn it off, "mallory" can steal the credentials of your contact and snoop into your conversation that way.

</comment><comment><USER55> As with all end-to-end encryption it stops at the "end". It is this unencrypted state, in which humans consume data, that can't be defended by crypto.

Therefore the only way to be completely safe, is to make sure both you and your conversation partner don't decrypt their message until it's on an offline device only you have access to.

But end-to-end encryption where the interface (mobile app/phone) is controlled by the parties you want to protect your data from is not possible. WhatsApp could send freaking screenshots back of the unencrypted data if they wanted. For nearly all other threat models whatsApp's encryption is a wonderful add- on.

</comment><comment><USER56> It's remarkably hard to tell if a key has changed with a peer in signal. It gives you some small faded text between messages which is easily scrolled off by the other party making a lot of comments.

Once its off your screen, there is no way to tell that you've never authenticated the current key. No mark, not even burred in a menu.

So perhaps I should not surprised to see the authors of the worst public key management security that I've ever actually used defending even worse public key management security.

</comment><comment><USER57> I don't user whatsapp, but a general question to these that do:

Can the server change keys twice?

Change once to server keys, ask for the entire history retransmission.

Change again to revert to original receipient keys.

Will the receipient be prompted in that case?

<comment><USER58> "The WhatsApp clients have been carefully designed so that they will not re- encrypt messages that have already been delivered. Once the sending client displays a "double check mark," it can no longer be asked to re-send that message. This prevents anyone who compromises the server from being able to selectively target previously delivered messages for re-encryption."

<comment><USER57> Ah, thanks

</comment></comment></comment><comment><USER59> Maybe I don't get exactly what this means, but isn't it true that if see a message that someone's signature changed and the other person sees this also and we both choose to ignore this message the man in the middle can read all our new conversations?

Ofcourse if then one of us checks the signature later and sees it is not correct this would be very harmfull for whatsapp.

But this indeed doesn't sound like a backdoor. It's just the way it works. Which seems good enough.

</comment><comment><USER60> I don't get the complains here. Whatsapp is used by over a billion people and offers end2end encryption for them. A system that mainly targets people with little tech experience can never be kept 100% secure. If they make it harder to switch phones, people would stop using whatsapp.

The only vulnerability seems to be that they could prevent delivery messages. I'm sure that most people would notice if they suddenly son't see the 2 ticks, even if the other person answered. And if you want your conversation to be secret, that's a major red flag, now that this is known.

And if I get a phone change notification even though the other person didn't change their phones I'd also be confused at least. When I last changed my phone, a lot of people noticed because of the notification and asked me. And those were not tech savvy people, they were just wondering why I got a new phone.

Spying on conversations (especially by govt agencies) is only effective if the target doesn't know about it. It seems that Whatsapp has no way of enforcing that without the user noticing.

</comment><comment><USER61> Yawn. Next what, whatsapp is not going to use monetizing to advertise? Why don't we just all admit that all our data is being plundered by corporations to make money and just leave it at that? Seriously, nobody cares about their data being used by corporations for profit. Just be honest about it.. and you will see that people continue to use whatsapp or signal or whatever the current fad is.

</comment><comment><USER62> > The choice to make these notifications "blocking" would in some ways make > things worse. That would leak information to the server about who has > enabled safety number change notifications and who hasn't, effectively > telling the server who it could MITM transparently and who it couldn't; > something that WhatsApp considered very carefully.

could not this be saved only localy ?

<comment><USER63> If resending undelivered messages to new keys waited for confirmation of the new key when safety number change notifications are enabled, then users without those notifications enabled would continue to immediately resend undelivered messages to new keys while users with the notifications enabled would not resend until the user manually OKed the change. The WhatsApp servers know (or can know) whether users have outstanding undelivered messages and can observe whether users resend them immediately after a key change. As a result, if resends after key changes waited for user confirmation with security notifications enabled, whenever a user changed keys, WhatsApp would be able to tell whether any of their contacts who had undelivered messages to that user had the notifications enabled by observing whether those contacts immediately resent the messages or not.

<comment><USER62> thats then a timing attack, but the client could replace the mesaage with a placeholder and send that immidietly, and the real message after the user approves. this way server could not know.

<comment><USER63> I think that could mostly work. The placeholder message would have to be of identical length to the original and the resent message would have to use later sequence numbers/message ids (or whatever is used to identify individual messages) so the server couldn't tell that the placeholders were placeholders.

One issue is that it would mean that, in the case of an active attack where the server substituted a key they knew in place of a legitimate new key from the user, the server would be able to decrypt the possibly-placeholder resent message and determine whether the user had notifications on. If the user didn't, they'd know that they were safe to continue to attack the user (this attack is more risky than the passive one on the blocking resend without placeholder messages protocol, of course). So, this does improve the security of the protocol for users with security notifications enabled, at the cost of making users without those notifications less safe. I'm not sure how the tradeoff should be balanced here (just as I'm unsure if the UX tradeoff of having the option of not receiving security notifications is worth it...).

<comment><USER62> to find out if the user has notification on would be the same as doing the attack, and to find that for all users is the same as mitm all users.

im not sure how is the security of those who dont have notifications on worse in this case then what they have now.

if i want to i should be able to say if somebody changes the key i want to first verify the key before i send the message to that person.

lets say you organise a big protest vs some regime. i know who you are and i know that you comunicate with the number xyz. i redirect that number to my. in the meantime you send me a list of names that are in our group and adresses. i reconect with a xyz number and get the list and everything. even if youbget the notification its to late.

</comment></comment></comment></comment></comment><comment><USER64> We can learn one important thing here - it is not possible to trust closed source software. Enough said, next issue please.

<comment><USER27> It isn't possible, in most cases, to trust open source software either. Have you verified that the binaries on your phone were indeed built from the source you can read on github or wherever?

<comment><USER65> Which fully open-source phone platform do you have in mind? I'm not aware of any.

On desktop and servers, however, it certainly is possible (and not-too- impractical) to verify binary blobs against known PGP signatures. See Debian's reproducible builds, for instance.

</comment></comment></comment><comment><USER66> Why is moxie doing PR for WhatsApp?

<comment><USER31> >Even though we are the creators of the encryption protocol supposedly "backdoored" by WhatsApp, we were not asked for comment.

It's only a small step from criticism of WhatsApp crypto to criticism of Signal crypto. Why wouldn't moxie be interested?

<comment><USER67> because here it clearly says that signal had dealt with this problem [https://tobi.rocks/2016/04/whats-app-retransmission- vulnerab...](https://tobi.rocks/2016/04/whats-app-retransmission- vulnerability/) So it is solely whatsapp's fault

</comment></comment></comment><comment><USER68> Wouldn't a better defense be to not re-transmit messages encrypted with the new key unless the originating user clicks a button authorizing it AFTER they have been informed that the receiving user has a new key??

</comment><comment><USER69> Response by the finder of the vulnerability:

As Eike Kühl pretty well describes, this functionality only increases usability in a rare corner case: When you dump your phone in the ocean and you need a month to get a new one. Then everyone who has sent you a message during this period will not need to press an additional "OK" button.

[https://tobi.rocks/2017/01/what-is-facebook-going-to-do-a- su...](https://tobi.rocks/2017/01/what-is-facebook-going-to-do-a-suggestion/)

</comment><comment><USER70> Telegram made different choice. Secret chats do get broken, if ephemeral key renewal fails. Queued messages won't get encrypted with new key automatically. Of course at times this is annoying.

</comment><comment><USER71> I have been contemplating deleting my facebook for 6 months. I finally pulled the trigger just now. I don't trust the company at all. Too many smokes and mirrors in what they do.

</comment><comment><USER72> So full-on paranoia mode on: What would you do if you wanted to compare safety numbers? I'm guessing most people would call and read out the code.

How far are we from targeted interception of calls, with replacement of key phrases? Voice synthesis seems to be there more or less, if I understood Adobe's recent demo correctly, but real-time parsing of conversations to determine where to intervene is probably not close yet.

<comment><USER40> This kind of phrase replacement in calls was on the NSA's priority list years ago, according to the Snowden leaks.

</comment></comment><comment><USER73> So if the security of Whatsapp's keys hinges so much on the key change notifications, why turn them off by default? Why allow them to be turned off at all?

No one (today) would get the idea to make https warnings optional even though that audience is even broader than Whatsapp's. (Possibly even _because_ that audience is so broad)

</comment><comment><USER74> > We believe that WhatsApp remains a great choice for users concerned with the > privacy of their message _content_.

What about meta-data? Even Signal uses Google's push service to send your messages, and WhatsApp is even known to collect meta-data. (IIRC they changed their EULA recently)

</comment><comment><USER75> response: [https://tobi.rocks/2017/01/there-is-a-whatsapp- backdoor/](https://tobi.rocks/2017/01/there-is-a-whatsapp-backdoor/)

</comment><comment><USER76> If I worked for WhatsApp (Or conversely, if WhatsApp used an implementation of something I've made, thus making it hugely popular in the process) I'd certainly say there's no backdoor indeed.

Conflicts of interest.

</comment><comment><USER23> seems like the original thread has fallen off the front page [https://news.ycombinator.com/item?id=13389935](https://news.ycombinator.com/item?id=13389935)

</comment><comment><USER77> Probably it is not a backdoor but still insecure. End to end encryption is not what they offer but they make you think you are safe. They should clearly state that in a big splash message.

</comment><comment><USER78> Did Hacker News delete the original Guardian WhatsApp article post?

</comment><comment><USER79> What about [https://web.whatsapp.com](https://web.whatsapp.com)? It grants full access to the entire message archive on your phone

<comment><USER80> Only once you scan the barcode, which contains an encryption key to use for your phone to securely ship /its/ keys to the browser. Only encrypted messages are transmitted between phone and browser

</comment></comment><comment><USER81> Terrible UX combined with unsane default, at best...

</comment><comment><USER82> A vulnerability you know of and choose to ignore IS a backdoor. All the rest is fancy talk.

</comment><comment><USER83> They are trying to say that an intentionally placed backdoor is not a backdoor? ha ha

</comment><comment><USER84> thanks

</comment><comment><USER85> The Guardian slipped up again, expect more BS from their incompetent journalists.</comment>