With this, humans won't need take BigDog for a daily walk anymore.

"Friendly countries"; like, the USA?

What? No mention of the Pixel Qi -based Adam? This is the one I'm waiting for.
http://notionink.wordpress.com/
http://www.notionink.in/

I made Basus not long ago. Successfully tested on about 50 kids. Read about the idea behind the programming language here: http://basus.no/idea.html

Get it here: http://basus.no/

It appears that PHP, upon seeing an incoming parameter with a name that ends in [something] (where something may be empty), automatically turns that variable into an array.

How many of you PHP developers out there knew that? I didn't. And I had to dig quite a bit to find a reference to this behaviour in the docs.

So, incoming stuff from the URL or the POST data are no longer strings all the time. Can they magically become other things than strings and arrays as well? Maybe not now, but what if some PHP developer thinks up another "nifty" feature _after_ I read the docs; how then am I supposed to protect my application in the future? Do I need to re-read the docs every time I upgrade PHP?

And is there a way to turn this "we know better than you what you need"-behaviour off?

I'm sick of seing framework developers add "nifty" features that you have to know about in order to write secure code. It's not only PHP, but also several highly popular Java frameworks that I work with these days. Some of them make it quite easy to write to object fields that are normally out of reach of the input fields in a form.

I want a framework that makes it impossible to make mistakes, and where you have to _enable_ potentially dangerous features when you _know_ you need them, rather than _disable_ potentially dangerous features most people don't know about (or use).

I don't know about the new attacks, but I researched a bit after
Gregory Steuck posted about "XXE (Xml eXternal Entity) attack" on
Bugtraq in 2002 (http://www.securityfocus.com/archive/1/297714).

You can easily do DoS attacks on a Java-based thing running on
e.g. Linux if you manage to trick the server into parsing one of the
following two XML documents:

        <?xml version="1.0" encoding="ISO-8859-1"?>
        <!DOCTYPE foo [
            <!ENTITY xee SYSTEM "file:/dev/tty">
        ]>
        <foo>foo: &xee;</foo>

        <?xml version="1.0"?>
        <!DOCTYPE foo SYSTEM "file:/dev/tty">

Both will make the XML parser try to read from the TTY, thus blocking
"forever" waiting for input that never comes. The fun thing is that
it doesn't help to setExpandEntityReferences(false), even though the
name sounds like it would help. The only thing that works (afaik), is
to install a custom made EntityResolver that refuses to look up
external entities. Since nobody does that, this vulnerability may be
found all over the place.

Variations exist for other OS-es and other web platforms as well. I
even found that Adobe Reader was vulnerable once
(http://shh.thathost.com/secadv/adobexxe/), and I recently stumbled
across a similar thing in a commercial web-protecting security
application. (They're working on a fix.)

The nice thing with computer software, is that you can keep subdividing until you reach a collection of single bits. Repairing a single bit is very easy, so there you go.

Since the article mentions Microsoft's attempts to undermine competing businesses, here's an interesting link to the Eupean Committee for Interoperable Systems' (ECIS) article "Microsoft: A History of Anticompetitive Behavior and Consumer Harm" (PDF): http://www.ecis.eu/documents/Finalversion_Consumerchoicepaper.pdf Published on 2009-03-31. Required reading. :-)

Astronomical? Like in millions of millions of stars?

If you compare to Oslo, the capitol of Norway, the closes neighbour to Sweden, the four guys have been sentenced to pay the price of a big house each (that is: four houses in total, in case I get the wording wrong) in the second most expensive part of the city. It's a lot of money (a lot!), but hardly astronomical.