It may not be part of the mainline Linux kernel, but the "firmware library" here is a kernel module, so this bug is a kernel-mode remote execution vulnerability. Which... probably isn't that much worse than a userland vulnerability for this type of device, where everything typically runs as root anyway, but still.

Alright, so what I meant to say was "it isn't there", rather than "it's gone" -- my bad for insufficiently nitpicking my own word choice. But either way, it's not on the table, and we're back to the choice-that-isn't-much-of-a-choice of "do exactly what we say" vs "fuck off".

That's because it's not actually an extension. They landed the code directly in Firefox itself, so you can't remove it without patching and recompiling.

Also it landed quite recently, so it won't be in a release Firefox until... oh, what's that? We're going to do a special out-of-schedule 38.0.5 release because it needs to be shipped super-fast and we can't be bothered to follow our own testing/release cycle? Okay then.

Okay, fair enough: if I want to watch something on Netflix, I have a choice between "watch it with exactly the software they dictate" and "fuck off". I suppose you can technically call that a choice, even though one of the options doesn't actually involve watching the thing.

But where's my choice of "watch it with the software I want to use"? Right, it's gone, because of the DRM.

I think HDCP is between the GPU and the monitor, rather than extending all the way to the originating software.

(It's also hilariously weak; replacing it with TLS would be much nastier.)

Except that's not really a choice when DRM is involved, is it? The entire point of DRM is to take that choice away from you.

The EME plugin could transfer video frames to the monitor over HTTPS. That way you can't sniff the uncompressed frames, and you can't MITM the connection unless the plugin is stupid enough to not check the certs it sees. The browser, OS and even the GPU are all just dumb pipes to get the uncompressed-then-reencrypted stream to the monitor.

(Obviously it'll use TLS or some custom scheme rather than HTTPS, and I'm not even sure if this "encrypted path right to the monitor" is actually a thing at the moment. But this is the basic idea of how it could work.)

Modelling with a binomial distribution? 20% chance of getting 4 accidents from a sample of 48 drivers when the true accident rate is 4.5%. 37% chance of 4 or more.

With a true accident rate of 4.5%, seeing an 8-9% accident rate in a sample of 48 is common and not cause for alarm. Now, if it was 480 trials (with a <0.1% chance of seeing even an 8% accident rate), I'd be worried, but it's not.

In this case, something can be done: the company can stop selling the lock as "secure" (or "a lock"), and then put out a new one that is actually secure. Maybe do a product recall so people know about it.

What did they do instead? Start threatening the guy who told them about the vulnerabilities. When a company does that, the only responsible thing to do is to publish, because you know the company won't ever fix the problems otherwise.

(I do think 30 days is a bit on the short side... but I don't think giving them longer would've changed anything. They clearly had no intention of fixing anything so long as their customers remained in the dark.)

Hah. Don't worry, they're working on that. GTK3 to turn off the native titlebar, new in-content theming that totally ignores your entire OS settings and goes its own way, plus the new in-content preferences to make sure you have to deal with the terrible theming. All of these, coming soon to a Firefox near you.

After all, who doesn't want all their desktop programs to look like they're designed for a tiny touchscreen?

If its worse sin is not doing the impossible, then it's doing pretty good: you can't talk between v4 and v6 hosts because of the pigeon-hole principle. There's just not enough space in the v4 dest header to fit a 128-bit address.

If you have a brilliant idea for getting around that, please do share.

We'd better make damn sure these AIs want to work well in a community, then. Preferably our community. And if it evolves, make sure it continues to want that.

That's a hard problem, and it's the one these scientists are worried about.

And so would I if I absolutely had to -- I'd even remember the v6 addresses -- but I don't. My life is easier than that.

We can't refuse to do v6 because "DNS is hard"; v4 with NAT everywhere is way harder.

"Just". I'd rather be told if my packets are reaching the remote end or not, rather than have to break out a microscope and go hunting. Assuming I even have enough access at both ends to do that.

Yeah, typing them out's a pain. I wish we could have a shorthand format like "~::2" which took the first N bits from your current network prefix. But I almost never type v6 addresses; it's usually DNS, or then copy/paste if I really am dealing with IPs for some reason. For that matter, I don't even know the v4 addresses for most of my machines -- I could give you the subnet, but I have no idea which IPs are which.

For what it's worth, v6 assignments currently start with 2001 or 2{4,6,8,a,c}0*, which is pretty similar to the well-known RFC1918 ranges. And you'll see your own prefix often enough to remember it, hex or no hex.