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!</>
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!
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.
The parallels are astounding: Indefinite delays, arbitrary conflicting decisions, and reapproval of already-approved content required when making minor changes!
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.
(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.
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...
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)...
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!
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...
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.
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.
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.
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...
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...
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?
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.:)
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?
Are they using a hub for wired connections at a security conference? Seems like the most plausible explanation for a simple "hack" like this with the network "working correctly"...
It's a common misconception that switches prevent snooping. Switches are *not* security devices, they are an performance optimization. As such, they mostly "fail open".
If you flood the switch with many different MAC addresses, such that its internal ethernet routing table fills up, it will usually simply direct *all* traffic to your port, rather than potentially incorrectly dropping some traffic you should have received.
And then you can snoop to your heart's content, with nobody else the wiser.
You don't actually need SPF for that. Instead, you should do return-path-rewriting on your *own* outgoing mail, which will completely solve the bogus bounces problem for you, without requiring anyone else to change anything.
It's basically just like SRS (which you need to use if you use SPF) except using it on your own outgoing mail instead of forwarded mail. And by using it, SPF becomes utterly worthless.
The idea is that you use a unique MAIL FROM: for all legit mail you sent, and simply reject all bounce messages that isn't going to these addresses.
> Do I need to write up an original blurb and host it elsewhere and then use the article I myself have written as a source?
Yes, you do, and for at least one very good reason. Wikipedia has just about *no* way to figure out where a piece of information in an article came from. I mean, yes, you can go through the edit history one edit at a time, but that's extremely cumbersome, and quite difficult if the information has survived through many rewordings/moves/etc. So, if you add info to an article, and 5000 revisions later, I come along and wonder why it says that, unless that information is sourced, it's nearly impossible to trace it back. So, I quite simply have no basis to even judge whether the information is trustworthy or not.
If you write it up elsewhere, and then reference it from wikipedia, only then is it possible to determine the source of the information, and even attempt to make judgement about whether it's trustworthy.
Yes, and this was exactly my point. The default dropping of incoming packets on the edge of the network *is the problem* today. If we move to IPv6 and _still_ every organization/home's router drops incoming packets on the edge of the network, we're in exactly the same boat we are today with IPv4. Little has improved.
I want to be able to design and use network protocols that utilize incoming connections. That's nearly impossible today, and looks likely to be just as hard after the move to IPv6 as well. All the contortions people have to go through right now to make that work are a huge cost, and for the most part unreliable.
Apple naively implemented end-to-end connectivity, because E2E is what everyone says the internet is supposed to be like, and therefore what everyone should want. And with IPv6, NAT was no longer required, so there was no technical reason to not allow e2e. Where Apple screwed up is listening to the people that said that end-to-end connectivity is what people want. It turns out that's not the case, because then you can no longer connect insecure IP devices to your home network with abandon.
Maybe you can tell me what's the "right" implementation of end to end connectivity? What should the next guy after apple do? At this point, the only obvious solution to me is to implement NAT for ipv6, and have it on by default. The IPv6 NAT can avoid actually modifying addresses and ports, but that hardly removes any complexity as it still needs all the same connection-tracking code. (but, then, even exposing distinct IP addresses of internal machines to the external world might be considered a security/privacy risk these days, so maybe the mfgr should just stick to a full NAT to avoid trouble...)
Slashdot Mirror
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!</>
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!
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.
The parallels are astounding: Indefinite delays, arbitrary conflicting decisions, and reapproval of already-approved content required when making minor changes!
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.
(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.
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...
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)...
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.
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...
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.
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.
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...
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...
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?
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. :)
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?
Are they using a hub for wired connections at a security conference? Seems like the most plausible explanation for a simple "hack" like this with the network "working correctly"...
It's a common misconception that switches prevent snooping. Switches are *not* security devices, they are an performance optimization. As such, they mostly "fail open".
If you flood the switch with many different MAC addresses, such that its internal ethernet routing table fills up, it will usually simply direct *all* traffic to your port, rather than potentially incorrectly dropping some traffic you should have received.
And then you can snoop to your heart's content, with nobody else the wiser.
No, I use that machine for other stuff than watching DVDs, too, and rebooting it frequently out of linux would interrupt that.
My only DVD player is a linux box.
As soon as Blu-Ray works just as well on Linux as DVD does now, I'll upgrade the drive to a Blu-Ray drive. Until then, no thanks.
(Of course, this means that the DRM will need to be thoroughly hacked to pieces first... Oh well.)
It's basically just like SRS (which you need to use if you use SPF) except using it on your own outgoing mail instead of forwarded mail. And by using it, SPF becomes utterly worthless.
The idea is that you use a unique MAIL FROM: for all legit mail you sent, and simply reject all bounce messages that isn't going to these addresses.
See here and here: here for more details.
> Do I need to write up an original blurb and host it elsewhere and then use the article I myself have written as a source?
Yes, you do, and for at least one very good reason. Wikipedia has just about *no* way to figure out where a piece of information in an article came from. I mean, yes, you can go through the edit history one edit at a time, but that's extremely cumbersome, and quite difficult if the information has survived through many rewordings/moves/etc. So, if you add info to an article, and 5000 revisions later, I come along and wonder why it says that, unless that information is sourced, it's nearly impossible to trace it back. So, I quite simply have no basis to even judge whether the information is trustworthy or not.
If you write it up elsewhere, and then reference it from wikipedia, only then is it possible to determine the source of the information, and even attempt to make judgement about whether it's trustworthy.
Yes, and this was exactly my point. The default dropping of incoming packets on the edge of the network *is the problem* today. If we move to IPv6 and _still_ every organization/home's router drops incoming packets on the edge of the network, we're in exactly the same boat we are today with IPv4. Little has improved.
I want to be able to design and use network protocols that utilize incoming connections. That's nearly impossible today, and looks likely to be just as hard after the move to IPv6 as well. All the contortions people have to go through right now to make that work are a huge cost, and for the most part unreliable.
Apple naively implemented end-to-end connectivity, because E2E is what everyone says the internet is supposed to be like, and therefore what everyone should want. And with IPv6, NAT was no longer required, so there was no technical reason to not allow e2e. Where Apple screwed up is listening to the people that said that end-to-end connectivity is what people want. It turns out that's not the case, because then you can no longer connect insecure IP devices to your home network with abandon.
Maybe you can tell me what's the "right" implementation of end to end connectivity? What should the next guy after apple do? At this point, the only obvious solution to me is to implement NAT for ipv6, and have it on by default. The IPv6 NAT can avoid actually modifying addresses and ports, but that hardly removes any complexity as it still needs all the same connection-tracking code. (but, then, even exposing distinct IP addresses of internal machines to the external world might be considered a security/privacy risk these days, so maybe the mfgr should just stick to a full NAT to avoid trouble...)