Forgot your password?
typodupeerror

Comment: Re:Not on the x86 Acer C7 Chromebook (Score 1) 232

by dririan (#43145923) Attached to: Netflix Using HTML5 Video For ARM Chromebook
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.

Comment: Re:Stick it online for four hours (Score 1) 178

by dririan (#43126227) Attached to: Chrome OS Remains Undefeated At Pwnium 3
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.

Comment: Re:Stick it online for four hours (Score 2) 178

by dririan (#43123661) Attached to: Chrome OS Remains Undefeated At Pwnium 3

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.

Comment: Re:WPA2-Enterprise (Score 1) 884

by dririan (#42993497) Attached to: Ask Slashdot: Dealing With an Advanced Wi-Fi Leech?

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.

Comment: Re:And STILL No 64 Bit (Score 1) 93

by dririan (#42988707) Attached to: Google Releases Chrome 25 With Voice Recognition Support
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.

Comment: Re:We should not need a petition (Score 1) 317

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.

Comment: Re:trivial, 99% effective fix (Score 3, Informative) 207

by dririan (#42891235) Attached to: Do Not Track Ineffective and Dangerous, Says Researcher

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.

Comment: Re:Can't Go Backwards (Score 1) 736

by dririan (#42888345) Attached to: Ask Slashdot: Why Is It So Hard To Make An Accurate Progress Bar?
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.

"Summit meetings tend to be like panda matings. The expectations are always high, and the results usually disappointing." -- Robert Orben

Working...