It's one thing to choose how to license your own code; it's quite another to insist that others license their code the same way, simply because it may have some tenuous connection to your code.
I don't think the connection is tenuous. Is the theme intended to be run as part of Wordpess? Yes. Does the theme work without Wordpress? No. Sounds like a derivative work to me.
IMO there is a big difference between coding to an established interface (let's say POSIX) and writing an extension (theme/plugin/whatever) that is intended to run only as part of a specific piece of software (like Wordpress).
If you want to create your own non-GPL blogging software to run your own themes, go for it. If you want to save time by using someone else's work, you have to abide by their rules. I am pretty sure that this definition of derivative work has not been tested in court yet, but it really has nothing to do with the GPL specifically.
If the patient REALLY wants that head CT, even though it's unnecessary and expensive, what about that one in a million chance that there was really a problem that the doctor missed that the test would have caught? Can you say lawsuit? Over-medicating and over-testing are a big problem, but don't blame the doctors, blame the lawyers and the misguided notion among the public that more treatment is always better.
We're forced to purchase car insurance with no government-provided option, BY LAW.
How is that a bad thing? You might feel differently when your car is totaled by an uninsured driver, who has no money to pay for your medical bills even if you sue him.
I honestly don't even think IPv6 is needed. We just need recall some of those huge blocks of IP addresses that have been allocated for no good reason and implement NAT/proxies more widely.
NAT requires jumping through all sorts of hoops to try to get back to the host-to-host connectivity that IP used to allow. It's slowing the adoption of things like IPSEC and makes any application that requires peer-to-peer connections a chore to set up. NAT is not a good thing.
Just about every single company uses firewalls nowadays anyway, there is absolutely no reason for them to have huge blocks of IP addresses like they currently do (they don't even use them!).
While I agree that some organizations have many more addresses than they will ever use, firewalls have nothing to do with NAT. Every company *should* use a firewall, of course, but firewalls worked perfectly well before NAT, and they will continue to work after NAT dies a deserved death.
The magistrate isn't going to care that the contract was too long for your little brain to easily comprehend.
Apparently they do care... that's why the companies are being fined. Contracts require a "meeting of the minds" and an unreadable EULA should hardly qualify.
Your analogy is flawed. IRC is nothing like the web. As you said, IRC is a decentralized network. There are connections between the servers. "The web" doesn't exist - it's just a bunch of servers that have no connection to each other. The IRC split just referred to other people starting their own IRC networks.
Maybe you meant to compare IRC to DNS, which is a giant network of sorts. I think a DNS split is very unlikely, though. There's little benefit to having a single giant IRC network, but obvious benefit to having a single DNS network, without which the whole Internet basically gets fragmented, from a usability standpoint.
Congress shall make no law... abridging the freedom... to petition the government for a redress of grievances.
I assume this is the part you're referring to, but I don't agree with your interpretation. I don't think petitioning "the government" in this case means that harrassing one government official in particular is necessarily Constitutionally protected behavior.
If Thompson's bill was worth supporting before, then his bill should still be worth supporting after annoying e-mails, spam or for all I care: murder.
Clearly you don't understand how the Senate works. Bills need support to pass, regarldess of their content. People make deals to support each other's bills. Having friends in your court is crucial if you want to get anything passed. Is this right? Maybe not, but that's how it is, and it's not exactly a secret.
For more information, I suggest reading Fight Club Politics, available at your local library.
"But all that means is that the CAN-SPAM act isn't the appropriate law to attack him with: instead, the Senator should just go for plain-old harassment" did you not understand, dumbass?
I think the part he was actually responding to was "Spam is commercial email. This is email about a pending legislative action, and thus Jack Thompson has the right to send it because he has a right to free speech."
Spam isn't necessarily commercial, and no he doesn't. The fact that the CAN-SPAM act in particular may not apply doesn't change the widely accepted definition of spam.
Windows has troubles with 64-bit and seems to be avoiding it.
I don't think this has been true for years. And the only problems I recall were some hardware vendors not putting out 64-bit drivers, but they seem to be on board now.
Blaming Disney is a distraction. Focus on the real source of the problem. It's the same thing as blaming movie studios for not letting you watch a film on a non-HDCP display, when in fact it is the operating system (Windows Vista or Mac OS X) that enforces this restriction on you.
This goes both ways. No one is forcing Disney to use the "disable skip" feature. HDCP is required by the hardware (at least for Blu-Ray). Who do you think pushes for things like HDCP? The studios. Yes, that includes Disney. The operating systems wouldn't enforce these restrictions if the media companies weren't pushing for them.
What scares me is that while this guards against the garden variety phishing attack, it can't protect me from an ISP DNS compromise.
That's what SSL is for. The name on the SSL certificate won't match the address of the site. OR, even if they do make a certificate for wachovia.com (for example), it will be self signed. Your browser will pop up some kind of warning. Firefox will make it almost impossible to proceed (this is what everyone's been complaining about, but now you can see why it's useful).
Self-signed SSL certs work marvelously in a number of use cases:
A) When an admin or user adds the cert to a client machine (like a laptop) in a secure environment.
B) When fingerprints are verified out of band, such as over the phone, over alternate sites and protocols, printed correspondence, etc...
C) When its only necessary to know that you are communicating with the same party you were last time.
Granted that 'C' may be a rare and less secure case, but the first two are easy to perform and can meet a high standard for authentication.
Yes, and in the cases you have described, Firefox will not show any warnings at all. It will treat it as trusted since you've already verified the certificate. What's the problem?
Re:Ignorance and laziness is helping even less
on
Google's Obfuscated TCP
·
· Score: 2, Insightful
It should by default accept a self-signed cert transparently without any fuss. It SHOULDN'T show a big green lock. It should just be a regular connection. If the self-signed cert changes on a subsequent visit, THEN they should get a warning. That's it.
The problem is, we've tried to train users to look for the "https" or the lock, or both. Getting rid of the lock for self-signed connections is fine, but the https is still there, and it's misleading.
It works great for ssh and solved the whole key distribution problem.
It works great after the initial conection, but you're vulnerable to a man in the middle attack on the initial connection attempt. It doesn't solve the key distribution problem at all. Or did you not read the warning message that ssh prints out on initial connections? You're accepting a risk, just as there is a risk in accepting a self-signed certificate. The difference is that your average SSH user can understand the risk, whereas unless you go the extreme route Firefox has gone, the average Web user will still see that the lock icon is there and just ignore any warnings.
The CA system DOES solve the problem, but it relies on trusted authorities. There is no chance of a man in the middle attack with a trusted signed certificate.
I agree that it's important not to mistake encryption for authentication, but they are *both* useful, even individually.
They are both useful individually, that's true. However, to use encryption, you have to share a key. If you haven't negotiated that key in advance, your only alternative is to authenticate the peer using a public key system like a CA. So with SSL you MUST authenticate the peer, or accept the risk that you really have no idea who you're talking to or who's listening in. Given that most people have no idea how SSL works, I don't think the average user is informed enough to accept that risk.
Obviously you've never connected to a host for which you didn't have the public key cached. Any half-decent SSH client will warn about this and require explicit permission to connect, just like Firefox does with invalid SSL certificates.
If a little yellow bar like the "remember password" bar came down and said "this site is encrypted, but its identity cannot be authenticated. Be aware that, like any normal (http) website, this one may not be from who it says it's from" then it would be completely different.
Yes, it would be completely different. Joe User would ignore it.
Bear in mind the three levels of security:
1) no-ssl: offers neither encryption nor authenication
2) SSL(self-signed): offers encryption
I don't think you understand how SSL works. Guaranteeing data confidentiality without a valid certificate is impossible.
3) SSL(3rd party signed): offers both
why is that that no.2, which is a significant improvement on no.1, generates such a severe warning message?
There is no such thing as no.2. In fact, it's worse than no encryption at all, because even someone as (seemingly) technically minded as yourself is fooled into thinking that it exists. Without certificate validation you can be subject to a man-in-the-middle attack without being aware of it. You might as well be using ROT13. Sure, it's "encryption," but what's the point?
'This ignores the value of simple encryption. Snooping a connection (i.e. on a wireless link) is much easier than any of the impersonation attacks that SSL authentication prevents.'
You are acting as if security is an all or nothing affair. There is no such thing as totally secure. Every step just raises the bar.
The problem is, SSL *is* an all-or-nothing affair. If the certificate can't be trusted, you can't guarantee encryption either. Or have you never heard of a man-in-the-middle attack? Without a trusted certificate there is no way to complete the initial handshake in such a way that you can guarantee no one else is listening in. Firefox's "giant red stop sign" is exactly the right thing to do - otherwise, Aunt Tillie, whom we've trained to dutifully look for the SSL lock icon, will think that her connection is secure, when it isn't. I guarantee you she wouldn't pay attention to a tiny warning somewhere on the screen.
If anyone should sue, it's NBC. Half of the "Chuck Norris" jokes are really "Bill Brasky" jokes - in fact the whole meme is a ripoff of those sketches from the late 90's.
Slashdot Mirror
Even big, established companies incentivize employees with various equity-ish options,
Incent. The word is incent.
It's not turned on for everyone yet. But you can go here to force it on.
It's one thing to choose how to license your own code; it's quite another to insist that others license their code the same way, simply because it may have some tenuous connection to your code.
I don't think the connection is tenuous. Is the theme intended to be run as part of Wordpess? Yes. Does the theme work without Wordpress? No. Sounds like a derivative work to me.
IMO there is a big difference between coding to an established interface (let's say POSIX) and writing an extension (theme/plugin/whatever) that is intended to run only as part of a specific piece of software (like Wordpress).
If you want to create your own non-GPL blogging software to run your own themes, go for it. If you want to save time by using someone else's work, you have to abide by their rules. I am pretty sure that this definition of derivative work has not been tested in court yet, but it really has nothing to do with the GPL specifically.
If the patient REALLY wants that head CT, even though it's unnecessary and expensive, what about that one in a million chance that there was really a problem that the doctor missed that the test would have caught? Can you say lawsuit? Over-medicating and over-testing are a big problem, but don't blame the doctors, blame the lawyers and the misguided notion among the public that more treatment is always better.
We're forced to purchase car insurance with no government-provided option, BY LAW.
How is that a bad thing? You might feel differently when your car is totaled by an uninsured driver, who has no money to pay for your medical bills even if you sue him.
I honestly don't even think IPv6 is needed. We just need recall some of those huge blocks of IP addresses that have been allocated for no good reason and implement NAT/proxies more widely.
NAT requires jumping through all sorts of hoops to try to get back to the host-to-host connectivity that IP used to allow. It's slowing the adoption of things like IPSEC and makes any application that requires peer-to-peer connections a chore to set up. NAT is not a good thing.
Just about every single company uses firewalls nowadays anyway, there is absolutely no reason for them to have huge blocks of IP addresses like they currently do (they don't even use them!).
While I agree that some organizations have many more addresses than they will ever use, firewalls have nothing to do with NAT. Every company *should* use a firewall, of course, but firewalls worked perfectly well before NAT, and they will continue to work after NAT dies a deserved death.
Standard certs do nothing to establish identity. They merely establish that the site is not being spoofed.
Isn't "preventing spoofing" just another way of saying "establishing identity?"
Have they ever advertised against Firefox?
Oh, yes they did!
The magistrate isn't going to care that the contract was too long for your little brain to easily comprehend.
Apparently they do care... that's why the companies are being fined. Contracts require a "meeting of the minds" and an unreadable EULA should hardly qualify.
Your analogy is flawed. IRC is nothing like the web. As you said, IRC is a decentralized network. There are connections between the servers. "The web" doesn't exist - it's just a bunch of servers that have no connection to each other. The IRC split just referred to other people starting their own IRC networks. Maybe you meant to compare IRC to DNS, which is a giant network of sorts. I think a DNS split is very unlikely, though. There's little benefit to having a single giant IRC network, but obvious benefit to having a single DNS network, without which the whole Internet basically gets fragmented, from a usability standpoint.
I assume this is the part you're referring to, but I don't agree with your interpretation. I don't think petitioning "the government" in this case means that harrassing one government official in particular is necessarily Constitutionally protected behavior.
If Thompson's bill was worth supporting before, then his bill should still be worth supporting after annoying e-mails, spam or for all I care: murder.
Clearly you don't understand how the Senate works. Bills need support to pass, regarldess of their content. People make deals to support each other's bills. Having friends in your court is crucial if you want to get anything passed. Is this right? Maybe not, but that's how it is, and it's not exactly a secret. For more information, I suggest reading Fight Club Politics, available at your local library.
"But all that means is that the CAN-SPAM act isn't the appropriate law to attack him with: instead, the Senator should just go for plain-old harassment" did you not understand, dumbass?
I think the part he was actually responding to was "Spam is commercial email. This is email about a pending legislative action, and thus Jack Thompson has the right to send it because he has a right to free speech." Spam isn't necessarily commercial, and no he doesn't. The fact that the CAN-SPAM act in particular may not apply doesn't change the widely accepted definition of spam.
Windows has troubles with 64-bit and seems to be avoiding it.
I don't think this has been true for years. And the only problems I recall were some hardware vendors not putting out 64-bit drivers, but they seem to be on board now.
Linux does as well, but much less so.
What the hell are you talking about?
Blaming Disney is a distraction. Focus on the real source of the problem. It's the same thing as blaming movie studios for not letting you watch a film on a non-HDCP display, when in fact it is the operating system (Windows Vista or Mac OS X) that enforces this restriction on you.
This goes both ways. No one is forcing Disney to use the "disable skip" feature. HDCP is required by the hardware (at least for Blu-Ray). Who do you think pushes for things like HDCP? The studios. Yes, that includes Disney. The operating systems wouldn't enforce these restrictions if the media companies weren't pushing for them.
1. Delete e-mail.
2. Log in to bank via their web site.
What scares me is that while this guards against the garden variety phishing attack, it can't protect me from an ISP DNS compromise.
That's what SSL is for. The name on the SSL certificate won't match the address of the site. OR, even if they do make a certificate for wachovia.com (for example), it will be self signed. Your browser will pop up some kind of warning. Firefox will make it almost impossible to proceed (this is what everyone's been complaining about, but now you can see why it's useful).
Self-signed SSL certs work marvelously in a number of use cases:
A) When an admin or user adds the cert to a client machine (like a laptop) in a secure environment.
B) When fingerprints are verified out of band, such as over the phone, over alternate sites and protocols, printed correspondence, etc...
C) When its only necessary to know that you are communicating with the same party you were last time.
Granted that 'C' may be a rare and less secure case, but the first two are easy to perform and can meet a high standard for authentication.
Yes, and in the cases you have described, Firefox will not show any warnings at all. It will treat it as trusted since you've already verified the certificate. What's the problem?
It should by default accept a self-signed cert transparently without any fuss. It SHOULDN'T show a big green lock. It should just be a regular connection. If the self-signed cert changes on a subsequent visit, THEN they should get a warning. That's it.
The problem is, we've tried to train users to look for the "https" or the lock, or both. Getting rid of the lock for self-signed connections is fine, but the https is still there, and it's misleading.
It works great for ssh and solved the whole key distribution problem.
It works great after the initial conection, but you're vulnerable to a man in the middle attack on the initial connection attempt. It doesn't solve the key distribution problem at all. Or did you not read the warning message that ssh prints out on initial connections? You're accepting a risk, just as there is a risk in accepting a self-signed certificate. The difference is that your average SSH user can understand the risk, whereas unless you go the extreme route Firefox has gone, the average Web user will still see that the lock icon is there and just ignore any warnings. The CA system DOES solve the problem, but it relies on trusted authorities. There is no chance of a man in the middle attack with a trusted signed certificate.
I installed the game, and clicked the icon. The screen went full screen and black, then it kicks out with a GPF error.
I didn't realize there was a Windows 98 version!
I agree that it's important not to mistake encryption for authentication, but they are *both* useful, even individually.
They are both useful individually, that's true. However, to use encryption, you have to share a key. If you haven't negotiated that key in advance, your only alternative is to authenticate the peer using a public key system like a CA. So with SSL you MUST authenticate the peer, or accept the risk that you really have no idea who you're talking to or who's listening in. Given that most people have no idea how SSL works, I don't think the average user is informed enough to accept that risk.
You never heard of SSH obviously.
Obviously you've never connected to a host for which you didn't have the public key cached. Any half-decent SSH client will warn about this and require explicit permission to connect, just like Firefox does with invalid SSL certificates.
If a little yellow bar like the "remember password" bar came down and said "this site is encrypted, but its identity cannot be authenticated. Be aware that, like any normal (http) website, this one may not be from who it says it's from" then it would be completely different.
Yes, it would be completely different. Joe User would ignore it.
Bear in mind the three levels of security: 1) no-ssl: offers neither encryption nor authenication 2) SSL(self-signed): offers encryption
I don't think you understand how SSL works. Guaranteeing data confidentiality without a valid certificate is impossible.
3) SSL(3rd party signed): offers both
why is that that no.2, which is a significant improvement on no.1, generates such a severe warning message?
There is no such thing as no.2. In fact, it's worse than no encryption at all, because even someone as (seemingly) technically minded as yourself is fooled into thinking that it exists. Without certificate validation you can be subject to a man-in-the-middle attack without being aware of it. You might as well be using ROT13. Sure, it's "encryption," but what's the point?
From the article:
'This ignores the value of simple encryption. Snooping a connection (i.e. on a wireless link) is much easier than any of the impersonation attacks that SSL authentication prevents.'
You are acting as if security is an all or nothing affair. There is no such thing as totally secure. Every step just raises the bar.
The problem is, SSL *is* an all-or-nothing affair. If the certificate can't be trusted, you can't guarantee encryption either. Or have you never heard of a man-in-the-middle attack? Without a trusted certificate there is no way to complete the initial handshake in such a way that you can guarantee no one else is listening in. Firefox's "giant red stop sign" is exactly the right thing to do - otherwise, Aunt Tillie, whom we've trained to dutifully look for the SSL lock icon, will think that her connection is secure, when it isn't. I guarantee you she wouldn't pay attention to a tiny warning somewhere on the screen.
If anyone should sue, it's NBC. Half of the "Chuck Norris" jokes are really "Bill Brasky" jokes - in fact the whole meme is a ripoff of those sketches from the late 90's.