The thing that Apple doesn't seem to get is that trademarks are designed to prevent confusion among products in the same field. If the iPood played music or was electronic in any way, Apple might have a leg to stand on. But nobody is rationally going to think that a trowel can in any way be confused with a portable music player. Not only are the products in question completely different, but so are the respective companies' fields of endeavor. Confusion is not possible here.
While I agree that ZIP confirmation is not particularly secure, there's actually a better reason that Canada doesn't use it: Canadian postal codes are alphanumeric, and installing a QWERTY keyboard at every point of sale just isn't going to cut it.
The actual RC4 cipher has bad key scheduling issues. Because the initialization step doesn't mix the key bytes well enough into the S-box, the first bytes of the keystream (which is XOR'd with the plaintext to produce the ciphertext) leak lots of data about the key. This is a major problem with WEP (there are, of course, others). Cryptographers recommend discarding the beginning of the keystream because of this weakness. Nevertheless, RC4 is popular because it is byte-oriented and fast. Even 8-bit machines can implement it trivially.
Ultimately, it comes down to the key scheduling. If Skype has a better key-scheduling algorithm, it may actually improve security over standard RC4.
This doesn't work when you have a system-wide installation. For example, I use Debian and have the DOM Inspector add-on installed through the package manager. The only way to remove the code in question is as root—and hopefully you're not using Firefox as root.
The difference here is that they actually intercepted data by mistake. If you use Kismet (probably the best wireless sniffing tool for Linux), you can set it to not save data packets, only beacon packets (which really have all the data that Google needs), but by default, it saves everything, including any data packets it sees (encrypted or unencrypted).
It depends on what you're doing what packets you want. If you're trying to break WEP, you only care about encrypted data packets; if you're just doing innocent wardriving, you only want the beacons.
The problem is not with porn. Obviously, there are some people that do not want to see porn. There are also children, who, for the sake of argument, should not see porn.
The problem is defining porn. Is a line drawing of two people having sex porn? Then Wikipedia has porn. What about text? Does porn have to be an image? How do we determine the difference between an erotic story and, for example, a medical description of sex?
There are numerous sites that describe medical aspects of sexuality. Wikipedia is one. There are others that teach people about how to perform a breast (or testicular) self-examination. Arguably, these sites should be seen by teenagers because they have information that is relevant to them.
The issue is that people who are easily offended want a technical solution to a social problem. This is impossible to achieve. The way we can come closest without widespread damage to the Internet is to allow the easily offended to have their own padded room of sorts.
The problem here is that creating a.xxx domain is enumerating badness. Pornography is something that people want to contain and restrict. People working in the security field have known for a long time that enumerating badness is ineffective: someone can always find a way around it. It is trivial to come up with several ways around a mandate that porn be limited to.xxx.
The secure solution is to enumerate goodness; that is, allow only certain specified things and block everything else. If people want to browse an Internet without porn, they should create a top-level domain that is "family-friendly." Basically, each application for a domain would be carefully vetted under some set of criteria and only unobjectionable content would be allowed. This, of course, would have a very small amount of content, but it would be fine for those with delicate sensibilities.
The way that is being proposed (.xxx) is trivially circumventable.
It looks like this article was published in a journal of some sort. It's my understanding that many math and CS journals prefer TeX. There's no reason to redo an article just to post it online.
The problem with having one file to copy is that it defeats one of the most important benefits of Linux: shared libraries. Unlike Windows and Mac OS X, it's very common to have one copy of a library that's shared by all processes. If every one of the GTK-based programs on my system had a copy of GTK, Glib, ATK, Pango, and all the other libraries, the bloat would be huge. It would also be really bad for distribution mirrors, especially for a project like Debian, which is a non-profit and cannot pay for its own hosting.
Actually, the output of a program can be considered a derivative work if the program copies part of its code into the output. For example, bison does so. A fairly long time ago, the FSF added an exception to the GPL, stating that the output of bison was not necessarily GPLd, even if it was in fact a derivative work under copyright law.
Well, you have the same problem with WPA2-Personal, except in that case there's no need to guess a username, only a password. You could say the same for pretty much anything that requires a username and password.
The benefit of using RADIUS is that you can have separate username/password pairs, and thus you can grant or restrict access individually without having to change the password each time.
Not that I agree with the ruling, but if you look at the case in terms of US fair use (which I admit is not applicable in Europe), there's a significant difference between quoting eleven words in a newspaper article, which is fairly short, and quoting eleven words in a book or short story. Proportionally, the amount used is significantly greater.
Nevertheless, I agree that this is a reasonable, non-infringing use. It doesn't harm the commercial aspects of the newspapers, since it's not like anyone is going to get their news from these eleven-word snippets.
Basically, IBM has created a set of cryptographic algorithms that allow fully homomorphic encryption. If you don't want your data to be analyzed, all you have to do is use an algorithm that doesn't support it. You'd want to do that anyway, since you'd want to use algorithms that are already considered strong, such as RSA and AES. Although RSA is homomorphic in theory, in practice it is not, since padding is used to prevent other weaknesses.
It's actually possible to use compression as part of TLS; the data will be compressed before they are encrypted (since, as you point out, it would be pointless to do it afterward). I don't know how many servers support it, but it's possible to do.
Using dynamic linking on Linux/i386 has an overhead: the processor has 8 general-purpose registers, and one of them is used for the PIC register. That's going to result in a pretty significant performance hit.
Windows doesn't use a PIC register; shared libraries are loaded into a certain spot in memory by default, and as long as they don't overlap, there's no fixup needed.
So since the test was done on an i386 system, dynamic linking may have affected the results. If the test were done on an amd64 system (running 64-bit code), the results might have been different.
You don't have to use Eclipse. I used vim and ant, and they work just fine. If you want to use Eclipse, Google will make it easy for you. But typing "ant" isn't exactly rocket science, either.
You have to compromise the OpenID server in order to gain access, since all that the consumer gets is a URL. You enter your password (if that's what you're using) only on your provider's website. If you don't trust your provider, you're fucked anyway.
If you're smart, you won't use a password. I run my own OpenID server and it uses my Kerberos credentials (via SPNEGO) to authenticate. No password ever leaves my machine. Someone wanting to compromise my OpenID must gain access to either the KDC or the CGI script.
In general, it's stupid to enter any sort of authentication information on a machine you don't trust. If I need to log in, I use my laptop, not a public terminal.
It's not seeding too often that's the problem, it's seeding with predictable data and expecting that data to be random. The time is very predictable, and contains very little entropy (randomness).
If you seed very often with data containing a lot of entropy (for example, radioactive decay), then there's no problem. It's also not a problem to add the time in the mix if you mark it as having almost no entropy.
2. Free speech is important, nobody is debating that. But there have to be limits on free speech when they can demonstrably justified. I cannot say ANYTHING I want about Jews/Muslims/Blacks/Gays in ANY forum at ANY time, especially when I target one group and I could impact THEIR right to live a happy and free life. You are correct, inasmuch as there are fora that would not be appropriate. For example, many workplaces require a modicum of decorum in speech and behavior. But as for public fora, I am entitled to say anything I want about any group at any time (as long as I am not disturbing the peace). I guess that is the difference between the United States and Canada.
The idea behind freedom of speech is that wrong ideas will readily be held up to ridicule and that the dialog that people engage in will pick the best ideas and discard the rest. Apparently there are people that believe Steyn's premise, as offensive as its delivery is. Silencing Steyn will not change people's minds. A reasonable public discourse might.
But Vista can support it. It just doesn't by default. Vista doesn't need it and shouldn't use it. Furthermore, given that it is an old feature that exists solely to work around broken network stacks, it is completely reasonable to assume that any modern OS supports a network stack that is sufficiently functional so as not to need it. (The alternative, but equivalent, assumption is that any OS still needing that feature is so old as to be a security risk, and therefore, shouldn't be on the Internet.)
That's the beauty of a "SHOULD" statement: it's a good idea, but not a requirement. There are numerous reasons why someone might not implement the requirements of such a clause: it's not needed, it can't be tested, or it violates a design concern such as security. When the DHCP server in question was written, Vista probably wasn't around, and therefore it wasn't needed. A basic review of computer security will demonstrate that unused or little-used code is especially prone to security bugs because nobody looks at or fixes it.
I also disagree that Microsoft gained a technical benefit from enabling it: why write brittle code when it's just as easy to write more robust code?
The Texas Legislature just recessed until January 2009; by the state constitution, the legislature can only meet for 140 days every two years, unless called into special session by the governor. Since there was no enabling legislation in Texas, Real ID won't be implemented here; it would violate parts of the Government Code permitting people to view and correct errors on information about them, among other laws.
Slashdot Mirror
The thing that Apple doesn't seem to get is that trademarks are designed to prevent confusion among products in the same field. If the iPood played music or was electronic in any way, Apple might have a leg to stand on. But nobody is rationally going to think that a trowel can in any way be confused with a portable music player. Not only are the products in question completely different, but so are the respective companies' fields of endeavor. Confusion is not possible here.
While I agree that ZIP confirmation is not particularly secure, there's actually a better reason that Canada doesn't use it: Canadian postal codes are alphanumeric, and installing a QWERTY keyboard at every point of sale just isn't going to cut it.
The actual RC4 cipher has bad key scheduling issues. Because the initialization step doesn't mix the key bytes well enough into the S-box, the first bytes of the keystream (which is XOR'd with the plaintext to produce the ciphertext) leak lots of data about the key. This is a major problem with WEP (there are, of course, others). Cryptographers recommend discarding the beginning of the keystream because of this weakness. Nevertheless, RC4 is popular because it is byte-oriented and fast. Even 8-bit machines can implement it trivially.
Ultimately, it comes down to the key scheduling. If Skype has a better key-scheduling algorithm, it may actually improve security over standard RC4.
This doesn't work when you have a system-wide installation. For example, I use Debian and have the DOM Inspector add-on installed through the package manager. The only way to remove the code in question is as root—and hopefully you're not using Firefox as root.
The difference here is that they actually intercepted data by mistake. If you use Kismet (probably the best wireless sniffing tool for Linux), you can set it to not save data packets, only beacon packets (which really have all the data that Google needs), but by default, it saves everything, including any data packets it sees (encrypted or unencrypted).
It depends on what you're doing what packets you want. If you're trying to break WEP, you only care about encrypted data packets; if you're just doing innocent wardriving, you only want the beacons.
The problem is not with porn. Obviously, there are some people that do not want to see porn. There are also children, who, for the sake of argument, should not see porn.
The problem is defining porn. Is a line drawing of two people having sex porn? Then Wikipedia has porn. What about text? Does porn have to be an image? How do we determine the difference between an erotic story and, for example, a medical description of sex?
There are numerous sites that describe medical aspects of sexuality. Wikipedia is one. There are others that teach people about how to perform a breast (or testicular) self-examination. Arguably, these sites should be seen by teenagers because they have information that is relevant to them.
The issue is that people who are easily offended want a technical solution to a social problem. This is impossible to achieve. The way we can come closest without widespread damage to the Internet is to allow the easily offended to have their own padded room of sorts.
The problem here is that creating a .xxx domain is enumerating badness. Pornography is something that people want to contain and restrict. People working in the security field have known for a long time that enumerating badness is ineffective: someone can always find a way around it. It is trivial to come up with several ways around a mandate that porn be limited to .xxx.
The secure solution is to enumerate goodness; that is, allow only certain specified things and block everything else. If people want to browse an Internet without porn, they should create a top-level domain that is "family-friendly." Basically, each application for a domain would be carefully vetted under some set of criteria and only unobjectionable content would be allowed. This, of course, would have a very small amount of content, but it would be fine for those with delicate sensibilities.
The way that is being proposed (.xxx) is trivially circumventable.
It looks like this article was published in a journal of some sort. It's my understanding that many math and CS journals prefer TeX. There's no reason to redo an article just to post it online.
It's a country on the northeastern edge of Africa, bordering the Red Sea. It gained independence from Ethiopia in the 1990s.
The problem with having one file to copy is that it defeats one of the most important benefits of Linux: shared libraries. Unlike Windows and Mac OS X, it's very common to have one copy of a library that's shared by all processes. If every one of the GTK-based programs on my system had a copy of GTK, Glib, ATK, Pango, and all the other libraries, the bloat would be huge. It would also be really bad for distribution mirrors, especially for a project like Debian, which is a non-profit and cannot pay for its own hosting.
Actually, the output of a program can be considered a derivative work if the program copies part of its code into the output. For example, bison does so. A fairly long time ago, the FSF added an exception to the GPL, stating that the output of bison was not necessarily GPLd, even if it was in fact a derivative work under copyright law.
Well, you have the same problem with WPA2-Personal, except in that case there's no need to guess a username, only a password. You could say the same for pretty much anything that requires a username and password.
The benefit of using RADIUS is that you can have separate username/password pairs, and thus you can grant or restrict access individually without having to change the password each time.
Not that I agree with the ruling, but if you look at the case in terms of US fair use (which I admit is not applicable in Europe), there's a significant difference between quoting eleven words in a newspaper article, which is fairly short, and quoting eleven words in a book or short story. Proportionally, the amount used is significantly greater.
Nevertheless, I agree that this is a reasonable, non-infringing use. It doesn't harm the commercial aspects of the newspapers, since it's not like anyone is going to get their news from these eleven-word snippets.
This doesn't work on all cameras. My Olympus Stylus 810 is from 2006, and it doesn't have that within the information. And yes, it does support EXIF.
Basically, IBM has created a set of cryptographic algorithms that allow fully homomorphic encryption. If you don't want your data to be analyzed, all you have to do is use an algorithm that doesn't support it. You'd want to do that anyway, since you'd want to use algorithms that are already considered strong, such as RSA and AES. Although RSA is homomorphic in theory, in practice it is not, since padding is used to prevent other weaknesses.
It's actually possible to use compression as part of TLS; the data will be compressed before they are encrypted (since, as you point out, it would be pointless to do it afterward). I don't know how many servers support it, but it's possible to do.
Using dynamic linking on Linux/i386 has an overhead: the processor has 8 general-purpose registers, and one of them is used for the PIC register. That's going to result in a pretty significant performance hit.
Windows doesn't use a PIC register; shared libraries are loaded into a certain spot in memory by default, and as long as they don't overlap, there's no fixup needed.
So since the test was done on an i386 system, dynamic linking may have affected the results. If the test were done on an amd64 system (running 64-bit code), the results might have been different.
You don't have to use Eclipse. I used vim and ant, and they work just fine. If you want to use Eclipse, Google will make it easy for you. But typing "ant" isn't exactly rocket science, either.
You have to compromise the OpenID server in order to gain access, since all that the consumer gets is a URL. You enter your password (if that's what you're using) only on your provider's website. If you don't trust your provider, you're fucked anyway.
If you're smart, you won't use a password. I run my own OpenID server and it uses my Kerberos credentials (via SPNEGO) to authenticate. No password ever leaves my machine. Someone wanting to compromise my OpenID must gain access to either the KDC or the CGI script.
In general, it's stupid to enter any sort of authentication information on a machine you don't trust. If I need to log in, I use my laptop, not a public terminal.
It's not seeding too often that's the problem, it's seeding with predictable data and expecting that data to be random. The time is very predictable, and contains very little entropy (randomness).
If you seed very often with data containing a lot of entropy (for example, radioactive decay), then there's no problem. It's also not a problem to add the time in the mix if you mark it as having almost no entropy.
The idea behind freedom of speech is that wrong ideas will readily be held up to ridicule and that the dialog that people engage in will pick the best ideas and discard the rest. Apparently there are people that believe Steyn's premise, as offensive as its delivery is. Silencing Steyn will not change people's minds. A reasonable public discourse might.
Flickr uses the 2.0 license, so it doesn't have that warranty by the licensor.
Actually, there are fourteen channels. Only eleven of them are legally allowed in the US. Many European countries allow channels up to thirteen.
But Vista can support it. It just doesn't by default. Vista doesn't need it and shouldn't use it. Furthermore, given that it is an old feature that exists solely to work around broken network stacks, it is completely reasonable to assume that any modern OS supports a network stack that is sufficiently functional so as not to need it. (The alternative, but equivalent, assumption is that any OS still needing that feature is so old as to be a security risk, and therefore, shouldn't be on the Internet.)
That's the beauty of a "SHOULD" statement: it's a good idea, but not a requirement. There are numerous reasons why someone might not implement the requirements of such a clause: it's not needed, it can't be tested, or it violates a design concern such as security. When the DHCP server in question was written, Vista probably wasn't around, and therefore it wasn't needed. A basic review of computer security will demonstrate that unused or little-used code is especially prone to security bugs because nobody looks at or fixes it.
I also disagree that Microsoft gained a technical benefit from enabling it: why write brittle code when it's just as easy to write more robust code?
The Texas Legislature just recessed until January 2009; by the state constitution, the legislature can only meet for 140 days every two years, unless called into special session by the governor. Since there was no enabling legislation in Texas, Real ID won't be implemented here; it would violate parts of the Government Code permitting people to view and correct errors on information about them, among other laws.