Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!


Forgot your password?

Comment: Re:Respecting Privacy??? (Score 2) 515

by Dagger2 (#49751339) Attached to: Ads Based On Browsing History Are Coming To All Firefox Users

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.

Comment: Re:Root cause = speed over security (Score 1) 71

by Dagger2 (#49743699) Attached to: 'Logjam' Vulnerability Threatens Encrypted Connections

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.

Comment: Re:Root cause = speed over security (Score 1) 71

by Dagger2 (#49739513) Attached to: 'Logjam' Vulnerability Threatens Encrypted Connections

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.

Comment: Re:Root cause = speed over security (Score 1) 71

by Dagger2 (#49738721) Attached to: 'Logjam' Vulnerability Threatens Encrypted Connections

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.

Comment: Re:NOT a kernel bug (Score 4, Insightful) 70

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.

Comment: Re:Get cracking (Score 1) 371

by Dagger2 (#49694015) Attached to: Firefox 38 Arrives With DRM Required To Watch Netflix

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.

Comment: Re:Typo: Digital Rights Management (Score 1) 371

by Dagger2 (#49681357) Attached to: Firefox 38 Arrives With DRM Required To Watch Netflix

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.

Comment: Re:How does it work ? (Score 1) 371

by Dagger2 (#49676213) Attached to: Firefox 38 Arrives With DRM Required To Watch Netflix

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.)

Comment: Re:that's fine (Score 1) 408

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.

Comment: Re:Deny them the pleasure of security by obscurity (Score 1) 87

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.)

Comment: Re:I've switched back to Firefox (Score 1) 240

by Dagger2 (#49611259) Attached to: Chrome Passes 25% Market Share, IE and Firefox Slip

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?

Comment: Re: Waiting for the killer app ... (Score 1) 390

by Dagger2 (#49531913) Attached to: Why the Journey To IPv6 Is Still the Road Less Traveled

It's worst sin is neglecting the obvious need for a transition mechanism

If its worse sin is not doing the impossible, then it's doing pretty good: you can't talk between v4 and v6 hosts because of the pigeon-hole principle. There's just not enough space in the v4 dest header to fit a 128-bit address.

If you have a brilliant idea for getting around that, please do share.

Never appeal to a man's "better nature." He may not have one. Invoking his self-interest gives you more leverage. -- Lazarus Long