Duck Duck Go: Illusion of Privacy (2013) - <AUTHOR> http://etherrag.blogspot.com/2013/07/duck-duck-go-illusion-of-privacy.html <comment><USER2> I think DuckDuckGo is unfairly singled out here. They do more than most companies to protect privacy, and most of their users are specifically trying to deprive Google of more feed for its data silo. Of course they can't protect you from the NSA. Extremely few actors can.

If your threat model includes actors within the US Federal Government (especially the intelligence community), run. Yesterday. That's a statement about our times, not about any particular company.

The solution ought to be browbeating the US Government for unethical practices, not browbeating a company that does privacy better than most, and not as well as would be necessary to stand toe-to-toe with some of the most powerful and far reaching organizations in the world.

<comment><USER3> I don't get why Google is always singled out either. When was the last time Google leaked your data. As you said, very few actors can protect your data from the NSA, so the next best thing is to have it protected from hackers and leaks. Every other company out there keeps on getting hit left and right, but for their size, Google is only of the only company who has never messed up with user data, and you know they are probably one of the most targeted, especially by state actors such as china and russia.

<comment><USER4> >When was the last time Google leaked your data[?]

According to the State of California Department of Justice [0], the last publicly acknowledged data breach from Google was March 9th, 2017. Before that it was August 10th, 2016, and before that March 29th, 2016.

[0] [https://www.oag.ca.gov/privacy/databreach/list](https://www.oag.ca.gov/privacy/databreach/list)

<comment><USER5> According to the notification letters on that site, those three incidents all involve Google employees' information being leaked by third parties, not Google leaking users' data.

Here's a quote from one of them:

"We recently learned that certain hotel reservations made for Google business travel were among the many reservations affected by a security incident impacting a third-party provider's electronic reservation system that serves thousands of travel agencies and hotels. This did not affect Google's systems. However, this incident impacted one of the travel providers used by Googlers, Carlson Wagonlit Travel (CWT)."

</comment></comment></comment></comment><comment><USER6> My beef with this article is that it's unreasonably reductionist to conclude that DDG provides an "illusion" of privacy based on the fact that they're as vulnerable to being targeted by the NSA as anyone else. The issue of privacy is so much bigger than that.

If you use Google Search and someone obtains access to the data they have on you, legally or illegally, they could end up obtaining many years of your browsing history. If you use DDG they have nothing, and the most they can do (as the article states) is start collecting your search habits from that point onward.

I don't want huge companies to amass giant archives of data about me. There are so many ways it can be abused by a multitude of actors. It's a selling point to me when a service retains little or no information, and if it needs to retain something, it requests limited permission in clear and simple terms.

</comment><comment><USER7> The only conclusion I can make from this article is to avoid services hosted in the USA but even that is not guaranteed to work -- having in mind that US agents have been known to go abroad to request access to foreign company's servers. (They were even supposedly thrown out from Iceland once -- assuming that wasn't a honey pot propaganda operation to lure people to host stuff in Iceland, of course.)

What's left for the people who aren't criminals but don't like being spied on? PGP and keys that are exchanged physically, by hand?

If somebody can physically spy on the infrastructure cables that your traffic goes through, will SSL protect you? As written in the article -- no it will not, because the certificate can be obtained, even if it takes some time and strong-arm effort to do so. But when a country can order you to give up private keys and keep quiet about it, really, what can you do?

At this point, full decentralization, mesh networking and something times better than Tor encoded in 100% of the network code seems to be the only way out. Maybe a combination of IPFS and FreeNet, full packet-level encryption and keys that expire in 1 minute and are auto-generated for every transaction?

<comment><USER8> I've argued here at HN before that I don't think this is a technological problem, but a social one. There is nothing that stops a powerful enough actor from breaking encryption with a rubber hose, except for a strong stigma against that kind of behavior. We need to give digital privacy the same social protection. The other problem with making a purely technical solution is that you leave out people who are not capable of using that solution because they do not have the resources, education or capability.

<comment><USER9> Solving the problem with technology is 1000000 times easier than solving it from the "social" side.

<comment><USER10> Is it? For who?

Do you think people's data would be more secure at the border if

\- You kernal-hacked iOS so that it booted into a vanilla account upon entry of a certain passcode, and encouraged people to install your hack from GitHub, potentially borking their phones

\- People couldn't be compelled (or face being denied entry) to allow search of their electronic devices

?

What about trying to do everything via a VPN and spoofed UA strings vs. PII being banned from sale, heavily taxed, or a meaningful opt-out existing? Or even just DNT having a legal basis?

<comment><USER11> _Is it? For who?_

For HN readers. And probably in general.

As for your questions, I would definitely like to first use software which doesn't compromise my privacy and security and only as a very distant second have some bureaucrat who would maybe in the best case scenario fine a company which leaks my data.

The vote I cast by running a Tor relay is much more meaningful and valuable defence of privacy than a vote in the general elections. By orders of magnitude.

<comment><USER10> Don't get me wrong, I'm all for using technology to preserve privacy.

> _The vote I cast by running a Tor relay is much more meaningful and valuable > defence of privacy than a vote in the general elections._

I kind of agree, but, not if the new leader outlaws using Tor tomorrow, as they have in China and Iran, and are attempting to do in Russia and _France_.

> _bureaucrat who would maybe in the best case scenario fine a company which > leaks my data_

You may be selling the power of legislation short. It has the power to entirely transform the default business model of the Internet away from surveillance capitalism, for example. In terms of privacy, this would eliminate entire classes of "threat".

We frequently under-estimate our power as technologists to influence these things; we have very much more than a single vote. The narrative of 'technology' in the media is almost entirely that of billionaires and spies, and the media are gradually starting to realize that they're being led along. Getting the voice of technologists to explain the societal impacts of technology policy is a problem that we need to identify with as group.

</comment></comment></comment></comment></comment></comment><comment><USER12> Recently I have been using the free and open source Searx more and more (admittedly mostly using the !searx shortcut from DDG). Results seem better than DDG sometimes. Would be interesting to try and host my own instance or write something that picks a random public instance.

[https://asciimoo.github.io/searx/](https://asciimoo.github.io/searx/)

<comment><USER13> Along that same line is YaCy.

[https://yacy.net/en/index.html](https://yacy.net/en/index.html)

<comment><USER12> I think YaCy didn't give me very good results last I tried it. It's not a fair comparison, as it has been a few years for sure, but if I had to guess then I would say that Searx, being just a search engine aggregator (it doesn't do crawling), gives better results.

<comment><USER13> I tried it last about six months ago. It was a marked improvement over what it was a couple of years prior. I like that it is decentralized and stores no private data. To me, the decentralized part is important. But, I'm not sure I'd say it's ready for prime time.

With Searx, you still need the regular search engines. I suspect that your traffic can still be identified, say through timing requests or from piecing together behavioral data. I haven't really dug that deep to investigate the risks.

I will give it a shot tomorrow, just to try it out. I've seen it in passing but you're the first person I've seen, in the wild, that uses it. I'll give it a test run.

</comment></comment></comment></comment><comment><USER14> To be fair here is ceo response quote

Hi, this is Gabriel Weinberg, CEO and founder of DuckDuckGo. I do not believe we can be compelled to store or siphon off user data to the NSA or anyone else. All the existing US laws are about turning over existing business records and not about compelling you change your business practices. In our case such an order would further force us to lie to consumers, which would put us in trouble with the FTC and irreparably hurt our business.

We have not received any request like this, and do not expect to. We have spoken with many lawyers particularly skilled and experienced in this part of US and international law. If we were to receive such a request we believe as do these others it would be highly unconstitutional on many independent grounds, and there is plenty of legal precedent there. With CALEA in particular, search engines are exempt.

There are many additional legal and technical inaccuracies in this article and I will not address all of them in this comment. All our front-end servers are hosted on Amazon not Verizon, for example.

<comment><USER15> Here is the link to the CEO's response for those interested: [http://etherrag.blogspot.in/2013/07/duck-duck-go-illusion- of...](http://etherrag.blogspot.in/2013/07/duck-duck-go-illusion-of- privacy.html?showComment=1373764601583#c337630469341123253)

<comment><USER16> The amount of unearned confidence the author of the blog displays in his reply is kind of embarrassing. "I read a CNET article once that contradicts what you're saying!"

He created that blog account just to write that article and it's the only one up there. Stuff like this makes me wonder what motivates some people.

</comment></comment></comment><comment><USER17> Like Google, by default DDG tracks what results the user clicks on. URLs are prefixed with a DDG URL. Users HTTP requests are forwarded through DDG servers.

By default, DDG "lite" does not set cookies or use Javascript. However, if the user wants to change the default "settings" (HTTP has no state so this is a fiction), then AFAICT she has to enable Javascript and accept cookies. Privacy conscious users do not want Javascript or cookies.

DDG could achieve the same result by simply providing an alternate URL, something like /lite2 in addition to /lite.

Whether DDG saves this data I have no idea. But one has to wonder why, if privacy is a goal, DDG is collecting it to begin with.

If DDG believes it is doing this for the benefit of users, it is not convincing because there are alternative ways to achieve the same benefit that do not require prefixing URLs, Javascript or use of cookies.

For example, browser settings already allow the user to control HTTP Referer headers, assuming queries were submitted using GET. The user can change the settings in the browser so that no referer is sent, or to send a custom referer of her choosing.

Another example is if DDG accepted queries via POST method in addition to GET. No search terms would be leaked in the URL or in any HTTP referer.

<comment><USER18> DuckDuckGo staff here - just want to clarify a couple of points:

* We don't track result clicks. URLs are no longer prefixed with a DDG URL by default except for old browsers (although this is controllable in the settings: [https://duckduckgo.com/settings#privacy](https://duckduckgo.com/settings#privacy) ), but even if this is in effect we don't store which sites users visit. We started stripping search queries in referrer headers in 2010 and you're right, current web standards make it possible to do this without us having to redirect through our own servers.

* We have an alternative non-JavaScript URL - [https://duckduckgo.com/html](https://duckduckgo.com/html) \- which tries to offer a fuller search experience than the minimalist [https://duckduckgo.com/lite](https://duckduckgo.com/lite)

* Cookies are used to store settings but if users prefer to block them, preferences can still be "saved" by using URL parameters, listed here: [https://duckduckgo.com/params](https://duckduckgo.com/params) These can be used either to form a local bookmark/start page or anonymously in the cloud with a password only (no username or other data).

> But one has to wonder why, if privacy is a goal, DDG is collecting it to > begin with.

I'm not sure which data this is referring to but we don't collect or share personal information. There's more on this in our privacy policy: [https://duckduckgo.com/privacy](https://duckduckgo.com/privacy)

<comment><USER18> I forgot to add that we do accept POST request queries as an alternative to GET, again from the settings.

</comment></comment></comment><comment><USER19> Most of the points is arguing that NSA could compel the company Duck Duck Go, Inc to install equipment and then forbidding the company from disclosing that fact.

Doing so does carry quite a bit of political risk. There have been quite a few lawsuits from EFF and ACLU in regard to do so, and as the comment from CEO of Duck Duck Go says in the comment thread, all existing cases has been about turning over records. Going the extra step of compelling people to install hardware and keeping the operation going would be a further step.

I doubt ddg is currently worth the political risk. There is likely much easier targets to attack first in order to get 100% of the worlds search data.

*down votes? Explanation?

<comment><USER20> I'm not sure if they really need to compel DDG in the first place.

I know if I was a three letter agency, I'd start a "secure" service like DDG myself as kind of a honeypot.

Not that I'm saying that such an agency is actually behind DDG -- I have no way of knowing. But I would be very surprised if a large number of services promising "security" and "privacy" weren't run by such agencies or their agents.

That's why I believe that frequent, independent third-party auditing (by multiple trusted groups like the EFF) would be necessary to gain any kind of confidence in such services. Even then, it'll be no guarantee that they're not compromised, but it would just make such compromise significantly more difficult and less likely to be effective.

<comment><USER19> While that is always possible, I think its more plausible that they then simply buy out key companies rather than found a bunch of new companies in hope that one will succeed. The question then is, what is the likelihood that NSA is the secret owner and operator of Microsoft, Apple or Yahoo, which each would likely be the cost effective choice if one wanted access to all search queries done on the Internet.

Independent third-party auditing is useful. There is the occasional fund raising for auditing of software (Truecrypt comes in mind), but I don't recall hearing one about search engines.

<comment><USER20> _" I think its more plausible that they then simply buy out key companies rather than found a bunch of new companies in hope that one will succeed."_

How many new search engines were focusing on privacy and security as their main differentiator from the competition?

I know of only one: DDG

<comment><USER19> Here is a meta article with the clicky _5 best search engines that respect your privacy_ with the lesser clicky official title: _Privacy Search Engines 2017 Group Review_. :"[https://www.bestvpn.com/privacy-search- engines/](https://www.bestvpn.com/privacy-search-engines/)

[https://en.wikipedia.org/wiki/List_of_search_engines](https://en.wikipedia.org/wiki/List_of_search_engines)

That list is long and show that there has been quite a few people have tried to get momentum in the search engine space. Would be interesting if anyone did a meta study to see how many uses the words "security" and "privacy" as marketing to gain users.

I think we should also include open source search engines and p2p, since if NSA developed them they could build backdoors in them. Most of them seems to have "privacy and security" as explicit goals.

</comment></comment></comment></comment></comment><comment><USER21> Recently I had a series of unfortunate plumbing mishaps at my home that set me back a bunch of money. I did very minimal google searching (just confirming the spelling of the plumber's name), but ads offering emergency home loans have started popping up in my browser.

If I can go to a search engine that doesn't sell the fact of possible financial problems to whatever loan shark is willing to pay the most to get to me, I see that as a win.

</comment><comment><USER22> Privacy requires full transparency. We're is documented with what foss software ddg works and where can I find trusted audit reports?

<comment><USER23> Even if they were completely open source how would you verify that they are using the same software on their servers? That the hardware is not compromised?

Audit reports? How trustworthy are they if Symantec was able to provide good reports for such a long time for their certificate issuance when things were clearly not ok.

<comment><USER24> For example if they used AGPL software, it would be much harder for them to cheat. But you can never get 100% confidence.

</comment></comment></comment><comment><USER25> Duck Duck Go is a company that I want to succeed, as they are clearly making a stand on user privacy.

However it never made sense to me why people would use those DDG bangs.

I mean privacy is the main selling point, so why in the world would you send the searches you make on other websites to DDG, when the browser is perfectly capable of being configured for " _search keywords_ ".

In Firefox, go to amazon.com (or any website you want), right click on their search bar and select " _Add a Keyword for this search..._ ". Add " _!a_ " or whatever you want. There, you've got your own bangs.

<comment><USER26> Not all browsers are configurable to search keywords (particularly on mobile).

DDG is consistent across hosts / browsers / OSes.

DDG maintain (and fix) the bang searches as they break (which ... happens).

I appreciate being able to !bang away in my Android browser(s) navbars. There are other options. Surfraw (a Linux CLI utility) is an example, though my problem is that 1) I can't remember the aliases and 2) they interfere with other commands I use (there are ... a _lot_ of surfraw elvi).

</comment></comment><comment><USER27> If you're worried that DDG may log your IP you can simply use it with the Tor Browser (it's the default search engine) or use their onion service ([https://3g2upl4pq6kufc4m.onion/](https://3g2upl4pq6kufc4m.onion/)) for increased security and anonymity.

<comment><USER28> Tor is _far_ from perfect and there are several ways in which one could connect traffic at some endpoint with a user at a specific IP. Do not rely on Tor if you _really_ want anonymity.

<comment><USER29> Tor offers a layer of protection. It is possible to stay anon on Tor.

<comment><USER28> > It is possible to stay anon on Tor.

That is an extremely dangerous statement to make and one I do not agree with.

Keep in mind that:

\- you will have to trust that a large chunk of the nodes is not in the hands of someone that you count as your enemy

\- that even if your enemy is not in charge of a substantial part of the network they may still be monitoring entry and egress and that that alone can be enough to figure out who is talking to who

\- that any data present at egress that can be intercepted might still reveal who you are

So no, Tor is not 100% secure and it is very well possible that even if you use Tor your identity will be connected with some activity or even all of your activity while using the network.

<comment><USER30> You didn't actually disagree with your parent comment. It is possible to be anonymous on TOR. It does not come for free.

<comment><USER28> Well, if you want to trust your anonymity to luck or not being monitored then yes, you can be anonymous on Tor. But that's little comfort. It's possible to cross a highway blindfolded too. But it isn't smart to do so and it is even less smart to assume that it will always work just because you can't see the danger with your silly blindfold on.

<comment><USER30> Thankfully, none of your assumptions are true if you consider TOR one part of anonymity as your parent comment did.

Not to mention, you conspicuously avoid comparing degrees of anonymity. Obviously TOR is better than SSL, which doesn't provide any anonymity.

<comment><USER31> If you use Tor as part of a group of privacy measures then you can protect your privacy online, but it's useful to know what the potential weaknesses of Tor are so you know what other measures to take.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER32> The issues brought up in this post apply to every single service operating online, and it only applies to DuckDuckGo in any special way because of their increasing size. This includes "client" encrypted webmail and similar applications: they can be forced to deliver malicious JS that gives up your keys, or the JS client delivery can be MitM'ed.

Many people seeking enhanced privacy from DuckDuckGo are seeking privacy _from Google_ , not from state actors. For that, you'd need additional measures like Tor, for which DuckDuckGo provides a convenient .onion service. Even if DDG is secretly tracking all our searches, they have less data to correlate it with.

My current privacy complaint on DuckDuckGo, combined with browser search UI issues (looking at you, Chrome) is over the !bangs. If you're doing "!w [sensitive topic]" instead of tabbing to Wikipedia search in your browser and searching that way, you're risking DDG or anyone who's compromised DDG seeing your Wikipedia searches, when the search should go straight to Wikipedia, Twitter, Stack Overflow, and so on.

<comment><USER33> DDG has [https://DuckDuckGo.com/lite](https://DuckDuckGo.com/lite)

For non js. There are of course other vectors and many not even search engine dependent.

<comment><USER18> Thanks for that. We also have [https://duckduckgo.com/html](https://duckduckgo.com/html)

(Disclaimer: DDG staff)

</comment></comment></comment><comment><USER34> I use Duckduckgo because I don't like monocultures.

<comment><USER35> Very noble.

</comment></comment><comment><USER24> I am participating in a peer-to-peer search engine based on free software, [http://yacy.net](http://yacy.net). But I am not sure it can save us from NSA... We have to take political steps against them anyway.

</comment><comment><USER36> comparison of using DDG vs Google over tor is enlightening (GIF):

[https://twitter.com/cyphunk/status/849615910545620992](https://twitter.com/cyphunk/status/849615910545620992)

<comment><USER26> Google's anti-bot measures DoS the service for me rather frequently.

(Perhaps I am a robot?)

</comment></comment><comment><USER37> Collecting meta-data is not benign at all, it's trivial for the usual suspects to de-anonymise, and profile based on browsing habits.

Fat protocols should marshal the true web 2.0 along with DAOs.

</comment><comment><USER38> So does DDG produce a transparency report and if not then why not?

</comment><comment><USER39> This is something that's always been fascinating to me. In any thread about privacy, there's always a comment along the lines of "if your threat model is a nation-state, then you're screwed." You hear it about DDG, Tor, client-side but web-delivered encrypted email, etc.

What if your threat model is a nation state? What's the proper way to ensure your privacy _that does not require abstaining from the internet_? Is a high degree of privacy even possible?

<comment><USER40> Privacy from the state never really existed, even before the internet. Paperwork always allowed the state to know things. Information has always been power, and information is an important tool for governments so they can be able to work. I think it always has been.

I'm more worried about privacy from private interests. The issue is what the governments do with data, and if the government let private parties access it, and where do you draw the line between the government having right to access, and companies being allowed to access it, because you will often have situations where things are not clear.

To be honest I will always have a problem with the whole privacy/surveillance debate, because there are things the government should know, but only because it is the government. Private companies are now being able to track people and have the same kind of data the government has.

So there is a big nuance, and it is often shut out by the outrage, which frankly comes from a libertarian agenda, which I have a problem with.

</comment></comment><comment><USER41> I wrote my own search engine and using it. Not very difficult.

<comment><USER31> Is it a proxy to other search engines or do you search your own database of websites?

<comment><USER41> Sorry for the delay in my reply.

I search from my own 1GB database; It covers 80% of my needs;

<comment><USER31> Interesting. Thanks for your reply.</comment></comment></comment></comment>


Formal Verification: The Gap Between Perfect Code and Reality - <AUTHOR> https://raywang.tech/2017/12/20/Formal-Verification:-The-Gap-between-Perfect-Code-and-Reality/ <comment><USER3> Having been down this road [1], a big problem is that the people doing this tend to be too much into the theory and not enough into wanting programs not to crash. That's some of the Coq world.

It doesn't have to be this way. Microsoft's work in this area led to the Static Driver Verifier [2], which was a huge success. Windows crashes due to kernel drivers breaking the rest of the kernel have pretty much disappeared. They were once (Windows XP and earlier) responsible for over half of Windows crashes.

Most of the things you want to prove about programs to make sure they don't crash are mathematically trivial. Detecting buffer overflows and off-by-one errors seldom requires elaborate proofs. If they do, your program design probably has a problem. Simple proofs can be handled by a prover which uses a Nelson-Oppen decision procedure. This is a complete decision procedure for formulas which contain only addition, subtraction, multiplication by constants, Boolean operators, structures, and arrays. This covers most data access operations. It's fully automatic and complete - the algorithm always succeeds within its problem space. You need one of those for the easy parts.

For the hard parts, we used the Boyer-Moore prover. (Sources are available and I brought it back to life on Github.[3] It runs 3000x faster than it did in 1982.)

The interface with the language is crucial to usability. Most efforts get this wrong. They put the verification stuff in separate files, or in comments. It should be part of the normal code. We built the verification language into the compiler, so you used the same source and the same syntax for compiling and verification. There were additional statements - ASSERT, ENTER, EXIT, etc. The same compiler front end was used for both compiling and verification. The verifier itself ran off the byte code from the compiler front end. All type and size issues had been decided at that point, so the verifier was looking at unambiguous operations such as "pop two operands from stack, add in 16-bit twos complement arithmetic, push on stack". This captured the semantics of the program the same way the compiler did.

The user never sees the easy stuff. Every subscript use generates a bounds check assertion which has to be proved. If the prover is able to prove the assertion true, the user doesn't see it. Only the errors are visible. Another trick is that you don't write "assert(a and b and and d)", you write "assert(a); assert(b);". Those generate separate proof goals, and if only one fails,the user gets error messages about only that one. Also, when you write "assert(a); assert(b);", the second one is proved under the assumption the first one is true. This prevents cascading errors.

A key point here is that verification is meaningless unless you prove _all_ the theorems. If you write "assert(false)" other errors go away, and you're left with one simple error, which you cannot eliminate. You don't get to dismiss it. It's possible to write an assertion that's equivalent to "assert(false);", such as "assert(0 > 1)"; This is why I'm so negative on the arguments from some of the Rust crowd that a little undefined behavior is OK. It can blow at any seam.

When you needed to prove something hard, you wrote

        assert(a);
        assert(b);

where a could be proved by the Nelson-Oppen prover from the code before it. B was chosen such that if you assumed b, the Nelson-Oppen prover could prove anything required past that point. Now you had one error message, that the system couldn't prove "a implies b". So then someone had to try to prove that with the Boyer-Moore prover. The Boyer-Moore prover is mostly automatic, but often someone had to provide intermediate theorems to get to a hard one. Those were all machine-checked. If this succeeded, the Boyer-Moore prover generated a theorem that a implies b for use by the verifier. Rerunning the program verifier would then succeed. Such theorems could be reused with different variable bindings, so if the same problem came up again, it didn't require more work with the Boyer-Moore system.

If you're generating vast amounts of user-visible proof work, something is wrong.

The whole system I'm describing is now on Github.[4] It's decades-old code, but I've ported about 80% of it to modern compilers. The Franz LISP to Common LISP port of the prover isn't working well, and the author of that code died years ago. If anyone wants to work on that, go ahead.

[1] [http://www.animats.com/papers/verifier/verifiermanual.pdf](http://www.animats.com/papers/verifier/verifiermanual.pdf) [2] [https://docs.microsoft.com/en-us/windows- hardware/drivers/de...](https://docs.microsoft.com/en-us/windows- hardware/drivers/devtest/static-driver-verifier) [3] [https://github.com/John- Nagle/nqthm](https://github.com/John-Nagle/nqthm) [4] [https://github.com/John-Nagle/pasv](https://github.com/John-Nagle/pasv)

<comment><USER4> I appreciate your detailed post. Very interesting esp with Nelson-Oppen being new to me. I remember Boyer-Moore from studying CLI stack. Your comment brings three things to mind:

1\. It implies, esp with links, that one should both look into and build on BM prover. Whereas, my foray showed that high-assurance sector moved on from BM to ACL2 with latter used in all sorts of stuff (esp hardware). Hardin et al link below are my favorite at the moment. Your Github on nqthm even says avoid BM in favor of ACL2 for new stuff. Anything you want to add on that such as things ACL2 could use from BM or in general? I know from other works that new and improved doesn't mean better in every way. Also, doesn't ACL2 lack a tiny, proof kernel checking its steps like the LCF provers or am I misremembering? I have seen work embedding it in HOL, though.

2\. It reminded me about Gypsy Verification Environment that got used on lots of B3/A1-style projects. I didn't realize that was in the FTP site. It might be interesting to get into runnable shape for reliving history and seeing how things were done similar to what you appear to be doing with those other works. I know it dates to the mid-70's but the mid-to-late 1980's paper on applying 2.0+ version doesn't mention your work at all in references even though done in similar time frame. Why you think that is? Since it doesn't, what's better or worse about the approaches if we compare your Pascal-F method to GVE? Side note: the report in the tarball describing the the Gypsy, Middle Gypsy, and Micro Gypsy languages was really good on readability vs detail included. I always love that.

3\. The current contenders in verified, low-level programming are the mature SPARK Ada tool and Microsoft's Dafny. Would you recommend skipping the Pascal tech to just enhance one of them directly or extracting new languages to their form for use on their tooling? Latter was my plan if I build anything with SPARK the target as many have done. Jasmin language similarly used Dafny. Anything you think especially SPARK Ada could learn in automating practical analyses from Pascal-F, Gypsy, or BM/ACL2? Interestingly, SPADE-Pascal, SPARK's predecessor, was developed in mid-80's as well.

As usual, just trying to see how these points in history might connect in old lessons or new opportunities.

[http://www.ccs.neu.edu/home/pete/acl206/slides/hardin.pdf](http://www.ccs.neu.edu/home/pete/acl206/slides/hardin.pdf)

<comment><USER3> I'm not suggesting one should use the original Boyer-Moore theorem prover today. It's of historical interest. I made it runnable again because I used it when it was state of the art, and I'd previously ported it once. But it's 1980s technology.

I like their constructive approach to mathematics. They build number theory up from something close to the Peano axioms, one proof at a time. This is good for soundness. I built on that and didn't add axioms. Proving McCarthy's "axioms" for arrays in Boyer-Moore theory was possible, and was done. Instead of explicit quantifiers, you have recursive functions which are proved to terminate. That gets you out of many annoying logic knots associated with quantifiers. Like undecidability.

I've been out of this for a long time. There's been considerable progress. But the tooling still seems not to be all that programmer-friendly. It could be. We had that partly figured out. What we didn't have was enough CPU power to make it go fast enough to be useful.

I'd hoped Rust would go in for more verification. C/C++ has so much undefined behavior that huge efforts have to be made just to nail down the language. Rust is much better in that respect.

People get carried away with abstraction in this area. I wouldn't try to verify macros or generics before they're instantiated. That requires elaborate and iffy type theory. Instantiate them, look at the generated code (say at the LLVM input level) with hard types for everything, and work on that. That's unambiguous. Then build a system with enough automation that the user doesn't have to do work for each instantiation. That's what computers are for. Don't try to be too clever.

<comment><USER5> Automated proof is what you get with SparkAda. With the 2014 version you get executable contracts (thanks to DbC added to Ada2012) and lots of help from the gnatprove tool (that acts as a frontend - meaning it implements all runtime checks the compiler implements - to why3 or other provers or static analysis tools - see the inclusion of codepeer recently). Then once you've generated all the verification conditions you run z3, cvc4, alt-ergo... You define the amount of effort you're allowing and if they fail to prove your VCs you get immediate feedback (in your dev IDE) and you drill down to 'why' and 'how to help the prover' quickly once you've spent some time doing it (most of the time it bogs down to 'state your unstated assumptions'). And if you're not lucky but still motivated you can quickly jump into Coq or Isabelle with your VCs.

They're very pragmatic. They went for a subset of Ada, that is deemed 'provable' but still largely useable. You get lots of nice typing features and RT checks in Ada.

Still some difficult areas : aliasing, floating point, and user-friendliness, but still the tech is working.

As for generics that's the tactic SparkAda adopted. It's disturbing at first ('they went the lazy way !') but it's pragmatic and it works great. In fact some times you'd be inclined to transform a procedure, function or package to a generic, because with the correct restricted, specific types and parameters the proof effort is easier.

We're at a point where proof of absence of runtime error is almost achievable by mere programmers. We'll be asking soon 'do we go for test+fuzzing+quickcheck for robustness or proof ?'.

As for automation, they're always working on small but useful stuff. The latest one I can think about is loop unrolling. Might look funny but writing loop invariants and variants is tedious. They're slowly (lead bullets) working up small automation steps.

</comment></comment></comment></comment><comment><USER6> I almost completely disagree with the author of this article.

Yes, formally verified systems still have bugs due to the TCB (the trusted computing base). But that's because the TCB is precisely the _only_ part of the system that is not formally verified! So of course it's going to have bugs.

If so many crashing and correctness bugs were found in the (small) trusted part of formally-verified systems (well, in reality only 16 bugs were found in 3 entire formally verified systems, but I digress), imagine how many similar bugs there are in systems that are not formally verified at all!

If anything, what this article should be arguing is that operating systems, proof finding and verification tools and compilers should _also_ be formally verified (and some already are), so that even bugs in these parts of the system are also eliminated.

The only part of the article that I agree with is that it's not feasible to write 10x more proof code than real code.

But IMHO, this is why proof automation is really important to have - <USER2> like Isabelle/HOL, Why3 and SMT solvers like Z3 provide this (the latter of which the author mentions).

Coq, on the other hand, has much less automation and the result is that it's much harder to use and results in larger proof code. Yet, it's seemingly inexplicably much more popular - perhaps it's the catchy name?

<comment><USER7> Coq has/is much stronger a logic (albeit constructive) than HOL. That is _sometimes_ convenient. Most users of proof assistants don't get far enough that powerful automation is unavoidable.

In addition, Coq benefits for a network effect: Coq started earlier targetting university teaching, primarily at UPenn with Pierce's Software Foundations [1].

[1] [https://softwarefoundations.cis.upenn.edu](https://softwarefoundations.cis.upenn.edu)

<comment><USER6> That Coq has a stronger logic is an argument I hear often, but is that really so important when the result is that it's so hard to use that no real-world software engineer is ever going to bother?

Maybe with HOL I will not be able to prove some deep theoretical mathematical result that I could with Coq's Calculus of Constructions, but if I can otherwise much more easily prove >99% of my code to be bug-free, then I would argue that perhaps it's the better "tool" for the job...

<comment><USER8> > Maybe with HOL I will not be able to prove some deep theoretical > mathematical result that I could with Coq's Calculus of Constructions, but > if I can otherwise much more easily prove >99% of my code to be bug-free, > then I would argue that perhaps it's the better "tool" for the job...

Is this true though? What program properties can Isabelle easily automate the proofs of that Coq cannot?

<comment><USER6> > Is this true though? What program properties can Isabelle easily automate > the proofs of that Coq cannot?

Almost all?

Granted, I haven't used Coq very much, so correct me if I'm wrong, but isn't it true that in Coq, with the exception of basic proofs like simple arithmetic expressions, in order to prove a theorem you have to at least explicitly know and write the name of the lemmas that are needed to prove it (apart from how they fit together)?

In Isabelle/HOL, many times you literally only need to write "try" and Isabelle will find the proof of the theorem for you, including the lemmas that were needed to prove it and how they fit together (assuming these lemmas were already proven before). If it turns out that your theorem is false, it can show you an example of inputs where it fails.

This auto-proof functionality I'm describing is mostly thanks to Sledgehammer [0], the auto-counterexample finding is due to Nitpick (and another tool which I can't remember), although there are a few other automation tools that are also very useful.

Granted, you still have to have a high-level understanding of how you want to prove your code, but I would argue this eliminates a lot of the work and (wasted?) time you need to accomplish the final goal...

[0] [http://isabelle.in.tum.de/website- Isabelle2009-1/sledgehamme...](http://isabelle.in.tum.de/website- Isabelle2009-1/sledgehammer.html)

<comment><USER8> Do you have any example proof scripts of some basic algorithms where the proofs can be almost fully automated in Isabelle?

<comment><USER6> See [1] for an example (edit: although this may not be the best example nowadays, see below):

Quoting:

> Consider the conjecture "length(tl xs) <= length xs", which states that the > length of a list's tail (its "cdr") is less than or equal to the length of > the entire list.

> Thanks to Vampire, Sledgehammer finds the following proof: by (metis > append_Nil2 append_eq_conv_conj drop_eq_Nil drop_tl tl.simps(1))

Those are all the lemmas that were needed to prove the theorem. They were selected completely automatically.

AFAIU the "metis" procedure tries to fit the lemmas together so that they prove the theorem, and I believe the HOL kernel gives high assurance that if "metis" succeeds, then the theorem was proven correctly (but my understanding may be wrong here).

Note that Sledgehammer may even automatically find and return a human-readable proof, which for the example above, it returns something like this:

      proof –
        have "tl [] = []" by (metis tl.simps(1))
        hence "∃u. xs @ u = xs ∧ tl u = []" by (metis append_Nil2)
        hence "tl (drop (length xs) xs) = []" by (metis append_eq_conv_conj)
        hence "drop (length xs) (tl xs) = []" by (metis drop_tl)
        thus "length (tl xs) <= length xs" by (metis drop_eq_Nil)
      qed

Edit: That said, note that at least nowadays Isabelle/HOL seems to be able prove the above theorem by simplification alone ("by simp"), so this may not be the best example.

[1] [http://people.irisa.fr/Thomas.Genet/ACF/BiblioIsabelle/isabe...](http://people.irisa.fr/Thomas.Genet/ACF/BiblioIsabelle/isabelleOverview.pdf)

<comment><USER9> metis is a first-order automated theorem prover. the metis tactic will handle encoding the goal as a first-order problem, using ~just the rules you provide it, invoking actual-metis, and reconstructing a proof (in the kernel logic) from the output proof. so, it is impossible to prove things that are false using the metis tactic (ie, metis is entirely out of the TCB).

re: the simplifier, I feel like it's a bad example because coming up with good simp rules and knowing when to add them and when not to when writing new code in Isabelle/HOL is almost an art.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER10> All of my formal verification experience comes from using it in hardware, so the following comment may not apply so well to software where I have no experience of formal methods (beyond learning about it at university).

I think the mistake the author is making here is seeing formal verification as an all or nothing affair. Either you formally prove your program to be correct or it's useless. I would agree with them that doing this is a huge amount of effort and potentially just not feasible for real systems.

However there's a huge amount of value in formal verification as an extra tool to assist you in your verification efforts. By combining traditional verification techniques (normal testing in software terms) with formal methods you have a whole new way to find bugs, one which works rather differently and hence tends to find different bugs. You may not get anywhere near confidence you've formally proved everything (for one I find the more interesting properties just never get proven, but leaving the tool to run for a while often throws up bugs that are tricky to find via other means) but it does accelerate your verification efforts.

It's also a useful tool for exploring certain scenarios you as the designer (or programmer) may be worried about. You can overconstrain it to just look at certain behaviour and you can ask it to show you some specific execution that hits a particular property. Maybe there's some code path that's very hard to stimulate for whatever reason and you want to check out it's functionality. You can get the formal tool to hit it and then see what it does.

<comment><USER11> Hi, author here. I definitely agree the valuable part is thinking through the verification process, which devotes a lot of time to understanding the system and adds resilience in edge cases. Someone on Twitter brought that up: [https://twitter.com/jetapiador/status/943909582279233536](https://twitter.com/jetapiador/status/943909582279233536). Perhaps that's what I should have concluded my argument with.

</comment></comment><comment><USER12> This is similar to the conclusion I came to after doing my PhD in a CS department that had lots of people enamored by formal methods: that the usefulness of it is inversely proportional to the complexity of the project to be verified.

Sad that apparently hasn't changed much in the 20 years since.

I say "enamored", because formal methods seems to me like a field that gets a lot of attention because the possible outcome of it is so damn attractive: if we indeed could easily prove software correct, that would be the biggest advance in software, EVER. But is a bit of a fallacy that just because the imagined end result is so elegant and desirable, that there must be a path to it.

Also, any gains that can be claimed by formal methods are hard to evaluate in a vacuum, as using any other techniques that involve spending 10x more time thinking about / working with some code can possibly have equally beneficial reductions in bug counts. Most software that has undesirable bugs is such because no time/money investment is deemed worth it to make it better, not because formal methods is the only way to improve it.

I find it funny that meanwhile, mainstream software is going the opposite direction, with ever larger systems written in dynamically typed languages like JavaScript and Python, or overly simplistic static type systems like those of Java and Go. You'd think if formal methods was our far away desirable future we'd be incrementally moving in that direction by using more expressive type systems (Haskell, Rust..) and maybe even dependent typing. The invariants that can be encoded in such systems can rule out usefully large classes of bugs with way lower effort than formal methods, but somehow movement on that front is slow. If so few people care to even grab the low hanging fruit, why do formal methods people think we can jump from chaos to order in one step?

<comment><USER13> For me, the problem with formal methods is that a prerequisite is a (formal) specification, and I've never seen one of those in 20 years of software work.

<comment><USER12> Yes. And the ones I did encounter had zero "testing" done to see if they corresponded to the real world.

Hence why we need more incremental tools, that allow us to encode more rules into the (type) systems we already use.

<comment><USER14> > And the ones I did encounter had zero "testing" done to see if they > corresponded to the real world.

You can excuse human beings for being unable to write the programs they want, but if they can't even _specify_ the programs they want, they don't deserve the epithet Homo _sapiens_.

</comment></comment></comment></comment><comment><USER15> This is an excellent blog post.

If you believe a proof of correctness produced by a formal verification tool, I have a bridge to sell you.

For a proof of correctness, you need to model the environment, and write a specification or a golden model. These are just as prone to bugs as the system you are trying to verify (even assuming the tools are correct).

That is not to say formal verification is useless. Developing a proof will force you to formalize your intuitive grasp of the system and its interfaces. Counterexamples produced by the tools will often help to find deep bugs that would be almost impossible to find any other way. And after many iterations of debugging both the system and the proof, you might gain a lot of confidence in the proof and the system.

But even after all of that, trusting a formal proof as a guarantee of correctness is insane.

<comment><USER16> What you're saying is just "trusting any system is insane", which sure, it might be (depending on the criticalness of said system).

But that's not very insightful or informative, how does that drive any sort of decision-making or improvement process?

Do you have any suggestion on how to improve the correctness of systems that work better than formal verification?

<comment><USER15> Formal verification techniques can be very useful, especially for finding deep, often insanely complex bugs.

The process of developing the proof can produce a lot of insight about the system and expose hidden assumptions that were never considered while designing the system.

It is the final proof itself which is the problem. It does not contribute anything except for terminating the debugging process.

Because the specification can be just complex as the system, the proof can only provide a false sense of security. A correctness theatre.

<comment><USER8> > Because the specification can be just complex as the system

Can you give an example of this? I don't find this true in general at all e.g. writing the specification of a sorting algorithm is much easier than implementing most practical sorting algorithms.

> the proof can only provide a false sense of security. A correctness theatre.

You could use this argument to say that unit tests, type systems, code review etc. are correctness theatre. All these things prevent mistakes.

<comment><USER7> > Can you give an example of this?

It's pretty clear that a _fully_ formal specification of a program must be (roughly) as complex as the program itself, for otherwise you could construct an infinitely descending chain of ever simpler specifications which leads to a contradiction.

The reason that you found the specification of a sorting algorithm simpler than the sorting algorithm is that you probably have not fully specified the algorithm. Consider the sorting algorithm in C's standard library, which allows the user to specify a comparison function. Now imagine you'd pass something like the following comparison function:

       def compare (x, y):
          printf ( "I'm comparing %i with %i\n", x, y )
          if ( x < y ) return 1
          if ( x == y ) return 0
          else return -1

It almost completely exposes the inner workings of sorting. Hence a full spec needs to account for this.

<comment><USER8> > It's pretty clear that a fully formal specification of a program must be > (roughly) as complex as the program itself, for otherwise you could > construct an infinitely descending chain of ever simpler specifications > which leads to a contradiction.

That's like saying a theorem statement must be roughly as complex as the proof.

Also consider that it's much harder to reason (and prove) that heavily optimised versions of algorithms are correct compared to naive implementations. For example, a proof of correctness for heapsort is more involving than one for insertion sort.

</comment></comment></comment></comment></comment></comment><comment><USER17> Whenever I read a post like this I have to wonder: was there as much resistance to writing tests for your code before that became common practice? Many of the arguments seem to apply to test driven development in the same way as they do to formal verification: \- You have to go over every single line of code (to show full functional correctness|to achieve full test coverage). \- The amount of code that goes into (verifying|testing) an application is on the same order of magnitude as the application itself! \- There are still bugs in (unproven|untested) parts of the application! \- It's not perfect, so why should we use it at all?

At the end of the day, formal verification is slowly but surely becoming mainstream. Whether through more advanced type systems, static analysis, domain specific model checking, or through interactive theorem proving. We're finally at the point where whole program verification is starting to become realistic for some domains and it will only become easier from here.

\---

As for the article itself, others have already pointed out some specific problems. Let me just add one more: Simulation proofs do not scale, but are far from the only option. I would encourage you to look into more high level verification techniques using axiomatic semantics, such as Iris in Coq.

<comment><USER18> Is this serious question? Yes, people are still saying the same thing about test-driven development.

</comment></comment><comment><USER19> Formal Verification is the state of the art verification method for hardware these days, with most of the ASICs in the market going through it, and recently many SoC's and complex chips like GPUs and non-RISC CPUs. It does not mean that other methods of verification are dying or are ever going to. FV is just as good as the combination of the tools and the people working on it, and it's an extremely difficult discipline to work on.

FV for software is a whole other beast, we simply lack the compute power to thoroughly verify even simple software properly, and the tools are still in their infancy.

My personal opinion, having worked for the lead FV company in the market for years, is that FV for software is probably sufficiently far fetched that Machine Learning methods for verification might be there before FV for software becomes a reality. The reason is: while for hardware it is imperative to have 100% correctness, since the cost of bugs is absurdly high, for software having 90 something percent is mostly acceptable, so if it's cheaper to let a neural network (or something else, I'm no ML expert) estimate the correctness of the software, that's whats going to happen.

</comment><comment><USER20> Very interesting. For example:

"The guarantees of a formally verified system rest entirely on the assumptions of the system, including its trusted computing base (TCB). The TCB of a verified system includes the specs, which are manually written and hoped (fingers crossed!) to be correct, the verification tools (e.g., Coq engine, Z3, compiler), and the runtime infrastructure (OS, hardware). This should be a huge red flag. For instance, if you've used Z3, you'll agree that it's black magic to everyone except the developers, and my professors confess that they've found correctness bugs, especially in decidability theories that are not commonly used."

<comment><USER21> I don't quite understand why Z3 is part of the TCB. Isn't Z3 generally used to generate proofs which are then verified by the respective proof assistant?

<comment><AUTHOR> Yes, if you use Z3 as part of a proof assistant like Isabelle/HOL or F-Star.

No, if you use Z3 as part of some other system that does not have its own primitive notion of proofs and proof checking. Many tools are like this: Dafny is one, I think, as is Why3, and the Alive system for checking the correctness of LLVM peephole optimizations. They simply trust Z3.

It's also used in lots of other things that are not "verifiers" as such. For example, to find new compiler optimizations by superoptimization: [https://arxiv.org/abs/1711.04422](https://arxiv.org/abs/1711.04422) (And sure enough, if you search the paper for "Z3", the first hit is a paragraph where the authors describe that they once had a miscompilation due to a bug in Z3.)

</comment></comment></comment><comment><USER22> It seems to me that the arguments here are fair, but maybe the conclusion isn't.

 _But the guarantees that we expect are much stronger than a correct protocol, handshake, or compiler optimization. We need the entire system to be reliable, and we need proof effort to be minimal for widespread adoption to be feasible._

Ideally, yes, of course that is true. But even if it is not currently true, having _some_ aspects of a system formally proven still means we can focus our limited resources on the other aspects and the integration, and that's still beneficial.

</comment><comment><USER23> Adrian Colyer's review of "An Empirical Study on the Correctness of Formally Verified Distributed Systems" covered in The Morning Paper

[https://blog.acolyer.org/2017/05/29/an-empirical-study-on- th...](https://blog.acolyer.org/2017/05/29/an-empirical-study-on-the- correctness-of-formally-verified-distributed-systems/)

Thank me later :)

<comment><USER24> No!

</comment></comment><comment><USER25> _Although the CompCert paper explicitly says that the parsing step, as well as the assembling /linking steps, are not verified, this kind of bug is a huge blow to the credibility of formal methods. It really makes you wonder what sort of bugs formal verification is supposed to catch._

That's strange I reach the exact opposite conclusion on this statement.

<comment><USER11> Author here. I guess what I was trying to say is that CompCert as a system has been trusted for over 10 years, yet only now do we find such a silly correctness bug. People won't read the paper to find out that parsing is unverified, they'll just trust CompCert because they hear it's been rubber- stamped as "formally verified". And that's dangerous.

<comment><USER4> A better way to do it is pull up C compilers, get their bug rates, and compare it to CompCert for both unverified and verified parts. First tests formal specs + safe language where latter tests verification. You can use smaller, C compilers if uou want to be fair. Two or three spec errors versus what you find in other compilers would corroborate CompCert team's claims. Likewise for verified TLS versus ad hoc protocols or implementations.

</comment></comment></comment><comment><USER26> The gap is IDEs becoming automated theorem provers. You put in the type signature of what you want and keep adding unit tests until the IDE finds the correct code for you.

<comment><USER27> Unity tests are not formal proofs.

Their philosophy are completely different. Formal proofs aim at proving the nonexistence of bugs, while tests (any kind of them) aim at revealing bugs in case you add them.

You can sometimes generate code form a proof, but you can't do that from tests.

</comment></comment><comment><USER28> I have begun to think of formal methods as a sort of tar pit. The idea is attractive to people who are concerned about correctness and are aware that you can reason about program behavior, but they do not yet provide a solution to the practical problems of writing correct software. On the other hand, this is not an excuse for abandoning any attempt at reasoning about programs, and settling for trial-and-error as the only way to write software.

</comment><comment><USER29> Formal methods have been verifying real world systems using ACL2 for a long time. Also, sqlite has 730 times amount of test code [https://sqlite.org/testing.html](https://sqlite.org/testing.html) .

Formal verification is not a magic bullet but it doesn't make your systems bullet proof though.

</comment><comment><USER30> Isn't formal verification subject to the problem of "when to stop proving correctness"? Even if you can prove one part you still have to prove that it's used correctly? Like in the WPA2 case?

<comment><USER6> You don't need to go all the way and specify/prove everything in order to achieve significant assurances of absence of (at least certain classes of) bugs.

See the section "Use SPARK at the right level for you" [0] for an example of how you can approach formal verification.

You can start proving certain things, like that your code is free from run- time errors, which already significantly eliminates a lot of bugs.

Then you can start proving certain properties, like it was done for WPA2, to make sure that at least those properties hold and are bug/error free.

Finally, you can achieve full functional correctness, which gives you a significantly higher assurance that your implementation really does satisfy your functional specification. You can start doing this in parts of the code, and progressively increase all the way to the entire code base if you so wish.

Every added formal verification step gives you higher assurance that your code works as intended.

Sure, you can never prove that your code is 100% bug free (this would require the functional specification itself to be bug free, and AFAIK there is no way to verify this), but I would argue that 99% verification is much better than 0% verification.

[0] [https://www.adacore.com/sparkpro](https://www.adacore.com/sparkpro)

</comment></comment><comment><USER31> What's really needed is a mathematical analysis of size of the bug space compared to the size of proving code required to cover it. I.e. to get to 99.5% confidence that a system of size N is bug-free it would take a proving system of size f(N). Is f polynomial, a small exponent, a large exponent? If it's a large exponent, then the more you take on, the farther you get from your goal, and the narrowly targeted efforts are the best we can do.

<comment><USER32> Off the top of my head, I would suspect that to be off in uncomputablity-land.

</comment></comment><comment><USER33> Some people work on monads over linear logic that supposedly could simulate any imperative program and make them available for formal verification, so we will see. OTOH I definitely wouldn't want to spend time proving correctness of every single line of code I write; it would make programming "no fun" zone and require rocket-science level of understanding.

<comment><USER6> > I definitely wouldn't want to spend time proving correctness of every single > line of code I write; it would make programming "no fun" zone and require > rocket-science level of understanding.

Fortunately, you don't have to. Formal verification can be done as little or as much as you want (and personally, I find it's quite fun, but that's subjective).

You can look at it like it's testing on steroids - you can not only verify that some part of your code works for certain inputs, but you can verify that it works for _all_ inputs! (for the definition of "work" that you decide to give it).

<comment><USER33> Yeah, it's fun to some extent; I still remember proving whole Peano arithmetic and then using that to prove functional programs. But doing real-world detail level I would probably go crazy fast; just making proofs some floating point computation does what it's supposed to would be extremely tricky due to bit- level stuff and stretching sparsity of representable numbers that could fit to xyz-bits of floating point.

</comment></comment></comment><comment><USER34> Interesting

I'm hoping the formal verification crowd will start to influence ethereum developers. You have small amounts of relatively simple code, that absolutely must be correct or at least predictable, seems like a perfect match

<comment><USER35> That's already happening. For example, see [https://runtimeverification.com/blog/?p=496](https://runtimeverification.com/blog/?p=496)

<comment><USER36> Also see [https://quantstamp.com](https://quantstamp.com)

</comment></comment></comment><comment><USER32> Wrong question.

The question that needs to be answered is not, " _But the guarantees that we expect are much stronger than a correct protocol, handshake, or compiler optimization. We need the entire system to be reliable, and we need proof effort to be minimal for widespread adoption to be feasible._ " (Pretend that's a question, ok?) The question that needs answering is, "what is the easiest way to provide (strong) guarantees that the code is reliable?"

If you wanted to write a filesystem, how much work would you have to put into it before you could consider it "reliable" using traditional techniques? If it is 10x more than it would take to simply write the code, then "MIT's FSCQ file system, developed over about 1.5 years using Coq, the complete system was 10x more code than a similar unverified filesystem. Imagine that — 2000 lines of implementation become 20,000 lines of proof!" doesn't sound so bad, does it? And 10x is not necessarily a bad estimate---unit testing alone would account for 2x, at a rough guess, and not only does it not cover all possible executions, it also has a reputation in this neck of the woods of focusing on the happy path.

"An Empirical Study on the Correctness of Formally Verified Distributed Systems" has been discussed here before ([https://news.ycombinator.com/item?id=14441364](https://news.ycombinator.com/item?id=14441364)) but I'd like to mention one quote from it:

" _Finding 9: No protocol bugs were found in verified systems, but 12 bugs were reported in the corresponding components of unverified systems. This result suggests that recent verification methods developed for distributed systems improve the reliability of components that, despite decades of study, are still not implemented correctly in real-world deployed systems. In fact, all unverified systems analyzed had protocol bugs in the one-year span of bug reports we analyzed._ "

(And speaking as a guy who has some network protocol experience, some of the bugs that were found in the "shim" layers were...likely caused by inexperience: no, TCP does not preserve write boundaries on the _recv_ end, and yes, UDP will duplicate packets under some error conditions.)

I will admit that many of the author's specific complaints are completely true. This quote should be in big letters in the introduction to any formal verification work: " _On top of all that, if any spec or implementation changes even slightly, all the specs, impls, and proofs that depend on it will change as well. This makes even small changes a huge pain._ " And Coq is something of a pain in the rump. (I encourage anyone with a few spare hours to work through _Software Foundations_ ([https://softwarefoundations.cis.upenn.edu/);](https://softwarefoundations.cis.upenn.edu/\);) it's a lot of fun but at the same time very frustrating. [That should be "many, many spare hours". --ed.]) The least damning thing you can say about Coq is that it's not very well engineered. On the other hand, SMT solvers like the kind of thing behind SPARK and Frama-C are brilliant when they succeed in finding proofs but when they fail,...well, they light up a "?" on the dashboard and expect the experienced driver to know what the problem is. Further, they're rather limited on the programming features you can use with them---Dafny and the Java verifiers have garbage-collected languages, alleviating some of the pain.

But still, to address the author's fundamental issue,

" _I went into the class believing that formal verification is the future — the only solution to a world of software ridden with bugs and security issues. But after recent events and a semester of trying to apply formal methods, I'm a serious skeptic. In this post, I'll discuss why I think formal verification has a long way to go — and why it just doesn't work right now._ "

Ya' got a better option?

<comment><USER27> > Ya' got a better option?

I don't think any clear-cut answer exists. For some applications (like your FS example) formal proofs are a complete no-brainier. On other cases, you are better served by many tests. On yet different cases, even tests are too much, and you will do better matching your code format to the specification as well as possible. Not to talk about the cases where specs validation is the real issue, and all your attention will be there.

It's not even an either-or issue. You can have all of those situations appearing on different places of the same code-base.

</comment></comment><comment><USER4> [Copying/pasting my reply to author in Disqus since at work. ]

Good write-up on the difficulties. The first I saw was Guttman's paper that set back the hype quite a bit:

[http://www.cypherpunks.to/~peter/04_verif_techniques.pdf](http://www.cypherpunks.to/~peter/04_verif_techniques.pdf)

His post and yours both oversell the problems while underselling the successes. It's best to keep big picture in mind. Yes, it's extremely hard. Yes, we shouldn't rely exclusively on it or have too much expectations. On Guttman's end, the Orange Book of TCSEC (later, EAL7 of Common Criteria) required many activities like I included in my own security framework:

[http://pastebin.com/y3PufJ0V](http://pastebin.com/y3PufJ0V)

Each was supposed to check the others. Each time, you want experienced people doing it since it's the people that make these processes work. What's mostly missing in this post and esp in Guttman's is all the evidence of defect reduction. Most of the work he cites were tracking problems they found throughout their lifecycle. They all said the formal specifications caught bugs due to ambiguity. Some found formal proofs beneficial with often mentioning "deep" errors they likely wouldn't find with testing or code review. TLA+ use at Amazon was great example where errors showed up 30+ steps into protocols. Most of old verifications found they caught errors just simplifying their specs for the prover even if they wouldn't run proofs. And for high-assurance security, the A1-class systems would go through 2-5 years of analysis and pentesting where evalutators said they did way better than systems using mainstream practices. Most of those can't even tell you how many covert channels they have.

If you're interested in methods that helped in practice, I dropped a start on a survey paper on Lobste.rs trying to shorten several decades worth of material into an outline post:

[https://pastebin.com/uyNfvqcp](https://pastebin.com/uyNfvqcp)

Now, all that said, full proof is hard with a lot of problems. You hit nail on the head about the infrastructure problem. I've always strongly encouraged people to concentrate on building up one or two projects to have infrastructure for most common ways of solving problems in programming with as much automation as possible. They have at least been building most things on Coq, Isabelle/HOL, HOL4, and ACL2. Having prior work to build on has been helping them. As you've seen, though, they've not made this a priority: the tooling still is horrible. So, horribly-difficult work with horribly-difficult tooling. That leads to the next proposal I did that might help you or some of your readers who want 80/20 rule of most benefits without most problems:

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

[https://lobste.rs/s/n7v658/your_thoughts_on_this_advice_thos...](https://lobste.rs/s/n7v658/your_thoughts_on_this_advice_those)

Here's some of those methods on top of the TLA+ and Alloy links:

[https://www.eiffel.com/values/design-by- contract/introductio...](https://www.eiffel.com/values/design-by- contract/introduction/)

[https://www.win.tue.nl/~wstomv/edu/2ip30/references/design-b...](https://www.win.tue.nl/~wstomv/edu/2ip30/references/design- by-contract/index.html)

[http://www.anthonyhall.org/c_by_c_secure_system.pdf](http://www.anthonyhall.org/c_by_c_secure_system.pdf)

[https://www.amazon.com/Building-High-Integrity- Applications-...](https://www.amazon.com/Building-High-Integrity-Applications- SPARK/dp/1107040736)

Here's my recommendation in general. Learn lightweight methods such as Meyer's Design-by-Contract for most stuff, TLA+ for concurrency/order, Alloy for structure, SPARK for low-level code, and so on. TLA+ on distributed stuff seems to sell people the most. With a formal method in hand, then apply this methodology: memory-safe language + lightweight method to model-check important stuff + Design-by-Contract + tooling to generate tests from specs/contracts + fuzzer running with runtime checks enabled. This combination will bring the most quality improvement for least effort. In parallel, we have the experts formally verifying key components such as kernels, filesystems, network stacks, type systems, compilers, security protocols, and so on. They do so modelling real-world usage with each one coming with contracts and guidance on exactly how they should be used. The baseline goes up dramatically with specific components getting nearly bullet-proof.

Also, you said you wanted entire system to be reliable. There was one that set the gold standard on that by noting how everything failed with systematic mitigations for it in prevention and/or recovery:

[http://www.hpl.hp.com/techreports/tandem/TR-85.7.pdf](http://www.hpl.hp.com/techreports/tandem/TR-85.7.pdf)

[https://en.wikipedia.org/wiki/NonStop_(server_computers)](https://en.wikipedia.org/wiki/NonStop_\(server_computers\))

The OpenVMS clustering software alone let their systems run for years at a time. One ran 17 years at a rail yard or something supposedly. The NonStop systems took that to hardware itself with them just running and running and running. Applying a combination of balanced assurance like I describe, NonStop techniques for reliability, and Cambridge's CHERI for security should make one hell of a system. You can baseline it all with medium-assurance using tools that already exist with formal verification applied to a piece of the design at a time. The work by Rockwell-Collins on their commercially-deployed AAMP7G's shows that's already reachable.

[http://www.ccs.neu.edu/home/pete/acl206/slides/hardin.pdf](http://www.ccs.neu.edu/home/pete/acl206/slides/hardin.pdf)

So, there's you some weekend reading. Merry Christmas! :)</comment>


Lime scooters are causing some issues for Brisbane's vision impaired community - <AUTHOR> https://www.abc.net.au/news/2019-01-21/lime-scooters-cause-issues-for-vision-impaired-residents/10731510 <comment><USER2> I loathe those scooters. We have about six different scooter companies here and they are a nuisance. They are left all over the place, in public walkways. And they are mostly ridden on sidewalks.

It still amazes me to see mostly healthy young adults that cannot walk a mile or two with their own legs.

<comment><USER3> Leaving them out and riding them on the sidewalks is definitely a problem.

But not wanting to walk two miles to a shop or restaurant is not a matter of inability or even of effort, it's a matter of time management. A two mile walk might be pleasant but would completely blow away my lunch break or interrupt progress on a project. There are limited options within a given walking radius, and adding a car, bike, or scooter makes this radius hugely larger. Parking a car or driving in traffic is a pain, so scooters and bikes are a useful - not lazy - solution.

We need ubiquitous scooter and bike racks, and respect from cars.

</comment></comment><comment><USER4> Anecdote. I was in China a few weeks ago, Shanghai to be precise. Me and my wife were walking around the city and there is scooters everywhere (the ones you sit on) and they're electric and because of this you don't hear him! A few times this caused me the scare the sh#t out me when suddenly one of these things comes from behind at high speed. Very annoying...

<comment><USER2> Yep, and most of the kids ride them like it's a race so they're weaving in and out of people like it's a race track.

</comment></comment><comment><USER5> I can't stand those scooters. Many people drive with them without being careful to other traffic. Some of them just swerve around in bike lined etc

</comment><comment><USER6> They're something of a plague in my home town as well, they're strewn all over the pavement/sidewalk/footpath(/whatever regional word), even when there was barely enough room for pedestrians.

Perhaps the users/distributors of these things aren't trying to come across as inconsiderate, but that's certainly the end result.

Pedestrians need their own space. These scooters shouldn't mix with pedestrian traffic at all

<comment><USER7> >Pedestrians need their own space. These scooters shouldn't mix with pedestrian traffic at all

Not sure how this is any different than suggesting that cars need their own space and that bicycles shouldn't mix with motor traffic at all.

<comment><USER8> Up to a point that's true. Low-speed roads are fine for mixing bikes and cars but once cars start going twice as fast as bikes (say, 40-50kph) you need separated bike lanes to have a safe biking experience. If you don't, bikes are likely to cause either massive safety risks or huge traffic slowdowns, which themselves can be a safety risk.

The same can be said for these scooters. Pedestrians walk at about 5kph; Lime scooters (at least the Lime-S ones) can go up to about 25kph. That's 5x the pedestrian speed; that's like biking on a road where people drive 100kph.

These scooters should be treated like bikes, not like pedestrians. A safe traffic segregation would be pedestrians separated from bikes separated from motor traffic, with anything going above 10kph classified as bikes.

<comment><USER7> It's suggestion that pedestrians and scooters not being able to share a space at all, that I find equivalent to a suggestion that motorists and cyclists should not be able to share a space at all. I also don't buy your suggestion that a difference in speed of 15-20kmph is the same as a 70-80kmph difference in speed. There's plenty of situations where it's safe to ride a scooter at 20kmph on a footpath, and from what I've seen, riding a lime on a foot path involves a lot of entirely safe speeding up and slowing down.

In an ideal world, there'd be enough room for cars, bikes, scooters and pedestrians all of have their dedicated space. But we don't live in that world. Few people would ride limes on the road, which wouldn't be any safer. If you were going to make anything illegal, banning riding scooters on the footpath would be about as good as banning them al together, and capping their speed at 10kmph wouldn't be much better. Why not just apply the same rules to scooters that are applied to vehicles? Carelessly driving a vehicle on the road is illegal, why can't it be for a scooter on the sidewalk? The lime riders who are considerate and slow down in busy areas aren't a danger or a problem.

</comment></comment></comment></comment><comment><USER9> Why not bill the rider extra if they don't return it to a designated parking area?

<comment><USER10> I'm a Brisbane CBD pedestrian.

Part of the issue is that there is no designated area so they are left either perpendicular to the curb on the road side of the footpath or next to the wall on the shopfront side.

I would assume Lime got a permit so Police can't simply hand out fines for obstructing the footpath.

The speed issue is also an issue but mainly of educating riders - I was almost run over last week when I started to move sideways hearing a scooter passing from behind on one side and narrowly avoided being hit by a second scooter passing on the other side - both traveling at full speed.

You don't see cyclists riding fast on the footpath where there are pedestrians - scooter riders don't seem to follow that etiquette. I much prefer the laws in Victoria where only children are allowed to ride on the footpath.

Is it because it is a paid service that they appear to feel entitled to go fast or weave in and out of pesdestrians where a cyclist would often dismount or go on the road?

<comment><USER11> They're legally forbidden on roads and even in the bike lanes [1]. I can understand the road lanes, but I think it's a bit insane to keep them from bike lanes. Either way, both the police and Lime (via the app) specifically direct people to only ride them on the footpaths.

edit for source: [1]: [https://www.abc.net.au/news/2018-12-23/the-rules- around-scoo...](https://www.abc.net.au/news/2018-12-23/the-rules-around- scooter-sharing-in-australia/10639170)

<comment><USER10> Not allowing them to use bike lanes seems crazy but I guess that doesn't fit the idea of them being a last mile option.

It takes 10-15min to walk Central Station to Eagle St so a scooter replacing a taxi/rideshare/bus and getting there in 5min makes sense.

Bike lanes in the CBD would be a good idea - instead we have bus lanes.

</comment></comment></comment></comment><comment><USER12> We've had them for a few months now where I live and I see them many times per day.

I think it's because pretty much every street here has a bike path, but I have yet to see people riding them in the way of pedestrians. I've seen one or two poorly parked ones, but they are usually parked next to bike racks.

I love that they have always on headlights though, with wind, rain and bad lighting here crossing a bike path is dangerous since so many don't follow the laws and use lights.

I just wish Lime-scooters were a bit cheaper (10 sek + 3 sek/min).

<comment><USER2> We have a lot of bike paths here but almost every scooter I see is on the sidewalk. I'd say fewer than 5% use the bike paths.

I do see some cyclists using the sidewalk, which is also very annoying.

</comment></comment><comment><USER13> Honestly the scooters seem like a reasonable idea, but they are being left everywhere in Brisbane, and also they're way too fast. Could bump them down to 25 or 20km/h pretty easily I would have thought.

<comment><USER2> I'm definitely in support of the scooters if they work with the city to ensure they stay out of walkways. The entire point of walkways are so that similar speed traffic is segregated together. Scooters are about 4x faster than a walking human.

</comment></comment><comment><USER14> TL;DR: people have not been trained in considerate scooter use, especially in pedestrian-dense environments.</comment>


You don't have to be "pro-nuclear" or "anti-nuclear." - <AUTHOR> https://www.vox.com/energy-and-environment/2019/9/6/20852313/cnn-climate-town-hall-nuclear-power-energy <comment><USER3> Placing some bets on nuclear make sense (France gets 80% of electric generation from nuclear) but counting on nuclear is risky because nobody can make nuclear plants cost efficiently anymore. America should probably keep trying on a small scale and if they can figure it, then ramp up. The big problem is that nuclear is essentially a big government project, and America is very bad at those.

<comment><USER4> > nobody can make nuclear plants cost efficiently anymore

Nobody ever could! Nuclear power generation, from its infancy, has been _outrageously_ subsidized, both directly (i.e. DoE grants, government funding of waste disposal) and indirectly (industrial-scale refining of fuel as a side effect of the weapons industry). Once those sources dried up it just plain stopped making sense.

At the end of the day it needs to stand on its own to make sense, and it can't, especially when compared to its green (and largely unsubsidized!) competitors. People who really want this to happen need to solve the technical problems and then come back with a plan.

To riff on the title: it's not "anti nuclear" to be anti-pro-nuclear. Make it work first before shouting about it on the internet.

<comment><USER5> Subsidized against what? It's main competitor, carbon, has the implicit subsidy of not having to account for the externalities in the waste it creates.

Against new green tech yes, it's a better argument.

<comment><USER4> > Against new green tech yes, it's a better argument.

Right, so I'll take cheap panels and turbines please. We should stop pushing the luxury reactors. We can't afford them if we actually want to spend the limited funds we have to save the planet.

</comment></comment></comment></comment><comment><USER6> This is bad writing for a lot of reason.

First the author tells us that if we consider ourselves pro or anti nuclear we can't possibly have thought through the pros and cons of nuclear power. It must be because we identify ourselves as left or right. Or green or not.

Then he tells us that if we _do_ have a policy position, we are probably wrong because "its complicated". All of which I find mildly insulting.

Then he proceeds to look at nuclear "purely though the lens of climate change", which as far as I'm concerned is not useful because many of the reasons one might choose to be anti-nuclear are not climate change related.

<comment><USER7> I found it good informative reading, compared to biased articles or comments that cover only one side. These articles are written for the masses, not people who have spent dozens of hours studying every nuance and came to an opinion.

If such people do comment on the article, I'd rather hope they comment on specifics rather than just say "writer is a snob, article sux".

<comment><USER6> My specific complaint with the article is that it's wrong and dangerous to consider nuclear through a narrow lens and therefore not a balanced and unbiased view.

<comment><USER7> The title of the article is "A beginner's guide to the debate over nuclear power and climate change", and is about the various perspectives of the DNC candidates in a specific 'Climate Change' debate.

Not sure how it's a problem that he's writing about it from a climate change perspective, and even has a disclaimer that it doesn't have all the details about the pro and anti nuclear debate.

>I'm not going to review all that history (it could fill a book); instead, I'll approach nuclear power purely through the lens of climate change.

<comment><USER6> Oh sorry, I thought that was obvious. It's a problem because you might read the article and start thinking that nuclear energy could be a reasonable solution to our climate change problem, but it can never be, for reasons that the author decided are outside the scope of his article.

</comment></comment></comment></comment></comment><comment><USER8> When Bernie/AOC lead with rhetoric like "climate change requires WWII levels of mobilization", it strikes me odd that they think that level of change is feasible, but that the unprecedented mobilization and centralization of efforts can't be applied to nuclear technology. It's bizarre and makes me think that it's a blatant political agenda much more than sensible application of technology to solve problems in the world.

<comment><USER9> What is bizarre about it? Not all options are equally good investments - <USER2> are clearly preferable over others. Why insist on new nuclear power when so much evidence shows it is not needed?

<comment><USER10> > Why insist on new nuclear power when so much evidence shows it is not > needed?

Which evidence? IPCC reports nuclear as being highly needed.

<comment><USER9> Which IPCC report recommends building new nuclear power plants in the US?

<comment><USER8> does the IPCC ever recommend exact allocations of power production per country? It seems like their report on Mitigation Pathways suggests a really wide range for nuclear, with the high overshoot pathway having an upper-bound of 7x increase in nuclear generation, whereas 5x upper-bound for low overshoot.

I find this line pretty interesting cause it suggests that people may very well arbitrarily ignore nuclear: "There are large differences in nuclear power between models and across pathways (Kim et al., 2014; Rogelj et al., 2018). One of the reasons for this variation is that the future deployment of nuclear can be constrained by societal preferences assumed in narratives underlying the pathways (O'Neill et al., 2017; van Vuuren et al., 2017b)."

</comment></comment></comment></comment></comment><comment><USER11> Interesting idea: you can opt out of identity politics.

<comment><USER12> People keep using this term. Is there a simplified no bullshit summary? I don't want to drown in a ridiculous Wikipedia article.

<comment><USER13> It simply means the process of politicians or normal people identifying with a specific group (other then the nation as a whole) and making that groups interest its primary concern rather then the nation or humanity as whole.

Or even simple the process of making policy turns into what are you and what are you not, rather then what are your actions or lack their off.

I the simply fact that you are born gay, straight, polish or any other identifiable group is what defines you and therefore defines your life.

</comment></comment></comment><comment><USER14> If it's really the case that the only way to make nuclear viable is to _deregulate the industry_ , then Bernie is absolutely right that we need to end reliance on nuclear power.

<comment><USER15> You can't have the real, workable New Green Deal without nuclear power. Anyone who says we're heading towards a climate catastrophe and is against 4th gen nuclear (thorium) at the same time is a hypocrite. Here we have something both sides of the aisle will support, irrespective even of their views on climate change, let's get to work and if there are safety concerns, let's mount an effort to address those. Once those are conclusively addressed, it will be easier to deregulate the industry and make it cheaper to build nuclear power plants. Thorium is abundant. There are now reactors that can utilize "nuclear waste" as well, so that problem could be solved too, I'm pretty sure.

I would be willing to bet that it will be dramatically cheaper than $10T "deals" floated so far. Shit, getting fusion to work with net energy gain will likely cost less than $1T all in all (although it'll take time).

If done properly, we could finally end up with electricity that's "too cheap to meter", and massively reduce the need for coal, oil, and gas, all without having to hobble the entire domestic industries and force them to burn coal in China instead.

<comment><USER16> "4th gen nuclear" that could utilize current waste is years or even decades away from commercial availability. If you want to bet everything on a potential future technology that doesn't currently exist why not choose nuclear fusion? That will really solve all your waste and fuel problems...

<comment><USER15> >> "4th gen nuclear" that could utilize current waste is years or even decades away from commercial availability

It's not: [http://www.world-nuclear-news.org/NN-Russias-BN-800-unit- ent...](http://www.world-nuclear-news.org/NN-Russias-BN-800-unit-enters- commercial-operation-01111602.html)

I agree with you on fusion. But as a stop gap, thorium and 4th gen nuclear sound awesome to me.

</comment></comment></comment></comment><comment><USER17> I have met with quite unreasonable (to my mind) fears about nuclear waste's supposed deleterious effects on people and nature, even if stored in a remote underground facility. Whenever people have gut reactions without evidence, the conversation quickly becomes non-productive.

<comment><USER18> Someone's "remote" is always someone else's backyard.

<comment><USER19> There have been a few [0][1] proposed storage facilities in the United States that have been stalled because of local NIMBY votes.

[0] [https://strangesounds.org/2014/06/us-nuclear-waste- storage-m...](https://strangesounds.org/2014/06/us-nuclear-waste-storage-map- this-map-shows-current-plants-storing-nuclear-waste-in-the-united-states-and- there-are-many-around.html)

[1] [https://trib.com/news/state-and-regional/govt-and- politics/s...](https://trib.com/news/state-and-regional/govt-and- politics/storing-nuclear-waste-would-only-net-wyoming-million- annually-/article_f38dee4e-9c16-5fae-bcbf-4c261250e406.html)

<comment><USER19> To be clear, I'm not attempting to pass judgement on people who vote this way. I would also vote "no" if someone wanted to store nuclear waste near my home. I'm only pointing out that storage is hard.

</comment></comment></comment></comment><comment><USER20> The main argument against nuclear is that it absolutely requires a highly educated, well organized society and workforce. If something really serious disrupts our elaborated, complex societies, then nuclear plants will become really dangerous.

With looming climate change, energy crisis, overpopulation and other problems, you can't be sure that we'll be in a stable enough world long enough to be completely safe.

<comment><USER21> This, like most anti nuclear arguments, is a standard that is _NEVER_ applied to other industries.

<comment><USER22> Which other industry can make an area uninhabitable for many decades?

<comment><USER23> Chemical processing plants? Water management?

</comment></comment></comment></comment><comment><USER24> > You don't have to be "pro-X"or "anti-X"

But don't we? We have to be completely polarized on every topic. How else will the binary political system survive?

OK, onward without the sarcasm ... This same kind of critical thinking must be applied to every issue, or we'll just end up in the dark ages again.

</comment><comment><USER25> How do plants deal with rising water from floods, or falling water from drying out, or overly hot cooling water from high temperatures? These are all in our future. I'm genuinely curious and not trying to troll

</comment><comment><USER26> Sorry folks give up the ghost nuclear was dead at least 3 decades ago. Solar and wind are the future. We don't have a decade to build a new nuclear plant, in that plan we'd need a time machine going backa decade to abate climate change that's now locked in. I'll spare you all the risks and externalities, it's just dumb. Again sorry.

<comment><USER27> You don't think we will need more power than solar and wind can provide in 10 years? Our energy consumption has historically only increased, even with strong conversation campaigns, we should assume this trend will continue.

<comment><USER28> > Our energy consumption has historically only increased

From what I can tell, energy consumption per capita is lower today than 30 years ago in many developed countries, including the US. While the rest of the world is far from reaching those levels of use, it may point to a cap in the need for more power.

</comment></comment></comment><comment><USER29> 50 years ago they said we would have fusion power plants in 50 years.

</comment><comment><USER30> Carbon neutral is a fancy way of saying "let's pollute the same as we do now". Generally achieved via fake offsets, as we do not have the technology to offset something like US pollution.

Even EU ETS (the most developed offset system) is much too slow to cause major dent in the problem.

Where most climate predictions require us to _stop altogether_ to avoid most painful results of climate change.

<comment><USER31> Context: very small western EU country.

Over here we are:

\- cutting down the very few square kilometers of forest we have because the EU declared that everyone has to be carbon neutral or pay fines, and 'wood pellets' are considered 'renewable' energy sources by the administration. The cabinet minister in charge has admitted to the absurdity but stated he is not going to stop the practice as this would lead to being fined.

\- keeping open severely damaged aging nuclear plants even when under the protest of several neighboring countries recognizing the dangers. The person in charge of this matter at the energy minister's cabinet just moved through he revolving door and got a very cozy 'job' at the company that owns and operates the plants. The energy minister was not amused as it is customary to await the next elections before cashing in and this person moved in a potential election preamble period.

\- The nuclear test facility operated by the government has once more run out of storage space for nuclear waste. In the 'good old days' they just dumped all the waste in the North Sea (it's still there), but now they have to store it. The cement vats they have been using were leaking in the past, and now they have ran out of space for storing them as the piles keep on growing.

Nuclear might be sound in theory, but humans just can't handle the responsibility in practice. And the one answer a neoliberal market economy based socio-economic system is incapable of providing is abstinence, as it is systemically antithetical to it and outside of its potential solution space.

<comment><USER32> I suppose you didn't mention the country in an attempt to not get criticized?

Because if you're talking about Belgium, half of what you said is plainly wrong.

<comment><USER33> Which half? Please elaborate.

<comment><USER31> I'm curious as well</comment></comment></comment></comment></comment>


Bezos Fortune: A Breakdown of the Amazon Billionaire's Assets - <AUTHOR> https://www.wsj.com/graphics/jeff-bezos-amazon-stake-and-other-assets/ <comment><USER2> Paywalled? Vague infographic - [https://si.wsj.net/public/resources/images/B3-CX966_201901_S...](https://si.wsj.net/public/resources/images/B3-CX966_201901_SOC1_20190118123506.png)</comment>


PSA: HN is being actively censored - <AUTHOR>

Try to provide nuance against the ridiculous notion that Reddit is a cesspool of right-wing toxicity but that ShitRedditSays is just misunderstood? Flagkilled.
Try to provide counterarguments against the reigning third wave feminist "women are oppressed in tech" narrative? Shadowbanned.
Instead it seems we're supposed to keep dredging up articles from the same unaccomplished tech personalities whose writing is a grab bag of 30 years of failed social science and confirmation bias elevated to the status of data.
Statistics is not magic, falsifiable science is not just a nice to have, and HN should damn well know better. <comment><USER2> HN guidelines mention that articles can be about "anything that gratifies one's intellectual curiosity".[1] Discussions about Reddit (or HN) being a cesspool don't seem to fall into that category.

[1] [https://news.ycombinator.com/newsguidelines.html](https://news.ycombinator.com/newsguidelines.html)</comment>