Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Comments

top

As HTML5 Gets 2014 Final Date, Flash Floods Mobile

foom Re:It'll be obsolete by then... (221 comments)

Nope. You've never been able to write pages against the HTML4 standard, and you certainly can't now. No browser "properly" implements HTML4, and to the best of my knowledge, never has, and never will. Just you try writing a document that looks like the below, and see if you can find a browser that renders it properly. Of course, if you do find such a browser, it probably can't render actual webpages properly...

This *is* valid HTML4 syntax:
<html<head<title/Foo/</><body<p<a href="foo"/link text/, hooray!</>

more than 3 years ago
top

How Facebook Responded To Tunisian Hacks

foom Good thing Tunesian doesn't have a Root CA! (227 comments)

At least, I guess they must not...unlike most every other government in the world... If they did, they could still pretend to be Facebook, even when facebook uses https!

more than 3 years ago
top

Best PC DVR Software, For Any Platform?

foom Cable box + firewire output (536 comments)

I use:
4) Cablebox with Firewire output + firewire port on PC.

It works really quite well.

Cable companies are required to offer cable boxes with firewire (usually the HD ones all come with it). However, depending on your cableco, the firewire output may or may not be encrypted. You can only connect it to your PC if it is not encrypted.

Note that the presence or absence of encryption on the Firewire output is *totally independent* from whether the data is encrypted on the cable line. The cable box decrypts the signal with its cable card, and possibly re-encrypts it for the firewire output, depending on the cableco's settings.

For me (with RCN Boston), I've found that all the extended-basic channels are sent unencrypted over the firewire output, except, paradoxially, *sometimes* the HD OTA channels. I dunno what's up with that, but my solution was to just not go through the cable box for those channels. I don't subscribe to premiums, so I don't know whether they are encrypted or not. Your mileage may of course vary, depending on provider and possibly even region.

more than 4 years ago
top

Blizzard Awaits China's Approval For WoW Relaunch

foom Just like developing for an iPhone (75 comments)

The parallels are astounding: Indefinite delays, arbitrary conflicting decisions, and reapproval of already-approved content required when making minor changes!

more than 4 years ago
top

How Apple's App Review Is Sabotaging the iPhone

foom Re:Have you tried the alternative store? (509 comments)

I'm sure part of the problem with the "unofficial" app store is that it's quite likely that one of these days, Apple will get serious, and make a bootloader without glaring security holes in it. (I mean come ON, Apple, the bootloader isn't that big!...)

When that happens, it may be impossible to "permanently" unlock an iPhone without hardware mods, which will seriously limit the Jailbreak community -- probably into irrelevance.

That's a rather big risk for anyone to take on in their development...

Heck, I'm not even bothering to learn to write for the iPhone as a *hobby*, because it'd be a waste of my time. Pretty much everything I want to write isn't allowed by Apple's rules, and while my phone is Jailbroken, Apple is trying (so far, completely incompetently...) to prevent me from being able to buy a new jailbreakable iPhone ever again. So it seems to me that the iPhone is basically a dead-end platform.

more than 5 years ago
top

Linux Distributions' Tracking of Upstream Projects Examined

foom Re:Tracking Debian Stable instead of Testing (132 comments)

(they still consider critical bugs of almost unknow and barely used packages as release-critical bugs that can stop the release of widely used and know packages with no critical bugs?).

Not true. Unfixed release-critical bugs in unknown and barely used packages result in the package being removed from the release, not the release being delayed.

more than 5 years ago
top

Kaminsky On DNS Bugs a Year Later and DNSSEC

foom Re:Optimistic guy (127 comments)

See here, about crypto CPU usage.

I'll also note that DNSCurve lookups use less network bandwidth than DNSSEC. DNSSEC drastically increases network bandwidth requirements with all those individual record signatures that need to be returned...

more than 5 years ago
top

Kaminsky On DNS Bugs a Year Later and DNSSEC

foom Re:Optimistic guy (127 comments)

Your statistic would be valid for no cache vs a cache.

But that's not the actual question at hand.

The question is:
What's the cache hit rate for a recursive cache serving a group of machines, vs. the cache hit rate for a recursive cache serving just a single machine.

I'm going to place my bet on nowhere near a 10x increase in traffic from having an unshared local cache.

But I haven't done the test. If anyone wants to (or knows of literature that's already explored this)...

more than 5 years ago
top

Kaminsky On DNS Bugs a Year Later and DNSSEC

foom Re:Optimistic guy (127 comments)

A "validating stub resolver" will actually need to be (basically) a recursive resolver itself (it needs to do multiple queries to verify each signature in the delegation chain from the root down to the record it's actually interested in). And thus, if you want it to perform well, it'll need a local cache.

Now it's basically a caching recursive resolver.

So, is your claim that because the caching recursive resolver which you run on localhost can use a second-level remote cache instead of talking to the authoritative servers directly, DNSSEC is superior?

I suppose you can consider that an advantage...but heck, I sure can't see the point of it. If you're going to require a caching recursive resolver on localhost, just have it talk to the authoritative servers and be done with it... It certainly doesn't seem worth all the pain of DNSSEC to allow for an untrusted intermediate cache to be used!

I just don't see it.

more than 5 years ago
top

Kaminsky On DNS Bugs a Year Later and DNSSEC

foom Re:Questions from a DNS implementor (127 comments)

36 RFCs over the course of 12 years for a not-even-deployed-yet standard really is quite excessive. I don't blame him for thinking it's going to be a monster...

more than 5 years ago
top

Kaminsky On DNS Bugs a Year Later and DNSSEC

foom Re:Optimistic guy (127 comments)

Huh?

DNSSec doesn't let you set your laptop's DNS to Starbucks' NS and be safe, because you can't do DNSSec from a stub resolver and have to use TSIG (which protects the client->server data transfer, not the zone data).

DNSCurve doesn't let you set your laptop's DNS to Starbucks' NS and be safe, because DNSCurve protects the client->server data transfer (of each step of the process) not the zone data.

You're screwed either way.

Or, you can decide to either use a different resolver somewhere on the internet you *do* trust (and configure its key so you can be sure you're actually talking to it!), or run a caching recursive resolver on your laptop. Either of those will give you properly secured DNS with both DNSCurve and DNSSEC.

more than 5 years ago
top

Kaminsky On DNS Bugs a Year Later and DNSSEC

foom Re:Optimistic guy (127 comments)

I'm just going to repost my last comment on this subject. I don't think things have changed since then, but if they have I'd certainly be interested to know. :)

You might be interested in this thread:
https://lists.dns-oarc.net/pipermail/dns-operations/2008-May/002736.html
where Paul Vixie recommends that nobody should ever deploy a stub resolver that supports DNSSEC, but instead use TSIG to talk to the recursive resolver. Which really makes DNSSEC's security characteristics look very much like DNSCurve. The only difference being that DNSSEC is hugely more complex to use and implement.

more than 5 years ago
top

DNSSEC Advances in gTLDs; Bernstein Intros DNSCurve

foom Re:DNSCURVE doesn't work... (179 comments)

You might be interested in this thread:
https://lists.dns-oarc.net/pipermail/dns-operations/2008-May/002736.html
where Paul Vixie recommends that nobody should ever deploy a stub resolver that supports DNSSEC, but instead use TSIG to talk to the recursive resolver. Which really makes DNSSEC's security characteristics look very much like DNSCurve. The only difference being that DNSSEC is hugely more complex to use and implement.

more than 5 years ago
top

DNSSEC Advances in gTLDs; Bernstein Intros DNSCurve

foom Re:Easy (179 comments)

But if I'm running BIND on my local machine, it would be just as secure under the DNSCurve proposal as with DNSSEC.

If my organization has a central, recursive, trusted DNS server, then I'm just as secure under DNSCurve as with DNSSEC.

The only place DNSCurve loses if if I have a stub resolver pointing to an *untrusted* recursive resolver on another host, instead of running my own recursive caching resolver. So maybe I just shouldn't do that...

more than 5 years ago
top

DNSSEC Advances in gTLDs; Bernstein Intros DNSCurve

foom Re:Slow down there (179 comments)

But DNSSEC uses all pre-computed signatures for the zone data. So if you can break the RSA key, you can create fake signatures ahead of time and serve bogus DNS data. Your botnet has got all the time in the world to try to break that key...

more than 5 years ago
top

DNSSEC Advances in gTLDs; Bernstein Intros DNSCurve

foom Re:DNSCURVE doesn't work... (179 comments)

DNSSEC addresses this adversary, because it is a data integrity protocol. DNSCurve does not: it explicitly trusts the recursive resolver and offers NO security guarentees against this very serious adversary.

Okay, so where can I find a patch to make glibc's stub resolver verify DNSSEC signatures, so that I can be pretected from my recursive resolvers? DNSSEC has been around for nearly a decade: surely someone's implemented this by now?

more than 5 years ago
top

Proprietary Blobs and the Pursuit of a Free Kernel

foom Re:Who cares *where* the non-free firmware is? (405 comments)

If the firmware comes with a liberal license that says that anyone can distribute it, then no, you probably won't care, but if it doesn't, and you start handing around copies of it, then you'll care when their lawyers come knocking.

Good point. I completely agree with that: distros should make sure that all the firmware they're distributing at least comes with a "anyone may distribute this" license.

I don't suspect having such a requirement would even cause much of a flamewar. :)

more than 5 years ago
top

Proprietary Blobs and the Pursuit of a Free Kernel

foom Who cares *where* the non-free firmware is? (405 comments)

I've always wondered why I, as a Freedom-loving-user, should prefer a device which has its non-free firmware embedded in a ROM or Flash chip rather than as a file on a CD or FTP server with my linux distribution.

Because, let's be clear: *where* the non-free firmware is being stored is usually the choice you have.

100% Free hardware would clearly be better, but there's precious little of that around...

So: why is it evil to have the firmware distributed on CD? Why should I care even one itsy-little-bit where it's stored?

more than 5 years ago

Submissions

foom hasn't submitted any stories.

Journals

foom has no journal entries.

Slashdot Login

Need an Account?

Forgot your password?