Malicious software libraries found in PyPI posing as well known libraries - <AUTHOR> http://www.nbu.gov.sk/skcsirt-sa-20170909-pypi/ <comment><USER2> Ok, here's some ugly backstory on this: This problem has been known for a while, yet both the pypi devs and the python security team decided to ignore it.

Last year someone wrote his thesis describing python typosquatting and standard library name squatting: [http://incolumitas.com/2016/06/08/typosquatting-package- mana...](http://incolumitas.com/2016/06/08/typosquatting-package-managers/)

However after that the packages used in this thesis - the most successful one being urllib2 - weren't blocked, they were deleted. Benjamin Bach was able to register urllib2 afterwards. Benjamin and I decided that we'd now try to register as many stdlib names as possible.

See also: [https://www.pytosquatting.org/](https://www.pytosquatting.org/)

<comment><USER3> This is a scary attack. One partial mitigation is to use a firewall (e.g., Amazon VPC network ACLs) to restrict outbound network traffic to a small number of known addresses like well-known repos. I can't think of a good reason why code in any well-behaved application should be allowed to make random outbound network calls.

I think it's also on app developers to rethink the culture of randomly grabbing packages to build applications quickly. This is already a security problem even with approved repos. Having a rat's nest of packages makes it hard to upgrade quickly when those repos post updates to address vulnerabilities.

Edit: Removed confusing statement about return connections

<comment><USER4> > One partial mitigation is to use a firewall (e.g., Amazon VPC network ACLs) > to restrict outbound network traffic to a small number of known addresses > like well-known repos.

That breaks down very quickly with the combination of public CDNs and TLS. I suppose you could do SNI based firewalling, but that is bit ugly, and afaik you can't do that easily with common firewalls (like netfilter).

<comment><USER3> As I mentioned above some of this goes back to application design. Ideally if you are layered correctly the application components of the system that own data should not talk to the outside world except in very narrowly circumscribed ways.

Unfortunately most real world systems that have internet access are created in far from ideal conditions.

</comment></comment></comment></comment><comment><USER5> Package managers seem to be an increasingly popular attack vector. It's only luck that none of the attacks have been particularly malicious yet. Considering how many package manager downloads go to a server in a datacenter, a widely distributed malicious package could control a botnet with extremely high throughput, or wreak havoc on any databases it comes into contact with.

It's only a matter of time before something like this happens. A big part of the problem is that application package managers, like pip or npm, are far less sophisticated than those of operating systems, like aptitude or yum. It needs to be easy for developers to open source their code, and to mark dependencies with precise commit hashes, but the download also needs to be secure and verifiable. There are many difficult tradeoffs to consider in terms of usability, centralization, security and trust.

<comment><USER6> Another fun fact to consider is that with many package formats, you can execute arbitrary code _at install time_ so if a malicious package can get into a repository, it's very likely to start compromising systems quickly.

Whilst a package manager repo. compromise would be the biggest bang in terms of attack, compromising the credentials of the developers of popualar libraries would be an easier attack (and indeed is already happening [https://twitter.com/chrispederick/status/892768218162487300](https://twitter.com/chrispederick/status/892768218162487300))

<comment><USER7> Doubly so since when installed on a server very often it will be done as "sudo pip install ....." (/s/pip/other-package-manager/ as needed)

<comment><USER8> I almost never see this. Even on systems that are only running a single python project, I only ever see folks use virtualenv. The only time I ever see things installed with sudo is when the package is being installed in a docker container.

<comment><USER9> This used to be super common, though. I see it all the time in legacy apps.

<comment><USER10> Yes – to the degree that it's uncommon now that's because many people in the community spent years loudly advising against it.

</comment></comment></comment></comment></comment></comment><comment><USER11> Yet another attack vector that doesn't exist at all in Linux distributions but invented by language package managers, sadly.

They solved the issue 2 decades ago by heavily vetting packages before accepting them into repositories. Users are allowed to add and use packages from 3rd party repositories.

Maybe solution to this is creating curated repositories based on publicly open ones and using them by default (and requiring opt-in for using other repositories). Conda for Python and Stackage for Haskell seems like relevant solutions.

<comment><USER12> Sure its nice (and easier) to use the distro's package management system, but it often just isn't up to date enough. You end up using thing that are a while out of date and may have security flaws as a result.

<comment><USER13> > using thing that are a while out of date and may have security flaws as a > result

On the contrary, on distributions that perform security updates the level of security of a package can only increase over time.

It might sound obvious but vulnerabilities are created in new releases, while vulns in existing packages can be only be found and fixed, not created.

(Of course I'm talking only about vulnerabilities here and excluding removal of obsoleted crypto or addition of new security features)

<comment><USER14> I would just like to point out that a "fix" for a vulnerability does occasionally introduce others.

</comment></comment></comment></comment><comment><USER15> It looks like the code phones home to a server in China:

IP: 126.96.36.199 Decimal: 2032851244 Hostname: 188.8.131.52 ASN: 37963 ISP: Hangzhou Alibaba Advertising Co.,Ltd. Organization: Hangzhou Alibaba Advertising Co.,Ltd. Services: None detected Type: Broadband Assignment: Static IP Blacklist: Click to Check Blacklist Status Continent: Asia Country: China cn flag State/Region: Zhejiang City: Hangzhou Latitude: 30.2936 (30° 17′ 36.96″ N) Longitude: 120.1614 (120° 9′ 41.04″ E)

<comment><USER16> When you go this adress [http://18.104.22.168:8080/](http://126.96.36.199:8080/)

"Hi bro :)

Welcome Here!

Leave Messages via HTTP Log Please :)"

</comment></comment><comment><USER17> This to me is the nightmare scenario. Well one of the two, the other one being that a developer of an obscure library I use has their password to PyPI compromised and a bad actor uploads a backdoored version of the library.

Fundamentally, the reason this is different from how thinks like Linux distos work is because Linux distros have maintainers who are in charge of making sure every new update to one of their packages is legit. I am sure you can try to sneak malicious code in, but it isn't going to be easy.

I am not advocating that PyPI (and npm) adopt the same model. That would be too restrictive. But maybe just showing the number of downloads isn't the best way to assure whether the package is legit. Perhaps some kind of built in review system would be nice.

<comment><USER6> A review system unfortunately isn't likely to be practicable with current development models. npm alone has over 500,000 packages ([http://www.modulecounts.com/](http://www.modulecounts.com/)) so even a one time review isn't going to happen.

If people want a more trusted solution the likely outcome is that they'll need to use a smaller more static set of libraries and then either do the audits themselves, or outsource that to a 3rd party.

Ofc with current speeds of change and deployments, it doesn't seem likely that many companies will adopt that model.

<comment><USER18> > npm alone has over 500,000 packages > ([http://www.modulecounts.com/](http://www.modulecounts.com/)) so even a one > time review isn't going to happen.

But at least the modules with the most downloads (webpack, react, or stuff like left-pad) could be vetted, and especially npm could implement a 2-or-more person model - basically, everyone with publish access can upload a new artifact, but to actually have it distributed to endusers, a second person would be required to sign off.

<comment><USER17> That's the thing. I worry less about popular packages. I can check that Django's GitHub repo links to PyPI and vice versa. But a random package to parse DSN's? I don't know it from Adam. I want to use it, and lots of others do too, but not everyone is going to review it. Maybe just a button on the package that says "I found insecure code!" Would be good.

<comment><USER18> > That's the thing. I worry less about popular packages. I can check that > Django's GitHub repo links to PyPI and vice versa.

I worry about the most popular, and there the small and next-to-unmaintained. Just think back to the left-pad desaster that broke builds all over the world and imagine it was not a deleted package but an update containing malware. I assume there are lots of such "hidden gems" where the maintainer has gone away... the consequences of hacking just _one_ improperly secured account are severe.

</comment></comment></comment></comment></comment><comment><USER6> This isn't, in any way, a new problem. I did a presentation on this topic for OWASP AppSecEU 2015 ([https://www.youtube.com/watch?v=Wn190b4EJWk&list=PLpr- xdpM8w...](https://www.youtube.com/watch?v=Wn190b4EJWk&list=PLpr-xdpM8wG- ZTcHhFfAeBthNVZVEtkg9&index=10)) and when doing the research for that I encountered cases of repo. attacks and compromise.

IME the problem will continue unless the customers (e.g. companies making use of the libraries hosted) are willing to pay more for a service with higher levels of assurance.

The budget required to implement additional security at scale is quite high, and probably not a good match with a free (at point of use) service.

<comment><USER19> If someone here wants to build a business around this, count me in for NPM (high willingness to pay) or PyPi (lower WTP).

Here's an idea: make it similar to Kickstarter, where customers can commit a certain amount of funds towards a specific package. If the package doesn't "tilt" in a certain amount of time money goes back. Otherwise you vet a point release and add it to your repo. you could offer subscriptions to keep packages updated or handle each update as its own project (with presumably lower costs if a recent release has been audited). Handling dependencies is key as an exercise for the reader

<comment><USER20> One thing to consider if you're going to provide a service like this:

What happens if a vulnerability nevertheless sneaks through?

The whoever did the vetting could conceivably get sued. So then they might want to take out insurance or try to protect themselves from lawsuits in some other way -- all of which is likely to make such a service even more expensive.

<comment><USER21> It has to be constrained to something reasonable. You can't guarantee the software is safe, but you can guarantee it is published by someone who is who they say they are, similar to EV certificates for domains. You can also refuse to publish packages with intentionally-confusing names.

<comment><USER20> _" you can guarantee it is published by someone who is who they say they are"_

Can you? Positively identifying people seems a pretty tricky and easily screwed up business.

ID's can be forged, and a web of trust requires, well, trust.

I guess such a service could say something like "we got this person's ID (and/or address)" or "here's this key's web of trust", and that would probably be a bit better than what we have today (which is virtually nothing), but it would still be a far cry from _" guaranteeing it is published by someone who is who they say they are"_.

<comment><USER21> EV certs have a complex verification process that can involve sending a physical representative from the company down to the place of business to confirm its presence/existence.

Bitcoin trading platforms have shown that compliance with AML/KYC regulations can be performed virtually by manual verification of a valid government ID, timestamped photo, handwritten note, and other mechanisms.

A company offering this service would go outside of the keyserver and verify the ID independently. It'd be much more of a "notarized packages" paradigm rather than just "published by 1337PyHax0r-88".

It is true that even extensive manual verification processes dependent on government-issued IDs can be faked, but there's a much higher bar involved.

</comment></comment></comment></comment></comment></comment><comment><USER22> I think a more Linux-like approach to package repos is better - a curated package repository run by volunteers in maintainership roles. Then you have a human being verifying the upstream and keeping malware out, and get more consistency across packages as a bonus. If you want your package added it's as simple as sending an email and provides a new avenue for people to contribute to the success of the ecosystem as package maintainers.

When you make the next big thing, consider this approach.

<comment><USER23> I don't think there are any maintainers that verify upstream code, they only manage packages and updates. Which is actually safer to do without maintainers, completely automatically, as it will eliminate a huge attack surface introduced by a maintainer.

<comment><USER24> Debian Developers are responsible of the package quality. Most package only well-known software that they are familiar with or read the code. Some do more thorough security audits.

Some security-sensitive packages are maintained by teams to share the workload.

<comment><USER23> They do a lot that could be and sometimes even is automated, but that doesn't help with security, only weakens it. Which is my point. It's better to automate package generation and trust fewer people, mainly the authors, not introduce maintainers into it.

<comment><USER25> Authors don't generate distro packages because there's too many distros and each distro needs to make changes that have nothing to do with code. Maintainers are necessary and a package signed by the author is a non-starter.

However, source code _can_ be signed and then used to make a package signed by a distro.

<comment><USER23> Think of it instead of allowing access to the system to maintain packages, we allow people to submit code that generates packages.

<comment><USER25> Of course you can do this - all packages are basically just wrappers around upstream code. But you still need someone to maintain the wrapper, and they have to check every new code release to see if there's something in the wrapper that has to change. And there are multiple distros. There's no getting away from maintainers with traditional linux distros.

Code package management is different. The author writes their software specifically to conform to the one code package management system. There's no wrapper glue needed, so you don't need a maintainer. Just release your new code and it fits into the system, and other code/tools/etc can just pick it up and use it.

This works if you constantly update all the software you use everywhere, and is pretty much guaranteed to become a nightmare if you don't. CPAN is probably the most mature software package management system in existence and it's still a nightmare if you don't keep a private repo and tightly manage releases, and you absolutely need a maintainer.

<comment><USER23> To be clear, what I'm suggesting is to generate those wrappers automatically, instead of maintaining them manually. A script can visit a release page daily, parse it and check for updates. If there is a new upstream release, it can generate a wrapper and let the build system do the rest, produce binaries, test them, etc. When things break, the code needs to be fixed, but it's definitely very far from every release. And you don't have to trust the maintainer of that script anymore or even have a separate maintainer, everything could be reviewed on pull requests with only a small group of people having commit rights to the repository.

<comment><USER25> That's basically how packages are maintained today, they just don't have as much automation and there's a lot less packages as a result. If you made one package for every software update and had to review each one you'd spend a lot more time reviewing.

Trust isn't an issue in reviewed/maintained repos because you have eyeballs on everything. When anyone can just ship an app/library and release it automatically you get these malicious software issues.

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER16> Related to this? [http://incolumitas.com/2016/06/08/typosquatting-package- mana...](http://incolumitas.com/2016/06/08/typosquatting-package-managers/)

<comment><USER26> That one is even more malicious, it uploads contents of your ~/.bash_history and system profile. But at least it notifies you afterwards...

<comment><USER27> Yes, but they do filter bash_history client side, only transmitting pip- related commands. They did this to find additional common typos. The relevant code:

      def get_command_history():
        if os.name == 'nt':
          # handle windows
          # http://serverfault.com/questions/95404/
          #is-there-a-global-persistent-cmd-history
          # apparently, there is no history in windows :(
          return ''

        elif os.name == 'posix':
          # handle linux and mac
          cmd = 'cat {}/.bash_history | grep -E "pip[23]? install"'
          return os.popen(cmd.format(os.path.expanduser('~'))).read()

</comment></comment></comment><comment><USER28> Both Anaconda (for Python, [https://docs.anaconda.com/anaconda/packages/pkg- docs](https://docs.anaconda.com/anaconda/packages/pkg-docs)) and Microsoft (for R, [https://mran.microsoft.com/](https://mran.microsoft.com/)) have "reviewed and audited" collections of packages for their languages. That's part of what you pay for when you buy support for the open source tools.

</comment><comment><USER29> Why is there no indication of any of this on the python.org website or any of their social media accounts?

I checked:

[https://pypi.python.org/pypi](https://pypi.python.org/pypi)

[https://www.python.org/blogs/](https://www.python.org/blogs/)

[http://planetpython.org/](http://planetpython.org/)

[https://pypi.python.org/security](https://pypi.python.org/security)

[https://twitter.com/pythoninsider](https://twitter.com/pythoninsider)

[https://plus.google.com/+Python](https://plus.google.com/+Python)

[https://www.facebook.com/pythonlang?fref=ts](https://www.facebook.com/pythonlang?fref=ts)

[https://twitter.com/ThePSF](https://twitter.com/ThePSF)

<comment><USER30> I guess that's because it's not a surprise. This has come up before, and it's basically unavoidable with the way PyPI is designed to work: if you see an unclaimed name, you can put whatever you want there.

<comment><USER29> I see your point, but I don't think that it needs to be a surprise to be announced or made well-known. No one is surprised that Microsoft releases loads of patches every Patch Tuesday, but they still publicize it and make it well known and easy for people to find out about.

</comment></comment></comment><comment><USER31> The regex they have for identifying fake/harmful packages is wrong.

`pip list –format=legacy | egrep '^(acqusition|apidev-coop|bzip|crypt|django- server|pwd|setup-tools|telnet|urlib3|urllib) '`

This incorrectly lists `urllib3` or the `cryptography` package for example, which are perfectly valid packages.

[UPDATE]

Read "tobltobs" comment below. I incorrectly removed a trailing space from the regex.

<comment><AUTHOR> I believe urllib3 is built-in. So if you have installed it from PyPI you've gotten a malicious version.

<comment><USER32> _urllib_ and _urllib2_ are built-in for Python 2, and were merged and reorganized as just _urllib_ in Python 3. _urllib3_ is a third-party module.

<comment><USER33> This is correct. In general, though, most packages don't rely on urllib3 directly, but on `requests`, which uses urllib3 but provides a friendlier API and built-in SSL cert verification.

</comment></comment></comment></comment><comment><USER34> "Success of the attack relies on negligence of the developer"

How about package manager managers accept their enourmous responsabilty? urllib vs urllib2, one is a virus? Sorry but that is not "negligence of the developer"

<comment><USER4> Managing supply chain is one the basic principles of good engineering. Not properly vetting your sources is negligence. The problem of course is that computers are really good at amplifying work, including mistakes. So small mistake, like a typo, could have catastrophic impact, like injecting malware that can take over the whole system.

</comment></comment><comment><USER35> How about a Levenshtein distance threshold for new package names to be accepted? I.e only allow names that are different enough from the existing set to avoid typos (or whatever errors we are trying to guard against)?

<comment><USER36> You don't need a strict ban for this to work either. Maybe just an end-user warning if distance < N and the relative popularity of the two modules is very high. You could also allow users or organizations to explicitly whitelist some names.

</comment></comment><comment><USER37> Any method of software distribution which is not rooted in cryptographic author verification against a fine-grained, user-manageable trust store should be put bellow the sanity waterline, 20 years ago.

</comment><comment><USER38> Here's something that contributes to typosquatting: the lack of responsiveness by package management organizations to claims on orphaned or unmaintainable packages.

People who upload packages often leave organizations, who are then stuck with a package they can't update because the password went with the person, and the email reset link points to a now-defunct email address.

Petitioning the package management team is sometimes fruitless, forcing a needless new instance of typosquatting.

<comment><USER39> I have found the PyPI group of people to be very helpful in these cases. You also should probably, as an organization, have more than one owner of your packages. That way, unless two people leave, things aren't orphaned. We have gone as far to have a 'meta-user' that is on all packages. It is only ever used to recover a fully abandoned package.

<comment><USER38> I understand you are trying to be helpful, and of course you are right, but the fact is that sometimes things fall between the cracks, especially in, say, hard-pressed startups.

There are so many _shoulds_ in the world that don't make it to _dids_ , it reminds me of the joke about the salesman trying to sell farming improvement techniques and being turned down by the old farmer, who says, "Son, I don't farm half as good as I know how to already."

Unfortunately, I have not found the PyPI group as helpful as you have. Perhaps I have been looking in the wrong places.

<comment><USER38> UPDATE: I was helped out by a very nice person from PyPI, so kudos to them.

</comment></comment></comment></comment><comment><USER40> Part of my dislike for the Node ecosystem in particular and I am sure others have a similar problem, is the dependency trees are super complex.

Because packages tend to be small and many, and each of those has their own dependencies, you can end up with hundreds of packages installed which is simply impractical to manually review.

It is not node, but we do in fact manually review each package we utilize for our given language because it's feasible and worthwhile as the dependency tree is small in this ecosystem. Each and every package is a possible attack vector whether that be intentionally or just because it's poorly written and we can't simply ignore that because it's the done thing and "the community reviews them".

</comment><comment><USER41> I bet there are quite a few malicious NPM packages that we do not know about.

Is Node is used in government and military solutions? If so then the NPM ecosystem is likely targeted by state actors, and it is a sitting duck.

<comment><USER42> State actors do not limit themselves to government and military targets; many of them target civilians for all sorts of purposes.

</comment></comment><comment><USER43> I once tried to upload a package called "requirements.txt" (since people do pip install requirements.txt all the time forgetting the -r).

Pypi actually blocks that name from being a package!

</comment><comment><USER44> Here is the general problem with dependencies:

When a dependency changes, all the projects that directly depend on it should get notified immediately and their maintainers should rush to test the new changes, to see if they break anything.

There is no shortcut around this, because if B _1_ , B _2_ , ... B _n_ depend on A _1_ , the consequences may be different for each B _k_.

The only real secure optimization that can be done is realizing that some of the B _k_ use A _1_ the _exact same_ limited way and thus make an intermediate A _1b_ that depends on A _1_ which those B _k_ 's depend on. These "projection" builds may be automated by eg the set of methods called by the B's.

Anyway, this is the way that iOS does it before iOS 11 comes out to users. They release a beta to all developers. And they even fix bugs in the beta before releasing to the public.

Without beta testing periods, you can get laziness and just auto-accepting of whatever cane out.

There is be an "alpha release" feature in git where maintainers might put out the next version to be tested by all who depend on it. _THIS FEATURE SHOULD NOTIFY THE MAINTAINERS SUBSCRIBED TO THE REPO. THE BUILD ITSELF SHOULD GET ISSUES AND RATINGS FROM MAINTAINERS AS THEY TEST THE NEW BUILD_. And releases should not be too frequent.

This is the way to prevent bad things from happening. But that also means that the deeper the dependency is, the more levels this process could take to propagate to end-users.

</comment><comment><USER45> I think we need a system to prevent this instead of the wild-west that PyPi has become. For example: Developer signatures that are checked against a community rating. If someone does `pip install` pip would look up the developer signature of the package and check a community rating that would verify this is a developer who has offered legit packages in the past. It's not foolproof, but it would go a long way towards solving this.

<comment><USER46> That sounds easy to defeat. Make some mundane, but legit packages (maybe on of those "$X but without the pointless complexity"-packages), gain trust, once trust is reached start uploading typo-squatting packages.

Knowing today's internet, programmers from cheap-labour nations (India & Co.) would soon start offering "trusted PyPi accounts" for sale on hacker forums.

<comment><USER45> Yes, but keys can also be revoked, providing a way to mitigate this.

</comment></comment></comment><comment><USER47> This is interesting in conjunction with the recent post about Python's popularity because that may be a weakness exploited here [1.]. It's easy to use and install and get libraries for anything, and apparently libraries for infecting your machine :(.

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

<comment><AUTHOR> The problem is that the vetting process of PyPI is completely inexistant. This has happened many times in the past, the last time I remember they uploaded a few libraries called "bs4" and stuff like that.

</comment></comment><comment><USER48> Relatedly: [https://github.com/pypa/pypi- legacy/issues/644#issuecomment-...](https://github.com/pypa/pypi- legacy/issues/644#issuecomment-305134745)

Also [http://evilpackage.fatezero.org/](http://evilpackage.fatezero.org/) / [https://github.com/fate0/cookiecutter-evilpy- package](https://github.com/fate0/cookiecutter-evilpy-package)

That one has neutered the call-home code by now, though.

</comment><comment><USER49> Would it be possible to have a general package manager (like apt) as reusable base for the individual language specific package managers? I know that npm and pip and gem etc all do some additional stuff, but at the core they all do the same (pull packages from repo, do some postinstall, resolve dependencies, maybe in some cases even check if the package is legit). So we could implement and check that once and then just reuse it like we do with many other libraries for image processing etc.

<comment><USER13> +1 to this. There's no need to reinvent the wheel a million times. At least having a shared standard on how to do packaging.

</comment></comment><comment><USER50> This is a known problem for a while. For example when we (RhodeCode) had an installer based on pip we actually rolled our own PYPI index. Having one you host is very easy and there are nice projects in existence that allowed that. It basically solved a problem of deployment when pypi wasn't available, speed up our test installer builds, and also total control over the packages we ship.

</comment><comment><USER51> Maybe packages should be signed by several trusted maintainers. Or, noticing PyPI packages list a source code link on github sometimes, along those lines, there can be a process to prove ownership of some known online identity, keybase style. Unpopular packages can also be flagged, especially one that has a near twin that is much more popular. There are many solutions.

</comment><comment><USER52> Unless your package manager enforces signatures and you trust the person that signed the package. Then this is an attack vector for you.

That includes Java (Maven), Ruby (Gems, Bundler), Node (npm), Haskel (stack) etc etc.

Installing code via package managers is the coders equivelant of opening up an exe sent to you in an email.

Code downloaded from the internet is not to be trusted.

<comment><USER4> Package signing is no silver bullet.

Signing packages helps against typosquatting about as much as SSL certificates help against phishing. Or in other words, not at all, especially if we don't have the certificates rooted in real world identities (like EV SSL certs).

</comment></comment><comment><USER53> Looks like they missed one:

[https://pypkg.com/pypi/xml/f/setup.py](https://pypkg.com/pypi/xml/f/setup.py)

Dork: site:[https://pypkg.com](https://pypkg.com) intext:"just toy, no harm"

</comment><comment><USER54> Hooray for the "wild west" model of package repositories.

Come back maintainers & packagers, all is forgiven!

</comment><comment><USER44> This is why I am not a huge fan of using package managers. I like to understand the code we put into our platform, and vet it. And not have it change under us automatically, after that, but review the changes manually before accepting it.

I felt a bit curmudgeonly but we have a responsibility at [https://qbix.com/platform](https://qbix.com/platform) for all our apps being secure. I wanted to use repos for each package and manually git pull or hg pull them when they changed.

I was finally convinced by our developers to just use package managers with version pinning. Honestly it's really hard to avoid package managers, especially for all the newer functionality such as Payment Requests or Web Push. Luckily there is version pinning.

We want our clients to feel secure that we vetted ALL the code that went into the platform. So our package json (and composer.json) uses version pinning. We'd rather take a bug report and manually fix it than NO bug report and have a SHTF moment.

</comment><comment><USER55> to see if you have any of these deps on your python path:

pip list –format=legacy | egrep -e '^acqusition$' -e '^apidev-coop$' -e '^bzip$' -e '^crypt$' -e '^django-server$' -e '^pwd$' -e '^setup-tools$' -e '^telnet$' -e '^urlib3$' -e '^urllib$'

to see if you have any projects in a given directory that require them:

cat $(find /path/to/dir -name 'requirements.txt') | egrep -e '^acqusition==' -e '^apidev-coop==' -e '^bzip==' -e '^crypt==' -e '^django-server==' -e '^pwd==' -e '^setup-tools==' -e '^telnet==' -e '^urlib3==' -e '^urllib=='

<comment><USER56> pip list --format=legacy | cut -d' ' -f1 | xargs egrep '^(acqusition|apidev- coop|bzip|crypt|django-server|pwd|setup-tools|telnet|urlib3|urllib)$'

</comment></comment><comment><USER57> well shit, I guess I should have followed up on this after I noticed it 2 months ago.

[https://twitter.com/JustinAzoff/status/881163562739277824](https://twitter.com/JustinAzoff/status/881163562739277824)

<comment><USER58> Yup, same: [https://gist.github.com/Spotlight0xff/829b7ebf32c4feec60ec44...](https://gist.github.com/Spotlight0xff/829b7ebf32c4feec60ec44eb86b0fb3f)

</comment></comment><comment><USER59> Whoa urlib & urllib3. Those are pretty popular packages, especially to newbies. Hundreds of websites that teach web-scraping use those libraries.

Wonder what is an effective form of protection against such attack vectors?

Do digitally signed certificates fit into this usage scenario??

<comment><USER60> > Do digitally signed certificates fit into this usage scenario??

No, because either the package author would have to sign them, in which case you have to choose to trust each package author, or the repository would sign them, in which case there would be no improvement for this current issue, since the repo would sign the fake packages as well.

<comment><USER59> Any way in which blockchain technology can be used? Like, the transaction becomes the act of the author uploading the code and the repo and user verify the transaction in some form?

<comment><USER25> Nope. You can't solve phishing with technological means. You have to curate either a whitelist or blacklist.

The best way to handle this is whitelists of trusted package maintainers and/or code authors.

<comment><USER60> To be fair you can do a lot with simple heurestics. New package + large number of downloads || new package || new package author = show users a warning message before installing the package.

</comment></comment></comment></comment></comment><comment><USER61> python-dev thread:

[https://mail.python.org/pipermail/python- dev/2017-September/...](https://mail.python.org/pipermail/python- dev/2017-September/149569.html)

</comment><comment><USER56> To check a few you different requirements.txt files (will look 3 folders deep)

find . -maxdepth 3 -name requirements.txt | xargs egrep '^(acqusition|apidev- coop|bzip|crypt|django-server|pwd|setup-tools|telnet|urlib3|urllib)'

<comment><USER56> Avoid some false positives

pip list --format=legacy | cut -d' ' -f1 | xargs egrep '^(acqusition|apidev- coop|bzip|crypt|django-server|pwd|setup-tools|telnet|urlib3|urllib)$'

</comment></comment><comment><USER62> I wonder if it's worthwhile having a check that compares closeness of the name to existing popular packages and if so does some extended vetting.

</comment><comment><USER63> Anyone know if this is also an issue for Java? I've used Maven repository for ages, and I know many big cos depend on it.

<comment><USER42> It's less of an issue, but it still could be an issue.

Deployed Maven artifiacts from Central are to required to be signed with a PGP key and are only supposed to come from approved hosts. I don't know how strictly that is enforced and how hard it is to become a host, but at least there is some kind of process.

Maven Central also doesn't allow the removal of artifacts after they've been published, and every artifact requires a unique version and name. And the names are namespaced. So you don't have the issues that you see with npm, where someone can pull a package and break everything people are using, and then some third party can come in and publish anything under the exact same name.

Is this model perfectly secure? No, you still have to trust that the artifact was signed by a non-malicious person from a host that was not compromised.

</comment></comment><comment><USER64> tiny open source project for this. [https://github.com/williamforbes/pypi_hacked_names](https://github.com/williamforbes/pypi_hacked_names)

</comment><comment><USER51> Maybe gov.sk should be vouched for too, I mean what's the chain of trust here? Why should I trust anyone?

</comment><comment><USER65> Do not forget their password that worked for couple of years: nbuSR123 ...

</comment><comment><USER66> Dry run?

<comment><USER67> The "malicious" code at the end of the advisory looks like nothing more than a beacon announcing it was installed?

      edit:
      get current working directory
      get username
      get hostname
      concatenate the last 3 together
      obfuscate(/encrypt?) this string
      send the result as a http request to 188.8.131.52 (the value of the base64 string)

<comment><USER68> # Welcome Here! :)

# just toy, no harm :)

</comment></comment></comment><comment><USER69> some of this could be helped by intelligent naming of packages. If something is called urllib, name the package urllib because that's what people are going to look for.

</comment><comment><USER70> Curious to know something similar happening for Scala.

</comment><comment><USER71> how likely is it that npm and other package managers that do not use digital signatures by default are unaffected?

</comment><comment><USER72> Python needs a way to run 2to3 during package installation that doesn't use setup.py (setup.cfg or wheels). As it stands now, you have the hassle of building a release four times if you want to support all combos of Py2, Py3, 32-bit, and 64-bit platforms. The absent support for 2 to 3 migration in the safer alternatives is why I stick with setup.py.

<comment> ThiefMaster- No, what you need to do is fix your package's code to work on Python 2 and 3 _without_ running 2to3 on it. The only case where this doesn't work is if you have binary extensions - but then you need separate wheels in any case.

</comment></comment><comment><USER73> I'm glad Go completely sidestepped the name-rush induced by this type of package managers (composer, cpan, rvm, pypi, npm…). Just provide an URL. Done.

<comment><USER13> ...which is even less secure.

<comment><USER73> May I ask why ? If anything, it's _more_ secure, since you know exactly who's publishing what.

Yes, it might put a higher burden on the publisher if they don't host on github/gitlab, etc.

But it strips the "magic" part and makes sure the dev knows where the code is coming from.

<comment><USER13> With packages identified by full URLs it's more likely to make a typo, or a misremember a part of the URL, or search for it on a search engine and pick a fork instead of the right one, or paste one from stack overflow or other forums that is plain false or even look legitimate due to unicode tricks. Also DNS MiTM/hijack can be used to inject a backdoor. Or the expiration of a legitimate domain.

<comment><USER74> You can also make a typo when all you need is a package name - as long as human beings have to type thigns out, that's going to be a problem. On the other hand, with a URL, you can actually inspect the code directly and (if it's hosted on Github or somewhere similar) see whether it's starred, forked or has any issues. It's not a case of URLs being less secure, it's just a tradeoff that pushes some of the security work to the community itself, rather than a dedicated staff of curators.

And since most package managers eventually resolve packages to a URL _somewhere,_ the issues you mention are probably present in other package managers, albeit hidden behind abstractions.

<comment><USER13> > You can also make a typo when all you need is a package name

"packagename" instead of a full URL is quite a difference. And you are not addressing the other risks.

> On the other hand, with a URL, you can actually inspect the code directly

You can do that with most package managers as they show you the upstream URL.

Expecting every developer and every system engineer to verify every package and every dependency they install is not "just a tradeoff". It's simply impossible.

> since most package managers eventually resolve packages to a URL somewhere, > the issues you mention are probably present in other package managers

Some check for the SSL certificate, some use package signing (e.g. APT). Also if the pypi domain expires everybody will know, unlike a random library.

<comment><USER74> >"packagename" instead of a full URL is quite a difference. And you are not addressing the other risks.

It is more characters, and therefore easier to misspell, but a URL also gives you a domain and probably a namespace for the developer, each of which can act as indicators of trustworthiness and help disambiguate packages with the same or similar names.

If you can't double check your spelling for a package name or you just pick the first Google result, or paste from SO, then you deserve what you get. Domain hijacking, MITM, Unicode shenanigans and such are real risks, but not of URLs as package identifiers per se, so much as risks of distributing packages over the internet, which most if not all do anyway.

>You can do that with most package managers as they show you the upstream URL.

But if you don't _have_ to deal with the URL, chances are you won't, and it's less likely you'll bother to follow it. I'm arguing that, if URLs are dangerous because of their length, then package names alone are dangerous because of their abstraction. I _know_ that I can probably trust including "[https://github.com/symfony/symfony"](https://github.com/symfony/symfony") but "symfony" or even "symfony/symfony" alone tells me nothing useful.

>Expecting every developer and every system engineer to verify every package and every dependency they install is not "just a tradeoff". It's simply impossible.

True, but Linus' Law is still basically the security model that's supposed to underpin open source software, even it it's proven not to scale as well as assumed. Someone, somewhere has to know the code is safe, and that's either you or someone you trust, or (as is likely the case with most developers) someone you just assume exists.

>Some check for the SSL certificate, some use package signing (e.g. APT). Also if the pypi domain expires everybody will know, unlike a random library.

There's no reason a package manager using URLs can't also require package servers (which, let's face it, are probably going to be Github and Bitbucket in almost all cases) or maintainers to do something similar. Or at the very least put out warnings the way browsers do about invalid or untrusted certificates or unknown domains. You would lose the freedom of the "wild west" model in its purest form but still not be tied down to a single source of authority.

</comment></comment></comment></comment></comment></comment></comment><comment><USER75> I'm all for security but this hit a nerve with me: "Success of the attack relies on negligence of the developer, or system administrator, who does not check the name of the package thoroughly."

Package managers need to do more. If they had an enterprise version that you could subscribe to monthly/annually invoice that you would get enterprises onboard, they are concerned about security and will pay. Developers like us will help encourage it. I'd rather not see some third-party "secure" package managers but make them part of PyPi and send funding to the Python foundation. They are seeking donations but that doesn't work well with businesses. Make it a monthly/yearly service.

<comment><USER76> There's written to check the package name and not to go through whole source code.</comment></comment>


A No-Frills Introduction to Lua 5.1 VM Instructions (2006) [pdf] - <AUTHOR> http://luaforge.net/docman/83/98/ANoFrillsIntroToLua51VMInstructions.pdf <comment><USER2> This is also the best internal opcode description for the LUA derived VM's: potion[1], sol[2] and tinyrb[3].

1: [http://perl11.org/potion/](http://perl11.org/potion/)

2: [https://github.com/rsms/sol](https://github.com/rsms/sol)

3: [http://code.macournoyer.com/tinyrb/](http://code.macournoyer.com/tinyrb/)

</comment><comment><USER3> This is pretty cool. Is there something like this for the LuaJIT VM?

<comment><USER4> See: [http://wiki.luajit.org/Bytecode-2.0](http://wiki.luajit.org/Bytecode-2.0)

Also running LuaJIT with -jdump will dump bytecode and compiler IR I believe.

</comment></comment><comment><USER5> I read this guide ALOT when trying to understand how a VM worked, this guide was invaluable. It gave me enough knowledge to write my own VM. Recommended!

</comment><comment><USER6> Let me guess, you were playing Hack 'n' Slash, and the control flow statements didn't make sense.</comment>


China Resurrects Great Cannon for DDoS Attacks on Hong Kong Forum - <AUTHOR> https://www.zdnet.com/article/china-resurrects-great-cannon-for-ddos-attacks-on-hong-kong-forum/ <comment><AUTHOR> Interesting how they do it. Injecting js to client pages on "great wall" to land on browsers where it is calling the targeted web site.</comment>


Can Economic Growth Last? - <AUTHOR> http://physics.ucsd.edu/do-the-math/2011/07/can-economic-growth-last/ <comment><USER3> I'm always a bit weary, when people rely on physics or rigid math to derive economic conclusions. In this case the author assumes _causation_ between energy production/consumption and economic growth. The conclusion being that since we have a limited capacity to produce energy on Earth and a limited ability to increase efficiency of energy consumption, growth is therefore limited. Which is true, given the above assumption holds. Real world economics is known however for messing up assumptions, however reasonable.

<comment><USER4> That's the nail on the head.

Once you start getting into these sorts of assumptions about trends and correlations, you really have to have a good understanding of all these inputs. They are all suspect to different degrees across different time horizons and scenarios.

What you really have when you put together these predictions is "Given A,B,C & D, this Y is likely to be whatever." That only works when you understand A,B,C & D quite well and keep them in your head. It's also bait for our biases and grand worldviews.

I had this massive argument 10 years ago with a politically active friend on the left. He was/is a sort of modern socialist-environmetalist. He brought up exactly this energy-gdp correlation and was extrapolating a log way into the future. It also played into his general sense that GDP growth is an unbecoming central goal for a society and that economic progress is at odds with the environment.

It's not a nonsensical perpective. That correlation _is_ relevant. But, you need to get into the subtleties.

Even the concept of "economic growth" is an abstract thing. GDP as a measure of economic output is becoming less and less useful metric. Wikipedia consumption contributes nothing to GDP. Some kid torrenting game of thrones contributes nothing to GDP. These things have value, but monetary exchanges are not good proxies for them.

Even within the "energy intensive manufacturing" paradigm, an iphone's utility-to-energy cost ratio is a funky thing to try and fit in to the GDP concept which ultimately uses money to measure value. A 2015 iphone is worth more than a 2010 iphone. You can see this if you try to sell one and if you could go back to 2010 in time with a box of 2015 iphones you would see it as well. But beyond that, trying to do price adjustments (which are the basis of "keeping interest rate constant") on a rapidly developing technological product puts you in the weeds.

This complexity is exactly why these correlations and trends are interesting They cut through the messiness. I think we should still do this. But… you need to treat these in the same way you'd treat Kurzweil's theories. Interesting, but built on a lot of unknowns. Too many to make you too confident.

<comment><USER5> The thing that makes GDP unsuitable in my view is that it measures destructive activity as being equal in value to constructive activity. You tear down a house, build an identical one in its place, and while nothing of value has been created, the GDP has received a sizable boost. Yes, people got paid for doing those things, but it would have been better had they been paid to produce something of value instead.

<comment><USER6> It's well-known that GDP is susceptible to the broken window fallacy because it doesn't measure destruction of capital. Consequently, it dramatically overstates the GDP of resource-rich nations. When Saudi sells a barrel of oil, that $75 is counted towards its GDP. But the actual value-add is $75 minus the value of oil in the ground, which is a much smaller number.

<comment><USER7> So why do we bother with it?

</comment></comment></comment></comment></comment><comment><USER8> _So linear growth starves the economic beast, and would force us to abandon our current debt-based financial system of interest and loans._

Debt, interest and loans are not dependent on economic growth. Debt is fundamentally about reducing the latency between consumption and production; rather than having to wait until after you've produced something of value, you can consume some of that future production today, in exchange for promising to divert some of that future production. There's nothing here that requires the whole pie to keep on growing.

<comment><USER9> If Fred and Ginger are an economic system whose total value at time t is $1000 (all of which is in Ginger's bank account), and Ginger loans Fred $500 on the promise that he'll pay her $600 at time t+1, then their agreement is predicated on the assumption that the Fred/Ginger economy will have grown 10% at time t+1.

<comment><USER10> No, Ginger could take a small nap and pay Fred a 100$ to do some work for her that she would normally do. Then, Fred would have 600$ to pay her back, and the economy's output would stay the same.

<comment><USER9> True, and some portion of lending is no doubt exactly that kind of shuffling. But the total amount of debt also includes some proportion of Gingers who lent more than they can nap off.

</comment></comment></comment></comment><comment><USER11> A criticism which seems to be gaining traction is that many traditionally held economic beliefs were not sufficiently established by data, with their adherents often being satisfied with a (single) model, consistent with a limited set of observations. The rise of advanced statistical methods with vast amounts of data is a relatively recent phenomenon.

A purported major factor in the collapse of Lehman Brothers was that their economical models failed to anticipate a dramatic drop in property prices because they didn't include data reaching far enough into the past.

Much of the machinery for large scale data analysis was developed in the context of trying to understand complex physical systems. Even basic linear regression has its roots in the study of celestial mechanics by scientists such as Laplace and Gauss. Von Neumann was the co-creator of game theory, John Nash proved its foundational result. Economics is not beyond the analytical abilities of physicists and mathematicians to investigate, although certainly they benefit from collaboration with domain experts to resolve basic misunderstandings.

Ignoring energy and entropy in a dynamical system does seem a bit curious. It's not really clear that GDP can be made both rigorous and meaningful in the sense of these thermodynamic terms. David Goodstein points out that oil companies haven't produced a drop of oil in their entire existence. They simply process the oil which biophysical forces produced over a hundred million years. This oil (and all other fossil fuels) will run out in something on the order of 100 years. After this, civilization will end. I find his prediction difficult to dismiss, although not a foregone conclusion. All the solutions to the problems Goodstein raises remain speculative.

<comment><USER12> There is several hundred years worth of coal in the ground. Further civilization only started using oil very recently. It's loss mipay seem huge but it's not that important.

<comment><USER11> Since our energy consumption has grown exponentially in modern industrial times, most of the energy consumed has been during the age of oil. Further energy is not the only dependency modern civilization has on oil.

You can't glibly dismiss Goodstein's analysis. He addresses this belief (canard) that we have hundreds of years of coal in the ground, or that the resource limitations which restrict the future of oil do not also apply to coal. To replace the energy, fuel, industrial and agricultural uses of oil, coal consumption would have to increase by at least 5x, with catastrophic environmental consequences. Goodstein also points out the unreliability of estimated reserves, which in many cases are political rather than scientific.

<comment><USER12> Actually farming still consumes vastly more energy than oil has provided. 1kw / m^2 is a lot of energy even if plants suck and significant parts of the globe have been under cultivation for thousands of years.

[http://www.zmescience.com/research/us-navy-synthetic-jet- fue...](http://www.zmescience.com/research/us-navy-synthetic-jet-fuel- seawater-0423432/) _US navy synthesizes jet fuel solely out of seawater; costs $3-6 gallon_

Wind is already cost competitive with coal. Sure, if oil was going to run out in 10 years that would be a huge issue, but when we have 50+ years to deal with the issue and it's bound at ~3x current costs it's just not that huge of a problem.

PS: The navy is interested in this because shipping fuel around is a major issue for them where nuclear reactors can provide plenty of energy.

</comment></comment></comment></comment><comment><USER13> Very interesting article. In human history, we have always had periods where growth comes from expansion and then periods where growth comes from innovation.

Globalization was an expansion-driven growth phase and we have reached the end of what it can do for global growth - yes there are regions that are still catching up with the rest of the wrold but barring Africa, their population is relatively small so their catch-up will not contribute to significant global growth.

We have transitioned into an innovation driven growth-phase now. We'll have to wait for it to start to sputter before we know what kind of expansion-driven growth we will see next.

I like the fact that the author thinks of "what comes after" because a lot of the green efforts that we are seeing are looking to prevent climate change/global warming and not enough of preparing for the eventuality that our preventive actions may fail and what would the world look like if we failed and how do we survive & benefit from that.

</comment><comment><USER14> Very nice article, along the lines of The Limits to Growth.

It is a big question if technology can solve all of our problems.

Technology is definitely a part of the solution but human mentality has to change. Most of the people care about their preferences and standards of living, they do not care to look, nor are they interested in participating in solving the problems of the global scale. When this is the case, it's quite hard to shift to something more sustainable.

Through my readings about sustainability I've always been left with a very weird feeling. I'm perfectly aware of what the subject is about, but I can't seem to find any solution that would divert us from the current path, and authors are mostly just commenting on the current situation, being themselves perplexed by the possible solutions.

</comment><comment><USER15> It might be interesting to think about the theoretical endpoint for farming. The number of workers needed went down dramatically when they were replaced by machines. In theory the machines could be made cheaper. What's left? The land and other physical resources like water. Land gets a certain amount of solar radiation that's converted into food. Available farmland goes down as it's built over, but that can't go on forever. Eventually, there's going to be an equilibrium since available sunlight is limited. Or we find another energy source (let's say nuclear) and need to figure out where to dump the heat. In the limit it's about global warming.

Contrast with entertainment. What theoretical constraints are there preventing all the entertainment you could possibly want being available for free? In the end it's not going to take a big solar panel to power your entertainment center. I'd bet on entertainment getting cheaper faster than anything else once AI really kicks in.

It might be a while before physics wins, though.

</comment><comment><USER16> Yes, it can, if we keep being ambitious as a species. I believe we did not even touch the real potential so far. There is an entire Universe out there, incredibly hard problems not yet solved (i.e. aging), are we really saying that this is it? I believe not, so economic growth will not only last, but it will be even higher if keep pushing our limits.

<comment><USER17> What makes you so confident? The author does address the idea that somehow technology might fix our problems.

<comment><USER16> The fact that growth is really the only way. If you think about it, everything we achieved has been through growth (i.e. how China managed to bring millions from below the poverty line in few decades). We face enormous challenges (i.e. 7 billion people on the planet), without growth we are pretty much doomed.

So, it's not so much about confidence, I think is rather hope for us as a species.

<comment><USER17> Well if growth is both the only way and unsustainable then I guess we're in trouble.

</comment></comment></comment></comment><comment><USER18> Economic growth could theoretically last, the problem is that the system is no where near properly structured to not cause deliberate bubbles and bust. It is odd that only very few people understand what the fundamental cause of economic growth, bubbles, and bursts is. They can all be tied back to deliberate manipulation to edge one group higher at the expense of another. The trite saying is true, economics is not a zero sum game, but besides that being totally irrelevant and a red herring to disperse challenge, the economy is very much not an infinite system and directly tied to the extraction of resources, whether natural or human.

</comment><comment><USER19> Of course economic growth can last. GDP is just a number, in nominal currency, that measures not just sheer output, but also efficiency, technological progress, etc... In an idyllic future, when we're no longer extracting oil from the ground, no longer working manual labour jobs, etc..., economic output may reflect technology and ideas being created, the dollar will be worth much less (thus more nominal output), and as long as people are engaged in some form of economic activity (buying something, working in any form), we'll have measurable growth.

<comment><USER20> Nominal GDP growth and real GDP growth are very different things, and it's the latter people are referring to. If it was only nominal that mattered, we could have a arbitrary economic growth through inflation.

<comment><USER19> Even 'real' GDP numbers are boosted by inflation (ie. the price levels of everything rising over time, not just the devaluation of currency). Real GDP is still just a number to compare output between two points in time, still measured in nominal currency (albeit inflation adjusted for say, a 15 year difference). The calculation of 'Real' GDP still is limited, only useful for comparison purposes.

Several generations ago, some of my ancestors (my great grandparents) came here and bought their farmland for $10. Now I can barely buy a beer for 10 dollars. Yet we don't measure GDP in 1900 dollars, or in year 3000BC shekels.

Regardless, in many ways, my beer today IS worth more than a farm in 1900. My beer was made because of generations of farmers growing grain, building up their homesteads, brewers buying equipment and employed generations of employees, farming equipment improving efficiency, and everything else that goes into the supply chain. Simply put, the value of technological progress is built into current price levels.

</comment></comment></comment><comment><USER21> If economy grows 3% per year and efficiency gains are 3% per year, energy consumption does not grow until we hit the floor where increasing energy efficiency takes too big investments.

In practice demand and size of the markets limit potential for growth more than physical limits. Population is important factor both in supply and demand.

Even if automation increases, people as the source of demand are important. Investing into microprocessor plant that supplies 10 billion people has different risk and profitability than building similar plant to supply demand from 5 billion.

</comment><comment><USER22> The answer to this question is really simple. It's not complicated at all. Allow me to explain.

Finance has abstracted economics from the real world into mathematical magic. People get into these complicated debates about concepts, acronyms, abstractions and GDP, when the reality is right in front of your face.

Think about it: In what reality can economic growth continue indefinitely into infinity? In what reality is there an unlimited supply of goods to satisfy boundless demand?

Let me say unequivocally the answer to the question: can economic growth last?

NO.

<comment><USER19> > In what reality can economic growth continue indefinitely into infinity? In > what reality is there an unlimited supply of goods to satisfy boundless > demand?

There doesn't need to be an unlimited supply of anything except economic activity. Economic activity is defined more or less as any exchange of goods and services (including labour). If I decide to go to the pub and recite poetry, and someone decides to give me money for reciting poetry, we have economic activity.

Another example. Take a brand new model year 2015 automobile, and contrast to a 2014 model with the same badge. The 2015 will be priced higher. Why? Because we assume it's better - more technology, maybe more features. Even if both have never been driven off the lot. Another poster made the comparison between a 2010 and 2015 iPhone. Even if both are in the original packaging, there will be a price difference.

It's in this way that technology is factored in to economic growth. In the future, as long as technology increases (which it likely will), even if the output of raw material decreases, even if we don't pull out as many resources, economic activity can still increase in value.

> Finance has abstracted economics from the real world into mathematical > magic.

To a certain degree, yes. Much like computing has abstracted transistors and electronic circuits into something that allows us to write plain English into an abstraction (HTML and such) that's interpreted through another abstraction (browser) that's implemented on top of another abstraction (OS) that's implemented with another abstraction (compiled language) over a language (assembly) that's a nicer façade over what the hardware actually interprets (machine language).

The language of Economics allows us to quantify what happens in the real world, and create abstractions to allow us to make sense of how it all works.

<comment><USER22> Buddy, abstractions aren't magic built on top of thin air. Abstractions can be built upon abstraction and can be built upon other abstractions but when you follow the supply chain all the way down to the logical conclusion you will hit a physical road block grounded in reality. Eventually there will be an abstraction that must be built on top of a concrete primitive.

What is this primitive thing at the end of the chain? Energy and material. Think about it. Your poet, in order to have the luxury of writing poetry instead of foraging for food must have physical requirements to assist in his writing of poetry. He must eat food, he must have shelter and materials to support his endeavor. When you give money away for poetry you are giving money away for concrete things. You are paying for his food, you are paying for his shelter, you are paying for his leisure time to allow him to practice his poetry. Food comes from plants, plants can only grow with sunlight... aka energy. Eventually the chain must end at a physical primitive.

Lets talk about a hypothetical island economy with a population of two people. Let's say these two idiots are poets. You cannot have an economy of two poets where both poets pay each other to recite poetry. The poets will eventually die of starvation. It's a mutually recursive abstraction that never ends and is unsustainable; An abstract infinite loop with no primitive at the root. TO fix: put a farmer on the island and have the farmer give food to the two poets in exchange for a recitation. Boom, there's a real economy. An economy of pure abstraction only exists in your imagination and even your imagination needs food for sustenance.

So when we talk about economics, when we talk about programming, we are not talking about magical abstractions built upon nothing. We are talking about reality. An economy will always be bounded by the physical limitations of the world because abstractions are built on top of the physical world itself, the two are one and the same thing.

Ironically the primitive in economics is the exact same primitive in the programming universe: Energy and material are the same thing as Procedure and State. The philosophical implications are profound. Even crazier is when you follow the chain in the programming universe you will find out that both state and procedure are abstractions on the same thing: Silicon and electricity. What is silicon and electricity? Material and energy. Yes that's right, not only is economics bounded by reality, but so is the world of programming, so is the concept of abstractions.

<comment><USER19> > What is this primitive thing at the end of the chain? Energy and material.

With nuclear fission power, we have a very large amount of energy available for the future. With nuclear fusion, potentially much more. As for materials, we can recycle most of them. And who's to say in the future we won't be mining asteroids?

I'm well aware that economics, in the end, is about raw materials, manpower, etc... After all, the first economic 'transactions' involved people cooperatively gathering food, building shelter, etc... (ie. you build a shelter and make a fire while I find us a rabbit to roast)

However there's nothing to say the future won't consist of a world powered by nuclear fusion (or some yet-to-be discovered method of energy production), where all labour is done by robots, where we're all given Star Trek-style 'credits' with which we pay each other to recite bad poetry.

Also keep in mind that economics didn't start with Keynes or Smith, or even Ibn Khaldun. The ancient Mesopotamians kept exhaustive records, had commodity- backed banknotes/tokens, units of precious metals (shekels), rules governing finance, and debt, etc... Modern economics isn't any different (fundamentally), we just now have more things to measure, and more abstractions to make sense of the endless complexity of a modern, global economy that has 7+ billion actors in it...

</comment></comment></comment></comment><comment><USER23> Is the "but at that kind of energy output we'll boil the planet" limiting case really a hard limit though?

If we're at the stage of having super-dense energy sources and super-tech, couldn't we we use those to cool the planet effectively?

Use a heat pump to move that heat off-planet? Drop some icy asteroids in the seas? Take compressed hot atmosphere off-planet in super-blimps, run it through a heat exchanger on Titan and then bring it back?

<comment><USER24> In the end the resources available to a civilization can only expand as the third power of time due to the speed of light limit. That means that the laws of physics do prohibit an indefinite exponential increase in energy use, baring new discoveries that look pretty unlikely.

</comment></comment><comment><USER25> disclaimer: I haven't read the article very well. If you don't feel like reading some drivel don't read any further.

My hunch is that this is the wrong question to ask. Tackling economical issues like this is like wanting to start working out and then spend all your time discussing the best(TM) fitness routine online. No amount of math will save us. After all those years of rapid economical and technological progress we have to acknowledge that it's the human factor we have to work on the most.

Economic growth is a tool and we can not use it very wisely as we haven't figured out our society's real needs all that well. We lack collective tacit knowledge so to speak. That what we can codify (at least at the moment) isn't enough to solve our problems.

But I think the author is right that a zero-growth economy should be the goal. Because only then resources of all kind _could_ be perfectly allocated. However, this assumes that the perfect allocation of resources is a.) possible and b.) desirable.

</comment><comment><USER26> It seems to me like the TLDR of the article is

1\. Energy use per capita cannot grow indefintely. - <USER2>

2\. The economy cannot grow without energy growth - Disagree (see chart in [0] shows that energy use per capita peaked in the 1970s and we most certainly have had growth since then)

3\. Our current economic system is based on growth and would collapse if we didn't have growth. - Disagree (he just kind makes this assumption and doesn't go into details)

4\. We should transition to a steady state economy - Disagree (Why should we stop growing now to avoid the potential problemof not growing in the future.)

[0] - [http://www.npr.org/sections/money/2013/04/10/176801719/two-c...](http://www.npr.org/sections/money/2013/04/10/176801719/two- centuries-of-energy-in-america-in-four-graphs)

</comment><comment><USER27> To answer the title: Yes, because population growth can, in theory, continue indefinitely. Assuming, of course, that we're not restricted to one planet. :)

<comment><USER22> No theory states that population growth can continue indefinitely. Growth is not only bounded by space availability, but energy as well.

<comment><USER27> I mean --- sure, fair. "Indefinitely," was the wrong word if we're going to be pedantic. But there's certainly orders of magnitude more space and available energy in the Universe than on Earth alone, so we're not restricted to just growing on this planet.

</comment></comment></comment><comment><USER28> For perspective, if could invest one cent in a fund that grew at 2% annually over the last 2000 years, you would have 1.58 quadrillion dollars today.

</comment><comment><USER29> > Can Economic Growth Last?

Not if a big chunk of the growth comes from the entertainment industry (Netflix et al.)

</comment><comment><USER30> Nominally, yes.

The mistake here is to assume there is a hard link between nominal growth and energy use.

</comment><comment><USER31> Natural brake for economy is when scammers that call themselves "socialists" come into play. They prey on people's desire to get rewarded for doing nothing. They promise to rob hardworking people of their income in exchange for votes.

</comment><comment><USER32> i want to point out just one thing - the problem is not in banks per se, the problem is merely in the expectation that interest rates have to be positive ;)

</comment><comment><USER33> Despite my last name, I'm skeptical about predictions that growth will foreseeably slow down or cease entirely. I believe it was Jim Manzi who coined the concept of the "Icarus Fallacy," in which the experts of each decade invariably predict an energy crisis 30 years hence — just after they will die.

Does this demonstrate that current, analogous predictions are false? Certainly lot. But Bayes theorem dictates that the similarity decreases the confidence that one should have in contemporary climate science.

I have neither the time nor the inclination to remain current on cutting-edge climate science. Whenever I check in, I find that the critics seem to be getting the better of the argument. But I profess no expertise.

I do, however, consider myself reasonably qualified to opine about the state of AGI research. And, despite more than a decade of trying, I have no idea when to forecast the emergence of AGI. I would not be shocked if it happened tomorrow, nor would I be surprised if it occurred 300 years from now — or not at all.

I am, however, confident that the emergence of AGI will radically alter the state of the earth, thereby rendering virtually all pre-AGI predictions worthless. The population trends of Africa mean little if some Western nation unleashes a digital demi-god capable of reshaping the earth in its image.

The IPCC's failure to account for this effect, which I believe in quite strongly, does not inspire confidence in the reliability of its other data. I do not, of course, mean to imply that it would be reasonable to expect an international panel on climate change to address the risks from artificial intelligence. But that is because there are so many different contingencies that it is silly to make projections so far into the future. It is not at all clear that an energy crisis is even the greatest existential threat that modern man faces.

<comment><USER14> > _I do, however, consider myself reasonably qualified to opine about the > state of AGI research. And, despite more than a decade of trying, I have no > idea when to forecast the emergence of AGI. I would not be shocked if it > happened tomorrow, nor would I be surprised if it occurred 300 years from > now — or not at all._

I'd be surprised if it comes tomorrow. The leading scientists have little belief that their current methods could be easily adjusted for AGI. All of the leads in AGI currently can't even simulate the problem solving skills of C. elegans. There's not a single AGI project that accomplishes the same skills of a specialized model.

<comment><USER33> >There's not a single [public] AGI project that accomplishes >the same skills of a specialized model.</comment></comment></comment>


Fakeblock is real - <AUTHOR> http://www.fakeblockisreal.com/

<comment><USER2> "Check out this facebook page... That's right, not a single friend"

LOL

</comment><comment><USER3> 1 - Take idea from Arrested Development 2 - Make website 3 - Sell $.99 iPhone app on website 4 - Profit.</comment>


Sony, Nintendo, EA hide behind PR move. Still support SOPA - <AUTHOR> http://www.destructoid.com/ea-nintendo-sony-reduce-sopa-support-by-50--218742.phtml

<comment><USER2> While I agree they were supporting it twice, and now only once, they did remove the support that they actually control. While each company is part of the ESA, they don't control it.

The ESA will have to take that action itself. Maybe it will get a clue from it's members.

<comment><USER3> The point is that if they _really_ didn't support the bill, the would either pressure the ESA into removing themselves or leave the group in protest.

<comment><USER4> How big is the ESA? Does any one of these companies (or even the three colletively) wield enough power to change the stance of the entire organization?

</comment></comment></comment><comment><USER5> Anybody who initially supported SOPA, has to come out against SOPA to win any browny points as far as I am concerned. Dropping support is just weak and non- believable.

<comment><USER6> On the other hand, the game companies probably also don't want to tick off the media industry. So while Nintendo, Sony, et al don't have much to gain from SOPA, they have quite a bit to lose if the major content industries decide to blacklist their platforms.

<comment><USER7> Which they would absolutely never do.

Right now Hollywood is desperate to break in to videogames. They know that games are an important part of the future, and want very badly to start making _good_ movie based games. But so far they haven't had much luck.

As it stands, if the game industry couldn't continue making weak movie tie- ins, it wouldn't be that big of a deal. They are a handy cash cow, but as often as not they are abysmal games, no thanks to the movie industry itself.

<comment><USER6> I was talking more about things like cutting off Nintendo, EA, Sony, etc. from deals with Netflix, licensing music to use as game soundtracks, and things like that. Basically, not letting their media hit the game consoles.

</comment></comment></comment></comment><comment><USER8> I think SOPA is a really bad idea.

How should companies like Nintendo or Sony (the game division) deal with the rampant piracy of games on their systems?

<comment><USER9> It's pretty much impossible to completely stop it. You can only choose how you will attempt to delay it or discourage it. Consider the war on drugs: at least there you have the advantage that you have a tangible object that you're seeking to limit access to which under our current understanding of physics is possible, but look how successful that has been. But trying to stop the spread of information that has no tangible limit and is trivial to spread?

As Corey Doctorow pointed out in his speech at a recent conference, copying will only get easier. In this world of increasingly computerized things, corporations will continue to struggle with this core problem: Computers (of all types) are general purpose (at the architecture level) and execute instructions given to it. How can we make it so it doesn't execute code that we don't like?

As others have pointed out, if your profitability relies chiefly on the secret order of 1s and 0s and restricting access to that voodoo then you're in for a long uphill battle because all of computing can be summed up as the art and science of copying bits from one location to another as cheaply and as efficiently as possible.

In the case of video game developers we've seen a few models that take into consideration copyright infringement. Some games have demonstrated profitable virtual economies with the company taking a cut of the profit, and even a company like Nintendo sells its hardware at a profit so as long as people have a reason to purchase Nintendo hardware there is room for a company like Nintendo to exist. This isn't to say these are the only or the best solutions, but rather just pointing out that to stay profitable going forward there is no reason to believe outdated business models will continue to thrive.

<comment><USER10> There are two ways current hardware makers are beating piracy, increasing hardware complexity and value-added services. A lot of people are complaining about the Vita's proprietary memory cards, but I wouldn't be surprised if that move was 100% solely made to prevent 3rd party execution. I'd imagine that more anti-consumer features would be coming in the next generation of console hardware too.

The flip-side is rewarding good customers. By not having a hacked console, you can use online services (such as Xbox LIVE).

Although amusingly, I think the answer may actually be in free-to-play games. 2011, in my opinion, was the year F2P changed from evil Zynga social games and last-ditch MMO fallback to a serious triple digit growth area with games like League of Legends and Team Fortress 2. Expect to see F2P on Sony consoles soon. (Sony is more liberal with their online policy, which is why I'm predicting the first popular F2P on their systems. Microsoft is very domineering of Xbox LIVE and how their online play works, and Nintendo's online strategy is somewhere in the pre-fire stoneage.)</comment></comment></comment>


Green New Deal Is Feasible and Affordable - <AUTHOR> https://www.cnn.com/2019/02/22/opinions/green-new-deal-sachs/index.html <comment><USER2> "Most of the modest costs of decarbonization will never hit the federal budget, as they will be absorbed by the utility industry, the automobile producers, and other parts of the private economy."

This worked out great for France. Just tell all the working class to buy a Tesla

<comment><AUTHOR> Actually it works great for France.

Look at all the electrified trains that the French take to work instead of driving.

Decarbonization does mean going to 0% overnight.

<comment><USER3> OP is referring to the enormous riots and rollback of similar policies in a much, much more liberal country.

When people talk about CNN being fake news, they're talking about this article. This is only feasible in the minds of people on HN/elites. People in the rest of the country, not so much. It's fascinating to me that in an era of staunch conservatism this is treated as something approaching possible.</comment></comment></comment>


Can being cold make you sick? - <AUTHOR> https://www.nytimes.com/2018/02/23/well/can-being-cold-make-you-sick.html <comment><USER2> When you don't have good nasal mucus flow, it's harder for the immune system to work against the virus. These viruses that cause us to catch a cold predominate during the winter month.</comment>


Why does First Solar stand alone? - <AUTHOR> http://www.news.com/8301-11128_3-9821209-54.html?tag=nefd.top <comment><USER2> That's another one of those submarine articles, right?</comment>


PDF vs. physical books - <AUTHOR> The page count has always been one of the important limiting factors in the publishing industry. The need to compress the material has made an adverse impact on the quality of many textbooks, leading to complaints about the lack of coherency, missing explanations, text being difficult to understand, etc. With the advent of electronic publishing, the situation has changed dramatically, and we now may be in for the pleasure of reading clearly written, extremely detailed expositions of vast and complex topics, such as statistics or modern physics... But this has not happened, and the standard curricula still rely on printed-size books and, hence, the need to be guided by a live teacher, in order for a student to be able to actually understand the material. Talk about the "horseless carriage"... <comment><USER2> ... and?

<comment><AUTHOR> Sure, let me elaborate.

We are already quite far into the 21-st century, and there are several directions in which the "large format" publishing (i.e. that of monographs, teaching materials, etc.) should be going by now instead of sticking with the "old ways":

\- abandoning the limitations specific to the old tech; the authors tend to show the reflexive desire to be minimalist in their exposition which results in a coverage of the topic that is sorely incomplete and/or unclear;

\- transitioning to new ways of information delivery, the ones that are only possible with the use of electronic devices; instead of bundling massive amounts of the material into a single package (a book), authors could follow the example set by Wikipedia, say, and create a much more fine-grained, yet naturally loose, collection of "articles" each being unlimited in size and therefore (unlike what we see in Wikipedia) detailed, thorough and thus accessible to anyone willing to spend time studying them;

\- using completely new ways of _presenting_ information afforded by computers, which, incidentally, would be nothing new as an idea, because the thought of computer-based education/training has been around since at least 1960s; yet, it is still waiting for its practical application on an adequate scale; from this perspective, teaching methods based on absorbing text - whether in printed or even electronic form - can truly be seen as backwards as thinking of a car as being merely a "horseless carriage".

This process is not happening in any perceptible manner, and I wonder what's holding us back to the degree it still is.</comment></comment>


Concrete AI tasks for forecasting (2014) - <AUTHOR> http://aiimpacts.org/concrete-ai-tasks-for-forecasting/ <comment><USER2> This is a pretty good list.

I see some criticism of the poker tasks, but that is unfounded. Poker is an important area of AI research because of bluffing (detection and when to do it). CMU is probably the most active in this area. See [https://www.cmu.edu/news/stories/archives/2016/february/poke...](https://www.cmu.edu/news/stories/archives/2016/february/poker- bot.html) and [http://www.cs.cmu.edu/~noamb/poker.html](http://www.cs.cmu.edu/~noamb/poker.html). Their bot (Claudico) was demoed at NIPS15.

Interestingly, I've seen solid progress on 3, 6, and 8 in the last 2 months of 2016 and on 7 in 2017 already.

</comment><comment><USER3> Number 31 ("Play poker well enough to win the World Series of Poker.") is a pretty empty statement, as 1 tournament does not reflect your skill at poker at all. Short term variance is too big of a factor when it comes to one 1 tournament result.

<comment><USER4> Well, in 2016 there were 6737 entrants [0], so I suppose the AI needs to have all its stars aligned or some other connection to god to win it without being good.

Biggest problems are usually not winning heads-up but meaningfully sampling the state space with more than a handful of players + accounting for the "no limit" part.

[0] [https://en.wikipedia.org/wiki/World_Series_of_Poker#Main_Eve...](https://en.wikipedia.org/wiki/World_Series_of_Poker#Main_Event)

</comment></comment><comment><USER5> " _Take a written passage and output a recording that can't be distinguished from a voice actor, by an expert listener._ "

Role Playing Games would explode if this happened. The ability to generate speech on the fly would create dramatically more immersive worlds.

<comment><USER6> [https://developer.amazon.com/alexa-voice- service](https://developer.amazon.com/alexa-voice-service)

</comment></comment><comment><USER7> Why is this tagged 2014? The article is dated Dec. 14, 2016 and includes a reference to AlphaGo.

<comment><USER8> Because someone didn't understand the ISO-8601 date format.

2016-12-14 => 14 December 2016

<comment><USER9> Is dang reading this?

</comment></comment></comment><comment><USER10> #22 - "system should write code that sorts a list, rather than just being able to sort lists."

Using symbolic techniques, synthesizing algorithms is tractable. See Sec5.3 on pg11- of [http://saurabh- srivastava.com/pubs/popl10-synthesis.pdf](http://saurabh- srivastava.com/pubs/popl10-synthesis.pdf) \- Figure 2(b) is the synthesized selection sort algorithm, and Table 3 has QuickSort synthesis time at 160seconds. Very old work (2010) and used templates to guide synthesis. SAT solvers have improved, and much more CPU cycles are available, so in 2016, exhaustively exploring the template space will be trivial.

I.e., rather than reconstructing code from concrete program execution traces, giving the synthesizer (AI?) the ability to manipulate symbolic spaces leads to a tractable search space. Finding specification-matching programs within this symbolic space is doable.

</comment><comment><USER11> I'd really love to see -

'Beat tier one teams at least 50% of the time in Dota 2 across multiple patches'

It's cool that people are starting to work on Starcraft 2 AIs but the game is kind of dead so competition at the top isn't going to be as strong as it is in more popular games. Also I think Dota presents a much more interesting and more difficult challenge for AI makers.

<comment><USER12> The challenge is different: you've got way more units to control in SC2 than in Dota. And rushes can be punitive, which do not occur as frequently in Dota

<comment><USER11> The more units thing is part of the reason I think Dota is a better challenge, I can't help but feel a SC2 AI could use inhuman micro as a crutch whereas in Dota mechanical / micro skill doesn't provide quite as big an advantage.

Not too sure what you mean by 'rushes can be punitive' but Dota certainly has a variety of early game aggression strats which tend to be high risk / reward and are seen fairly regularly.

</comment></comment></comment><comment><USER13> IMHO the wording of point 12 is a silly way to pretend that Alphago has not completely achieved its goal. Human players learn Go using manuals that compile the experiences of millions of games. The fact that Alphago can use directly huge collections of games is not very relevant for its success.

<comment><USER14> There's a difference between needing 100,000,000 games and 50,000 for training to be the best. That difference is learning efficiency and astuteness - a good way of judging AI progress, no?

<comment><USER15> I think "50,000 games played" puts it a bit too simply. How many games has he watched how many equivalents of a game has he visualized as sequences of moves? If "played" is over 50k I'd be willing to bet "considered" is over 1,000,000.

</comment></comment></comment><comment><USER9> Imagine the implications for the real world if you can solve #32. I wonder will it be able to detect emergent laws (e.g. thermodynamics, Newtonian gravity as an approximation to general relativity etc.)? Also it will be very interesting to see which experiments AI chooses to perform.

</comment><comment><USER16> Some of these are pretty awesome/crazy. I hope to see many achieved in the near future.

<comment><USER17> Yes and to be honest I wouldn't go so far as to call a lot of these "Concrete" tasks.

But it is an interesting and throught provoking list. And makes me consider more quantitive metrics for qualatitive things like how good a piece of music is.

</comment></comment><comment><USER18> After we've achieved all these things, we can start asking when "general intelligence" will arrive.

<comment><USER19> Most humans are pretty bad at at least a few of those things. Also, some are tasks that the human brain is specifically optimized for - human natural language most likely plays well to lots of human-hardware-design-quircks. So using them a test sounds pretty bad / unfair - lots of human-level but independently evolved alien intelligences would probably fail miserably at them. You could have above-human intelligence barely reaching human performance at either of these tasks but vastly surpassing human intelligence at others...

Imho GI "will arrive" after the point that we have swarms of similar close-to- human-level ai-agents trying to model each other's behavior while competing and collaborating in artificial and natural environments.

All theories of self-consciousness that make some sense imho are about _agents trying to model self-similar agents and then somewhow reframing this ability to model past and future self._ So you could have self-conscious dog-level agents (yeah, I believe "self conscience" is quantitative and a dog can have some of it and a human a different level of it, not 0 or 1), or non-self conscious above-human-"general"-AIs (though I don't know if you'd want to label "general" any non-self conscious AI, and I think any non-self-conscious above-human AI would get "self conscience" quite fast if you were to push it be be "general purpose" \- striving to solve more and more types of problems, you inevitably arrive to some formulation of the "model something like yourself in order to predict its actions" problem).

<comment><USER5> Hardware plays a massive part too; I don't see a static micro processor becoming conscious anytime soon. Our brains though are literally physical neural networks, that grow, move, and change physically all the time.

<comment><USER19> It does not. Any kind of software can run on any kind of turing complete hardware. Unless you're one of those believing in the quantum mind theory [https://en.wikipedia.org/wiki/Quantum_mind](https://en.wikipedia.org/wiki/Quantum_mind) . Just as a human brain can simulate a microprocessor (although unusably slow and with errors), so can a microprocessor simulate a human brain (also unusable slow). Read a bit more on turing equivalence - a badly explained topic unfortunately, because you know how bad are mathematicians at explaining stuff, even if imho it should be part of junior school curricula in a simplified version. (Oh, and maybe it's brushed off because it can also lead to pretty trippy conclusions: take a cockroach brain which is likely turing complete, mount it as a cpu in some kind of computer, stuck in a maigc time- machine box that makes time run order of magnitude faster, add some really fancy input/output tech, and you could run a human mind on it... think of what the reincarnation weirdoes would milk from this :) )

 _I 'm pretty sure that if you find a way to extract a mathematical model of a human's personality, and a way to transform it to reduce "chemical noise quircks" and other hardware dependent but unnecessary "features"/bugs, you could run it just fine on a big datacenter and have a working immortal human mind._

(I'm also pessimistic enough to believe that we'll solve the "general AI" problem before solving the "mind extraction" one unfortunately. Hopefully our creations don't destroy us completely before solving problem (2) and we have time to pass on some direct immortal legacy of what it means to be "human"...)

P.S. but yeah, I agree that engineering better suited hardware might be actually easier than getting the current type of hardware fast enough or than inventing the mathematical transforms needed to run a mind's set of equations on current type hardware... we're slowly getting to custom hardware for ai ( [https://cloudplatform.googleblog.com/2016/05/Google- supercha...](https://cloudplatform.googleblog.com/2016/05/Google-supercharges- machine-learning-tasks-with-custom-chip.html) ), but I imagine the future will be more analog/clockless...

<comment><USER5> Not saying you can't run any kind of software on turing complete hardware, but consciousness is far more that just software. The only proof of consciousness we have is that a brain is required, where software and hardware are the same thing. New thoughts are real physical connections in the brain.

<comment><USER9> If you need new hardware for new software (thought) then it's a pretty bad design.

<comment><USER5> Actually it is a superior design; hardware that can adapt to the needs of the software can optimise at will, enhancing the performance to ridiculously fast levels.

</comment></comment></comment></comment></comment></comment></comment><comment><USER20> > Translate a text written in a newly discovered language into English as well > as a team of human experts, using a single other document in both languages > (like a Rosetta stone).

Huh? We can't even translate texts correctly between mainstream languages yet.

<comment><USER21> There is some interesting work applying word2vec on the voynich manuscript. It found all sorts of patterns that humans weren't aware of. It's theoretically possible even without strong AI.

</comment></comment><comment><USER22> Some are pretty silly unfortunately: "Write a novel or short story good enough to make it to the New York Times best-seller list."

<comment><USER23> What's silly about it? If AI could write (for example) Fifty Shades of Grey, it would be super impressive.

</comment></comment><comment><USER24> _" relatively well specified"_

If these are "well specified", then the author and my boss are operating on some definition unknown to me.

Also, quite a few tasks don't seem to be obviously about AI. Stuff like:

> Play poker well enough to win the World Series of Poker.

It's one thing to play Starcraft or Go well. But implementing this is either mostly a question of luck, or an incredibly lifelike robot with incredible facial recognition skills. Very different tasks!

> Beat the fastest human runners in a 5 kilometer race through city streets > using a bipedal robot body.

This requires no AI, just a lot of improvement in energy density and actuator technology.

<comment><USER5> _" It's one thing to play Starcraft or Go well. But implementing this is either mostly a question of luck, or an incredibly lifelike robot with incredible facial recognition skills."_

In terms of strategy though, it is the next level up I'd say. Videogames come first, then more difficult games such as Poker come later where you need to be able to tell a bluff from the truth. Much more subtle.

 _" This requires no AI, just a lot of improvement in energy density and actuator technology."_

It did say city streets though, which makes me think it would need to strategise and be able to:

1\. Adjust speed and take corners close such as what you see in F1 races.

2\. Switch between endurance and sprinting when necessary to maintain energy for the whole race.

3\. Run behind others to stay in the tailwind and reduce energy cost.

All require human level sensory input and a strategising component.

<comment><USER25> I understood the running task as being through _actual_ (i.e. _populated_ ) city streets; either a real city or a mockup built out of harm's way.

This would require real-time object detection and avoidance, following signs/social conventions/etc., complex route-planning, avoid people/cars/etc., predicting the movements of others, predicting how others will predict your predictions, etc.</comment></comment></comment>