Because there's no way to make it work. v4 is incapable of talking to v6, because there isn't enough space in the v4 destination address field for the v6 address to go. You'd need to somehow make every v6 address also be a v4 address, but that won't work because there are only 32 bits available in v4 and that's nowhere close to enough. There's nothing v6 can do about this, because it's v4's problem.
One possible workaround would be to do NAT with v6 on the inside, but doing that would only allow outbound connections from v6 to v4. Also it's called NAT64 and it's already a thing that exists and you can use it and it works. Is that good enough for you?
I'm confused. Where do you get the idea that they made no attempt at backward compatibility? We have 6to4, Teredo, NAT64+(DNS64/464XLAT), 6rd and DS-lite, we have standard APIs that work with both v4 and v6 addresses interchangeably and you can run the two protocols in parallel on the exact same networks and hosts and they won't interfere with each other. What part of that comes under "no attempt at backward compatibility"?
Perhaps you mean that you can't make connections from unmodified v4-only hosts to v6-only ones, but that's impossible because of the pigeonhole principle, and it would be a little unfair to criticise v6 for not doing something that's impossible.
Direct connectivity is impossible, and any attempt at working around that results in something that looks like one of the transition techs that we already have. So what more could they possibly have done?
From what I've seen, those "reputable, well-engineered VPNs" block v6 because they're crap and don't support it. What they should do is exactly the same thing they do for v4: put the traffic down the VPN.
v6+privacy addresses is no worse than v4+NAT for your privacy. Both of them are crap, of course, because they let you connect to web servers which track you via cookies and browser fingerprinting, but there's no reason to avoid v6 on this count.
We probably won't. Devices having a public IP isn't a problem; just because you have a public IP doesn't mean it's possible to connect to it. ISPs provide routers that have firewalls, and the firewalls block inbound connections. Your "average joe blow" just plugs that in and they're fine.
What happens today is that people buy IP cameras, and then they go "hey, how do I view this from the office?", followed shortly by port forwarding to the camera or putting it in the DMZ. 30 seconds later, somebody finds the camera in a random port scan, because the v4 internet is tiny and it's very easy to exhaustively scan the entire thing. With v6, this isn't going to happen -- it's nigh on impossible to find devices by randomly scanning the internet, because it's just too big. Of course that doesn't make the device itself secure, but it should render random network scanning useless as a technique for spreading worms, which should improve the security of the internet as a whole.
You say that as if you think that our brains aren't just weighted directed acyclic graphs -- but that is in opposition to the article and the research, which seems to demonstrate that that's pretty much what brains are, at least for this particular part of their functionality.
They've already deployed IPv6 to their entire consumer customer base.
(Unfortunately the routers they used to give out don't do v6, so if you have a "Home Hub 5" or earlier then you'll need to get that replaced, which is why only 35% of their users are actually using v6 rather than the 93% or so that Sky are at. But they are in fact providing it.)
The goal is to get T-Mobile to change their bad behavior, and if this fine gets them to do it (which, at $40M, seems like it might not...) then the goal is achieved, regardless of where the money goes.
Most of the affected people will be non-T-Mobile customers; the only identification T-Mobile have is their phone numbers. Tracking down the owner of each phone number at the time of each call and mailing out who knows how many millions of checks would likely cost more than the fine amount, at which point you wouldn't be getting anything anyway.
It's perhaps unfortunate that the fine doesn't go to the people who were wronged, but that's not a good reason to not do the fine. At least this way the money can be channelled into other enforcement efforts (although given that this is the US, I have a feeling that's probably not what's actually going to happen to it).
He is aiming to supply 230W for 15 minutes, which he says will power a "typical desktop system with 4k monitor." It won't, for that you need at least 500W and unless you want to play a careful balancing game more like 1000W. Sure, you system might average 230W, but peak load...
It might, depending on how much extra hardware you're running beyond a single SSD and whether the system is idle or not.
Peak load is a separate thing, but you don't need to be able to supply 1000 W for 15 minutes to be able to cover 1000 W peaks.
Maybe consider GPU passthrough. In my experience it works very nicely and is more or less equivalent to dual boot but without needing to reboot all the time. (Or more accurately: equivalent to having two separate machines, but without needing two machines.)
When you can switch between Linux and Windows just by pressing a button on a HDMI switcher remote (or alt-tabbing to LookingGlass), it becomes a lot less irritating to use Windows only for the things that require it.
Is it really so unlikely? They'd be moving from a browser that's confirmed to ship your browsing history off, to one that isn't (excluding Sync, but that's opt-in).
Also, let's be honest: where else are you going to go?
In the case of Germany, I suspect it was more the whole Cliqz thing rather than Fx57. (Which is unfortunate, because it suggests that most people are just going to go on using Firefox rather than get Mozilla to fix their current extension situation.)
In case you missed it, Mozilla shipped a small percentage of new installs in Germany with an extension that records your visited URLs and any text entered into the address bar and sends it off to a third party company. Germany is relatively privacy-conscious and I suspect many German users didn't take too kindly to that.
It's true that it doesn't show up until the 5th page of results if you just search for "pichai", but that might be because it's a 5 month old news article that's getting crowded out by multiple articles that are closer to 5 hours old.
The part where "arbitrary process memory" includes the kernel is indeed Intel-only, yes. The discussion was about exploiting Meltdown from JS, after all, not Spectre. If you only target user address space then the reads will complete just fine on AMD.
It's also possible to extract data from a different process by finding code in that process that can be used to leak data. That part of Spectre works fine on AMD too, and I see no reason why the process in question couldn't be the kernel (even AMD's processors allow kernel code to read kernel address space, after all). I think that variant would be very difficult to exploit from Javascript, however.
I'm not sure which research you're referring to, because I've read the Kocher paper ("Spectre Attacks: Exploiting Speculative Execution") and it talks about leaking info from a target process by getting the target process to execute some of its own code:
in this method the attacker chooses a gadget from the address space of the victim and influences the victim to execute the gadget speculatively
To mistrain the BTB, the attacker finds the virtual address of the gadget in the victim's address space, then performs indirect branches to this address. This training is done from the attacker's address space
It's pretty clear from the paper I read that the gadget has to be in the same process, but the mistraining can happen from another process and the gadget leaks info via a side-channel that can be read by any process. Also there is nothing stopping the gadget from being in the kernel, in which case "same process" is the kernel, which includes the kernel's map of the entire physical RAM.
Yes, Meltdown is a very serious issue, but it has both a software workaround and an obvious hardware fix. Spectre is an entire class of issues that we're going to be dealing with for probably decades.
This post may look well-written, but it's also mostly wrong. Spectre affects Intel, AMD, ARM as well as other CPUs, because it's a vulnerability in speculative execution as a concept, not in any particular implementation of it. Intel have an additional issue in that their speculative execution ignores user/kernel permission checks on memory accesses.
Spectre allows a piece of code to read everything in its own address space, and to leak that info to any other process. It's also possible to use existing and completely bug-free code in other processes (including the kernel) to get those processes to leak their address space to you. This allows, for example, Javascript executing in a sandbox to read the entire address space of the browser process that it's running in, and it can also be used to get the kernel to leak its own address space, which includes all of physical RAM. Spectre is in no way trivial or insignificant.
Meltdown is also serious, but in many ways it's the lesser problem because there's a kernel-level workaround for existing hardware plus a clear path to fixing it in new hardware (i.e. for Intel to update their designs to not speculatively load memory across a permission boundary). Spectre is going to be much more difficult to fix, unless you are okay with tanking performance by outright disabling speculative execution, because it's an entire new class of vulnerabilities. There is some work going on to alter compilers to avoid generating known exploitable code, which will definitely help but is far from a full fix -- we would need to get the code generation change into every single compiler and recompile every single piece of software, and it would still only help against specific known instances of Spectre (and in fact the current work only guards against one of the two published variants of it).
There is no direct evidence that Meltdown is an NSA backdoor. Although it is certainly an absolutely marvellous vulnerability for them, it's believable that Intel engineered their processors the way they did because they simply didn't realize it was unsafe. Spectre certainly isn't a deliberate backdoor; we've spent decades designing our CPUs around "be as fast as possible", and speculative execution is a part of that.
Having said all of that, I do agree that anybody buying new CPUs now should be giving AMD an even more serious look than they were before. On top of all the other good reasons to be going with Ryzen/Threadripper, they also didn't just get a big speed nerf.
Unless I'm misunderstanding it, the Javascript PoC in the paper can read arbitrary memory offsets. The JS is approximately this: if (index < simpleByteArray.length) {
index = simpleByteArray[index];
index = (index * TABLE1_STRIDE) & (TABLE1_BYTES-1);
localJunk ^= probeTable[index]; }
and the JIT will compile the second line of that to: REX.W leaq rsi,[r12+rdx*1] ; Set rsi=r12+rdx=addr of first byte in simpleByteArray movzxbl rsi,[rsi+r15*1] ; Read byte from address rsi+r15 (= base address+index)
The base address is constrained by wherever the browser decided to allocate simpleByteArray, but index is fully under attacker control so they can pick whatever memory address they like, which of course includes the addresses that the kernel is mapped into.
I think this is still technically within the bounds of the original quote, because this only gives you the ability to read the entire contents of RAM. You can't write to it, and your own code is still stuck executing inside the browser sandbox.
The energy costs are not so high these days. I have a quad core desktop-class CPU from two generations ago, and it can do ~1 GB/s of AES on each core, which is something in the region of 30 Gbit/s of encrypted traffic in total. Most servers don't even have more than a single 10 Gbit/s NIC... or rather, most servers are still on 1 Gbit/s, which would mean spending all of 3% of my CPU on encryption. The time/energy required to generate the data that's being sent would be far higher.
We also have TLS session resumption now. We're no longer in the Hotmail era. The energy costs of HTTPS are incredibly cheap compared to all of the security and privacy holes that it closes.
HTTPS is easily broken by the NSA if you use any official signing authority except perhaps Let's Encrypt
Um, no. You do know that signing authorities only sign the public part of your key, right? You don't give them the private part of the key.
Encryption fixes many problems caused by plain-text HTTP and is fully worth doing everywhere. It's true that there are some problems that HTTPS doesn't fix, but that is not a good reason to not use it.
Ah, I see -- you're not talking about downtime on the server side, but rather a scenario where the website (or API or...) clients are whitelisting particular cert fingerprints, and the new cert needs to be added to the client-side whitelist before it can be used.
(I interpreted "clients" as being people paying for your contracting services.)
But I still don't see that downtime is necessary here. Just tell the clients the new cert fingerprint ahead of starting to use it.
My point was merely that it is still possible to commit this particular fuckup even if you're using NAT. (In fact the NAT probably makes it more likely you'll do it, because it may lull you into a false sense of security,)
I wouldn't put too much trust in DFEOJM.com; it even claims that Google is down. Meanwhile, I have no trouble connecting to ipv6.vm1.test-ipv6.com:
Connecting to ipv6.vm1.test-ipv6.com (ipv6.vm1.test-ipv6.com)|2001:470:1:18::119|:80... connected.
You might be single-homed behind Cogent, who have an issue with reaching HE (specifically, the issue is that they just can't stop being assholes). If so then you should probably talk to your ISP and get them to get an extra upstream.
Slashdot Mirror
Because there's no way to make it work. v4 is incapable of talking to v6, because there isn't enough space in the v4 destination address field for the v6 address to go. You'd need to somehow make every v6 address also be a v4 address, but that won't work because there are only 32 bits available in v4 and that's nowhere close to enough. There's nothing v6 can do about this, because it's v4's problem.
One possible workaround would be to do NAT with v6 on the inside, but doing that would only allow outbound connections from v6 to v4. Also it's called NAT64 and it's already a thing that exists and you can use it and it works. Is that good enough for you?
I'm confused. Where do you get the idea that they made no attempt at backward compatibility? We have 6to4, Teredo, NAT64+(DNS64/464XLAT), 6rd and DS-lite, we have standard APIs that work with both v4 and v6 addresses interchangeably and you can run the two protocols in parallel on the exact same networks and hosts and they won't interfere with each other. What part of that comes under "no attempt at backward compatibility"?
Perhaps you mean that you can't make connections from unmodified v4-only hosts to v6-only ones, but that's impossible because of the pigeonhole principle, and it would be a little unfair to criticise v6 for not doing something that's impossible.
Direct connectivity is impossible, and any attempt at working around that results in something that looks like one of the transition techs that we already have. So what more could they possibly have done?
From what I've seen, those "reputable, well-engineered VPNs" block v6 because they're crap and don't support it. What they should do is exactly the same thing they do for v4: put the traffic down the VPN.
v6+privacy addresses is no worse than v4+NAT for your privacy. Both of them are crap, of course, because they let you connect to web servers which track you via cookies and browser fingerprinting, but there's no reason to avoid v6 on this count.
We probably won't. Devices having a public IP isn't a problem; just because you have a public IP doesn't mean it's possible to connect to it. ISPs provide routers that have firewalls, and the firewalls block inbound connections. Your "average joe blow" just plugs that in and they're fine.
What happens today is that people buy IP cameras, and then they go "hey, how do I view this from the office?", followed shortly by port forwarding to the camera or putting it in the DMZ. 30 seconds later, somebody finds the camera in a random port scan, because the v4 internet is tiny and it's very easy to exhaustively scan the entire thing. With v6, this isn't going to happen -- it's nigh on impossible to find devices by randomly scanning the internet, because it's just too big. Of course that doesn't make the device itself secure, but it should render random network scanning useless as a technique for spreading worms, which should improve the security of the internet as a whole.
If anybody was still wondering why the GDPR is a thing... stuff like this is why.
You say that as if you think that our brains aren't just weighted directed acyclic graphs -- but that is in opposition to the article and the research, which seems to demonstrate that that's pretty much what brains are, at least for this particular part of their functionality.
They've already deployed IPv6 to their entire consumer customer base.
(Unfortunately the routers they used to give out don't do v6, so if you have a "Home Hub 5" or earlier then you'll need to get that replaced, which is why only 35% of their users are actually using v6 rather than the 93% or so that Sky are at. But they are in fact providing it.)
The goal is to get T-Mobile to change their bad behavior, and if this fine gets them to do it (which, at $40M, seems like it might not...) then the goal is achieved, regardless of where the money goes.
Most of the affected people will be non-T-Mobile customers; the only identification T-Mobile have is their phone numbers. Tracking down the owner of each phone number at the time of each call and mailing out who knows how many millions of checks would likely cost more than the fine amount, at which point you wouldn't be getting anything anyway.
It's perhaps unfortunate that the fine doesn't go to the people who were wronged, but that's not a good reason to not do the fine. At least this way the money can be channelled into other enforcement efforts (although given that this is the US, I have a feeling that's probably not what's actually going to happen to it).
He is aiming to supply 230W for 15 minutes, which he says will power a "typical desktop system with 4k monitor." It won't, for that you need at least 500W and unless you want to play a careful balancing game more like 1000W. Sure, you system might average 230W, but peak load...
It might, depending on how much extra hardware you're running beyond a single SSD and whether the system is idle or not.
Peak load is a separate thing, but you don't need to be able to supply 1000 W for 15 minutes to be able to cover 1000 W peaks.
He posted about this exact thing if you want to get some insight into the reasoning.
The real-time aspects will still be handled by a microcontroller.
Maybe consider GPU passthrough. In my experience it works very nicely and is more or less equivalent to dual boot but without needing to reboot all the time. (Or more accurately: equivalent to having two separate machines, but without needing two machines.)
When you can switch between Linux and Windows just by pressing a button on a HDMI switcher remote (or alt-tabbing to LookingGlass), it becomes a lot less irritating to use Windows only for the things that require it.
10:51 UTC to 16:08 UTC. Greatest eclipse at 13:29 UTC.
Why the summary couldn't have just said that, I don't know.
Is it really so unlikely? They'd be moving from a browser that's confirmed to ship your browsing history off, to one that isn't (excluding Sync, but that's opt-in).
Also, let's be honest: where else are you going to go?
In the case of Germany, I suspect it was more the whole Cliqz thing rather than Fx57. (Which is unfortunate, because it suggests that most people are just going to go on using Firefox rather than get Mozilla to fix their current extension situation.)
In case you missed it, Mozilla shipped a small percentage of new installs in Germany with an extension that records your visited URLs and any text entered into the address bar and sends it off to a third party company. Germany is relatively privacy-conscious and I suspect many German users didn't take too kindly to that.
https://www.google.com/search?... second result.
https://www.google.com/search?... first result.
https://www.google.com/search?... second result.
https://www.google.com/search?... first result.
Seems to be fairly findable on Google.
https://www.google.com/search?...
First result.
It's true that it doesn't show up until the 5th page of results if you just search for "pichai", but that might be because it's a 5 month old news article that's getting crowded out by multiple articles that are closer to 5 hours old.
The part where "arbitrary process memory" includes the kernel is indeed Intel-only, yes. The discussion was about exploiting Meltdown from JS, after all, not Spectre. If you only target user address space then the reads will complete just fine on AMD.
It's also possible to extract data from a different process by finding code in that process that can be used to leak data. That part of Spectre works fine on AMD too, and I see no reason why the process in question couldn't be the kernel (even AMD's processors allow kernel code to read kernel address space, after all). I think that variant would be very difficult to exploit from Javascript, however.
I'm not sure which research you're referring to, because I've read the Kocher paper ("Spectre Attacks: Exploiting Speculative Execution") and it talks about leaking info from a target process by getting the target process to execute some of its own code:
in this method the attacker chooses a gadget from the address space of the victim and influences the victim to execute the gadget speculatively
To mistrain the BTB, the attacker finds the virtual address of the gadget in the victim's address space, then performs indirect branches to this address. This training is done from the attacker's address space
It's pretty clear from the paper I read that the gadget has to be in the same process, but the mistraining can happen from another process and the gadget leaks info via a side-channel that can be read by any process. Also there is nothing stopping the gadget from being in the kernel, in which case "same process" is the kernel, which includes the kernel's map of the entire physical RAM.
Yes, Meltdown is a very serious issue, but it has both a software workaround and an obvious hardware fix. Spectre is an entire class of issues that we're going to be dealing with for probably decades.
This post may look well-written, but it's also mostly wrong. Spectre affects Intel, AMD, ARM as well as other CPUs, because it's a vulnerability in speculative execution as a concept, not in any particular implementation of it. Intel have an additional issue in that their speculative execution ignores user/kernel permission checks on memory accesses.
Spectre allows a piece of code to read everything in its own address space, and to leak that info to any other process. It's also possible to use existing and completely bug-free code in other processes (including the kernel) to get those processes to leak their address space to you. This allows, for example, Javascript executing in a sandbox to read the entire address space of the browser process that it's running in, and it can also be used to get the kernel to leak its own address space, which includes all of physical RAM. Spectre is in no way trivial or insignificant.
Meltdown is also serious, but in many ways it's the lesser problem because there's a kernel-level workaround for existing hardware plus a clear path to fixing it in new hardware (i.e. for Intel to update their designs to not speculatively load memory across a permission boundary). Spectre is going to be much more difficult to fix, unless you are okay with tanking performance by outright disabling speculative execution, because it's an entire new class of vulnerabilities. There is some work going on to alter compilers to avoid generating known exploitable code, which will definitely help but is far from a full fix -- we would need to get the code generation change into every single compiler and recompile every single piece of software, and it would still only help against specific known instances of Spectre (and in fact the current work only guards against one of the two published variants of it).
There is no direct evidence that Meltdown is an NSA backdoor. Although it is certainly an absolutely marvellous vulnerability for them, it's believable that Intel engineered their processors the way they did because they simply didn't realize it was unsafe. Spectre certainly isn't a deliberate backdoor; we've spent decades designing our CPUs around "be as fast as possible", and speculative execution is a part of that.
Having said all of that, I do agree that anybody buying new CPUs now should be giving AMD an even more serious look than they were before. On top of all the other good reasons to be going with Ryzen/Threadripper, they also didn't just get a big speed nerf.
Unless I'm misunderstanding it, the Javascript PoC in the paper can read arbitrary memory offsets. The JS is approximately this:
if (index < simpleByteArray.length) {
index = simpleByteArray[index];
index = (index * TABLE1_STRIDE) & (TABLE1_BYTES-1);
localJunk ^= probeTable[index];
}
and the JIT will compile the second line of that to:
REX.W leaq rsi,[r12+rdx*1] ; Set rsi=r12+rdx=addr of first byte in simpleByteArray
movzxbl rsi,[rsi+r15*1] ; Read byte from address rsi+r15 (= base address+index)
The base address is constrained by wherever the browser decided to allocate simpleByteArray, but index is fully under attacker control so they can pick whatever memory address they like, which of course includes the addresses that the kernel is mapped into.
I think this is still technically within the bounds of the original quote, because this only gives you the ability to read the entire contents of RAM. You can't write to it, and your own code is still stuck executing inside the browser sandbox.
The energy costs are not so high these days. I have a quad core desktop-class CPU from two generations ago, and it can do ~1 GB/s of AES on each core, which is something in the region of 30 Gbit/s of encrypted traffic in total. Most servers don't even have more than a single 10 Gbit/s NIC... or rather, most servers are still on 1 Gbit/s, which would mean spending all of 3% of my CPU on encryption. The time/energy required to generate the data that's being sent would be far higher.
We also have TLS session resumption now. We're no longer in the Hotmail era. The energy costs of HTTPS are incredibly cheap compared to all of the security and privacy holes that it closes.
HTTPS is easily broken by the NSA if you use any official signing authority except perhaps Let's Encrypt
Um, no. You do know that signing authorities only sign the public part of your key, right? You don't give them the private part of the key.
Encryption fixes many problems caused by plain-text HTTP and is fully worth doing everywhere. It's true that there are some problems that HTTPS doesn't fix, but that is not a good reason to not use it.
Ah, I see -- you're not talking about downtime on the server side, but rather a scenario where the website (or API or...) clients are whitelisting particular cert fingerprints, and the new cert needs to be added to the client-side whitelist before it can be used.
(I interpreted "clients" as being people paying for your contracting services.)
But I still don't see that downtime is necessary here. Just tell the clients the new cert fingerprint ahead of starting to use it.
My point was merely that it is still possible to commit this particular fuckup even if you're using NAT. (In fact the NAT probably makes it more likely you'll do it, because it may lull you into a false sense of security,)
I wouldn't put too much trust in DFEOJM.com; it even claims that Google is down. Meanwhile, I have no trouble connecting to ipv6.vm1.test-ipv6.com:
Connecting to ipv6.vm1.test-ipv6.com (ipv6.vm1.test-ipv6.com)|2001:470:1:18::119|:80... connected.
You might be single-homed behind Cogent, who have an issue with reaching HE (specifically, the issue is that they just can't stop being assholes). If so then you should probably talk to your ISP and get them to get an extra upstream.