I think almost everyone here understands that a cert doesn't provide identification of the people behind it. It just proves that the server is authorized to operate for a given domain. As such, AFAICT, Comodo didn't have any requirement to revoke the certs in the article you referenced at all. If you want identification of the people, background checks, etc., then you should only trust EV certs. As for taking a month to revoke something, before a company can interfere in the operation of a business, it has to make darn sure that it is not a legitimate business. AFAICT from that article, this isn't a clear-cut case of someone obtaining a cert for somebody else's domain. This is a case of somebody whining that a site run by criminals was allowed to get a cert. The expectation that they could not has no basis in reality, which was the entire point of my previous posts on the subject.
This involved a reseller of Comodo's certs, not Comodo itself; upon being notified of the problem, Comodo made the reseller fix the problem and as I understand it, manually verified all the SSL certs that the reseller in question sold. Given the circumstances, I think that's a perfectly reasonable response and see no reason that they should be delisted, IMHO. Now if some other reseller comes along and pulls the same stunt and Comodo doesn't notice, then it might be worth revocation of trust. Presumably, however, Comodo will be more careful about monitoring their resellers from now on.
Yes and no. Preventing spoofing means establishing that the content comes from the actual domain in question, so in effect, it is establishing the identity of the https server in terms of the domains it is authorized to serve. It is not, however, establishing the identity of the people who run that server in any way (except ensuring that they have a valid email address). It similarly does not establish the identity of the domain's owners.
If they did not do the whois check, it would only be necessary to hack one DNS server anywhere in the world to be able to spoof traffic from some users. For that matter, an ISP owner or admin acting maliciously would not have to hack a server at all, but merely reconfigure it. By requiring the whois check, they would have to crack one or more authoritative DNS servers for the domain, crack the owner's account at the registrar, or crack the registrar's caching DNS server just to be able to get the cert at all. That's a much, much narrower set of possible targets.
Standard certs do nothing to establish identity. They merely establish that the site is not being spoofed. Thus, the purpose of the whois email verification is not to prevent illegitimate sites from getting certs. The purpose of the whois email verification is to ensure that I can't get a cert for www.bankofamerica.com, hack an ISP's DNS server to redirect their traffic to my site, and pose as Bank of America. For those purposes, it is sufficient to merely require that the domain owners confirm via email that the request was authorized.
If you want to confirm that a domain owner is in any way anything approaching a legitimate business, that's what an EV cert is for. Only an EV cert establishes identity in any way.
You don't haul a girl off to jail if she was raped do you?
That's clearly an attempt to draw an analogy, so it really isn't as offtopic as it sounds. And yes, in the case of repeated rape of the same girl by the same person, you might. It's called protective custody.
In this case, though, AT&T almost certainly isn't doing it to protect 4chan's server. I'm sure they couldn't care less about that. They do, however, care about the huge zombie botnet on their network that is probably racking up huge bandwidth bills for them with their upstream providers.
4. Replace the dots with underscores. Other than the size of the DNS zone file, there's no practical difference between those sub-subdomains being bar.foo.mydomain.org and being bar_foo.mydomain.org.
As for why sub-subdomains don't work, that's actually browser-dependent. Some browsers allow it, some don't.
Regarding securing the domain itself, it's all about money. Some SSL cert vendors' wildcard certs do cover the domain itself, some don't. For example, DigiCert's wildcard certs cover the domain itself. The ones who don't merely decided, "We'll get an extra $xxx for the domain cert." It's all a question of whether they included the domain itself in the list of things that their signature covers or not. It's just an extra entry in the list of authorized domains for the cert.
Uh, no, they'd better not be doing that. A certificate authority (CA), in order to be recognized by any of the major browser vendors, is required to contact the people responsible for a domain before issuing a cert for that domain. Normally, the CA does this by sending email to the contact addresses in the domain's whois record. Unless one of those contacts clicks a link or takes some other action to confirm that the person is authorized to obtain a cert on the domain's behalf, the CA is not allowed to issue the cert. Some CAs will also allow certified letters from the registrar if your whois contact info is stale, but that's likely to be an even bigger hoop.
If you know of a CA that is violating this policy and is just issuing a cert if the credit card clears, please contact every browser vendor out there, and that CA will immediately cease to be a recognized CA.
Get a free certificate, then. http://www.startssl.com/ generates basic certificates at no charge. It works in most major browsers, and IE support is expected in the near future. Now that startssl exists, there's really no excuse for self-signed certs even inside a corporate firewall, much less for a real public website.
That really doesn't matter anyway. Without a signed release, it is violation of privacy laws to use someone's photograph in a commercial advertisement, period. You need a full fledged model release that makes it explicitly clear that you are agreeing to have a photograph of you used in this way, and in order to be a valid contract, you have to get compensation in return. The Facebook contract doesn't contain any such authorization, so it wouldn't protect an advertiser even if Facebook said such use was allowed. Further, even if the FB user agreement contained such an authorization clause, it still would not be legally valid. Profile photos may contain other people who are not a party to the FB user agreement.
Thus, use of photos in that way is not a contract matter, it's a criminal violation of privacy laws, and companies doing this could easily find their ad people doing time behind bars.
A far bigger problem, however is that Facebook isn't policing their advertisements AT ALL. I've seen violations of the no-use-of-photos-in-ads policy by that sleazy IQ Test scam as late as a few hours ago. Screen capture here.
Facebook needs to ban that IQ test company from advertising on their site. Besides being a textbook case of telco fraud, they're violating a number of privacy laws with these ads, violating Facebook policy, etc. These people truly should be arrested.
No, now it's a MySpace clone with a median age somewhere in the 30s or 40s. The reason MySpace isn't doing nearly as well is that it catered mainly to teenagers, so adults rarely got accounts. Facebook catered to adults, so teens saw it as something that would make them seem older/more mature, and thus more cool. In effect, they won over the teenage crowd by not trying to win them over. Understanding the teenage mind FTW.
Actually, this is a great application for MobileMe. If you forget your pin number, assuming you are connected through MobileMe, it would be just as simple to have a remote unlock/PIN reset command as it is to have a mobile wipe. No support nightmare required. "Log into your MobileMe account. Now click 'My iPhone.' Now click 'Forgot PIN'. Now enter a new PIN. No! Don't tell me what it is! Enter a different PIN. Write it down before you do. Now click the 'Change PIN' button. Wait for it." The phone buzzes. "Now type in that new PIN. Did it unlock? Good."
In fact, it does. BlackBerries even have an option to not encrypt the address book so you can have names appear on caller ID while the device is locked.
They shouldn't leave the address book unencrypted. You could get a fairly significant increase in security with just some simple hashing.
For the copy on the "public" side (used while the device is locked), you use a database with two keys: hash and cryptname. Use a one-way hashing function on the telephone number and store that in the hash field, then compute a second hash (either with a different hash function or a different "salt" or whatever) on the telephone number, XOR the result with the name, and store the result in the cryptname field.
When the phone receives a call, hash the phone number. If the result matches the value of the hash field in one row, compute the second hash, compute the XOR of that second hash result with the cryptname field, and display the resulting name. The only way to crack this is to test every possible phone number in the world against every possible entry in the address book. Want to make it harder to crack? Use a slower hash function or hash it a thousand times or whatever. Make it computationally expensive enough that brute force cracking isn't worth the effort.
To make it even more secure, salt the data before hashing. In other words, take random data and mix it in with the digits of the phone number in some way. Store that random data in another field. By making the resulting input data to the hash much larger than ten digits, this makes it harder to create a website of hash tables of phone numbers. Make this field as large as you want.
To increase correctness, you should also encrypt a copy of the phone number (using a different hash/salt) to ensure that if you get a hash collision and two numbers end up matching one of the values in the "hash" column, the software can display the correct phone number.
Is such a scheme secure? No. Is it a heck of a lot better than cleartext? Yes. Is it so simple to implement that it makes no sense not to do so? Also yes.
The purist seeks to change the world to fit him, whereas the pragmatist changes himself to fit the world.
Precisely.
Ergo all progress relies on the purists.:-)
No, you have it backwards. All true change depends on the pragmatist. While the purist is seeking a way to fix everything that's wrong (because it's all or nothing), the pragmatist is adapting himself/herself enough to actually solve as many problems as is practical, one at a time.
As Nietzsche put it (I think), before you can change the world, you must first change yourself. As long as you're on the outside looking in, you cannot effectively cause change. All you can do is spew rhetoric. Only when you come to accept that you can't save the world can you begin to save individuals within it, and in so doing, actually make the world better.
I think that's massive overkill. Just provide a 12V rail, a 5V rail, and a ground using a polarized plug. Heck, you can probably dispense with the 12V rail. A 5V rail by itself should cover the vast majority of portable electronics these days. Amperage negotiation? Build the supply so that if it is under too much load, it sheds power connections, then periodically switches which jacks are shed. That's much cheaper to design, and it doesn't unnecessarily add to the complexity of the devices that use it.
25 years is way too long for software copyrights. Here's a challenge: name one piece of commercially distributed software that still works *without modification* on modern hardware after 25 years and is still useful in some way.... Bear in mind that 25 years ago, the state of the art included the Apple IIc, the 128k Mac, the IBM PC AT, etc. This was several years before the first personal computer with a paged memory management unit. I've seen modern wristwatches with more powerful CPUs. Apart from arcade game nostalgia and a few legacy financial systems, I think it's safe to say that there is basically nothing of value in code from that far back. Everything of value had to be updated, massively reworked, or rewritten hundreds of times since then to remain useful.
The purpose of copyright is to encourage creation of new works and to expire after a period of time to enrich the public domain. Copyright durations of 25+ years on software do neither. They don't contribute to the public domain because the software is useless by the time the end of the copyright period is reached, and they don't encourage creation of new software because companies are allowed to rest on their laurels, not creating anything until their copyright runs out or until changes to the underlying OS/hardware force them to update their software to keep selling it.
Remember that, at least in the U.S., derivative works are also protected by copyright, so the version 2.0 can still be protected by copyright after the copyright on version 1.0 expires. There's no benefit to having copyright on older versions of software unless the new versions don't offer enough advantage to be worth buying, in which case they don't deserve protection anyway. I strongly feel the policy should be, "Innovate or die." If you aren't improving the state of technology---if you're just making money off something you created decades ago---then you are no longer contributing to society and don't deserve to be rewarded for your lack of contribution.
Five years after first release is long enough. Ten years is barely acceptable. Twenty-five years is obscene. The current 120 years is outright grand larceny from the public domain.
I think that by focusing on prior art, you are all missing the real point of this story. This shows why software patents are sometimes good. This patent ensures beyond a reasonable doubt that grotesque user interface abuses like this one never make it into any generally accepted standard....
It's not necessary to check a return value if you don't care if the action succeeded or failed. One could reasonably argue that (at least in GUI application) printf qualifies as just such a throwaway statement.
As for returning an exit status, AFAIK, both C99 and C++ codify that a main() function should implicitly return zero if the end of the function is reached. Thus, that's also correct, although one could argue that the behavior was OS-dependent back when that code was originally written, and thus it has only become correct in the past decade or so.:-)
Slashdot Mirror
Oops. My bad. Yeah, make that a hyphen. :-)
I think almost everyone here understands that a cert doesn't provide identification of the people behind it. It just proves that the server is authorized to operate for a given domain. As such, AFAICT, Comodo didn't have any requirement to revoke the certs in the article you referenced at all. If you want identification of the people, background checks, etc., then you should only trust EV certs. As for taking a month to revoke something, before a company can interfere in the operation of a business, it has to make darn sure that it is not a legitimate business. AFAICT from that article, this isn't a clear-cut case of someone obtaining a cert for somebody else's domain. This is a case of somebody whining that a site run by criminals was allowed to get a cert. The expectation that they could not has no basis in reality, which was the entire point of my previous posts on the subject.
This involved a reseller of Comodo's certs, not Comodo itself; upon being notified of the problem, Comodo made the reseller fix the problem and as I understand it, manually verified all the SSL certs that the reseller in question sold. Given the circumstances, I think that's a perfectly reasonable response and see no reason that they should be delisted, IMHO. Now if some other reseller comes along and pulls the same stunt and Comodo doesn't notice, then it might be worth revocation of trust. Presumably, however, Comodo will be more careful about monitoring their resellers from now on.
Yes and no. Preventing spoofing means establishing that the content comes from the actual domain in question, so in effect, it is establishing the identity of the https server in terms of the domains it is authorized to serve. It is not, however, establishing the identity of the people who run that server in any way (except ensuring that they have a valid email address). It similarly does not establish the identity of the domain's owners.
If they did not do the whois check, it would only be necessary to hack one DNS server anywhere in the world to be able to spoof traffic from some users. For that matter, an ISP owner or admin acting maliciously would not have to hack a server at all, but merely reconfigure it. By requiring the whois check, they would have to crack one or more authoritative DNS servers for the domain, crack the owner's account at the registrar, or crack the registrar's caching DNS server just to be able to get the cert at all. That's a much, much narrower set of possible targets.
Standard certs do nothing to establish identity. They merely establish that the site is not being spoofed. Thus, the purpose of the whois email verification is not to prevent illegitimate sites from getting certs. The purpose of the whois email verification is to ensure that I can't get a cert for www.bankofamerica.com, hack an ISP's DNS server to redirect their traffic to my site, and pose as Bank of America. For those purposes, it is sufficient to merely require that the domain owners confirm via email that the request was authorized.
If you want to confirm that a domain owner is in any way anything approaching a legitimate business, that's what an EV cert is for. Only an EV cert establishes identity in any way.
That's clearly an attempt to draw an analogy, so it really isn't as offtopic as it sounds. And yes, in the case of repeated rape of the same girl by the same person, you might. It's called protective custody.
In this case, though, AT&T almost certainly isn't doing it to protect 4chan's server. I'm sure they couldn't care less about that. They do, however, care about the huge zombie botnet on their network that is probably racking up huge bandwidth bills for them with their upstream providers.
4. Replace the dots with underscores. Other than the size of the DNS zone file, there's no practical difference between those sub-subdomains being bar.foo.mydomain.org and being bar_foo.mydomain.org.
As for why sub-subdomains don't work, that's actually browser-dependent. Some browsers allow it, some don't.
Regarding securing the domain itself, it's all about money. Some SSL cert vendors' wildcard certs do cover the domain itself, some don't. For example, DigiCert's wildcard certs cover the domain itself. The ones who don't merely decided, "We'll get an extra $xxx for the domain cert." It's all a question of whether they included the domain itself in the list of things that their signature covers or not. It's just an extra entry in the list of authorized domains for the cert.
Uh, no, they'd better not be doing that. A certificate authority (CA), in order to be recognized by any of the major browser vendors, is required to contact the people responsible for a domain before issuing a cert for that domain. Normally, the CA does this by sending email to the contact addresses in the domain's whois record. Unless one of those contacts clicks a link or takes some other action to confirm that the person is authorized to obtain a cert on the domain's behalf, the CA is not allowed to issue the cert. Some CAs will also allow certified letters from the registrar if your whois contact info is stale, but that's likely to be an even bigger hoop.
If you know of a CA that is violating this policy and is just issuing a cert if the credit card clears, please contact every browser vendor out there, and that CA will immediately cease to be a recognized CA.
Get a free certificate, then. http://www.startssl.com/ generates basic certificates at no charge. It works in most major browsers, and IE support is expected in the near future. Now that startssl exists, there's really no excuse for self-signed certs even inside a corporate firewall, much less for a real public website.
That really doesn't matter anyway. Without a signed release, it is violation of privacy laws to use someone's photograph in a commercial advertisement, period. You need a full fledged model release that makes it explicitly clear that you are agreeing to have a photograph of you used in this way, and in order to be a valid contract, you have to get compensation in return. The Facebook contract doesn't contain any such authorization, so it wouldn't protect an advertiser even if Facebook said such use was allowed. Further, even if the FB user agreement contained such an authorization clause, it still would not be legally valid. Profile photos may contain other people who are not a party to the FB user agreement.
Thus, use of photos in that way is not a contract matter, it's a criminal violation of privacy laws, and companies doing this could easily find their ad people doing time behind bars.
A far bigger problem, however is that Facebook isn't policing their advertisements AT ALL. I've seen violations of the no-use-of-photos-in-ads policy by that sleazy IQ Test scam as late as a few hours ago. Screen capture here.
Facebook needs to ban that IQ test company from advertising on their site. Besides being a textbook case of telco fraud, they're violating a number of privacy laws with these ads, violating Facebook policy, etc. These people truly should be arrested.
Maybe, if they given them away for free. What young person wouldn't want a hot secretary and a convertible?
No, now it's a MySpace clone with a median age somewhere in the 30s or 40s. The reason MySpace isn't doing nearly as well is that it catered mainly to teenagers, so adults rarely got accounts. Facebook catered to adults, so teens saw it as something that would make them seem older/more mature, and thus more cool. In effect, they won over the teenage crowd by not trying to win them over. Understanding the teenage mind FTW.
You can write games with scripts.... It's just a whole lot harder.
Actually, this is a great application for MobileMe. If you forget your pin number, assuming you are connected through MobileMe, it would be just as simple to have a remote unlock/PIN reset command as it is to have a mobile wipe. No support nightmare required. "Log into your MobileMe account. Now click 'My iPhone.' Now click 'Forgot PIN'. Now enter a new PIN. No! Don't tell me what it is! Enter a different PIN. Write it down before you do. Now click the 'Change PIN' button. Wait for it." The phone buzzes. "Now type in that new PIN. Did it unlock? Good."
Mine is sooooooo much better. The combination is...
1...
2...
3...
4.
They shouldn't leave the address book unencrypted. You could get a fairly significant increase in security with just some simple hashing.
For the copy on the "public" side (used while the device is locked), you use a database with two keys: hash and cryptname. Use a one-way hashing function on the telephone number and store that in the hash field, then compute a second hash (either with a different hash function or a different "salt" or whatever) on the telephone number, XOR the result with the name, and store the result in the cryptname field.
When the phone receives a call, hash the phone number. If the result matches the value of the hash field in one row, compute the second hash, compute the XOR of that second hash result with the cryptname field, and display the resulting name. The only way to crack this is to test every possible phone number in the world against every possible entry in the address book. Want to make it harder to crack? Use a slower hash function or hash it a thousand times or whatever. Make it computationally expensive enough that brute force cracking isn't worth the effort.
To make it even more secure, salt the data before hashing. In other words, take random data and mix it in with the digits of the phone number in some way. Store that random data in another field. By making the resulting input data to the hash much larger than ten digits, this makes it harder to create a website of hash tables of phone numbers. Make this field as large as you want.
To increase correctness, you should also encrypt a copy of the phone number (using a different hash/salt) to ensure that if you get a hash collision and two numbers end up matching one of the values in the "hash" column, the software can display the correct phone number.
Is such a scheme secure? No. Is it a heck of a lot better than cleartext? Yes. Is it so simple to implement that it makes no sense not to do so? Also yes.
Precisely.
No, you have it backwards. All true change depends on the pragmatist. While the purist is seeking a way to fix everything that's wrong (because it's all or nothing), the pragmatist is adapting himself/herself enough to actually solve as many problems as is practical, one at a time.
As Nietzsche put it (I think), before you can change the world, you must first change yourself. As long as you're on the outside looking in, you cannot effectively cause change. All you can do is spew rhetoric. Only when you come to accept that you can't save the world can you begin to save individuals within it, and in so doing, actually make the world better.
I think that's massive overkill. Just provide a 12V rail, a 5V rail, and a ground using a polarized plug. Heck, you can probably dispense with the 12V rail. A 5V rail by itself should cover the vast majority of portable electronics these days. Amperage negotiation? Build the supply so that if it is under too much load, it sheds power connections, then periodically switches which jacks are shed. That's much cheaper to design, and it doesn't unnecessarily add to the complexity of the devices that use it.
Yes, I was definitely being sarcastic.
25 years is way too long for software copyrights. Here's a challenge: name one piece of commercially distributed software that still works *without modification* on modern hardware after 25 years and is still useful in some way.... Bear in mind that 25 years ago, the state of the art included the Apple IIc, the 128k Mac, the IBM PC AT, etc. This was several years before the first personal computer with a paged memory management unit. I've seen modern wristwatches with more powerful CPUs. Apart from arcade game nostalgia and a few legacy financial systems, I think it's safe to say that there is basically nothing of value in code from that far back. Everything of value had to be updated, massively reworked, or rewritten hundreds of times since then to remain useful.
The purpose of copyright is to encourage creation of new works and to expire after a period of time to enrich the public domain. Copyright durations of 25+ years on software do neither. They don't contribute to the public domain because the software is useless by the time the end of the copyright period is reached, and they don't encourage creation of new software because companies are allowed to rest on their laurels, not creating anything until their copyright runs out or until changes to the underlying OS/hardware force them to update their software to keep selling it.
Remember that, at least in the U.S., derivative works are also protected by copyright, so the version 2.0 can still be protected by copyright after the copyright on version 1.0 expires. There's no benefit to having copyright on older versions of software unless the new versions don't offer enough advantage to be worth buying, in which case they don't deserve protection anyway. I strongly feel the policy should be, "Innovate or die." If you aren't improving the state of technology---if you're just making money off something you created decades ago---then you are no longer contributing to society and don't deserve to be rewarded for your lack of contribution.
Five years after first release is long enough. Ten years is barely acceptable. Twenty-five years is obscene. The current 120 years is outright grand larceny from the public domain.
I think that by focusing on prior art, you are all missing the real point of this story. This shows why software patents are sometimes good. This patent ensures beyond a reasonable doubt that grotesque user interface abuses like this one never make it into any generally accepted standard....
I tend to agree.
Whoosh.
It's not necessary to check a return value if you don't care if the action succeeded or failed. One could reasonably argue that (at least in GUI application) printf qualifies as just such a throwaway statement.
As for returning an exit status, AFAIK, both C99 and C++ codify that a main() function should implicitly return zero if the end of the function is reached. Thus, that's also correct, although one could argue that the behavior was OS-dependent back when that code was originally written, and thus it has only become correct in the past decade or so. :-)