There's a similar law in the UK, and companies generally comply with the letter. (Although I've seen some interesting ways of working around the spirit; one form I saw asked for permission to use the information in a variety of ways, which were opt-ins and opt-outs more or less at random, so you had to read it carefully to determine which boxes to tick.)

Unlike the Windows 8 version, the Canonical version appears to be to use the same codebase for the tablet and desktop programs, but to have a different interface for each. (It's entirely possible to put multiple interfaces in one codebase or even one binary; NetHack has been doing it for years.)

What's probably more interesting was their fix for the problem. Instead of trying to do any sort of rollback (although they did find people with impossibly high currency amounts and reduce them to saner values), they put a large amount of very expensive trophy items for sale which didn't do anything useful, in the hope that people would put their newfound wealth to an amusing trivial cause.

It doesn't. You can do it with two clicks in two different ways, but as far as I know, there's no way to pin the applications lens, which is what would be required to do it in one. (They have fixed the dock, now, though.)

The way it's done in the UK is that the shop (whether it's a small corner shop, or a large chain) charges you the tax anyway and gives you a receipt with a tax breakdown (as they're required to do on request, by the law). Then you take the receipt to a tax reclaiming kiosk with proof that you're not a UK national and are only there for a short time (holiday or the like), and they give you a refund for the tax. (They tend to be at airports, for obvious reasons; they wouldn't really be required anywhere else.) This way, the shops don't have to worry about establishing whether someone's meant to pay tax or not; all that complex handling can be centralized.

Is it possible that the address was spoofed? (Perhaps because they were reflecting attacks off your computer.)

Basically the problem is that OpenGL has a lot of old cruft in that people have been trying to get rid of for a while, that made sense at the time but nowadays only exists for backwards compatibility. OpenGL ES is gaining in prominence because it looks like it might actually be a chance to make a clean break with OpenGL's past.

Unless they've done something stupid like copying the documentation word for word, or stealing source code, it isn't likely that there will be copyright-related problems. (And giving it a different name means that trademark-related problems are also unlikely.) People are mostly scared about patents, instead.

The same bug can brick Samsung laptops on Windows too. It's just that it was noticed on Linux first.

It doesn't work any more; Slashdot just deletes the word altogether if it contradicts the score. I think the highest score you can get on a "Troll" post is 2.

Actually, correction: this isn't session fixation, it's a replay attack (as earlzdotnet points out). Session fixation is where you make the user use the attacker's cookie, rather than the other way round. (Less useful but still potentially exploitable.)

https is used to prevent session fixation working without a secondary exploit. If you have a secondary exploit that allows access to the cookie (e.g. the XSS exploit you're describing), then a different fix is needed for the different exploit (for instance, fixing the XSS hole itself, or marking the cookies as http-only so that they can't be accessed via JavaScript). If you don't have https, then someone with access to the victim's network doesn't need another exploit at all; their network access is enough in its own right.

In this case, it seems that some of the services were using https to protect the cookie and had secondary exploits, and others weren't protecting the cookie and so the secondary exploits weren't needed.

(Also, your suggested fix doesn't work; what's causing the server to send the hidden form field? There's no obvious way to send it to the user-who-has-a-cookie unless you also send it to the attacker-who-has-a-cookie. Unless you make the user log in on every page view, which would be ridiculous (although at least Bugzilla can optionally fall back to that mechanism if the user isn't accepting cookies).

This isn't exactly a new exploit (I remember the Firesheep event where someone made hijacking Facebook accounts like this user-friendly, but don't have a link handy). One problem with actually doing this is that you need access to the data as the victim's sending it (e.g. via sniffing unencrypted wi-fi, or physical access to the network that the victim is using); that still gives several possible targets (especially the wi-fi angle), but makes it much harder to use against arbitrary targets.

(The simplest fix, of course, is to use https for all cookie handling, which probably means https for every page access.)

So this is old news, although a reminder that this is still possible is definitely worthwhile.

There are laws against what AT&T did in the UK (if you're storing information about a person that's sufficient to identify that person, you can't make it public without their permission, although you can obtain their permission when you obtain the information). Ones that are considered important enough to be taught in schools.