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.
A router only to wifi to the Chrome OS and no active prevention measures (human intervention).
If it's still standing securely after that time then I'll be impressed. Until then this is just great
advertisement for the Chrome OS and nothing more.
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.
Researchers is a broad term and the conditions kept many away.
Which explains why everything else there was broken, right? Nope, wait, also complete nonsense.
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.
This is less good advice because, aside from being really hard, the Evil Twin attack might be able to defeat it. I'm not sure, though.
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.
The subsidized phone model doesn't work without the locked phone model.
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...
They can still track by IP address and you're browser fingerprint. Browser fingerprinting can be defeated though current browsers don't seem to want to help make it easier to do so.
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).
I'm not sure what we'll do when IPv6 rolls around and every device has a unique address. Either you go back to NAT and share addresses, which is not completely effective due to fingerprinting, or you change your address every few hours or days. Either solution defeats the purpose of IPv6.
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.
Rosetta is not even installed on Mac OS X by default anymore.
It hasn't been available at all since Lion (10.7). Snow Leopard (10.6) didn't have it by default but at least supported it. I wouldn't be surprised to find out that someone has gotten Rosetta from 10.6 to work on {Mountain,}Lion, but even if it works it's not guaranteed to work after patches or to not just blow up in your face.
Have you done multi-threaded programming? Everything needs to be re-entrant if it can possibly be called from more than one thread, even if there are different instances/contexts across threads. It's not as simple as "make new thread, hook things up, fire thread".
Explain how that scenario has different requirements from the current implementation in browsers, from the thread POV.
As I said, everything needs to be re-entrant (which there's no reason for it to be with only one thread), and everything shared across threads needs to be made thread-safe. Files, I/O, and everything with side effects needs to be locked so threads don't stomp on each other. Even with one thread per tab, lots of resources are shared across threads. Perhaps most of the work wouldn't be in the JS engine itself. It doesn't matter. This thread was about it being non-trivial to add threading or multiple processes to a single threaded, single process browser, which there's no way you can argue with.
I think we're talking about completely different things. I agree with all of your points, but I'm saying that it is very non-trivial to run one thread per page, even just for the JS engine, because of the work that has to be done. You're saying that the JS engine itself doesn't need a ton of work, which is correct (although everything must be re-entrant, which does require work unless everything is already re-entrant). Please don't forget that while thread-safe functions aren't required if one context only has one thread, you still need re-entrant functions as soon as you get more than one thread.
Generally, JS is single-threaded, especially within a page. You'll note there's no "thread" type, class, nor anything else you can access from within the browser (to stay on topic, Node.js etc are not in scope) You can achieve multi-threading via Ajax, which does run a separate I/O and "thread" in JS, and can cause some interesting behavior (race conditions) if you have multiple Ajax calls affecting the same element set.
Correct, but you were saying that the JS engine itself should have a pool of threads, and that is what I was addressing.
Going further - the I/O for cookies is handled underneath the JS engine, the JS engine itself, at least as far as page rendering and UI interaction goes, is single threaded.
Cookies were merely an example. There are plenty of cases where you need not only re-entrant functions, but thread-safe ones as well. Furthermore, even if the cookie I/O isn't handled by the JS engine itself, it's still irrelevant. If two pages are running (with one JS engine thread per page) and both try to access cookies, you really should hope the cookie accessors are thread-safe. Whether or not the access is done directly from the JS engine doesn't matter much as long as there are multiple threads running simultaneously.
as far as the JS engine goes, there is no IPC, and even in Chrome
I never claimed that there was IPC specifically in Chrome's JS engine. The point was that, as Chrome uses multiple processes, there is lots of IPC. Specifically, I was pointing out that for someone to add multi-processing to any given browser (in this case Firefox), even just for the JS engine, they'd need to do lots of work to get the IPC working. The only reason Chrome's JS engine doesn't do IPC is because it is part of the same processes as the renderer AFAIK.
I get the concept of a script locking up the JS engine, but my point is that you should always get the unresponsive script warning, with the option to stop it. If you don't, then it's a bug.
I don't know why you say there's no IPC. Chrome uses IPC heavily as documented here. I don't see any way around it, either.
Again, I don't know why you say you wouldn't need thread-safe functions either. Imagine if one thread reads the cookie database, and another writes to it. You bet that needs to be thread-safe... even if you're talking about the JS engine. I'm not a big JavaScript developer, but I know you're still going to need thread safety. Hell, everything would need to be, at the very least, re-entrant. Also, for what it's worth, the OS normally schedules threads with common threading libraries (like pthreads, but NOT GNU Pth which only has one OS thread and does its own scheduling).
Though this is fairly OT (given that this story is about Java blocking), the script being on another tab shouldn't matter. That sounds like a bug to me. Chrome for me uses far more memory than Firefox, because it spawns at least one process per page (as well as per extension!) but the multi-process model does have nice benefits, such as one page not being able to slow down the rest (unless your CPU is pegged/hard drive is thrashing). I'm also reasonably confident that the JS engine doesn't use threads either. They specifically mention not seeing any benefits in a multi-threaded model, just more complexity. Also, why are separate processes easier? With threads, you need to worry about thread-safe functions and mutexes. With processes, you need an entire IPC system to coordinate things between processes. Personally I find both a pain, but I certainly wouldn't call processes easier at all.
Winapp2.com is the official website of Winapp2.ini, an addon for CCleaner, System Ninja, and
BleachBit that adds support for over one thousand additional programs.
It doesn't come from CCleaner, CCleaner merely supports it as well. They may have even come up with the format (I don't know), but the file was created by the community not Piriform.
That has never happened to me ever. Any script hogging the CPU should trigger the long-running script warning, giving you the option to kill it. Even when that happens, I still can use the rest of the browser, it's just sluggish. I have no idea why it would block everything else. You're right though, only browsers that use one process per tab are immune to that (such as Chrome).
It's about user choice. See how the parent said "explicitly tell it so"? Yes, you can run vulnerable plugins but only after you are aware that it's vulnerable, and explicitly request to be be re-enabled. The automatic updater is much more effective now than it was before, but it still doesn't force people to update. Mozilla forces almost nothing, including blocklisting (hard blocks aren't possible to override, but those are only used for plugins that crash on startup or are outright malware). If you want someone making your choices for you and not letting you work around them, then perhaps Firefox isn't your browser.
Slashdot Mirror
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.
A router only to wifi to the Chrome OS and no active prevention measures (human intervention). If it's still standing securely after that time then I'll be impressed. Until then this is just great advertisement for the Chrome OS and nothing more.
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.
Researchers is a broad term and the conditions kept many away.
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.
This is less good advice because, aside from being really hard, the Evil Twin attack might be able to defeat it. I'm not sure, though.
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.
The subsidized phone model doesn't work without the locked phone model.
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...
They can still track by IP address and you're browser fingerprint. Browser fingerprinting can be defeated though current browsers don't seem to want to help make it easier to do so.
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).
I'm not sure what we'll do when IPv6 rolls around and every device has a unique address. Either you go back to NAT and share addresses, which is not completely effective due to fingerprinting, or you change your address every few hours or days. Either solution defeats the purpose of IPv6.
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.
Rosetta is not even installed on Mac OS X by default anymore.
It hasn't been available at all since Lion (10.7). Snow Leopard (10.6) didn't have it by default but at least supported it. I wouldn't be surprised to find out that someone has gotten Rosetta from 10.6 to work on {Mountain ,}Lion, but even if it works it's not guaranteed to work after patches or to not just blow up in your face.
Explain how that scenario has different requirements from the current implementation in browsers, from the thread POV.
As I said, everything needs to be re-entrant (which there's no reason for it to be with only one thread), and everything shared across threads needs to be made thread-safe. Files, I/O, and everything with side effects needs to be locked so threads don't stomp on each other. Even with one thread per tab, lots of resources are shared across threads. Perhaps most of the work wouldn't be in the JS engine itself. It doesn't matter. This thread was about it being non-trivial to add threading or multiple processes to a single threaded, single process browser, which there's no way you can argue with.
I think we're talking about completely different things. I agree with all of your points, but I'm saying that it is very non-trivial to run one thread per page, even just for the JS engine, because of the work that has to be done. You're saying that the JS engine itself doesn't need a ton of work, which is correct (although everything must be re-entrant, which does require work unless everything is already re-entrant). Please don't forget that while thread-safe functions aren't required if one context only has one thread, you still need re-entrant functions as soon as you get more than one thread.
Generally, JS is single-threaded, especially within a page. You'll note there's no "thread" type, class, nor anything else you can access from within the browser (to stay on topic, Node.js etc are not in scope) You can achieve multi-threading via Ajax, which does run a separate I/O and "thread" in JS, and can cause some interesting behavior (race conditions) if you have multiple Ajax calls affecting the same element set.
Correct, but you were saying that the JS engine itself should have a pool of threads, and that is what I was addressing.
Going further - the I/O for cookies is handled underneath the JS engine, the JS engine itself, at least as far as page rendering and UI interaction goes, is single threaded.
Cookies were merely an example. There are plenty of cases where you need not only re-entrant functions, but thread-safe ones as well. Furthermore, even if the cookie I/O isn't handled by the JS engine itself, it's still irrelevant. If two pages are running (with one JS engine thread per page) and both try to access cookies, you really should hope the cookie accessors are thread-safe. Whether or not the access is done directly from the JS engine doesn't matter much as long as there are multiple threads running simultaneously.
as far as the JS engine goes, there is no IPC, and even in Chrome
I never claimed that there was IPC specifically in Chrome's JS engine. The point was that, as Chrome uses multiple processes, there is lots of IPC. Specifically, I was pointing out that for someone to add multi-processing to any given browser (in this case Firefox), even just for the JS engine, they'd need to do lots of work to get the IPC working. The only reason Chrome's JS engine doesn't do IPC is because it is part of the same processes as the renderer AFAIK.
I get the concept of a script locking up the JS engine, but my point is that you should always get the unresponsive script warning, with the option to stop it. If you don't, then it's a bug.
I don't know why you say there's no IPC. Chrome uses IPC heavily as documented here. I don't see any way around it, either.
Again, I don't know why you say you wouldn't need thread-safe functions either. Imagine if one thread reads the cookie database, and another writes to it. You bet that needs to be thread-safe... even if you're talking about the JS engine. I'm not a big JavaScript developer, but I know you're still going to need thread safety. Hell, everything would need to be, at the very least, re-entrant. Also, for what it's worth, the OS normally schedules threads with common threading libraries (like pthreads, but NOT GNU Pth which only has one OS thread and does its own scheduling).
Louise Kinane
Customer Experience Manager | Head of UK Operations | Piriform
IANAL, but I agree with the advice to send a polite but firm "no, unless you can provide a legal backing to your request".
Though this is fairly OT (given that this story is about Java blocking), the script being on another tab shouldn't matter. That sounds like a bug to me. Chrome for me uses far more memory than Firefox, because it spawns at least one process per page (as well as per extension!) but the multi-process model does have nice benefits, such as one page not being able to slow down the rest (unless your CPU is pegged/hard drive is thrashing). I'm also reasonably confident that the JS engine doesn't use threads either. They specifically mention not seeing any benefits in a multi-threaded model, just more complexity. Also, why are separate processes easier? With threads, you need to worry about thread-safe functions and mutexes. With processes, you need an entire IPC system to coordinate things between processes. Personally I find both a pain, but I certainly wouldn't call processes easier at all.
Winapp2.com is the official website of Winapp2.ini, an addon for CCleaner, System Ninja, and BleachBit that adds support for over one thousand additional programs.
http://winapp2.com/
It doesn't come from CCleaner, CCleaner merely supports it as well. They may have even come up with the format (I don't know), but the file was created by the community not Piriform.
That has never happened to me ever. Any script hogging the CPU should trigger the long-running script warning, giving you the option to kill it. Even when that happens, I still can use the rest of the browser, it's just sluggish. I have no idea why it would block everything else. You're right though, only browsers that use one process per tab are immune to that (such as Chrome).
It's about user choice. See how the parent said "explicitly tell it so"? Yes, you can run vulnerable plugins but only after you are aware that it's vulnerable, and explicitly request to be be re-enabled. The automatic updater is much more effective now than it was before, but it still doesn't force people to update. Mozilla forces almost nothing, including blocklisting (hard blocks aren't possible to override, but those are only used for plugins that crash on startup or are outright malware). If you want someone making your choices for you and not letting you work around them, then perhaps Firefox isn't your browser.