I mean, we kill lots of delicious cows, sure -- but you'd think the people whose business it was to sell us the delicious cow meat would be counting them.
See my response above -- "Mac/PC" hybrid disks actually use two different filesystems. Macintosh CDs use the HFS/HFS+ filesystem. People took advantage of this to make dual-filesystem hybrid disks. (On the other hand, having two partitions with different filesystems on one disk was old hat by the time data CDs were around.)
The "Macintosh-format" CDs don't use ISO, they actually use HFS/HFS+. The dual-format disks actually contain an ISO and an HFS partition, but they're engineered so that they share data. You can have ISO-only files, HFS-only files, and shared files; the shared files are only stored once. The ISO partition is used to store data for windows; the HFS partition is used to store data for Mac OS.
The interesting thing about those disks isn't that they're formatted to have two different filesystems on them -- by the time the dual-format CDs were around, putting two partitions on a disk was no big shocker. The interesting part was that they were designed to have two partitions own the same data.
Compare with the disk mentioned in the article. It sounds like the data for the IBM and C64 are entirely separate. The interesting feature is making what is essentially a two-partition disk out of a disk that's designed to be single-partition.
Possibly, but the primary goal of the DMCA was to target companies or individuals who produce tools to assist consumers in copyright violations, not the copyright-violators themselves.
Generally, if you disagree with the EULA, the company will refund your money if you return the product. Now, Best Buy might not. But placing a legal agreement where it cannot be read before purchase and refusing a fair return if you reject that agreement is making you a prime target for a successful lawsuit.
I know for a fact that if you refuse the EULA, Microsoft will do a return of Windows.
No, see, if I was addressing the article/summary, I would've written,
"Didn't anyone ever teach you that just because your extrapolation model is precise to the day, your results aren't necessarily that precise or accurate?"
Of course, I generally dismiss future-prediction models that give numbers but don't include error margins or a word like "approximately". (And, as you would presumably agree, "approximately 823.2 days" doesn't count.)
In case you didn't read, I did mention that a successful attack requires neither access to the internal network nor BGP hijacking.
Considering BGP hijacking has also been successfully done (recently) and is an excellent way to get access to communications, I'd hardly call it specious. Yet secure protocols like DNSSEC and HTTPS provide security in the case where your route goes through hostile nodes.
Again, by hijacking the MX record for a domain -- an attack that doesn't require any particularly privileged access on the target's network -- mail to that domain can be sent instead to an arbitrary third party. Applying SSL to the SMTP connection does not in any way protect against this, because there's no guaranteed connection between the name of the domain you are e-mailing and the name of the server handling its mail other than the information provided in the MX record. Securing the DNS lookup is necessary.
Digital signals of a quality similar to analog television take up substantially less bandwidth. HD television signals, if I remember correctly, take up roughly the same bandwidth as an analog signal. They can't share space on the spectrum, so if you're transmitting both analog and HD, you take up twice as much of the spectrum per channel. In many areas, there's simply not enough broadcast spectrum to hold both analog and HD transmissions of each channel.
They actually only lay copyright claim to their particular collection of facts (that is, the grouping of station names into categories that they created). This, as it turns out, is quite copyrightable.
You (a) shouldn't base a security approach on having no malicious computers on your subnet (b) don't need access to the subnet to execute this attack and (c) don't even need access to the routing path (which you could obtain without being on the same subnet with BGP hacks, among others).
All the information the MX record contains is the address of a machine you can control. It doesn't have to be yours, as long as you control it.
Using MX forging to redirect mail traffic in exactly this manner has been used in the wild (against unnamed US government organizations, for that matter), so I'd say the chances of this happening are 100%.
It's perfectly valid for the MX record to specify that the mail handler for foo.com is mail.foo.com, or even mail.bar.com. Valid and common. To send the mail, then, you're connecting to mail.bar.com. Say this SSL connection is authenticated such that you're sure you're talking to mail.bar.com.
So, the attacker just changes the MX record to mail.evil.com. (Through, for example, DNS cache poisoning.) So, now you set up an SSL connection to mail.evil.com, and you're sure you're talking to mail.evil.com.
The SSL connection is completely valid, yet your mail has been hijacked.
It's unwise to run a DNS server on the same machine as an HTTP/HTTPS server anyway, so DNSSEC will put no additional load on those servers. (They will put additional load on DNS servers, and that limits adoption.)
The US government doesn't administer any of this, and they're not by any means the first mover on this. They just happen to control quite a few websites and make press releases.
As far as sending e-mail via SSL, are you familiar with what MX records do? It should be clear that SSL provides absolutely no protection for MX record poisoning.
DNSSEC protects things that aren't secured by https, like MX records. I suspect it's also easier to implement than forcing everyone to move to HTTPS and other encrypted protocols.
The parts of the Web where you don't care about security are built around HTTP, but there's still value in preventing them from being hijacked.
Except that automatic-update systems, such as what you would use to patch the browser against the user's will, only accept signed packages. You can hijack the domain name and send them all the malicious data you want, but they won't install it for you, because the browser doesn't implicitly trust the domain name.
DNS does not *have* to be secure. It just makes it much more convenient.
I'm not actually advocating anything, I'm explaining a logical fallacy. The fallacy is that compromise is necessarily better.
What you're saying is, incidentally, another fallacy -- you're claiming that since I say "compromise is not necessarily better than a non-compromise" that I also mean "non-compromise is necessarily better than a compromise". They are distinct statements.
Having worked on one of these, two failures this early on is par for the course. There's a lot of work to be done even after the thing is build and initial testing is done before it's stable and working (and even then, most particular accelerators are only somewhat "stable" with very heavy maintainance).
Actually, it's not a straw-man argument, it's an illustration of a fallacy. A well-known fallacy, in fact -- the fallacy of compromise. While some sort of compromise is very often useful or effective, it does not follow logically that a compromise between two arbitrary suggestions is necessarily superior. In many cases, a "compromise solution" makes no sense; in others, it's clearly not the "fair" choice.
There is no innate "middle ground". If you define it as a "reasonable compromise", you're imposing a particular person's arbitrary sense of "reasonable" anyway.
To be fair, I think he's saying that their being Republican doesn't really count, not that their charity doesn't count. If they're duped into voting Republican, they don't really "count" as Republican.
Slashdot Mirror
How do we kill countless billions?
I mean, we kill lots of delicious cows, sure -- but you'd think the people whose business it was to sell us the delicious cow meat would be counting them.
They don't respirate as much CO2 as they take up. The carbon from the difference is used to build more tree.
See my response above -- "Mac/PC" hybrid disks actually use two different filesystems. Macintosh CDs use the HFS/HFS+ filesystem. People took advantage of this to make dual-filesystem hybrid disks. (On the other hand, having two partitions with different filesystems on one disk was old hat by the time data CDs were around.)
The "Macintosh-format" CDs don't use ISO, they actually use HFS/HFS+. The dual-format disks actually contain an ISO and an HFS partition, but they're engineered so that they share data. You can have ISO-only files, HFS-only files, and shared files; the shared files are only stored once. The ISO partition is used to store data for windows; the HFS partition is used to store data for Mac OS.
The interesting thing about those disks isn't that they're formatted to have two different filesystems on them -- by the time the dual-format CDs were around, putting two partitions on a disk was no big shocker. The interesting part was that they were designed to have two partitions own the same data.
Compare with the disk mentioned in the article. It sounds like the data for the IBM and C64 are entirely separate. The interesting feature is making what is essentially a two-partition disk out of a disk that's designed to be single-partition.
Possibly, but the primary goal of the DMCA was to target companies or individuals who produce tools to assist consumers in copyright violations, not the copyright-violators themselves.
It is (sometimes) entrapment if the police do it. It's not entrapment if people who are not the police nor working on behalf of the police do it.
You can't "go in" to the game publisher, only to a retail store. As I mentioned, the retail store might not offer a refund, but the publisher will.
You certainly can -- you just can't use the forums that they're providing (and paying for) to discuss it.
Generally, if you disagree with the EULA, the company will refund your money if you return the product. Now, Best Buy might not. But placing a legal agreement where it cannot be read before purchase and refusing a fair return if you reject that agreement is making you a prime target for a successful lawsuit.
I know for a fact that if you refuse the EULA, Microsoft will do a return of Windows.
No, see, if I was addressing the article/summary, I would've written,
"Didn't anyone ever teach you that just because your extrapolation model is precise to the day, your results aren't necessarily that precise or accurate?"
Of course, I generally dismiss future-prediction models that give numbers but don't include error margins or a word like "approximately". (And, as you would presumably agree, "approximately 823.2 days" doesn't count.)
In case you didn't read, I did mention that a successful attack requires neither access to the internal network nor BGP hijacking.
Considering BGP hijacking has also been successfully done (recently) and is an excellent way to get access to communications, I'd hardly call it specious. Yet secure protocols like DNSSEC and HTTPS provide security in the case where your route goes through hostile nodes.
Again, by hijacking the MX record for a domain -- an attack that doesn't require any particularly privileged access on the target's network -- mail to that domain can be sent instead to an arbitrary third party. Applying SSL to the SMTP connection does not in any way protect against this, because there's no guaranteed connection between the name of the domain you are e-mailing and the name of the server handling its mail other than the information provided in the MX record. Securing the DNS lookup is necessary.
Digital signals of a quality similar to analog television take up substantially less bandwidth. HD television signals, if I remember correctly, take up roughly the same bandwidth as an analog signal. They can't share space on the spectrum, so if you're transmitting both analog and HD, you take up twice as much of the spectrum per channel. In many areas, there's simply not enough broadcast spectrum to hold both analog and HD transmissions of each channel.
They actually only lay copyright claim to their particular collection of facts (that is, the grouping of station names into categories that they created). This, as it turns out, is quite copyrightable.
You (a) shouldn't base a security approach on having no malicious computers on your subnet (b) don't need access to the subnet to execute this attack and (c) don't even need access to the routing path (which you could obtain without being on the same subnet with BGP hacks, among others).
All the information the MX record contains is the address of a machine you can control. It doesn't have to be yours, as long as you control it.
Using MX forging to redirect mail traffic in exactly this manner has been used in the wild (against unnamed US government organizations, for that matter), so I'd say the chances of this happening are 100%.
On a separate note, didn't anyone ever teach you that just because your calculator displays all those digits, it doesn't mean they're significant?
It's perfectly valid for the MX record to specify that the mail handler for foo.com is mail.foo.com, or even mail.bar.com. Valid and common. To send the mail, then, you're connecting to mail.bar.com. Say this SSL connection is authenticated such that you're sure you're talking to mail.bar.com.
So, the attacker just changes the MX record to mail.evil.com. (Through, for example, DNS cache poisoning.) So, now you set up an SSL connection to mail.evil.com, and you're sure you're talking to mail.evil.com.
The SSL connection is completely valid, yet your mail has been hijacked.
How do you reproduce the effect of Vista's UAC dialogs from a browser?
Or is there, in fact, a way of displaying windows that only the OS can use?
It's unwise to run a DNS server on the same machine as an HTTP/HTTPS server anyway, so DNSSEC will put no additional load on those servers. (They will put additional load on DNS servers, and that limits adoption.)
The US government doesn't administer any of this, and they're not by any means the first mover on this. They just happen to control quite a few websites and make press releases.
As far as sending e-mail via SSL, are you familiar with what MX records do? It should be clear that SSL provides absolutely no protection for MX record poisoning.
DNSSEC protects things that aren't secured by https, like MX records. I suspect it's also easier to implement than forcing everyone to move to HTTPS and other encrypted protocols.
The parts of the Web where you don't care about security are built around HTTP, but there's still value in preventing them from being hijacked.
Except that automatic-update systems, such as what you would use to patch the browser against the user's will, only accept signed packages. You can hijack the domain name and send them all the malicious data you want, but they won't install it for you, because the browser doesn't implicitly trust the domain name.
DNS does not *have* to be secure. It just makes it much more convenient.
This is the well-known "login page is not over https" problem.
I'm not actually advocating anything, I'm explaining a logical fallacy. The fallacy is that compromise is necessarily better.
What you're saying is, incidentally, another fallacy -- you're claiming that since I say "compromise is not necessarily better than a non-compromise" that I also mean "non-compromise is necessarily better than a compromise". They are distinct statements.
Having worked on one of these, two failures this early on is par for the course. There's a lot of work to be done even after the thing is build and initial testing is done before it's stable and working (and even then, most particular accelerators are only somewhat "stable" with very heavy maintainance).
Actually, it's not a straw-man argument, it's an illustration of a fallacy. A well-known fallacy, in fact -- the fallacy of compromise. While some sort of compromise is very often useful or effective, it does not follow logically that a compromise between two arbitrary suggestions is necessarily superior. In many cases, a "compromise solution" makes no sense; in others, it's clearly not the "fair" choice.
There is no innate "middle ground". If you define it as a "reasonable compromise", you're imposing a particular person's arbitrary sense of "reasonable" anyway.
Anyway, yes. Fallacy of compromise.
To be fair, I think he's saying that their being Republican doesn't really count, not that their charity doesn't count. If they're duped into voting Republican, they don't really "count" as Republican.