That's not what it says. It says that the capacity at 200 cycles is 1.5x a current cell. No mention is made of the point at which the capacity of these cells drops below the capacity of regular cells, if indeed such a point even exists: it's entirely possible these cells have roughly the same performance vs cycle curve as current cells after 200 cycles, just with a generally higher capacity.
I suppose you might raise the question of why they limited their testing to 200 cycles rather than more, but I note that if each charge/discharge cycle takes 4 hours then 2000 cycles would take almost a year to complete.
No, SLAAC isn't used with link-locals -- link-local addresses are assigned automatically by the host. It's used with whatever the network range on the segment is, which will usually be a global unicast range, or sometimes ULA. That's where it's supposed to be used, it's a normal way to do v6 and it works just fine.
Maybe. But on the other hand, even active servers spend a lot of their time idle (the paper says server utilization "rarely exceeds 6%"), and I bet a lot of these "comatose" servers are actually long-forgotten old hardware, or machines that nobody can be bothered to decommission -- it's possible that on average they're older than active servers and thus eating a lot more power.
You can sign SSL certificates without ever knowing the private part of the cert, so it's possible to set things up such that it's obvious that they're not leaking the private part of your certs to the NSA.
Whether they will actually do that or not remains to be seen.
Yes, you said that already and it was already a given, but what new thing can the host do now that it couldn't do before that allows it to send packets to a v6 address?
Remember, the host is still connected to the v4 internet, and it still has no v6 internet connection. It has to send v4 packets. What v4 packets can it send to reach v6 hosts?
But you could upgrade B and it would work without changing the configuration of A!!!!!
Did you finally get it now? You could upgrade B without touching A and NOT CHANGE the address of either A nor B and it would all work just fine.
No, because all you're still doing is telling me it'd work without explaining how.
Even with upgraded software on B, the v4 dest field is still too short for v6 addresses. This is the whole problem in the first place. How does the software upgrade help? What does the software upgrade actually do to work around this?
It's really that simple. It's not about IPv4 connecting to IPv6 (that would be forward-compatibility, which is impossible in that case) but the other way around.
Okay, here's the critically important thing: these are no different to each other!
Remember, at the IP level, there's no such thing as "connections". There's no state. It's all just packets being sent from a source address to a dest address. So we could put v4 into a v6 prefix, and v6 hosts would be able to send packets to existing v4 hosts -- this would work just fine. But those v4 hosts could never respond. They can't fit the response address into their dest field.
And because that's not possible, you can't make a TCP connection or hold a UDP conversation. The ability to "yell at the existing v4 internet but never get a reply" just isn't going to be enticing enough to get anybody to drop their v4 connections. Basically, the v6 designers didn't do it because it was pointless to do.
And then what? How would that lead to an inter-compatible v4 and v6? You're right that I don't get it; please explain it to me.
How would an existing v4 host at w.x.y.z be able to send to a v6 host at a.b.c.d.e.f.g.h.i.j.k.l.m.n.o.p? This seems like an entirely technical problem to me, and you can't normally just define your way out of those.
How would you actually go about doing this though? I've seen lots of people go "IPv6 is retarded, they should've just added some extra numbers to the end of v4", and it's very easy to just sit there and say it, but none of them have explained how they could've done that and actually had it work.
Please, be the person that explains it to the world, if it's so obvious to you: how the heck do you beat the pigeonhole principle?
For what it's worth: they don't take it. Your browser tracks your history (as it has always done, unless you've turned that off), and makes the decisions of which adverts to display locally.
Mozilla can attempt to infer your browsing history from which adverts you load (and I've seen discussions about trying to reduce the amount of information they receive, although I don't know how much of that actually made it to the implementation), but they don't get a copy of it. Only your local browser gets that.
It is, but you'd achieve a much higher resistance to precalculation attacks just by generating and sharing a longer key in the first place -- which also has the advantage of not burning hours of CPU time on every single machine.
Perhaps the best thing to do here would be for each system to download DH parameters (or get them from a package or whatever) at installation time, and then regularly change the parameters that are available for download. That avoids the massive generation time on each machine, but also limits the amount of machines that you share parameters with. So long as those parameters aren't tiny, that should be fine.
Bonus points if you include a simple "make_me_my_own_dhparams" script that makes generating your own parameters trivial, but I do think we can get most of the benefit here without requiring every single install to use it.
So... generating new DH parameters on each connection leads to connection latencies of up to a few hours, which isn't really viable?
Also, what are you trying to protect against by regenerating the key frequently? We normally cycle RSA keys every year or two because of the risk that someone might break into the server in that time and steal the key (and we don't want the stolen key to be valid forever), but that's not an issue with DH parameters because they're public anyway.
The other reason to regenerate frequently is to limit the window of opportunity for brute force attacks, but that doesn't make much sense either: instead of generating lots of small keys, just generate one bigger key in the first place. It'll take far less CPU time and yet still be far harder to brute force.
It takes my (2009 era) machine 5-300 minutes (it varies wildly depending on how lucky you get) to generate a set of 4096-bit DH parameters. And that's actual CPU time, not "sitting around waiting for the Linux entropy pool to regenerate" time. You're going to have to make some tradeoffs here.
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.
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.)
and it just respects my look and feel (colors, borders, font sizes, etc).
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?
Slashdot Mirror
That's not what it says. It says that the capacity at 200 cycles is 1.5x a current cell. No mention is made of the point at which the capacity of these cells drops below the capacity of regular cells, if indeed such a point even exists: it's entirely possible these cells have roughly the same performance vs cycle curve as current cells after 200 cycles, just with a generally higher capacity.
I suppose you might raise the question of why they limited their testing to 200 cycles rather than more, but I note that if each charge/discharge cycle takes 4 hours then 2000 cycles would take almost a year to complete.
~3.8 GB, apparently.
What?
No, SLAAC isn't used with link-locals -- link-local addresses are assigned automatically by the host. It's used with whatever the network range on the segment is, which will usually be a global unicast range, or sometimes ULA. That's where it's supposed to be used, it's a normal way to do v6 and it works just fine.
Maybe. But on the other hand, even active servers spend a lot of their time idle (the paper says server utilization "rarely exceeds 6%"), and I bet a lot of these "comatose" servers are actually long-forgotten old hardware, or machines that nobody can be bothered to decommission -- it's possible that on average they're older than active servers and thus eating a lot more power.
You'd know the difference, because the fingerprint of the cert wouldn't match the one in DANE.
Except nobody supports that, because closing that particular hole apparently isn't important...
You can sign SSL certificates without ever knowing the private part of the cert, so it's possible to set things up such that it's obvious that they're not leaking the private part of your certs to the NSA.
Whether they will actually do that or not remains to be seen.
Yes, you said that already and it was already a given, but what new thing can the host do now that it couldn't do before that allows it to send packets to a v6 address?
Remember, the host is still connected to the v4 internet, and it still has no v6 internet connection. It has to send v4 packets. What v4 packets can it send to reach v6 hosts?
But you could upgrade B and it would work without changing the configuration of A!!!!!
Did you finally get it now? You could upgrade B without touching A and NOT CHANGE the address of either A nor B and it would all work just fine.
No, because all you're still doing is telling me it'd work without explaining how.
Even with upgraded software on B, the v4 dest field is still too short for v6 addresses. This is the whole problem in the first place. How does the software upgrade help? What does the software upgrade actually do to work around this?
Okay, here's the critically important thing: these are no different to each other!
Remember, at the IP level, there's no such thing as "connections". There's no state. It's all just packets being sent from a source address to a dest address. So we could put v4 into a v6 prefix, and v6 hosts would be able to send packets to existing v4 hosts -- this would work just fine. But those v4 hosts could never respond. They can't fit the response address into their dest field.
And because that's not possible, you can't make a TCP connection or hold a UDP conversation. The ability to "yell at the existing v4 internet but never get a reply" just isn't going to be enticing enough to get anybody to drop their v4 connections. Basically, the v6 designers didn't do it because it was pointless to do.
And then what? How would that lead to an inter-compatible v4 and v6? You're right that I don't get it; please explain it to me.
How would an existing v4 host at w.x.y.z be able to send to a v6 host at a.b.c.d.e.f.g.h.i.j.k.l.m.n.o.p? This seems like an entirely technical problem to me, and you can't normally just define your way out of those.
How would you actually go about doing this though? I've seen lots of people go "IPv6 is retarded, they should've just added some extra numbers to the end of v4", and it's very easy to just sit there and say it, but none of them have explained how they could've done that and actually had it work.
Please, be the person that explains it to the world, if it's so obvious to you: how the heck do you beat the pigeonhole principle?
For what it's worth: they don't take it. Your browser tracks your history (as it has always done, unless you've turned that off), and makes the decisions of which adverts to display locally.
Mozilla can attempt to infer your browsing history from which adverts you load (and I've seen discussions about trying to reduce the amount of information they receive, although I don't know how much of that actually made it to the implementation), but they don't get a copy of it. Only your local browser gets that.
It is, but you'd achieve a much higher resistance to precalculation attacks just by generating and sharing a longer key in the first place -- which also has the advantage of not burning hours of CPU time on every single machine.
Perhaps the best thing to do here would be for each system to download DH parameters (or get them from a package or whatever) at installation time, and then regularly change the parameters that are available for download. That avoids the massive generation time on each machine, but also limits the amount of machines that you share parameters with. So long as those parameters aren't tiny, that should be fine.
Bonus points if you include a simple "make_me_my_own_dhparams" script that makes generating your own parameters trivial, but I do think we can get most of the benefit here without requiring every single install to use it.
So... generating new DH parameters on each connection leads to connection latencies of up to a few hours, which isn't really viable?
Also, what are you trying to protect against by regenerating the key frequently? We normally cycle RSA keys every year or two because of the risk that someone might break into the server in that time and steal the key (and we don't want the stolen key to be valid forever), but that's not an issue with DH parameters because they're public anyway.
The other reason to regenerate frequently is to limit the window of opportunity for brute force attacks, but that doesn't make much sense either: instead of generating lots of small keys, just generate one bigger key in the first place. It'll take far less CPU time and yet still be far harder to brute force.
It takes my (2009 era) machine 5-300 minutes (it varies wildly depending on how lucky you get) to generate a set of 4096-bit DH parameters. And that's actual CPU time, not "sitting around waiting for the Linux entropy pool to regenerate" time. You're going to have to make some tradeoffs here.
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.)
Don't want it, don't use it
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.)
and it just respects my look and feel (colors, borders, font sizes, etc).
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?