As I said, that's not Silverlight. I know (and said) that Netflix worked on x86 Chromebooks, but with a custom plugin, not Silverlight.

Are you sure?

Unless your Chromebook doesn't run Chrome OS, you don't have Silverlight. Silverlight only works on Windows and OS X. Moonlight IIRC got discontinued (which was basically Silverlight for Linux) but it never worked with Netflix because it lacked Silverlight's DRM. Plus, in the summary itself it even says "ARM Chromebooks", so I doubt your x86 Chromebook is using the HTML5 stuff. Apparently it uses some EME stuff that's not on the x86 Chromebooks yet. I believe that Google and Netflix partnered up to release a plugin just for Netflix on x86 Chromebooks, but that was quite some time ago.

First of all, I'm not sure exactly what you're saying. That being said, my point is that opening it up to the world (which is the most extreme option) wouldn't do anything, because there's no way for attackers to get in. The rules specifically allow the attackers to specify a website that will be navigated to. So leaving a Chrome OS laptop just sitting there won't do anything, because there's no way for attackers to get in; you're going to have to go to an attack page of some sort.

To the best of my knowledge, Chrome OS doesn't listen on any ports out of the box. Even DMZing it would do nothing, because there's nothing for attackers to connect to. Perhaps you should learn more about Chrome OS before you come up with ideas like this.

Which explains why everything else there was broken, right? Nope, wait, also complete nonsense.

Is that anything like +1 Funny?

That may work for third-party applications, but what about the built-in ones? What about the kernel? The simple fact of the matter is once XP goes EOL there's no way to continue supporting it yourself.

If you use EAP-TLS or EAP-TTLS the station should complain that the RADIUS server's certificate is not valid. Most of the other EAP schemes have similar security precautions.

You are correct, Firefox is 32-bit on Windows. I believe Chrome may be more suitable for 64-bit on Windows than Firefox, as well (but I could be wrong here). Because of Chrome's multi-process model, compatibility with 32-bit plugins should be fairly trivial. The process running the plugin can be 32-bit (for plugins that are 32-bit only, such as Flash IIRC), but the rest of the browser's processes can be 64-bit. I know that Firefox does run plugins in a separate process (open Firefox, go to a site that uses some plugin, open Task Manager, and notice at least one "plugin-container.exe" process), but I don't know how easily plugin-container could be adapted to support 32-bit plugins on 64-bit Firefox.

Even if you unlock your phone, if you have a contract with a carrier you have two options: keep paying for the cell phone service to the end of your contract's term or pay the ETF laid out in your contract. Either way, the carrier gets money. There's no reason unlocking should be illegal. The only money that the carriers may lose is the insanely high overage charges we have here in the US, but that's no reason to forbid people from unlocking their phones. It's not the government's job to enforce business models.

As I said over an hour before you posted, the IPv6 prefix is just as effective as a NAT'd IPv4 address tracking-wise. The privacy extensions don't improve the situation compared to IPv4, merely bring it to the same level. Try reading before you post next time, please.

If you do that, then the IPv6 prefix is just as effective as a NAT'd IPv4 address tracking-wise. No more, no less. But you're right, no one dares to track you by your IPv4 address these days...

AC is right. Deleting cookies at the end of each session may help a bit, but there are still plenty of ways to identify you especially if you include your IP address (but that's not always reliable).

There's already a solution for that. Use the randomly-generated address for normal things, but use your static address for servers and the like. IPv6 privacy extensions are supported on Windows, Mac, and Linux.

There's also a problem when you don't know exactly how much work needs performed. Let's say you're copying two files: foo (1KB) and baz (1GB). A naive implementation may set the progress bar to 50% when foo has been copied, assuming they are close to the same size. Thus, the progress bar would quickly jump to 50% and then slowly go up (assuming the remaining 50% are given accurately based on baz's size). This can be fixed by checking the size of all the files first, but that was merely an example of the "true amount of work unknown" problem.

Were the files over 2GB? I believe that was the IE bug wrt large files: downloading files over 2GB or 4GB (depending on the version of IE) would fail spectacularly including negative progress. It's even documented on kernel.org.