Deprecating Non-Secure HTTP - <AUTHOR> https://blog.mozilla.org/security/2015/04/30/deprecating-non-secure-http/ <comment><USER3> I should be happy about this -- who _wouldn 't_ want the entire web to be encrypted -- but SSL is so broken for normal people. SSL is expensive (wildcard certificates run $70 a year and up), confusing (how does one pick between the 200 different companies selling certificates?), and incredibly difficult to set up (what order should I cat the certificate pieces in again?).

If SSL doesn't change, this move will cut the little folks out of the internet. What are Mozilla's values?

<comment><USER4> Why this project: [https://letsencrypt.org/](https://letsencrypt.org/) is so important.

From the site: Let's Encrypt is a new Certificate Authority: It's free, automated, and open. Arriving Mid-2015

<comment><USER5> That's just _one_ project, and it doesn't even exist yet.

The web is moving faster every day, apparently. I sure do hope that project will be all it's chalked up to be.

For example, I need IP-only certs for a new project I'm working on (waiting for DNS to propagate to all clients is too unreliable and slow). If letsencrypt doesn't do that... well then I'd have to hope real hard for a competent CA out there who has an automated process available that allows IP- only certs. And whatever their price, if companies start following Mozilla's lead too soon, I'll have to pay up.

The wording in the article is perhaps not so damning yet, but it's still making me uneasy that they put out this press release while there are currently ZERO viable solutions for this.

<comment><USER6> _For example, I need IP-only certs for a new project I 'm working on (waiting for DNS to propagate to all clients is too unreliable and slow)._

This doesn't make any sense. You're not waiting for DNS to propagate to clients; if anything you're waiting for recursive DNS servers at shitty ISPs to time out their caches when they are configured to not honor the RR's TTL sent by the authoritative server in a misguided attempt to make the internet "faster".

But this is completely avoidable without having to use IPs or certificates with CN/SAN that are IPs: get a wildcard cert and rotate the subdomain name. It's a new hostname, so it busts intermediate DNS caches by being new queries; since it's a new query, there's no "propagation to clients" to wait for when you change IPs, all queries for the new name hit authoritative servers. Additionally, it looks infinitely more legit than a website that is accessible only via IP address. And doubly additionally, if you're going through so many IPs, presumably you'll be rotating some out and those may be assigned to other people who can then get their own cert for that IP and impersonate you.

<comment><USER7> How often are DNS caches configured to ignore TTLs? That sounds awful.

I assumed the grandparent simply didn't understand the need to lower his TTLs.

<comment><USER8> Google DNS seems to ignore TTL but it does the opposite of what the GP is saying; gDNS drops it cache before the TTL is expired.

<comment><USER6> Unless you have a reference for Google saying they purposely do this, it is more likely that the cache is dropping LRU entries as it fills up. Also, I doubt there is a trivial number of actual resolvers behind the google public DNS endpoints, so you may be seeing the result of multiple individual servers without shared cache initially populating their caches.

Some quick tests with dig seem to indicate that, at least for the region I'm in, my queries to google's public DNS is rotating between 4 or 5 servers, as evidenced by the TTLs being returned.

</comment></comment></comment></comment></comment></comment></comment><comment><USER9> I agree with trying to phase out HTTP, but I think their method is "annoying." What do features have to do with HTTP Vs. HTTPS? It just seems like an arbitrary punishment.

Wouldn't it just be significantly easier to simply change the URL art style to make clear that HTTP is "insecure." Like a red broken padlock on every HTTP page?

That has the following advantages:

\- HTTP remains fully working for internal/development/localhost/appliance usage (no broken features).

\- Users are reminded that HTTP is not secure.

\- Webmasters are "embarrassed" into upgrading to HTTPS.

\- Fully backwards compatible.

Seems like a perfect solution where everyone wins.

<comment><USER10> I can imagine a lot of personal sites will suffer from this. With most, they're sitting on something like Eleven2 or Dreamhost, who requires a dedicated IP for an SSL certificate, which the user then has to buy and figure out for himself (it's not trivial for the average "webmaster"), or buy the certificate from their host which is marked-up plenty.

Yes, the hosts could wildcard. Yes, there are other solutions out there. But for the average Joe who is blogging about his vacations and family? They're going to be completely lost.

Why don't shared hosts just wildcard? Shared certificate? Well, let's think about it... Charging ~$5/month/dedicated IP is a nice upsell, and getting $70 for an installed SSL cert that costs them $10 from their SSL cert reseller, that takes them 2 minutes to configure... That's a nice slice of pie. I'd take that bet any day.

<comment><USER11> I think you're overstating how bad things are. Dreamhost, for example, no longer requires a dedicated IP for SSL, though they do still recommend it for e-commerce. They are charging $15/year for a CA-signed certificate. Granted, that's for a single-site cert and they don't support wildcards under this scenario, but the vacation blogger isn't likely to need that anyway.

</comment></comment></comment><comment><USER12> This is stupid. There are all kinds of use cases where you don't care who knows what you're looking at, or whether it is authentic.

Say I navigate to some restaurant's web page using HTTP. Even if I used HTTPS, someone spying on my traffic would know what I'm reading, if the IP address is a dedicated server for that web site only. Whether I use HTTP or HTTPS, they could infer that I'm interested in visiting the restaurant.

Secondly, I'm only interested in the opening hours. That is not classified information.

I suppose that a MITM attack could be perpetrated whereby the attackers rewrite the opening hours. I end up going to the place while it is in fact closed (and the area happens to be deserted), making me an easy target for the attackers to rob me.

Okay, okay, please deprecate HTTP; what was I _thinking_!

And that restaurant better get a properly signed certificate; no "self signed" junk! Moreover, I'm not going to accept it over the air the first time I visit, no siree. DNS could be redirecting me to a fake page which also has a signed certificate. I'm going to physically go the restaurant one time first, and obtain their certificate from them in person, on a flash drive, then install it in my devices. Then I'm going to pretend I was never there and don't know their opening hours, and obtain that info again using a nearly perfectly secured connection!

<comment><USER13>
        > Even if I used HTTPS, someone spying on my traffic would
        > know what I'm reading, if the IP address is a dedicated
        > server for that web site only

How would they know the IP is a dedicated server for that website only, rather than simply a default?

<comment><USER14> Since the SSL negotiation happens before the HTTP request, either there's only one certificate for that IP or you need to use SNI, which reveals the domain you're requesting.

You could have multiple domains in the certificate to avoid identification, but that has its own problems.

</comment></comment></comment><comment><USER15> I have to say, I actually disagree with this move. While I think the intentions sound noble, and I'm all for a more secure web, I also believe that a web browser has no business dictating that the entire web should be forced in HTTPs.

I don't see any benefit in this type of blanket, all or nothing, type of approach. In fact, I see it doing more damage than good. Encrypting blogs, news websites, etc still makes no sense to me. I'm actually disappointed in Mozilla for looking at doing this. As a developer I respect many of their products and see them as champions of the web in a lot of ways.

HTTPs does not:

\- protect a user from malware on their own system with keylogging taking place

\- increase security in outdated and insecure websites (eg: old known exploitable code)

\- prevent any browser drive-by downloaders or exploits

\- increase the security of the web server itself (web stack thats serving requests) - yeah that's you using a private VPS without doing Kernel updates.

These are likely the major factors of why people have security issues. What is forcing HTTPS on the entire web actually doing? Who is it benefiting? The government can still snoop your data in-flight. If someone is connected to a fake wifi endpoint there is on the fly SSL decryption out there.....

Do we still need TLS for actual secure transactions that deal with personal data? Yes, of course. That's what it is intended for.

Do we need TLS to read the latest TMZ post about Miley Cyrus? You decide... (oh and it's http if you were wondering)

<comment><USER16> HTTPS provides authentication, not just confidentiality.

When you visit "blogs, news websites, etc" do you think there's no value in being able to know for sure that the content is exactly what the owner of the site intended? Even though ISPs have proven themselves willing to intercept and modify that content in transit?

[http://arstechnica.com/tech-policy/2013/04/07/how-a- banner-a...](http://arstechnica.com/tech-policy/2013/04/07/how-a-banner-ad- for-hs-ok/)

[http://arstechnica.com/tech-policy/2014/09/08/why- comcasts-j...](http://arstechnica.com/tech-policy/2014/09/08/why-comcasts- javascript-ad-injections-threaten-security-net-neutrality/)

<comment><USER17> But https doesn't 'let you know for sure that the content is exactly what the owner of the site intended' as it doesn't protect you from xss

<comment><USER18> Than you fix the XSS vulnerabilities and implement CSP. Shitty security practices is not an excuse for more shitty security practices. [https://developer.mozilla.org/en- US/docs/Web/Security/CSP](https://developer.mozilla.org/en- US/docs/Web/Security/CSP)

</comment></comment></comment></comment><comment><USER19> Meanwhile, OpenBSD 5.7 came out today, with the following security fixes in LibreSSL (arguably the most secure SSL library so far):

"Multiple CVEs fixed including CVE-2014-3506, CVE-2014-3507, CVE-2014-3508, CVE-2014-3509, CVE-2014-3510, CVE-2014-3511, CVE-2014-3570, CVE-2014-3572, CVE-2014-8275, CVE-2015-0205 and CVE-2015-0206."

So if I were running a TLS-enabled site using LibreSSL from OpenBSD 5.6, I'd have been exposed to potentially 11+ CVEs. A little sooner with OpenSSL, and I would have been exposed to Heartbleed. And who knows how many CVEs will arise before 5.8 is released?

Why is it so impossible to write a secure TLS library? Why should I put my entire server at risk to appease the attempts of Mozilla and Google to prop up the CA business? Sorry, but I'll stick to parsing lines of text.

Let 'em remove HTTP completely. Hopefully after they break 90% of the web, we'll get some real user revolt, and some real competitors in the web browser space might emerge. Maybe from some people who actually listen to what their users are asking for.

I guess now we know what that "signed extensions only" change was for: what do you think they're going to do when someone submits a "Restore HTTP Functionality" add-on in the future?

<comment><USER20> Well, frequently the vulnerability of those CVEs is breaking or downgrading the crypto... or in other words: if exploited, the connection could become as insecure as HTTP.

So your argument is that since locks can occasionally be picked, doors shouldn't have locks? What exactly is the massive burden with HTTPS? The computational cost is tiny and will continue to become tinier, there are free cert providers like StartSSL and more coming soon, and the implementation is simple enough that anyone managing a server should be able to handle it easily.

The number of websites where I wouldn't prefer encryption and identity authentication is around zero, and the number of websites where I'm okay with someone injecting arbitrary JavaScript is exactly zero. The time people spend making flawed "if you have nothing to hide, you have nothing to fear" or "crypto libraries/CAs are bad, scary, and hard to use" arguments would be much better spent actually trying to improve those circumstances for the inevitable and necessary shift to HTTPS everywhere.

<comment><USER19> > So your argument is that since locks can occasionally be picked, doors > shouldn't have locks?

A faulty lock on my house doesn't turn into Heartbleed.

The thing is, _I_ don't need a lock on my server that serves up static, legal content. You might think it's a problem, that the NSA is going to spy on you, or China is going to inject attacks into your requests to my server, but that's your problem.

I'm not going to run a massively buggy TLS library with an API guide that would take a whole team of engineers _weeks_ to decipher, just because you're intensely paranoid about accessing game-related data over HTTP.

Seriously, look at the GnuTLS documentation sometime. It's psychotic. As is MatrixSSL, PolarSSL, OpenSSL, and NSS. The closest to sanity I've ever seen was libtls, which is only on OpenBSD, still has lots of CVEs popping up, and can't do non-blocking mode.

> What exactly is the massive burden with HTTPS?

1\. write your own HTTPS server. I'll wait a few months, or

2\. find a library that's easy to use and won't expose my server to Heartbleed-like attacks, and

3\. pay me $70/yr for the wildcard cert I would need.

I'll cover the extra CPU costs, since you say they're so small. (even though when people say "small", they're counting overhead as a percentage against a site running a bloated beast like Wordpress in PHP + MySQL.)

> there are free cert providers like StartSSL and more coming soon

That don't provide wildcart certs (and I have a wildcard CNAME entry; and I make use of that.)

> The number of websites where I wouldn't prefer encryption and identity > authentication is around zero

And you're free to not visit my site, just like I wouldn't ever patronize a webstore that wasn't HTTPS. That's how markets are supposed to work. I don't see why your browser has to make the decision for the both of us.

> and the number of websites where I'm okay with someone injecting arbitrary > JavaScript is exactly zero

Honestly ... I would be okay with blocking Javascript over HTTP. But I think that's more because I just hate Javascript :P

> would be much better spent actually trying to improve those circumstances

You seriously want me to write a TLS library?

My dream goal would actually be to have it built-into the sockets layer. If it could be enabled as easily as a setsockopt(SO_TLS_CERTIFICATE, (void*)certificatedata, ...); and OS updates could fix the security, I'd be a lot more inclined to get on board with the programming side.

I don't have a solution to the wildcard cert issue. I can't well start up my own CA to give them out for free. I guess it would at least be nice to see if they ever tone down self-signed certs from "WORSE THAN HITLER" to "at least equal to HTTP" in terms of warning messages. People keep talking about it, but it's been what? Over a decade now? I'll believe it when I see it.

</comment></comment></comment><comment><USER21> Can someone explain why HTTPS is necessary for a webpage where I don't log in or submit any information?

For example, take the xkcd homepage. Not only do I not log into it, there's nowhere I _could_ log in. The only input is a search box (which seems to be disabled at the moment anyway). Is it really a security risk if my communication with xkcd's servers is unencrypted? (Yes, xkcd has a store and a forum, and I understand why you'd need HTTPS on those subdomains - but I don't see why the main domain needs it.)

I agree with the parts of their plan to disable browser features that could be a security risk to non-HTTPS pages - that makes total sense. But it seems absurd to prevent static pages from using future CSS layout features just because they're not using HTTPS.

<comment><USER22> Intermediaries can (and already do) silently cause the content to be tracked, altered or otherwise modified against both your and the site owner's interests.

How would you feel if they inserted javascript to mine bitcoins?

<comment><USER13>
        > How would you feel if they inserted javascript to mine bitcoins?

I couldn't care less. JavaScript to DDoS GitHub, on the other hand...

</comment></comment></comment><comment><USER23> If things like "python -m SimpleHttpServer" don't work then developers will switch browsers. I don't think anyone is seriously considering what it will take to migrate the long tail of development tools that use HTTP on localhost.

<comment><USER24> And what about testing small applications on remote servers like "dev.my- personal-site.com"? I don't want to pay $15 for an SSL certificate and 15 minutes of my time just so I can get my dumb lunch break tetris HTML app running on the machine I SSH into from my tablet.

<comment><USER25> I am long past confused and heading toward awed, at this point, that it's not a common-sense practice for every web developer to generate a personal self- signed root-CA cert, and install it on all of their machines. It's as basic as having an SSH or PGP key.

Setting up a new box? Put your CA-cert in its trust roots. Then use your CA to generate a server cert for it; plop that in /etc/nginx and wherever else. Now it's secure!

This is exactly the original use-case for X.509 certificate authorities: pairing devices on a _private network_ without having to give each of them a set of of their peers' keys in advance. You have a private network that you run services on? You're a CA.

And really, in the dev-environment case, you actually want client-auth, too, because then you get "clients who don't have a CA-issued client cert can't connect" for free.

In proper X.509, the server auths the client just like the client auths the server—it's really more of an equal-peers "we're both trusted by the CA—the network owner—so we should both trust each-other" kind of thing. The public Internet centralized X.509 model—where the client has a huge list of CAs that the user doesn't even know the contents of, and the server doesn't check _anything_ —is a very strange and non-idiomatic implementation of the premise.

<comment><USER26> > It's as basic as having an SSH or PGP key.

And you're surprised that not every developer has done this? A minority of the developers I've ever worked with have ever done any of these things.

<comment><USER25> I'm really talking about the kind of developers that hang out here—people who regularly set up their own staging environments, use those "tunnel into my dev box" services, etc. Most of us here certainly know SSH, and probably have used GnuPG at least once. But it's still relatively unlikely, statistically, that you or I have ever touched the openssl(1) command.

<comment><USER27> Well, when we are talking about a change in Firefox, we are talking about every developer, not just the ones who hang out on HN.

</comment></comment></comment></comment></comment></comment><comment><USER28> Here's two relevant Bugzilla bugs:

Self-signed certificates are treated as errors: [https://bugzilla.mozilla.org/show_bug.cgi?id=431386](https://bugzilla.mozilla.org/show_bug.cgi?id=431386)

Switch generic icon to negative feedback for non-https sites: [https://bugzilla.mozilla.org/show_bug.cgi?id=1041087](https://bugzilla.mozilla.org/show_bug.cgi?id=1041087)

Here's a proposed way of phasing this plan in over time:

1\. Mid-2015: Start treating self signed certificates as unencrypted connections (i.e. stop showing a warning, but the UI would just show the globe icon, not the lock icon). This would allow website owners to choose to block passive surveillance without causing any cost to them or any problems for their users.

2\. Late-2015: Switch the globe icon for http sites to a gray unlocked lock. The self signed certs would still be the globe icon. The would incentivize website owners to at least start blocking passive surveillance if they want to keep the same user experience as previous. Also, this new icon wouldn't be loud or intrusive to the user.

3\. Late-2016: Change the unlocked icon for http sites to a yellow icon. Hopefully, by the end of 2016, Let's Encrypt has taken off and has a lot of frameworks like wordpress including tutorials on how to use it. This increased uptake of free authenticated https, plus the ability to still use self-signed certs for unauthenticated https (remember, this still blocks passive adversaries), would allow website owners enough alternative options to start switching to https. The yellow icon would push most over the edge.

4\. Late-2017: Switch the unlocked icon for http to red. After a year of yellow, most websites should already have switched to https (authenticated or self-signed), so now it's time to drive the nail in the coffin and kill http on any production site with a red icon.

5\. Late-2018: Show a warning for http sites. This experience would be similar to the self-signed cert experience now, where users have to manually choose to continue. Developers building websites would still be able to choose to continue to load their dev sites, but no production website would in their right mind choose to use http only.

<comment><USER29> Why the hate for self-signed certificates?

I would personally rather see those promoted and methods developed to securely bootstrap them than make us all reliant on centralised CA infrastructure. The centralised CAs are all at the mercy of their governments and hence, in my opinion, ought to be considered almost as insecure as self-signed certs.

EDIT: I think I misunderstood your comment - reading again it sounds like you are also in favour of self-signed (hopefully so).

<comment><AUTHOR> Until supports for DANE and DNSSEC becomes widespread, unless it's a site for personal use, self-signed certs can't really be trusted by third parties.

(BTW, if you're not using a conventional CA, you'd best off being your own CA, and signing your certs with a CA certificate you've generated rather than simply self-signing the cert. It's a little more trouble in the short term, but it means that each time you subsequently need to generate a new cert, you don't need to put up with warnings everywhere because it'll be validated by your own CA cert. The downside of this is having to install the CA cert everywhere. That's what I do for my private stuff. There are tonnes of tutorials online on how to do it.)

</comment></comment></comment><comment><USER30> I envy you, citizens of the free world :) You (mostly) can use HTTPS, avoid government surveillance, and use new shiny Mozilla features (for whatever they are going to be).

It's not the same in e.g. Russia (and I'm sure it's not just Russia). In Russia, the Web is now officially being censored by the state. They have a national register of prohibited resources -- basically, a huge list of URLs. Every ISP must block all access to those URLs, or else.

So if a page (perhaps, a comment page?) on your site enters the register, and it is served over unencrypted HTTP, ISPs can use DPI to block the access to just that specific page -- which sucks, but at least your site is still accessible. If, however, you use HTTPS -- then ISPs have no other choice but to block all traffic to your site entirely. Given that choice, many webmasters (myself included) will have to choose plain HTTP.

<comment><USER13>
        > then ISPs have no other choice but to block all traffic
        > to your site entirely. Given that choice, many
        > webmasters (myself included) will have to choose plain
        > HTTP

At some point, blocking CDNs at IP level becomes too much of an economic burden on a country to be feasible. We've seen an unwillingness by the Chinese to block access to GitHub; presumably this means Fastly (their CDN provider) is safe for a while.

<comment><USER30> Did you know that Russians had github blocked for several days? Anyway, you're talking about counter-censorship warfare. Yes, some of those measures will be somewhat effective sometimes, but the costs (not necessarily even monetary) are actually quite substantial, and it's definitely not for everyone.

</comment></comment></comment><comment><USER31> This potentially removes the relative anonymity that the entire non-commercial web offers (and in fact was largely built on, post-DARPA). Free DV certificates _may_ help minimize that negative effect, but this entire scheme _still_ further increases reliance on a badly broken CA system.

This seems like a somewhat rushed idea with good intentions but without sufficient community discussion.. rather than put all our eggs in one basket with LetsEncrypt et al, which are noble efforts to fix a broken system, are there things we can do right now in terms of favoring self- _authentication_ of self-signed certs? This whole thing feels a bit like a witchhunt to punish non-HTTP sites.

<comment><USER16> > are there things we can do right now in terms of favoring self- > authentication of self-signed certs?

That's a good question, but I've yet to see any justification for thinking the answer is "yes".

If an attacker controls your network connection and/or DNS, what possible information could you obtain to prove the authenticity of a website, without reference to an external source of authority?

<comment><USER31> Agreed. That's why it was a question. :) I'm trying to get people to start thinking in that direction, rather than in a central source of authority (which also means DNSSEC or DNS TXT's are out)

</comment></comment></comment><comment><USER32> I'm very glad to see this. It's embarrassing to think that, just a few years ago, many major websites used HTTP for all but their login pages, and it took Firesheep to get them into gear.

> For the first of these steps, the community will need to agree on a date, > and a definition for what features are considered "new". For example, one > definition of "new" could be "features that cannot be polyfilled".

I hope that includes WebRTC, since WebRTC can be used to figure out your local IP address, which (when combined with your public IP address) is essentially a unique identifier[0]. WebRTC is a technology that enables some great things (like Firefox Hello!), but it's a MASSIVE privacy hole[1], and one that I can't imagine justifying for non-secure endpoints.

 _EDIT_ : Added link to proof-of-concept attack

[0] [https://www.browserleaks.com/webrtc](https://www.browserleaks.com/webrtc)

[1] [https://github.com/diafygi/webrtc- ips/blob/master/index.html](https://github.com/diafygi/webrtc- ips/blob/master/index.html)

<comment><USER33> It's worth bearing in mind that in the beginning, https was a significant CPU overhead... Since 2004 or so, much less of one. And since around 2010 CPU is rarely the bottleneck for web applications.

I do find it interesting that someone starting out as a significant effort after 2010 would bother having a partially https site, with back and forth jumps for login. It seems to me like it's actually _more_ work than just having it all https and flat.

<comment><USER34> Amazon does this today, browsing is http.

</comment></comment></comment><comment><USER35> I view this as an attempt by various power brokers to subvert the power of the World Wide Web by attacking it's decentralized nature. In the beginning (like now) it'll be relatively simple for everyone to get their hands on the SSL cert they need, but the risk is that in the future, after support for HTTP has been reduced it could become more difficult to acquire the certificates required to deliver the user experience that you wish to deliver (not just in terms of price, but in terms of censorship).

In addition to making the web more centralized, forcing everyone into HTTPS actually makes it much easier to effect broad scale traffic analysis. On top of that many info-sec experts suspect that the actual cipher in play here may eventually be proven to have significant weaknesses at some future date. AND HTTPS is more expensive to support in terms of bandwidth, CPU, and increased latency. It could result it more coal being burned each year to push all of those extra bytes around.

<comment><USER36> In such a scenario, wouldn't an alternative/forked browser emerge with support for an HTTP/anonymous web?

There is also censorship risk in named-data and content-centric networking, which offer multicast and caching benefits, but rely on uniquely identified content.

<comment><USER35> certainly there will always be alternative browsers, but since they would be used by a small minority the censors would effectively have the ability to determine which publishers are "cleared" to reach out to the most broad demographics. That alone would be enough if your censorship goal was to be able to sway public sentiment.

</comment></comment></comment><comment><USER37> Hopefully they will also introduce a standard and free way to get SSL certificates. I do not like the idea of having to buy new certificates every year (and all the hassle that comes with installing the certificates) just to maintain a very basic website.

<comment><USER38> Nope. The goal is to make running a server only available to corporate entities. It reduce competition from folks like yourself.

<comment><USER39> If the cost of an SSL certificate is a barrier for you to compete, you should probably do something else.

<comment><USER40> It just takes a tiny cost to turn off bright 10 year olds from experimenting.

<comment><USER41> Cloudflare's free plan has SSL now, which a 10 year could utilize. While that opens up a potential MITM attack, I don't believe it's worse than having no SSL at all (others argue it is, on the premise that it creates a false sense of security).

<comment><USER42> Amateur web development shouldn't depend on having an account with a 3rd party service which can arbitrarily decide whether or not to sign your cert.

<comment><USER43> Well you still depend on 3rd parties to register a domain. And one to provide a connection, if not a server.

<comment><USER44> /etc/hosts

when I was experimenting with computers I had a WAMP executable on my LAN.

less parties involved the better.

<comment><USER45> Localhost will not be restricted. If you're making people edit their hosts file you can make them bypass any security warnings.

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER46> This is a pretty bold move, but I like the intent behind it. Hopefully Mozilla can pull it off without causing any problems for normal users.

Presumably it will all be synced with their plans to launch a free CA[1] in the near future.

[1] [https://letsencrypt.org/](https://letsencrypt.org/)

<comment><USER47> One thing I've never been able to figure out from Let's Encrypt's website - will you be able to get a certificate, _without_ hosting your own instance? Or will it be limited to servers you can actually install their program on? Also, I assume they'll get the root CA included by all major vendors/browsers?

<comment><USER48> You don't have to run the Let's Encrypt client, but you do have to be able to do things to prove that you control the domain. Currently the Let's Encrypt client assumes that it's being run on the same machine on which domain control will be proved (though not necessarily the same machine where the cert will eventually be deployed). Someone could write another client application which gives instructions to complete the challenges manually, which is a feature that's occasionally requested.

The CA will be cross-signed by IdenTrust, which is accepted by mainstream browsers, so those browsers will also accept the certs we issue.

<comment><USER49> So you don't have to run the Let's Encrypt client? I was under the impression you did because without running the client there was no way to communicate with the Let's Encrypt service?

Or do you mean, you can have multiple servers and only need to run the client on one of them?

<comment><USER48> I mean that you need to run some client software, but it doesn't have to be the client software we're writing. Other people can implement ACME, for example in hosting provider infrastructure or in server software or other configurations. There could be an ACME client where the verification steps indicated to the user are performed manually rather than automatically. You could probably even speak ACME with curl, although quickly generating valid JSON objects that contain valid cryptographic signatures might be a bit challenging. :-)

It's also right that you can have multiple servers and only run the client on one of them, if you're willing to copy key material from one server to another.

<comment><USER49> Ah gotcha! Thanks for clarifying.

</comment></comment></comment></comment></comment></comment><comment><USER50> My question whenever this comes up is how will the web respond to the millions of caching devices out there that will now provide no bandwidth savings?

ISPs and companies all over the world cache static HTTP content (i.e. HTTP resources with proper caching headers). Doesn't endpoint-to-endpoint encryption basically kill that?

What I'd love is to have HTTPS for encrypted traffic, and signed HTTP for traffic that doesn't need encryption. So you would use the certificate to authenticate the payload, but a cache would still be able to deliver the content (because a replay would be valid).

</comment><comment><USER51> From the comments section:

> Not all data needs to be secure. Not all websites need to be secure. > Requiring HTTPS means additional compute and additional servers securing > something may not need to be secured and provides no benefit – only cost. > Free and open information should be (optionally) free of encryption as well.

Indeed, there still a portion of the internet that could benefit from being SSL free.

</comment><comment><USER52> I have a small blog on a home server. Basic HTML and static content and I don't care who views it. I can't get a static IP address.

Some things about this decisions doesn't seem thought out. -who regulates the companies selling certificates? ($5 for a cert seems shady), are cert companies fronts for others entities? -does this really prevent malware? -will self signed certificates get a bit more respect? -how does this stop Lenovo from adding preinstalled malware that circumvents security certificates?

</comment><comment><USER53> This is so wrong. Partially because HTTP is used as a vehicle to deliver applications. This blurring of responsibilities results in the messy state the Web is going to be in. I see parallels with systemd and Linux here: poor design decisions, the chase to accommodate an ever-widening audience of Internet users, one-button devices. Just recently I saw a post from a guy somewhere on a dial-up link in Nepal that it is impossible to write e-mails anymore. You have to write them in Notepad and then copy-paste it into your web-based e-mail client, otherwise the "client" is too slow. And no, adding fancy animations to my GUI is not progress.

</comment><comment><USER54>
        "It should be noted that this plan still allows for usage of the "http" URI scheme in legacy content."

This is an important qualifier to the headline, and means that Firefox will remain workable with things that won't implement https for a decade.

<comment><AUTHOR> Hence 'deprecating': they're not getting rid of HTTP, it's just that HTTPS will be preferred, with HTTP sticking around for legacy purposes.

</comment></comment><comment><USER55> For Tor and I2P hidden services, HTTPS is redundant so I don't really see the point in punishing people for things like this. Loopback sites are an obvious exception to the "HTTPS is better" rule as well.

<comment><USER56> I'm pretty sure you want to avoid HTTP websites while on TOR. HTTPS encrypts your connection, while TOR anonymizes it.

<comment><USER57> This makes sense for clearnet stuff. Hidden services are encrypted before transit.

</comment></comment></comment><comment><USER58> Please, can we stop calling it SSL?

SSL means something very specific; something that people should no longer be deploying. The article notably uses the term 'Non-secure HTTP' which at this point in time means HTTPS leveraging TLS (probably at least 1.2) but leaves some room for future interpretation as newer versions or entirely different standards arise.

No one is advocating for 'SSL' here, and continuing to use the term 'SSL' or 'SSL/TLS' when we really mean 'TLS' further confuses the situation.

<comment><USER59> It's not that specific. You could even negotiate a downgrade with a TLS server to use SSL. The first 3 versions of the protocol were named SSL and the later ones were named TLS but they're not really different.

<comment><USER58> The differences are significant when it comes to the security of the underlying protocol, and the downgrade is why it's important you refuse to support SSL entirely. SSL of any version (v2 or v3.. the v1 you refer to was never publicly in use) comes with security problems that are resolved in TLS.

I won't bore you with the details, they're well explained at [http://disablessl3.com/](http://disablessl3.com/) among other places. All major browsers have ended support for SSL, and more secure alternatives have been available for years.

It's not a high risk; attacks require scenarios that may not be common, but it remains true that there's no reason to deploy SSL today.

<comment><USER59> TLS 1.0 was also vulnerable to BEAST. I'm assuming that pointing to TLS 1.0 as the "minimum" is temporary. Over time, we will decide that the cutoff should be TLS 1.1 and we'll deprecate TLS 1.0. At that point, everything you're saying about SSL will be true of TLS 1.0. It's really just a difference in version number.

<comment><USER58> Yes, it likely will. That's probably why the article mentions a deprecation of "Non-Secure HTTP" rather than prescribing a specific TLS version. It's the sort of language that will stand the test of time as newer protocols become deprecated. The comments here, however, largely encourage "SSL" which is poor advice.

BEAST can be mitigated through ciphersuite selections and other measures. This makes it somewhat different than POODLE which is a protocol design flaw for which no reliable mitigation exists.

Suggesting folks not deploy SSLv3 is hardly a controversial statement. It's not just a difference in version number, it's a difference in protocol specification and name. When we say 'Use SSL' a well intentioned reader may follow that guidance and implement SSLv3, or worse disable support for TLS. Words mean things.

</comment></comment></comment></comment></comment><comment><USER60> Oh cool, so with increasingly stringent SSL requirements, we're basically entirely phasing out the ability to run a website without a certificate authority's involvement.

So instead of all this bullshit from Chrome, Firefox, et al., can I please just send some huge check to GoDaddy or Verisign or whomever and continue to use the internet as an open platform and not some managed service where we try to hold everyone's hand because we've conditioned them to spew their personal information all over the web all day?

</comment><comment><USER61> Mentioned this last time, but since I didn't see it elsewhere in the thread, will mention it again... what about LAN resources served over HTTP like NAS, Printer, AP, etc.? These devices don't have DNS, forget about about SSL.

Is the entire local subnet going to be a secure origin like localhost? Because that sounds problematic... What I want is a way to single-click pin a self- signed certificate to "turn it green".

<comment><USER62> _These devices don 't have DNS_

They should, via mDNS AKA Zeroconf AKA Bonjour AKA Avahi. Often, _printer- name.local_ port 80 or port 631 will lead to the printer's status page.

<comment><USER61> So vendors are supposed to pre-install a certificate based on that? What happens when you rename it? What happens if you have two of the same AP in the house?

</comment></comment></comment><comment><USER63> At first, I was apprehensive. As a newer web developer I have never had a secure site. I have a small portfolio and a few tiny side projects I work on, nothing with >10 users. I will have to learn more, do more, and pay more to support HTTPS.

When I look at it from a different lens, I believe the internet should be as private as possible. Encryption is a solution. I think we should all make a push to make things more secure. Hopefully, we can destroy the cottage industry around SSL certs and it will be bundled in as an expected value add with either hosting or DNS purchase. I think that $1 a month is enough rent for a cert, I saw an SSL cert offered for $600 bucks which is quite problematic if it represented the threshold someone would have to cross to get a cert.

Hopefully, mozilla will work to sort out the CA problem, which is the real thing holding back HTTPS adoption.

</comment><comment><USER64> Question: if I'm prototyping a webapp on my machine -- one that will ultimately run behind apache or nginx or an amazon load balancer or something -- can I still prototype it in my browser with new features enabled without getting a valid https setup running on my localhost?

<comment><USER65> Yes; localhost specifically counts as secure.

<comment><USER33> Hopefully they put in a whitelist option... (similar to IE's security zones)... so you can whitelist your development domains.. in the case of hostnames, or when you hit a local VM.

I agree with another comment that a red broken lock for HTTP connections would be a better approach.

<comment><USER16> Chrome is proposing the same thing as Firefox (deprecating advanced features over HTTP) and additionally wants to visually mark HTTP connections as insecure: [https://www.chromium.org/Home/chromium-security/marking- http...](https://www.chromium.org/Home/chromium-security/marking-http-as-non- secure)

</comment></comment></comment></comment><comment><USER66> For a start, I would like to see http content and https self-signed content being marked the same way. The fact that https self-signed has a shocking warning right on the face and that http is just let through makes me a very sad camper.

</comment><comment><USER67> Why do we have to pay for an SSL certificate? Shouldn't it be free?

<comment><USER68> You would think so.

The problem is that browsers have gone and made self-signed certs suspect, and yet not created, for example, a well-established foundation for signing such certs.

<comment><USER14> It's exactly what they're doing with Let's Encrypt.

</comment></comment></comment><comment><USER69> I can see how https is technically better than http. But wouldn't a https-only web put too much trust in companies who create certificates? I can't think of a concrete danger but it sounds dangerous that the degree of security depends on monetary interests.

</comment><comment><USER70> Without a solution to everyone needing to pay for a certificate and identify themselves this seems a bit premature. Maybe browsers will relax the "This is an evil self signed certificate on the site" warning when they do it.

</comment><comment><USER71> Why isn't encryption in the network stack, at a lower level than HTTPS?

<comment><USER72> It is; HTTPS is HTTP over TLS ("Transport Layer Security"), however, there are various features like pinning, HSTS, etc that need to be controlled by the application layer, which is why we talk more about HTTPS than TLS.

</comment></comment><comment><USER73> In the worst case, Mozilla (i.e. Firefox and Firefox OS) will make itself irrelevant because it breaks the Internet for its users.

In the best case, this will make website owners value HTTPS as a marketing decision (rather than a boring non-mandatory privacy decision, because let's be honest, what business really cares about its users' privacy as much as it cares about marketing goals?). Much like how Apple helped making Flash irrelevant (at the cost of impacting their users' experience just like Mozilla does now).

</comment><comment><USER74> If you really want to tackle SSL make it less stupid. Self-signed certificates? I want these pinned and treated as secure. I want a notification if they change around the time they expire and a really big warning if they don't.

If we must have central trust sources, then have central hash servers so when I visit a new self-signer I can externally verify the hash.

<comment><USER14> Say the owner of a website with a self-signed cert fears it might have been compromised, and decides to create a new cert. How is the user supposed to distinguish that from a MITM?

<comment><USER74> That's what the central hash servers are for. Am I being MITM'd? Well, ignoring a global adversary, the problem is usually local. But CA's don't solve the global problem either.

<comment><USER14> Wouldn't you have to tell the central servers about each and every site you visited?

</comment></comment></comment></comment><comment><USER75> Maybe a good first step would be to make self-signed SSL certificates appear less scary than unencypted HTTP in firefox.

While SSL with self-signed certs don't make MITM attacks much harder, they do prevent passive evesdropping. Yet the firefox UI seems to imply the contrary, by making it harder to use https-sites with self signed certs than unencrypted sites.

</comment><comment><USER76> This kind of implies that HTTPS is secure. :) I dont think there is anything wrong using HTTP internally in a datacenter for data that is not sensitive (like monitoring, statistics, etc.). I guess you can still access these in legacy mode. I think the title should be that HTTP is getting phased out for public internet use or something.

<comment><USER77> actually, its not really "safe behind a firewall"

what if im inside the network i tell your monitoring that everythings ok while i break stuff?

<comment><USER76> and how is HTTPS protecting us against that? if you took over that IP address you can initiate a valid HTTPS session using the compromised server's identity and communicate with the monitoring service happily reporting fake data over HTTPS. I don't see your point. The question here is btw. is it worth X amount of dollar to protect this service with a secure channel? Sometimes the answer is yes, sometimes it is no.

<comment><USER77> the internal server is always made of servers and clients just like the external one. if you compromise one server you have access to the data transiting there, but not the others

if you compromise one client you have access to the data this client sends only

in particular, very few internal networks enforce L2 security (ie its possible to sniff all data on the same VLAN as you are).

</comment></comment></comment></comment><comment><USER78> Whole point of certs is to verify the site ownership. If getting certs is too easy, well those are then worthless. As it happens to be already. Email verification of domain ownership isn't good verification at all. These certs even if trusted are no different from self signed certs. IMHO.

</comment><comment><USER79> So, to what extent does this address the concerns of Tim Berners-Lee, expressed in "TLS Everywhere, Not Https: URIs" [https://news.ycombinator.com/item?id=9424327](https://news.ycombinator.com/item?id=9424327) ?

</comment><comment><USER52> I understand that http will still be supported but downgraded by both Mozilla's browser and Google search. How about distinguishing websites that are only static content, and websites that have some forms, or dynamic content.

</comment><comment><USER80> There where an interesting article recently on HN about this;

"Please consider the impacts of banning HTTP"

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

<comment><USER73> That was the opposite though. There's an obvious difference between making a website HTTPS-only and making a browser HTTPS-only (or blacklisting features for non-HTTPS websites).

</comment></comment><comment><USER81> Great! Now I just need to setup ssl on my Raspberry Pi to access the several web interfaces I have running there. Oh wait. I'm no longer running Firefox, I won't have to worry about this immediately.

<comment><USER14> If you're running Chrome instead, you still do; they have similar plans.

</comment></comment><comment><USER82> So SSL on localhost? That seems a bit over the top? Can we then assume that all browsers will include a trusted CA/cert for localhost? That doesn't work with eg: ssh tunnels? Or will we need "developer" browsers and "app" browsers to work with localhost? Either for test/dev or for deploying "apps" with nodejs etc?

I'm not sure if considering localhost to be secure/"encrypted" (access to all features) would be a good or bad idea...

</comment><comment><USER83> this is very bad news indeed for hobbyists

</comment><comment><USER84> HTTPS everywhere is huge waste of energy. Lets encrypt ==> lets transform energy to heat.

</comment><comment><USER85> Great! Make it simple to implement for all and make it affordable.

</comment><comment><USER49> If anyone needs help or has questions about SSL, please ask! I work at a company that provides SSL and would also be happy to give out discounts to anyone here.

</comment><comment><USER86> How does this affect personal websites?

</comment><comment><USER87> I think there are some issues here.

Browser vendors have indirectly created the money sucking machine that is the certification industry by requiring potential root CAs to have been audited to a very thorough standard (e.g. WebTrust).[0] Most of these audits implicitly require dedicated premises, extreme physical security measures, dedicated hardware, multiple dedicated uplinks, 24x7 personnel, and more. Even browsers that don't use their own cert store prop up this system by using the OS store which does require said audits. (And if anyone doubts how instrumental the browsers are to the continuance of this system, imagine how relatively niche the X509 industry would become if they moved to using something else.) As anyone who has tried to grok the documents at [0] will attest, it's a damn scary thing. Honestly you may as well try to start a bank. Or a country.

This level of difficulty creates a monopoly (or oligopoly, to be more precise.) Few people have the will/finance to do it so few do, and those who do get to take the piss with pricing. As I previously wrote[1], this means _FOUR_ companies control the CAs that issue 91% of _ALL_ the internet's TLS certificates.

LetsEncrypt seems like a good thing, and it might be, but it also might not be. It is, underneath all the PR, pretty much just another root CA who holds itself to the same auditing standards. It is no-doubt a very expensive undertaking and as such we may reasonably assume that there will be few, if any, additional zero-cost, fully-supported CAs in the future: and herein lies one problem. Unless you have specific requirements that LetsEncrypt just doesn't support, you have no reason not to use them. So a future CA landscape might be _ONE_ company controlling 99% of the internet's secrets. Oh dear.

What's more, we should not underestimate the importance of cheap shared hosting. The internet is a medium for information and nothing more, and _everybody_ has something that they might wish to broadcast. Currently, deprecating vanilla HTTP is akin to deprecating the ideas of millions of non- experts who rely on shared hosting to participate. We're telling them to join us in the land of VPSs and terminal emulators/Plesk (shudder), or to use one of the many PaaS services we've created over their own homemade solution. This is fundamentally anti-technology, which is supposed to harness innovation and make lives easier. This point is especially pertinent when you consider that the vast majority of these sites probably don't need encryption at all, so it's not even like you can mitigate the pain with direct benefits - <USER2> there are none.

Finally, TLS is a pain in the arse to administer. Really - it's not fun. I'm no stranger to it, and even I get a bit of a sinking feeling when it has to be done. To this day I'm bound to using Chrome, because no matter what I do I cannot get Firefox to _parse_ (never mind accept) my NAS's self-signed cert. Requiring TLS across the board is tantamount to requiring many millions of hours of pain across the world.

To hold up some moral torch that does _not_ have universal applicability and actively makes life difficult, and then declare it as canonical truth that all must adhere to is arrogance of the highest order. A great deal of chat in the tech community is dedicated to lambasting short-sighted and ill-conceived laws (think surveillance, copyright, patents, etc.) and yet here we are, _making them_. We have to do better.

        [0]: http://www.webtrust.org/homepage-documents/item27839.aspx
        [1]: http://lorddoig.svbtle.com/heartbleed-should-bleed-x509-to-death

</comment><comment><USER88> As someone who participated in the referenced discussion and on HN, I have to say I am very happy with this outcome. Seems like reason has won. Now, if Google follows Mozilla's example, we might actually be able to pull this off.</comment>


Asteroid set to come closer to the Earth than the moon Nov. 8 - <AUTHOR> http://www.nasa.gov/mission_pages/asteroids/news/yu55-20111025.html

<comment><USER2> The Moon is much larger and much farther away from the Earth than you are probably imagining when you hear this.

Still cool, though.

<comment><USER3> Here's an image of the Earth (on the left) and the Moon (on the right) to get a better sense of the distance between the two:

[http://eoimages.gsfc.nasa.gov/images/imagerecords/51000/5196...](http://eoimages.gsfc.nasa.gov/images/imagerecords/51000/51969/EarthMoon_juno_2011238_lrg.jpg)

<comment><USER4> Wow, I'm not sure I fully grasped the distance until I saw that picture. The fact that people actually went allllll the way out there and back just astounds me.

</comment></comment></comment><comment><USER5> Am I the only one who read the article hoping for a "If it DID hit the earth, X would happen..."?

<comment><USER6> A couple of nights ago a had strange dream about asteroids hitting earth. Didn't think much of it... still don't think much it.... but I would like to know _where_ this would hit if it were to hit.

<comment><USER7> That's kindof like not having a sweater, and asking what color it would be if you had one. If you alter reality such that it would hit, I think you sortof have your arbitrary choice of where.

<comment><USER8> Hmm, I wonder if the poles would get hit less often than the tropics due to the distribution of asteroids being more or less in the ecliptic, or whether that's not sufficiently significant. Probably not -- I don't know of any latitude-dependent distribution of lunar craters.

</comment></comment></comment></comment><comment><USER9> Brace yourselves: the doomsday articles/memes/stories are coming..

PS will it be visible to naked eye? if yes then when and where and for how long and where in the sky? can there be a real time Google earth 3d simulation like NASA did for space shuttle launch?

<comment><USER10> _The asteroid's surface is darker than charcoal at optical wavelengths. Amateur astronomers who want to get a glimpse at YU55 will need a telescope with an aperture of 6 inches (15 centimeters) or larger._

<comment><USER11> Yeah, it's the low albedo that kills you. Something that large made of ice would probably be quite bright.

Quick OOM calc: This thing has an area proportional to the moon of (200m/1700km)^2. The moon has an albedo of ~0.12. An object with albedo 1 would thus have a brightness of ~1e-7 of the Moon's. The full Moon has a magnitude of -12.7, so such an object would have a magnitude of -12.7-2.5log10(1e-7), or about 4.8. That's clearly visible to the naked eye at a dark site, but not very impressive.

</comment></comment></comment><comment><USER12> Hmm, the Mayans did quite a good job. They only guessed wrong by 324,600 kilometers and 53 days.

</comment><comment><USER13> Anyone know how fast it is going relative to the earth? And I'd love to get an answer to wether it will be visible.

<comment><USER14> 13.72km/s - 49392km/h

Source: <http://hisz.rsoe.hu/alertmap/index2.php> (scroll to the bottom for Earth approaching objects)

</comment></comment><comment><USER15> Would be interesting if during the flyby our analysis revealed that it was made up of a Gold core or something :). Suddenly NASA might get a bunch of funding to prepare for the next flyby

<comment><USER16> I hear stuff like this a lot (mining asteroids for precious metals)...

Wouldn't flooding the market with that much gold...crash it? Are we really talking about that many billions and billions of dollars worth of potential revenue from mining an asteroid?

This all just seems like fun sci-fantasy.

<comment><USER17> _Wouldn't flooding the market with that much gold...crash it?_

Well, presumably only a single party is going to recover that gold. If they dumped the whole load onto the market, it would crash. But if they release it slowly, then a greater supply from each batch would cause "inflation", so that the price they could get from the next batch would be lower. But they could still derive significant wealth before trailed off.

<comment><USER18> Seville in the 16th century is the best example of what might happen. Spain got hold of the equivalent of a gold-filled asteroid - South America. All the gold and silver came in through the port at Seville, which became very rich, and inflation slowly radiated out from there to the rest of Europe.

</comment></comment></comment></comment><comment><USER19> Anyone have a recommendation for a kick ass telescope that could see this thing? Best bang for the buck kinda deal.

<comment><USER20> It's actually much easier to locate and track large, distant objects than it is to track small, (relatively) close objects. Ever try to track a jet with a pair of binoculars? Not easy.

</comment></comment><comment><USER21> I'd guess that roughly 50% of asteroids passing by end up closer to the earth than the moon.

</comment><comment><USER22> Isn't about half the universe closer to the Earth than to the moon (at a particular time)?

Meaning: stand on a point of the Earth such that the moon is situated exactly above the opposite side of the Earth. Then look up. All that stuff you see is closer to the Earth than the moon.

<comment><USER23> This is the logical extension of the peek-a-boo fallacy.

The moon doesn't stop being closer to the earth simply because you can't see it from a particular point on the Earth.

About the only thing you can say is that if you were to proceed outward on a linear path from the opposite side of the Earth from that which the moon is currently positioned, then you would reach something other than the moon sooner than you would reach the moon.

But that would be saying nothing, really.

</comment></comment><comment><USER24> Let's hope it has enough velocity to escape Earth's field and carry on. I'm sure it does, but I'll keep my fingers crossed, just in case.

<comment><USER2> Give science a little more credit :) The n-body problem is hard, but it's more like "we don't know if this same asteroid will hit the Earth 20 years from now" hard than "this asteroid could shift course at any moment!" hard.

<comment><USER8> The _n_ -body problem is hard to solve analytically, but trivially easy to solve to arbitrarily high precision numerically.

<comment><USER25> I work at NASA, supporting the person who wrote the codes that is now used for planetary dynamics simulation, like this. It is an extraordinarily complex problem, and a specialized academic discipline in its own right.

n-body dynamics is a complicated, chaotic system. Getting any precision at all over any reasonable period of time is a feat of itself.</comment></comment></comment></comment>


The Rise and Fall of the Independent Developer - <AUTHOR> http://furbo.org/2011/07/13/the-rise-and-fall-of-the-independent-developer/ <comment><USER2> One of the issues here that wasn't mentioned, facing independent developers, is the almost pathological tendency of some people/groups in the F/OSS community to clone any even mildly successful product for no particular reason. I'm a big fan of free and open source software (especially when it's genuinely new or fills an actual gap, like the GNU tools and Linux), but there are times I wonder whether there are a lot of vested interests out there who would like to drive the cost of software to zero and make us all work for a wage providing 'services'.

There are entire categories of software now where people are now conditioned only to accept an open source product. Can you imagine anyone building a new computer language now, commercially? If it was even vaguely successful it would be cloned and forked so quickly it'd make your head spin.

Between the ideologues like Stallman, who effectively think it's immoral to make money off selling the software itself (I know his position is supposedly more nuanced than that, but free software effectively amounts to this if you have to hand out source to all and sundry) and the open-source-friendly companies like IBM and Google - who have every reason to drive the $$$ available off software to zero, it's easy to feel a bit beleaguered.

<comment><USER2> To clarify my point, my problem is not with open source in general, it's with 'feature-by-feature clones of an innovative piece of software'.

The process of building, say, VisiCalc is a lot riskier and harder than turning Excel into Libre Office Calc. If Bricklin had known he was going to have to compete with free in a matter of a few months after release, he might have done something else entirely.

This may be hard to understand for people that haven't ever designed anything difficult, but frankly, it's _so_ much easier to clone something than build it the first time. Even just knowing that something is possible is a huge leg up.

If you think routinized F/OSS cloning of software is an actual service to innovation, you need your head examined. If nothing else, it makes going into a patent frenzy with every idea far more tempting.

It's hard for me to prove a counterfactual, of course, and show all the wonderful things that have been discouraged by the prospect of immediate shitty open source clones. I fully accept that open source allows us to build innovative things on top of other software layers - it's not necessarily all bad. But it's not necessarily all good either.

<comment><USER3> So you think Excel was an "innovative piece of software" in the first place? It wasn't. Many spreadsheets existed before that.

A much more practical angle: there is no MS Office or equivalent for operating systems such as Linux and BSD, so the OS people had to write their own.

To be honest I think the developers of LibreOffice are heroes. Not many people in the open source scene want to be seen working on 'boring clone' projects like an office productivity suite, and would rather innovate. But the fact is, it is a necessary evil for many users, and the availability of OO has helped Linux adoption a lot.

<comment><USER2> You appear not to have read the post you are responding to. I'm particularly baffled as to why you are reassuring me that other spreadsheets existed pre- Excel given that my post mentions VisiCalc and Dan Bricklin. As we used to say in high school: "No shit, Sherlock".

Nor are you making a germane response to my post, which is not that LibreOffice is bad and Excel is good, but that if the creator of Visicalc had been in the situation where a few short months after he created his spreadsheet someone was going to clone it and give it away for free, he may not have bothered.

</comment></comment></comment></comment><comment><USER4> The sad reality is that if you make something of value, there are rotten people who will come and try to steal from you. The author thinks he's discovered something new. I don't think he has. "Patent trolling" might be a bit of a new angle but business has always been risky.

In some parts of the world, if you farm a little too much, gangs come by in rusty toyotas with AK47's and help themselves (and might kidnap your children for good measure). In our society, we've allowed these men to wear suits and pretend they are contributing members and in exchange, they no longer use guns. This seems like a valid compromise until we as a society outgrow this sort of behavior. (Here's hoping)

There are tools for managing risk. Create an LLC and have professional liability insurance. Sure bad stuff can happen. I had an over-zealous zoning official try to revoke the business license for my house because I was "manufacturing" software (and manufacturing is zoned industrial, donchaknow).

I wish there weren't patent trolls, but at some point you have to admit that you can't spend your life worrying about all of the bad stuff that _could_ happen. Take a few reasonable precautions and then do your thing.

<comment><USER5> Neither an LLC nor liability insurance will stop your business being destroyed and years of your life being wasted if a troll decides to target you.

Would you suggest an LLC for each product so that they can only be attacked individually?

<comment><USER4> Actually, if they are suitably different, _yes_. It has the added benefit of making it easy to sell the product/business down the road or convert to a different kind of Corp to get investors.

If a product is good enough to make money on it's own, it's good enough for its own LLC.

</comment></comment></comment><comment><USER6> He's got his history completely wrong. From the first days that home computers were affordable at all, there were tons of very small software shops. I recall purchasing programs from computer stores that came in poly bags containing a photocopied manual on card stock and a cassette tape with a photocopied label that had been glued on by hand. If you called the company for support, sometimes you woke the guy up.

</comment><comment><USER7> All businesses have risk.

Even if you are an indie one man shop you are in fact a business and there are risks. Same thing goes for being a lawyer or accountant or contractor. If you screw up, it could cost you financially in a very big way, even if you didn't intend to do anything wrong.

Even successful businesses can crumble, even billion dollar businesses can get beat up by litigation to the point it isn't even worth continuing.

To say that the sky is falling for indie devs is a bit silly. There are plenty of places you can build, innovate, distribute, and succeed. Sure, the iTunes App Store thing is big today, or maybe Facebook, or maybe Steam, or maybe Wii's downloadable channel, it doesn't matter. Any one of those could be gone in a year or two.

Here's an example, there are people out there who make millions of dollars selling e-books and mediocre/overpriced software on Clickbank right now. Some of those people get sued I'm sure for their products. More people show up. You could take the same ebook and sell it on Kindle or Nook if you got shut down or you could sell your software on the Mac App Store or Chrome Web Store if CB went under.

There are so many platforms to distribute and build software and businesses on now, it really is hard to complain about the death of the indie developer because there are so many new companies getting started every day on all these different platforms that didn't exist even 5 years ago.

As a business owner you can't control all risk, but you certainly can and should plan around them.

If one channel gets shut down, move on to a different one or a different product.

Great devs and great companies aren't built on one hit one time wonders.

<comment><USER8> The problem is that a lawsuit easily can take out a small developer. Even if the lawsuit is completely frivolous. I can't afford tens of thousands of dollars for a lawsuit. If I get sued my company is probably done. It doesn't matter if the suit has merit or not.

<comment><USER9> I haven't gone through this or anything, so maybe an actual lawyer would be happy to speak up in this thread. But my simpleminded understanding is that your typical frivolous lawsuit goes like this, only less transparently:

TROLLCORP: "We're suing your company for ONE MILLION DOLLARS."

CEO (through a lawyer, of course): "Well, oops, we've only got ten thousand in the bank plus a couple of old Macbooks. After that we're just going to declare bankruptcy and you won't see a dime."

TROLLCORP: "Well, okay, frankly, we don't want to see you go bankrupt. Bankruptcy court is no fun at all. We don't need to pay for a tedious legal battle. We just want the money. How about you just give us the ten thousand plus 5% of all future revenue from your products?"

CEO: "If I spend the ten thousand on a lawyer, I can file some motions to delay your lawsuit. _Then_ I can go bankrupt. You'll get nothing then. So, how about one thousand bucks and 0.5% of future revenue?"

TROLLCORP: "Two thousand and 2%."

CEO: "Done."

As with any parasitic transaction, the parasite has no rational interest in killing you. Dead companies don't pay. The danger, of course, is that they won't be reasonable and will accidentally push too hard, in their attempt to convince you to search under more sofa cushions for loose change that they can take. Or that they are, in fact, happy to kill your company because they think it will be an instructive demonstration for the other companies they sue. Or that they will gradually consume your time and suck your blood and your company will eventually die of exhaustion in 2% increments. But, you know, this is why it's good to be a _small_ company. Having nothing means having nothing to lose.

<comment><USER10> The "can't squeeze blood from a stone" defence is probably your best bet if you're a really small operation, but as you say you'd just better hope the patent troll is behaving in a rational manner & not trying to make an example of you. I would assume that a rational troll would only harass you if you were getting noticed & making a profit, but who knows what kind of reasoning goes on within the lizard hind-brain of your standard patent troll types...

</comment></comment></comment></comment><comment><USER11> If it were easy, everybody would be doing it. It does suck that now independent developers have to also worry about patent litigation. However, it will not stop the most resolved developers from continuing forward.

On the bright side, patent trolls are patenting the most obvious patents right now. In 20-30 years all of those patent will expire. I'll be amazed if 20 years from now we will still continue to patent obvious things like one click button transactions. If so, we all deserve to go down the ship of financial failure since it is us, society, that allows such things.

Meanwhile, if we could only find the best ways to make patent trolls' lives more painful... At least it would dissuade the casual patent troll.

<comment><USER5> The implication is that products for which there is a demand won't come to market.

It might not be easy, but society is harmed if we make it artificially harder to respond to market demand.

<comment><USER11> I understand, but unfortunately short term (like next year) is hard to change that (or maybe we can we just haven't figured it out). It is still better to continue moving forward, we'll figure something out along the way.

<comment><USER5> What do you mean by 'moving forward', and what do you expect to happen that's going to change things in the longer term?

<comment><USER11> I mean don't just give up. I don't know what will change, but things have a way to work themselves up if one continues to hammer at the problem. There will always be issues when trying to do something important. This is just another one.

And as I write this I realize that I sound a bit corny. The shame... (no sarcasm intended)

<comment><USER5> It's not particularly corny, and it's hard to disagree about not giving up in principle.

That said, human political systems can and do lead to sustained bad results. In my mind, 'things working themselves up' really means, 'someone finds and implements a solution'.

Meanwhile actual indie developers are as we speak, prevented from working on adding value to the economy because they are forced to spend their time and money dealing with trolls.

</comment></comment></comment></comment></comment></comment><comment><USER12> Unrelated, but interesting nonetheless: the current software industry has a strikingly similar feel to the early texas oil prospecting days.

Independents are suddenly able to take a little bit of risk, take on some money (then: banks, now: angels and VCs), and work by themselves or in small teams to produce something that lots of people need (then: oil, now: good software).

Some of the biggest fortunes in history were made back then (1900 - 1930s), just as some of the biggest fortunes are now being made in this industry.

The digger I deep (no pun intended), the more similar these two stages of history look alike. I'm sure there are other eras that also share these common threads.

</comment><comment><USER13> What I'd like to see is a collective legal fund to protect devs from patent trolls. Like insurance, everyone pays into the system and if you need representation, high quality lawyers would be there for you. That seems to me to be the best solution to this problem short of abolishing software patents altogether.

<comment><USER5> I like they idea, but I don't see how it reduces the risk. If someone has a valid patent, you're still in trouble.

<comment><USER14> An independent developers' patent pool, then.

<comment><USER5> Patent pools are no defense against trolls.

<comment><USER14> Fair point.

</comment></comment></comment></comment></comment><comment><USER15> _In the days where software was distributed on magnetic media, such as reels of tape, cassettes, or floppy disks, it cost a lot of money to get the product to a customer._

One of us is misremembering. _I_ seem to recall an interview with Gates and/or Ballmer where they talked about the realization that the cost of 5 or 6 floppies at wholesale was insignificant compared to the revenue from the software, that it was a no-brainer cost-wise. CDs were the first time when cost became an issue, iirc (again) because you had to pay for one or more masters to print the production copies. I'd feel better if his history was right.

 _This time the retail channel itself is very cheap, but the ancillary costs, both financially and emotionally, are very high._

 _And, of course, only large companies and publishers can bear these costs. My fear is that It's only a matter of time before developers find the risks and expenses prohibitive and retreat to the safety of a larger organization. We'll be going back to square one._

I can't even address the "emotional costs" he talks about, but there is a precedent for dealing with risks of this kind. For consulting engineers, it's called "errors and omissions insurance." It strikes me that if there isn't something like that for developers, one plausible reason is that this kind of liability hasn't actually been a problem. Is there errors and omissions insurance for developers?

 _From our experience, it's entirely possible that all the revenue for a product can be eaten up by legal fees._

The author uses the phrase "from our experience," but I wonder what that experience actually is. At this point, it's not even anecdotal, because he doesn't supply the anecdote! We can't even begin to ask if his experience generalizes. For example, did he get good counsel? Was he actually infringing? Should he have settled? Did he avail himself of the FSF or ESF if applicable? Should his product have been more profitable?

I think I'm either blessed or cursed with too much curiosity to take this guy at his word.

<comment><USER16> >The author uses the phrase "from our experience," but I wonder what that experience actually is. At this point, it's not even anecdotal, because he doesn't supply the anecdote!

Craig is a very well-known developer and author in the Mac and iPhone developer community and works at Iconfactory. They're one of the first companies that was addected when the Lodsys patent issue came to light. Even if you didn't know that, the very previous entry on his blog is an open letter to Apple about the problems his company is having with the patent issues. It's a little disingenuous to call someone out about omissions in a blog entry while taking zero effort to familiarize yourself with any of their work.

<comment><USER17> It seems perhaps as disingenuous to think that because you know a (very) little bit about the Lodsys issue that the anecdote that all of a products profits can be consumed is true even in this instance. After all, Apple has been standing up in defense of individual developers on this issue.

<comment><USER18> This is not true. While this may be true in the future, Apple is not currently involved in the legal defense of companies involved in the Lodsys lawsuits and there is no timetable for which they will enter into such an involvement.

</comment></comment></comment></comment><comment><USER19> Does anyone have any statistics about the number of independent developers / startups that suffer a significant negative financial impact because of a patent infringement lawsuit? My gut feeling is that it's a very small percentage. A few years ago, I think Paul Graham wrote an article suggesting startups shouldn't worry about being sued because in practice it rarely happens to them.

</comment><comment><USER5> Does anyone think that a legislation preventing NPE's from suing for patent infringement would be practical? They'd still be able to hold them - just not sue.

It seems like something that large corporations as well as independents could get behind.

<comment><USER20> How do you prove that an organization is an NPE? All they have to do is hire a couple of college kids dirt cheap and they can show that they are "developing" a product.

Denying patent protection to anyone who doesn't already have a finished product out on the market opens a whole new can of worms.

<comment><USER5> The law already deals with vague definitions. It really wouldn't be too hard to write something that erred on the side of making it somewhat hard to prove that you were practicing.

</comment></comment></comment><comment><USER21> Should move the corporate to China and clone the heck out of everything.

Facebook -> RenRen

Twitter -> Weibo

YouTube -> Tudou

Google -> Baidu

Flickr -> YuPoo

See <http://www.randomwire.com/chinese-web-20-clones>

Yeah, Trolls, go ahead and sue them.

</comment><comment><USER22> Well, the good thing about it is maybe this will force a "Silicon Valley" to finally appear in Europe where the odds aren't stacked so badly against the little guy.

</comment><comment><USER23> I wonder what 37 signals would do.

</comment><comment><USER24> It's really hard to want to continue reading when the third sentence says this:

 _Little has changed with the process of software development since the 1980's_

I understand the point: that things are the more the same than ever, that this guy is a salty old sonofabitch who's forgotten more than i've learned, but seriously. Little has changed with the process of software development since the 1980s other than the tools? The entire way we think about why we're building software and what we're trying to get out of has changed and is still changing.

</comment><comment><USER25> Our startup (<http://infostripe.com>) is built on independent spirit. So far we have been doing well. It's a struggle sometimes but always worth the effort.

<comment><USER26> Every comment you've made has a link to your startup in it. There's a difference between self promotion and spam.

<comment><USER25> It's true, I do mention my startup a lot. It's just that we are a small (aka unfunded) startup with lots of dev and little marketing.. when I see an article that is relevant and I have a thought on it I link to try and reach out. I don't have much time to really get into comments as I'd like. I read a lot though. I will try and find other ways to contribute.</comment></comment></comment>


Bootstrap 2.0.2 released - <AUTHOR> http://www.markdotto.com/2012/03/12/bootstrap-2-0-2-released/

<comment> w-ll This probably isn't new to 2.0.2 but I just noticed "What up girl, this is Section C." in the Tabs section.

<comment><USER2> Finally, documentation that speaks to me.

</comment></comment><comment><USER3> Badges are a much welcomed feature, but it's too bad they don't have any live examples in the documentation to see how they look.

Mark mentions fixed-bottom dropdown menu's, but I don't seem to see it mentioned in the docs anywhere also.

<comment><USER4> Badges live examples are here: <http://twitter.github.com/bootstrap/components.html#badges>

<comment><USER5> That section doesn't appear to exist for me. The "Miscellaneous" section has the subtitle "Wells, badges, and close icon", but only wells and the close icon are actually there.

Edit: Whatever cache was holding this appears to have refreshed, I can now see it under its separate section, along with the rest of the updated docs.

</comment></comment></comment><comment><USER6> Because I just downloaded Bootstrap yesterday I kept getting v2.0.1 due to caching. I wouldn't even have caught it if it wasn't for svn not showing a change. What's up with the anti-version number visibility trend?

</comment><comment><USER7> Bootstrap keeps getting sexier and sexier. Thank you to everyone who's contributing.

</comment><comment><USER8> We absolutely recomment Bootstrap! We also used it in an earlier version to realize our newest project called SpritePad www.wearekiss.com/spritepad

</comment><comment><USER9> Yay!

</comment><comment><USER10> I love the work that is going on with Bootstrap. I merged the BS master branch with my fork, copied the files into my project. Quickly checked to see if everything was good, then pushed it live. A smooth upgrade with no real issues. <https://www.voo.st/></comment>


A Growing OpenStreetMap Needs Your Support - <AUTHOR> https://donate.openstreetmap.org/ <comment><USER2> The Operations Working Group, the sysadmins holding the servers together, are all volunteers. [http://wiki.osmfoundation.org/wiki/Operations_Working_Group](http://wiki.osmfoundation.org/wiki/Operations_Working_Group) and keeps a list of hardware and open issues. [https://github.com/openstreetmap/operations](https://github.com/openstreetmap/operations) (more help always welcome).

A frequent question is why the hardware bought and not rented hourly/yearly with a PaaS. First of all the bandwidth requirement are huge and it would put too much pressure on the organization to reach donation goals every year.

Besides the donation runs you can also become a member ([https://join.osmfoundation.org/normal- membership/](https://join.osmfoundation.org/normal-membership/)) or you company a corporate member ([http://wiki.osmfoundation.org/wiki/Corporate_Members](http://wiki.osmfoundation.org/wiki/Corporate_Members)).

Unlike wikipedia the donation drive won't need months. If I remember correctly last year two companies gave 20.000 USD each. That said: donate now please.

disclaimer: work at [https://geocoder.opencagedata.com/](https://geocoder.opencagedata.com/), we're a corporate member

</comment><comment><AUTHOR> It's not widely appreciated how efficient OSM is: the whole project runs on roughly $170k a year. Wikimedia spends around $65m (there are, obviously, many differences in what the organisations do, but it's an interesting comparison).

<comment><USER3> By design :-)

<comment><USER2> To put the comment in context: Steve Coast started OpenStreetMap [https://en.wikipedia.org/wiki/Steve_Coast](https://en.wikipedia.org/wiki/Steve_Coast)

</comment></comment></comment><comment><USER4> OSM powers this JavaScript library that was shared earlier: [http://leafletjs.com/](http://leafletjs.com/)

Here's the related discussion: [https://news.ycombinator.com/item?id=12589447](https://news.ycombinator.com/item?id=12589447)

<comment> harry-wood There's some complicated nuance in the word "powers" in that sentence. LeafletJS is an open source javascript library for displaying maps on the web. This usually involves bringing in a base-map, and you can get this from a whole myriad of different providers who do the stylising, rendering, and hosting of raster map tiles. They in turn may or may not be doing all of this using vector map data from OpenStreetMap. It's all nicely de-coupled, although for a typical web developer, when you look to "use OpenStreetMap" it will mostly just involve learning how LeafletJS works. Also regardless of which OpenStreetMap-powered tile server you choose to use, you must give credit to OpenStreetMap on your map display. But to illustrate the de-coupling... you might also choose to use "OpenLayers" instead. It's another open source javascript map display library!

</comment></comment><comment><USER5> This is one of those reminders I'm glad that is posted to HN.

I've just donated, it's a great project, if you value it too you should give what you are able to.

<comment><USER6> And it reminded me to donate to Qgis too! [http://qgis.org/en/site/index.html](http://qgis.org/en/site/index.html)

Kudo to all FOSS GIS developers!

</comment></comment><comment><USER7> As well as giving money, it's also useful to become a member of the OpenStreetMap Foundation. You get voting rights for the board, which helps set policy directions, and (possible) licence changes.

</comment><comment><USER8> OSM is an incredibly impressive and useful project. It's gotten to the point where it is, at least for some locations, competitive with Google Maps.

</comment><comment><USER9> Doesn't Apple Maps use openstreetmap? Are they donating?

</comment><comment><USER10> what is the best OSM powered navigation app for Android?

<comment><USER11> IMHO it is Maps.me by far

</comment></comment><comment><USER12> Paypal only? Not happening. Sorry guys.

<comment><USER13> They accept Flattr, Bitcoin, bank transfer and credit cards (through PayPal, but not requiring a PayPal account).

[https://wiki.openstreetmap.org/wiki/Donations](https://wiki.openstreetmap.org/wiki/Donations)

<comment><USER14> Does PayPal get a cut of the donation?

</comment></comment></comment><comment><USER15> and here is where i have a problem with "Open..."anything.

the belief that a non-profit model is the sole method for maintaining ideologically directed development is a fallacy. look to Mozilla, which at times has strayed far from the best interests of its users. look at the wounded soldier project. the belief that making a profit will cause for corruption of the ideological drive of an organization is a fallacy. look at SpaceX which has made more progress in a shorter period of time than just about anyone else to date.

the problem i have with the "please send us money" routine is that it ignores certain basic, fundamental economic and financial realities. if an organization is creating value, then they should be able to exchange value for value. if they are not creating value, then it should be considered R&D or a hobby, and should be funded as such. OpenStreetMap is creating value. there is no reason they shouldn't be able to utilize the freemium model. the freemium model could be coupled with a california style "benefit corporation". by acknowledging that we _all_ must sing for our supper, we are forced to face the realities of the marketplace, of limited resources, of special needs, and so on. by continuing to deny this fact these organizations will constantly be either over or under funded compared to their needs. said more plainly, by staying totally blind to the economic realities of ones marketplace you're gonna make worse business decisions than if you put it all on the table. every time.

bottom line, there is no free lunch, and until the open-source community fully acknowledges and embraces this _reality_ it will be at a disadvantage to other players. and, frankly, it will be lying to itself.

disclaimer: i'm a die-hard open-source software advocate. i just want to see it succeed.

<comment><USER8> The freemium model would effectively defeat the whole point of OSM.

<comment><USER15> How so..? Open-source is twice free. Free as in beer. Free as in speech. So, OSM could give away the map, but provide value added services to city planners, sell api tokens to advertisers, sell services to private developers.

Oh wow, I just thought up three possibilities in a minute which still allow it to be kept free for individuals.

Last week I began working on a bicycle routing app for android, and there is no obvious way to have unlimited calls to OSM, even if I paid. So, what I must do is host my own instance of it. That's a lot of overhead for most use cases. This is pretty much the opposite way app development has been going, where I build off an api as a service.

If I'm using OSM wrong in this case, I'd sincerely appreciate being pointed in the right direction.

side note, I'm assuming you down-voted me, but thank you for at least saying why. other down-votes received, because i guess they are right. feels like high-school popularity contests all over again when receiving anonymous down- votes. heck, maybe it's possible to have a dissenting comment without a down- vote. HN obviously believes this mechanism is good enough for letting the best stories rise to the top. not sure why HN feels that people's comments should be down-voted but stories shouldn't...

<comment><USER8> Thanks for an explanation. I was thinking in the direction of commercializing the map itself. Considering how many tech companies go in this direction. I don't know what I was thinking.

And I did downvote you, because when I read your comment, it seemed to merely be bashing on OSM, and didn't seem to be adding much value to the conversation. Now that you've clarified, I kind of regret it.

And yes, anonymous downvotes are terrible, which is why if I downvote I usually post a comment explaining why, unless somebody else has already done it better.

<comment><USER15> all good, that's why i appreciated your comment :) fostered conversation, and we met in the middle! take it easy!</comment></comment></comment></comment></comment>


Could you link me to the post about a guy who never gave up singing? - <AUTHOR>

I remember someone who wrote about how he wanted to be a good singer but was put down by people who said he wasn't cut out for it. But he never gave up and in the end after decades of practice he got good at it. He wanted to take up programming next. Anyone has the link to this article? <comment><USER2> Here you go

<http://sivers.org/15-years></comment>


Ackermann Steering Geometry - <AUTHOR> https://en.wikipedia.org/wiki/Ackermann_steering_geometry <comment><USER2> The mechanics of turning are one of those things that seem simple and mundane at first but become increasingly more interesting the more you analyze them.

For instance:

How do trains turn if the outside wheels can't spin faster than the interior wheels? \- [https://www.youtube.com/watch?v=Ku8BOBwD4hc](https://www.youtube.com/watch?v=Ku8BOBwD4hc)

How do you create stable train wheels? \- [https://www.youtube.com/watch?v=agd8B-31bjE](https://www.youtube.com/watch?v=agd8B-31bjE)

How do automotive differentials work? \- [https://www.youtube.com/watch?v=85CA4_cgZ5U](https://www.youtube.com/watch?v=85CA4_cgZ5U)

How do 6 wheel truck differentials work? \- [https://youtu.be/LwZBnMQ40rI?t=261](https://youtu.be/LwZBnMQ40rI?t=261)

And on and on down the rabbit hole

<comment><USER3> Great video from 1937 on differentials: [https://www.youtube.com/watch?v=yYAw79386WI](https://www.youtube.com/watch?v=yYAw79386WI)

<comment><USER4> I think it's been discussed a few times on HN before. The fact that it's over 80 years old yet easier to understand than newer material is amazing.

</comment></comment></comment><comment><USER5> As a boy I'd always wanted a small car that I could drive. I pestered my father for years with plans from various magazines until one came up for a kart ("go-kart"). He got interested and bought some scrap mild steel. My job was to cut everything to fit and assemble it. We paid a welder to weld it.

But the steering geometry was the beautiful part. We knew about Ackerman's work and also about camber, caster and toe-in/out but had never done any design. So I had to read up on steering design/geometry. I already had a strong interest in auto sports. My geometry class turned out to be quite useful. FWIW on a kart with no suspension the geometry problems are simpler.

That kart is still in the family, still running and never had a structural failure. It's worn out a number of engines and been a blast for all involved.

[http://yospeed.com/wheel-alignment-explained-camber- caster-t...](http://yospeed.com/wheel-alignment-explained-camber-caster-toe/)

<comment><USER6> a competition kart with a single solid rear axle has a different steering setup from the car. the wheels also dig into the ground to lift one of the rear tires up, which allows the cart to actually turn. otherwise they understeer under enough throttle.

when a car goes fast enough you actually want anti-ackermann. the slip angles and not the actual angles are what matter, and the inner wheel has a different load which means it needs to turn less rather than more in order to still grip.

<comment><USER5> Our kart had a live rear axle with power to both wheels and slicks on the rear. Top speeds was < 60 mph so standard Ackerman geometry was fine.

On a track or flat parking lot you could throw the wheel hard left or right even at max speed with no controllability problem other than the aforementioned slight "washing out" if the surface was slick. It _would_ go into a very nice predictable controlled slide.

I miss it! It was great training for later driving a car. I never had the urge to do anything foolish in an automobile b/c the kart was always far, far more exciting. Driving a car was dull in comparison.

<comment><USER6> shifter karts are faster, but the one i modified for a project only did 60mph. you still needed to lean. you were probably still seeing a great deal of slip.

take a look at the steering on a pro kart - the wheels are deeply angled around the kingpin and dig into the ground.

</comment></comment></comment></comment><comment><USER7> Here's a neat demo in JS [https://www.quaxio.com/steering/](https://www.quaxio.com/steering/)

</comment><comment><USER8> My first exposure to this term and concept was back in the early-mid 90s when building and racing RC-10s. Ackermann was something we could adjust, and it, combined with caster, made a big difference in how the vehicles steered especially in the dirt.

<comment><USER9> yep, I learned a lot about steering and suspension tuning racing rc. I raced dirt oval and then asphalt oval back in the day.

<comment><USER8> Hobby-grade RC kits have to be one of the most useful educational "toys" you can give children, even today.

My childhood street had a circle of boys who regularly did RC stuff together, our bedrooms overflowing with kits, parts, tools, it was borderline obsessive. But as we became young adults, it was _very_ apparent that we had learned a whole lot of valuable skills the kids whose parents refused to spend money on the relatively expensive toys lacked.

I remember like it was yesterday a friend letting me take one of his disassembled kits unfamiliar to me home without the instructions so I could put it back together "blind" for the fun of it. It was just a box full of tiny screws and parts, such a great puzzle, with only the box exterior photos to go from. It was a Kyosho Lazer ZX-R, I coveted that kit.

</comment></comment></comment><comment><USER10> The most bizarre application of this is drift cars

They actually have pretty aggressive negative Ackerman, which is why they can do stuff like reverse entry drifts

<comment><USER11> I love ice-covered parking lots in the winter!

But you gotta know that the lot has no interior curbs.

</comment></comment><comment><USER12> And more generally:

Control Schemes of Steering System of a Multi-axle All-wheel-steering Robot

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

</comment><comment><USER13> This is incredibly useful for driving games. But like all physics in games, it is better to fake it.

</comment><comment><USER14> This model always reminds me of Nelson's parking problem:

[https://rigtriv.wordpress.com/2007/10/01/parallel- parking/](https://rigtriv.wordpress.com/2007/10/01/parallel-parking/)

</comment><comment><USER15> This would seem unnecessary if you have a differential, right? Or if your front wheels are unpowered.

This steering configuration would seem to also require very large wheel wells.

<comment><USER16> None of the above.

The problem this addresses is facing each front wheel the correct direction when turning.

Imagine fixing a pair of bicycles together at the bodies. When you want to go around a corner, the inner bicycle will have to turn more sharply than the outer one (which in turn has to go faster). That means that the front wheel needs a higher angle of deflection on the inside than the outside.

The same dynamic exists in a true 4-wheel vehicle, except that there is a mechanical linkage that allows you to steer both front wheels together instead of independently. The problem this linkage geometry solves is the problem of getting the inner wheel to deflect further than the outer wheel, by approximately the right amount. (iirc, this geometry doesn't get that perfect, and modern cars use a variant that's a bit more accurate. But that's a small optimization compared to the improvement this provides over just making the wheels both turn the same angle.)

The problem a differential solves is allowing the wheels on the outside edge to spin faster even when sharing an axle with the wheels on the inside edge.

</comment></comment><comment><USER17> Is this what the Yamaha Niken uses?

<comment><USER18> Yeah, but with such a short distance between the wheelbase I'm not sure how important this would be apart from the very tightest of corners.

<comment><USER17> Well with the Niken it's the fact that it's got two wheels up front but can still lean. That's as opposed to the Can-Am Spyder which is an old school trike.

</comment></comment></comment><comment><USER19> Huh, TIL. That's really cool!</comment>