Extended Validation Certificates Are Dead - <AUTHOR> https://www.troyhunt.com/extended-validation-certificates-are-dead/ <comment><USER2> I'm seeing a lot of discussions about financial and specifically banking sites here. For the average user, there's no reason or need to phish a particular financial site.

One of our engagements sent users to a site we just made up, and asked for user credentials for a site they had never heard of in order to access cat videos. In most cases, we were given valid domain credentials. I'd bet money a high percentage of those were also banking credentials. What good would an EV cert at the bank do for this?

<comment><USER3> It wouldn't do anything, because users don't check it. I used to be involved in phishing campaigns against internal employees at a fintech company. Despite these employees being highly technical people, I can't recall incorrect or missing extended validation certificates ever stopping them from submitting credentials.

As another commenter has said, I can't personally tell you the name of any specific website with an EV certificate. I don't know any friends or family who actually check for the presence of correct EV certificates. It's a cool idea and it's made CAs plenty of money, but it's just too subtle of a cue.

I think many people are resistant to the idea that extended validation certificates aren't effective for one or both of two reasons. First, they probably want to actually do something instead of being hopeless, so they consider doing something better than nothing even if it's not ideal. Second, they are reviewing the technical specification and finding it sound, but not grounding it in the reality of how users work.

Part of the argument against them is not just that they're ineffective, but also expensive. It's not unreasonable to simply call it snake oil. The visual cue would need to be significantly more prominent - up to par with the red versus green icons of HTTP and HTTPS, respectively - in order to have a real impact. Users would need to have better training and education to come to _expect_ the extended validation instead of merely feeling more assurance when it's present. The system has insufficient penalty for sites which should have extended validation but only present domain validation, and browser-buyin to the concept is fading.

<comment><USER4> > First, they probably want to actually do something instead of being > hopeless, so they consider doing something better than nothing even if it's > not ideal.

Right, once OV and EV certificates are effectively removed from browsers, users such as myself will no longer have _any_ tool to help ensure we are interacting with the entity intend to be interacting with. It is kind of like getting a cold call from your credit card company saying their has been suspicious activity and they want me to authenticate my account with personal details. I always call the phone number on the back of my physical credit card to ensure someone isn't scamming me.

Rather than removing EV certificates as a concept, I would love to see some experiments run by browser vendors to see how users can more readily understand who they are interacting with. But instead, the solution seems to be to get rid of the only option since it doesn't work in its current incarnation.

> Part of the argument against them is not just that they're ineffective, but > also expensive. It's not unreasonable to simply call it snake oil.

I have a hard time understanding this argument. You can purchase an EV cert for $80 a year from NameCheap. The extra cost is because they have people verify that the company details you have provided are valid and that you are an authorized representative of the company. Any company that is more than a solo founder is going to be in dire straights if $80 a year is too much. I mean, are you even going to find a domain name and hosting for less than $80 a year?

In reality though, I don't think much of anyone other than major email providers and financial institutions really need to worry about EV. If a website doesn't have EV, but uses PayPal, I have no qualms. But if I go to long into Fidelity or PayPal and they couldn't be bothered to spent $100 per year to help me ensure I am actually interacting with them, that says a lot to me. I mean, even my small town NH bank has an EV cert. It just makes sense if you are dealing with finances.

<comment><USER2> OV was never really accessible in browsers. Even the vendors pushing these seemed to avoid showing how to identify one (when they would screencap the EV green bar), and probably for good reasons.

> You can purchase an EV cert for $80 a year from NameCheap

I've been through this a quite few times. The cost of the cert isn't the true cost. If I could pay $80 to Lets Encrypt to have every issued cert be EV, I'd do it just to avoid this bikeshed. Every single time I've done it, the validation process has been extremely painful. I feel like it's made up on the spot by whatever offshore person gets asked to do the validation. Documents accepted last year are suddenly not accepted at renewal time. Being denied because my Australian company doesn't show up on a UK business register for example.

<comment><USER5> > avoid showing how to identify one

The certificate policy identifier will be 184.108.40.206.2.2 for OV. You have to look at the certificate details to find it.

I looked into it for someone once. Then I watched in amazement as less technical person insisted on OV certificates.

</comment></comment></comment></comment></comment><comment><USER6> EV is very useful when banks decide to host some parts of their online presence on what sounds like a phishing domain. Think "onlinewebconnect.com", which redirects through "live.logonvalidation.net" (Saxo Bank - they're hip enough to have their own TLD but apparently not smart enough to actually use it for something good) or the various domains banks liked to use for their "3D secure" login process.

It also drives the cost of phishing attacks up significantly. Sure, you can get a confusing cert issued, but if it requires you to _create a new company_ , it's not going to be used in mass phishing attacks.

<comment><USER3> Extended validation _isn 't_ very useful, for exactly the reasons the article explained. Most users don't take advantage of its benefits no matter how technically sound the concept is. Providing users with anti-phishing and phishing-detection tools doesn't mitigate phishing. The way to mitigate phishing isn't to empower the user with sophisticated awareness, it's to eliminate the need for that awareness.

<comment><USER7> Ok so we just removed the "sophisticated awareness" and now we wait for a fantasy/unknown solution. No brainer, right? To me this looks like a bad day for the open internet and a good day for walled gardens(i.e. Apple Store).

<comment><USER3> How exactly did you get from the inefficacy of extended validation certificates (and their subsequent obsolescence) to solidfying moats for walled gardens?

<comment><USER8> The original purpose of an EV cert is to provide a browser UI that tells a first-time visitor that they can trust the website they've landed on. This is a separate goal from TLS in general, which is just supposed to secure the traffic in transit.

Google in particular has no interest in providing such a browser UI. They want users to use Google Search to establish trust instead. "If you're not sure, Google the business name" is common advice to avoid copycat sites. Boy is that a good position for Google to be in! Why would they invest in an alternate solution with a distributed architecture and client-side UI?

Almost all the "best practice" security advice today is centered around protecting existing relationships with sites. "Use a strong password, a password manager, and two-factor-authentication" does nothing to protect a first-time site visitor from a scams. It makes sense for security professionals to focus on the lowest hanging fruit, but the result is web in which first time site visits are perilous and uses get no help at all with that.

<comment><USER3> Yikes there's a lot of (in my opinion) misconceived cynicism here...

 _> The original purpose of an EV cert is to provide a browser UI that tells a first-time visitor that they can trust the website they've landed on. This is a separate goal from TLS in general, which is just supposed to secure the traffic in transit._

This isn't _really_ accurate. Basic TLS (domain validation) provides encryption _and_ authentication - if TLS did not provide authentication in its most basic form, the encryption would not be very secure on its own. Extended validation merely adds further parameters (properties, characteristics, etc) to the server side of the authentication process that already exists in TLS, in combination with administrative work on the part of the certificate authorities.

Then the client provides the UI visual indicators corresponding to the authenticated identity, as you say. But while all of this technically works, _most users don 't bother with checking it._ Security with friction to use doesn't typically provide any security, it just makes you feel like you're doing _something._

 _> Google in particular has no interest in providing such a browser UI. They want users to use Google Search to establish trust instead. "If you're not sure, Google the business name" is common advice to avoid copycat sites. Boy is that a good position for Google to be in! Why would they invest in an alternate solution with a distributed architecture and client-side UI?_

I can trade your flavor of cynicism with my own: certificate authorities don't want TLS certificates to be cheap, so they come up with shiny options such as OV and EV to have something they can upsell.

See what I just did? We can just keep arguing cynically if we'd like, but we don't arrive at any new insight about the actual point. The fact of the matter is that it's largely irrelevant what Google's motivation is, because the efficacy of extended validation (or lack thereof) does not rely on Google (or any other browser's) motivation. And for what it's worth, Google is not the only browser maintainer moving away from EV visual indicators.

 _> Almost all the "best practice" security advice today is centered around protecting existing relationships with sites. "Use a strong password, a password manager, and two-factor-authentication" does nothing to protect a first-time site visitor from a scams._

This is a fair point. It's definitely true that phishing is not as sexy a problem as "technical" security vulnerabilities, and so gets relatively less attention. But a security mechanism only augments security if it's actually used or adhered to. I'm not debating the technical merits of extended validation. I'm stating that it's ineffective beause it's a technical solution to a social problem. The way to resolve that social problem is through more sophisticated education and training. Or more likely, to re-architect the interface and browsing methodology in a way that obviates phishing entirely. Just because one of those approaches seems out of reach doesn't mean we should settle for EV, which in practice doesn't do anything. The only nontrivial users of EV are banks and financial institutions; these are the same institutions who have completely bought into security questions, inability to paste passwords and draconian password complexity requirements.

<comment><USER8> TLS authenticates in a technical sense. The purpose of EV was to tie the technical authentication to existing processes for legal authentication. That's why, for example, EV certs must include the legal name of the company or a registered DBA (note--edited to fix this).

> But while all of this technically works, most users don't bother with > checking it.

Shouldn't that be a UI problem? But instead of improving the usability and utility of EV and OV cert content, browsers are instead just hiding it.

> I can trade your flavor of cynicism with my own: certificate authorities > don't want TLS certificates to be cheap, so they come up with shiny options > such as OV and EV to have something they can upsell.

A lot of people do feel this way. The objection to OV and EV certs has a large cultural component. Browser providers don't like CAs in general. Part of it is because most CAs are not as technically savvy. But yes, part of it is: who is going own identity and authentication on the Web? It's a tug of war with real business implications.

What gets lost in the fight is that EV and OV certs are not just stupid scam upsells. Conceptually they are different from DV certs, and contain different content that could be used to solve real problems for users. Sure--anyone can create a company and register it with a CA to generate an EV cert. But doing so leaves a paper trail that is easier for law enforcement to follow than just a DNS entry for a DV cert.

> The way to resolve that social problem is through more sophisticated > education and training.

This is not how social problems get solved. We didn't provide sophisticated education and training to help people discern real clothing stores from criminals who will rob you; we used the collective resources of society to create processes and records that help us hold business owners accountable if they use their business to commit crimes.

<comment><USER9> Suppose Alice is looking at a web page, [https://example.com/](https://example.com/) which she believes is run by Bob, and Alice types in her credit card number, and then she presses the Charge button and a form submission happens, which means behind the scenes the browser does HTTPS POST to [https://card.example.com/](https://card.example.com/) Let's walk through this:

1\. Alice's browser looks up card.example.com and gets some IP address, it connects to this IP address, with TCP, on port 443 the standard HTTPS port.

2\. It does a TLS handshake with the server that answers, it sends SNI asking for card.example.com, the server sends a certificate and proof that it owns this certificate (in older setups the proof may be implied but let's not worry about this detail)

3\. The browser validates that the proof is correct, that the certificate is acceptable (signatures etcetera) and that the certificate has a Subject Alternative Name matching card.example.com, if anything is wrong it aborts.

4\. Otherwise the browser writes the HTTP POST data over the TLS connection to card.example.com, it gets back an HTTP response body, which it processes as normal, for example, the display body may be a 30x series HTTP redirect back to [https://example.com/](https://example.com/) and that's displayed for Alice.

Now, where in this process did Alice get a chance to verify that her credit card data goes to Bob?

Nowhere. Even if card.example.com has an EV certificate which says the subject's real name was "Bob Limited" that information is meaningless to a web browser and is never displayed for Alice to look at.

Let's suppose we really try hard to help Alice here. When do we show her the "Bob Limited" subject? We only discover it during the HTTPS POST operation, milliseconds before we send her credit card data. Do we... stall everything, and hope Alice can examine the certificate while the transaction waits? Good luck with that, even if Alice is (unlike all normal users) fastidious enough to not just click "Yes, yes, go away and stop bothering me you stupid computer".

<comment><USER8> The EV cert is served with example.com, where Alice can see it.

EV is not necessary for card.example.com because a) it's not a domain that Alice will visit directly, and b) Bob has out-of-band opportunities to confirm that he wants his application to connect to card.example.com.

EV does not provide better technical security than DV, it provides better information for following up on problems. If Alice thinks Bob ripped her off, she can look at the EV cert on example.com to get the legal name of Bob's business and the locality in which it is incorporated, and file a complaint against him. She doesn't need to know about how Bob processes credit cards to do that.

<comment><USER9> But why bake this stuff into the certificate in this scenario?

If Alice is only going to check any of this long afterwards it doesn't need to be part of the X.509 certificates issued for the Web PKI, Alice can check in any number of ways which business it is that she thinks ripped her off.

Of course since she waited until after she was ripped off it may be that it's a company with no practical presence in her country and she can't do anything about it anyway. But EV doesn't make any difference there.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER10> They were pretty silly in the first place. All it did was emphasise what a giant scam the CA business is: either all certificates have undergone meaningful validation, or none have, having higher and lower grades is .. broken.

<comment><USER8> The purpose of an EV cert was to provide the user with trust that the company running the site is a legitimate business. That is different from the purpose of TLS in general, which is simply to secure traffic over the wire. That's why they are different products.

The use case for EV is hard, and CAs did not always deliver on the goal. But instead of working on that hard problem of trust on first visit, most security professionals have decided to ignore that problem and pretend that all certs have ever needed to do is secure the wire. Of course EV certs look silly under that line of thinking, but that doesn't mean it's right or complete.

The industry has basically given up on the idea that there is some way to establish trust on first visit. Which is nuts, because we take it for granted in real life that we can just walk into a brick and mortar store and conduct business without getting mugged.

<comment><USER11> _most security professionals have decided to ignore that problem and pretend that all certs have ever needed to do is secure the wire_

If you want to blame someone, blame the original designers of the current system, who decided certificates had to be a one-size-fits-all solution for _both_ encryption and identity. Also, blame the years and years and years during which people on sites like HN condescendingly insisted that identity was the important part of TLS/SSL, and who more or less said you'd be better off unencrypted than encrypted without ultra-mega-hyper-octuple-verified identity.

 _The industry has basically given up on the idea that there is some way to establish trust on first visit. Which is nuts, because we take it for granted in real life that we can just walk into a brick and mortar store and conduct business without getting mugged._

In real life it's difficult and expensive for me to rent a brick-and-mortar storefront, cover it with the branding and logos of a trusted company, stock it with real-looking products and employees in uniforms, etc. On the web, it takes five minutes and costs little or no money to produce a good-enough imitation of a trusted company's site. Any attempt to analogize between them will fail because of how much lower the barrier is online. Any attempt to say that it's easy in real life, so it ought to be easy online is based on missing this fundamental fact.

Also, we live in an age where it's profitable to cold-call people on the phone and say "I'm the tax authority and you owe money, buy $500 worth of iTunes gift cards and send them to this address", and where the majority of calls that come to my phone use spoofed caller ID to try to scam me.

"Trust on first visit" is really a monstrously hard problem, and I think you're underestimating that.

<comment><USER8> I'm not underestimating how hard the problem is, I'm complaining that people are taking the difficulty as an excuse to pretend it does not exist, or to treat it as unsolvable.

I'm not saying it's easy in real life, I'm saying it's largely solved in real life. There is a big difference between those two ideas.

The difficulty was part of how it was solved. In addition to the physical difficulty of setting up a store, businesses have to be registered and licensed by state and local authorities. The purpose of the EV cert (and the OV cert, really) was to tie web trust back to that same regulatory infrastructure. If you have a problem with a site using an EV cert, you can look up the company info in the cert and contact their local authorities.

<comment><USER11> _The purpose of the EV cert (and the OV cert, really) was to tie web trust back to that same regulatory infrastructure._

Except the only way to get what you want using EV is to force literally every site on the internet to go through the EV cert process. Otherwise, somebody's going to go get a "less verified" cert, set up an impostor site and phish people.

Is that really the world you want? Is that the price you're willing to pay to get it?

<comment><USER8> > Except the only way to get what you want using EV is to force literally > every site on the internet to go through the EV cert process.

No it's not. There are a lot of ways to physically sell things without setting up a retail establishment. You can drag a box out onto the sidewalk and sell sunglasses to people; you can host a yard sale, you can set up at a flea market, you use a classified ad or Craigslist, you can sell through MLM, etc. Customers will calibrate their level of trust based on the experience you provide.

Operating a physical retail store (or a bank branch, or a restaurant, etc) carries with it an implicit promise of trust to the customer, and it's a promise that is backed by social and legal conventions.

So there's a range of experiences and implied trust in physical life, and it's fine if there is a range online. Site operators could choose the level of trust they're willing to invest in providing.

> Otherwise, somebody's going to go get a "less verified" cert, set up an > impostor site and phish people.

That's only true if browsers make less verified certs look the same as more verified certs, which is what they are doing. It's a self-fulfilling prophecy. Now every site looks like a guy with a box on the sidewalk.

<comment><USER11> _That 's only true if browsers make less verified certs look the same as more verified certs_

Given that decades of user research overwhelmingly indicates that the average web user does not understand the components of the browser URL bar, and in many cases those users are completely unaware there even _is_ useful information there, I'm going to bow out of this, because you're now into territory where you need to forcibly educate every single person on earth to understand the URL bar.

(and you're "only" now requiring that every single person who will ever do business of any sort must pay up for an EV cert, but that's actually less of a problem than trying to force people to understand what an EV cert is and how to tell if a site has one)

<comment><USER8> Why are we constrained to the URL bar?

I think people have just developed a weird blindness about the possibilities of user interface in browsers. There's no reason browsers could not have created all sorts of interesting user experiences with the validated business information in EV and OV certs.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER12> Another way to look at this article is: The browsers are killing EV certs.

That seems to be the bulk of the point he's making, EV certs are dead because, especially on Mobile, you can't even tell they are there. He doesn't really, in my mind, support the case that EV certs never were worth anything. I definitely liked to see them when I went to my banks and the like. But I'll admit that I don't remember which ones had them and which didn't, other than that I expected my financial institutions to have them.

<comment><USER13> > But I'll admit that I don't remember which ones had them and which didn't, > other than that I expected my financial institutions to have them.

This is a core point in the article too that you've glossed over: no _one_ knows which websites must have EV information other than a general "hope my bank has one". EV certificates are useless not just because the browsers are dropping them, the browsers are dropping marks for EV certificates because they are useless for actual security.

They were an interesting attempt at security, but like the "take your shoes off at the airport", it only really helped you from maybe blowing up your own foot, tops. Ultimately the only thing that EV certificates were doing was lining the pockets of security theater predators, because despite "reports" they've never really meant anything to the average consumer and most consumers never learned how/where to look for them except sometimes "maybe my bank should have one, I don't know?"

<comment><USER14> This is worse than that, because no one ever wondered if they should have one.

People only notice when it is there.

</comment></comment></comment><comment><USER15> I may be different, but to me it seems that EV certificates are useful for dealing with domain typo fishing. Google.com is pretty short and memorable. However, when I type my bank's address, especially if it is a small bank, seeing the EV certificate gives my more confidence that I did not make a typo in the URL. Given that LetsEncrypt makes if free and painless to set up https if you have control of a domain, the EV certificate just gives me just a little bit more comfort over a DV especially for sensitive information.

<comment><USER16> >seeing the EV certificate gives my more confidence that I did not make a typo in the URL

not really. there's nothing preventing an attacker from creating a legal entity with the same name and legitimately getting a EV certificate.

[https://stripe.ian.sh/](https://stripe.ian.sh/)

<comment><USER17> This is a much easier problem to deal with than trying to make any other strategy useful. The requirements to get an EV certificate can and should be updated, but it's the closest thing HTTPS does to being a useful security measure.

The reality is that good security doesn't scale. If an entity starts specifying a reasonable list of certificates it has directly verified are the trustworthy well-known entities people expect, you have a good trust system. Once you start throwing in an automatically-verifiable system where everyone should be able to participate, phishing is going to happen.

As much as Let's Encrypt helped encrypt the web for free, it also guaranteed that convincingly phishing the web is also free. Making a legal entity and going through the EV process is a level of frustration that isn't easy to handle repeatedly, and very few checks would be needed to be added to EV to make it near impossible for an entity to rebrand and reappear after being banned for misusing it's certificate. Notice that stripe.ian.sh doesn't actually have an EV cert anymore: A system working as designed.

The only way we are going to ever ensure your bank site can't be imitated by some kid in their garage is going to be to create a system that a kid in their garage can't participate in. And the closest thing to that is EV.

<comment><USER18> > Notice that stripe.ian.sh doesn't actually have an EV cert anymore: A system > working as designed.

Comodo has apologized for incorrectly revoking the certificate for stripe.ian.sh and offered a new EV cert.

[https://www.comodoca.com/en-us/about/blog/on-comodo- ca's-rec...](https://www.comodoca.com/en-us/about/blog/on-comodo-ca's-recent- revocation-of-an-ssl-certifi/)

In fact, many browser security developers would disagree with your assessment:

[https://groups.google.com/forum/m/#!topic/mozilla.dev.securi...](https://groups.google.com/forum/m/#!topic/mozilla.dev.security.policy/NjMmyA6MxN0)

<comment><USER17> I have very little faith in the opinions of "browser security developers" at the moment on account of browser security being a joke. Their focus has been on technical security but lacks practical security. Yes, stripe.ian.sh exists, but have you ever seen a truly malicious use of EV?

Browser security developers concern themselves with arcane exploits of sandboxes while they don't mind nearly that every browser extension has full read/write access to everything people see and do.

EV has flaws, but it's better than literally anything else. We shouldn't be promoting HTTPS if it isn't solving this, the other problems it attempts to solve are mostly overstated problems. Because phishing is a vastly bigger threat than MITM.

EV has theoretical flaws but solves real problems, HTTPS without it has real problems and largely solves theoretical flaws.

<comment><USER19> > _but have you ever seen a truly malicious use of EV?_

Assuming there hasn't been, I think this just supports the idea that EV certs aren't useful: the bad guys don't even feel the need to try to use them maliciously!

<comment><USER17> Or the return isn't worth it. Malicious actors have to assume that any given domain, certificate, URL, etc. will get blocked or shut down by the security industry, so being able to cycle those endpoints is key. EV is not easy to automate/cycle, and can also be more cost prohibitive, so each cycle is less profitable as well.

That's my point: Systems that don't scale are less profitable to attempt to abuse for malicious ends, because more time and effort has to be invested into any given effort, and ideally, there are actual humans involved in the process which catch discrepancies.

The other reason you may not see a lot of attempts to find exploits in EV (apart from Ian) is that most of the actors sites want to pretend to be aren't using EV either. If you want to fake yourself as Google, EV isn't going to help you since Google doesn't use it.

I would argue the claim "bad actors aren't trying to abuse it so it isn't effective" to be silly, as that claim would apply among all methods that bad actors can't meaningfully abuse.

</comment></comment></comment></comment></comment></comment></comment><comment><USER20> It's got more credence coming out of Troy's mouth than, say, a random commenter's like mine, his somewhat bit too scathing snark notwithstanding, but on the "stripe.ian.sh" thread a few months ago I observed [1] that EV, or rather, people's mental model of the trust that EV confers is broken. People typically care about whether the site they arrived at was the one they were intending to visit, which the computer can't possibly know without additional input, but EV has attained a role of serving as a flawed signal of such, because the browser bar said something that doesn't look alarmingly different.

What we're seeing now is the convergence of forces that are pushing short- lived, automatic DV certs and players who are keen on de-emphasizing EV's imperfect role as a destination surety signal.

Big sites can get by with DV because people trust big sites by fiat, just by mental associations they already have to a URL. There's no benefit to Facebook having an EV cert, because literally everyone who'd want to visit Facebook knows Facebook's URL. User error about entering credentials on the wrong site -- accidentally due to typosquatting, or through leading such as phishing -- is better mitigated in other ways: multi-factor authentication (especially unproxiable such as U2F); not by making the high-profile site pay thousands of dollars for a text string in green, when there's users who fall victim to phishing from bizarre domains too.

[1] [https://news.ycombinator.com/item?id=15904513#15909273](https://news.ycombinator.com/item?id=15904513#15909273)

<comment><USER21> _It 's got more credence coming out of Troy's mouth than, say, a random commenter's like mine, his somewhat bit too scathing snark notwithstanding_

If a CA flogs a guarantee for very expensive certs, but fails to explain what it entails. Then bloviates about nerds on the twitter account of the CEO to then block Troy (who, once again, asked a super legitimate question) then they not only deserve all the snark slung into their general direction.

No, they deserve to fucking die!

</comment></comment><comment><USER7> I actually found EV useful especially when logging in financial websites. Of course most people can't make the difference between http and https but I thought this issue will only be fixed by time.

<comment><USER22> That's actually how I found out my Lenovo was doing MITM a few days before the whole Superfish debacle exploded on the net. I went on Bitbucket (I think) and noticed something seemed different, I realised it wasn't showing an EV certificate: I dug deeper and saw that the issuer was suspect.

I feel that EV certificates do have their use for high-worth targets (banks and so one). Getting one is not trivial and definitely not scalable. Maybe they are a bit overpriced, maybe the certificate industry is kind of sketchy, but that's other debates.

</comment></comment><comment><USER23> I get that it's unreasonable to expect users to distinguish EV from DV certs.

But a machine should be able to distinguish. There should be an Expect-EV pin header, just like HSTS and Expect-CT. That way you can be sure the certificate wasn't issued via DNS hijacking.

<comment><USER11> The root problem is SSL/TLS was largely promoted, for years and years, as conflating two concerns:

1\. Can an arbitrary third party eavesdrop on my communications?

2\. Am I communicating with who I think I'm communicating with?

It is now extremely easy to handle use case (1). Use case (2) is still genuinely hard, because even extremely technically literate security-savvy people can still easily be phished (my current go-to example is this talk: [https://www.youtube.com/watch?v=ZjW12K0IHgo](https://www.youtube.com/watch?v=ZjW12K0IHgo)).

Compounding the problem, many people insisted, for many years, that use case (2) was the overwhelming majority of all the value of SSL/TLS, and use case (1) was at best a tiny microscopic fraction of a fraction of a fraction of what was useful about SSL/TLS.

Lest you think I'm exaggerating: I've spent years arguing with people, including right here on HN, about this, and being condescendingly told that identity verification is the crown jewel, and that if I'm not going to make use of that then I might as well literally just go back to plain unencrypted HTTPS, because apparently that's actually better than using SSL/TLS without identity verification.

Also, I really recommend watching that video I linked. It's a security engineer at Stripe, talking about how she ran some pretty successful campaigns within the company. Whatever you may think of them, they're not unlettered philistines. But even things like your "Expect-EV" wouldn't have helped -- she cites an example of people noticing their password manager wasn't autofilling, because it knew they weren't on the expected domain, and then _users manually copy /pasting the credentials out of their password manager anyway_. There just aren't any easy "just do X" technical solutions here.

<comment><USER24> > she cites an example of people noticing their password manager wasn't > autofilling, because it knew they weren't on the expected domain, and then > users manually copy/pasting the credentials out of their password manager > anyway

One big reason people do that is because probably 99+% of the time their password manager fails to fill the fields is not because it is the wrong site.

It is almost always because the site has done something with its fields that is either preventing the password manager from finding the fields, or is blocking it from filling them (often intentionally).

<comment><USER11> _Why_ people bypass the password manager's domain checks isn't relevant.

The issue is that credential stores which know how to recognize the "real" version of a site aren't going to achieve the level of effectiveness we'd like to have against phishing.

</comment></comment></comment></comment><comment><USER25> I actually kind of agree that EV certificate inspire more confidence when buying something on a dodgy website that you never heard about. But for that one needs to be tech savvy enough to even recognize what an EV certificate is and how it is different from a DV cert, and I am sure that even most developers aren't sure exactly, let alone the wider population. So I doubt it gives much benefit to any website.

<comment><USER8> If only there was some common, easily visible browser UI element that told users when an EV cert was present, so they didn't have to understand the differences between certs.

</comment></comment><comment><USER26> next: code signing certificates under Windows

a lot of B.S. there too

<comment><USER27> Yes. Two years ago I bought EV for code signing to avoid Microsoft Smartscreen.

The whole experience left a stale impression: we were then in the process of switching to non-profit and already dissolved the for-profit company but got the EV for the old company anyway! Clearly the CAs have a moral hazard: if they check too thoroughly they will sell less certificates, so it is not in their interest. In my case they blatantly asked me to provide bullshit evidence for the dissolved company!

No wonder that Microsoft Smartscreen doesn't seem to treat EV certificates as all encompassing truth of existence of something. We had to jump through some more hoops to satisfy Smartscreen, the certificate alone was not enough.

</comment></comment><comment><USER28> EV certs are a useful as a barrier-to-entry when you do cert pinning against roots/intermediates.

<comment><USER29> Except that HPKP is being deprecated by Chrome ([https://groups.google.com/a/chromium.org/forum/#!msg/blink-d...](https://groups.google.com/a/chromium.org/forum/#!msg/blink- dev/he9tr7p3rZ8/eNMwKPmUBAAJ?hn)). And I'd suspect other browsers will follow.

<comment><USER30> When pinning CAs instead of certificates, you'd use CAA instead of HPKP.

<comment><USER31> CAA isn't restricting acceptance of certs, it's restricting issuance, assuming the attempted issuer is compliant, competent, and that your domain didn't get hijacked.

</comment></comment></comment></comment><comment><USER32> no need to RTFA! EV certs were nonsense from the start.

</comment><comment><USER4> Google seems intent on creating a more confusing UX in regards to EV certs as EV looks more similar to Non Secure than secure sites in Chrome 69.

For now this has given me the impetus to ditch Chrome. All of the other major desktop browsers still provide useful UI for EV certs. I'm less inclined to deal with finances on mobile through a website anyway, as every financial org I've had to deal with has an app, and Apple ends up being the gatekeeper in that realm.

Hopefully there will be some sort of push for useful additions to certificate security coming out of Google, as right now they seem more determined to just be undermining things.

<comment><USER33> That is an interesting way to describe the most effective mover in all of TLS security. No company has done more to improve it. We owe to Google, in at least a substantial way, if not always entirely:

* The dis-trusting of basically every skeezy dis-trusted CA.

* The adoption of TLS 1.3.

* Certificate pinning.

* HSTS preloading.

* The modernization of OpenSSL.

* The Heartbleed attack that prompted the modernization of OpenSSL.

* Certificate transparency.

I'm rattling these off my head and certainly forgetting something. Obviously, if you broaden the question to _everything_ relevant to browser security, the list gets much longer.

<comment><USER9> I'm definitely not giving you "dis-trusting of basically every skeezy dis- trusted CA" for Google.

All the heavy lifting continues to be done by m.d.s.policy, which is Mozilla's, not Google's if it's anybody's. I used to want to believe that the (behind closed doors) other root programmes also had their own effective mechanisms. A few years of working with m.d.s.policy and watching absolutely nothing else making any difference disabused me of this notion. It gets done in public or it doesn't get done at all, and m.d.s.policy is where it gets done in public.

Does Google have (mostly in the form of Ryan Sleevi who is a Google employee) a contribution to m.d.s.policy? Sure they do. But there are quietly also people from Microsoft and others paying attention, it's just that Ryan is much noisier, for good or bad.

If I was going to single out a _person_ for this work it would be the late Gervase Markham, who was a Mozilla employee. The big list of problems at StartCom is Gerv's list, for example. I think even the idea to go after auditors not just CAs was Gerv's idea.

<comment><USER33> I'm really not interested in whatever weird personal problems you might have with Ryan Sleevi, sorry.</comment></comment></comment></comment>


Show HN: Some non-trivial Covid-19 charts - <AUTHOR> https://cv.moskovski.com/ <comment><AUTHOR> I couldn't find some essential charts about the coronavirus, so I made my own.

More charts are in the works.

No ads, no collecting of personal data (sans GA), just charts.

Let me know, if you'd like to see some other representations there.

</comment><comment><USER2> Nice use of apexcharts.

I'm curious whether/why you chose it over d3?

</comment><comment><USER3> What does active refer to?

<comment><AUTHOR> Confirmed cases - (deaths + recovered cases)</comment></comment>


If you want to learn Lisp, be ready to meet the scowling faces (and don't even think about mentioning PG in #lisp) - <AUTHOR> http://classbug.com:3000/post/main.html <comment><USER2> Chapter 3 of The Structure and Interpretation of Computer Programs is a great discussion of mutable state (make sure you read the previous chapters, though, or at least the first chapter and The Little Schemer).

A functional-ish way to run a game world simulation:

(define (run-game)

  (define (make-initial-world) ...)

  (define (get-input) ...)

  (define (wait-for-next-frame) ...)

  (define (update-world world input) ...)

  (define (game-over? world) ...)

  (define (run-step world)

    (display-world world)

    (wait-for-next-frame)

    (if (game-over? world)

      'bye

      (run-step (update-world world (get-input)))))

  (run-step (make-initial-world)))

It's not _purely_ functional: the calls to display-world and wait-for-next- frame are made for their side effects. But they are not mutating any program state, so this is good enough. You _can_ try and get more 'pure' with Haskell and monads when you feel brave, but there is plenty to grok before going there.

Let's study the parts:

make-initial-world: self-explanatory; I'll only add that this object is held 'in the stack' and (conceptually) never overwritten.

get-input returns the player actions, game time, and whatever other 'delta' data is relevant for the current update. You can think of the input over a whole game session as an indefinitely long list which you iterate over, one element (game update) at a time. You can indeed run automated tests replacing this data with an actual list; the program shouldn't notice the difference.

wait-for-next-frame causes a time delay that is conceptually irrelevant to the rest of your logic (you deal with system time, if at all, in the body of (get- input)). In test situations, you should be able to just replace this with a no-op.

game-over? tells you whether the player has quit. I make it a function of the world and not the input because the input is meaningless without the context that the world object represents.

(By this time you may have noticed that I'm being a bit sloppy with terminology, for color and simplicity. 'world' is not only the game world, but also the program state (e.g., is the user in a configuration screen?). Similarly, 'game over' is not the end of one game/'match' but of the playing session. The principles are the same.)

run-step is just a loop that keeps updating and displaying the world state until the game is over. Don't be scared by the recursive call to run-step itself; that's the idiomatic way to loop in Scheme, and implementations are required to handle it efficiently (google for 'tail recursion').

The crux of the problem is in update-world. This is an ordinary function that takes the world and the input for this game tick, and returns the world corresponding to the next tick.

You'd think there are only two options here: either modifying the existing world in place- definitely non-functional!-, or building a new one from scratch, which sounds inefficient.

Actually, there is much more to be said about purely functional data structures. In a nutshell, you can often make a new world that shares most of the data with an old one, so only the delta is created anew. References to the old world will not be affected at all by the new one, so you can keep as much history of your game as you have memory for. As a basic example, in Lisp you do this with lists all the time. But it can get more complex:

<http://www.cs.cmu.edu/~rwh/theses/okasaki.pdf>

(This thesis was expanded upon and published as a book by the same name, with examples in ML and Haskell. If someone knows of more resources about this, please let me know.)

Depending on the ratio of changing-data-per-frame versus total data in your application, this may be an interesting option. The learning curve is considerable, though.

But note that when update-world is called the old world will never be used again (most games don't keep the state of every past frame). So in this case it's OK to modify the old world in place and use that as the return value. The rest of the code doesn't care; again, you might as well be iterating over a stream of worlds (with the same desirable implications for testing).

If you do mutate the world, though, you may want to make it explicit by saying something like

(define (run-game)

  ...

  (define (run-step)

    (update-world! world (get-input))))

    (display-world world)

    ...)

  (define world (make-new-world))

  (run-step))

This is harder to test and more work if you want to switch to a purely functional update-world later, but there's less risk you or others will try and use (or modify!) a world after it's been updated.

Part of the calculations _within_ update-world can still be done in a functional way, and where you need to mutate state, you can often hide that behind a functional interface, with varying degrees of hygiene.

The bottom line is you don't need religious avoidance of mutable state to benefit from functional programming at all; you strive for stateless code by default, you compromise where it makes sense, and you try to minimize the impact of such sins by wrapping functional interfaces, or placing warning signs, around them. The mere habit of paying attention to these matters will improve your taste.

There is a lot more to be said about this, but I hope you can already see how this is not an easy topic to introduce, out of the blue, via IRC. In all fairness to the Lisp folks, I have to say the question about Python packages was much more concrete and easier to address without both sides losing patience.

<comment><AUTHOR> _Great_ info, _great_ detail. Thanks so much for your time. I've never even considered looping through recursion. The construct-a-new-world vs modify-the- current-world situation was exactly the problem I was thinking of. And you followed it up with a paper, if I wanted to learn more. It's hard to emphasize how perfect stuff like this is for a newcomer to Lisp. There should be more snippets like this. You should write a tutorial somewhere.

<comment><USER3> Scheme has kind of a different culture from Common Lisp. Most of the material is oriented towards students in order to teach the timeless stuff in computer science.

I learned C before I learned any functional languages and I regret it to this day. It took me _years_ to undo the damage. I really dug myself into a hole, too, by learning all about pointers and low-level stuff like that before I ever knew what Python, Ruby, etc. were.

</comment></comment></comment><comment><USER4> I was lurking on #lisp for most of today and it seems to me you're being a bit oversensitive. You asked about packages at 14:23. Several people tried to figure out exactly what you were asking, including gigamonkey (the author of PCL!). At 14:26 rahul mentioned "asdf" which is probably what you are looking for. If you had at that point Googled 'asdf lisp' and felt lucky, you would have gone straight to this page: <http://www.cliki.net/asdf> , which contains a script to automatically generate packages as well as some other Windows- specific information that you were asking about. Otherwise, at 14:39 in the complete log, jamesjb pointed you to a tarball containing an example system. Not too shabby IMHO.

Incidentally, <http://www.cliki.net/IRC> mentions #cl-gardeners and #lispcafe as more novice-friendly than #lisp, though I've never been too troubled by my own experiences there as a newcomer to Lisp.

Lastly, you might want to check out <http://www.google.com/coop/cse?cx=012679172708151972086%3Aeg1jtvm_dlk> (hopefully the link did not break) -- it's a custom Google search that searches a set of 20 Common Lisp resources. It's pretty useful.

Good luck.

<comment><AUTHOR> Thanks for the awesome resources. I'm honored that the author of a book took the time to speak to me. If I was being oversensitive though, the average newcomer has no chance.

</comment></comment><comment><USER5> Just to play devil's advocate here:

I'm a frequent contributor on The GWT newsgroups and it's very easy to get annoyed. Specifically, java suffers from a lot of wannabe programmers. For those of you liking the ambiance amongst Ruby and Python groups, you should do yourself a favour and stop advocating the use of Ruby/Python in colleges.

The influx of those idiots will kill your newsgroups and your IRC channels -very- quickly.

Now, as to the LISP community, they aren't usually bothered too much, I'd gather, with wannabees. However, where they do waltz I'm, I can imagine they'll be mentioning Paul Graham's essays. Result: short fused posters take the piss out of you.

And, you have to admit, Paul Graham's ramblings on LISP are a bit out of left field. The problem with promising magical performance with any one programming tool is that you create expectations. I'm fairly sure the expectations created by PG are waaay out of proportion of what you can reasonably expect a functional programming newbie to do in the span of a couple of months.

This isn't an excuse or anything. The chat logs are certainly horrible. Just trying to figure out if I can explain why this is happening.

<comment><USER6> Can you give me an example of a specific paragraph of rambling you consider to be out of left field?

<comment><USER5> I'm referring to the tales of orders-of-magnitude flexibility and productivity enhancement, mostly the "Beating the Averages" essay, in other words. Here's a fragment that seems to promise almost magical productivity:

It must have seemed to our competitors that we had some kind of secret weapon-- that we were decoding their Enigma traffic or something. In fact we did have a secret weapon, but it was simpler than they realized. No one was leaking news of their features to us. We were just able to develop software faster than anyone thought possible.

<comment><USER6> That's out of left field? We were writing code in Lisp, with a read-eval-print loop to test stuff, and they were writing code in C++ with "builds."

There's nothing preposterous in claiming we could implement a serious feature in a couple hours. A lot of people could today with Ruby or Python. But there were no Ruby or Python at the time I'm describing. (An early form of Python existed, but few used it.)

</comment></comment></comment></comment><comment><USER7> Don't forget

<http://groups.google.com/group/comp.lang.lisp/browse_frm/thread/88a36fb2c239a44e/89405e202723a377>

<comment><AUTHOR> Holy jeez, that's way worse. I guess I should consider myself lucky.

</comment></comment><comment><USER8> You should pick up a copy of The Little Schemer. It's entirely Socratic, assumes no background knowledge, and is probably one of the best books ever written on any subject. And it just happens to be on Scheme, so all the better.

And while Scheme varies in syntax, the concepts are the same.

<comment><USER9> Great call, Alex. That's one of my favorite books ever. I blogged this here: <http://herdrick.blogspot.com/2006/03/what-all-books-ought-to-be.html>

<comment><USER8> Good post. The only other Socratic book I own is "What is Calculus about" by W.W. Sawyer. It's more loosely Socratic though. There are paragraphs of text interspersed with questions that either ask you to look for a pattern, or else follow a statement to its logical conclusion.

Not as good as The Little Schemer, but it's still cool that you can learn traditional (non-lambda) calc knowing only addition and subtraction.

</comment></comment></comment><comment><USER10> It often feels like the lisp way is to figure it out yourself, at any cost, and without any external help. For whatever reason the community feels skewed towards egotistical hackers without much sympathy.

I have enjoyed working with CL, and built several large projects in it, but the packaging is a serious pain. At some point you accumulate sufficient knowledge that you can use the different packaging systems, but until then you are essentially sol.

A number one complaint about CL is the lack of libraries, but I think the real issue isn't that the libraries don't exist, but that installing them often isn't worth the effort. C'est la vie, but its still a pity.

<comment><USER11> Can you clarify why you think it's not worth installing the libraries?

</comment></comment><comment><USER12> Palish- I sympathize you. I recently read PCL and started to code a project with it. I have a pretty firm idea of where I wanted to go and ran into the same issues with ASDF that you mention. Fortunately I was on linux so I was able to fix them quickly. Still I was just fed up with a lot of the unclean syntax that I had to write to make stuff work. No one was sympathetic with my viewpoint on #lisp and they all said there was no such thing as "clean and consistent" code when I argued that I would use Arc if it was more clean and consistent than ANSI CL. I came to the conclusion that the community sucks and I don't want to be apart of it, even if their language is better. Anyway to celebrate my decision I went over and coded some rubini.us . Cheers.

<comment><USER10> So you went into a programming language's IRC chatroom and began arguing that a non-existent language is better then theirs. I don't really envision many language enthusiasts responding well to that. Is the next step is for us to debate with pg that Fortress is better than Arc?

<comment><USER12> I referenced that point out of context.

Someone asked, "Is there any demand for Arc?", After people were joking about the 'Invisible Arc.' I said, "If it is more clear and consistent, I demand it." I was merely stating my demand, not arguing with them that Arc is better. I don't know if Arc is better, but I know that if the Community of Arc is better than #lisp that would be a great start.

<comment><USER10> Sorry, it just seemed a mite too easy. :) Its pretty hard to find a community worse than lisp, but a big part of that is that lisp is at a very different stage of its lifetime than almost any other language out there.

Python/Ruby/Perl/TclTk et al are very young, and tend to be much more friendly (interestingly many feel that the Ruby crowd is getting a bit antsy these days, an acceptable lisp afterall? never). I'm hard pressed to explain why C is still relatively friendly, but I suspect it is in large part because there are many more C programmers, many more new C programmers, and that C finds people, whereas people find Lisp.

</comment></comment></comment></comment><comment><USER13> How To Ask Questions The Smart Way

<http://www.catb.org/~esr/faqs/smart-questions.html>

I didn't read the whole transcript, but the above advice is a nearly foolproof formula for getting good answers.

</comment><comment><USER14> Well, you're not the first one to complain about it: <http://social-problems- of-lisp.blogspot.com/>

But personally, I've found that if you post a question to the c.l.l. newsgroup about how to do something specific, you'll get good replies.

It's the more theoretical and philosophical type of posts which wind up attracting the trolls en masse.

</comment><comment><USER15> You made assertions that possible things were impossible, and asked how to do intrinsically non-functional things in a functional way.

I think you experienced a typical IRC reaction of "annoy the newbie because it's easier than answering him". It seemed to work. I've seen it in non-Lisp channels too.

You need to store things on the heap or on the stack, there is nowhere else. When you're thinking in objects, program in objects. To think in objects but then try to write functionally is going to cause you difficulty. You can write procedurally in Lisp, without OOP, it's not just a choice between OOP and FP. Lisp programmers treat these as tools, not lifestyle choices.

<comment><AUTHOR> _I think you experienced a typical IRC reaction of "annoy the newbie because it's easier than answering him". It seemed to work. I've seen it in non-Lisp channels too._

Hell yes it worked; that's why I wrote this article. The problem with the Lisp community is that it's the _first_ reaction, not the last. You won't get this on #gamedev. You'll either get a "Google it" or a helpful response.

I also asked if Lisp constructs could be stored on the stack, _instead_ of the heap; not whether they could be stored in some magical place that doesn't exist.

<comment><USER16> Yeah, I've seen the pattern. Part of the problem is, I guess, that Lisp has long history and stable user base so that the newbie/expert ratio is much lower than other languages; and (a) experts tend to forget how they were like when they were newbies, or (b) even they remember, there weren't such a thing like irc back then and they figured out most by themselves, so they expect a newbie nowadays can do the same thing.

However, another part of the problem, which I think is larger, is that the way of functional thinking is _so_ different than the way of procedural thinking, and it is simply impossible to tell concisely "this is the functional way" (except very abstract statement like "avoid side effects"). If the asking one only has procedural background, his very _question_ often doesn't make sense when viewed from the functional world; and we cannot answer a question which is not really a question.

Take one example: You asked about stack and heap. Probably you assumed a specific storage model, used mainly in C, C++, etc. However, in many functional languages, the extent of objects are just infinite by default, conceptually---and you just let the compiler to figure out which objects can be stack allocated and which should be heap allocated. Or, even a compiler can allocate _everything_ on stack first, and when stack is popped or becomes full it moves live objects into heap, effectively using stack as a nursery of objects. It all depends on implementations, not the language. See, just asking "how to put an object on the stack instead of a heap" doesn't really make sense, except you are talking about a specific optimization technique on a specific implementation (in which case you should've already known the language and quite deeply about the implementation.)

This is just an example. Treating states, when to use mutation, how to model I/O, ... all require very different views.

I program in Lisp/Scheme both for work and hobby, and I feel sorry about your experience. If you still think giving a try to the functional way, another path may be to taste a few other functional languages (Haskell seems to get quite attention recently, and ML claims very fast); then you'll get the perspective of procedural vs functional ways, instead of (all other languages) vs Lisp.

</comment></comment></comment><comment><USER17> Has anyone here had any experience using newlisp? There are things I don't love about it, like the lack of backquote syntax, but the community seems a lot friendlier than what palish has had to deal with. That being said, my experience with comp.lang.lisp hasn't been bad. I posted a simple question about destructive functions there a while ago and got a helpful response pretty quickly.

<comment><USER18> NewLisp is dynamically scoped. That's a showstopper for many people who have any experience with dynamically-scoped languages (eg. Emacs Lisp, Maclisp).

</comment></comment><comment><USER19> I had much the same experience myself in the channel, though after much brow beating I did eventually get my questions answered.

</comment><comment><USER20> The famous books are not good for beginners.

This one is very good for beginners: <http://www.cse.buffalo.edu/pub/WWW/faculty/shapiro/Commonlisp/> In fact, that one is the one that finaly teached me Lisp.

</comment><comment><USER21> I think the way to do this functionally is the Haskell way with Monads: <http://en.wikipedia.org/wiki/Monads_in_functional_programming>

Having used Haskell (which is purely functional) to write a compiler for a CS class, state is mostly kept by passing it around and using recursion. It's hard to explain if you don't know Haskell, however the other way is to use Monads. I can't explain them, because I don't understand them completly myself. Anyhoo, good luck.

</comment><comment><USER22> If you want to learn a functional programming language that comes with a friendly on-line community, try Haskell. The people at the Haskell IRC channel and haskell-cafe mailing list will criticize you if you say something that just isn't right, but they are also relentlessly friendly to newcomers, they like to spend some time working on educational materials that explain their latest type system hacks, and there are always some of them around.

</comment><comment><USER23> There's a nice group called a comp.lang.lisp also accessible through google groups <http://groups.google.com/group/comp.lang.lisp/topics> if you have any newbie question ask it there and mention that you're newbie. There's a lot of people who will answer, sometimes even in a less than minute.

Slobodan Blazeski

<comment><USER24> Hi fireblade!

Yes comp.lang.lisp was very useful to me for the last year. Too bad the group is not available on gmane, and the full archive is only in google, but if you have an NNTP provider (www.motzarella.org for example) you can read it with your newsgroup reader, although you get only the messages from the last month.

Dimiter "malkia" Stanev.

</comment></comment><comment><USER25> I have to say, I'm not that sympathetic. If you are using open source software, you can't expect free support, and you definitely can't expect immediate free support. Plus, it actually looks like you got each of your questions answered within an hour, which is pretty impressive actually.

<comment><USER26> The point of open source software is to act as an alternative to the proprietary stuff out there. Therefore, you _can_ and _should_ expect free support. It's in the best interests of the project to have more people use it.

<comment><USER25> I understand that it is in the best interests of an open source developer to give support for his software (assuming he wants people to use it), but he's in no way obligated to do so. Some people just develop software for fun and make it available to the public as an afterthought in the hopes like minded people will find it useful. I know with the personal projects I've released as open source, although I fixed bugs and responded to requests when I could, it was my goal to give prompt technical support.

<comment><USER26> _Some people just develop software for fun and make it available to the public as an afterthought in the hopes like minded people will find it useful._

That's true. But this is a programming language we're talking about. The goal is to create a good implementation and part of that is having good support. Does a programming language exist if no one uses it?</comment></comment></comment></comment>


Azure Repos – unlimited, cloud-hosted private Git repos for your project - <AUTHOR> https://azure.microsoft.com/en-us/services/devops/repos/ <comment><AUTHOR> Though Azure Dev Ops was discussed elsewhere, the unlimited private Git repos part was not really discussed.

[https://docs.microsoft.com/en- us/azure/devops/repos/git/limi...](https://docs.microsoft.com/en- us/azure/devops/repos/git/limits?view=vsts)

The limit of 10GB per repo is pretty generous.

However, the pricing page ([https://azure.microsoft.com/en- us/pricing/details/devops/azu...](https://azure.microsoft.com/en- us/pricing/details/devops/azure-devops-services/)) doesn't mention unlimited private repos. It just mentions unlimited public repos.

It would be great if any of the Azure people on Hacker News can clarify if private repos are indeed free or not!

Also, are free private repos limited to only 5 members or unlimited number of project members are allowed to access the free private git repos?</comment>


What Is Gaussian Curvature? - <AUTHOR> https://bastian.rieck.me/blog/posts/2019/curvature/ <comment><USER2> It's a nice article and all, but it can never reach the greatness of this overly enthusiastic backtothefutureesque professor explaining curvature with a slice of pizza.

[https://www.youtube.com/watch?v=gi- TBlh44gY](https://www.youtube.com/watch?v=gi-TBlh44gY)

<comment><USER3> It's Cliff Stoll, not just some wacky guy. He is extremely famous among people who were interested in computer security in the 90s. I know that's not the sense of "hacker" that "hacker news" refers to, but still.

<comment><USER4> Yes. He wrote _The Cuckoo 's Egg_ for one. My uncle gave me the book when I was a kid. The first Java program I wrote was a sequence generator for the Morris Number Sequence [2] given to Stoll by Robert Morris Sr at the NSA: "What is the next number in the sequence 1, 11, 21, 1211, 111221?"

[https://en.wikipedia.org/wiki/The_Cuckoo's_Egg](https://en.wikipedia.org/wiki/The_Cuckoo's_Egg)

</comment></comment></comment><comment><USER5> Roger Penrose gets to this topic early in his book 'The Road to Reality': [https://www.goodreads.com/book/show/10638.The_Road_to_Realit...](https://www.goodreads.com/book/show/10638.The_Road_to_Reality)

<comment><USER6> Also covered by Greg Egan in Chapter 2 of _Diaspora_ , with some accompanying drawings here. [https://www.gregegan.net/DIASPORA/02/02.html](https://www.gregegan.net/DIASPORA/02/02.html)

</comment></comment><comment><USER7> I'm fascinated by these things but afraid of the formalism involved in the papers that define concepts and prove things. Am I doomed to only enjoy math through the generosity of people like the author? Or is there a way for me to dive into math without the help of an actual mathematician using only books?

<comment> 1e-9 You can absolutely learn math on your own. Many of the most well-known mathematicians, engineers, and scientists were largely self-taught. Examples include da Vinci, Watt, Edison, the Wright Brothers, Heaviside, Ampere, Boole, Galileo, Pascal, Leibniz, and Ramanujan. The learning materials available to those guys were vastly inferior to what we have today. In fact, you could take yourself very far using nothing more than Wikipedia coupled with a divide-and- conquer approach. If you want to understand a topic, do a Wikipedia search on it. There are usually some good references and links at the bottom of the page that can help with further background and intuition. Never be intimidated by the complexity. Every complex topic can be broken down into simple, easy-to- understand pieces. For every subtopic in the description that you don't understand, click on its link, read, and repeat. Eventually, your subtopic dive should reach a low enough level that you can grasp the concept and use it to understand the previous higher-level topic. For each concept, you should develop an intuitive understanding that goes along with the formalism. Try to visualize every concept in some way. Use mental animations, graphs, sounds, colors, etc. One of the tricks is that you should only focus on learning a small number of new concepts every day (maybe 5 to 7 at most). A night's sleep will help you consolidate those concepts and build on them. For even the most accomplished mathematicians, there are papers that they don't understand at first glance. They must go through their own divide-and-conquer process to grasp unfamiliar concepts.

<comment><USER8> I have been semi-diligently (4-5 hours/week as adult life allows) following this approach coupled with working my way through math texts. Although I zero problem grasping concepts and parsing propositions and examples, I find it very difficult to solve end-of-chapter problems. No more than 4 or 5 problems a week, and hence my advancement is agonizingly slow.

I started with Spivak & Apostol but reverted to Riley and Hobson's Foundations text because I was struggling too much with the A&S's problems. Given that I did very well on symbolic-logic proofs in an undergrad course, I figured it would be easy enough to get into math if I had diligence and sincere interest. After having been a 'D' student, my recognition of arithmetic and algebraic expressions and manipulations is hopelessly sub-par. Even many of the R&H problems are beyond my grasp.

My approach has been informed by a sincere desire to engage with mathematics (one I unfortunately did not have through my formal education) as well as several "How do I self-teach maths" threads on HN, Reddit, and /sci/. Previously I had chalked up my poor grades to an undisciplined, unmotivated youth. Now I'm beginning to suspect I may simply not have the requisite intelligence, or am at least outside the age where I had enough time and neuroplasticity to pick math up in earnest.

<comment> 1e-9 Given that 1) you have zero problem grasping the concepts and understanding the examples, and 2) your difficulty is in solving the end-of-chapter problems; I think it is almost certain that your issue is one of making small mistakes that throw off your solutions (for example, didn't change a plus to a minus sign, left off a term, made an incorrect assumption, etc.). You just need to learn how to double-check your work and figure out where you went wrong. This is a skill that everyone doing nontrivial math has to learn. In a formal learning environment, you constantly get feedback on your mistakes through the grading process, which you obviously don't get when self-learning. My advice is to work the example problems before looking at the solution. After you have worked it yourself, you can then easily see where you went wrong. You should also get books of solved problems that let you practice this more extensively. There are problem books for pretty much every undergrad math topic as well as some grad-level ones. A lot of textbooks even have solution manuals that will show you how to solve the end-of-chapter problems in the textbook. An Amazon search with the word "solutions" and whatever math topic you want should turn up many examples. With practice, you learn how to detect errors and rectify them even when there is no solution manual.

</comment></comment></comment></comment><comment><USER9> So the outside of a sphere is convex (positive curvature), a saddle is concave (negative curvature)... and the inside of a sphere (AKA a concave mirror/lens) is also convex (positive curvature)?

<comment><USER10> There is no "outside" or "inside" when you're talking about Gaussian (intrinsic) curvature. "Outside" or "inside" are about how the object is embedded in space, but Gaussian curvature is independent of how (or even if) the object is embedded in space.

<comment><USER9> So Gaussian curvature reuses the words "convex" and "concave" to mean things entirely different from the everyday/lens usage?

<comment><USER10> _> So Gaussian curvature reuses the words "convex" and "concave" to mean things entirely different from the everyday/lens usage?_

The everyday/lens usage is talking about how the surface is embedded in a higher dimensional space. Gaussian curvature is not. So you should not expect the meanings in the two cases to be the same.

</comment></comment></comment></comment><comment><USER11> Can someone connect or point to a connection between this and the measure of curvature of the universe? Im curious what interior angles we're referring to (or equivalent) in 4D spacetime.

<comment><AUTHOR> In 4D, we cannot use triangles directly (we could use their higher-dimensional counterparts if we want to classify 3-manifolds), so more complex formulations of curvature are required.

I am no expert in curvature myself, but I would wager that researchers would use Ricci curvature here.

There's also a nice connection to the Poincare conjecture. I was planning on tackling that in another article. See MathOverflow for an interesting discussion on this subject: [https://mathoverflow.net/a/9717](https://mathoverflow.net/a/9717)

</comment></comment><comment><USER12> > We already encountered a triangle with three right angles on the sphere

Nitpick, but the upper angle of triangle displayed is not right, it's 72 degree (1/5 of 360)

<comment><AUTHOR> Thanks, I will correct this in a subsequent version of the article.</comment></comment>


5 Reasons For Having Weekly Two-Hour Lunches With Your Co-Founders - <AUTHOR> http://www.stangeek.com/5-reasons-for-having-weekly-two-hour-lunches <comment><USER3> _I would never work with co-founders who only like to live on cardboard pizza and redbull ;)_

Same. I don't buy into the startup "lifestyle" of most B2C web companies. I'm pretty sure, in the US, it's a relic of the dotcom era that needs to die.

</comment><comment><USER4> My startup did this in the early stage partly because everyone was moonlighting and having a weekly meeting helped keep us focused on the project and hash out any development issues.

<comment><AUTHOR> Your comment is very interesting, because it relates to my previous post who essentially recommends moonlighting (at the early stage) - <USER2> <http://www.stangeek.com/your-best-business-angel-yourself>

</comment></comment><comment><USER5> _Food (and a reasonable amount of beverage) is good for creativity._

Eating together is also a bonding experience. So eating together can help foster trust. (Though I think this depends in part on the experience being a successful experience -- hating where the other person likes to eat might tell you there are potentially bigger problems in your future.)

<comment><AUTHOR> Yep, fully agree, that's exactely what I say in point #4 of the blog post :)

<comment><USER5> Well, I didn't get that out of point 4. Here is the exact quote:

 _Making your startup succeed requires you to have a lot of faith and dreams about your project, and a weekly lunch is probably a good environment for having this kind of team "bonding" around a common vision / dream._

It's not merely a good environment for bonding, sharing a meal actually causes some bonding all by itself, whether you discuss business or not. Humans are at their most vulnerable when eating and food sustains life itself. There are some very powerful psychological and emotional forces at work when you sit down and break bread with another person. It isn't merely "nice atmosphere".

I used to feed the single soldiers who came to my apartment in Germany to play role playing games with my husband. Every last one of them came to say "goodbye" to me when they got their orders to go back home to the US. And some of these strapping young soldiers cried as they hugged me goodbye, though their relationship had not really been to me, it had been to my husband. But I was the one who played hostess and cooked them Christmas dinner and put my kitchen at their disposal every weekend, not him.

Peace.</comment></comment></comment>


Ask HN: What did Netflix do differently to survive the Amazon outage? - <AUTHOR>

Inspired by these:
http://news.ycombinator.com/item?id=2475729 (Jedberg on Reddit's recent outage)
http://news.ycombinator.com/item?id=2476052 (Skynet, EC2, and Zencoder)
Why did Reddit, Zencoder, Heroku, and myriad other services go down, without Netflix encountering the same problem? Can anyone get into the details on what's different about their architectural setup that allowed them to handle the failure gracefully? <comment><USER2> there was some talk of it here: <http://news.ycombinator.com/item?id=2470773></comment>


Stack Overflow Is Not Trying to Start Audio - <AUTHOR> https://meta.stackexchange.com/questions/332229/stack-overflow-is-not-trying-to-start-audio <comment><USER2> stack overflow becomes ultrasonic tracking beacon apologist?</comment>


STS-107 "Columbia" Loss FAQ (2004) - <AUTHOR> http://web.archive.org/web/20040413043718/http:/www.io.com/~o_m/columbia_loss_faq.html <comment><USER2> From what I read, it's scientific value was significant. Very sad for this accident.</comment>


Facebook Wants To Make Your Voice Plan Obsolete - <AUTHOR> http://techcrunch.com/2013/02/22/facebook-wants-to-make-your-voice-plan-obsolete-adds-free-calling-to-its-ios-application/

<comment><USER2> I've never, ever thought "I have too much unused data quota on my smartphone plan, I wish I could trade it in for voice minutes". So I'm not sure I see the value proposition here.</comment>


As Glaciers Melt in Alaska, Landslides Follow - <AUTHOR> http://www.nytimes.com/2016/07/06/science/alaska-landslides-glaciers-melt.html <comment><USER2> The original article in Alaska Dispatch News has more pictures of the landslide in Glacier Bay, it's pretty impressive.

[http://www.adn.com/alaska-news/2016/07/02/massive- landslide-...](http://www.adn.com/alaska-news/2016/07/02/massive-landslide- crashes-onto-glacier-in-southeast-alaska/)

</comment><comment><USER3> Similar problems in Switzerland. After the Lower Grindelwald Glacier partially melt to generate a lake, there were worries that a sudden outbreak would flood Interlaken. Also there were landslides. A short tunnel to drain the lake has been bored.

</comment><comment><USER4> It is amazing how both adaptable and yet resistant to change we are. We are so afraid of change—yet what comes just might be better than what we have now.

<comment><USER5> In a vacuum, you might have an excuse for saying that. But we are not in a vacuum. We know what bad things are coming via climate change, and we are seeing bad effects already. Furthermore, we have every reason to believe that the interaction between current geopolitical systems and the technological systems that support food production will be severely strained by what's coming, and is strained by what's already here.

It is simply too late in the game for deliberately uninformed speculation about what utopias await us after the global demise of saltwater shellfish, for example, or after the collapse of thermohaline circulation, or the thawing of methane hydrates. This isn't some game of chicken that will be won by not being "afraid of change." This is the recognition of an unfolding global catastrophe, and it's irresponsible to bury our heads in the sand with wild essentialist speculation about how "resistant to change" we are. Whether we survive or not will not depend on essences like "adaptability" or "resistance"; it will depend on contingencies like whether the boreal forests burn in spring or fall of 2023, or whether political instability in a crumbling Russia results in the launching of nuclear weapons and how the West responds.

<comment><USER6> There's no need to go as far as nuclear war. Climate change will manifest itself in political instability and mass migration (see Syria and Africa), and perhaps even more fundamentally, rampant desertification which is liable to lead to food shortages in poorer countries.

But yes, it _is_ a global catastrophe and sadly few people seem to care enough to do something about it.

</comment></comment></comment><comment><USER7> Keep in mind that glaciers always melt. And cause landslides. And new ones form. Been happening for millions of years.

<comment><USER5> > Keep in mind that glaciers always melt. And cause landslides. And new ones > form. Been happening for millions of years.

Keep this in mind, from the article:

> Scientists say the slides will most likely continue as warming temperatures > cause more glacial melt.

Also, keep in mind that mussel shells were 27% thicker in 1970 than they are now, due to ocean acidification. Keep in mind we just came out of a streak of the 12 hottest months on record, and, lest we feel complacent, that's only because the 13th month was the second hottest on record. Keep in mind that we're about 4 years away from having no glaciers in Glacier National Park.

In the completely neutral spirit of keeping things in mind, keep all those things in mind, too. As a matter of fact, I recommend to you, and to everyone here, go online and find climate-related things to keep in mind.

Thank you for your concern.

<comment><USER8> "Keep in mind we just came out of a streak of the 12 hottest months on record"

Keep in mind that "on record" covers less than an eyeblink, geologically speaking, and that we have evidence that the earth has been both much warmer and much colder than it is now.

Not just millions of years ago, either. On the warm side, the Vikings had dairy farms in Greenland, some of which are only now emerging from the ice. That's only 1,000 years ago, and the temperatures were clearly warmer than they are now (not only are there no dairy farms in Greenland today, but quite obviously the farms were not frozen in the ice when they were in operation).

[http://naturalhistory.si.edu/vikings/voyage/subset/greenland...](http://naturalhistory.si.edu/vikings/voyage/subset/greenland/archeo.html)

On the cold side, most of the American Midwest and central Canada was covered in several miles of ice as recently as 11,000 years ago.</comment></comment></comment>


Ask HN: What AI courses/material should I choose? - <AUTHOR> Posting it here again since it didn't get much attention yesterday.
I'd describe myself as someone who has beginner/intermediate skills in the field. I started exploring AI field at the beginning of the last year. Then I took a year off, exploring other fields trying to figure out what am I interested in. Now I can confidently say that AI/DL is a path I want to pursue in the future. - I have some basic experience across the DL field in general (GANs, convolutional nets, word2vec, LSTMs, math/reasoning behind these topics)
- I have experience building simpler neural nets (mostly conv nets + GANs) from the scratch using NumPy
- I was frequently working with Tensorflow but I can imagine that the library changed a lot since the past year
- I feel that my probabilistic/statistics skills could be better
- I feel that I have very little experience building AI in the real world
- I feel like I need to learn how to be able to apply the latest scientific papers
What I need now is to (1) refresh my old knowledge, (2) take more challenging courses/classes with more "real world" approach and (3) start reading (and applying) scientific papers.
Do you please have any recommendations regarding me coming back to this field and getting deeper into it? <comment><USER2> Would you enjoy something that gives a broad overview? Norvig's AI book [https://www.amazon.com/Artificial-Intelligence-Modern- Approa...](https://www.amazon.com/Artificial-Intelligence-Modern- Approach-3rd/dp/0136042597) should give you a very broad perspective of the entire field. There will be many course websites with lecture material and lectures to go along with it that you may find useful.

The book website [http://aima.cs.berkeley.edu/](http://aima.cs.berkeley.edu/) has lots of resources.

But it sounds like you are specifically interested in deep learning. A Google researcher wrote a book on deep learning in Python aimed at a general audience - [https://www.amazon.com/Deep-Learning-Python-Francois- Chollet...](https://www.amazon.com/Deep-Learning-Python-Francois- Chollet/dp/1617294438) \- which might be more directly relevant to your interests.

There's also what I guess you would call "the deep learning book". [https://www.amazon.com/Deep-Learning-Adaptive-Computation- Ma...](https://www.amazon.com/Deep-Learning-Adaptive-Computation- Machine/dp/0262035618)

(People have different preferences for how they like to learn and as you can see I like learning from books.)

(I apologize if you already knew about these things.)

<comment><AUTHOR> Thank you for the tips.

The Deep Learning Book ([http://deeplearningbook.org](http://deeplearningbook.org)) was one of my main studying materials. How would you compare the other DL book you mentioned ([https://www.amazon.com/Deep-Learning-Python-Francois- Chollet...](https://www.amazon.com/Deep-Learning-Python-Francois- Chollet/dp/1617294438)) against this one?</comment></comment>


SpaceX Vet's Startup Raises $21 Million to Build Smaller, Cheaper Rockets - <AUTHOR> https://www.bloomberg.com/news/articles/2017-06-29/spacex-vet-s-startup-readies-small-rockets-for-takeoff <comment><USER2> > The price per pound on the large rockets from SpaceX and others is still > more economical. But it's the flexibility of requesting a launch, almost > like you'd order something on Amazon.com, that could end up being more > attractive than pure cost.

I don't see this working out. The regulatory burden is going to be immense compared to the cost of the hardware.</comment>