Microsoft won't say. And they've stated publicly that the reason they won't say is that if they did there's a high risk that the Linux community would either remove the infringing material or invalidate the patents in question.
That 6 months is probably to cover cases where you did all the groundwork for it while employed but only "invented" it (ie. published the details or started making it for sale) after you left. I don't think I'd agree to the term as it's given, but it's not a completely unreasonable concept.
If you live in California, CA Labor Code section 2870-2872 restricts what the employer can require. In particular, that 6-month period is probably not allowable under that code. You'd need to consult a labor lawyer for a professional opinion (and IMO you should consult one regardless when faced with something like this).
It is? I was under the impression that I was the one footing the bill for my phone line. Nice to know it's the telemarketers, I'm sure they'll have no problem paying up when I send them the bill for the last 5 years of payments I've been making for their phone line, right?... right?... thought so. No, it's my phone line after all, I guess, since they aren't paying for it.
And telling them they can't use my phone line without authorization first isn't any sort of restraint on their speech. They can speak all they like... on their dime. The right to free speech does not include the right to make someone else pay for it.
Why would it be prior restraint? It's not the company's phone line they're using, they're not paying for it, why should they get any right to use that line without the owner's prior authorization?
The question wouldn't be about the UDRP, I'd start with the trademark itself. If he doesn't have a registered trademark, register the mark yourself. In both the courts and the UDRP, if one party has a valid registration for the mark and the other doesn't the party with the registration has an overwhelming advantage (we can thank our corporate overlords for this, but occasionally it can be used to advantage). In fact, once you've got the registration in your name, you can probably force him to give up his domain. A truly vindictive (and cash-flush) person would look up the registration status of a bunch of his other site names and really turn things around on him.
If he's got a trademark on the name, then you're probably better off changing your domain. Fighting it will be expensive and the odds of winning are no better than 50/50 (thank our corporate overlords as noted above) even if your use is legitimate.
There's a third option. What the RIAA has presented is an allegation. Let them prove in court that their evidence is correct. Show the method by which they acquired their logs, and that it's accurate. Show the chain of custody and the steps they took to insure that the logs weren't altered before being presented to the court. List the mechanisms they have in place to detect any alteration of the evidence while under their control. Show how they analyzed the logs, the procedures they used to track a connection back to the IP serving the files and that those procedures in fact accurately identify one specific computer and no other.
It's similar to a lot of "this anonymous poster defamed us" cases. Before they get that poster's identity, the plaintiff should be (and slowly is being) required to prove that the statements made were in fact defamatory. That can be done without knowing or caring who made them. The same thing applies here: show in court that your evidence is in fact true and that it shows a case of copyright infringement, then you get access to the records to see who's guilty of it.
The firewall settings should *always* override other application settings so that an administrator cannot accidentally open a hole in the firewall.
This leads to the nonsensical result that when I tell the computer "block all incoming connections" and "synchronize your time to the Internet", it may not be allowed to synchronize time to the Internet because the incoming UDP packets needed for time synchronization will be blocked. There are ways around that, but remember that with NTP if I send a request to UDP port 123 on the NTP server, the reply does not have to come from UDP port 123 on the NTP server and connection tracking won't work in that case. The same applies to DNS. Both ntpd and BIND can be and often are configured to use random non-privileged ports for outgoing packets to remove the need to run as root after binding their listening port. When the UDP response doesn't come from the same port on the server that the request went to, connection tracking (which depends on matching up addresses and ports) fails to work and you need to punch a hole explicitly in both directions.
Not really. Remember that UDP doesn't have the concept of a connection. There's incoming packets, but at the level of the firewall it's much harder to determine whether a UDP packet's in response to a request from the local computer or not. And you can't block all incoming UDP packets. If you do, things like DNS stop working because the replies to your DNS queries get blocked. And the non-technical user isn't going to know which holes really do need punched through the firewall for things like DNS and time sync to work, so when the user says "block all incoming connections" the firewall has to decide for them which exceptions it has to make for the computer to keep working. When the user says "block all incoming connections" but also says "synchronize your time to the Internet", the firewall has to notice that it can't comply with the second request if it implements the first literally so it needs to make an appropriate exception.
That's a criticial point, BTW: the firewall settings are not the only instructions the user has given the system. If I tell it "synchronize your time with the Internet", the computer shouldn't decide to ignore that instruction just because I've also enabled the firewall. And if you do want it to start ignoring what the user's told it, why should the firewall settings take precedence over other instructions?
Yes, but the text dump is for the NTP protocol, not NetBIOS, and NTP's a protocol that presents a very low risk and it's much easier to just punch it through globally and let the NTP client handle discarding bogus attempts to alter it's time. Given that Apple's using the standard ntpd software, I'm going to want to see details of an actual exploit before I consider having it open a hole.
Well yes, I'd expect it to. The NetBIOS services on my computers do too despite being firewalled. That's because, if you look at the packet dump, the packets are sourced from the local subnet (the addresses are 192.168.69.2 and 192.168.69.21, both in the 192.168.69.0/24 network within the 192.168.0.0/16 reserved block). For SMB shares to work at all, you need to allow NetBIOS services to and from the local subnet. Since that's by definition on a different interface from the outside world (192.168.x.x addresses are not going to work on a public interface), it's a safe hole to poke. For a proper test, the attempt to access the service needs to be from a machine not on the local network.
The sources are RFC 792, the ICMP protocol specification, and RFC 1812, IP v4 host requirements (especially section 5.2.7.1 relating to firewalls). Note that the TCP protocol specification isn't particularly relevant to a discussion of how the IP stack responds to a TCP not not being listening, since if the port isn't listening the TCP connection sequence never begins. A TCP RST presumes an existing connection to reset, which there can't be if there's nothing listening for a connection to be established with.
No. It means that the firewall's black-holing (dropping without generating any ICMP response) all packets to ports 80 and 443. It can do this whether or not a Web server's running.
The NTP port is easy enough to explain. NTP is a UDP-based protocol, so there aren't any connections. When operating properly, the time interval between packet exchanges with the time servers is long so maintaining the equivalent of a TCP masquerading map isn't feasible (you either need unreasonably long timeouts leading to odd behavior when the entries become invalid but aren't timed-out, or you tend to time out active entries). Since NTP packets are fairly simple and, being UDP, arrive in a single message with the length known as the packet is read, NTP clients aren't generally subject to buffer overflow attacks. Since they also default to not trusting or accepting synchronization from any hosts other than those they're configured to use and to only accept packets from those hosts that're in response to a known request from the client, and serving time up to random clients is considered safe for the server, it's not considered a risk to have them accessible and it simplifies the firewall rules considerably to just leave the NTP port open to the world.
ICMP type 3 errors, destination unreachable, are very specifically for this purpose. In particular type 3 code 3, port unreachable, is returned if the port the client's trying to connect to isn't listening for connections. Type 3 code 13, communication administratively prohibited, is intended to be returned if a firewall rule prohibits the connection (eg. a filtering rule denies connections to that host and port). And yes, ICMP isn't part of TCP. It is, however, part of IP (although it's a parallel protocol at the same level as IP) and intended precisely for this sort of thing.
A TCP RST response is not the proper response to a closed port. It would indicate that the port was open, the listening application accepted the connection and then immediately (before any traffic was received) rejected the connection. Most commonly this happens when tcp_wrappers is being used to control access to services. It has to accept the connection to get the peer address, and then if that peer address isn't allowed access it resets the connection.
I notice in their report that they complain about services Nmap lists as "open/filtered". Nmap reports that result when it encounters a port that elicits no reply whatsoever to a probe. This happens only when a firewall is dropping all traffic to a port and not generating any ICMP error packet for the attempt. The TCP spec says if a port isn't open the client should get an ICMP error, so Nmap knows that there's something there even if access to it's being blocked. If this is any indication of the quality of this "analysis", we can discount the article.
I was under the impression from the Treasury Department page that cash was always a valid offer of payment for a debt. I suppose a creditor could refuse to accept it, but no court will let that creditor do a blessed thing against a debtor who's got a current offer of payment in legal tender sitting there that the creditor's refusing to accept.
Solid engines can't throttle. They've got two settings: off, and full power. And once they're lit, they're at full power basically until they run out of fuel to burn. There's a few things you can do to throttle them, but all of them are really hairy and complex. Basically, solid rockets are good for getting you up, not so good for getting you back down in a controlled manner.
Cash must be accepted as payment for debts. IOW if you owe someone money and offer cash in payment, they can't legally refuse to accept it. If you do not owe them money, though, then no debt exists and that rule doesn't apply. A merchant's entirely free to refuse any method of payment for a transaction where no debt exists yet.
For the iPhone, this means that if you walk up to the counter wanting to buy, they're allowed to refuse to sell for cash. Once you've bought the phone and used the service and now owe them money for that service, however, they're not free to refuse a cash payment.
I tend to go even further: if it's got an attachment and I'm not expecting a specific attachment from that particular sender at that time, it's spam. A lot of viruses send to addresses in the local address book, so just because I know the sender doesn't mean they haven't gotten infected and it's the virus sending me spam/malware. So my policy is that if people want to send me files they can either put them up on a server and send me the location so I can download it, or they can contact me beforehand and find out what format I need it in and I'll be expecting it.
I get the occasional person who whines because I insist they send their plain text mail to me as plain text, requiring them to jump through hoops to make their mail client stop generating obnoxious HTML or whatnot. But these tend to be the same people whining to me about how many problems they have with viruses on their computer, while I've gone 20+ years without a single successful infection of any of my machines.
Probably habits. I see a lot of bad design when it comes to computer keyboards. Take, for example, wrist rests. When I was taking typing classes, proper typing position was with the wrists straight so the back of your hand was level with the top of your forearm. If you let your wrists collapse far enough to touch where a wrist-rest would be, the teacher'd correct you with a quick smack of the ruler and a "Wrists UP!". Looking back at it, the wrist position they demanded was nearly exactly the right position to minimize irritation of the tendons and nerves running through the wrist. Ditto with seating, my typing teacher would've considered most modern office desks hopelessly inadequate for typing work. An additional 6-9" of chair height would be needed, plus an addition 4-6" more on the work surface around the keyboard (the keyboard should be dropped to allow the forearm to be parallel with the floor when in proper typing position while still keeping the rest of the work surface high enough to be comfortable). As for chairs, she'd've Had Words with someone about standard corporate seating policy (which most places seems to be "steal anything available for the new guy"). I literally have better chairs at home for my workstations than I've ever seen in a corporate office.
That shouldn't be a reason to bump the charge back up to regular rate, though. Standby isn't new, I've done it flying. I buy a standby ticket on a flight, I get a much cheaper rate but I only get to fly if there's an empty seat. And if there is an empty seat and I fly, I do not suddenly have to pay full fare. The discount was for me taking the risk that I wouldn't be able to fly, and if it happens I can that doesn't negate the risk that's the reason for the discount. Same here: if someone's getting a discount because they're willing to have their ad not run on the requested day if there's no space left unused by full-price ads, the fact that there is space available shouldn't negate the deal. Now, if the NYT turned down full-price ads to insure there was space left over, that would be another matter. But absent that, the discount was for taking the gamble, not for losing it.
The stores already won't sell that game to your 8-year-old. Maybe a 17-year-old, or a mature 16-year-old, if the store's lax in carding, but that's about it. And as I said, all the cases that've been the focus of the debate have involved a parent or other relative giving the kid the game. So either there's no problem for the laws this guy proposes to address, or if there is a problem 99% of the time it doesn't involve the store.
And his law will be totally ineffective. If you go back and look at the publicized cases of video games being "sold to a minor", you'll find that in all of them the store did not sell the game to a minor. They sold it to a legal adult, in all the cases I can recall a relative of the kid involved and most often a parent, who then gave it to the minor. Any law targeting the store will simply not do anything about that. You'd need a law targeting the parents, and I don't see him proposing such a law.
Slashdot Mirror
Microsoft won't say. And they've stated publicly that the reason they won't say is that if they did there's a high risk that the Linux community would either remove the infringing material or invalidate the patents in question.
That 6 months is probably to cover cases where you did all the groundwork for it while employed but only "invented" it (ie. published the details or started making it for sale) after you left. I don't think I'd agree to the term as it's given, but it's not a completely unreasonable concept.
If you live in California, CA Labor Code section 2870-2872 restricts what the employer can require. In particular, that 6-month period is probably not allowable under that code. You'd need to consult a labor lawyer for a professional opinion (and IMO you should consult one regardless when faced with something like this).
It is? I was under the impression that I was the one footing the bill for my phone line. Nice to know it's the telemarketers, I'm sure they'll have no problem paying up when I send them the bill for the last 5 years of payments I've been making for their phone line, right? ... right? ... thought so. No, it's my phone line after all, I guess, since they aren't paying for it.
And telling them they can't use my phone line without authorization first isn't any sort of restraint on their speech. They can speak all they like... on their dime. The right to free speech does not include the right to make someone else pay for it.
Why would it be prior restraint? It's not the company's phone line they're using, they're not paying for it, why should they get any right to use that line without the owner's prior authorization?
One word: Divx. Not the codec, the video-disc format. Did anyone seriously think that it wouldn't work out that way again?
First rule: Do not look into laser with remaining eye.
The question wouldn't be about the UDRP, I'd start with the trademark itself. If he doesn't have a registered trademark, register the mark yourself. In both the courts and the UDRP, if one party has a valid registration for the mark and the other doesn't the party with the registration has an overwhelming advantage (we can thank our corporate overlords for this, but occasionally it can be used to advantage). In fact, once you've got the registration in your name, you can probably force him to give up his domain. A truly vindictive (and cash-flush) person would look up the registration status of a bunch of his other site names and really turn things around on him.
If he's got a trademark on the name, then you're probably better off changing your domain. Fighting it will be expensive and the odds of winning are no better than 50/50 (thank our corporate overlords as noted above) even if your use is legitimate.
There's a third option. What the RIAA has presented is an allegation. Let them prove in court that their evidence is correct. Show the method by which they acquired their logs, and that it's accurate. Show the chain of custody and the steps they took to insure that the logs weren't altered before being presented to the court. List the mechanisms they have in place to detect any alteration of the evidence while under their control. Show how they analyzed the logs, the procedures they used to track a connection back to the IP serving the files and that those procedures in fact accurately identify one specific computer and no other.
It's similar to a lot of "this anonymous poster defamed us" cases. Before they get that poster's identity, the plaintiff should be (and slowly is being) required to prove that the statements made were in fact defamatory. That can be done without knowing or caring who made them. The same thing applies here: show in court that your evidence is in fact true and that it shows a case of copyright infringement, then you get access to the records to see who's guilty of it.
The firewall settings should *always* override other application settings so that an administrator cannot accidentally open a hole in the firewall.
This leads to the nonsensical result that when I tell the computer "block all incoming connections" and "synchronize your time to the Internet", it may not be allowed to synchronize time to the Internet because the incoming UDP packets needed for time synchronization will be blocked. There are ways around that, but remember that with NTP if I send a request to UDP port 123 on the NTP server, the reply does not have to come from UDP port 123 on the NTP server and connection tracking won't work in that case. The same applies to DNS. Both ntpd and BIND can be and often are configured to use random non-privileged ports for outgoing packets to remove the need to run as root after binding their listening port. When the UDP response doesn't come from the same port on the server that the request went to, connection tracking (which depends on matching up addresses and ports) fails to work and you need to punch a hole explicitly in both directions.
Not really. Remember that UDP doesn't have the concept of a connection. There's incoming packets, but at the level of the firewall it's much harder to determine whether a UDP packet's in response to a request from the local computer or not. And you can't block all incoming UDP packets. If you do, things like DNS stop working because the replies to your DNS queries get blocked. And the non-technical user isn't going to know which holes really do need punched through the firewall for things like DNS and time sync to work, so when the user says "block all incoming connections" the firewall has to decide for them which exceptions it has to make for the computer to keep working. When the user says "block all incoming connections" but also says "synchronize your time to the Internet", the firewall has to notice that it can't comply with the second request if it implements the first literally so it needs to make an appropriate exception.
That's a criticial point, BTW: the firewall settings are not the only instructions the user has given the system. If I tell it "synchronize your time with the Internet", the computer shouldn't decide to ignore that instruction just because I've also enabled the firewall. And if you do want it to start ignoring what the user's told it, why should the firewall settings take precedence over other instructions?
Yes, but the text dump is for the NTP protocol, not NetBIOS, and NTP's a protocol that presents a very low risk and it's much easier to just punch it through globally and let the NTP client handle discarding bogus attempts to alter it's time. Given that Apple's using the standard ntpd software, I'm going to want to see details of an actual exploit before I consider having it open a hole.
Well yes, I'd expect it to. The NetBIOS services on my computers do too despite being firewalled. That's because, if you look at the packet dump, the packets are sourced from the local subnet (the addresses are 192.168.69.2 and 192.168.69.21, both in the 192.168.69.0/24 network within the 192.168.0.0/16 reserved block). For SMB shares to work at all, you need to allow NetBIOS services to and from the local subnet. Since that's by definition on a different interface from the outside world (192.168.x.x addresses are not going to work on a public interface), it's a safe hole to poke. For a proper test, the attempt to access the service needs to be from a machine not on the local network.
The sources are RFC 792, the ICMP protocol specification, and RFC 1812, IP v4 host requirements (especially section 5.2.7.1 relating to firewalls). Note that the TCP protocol specification isn't particularly relevant to a discussion of how the IP stack responds to a TCP not not being listening, since if the port isn't listening the TCP connection sequence never begins. A TCP RST presumes an existing connection to reset, which there can't be if there's nothing listening for a connection to be established with.
No. It means that the firewall's black-holing (dropping without generating any ICMP response) all packets to ports 80 and 443. It can do this whether or not a Web server's running.
The NTP port is easy enough to explain. NTP is a UDP-based protocol, so there aren't any connections. When operating properly, the time interval between packet exchanges with the time servers is long so maintaining the equivalent of a TCP masquerading map isn't feasible (you either need unreasonably long timeouts leading to odd behavior when the entries become invalid but aren't timed-out, or you tend to time out active entries). Since NTP packets are fairly simple and, being UDP, arrive in a single message with the length known as the packet is read, NTP clients aren't generally subject to buffer overflow attacks. Since they also default to not trusting or accepting synchronization from any hosts other than those they're configured to use and to only accept packets from those hosts that're in response to a known request from the client, and serving time up to random clients is considered safe for the server, it's not considered a risk to have them accessible and it simplifies the firewall rules considerably to just leave the NTP port open to the world.
ICMP type 3 errors, destination unreachable, are very specifically for this purpose. In particular type 3 code 3, port unreachable, is returned if the port the client's trying to connect to isn't listening for connections. Type 3 code 13, communication administratively prohibited, is intended to be returned if a firewall rule prohibits the connection (eg. a filtering rule denies connections to that host and port). And yes, ICMP isn't part of TCP. It is, however, part of IP (although it's a parallel protocol at the same level as IP) and intended precisely for this sort of thing.
A TCP RST response is not the proper response to a closed port. It would indicate that the port was open, the listening application accepted the connection and then immediately (before any traffic was received) rejected the connection. Most commonly this happens when tcp_wrappers is being used to control access to services. It has to accept the connection to get the peer address, and then if that peer address isn't allowed access it resets the connection.
I notice in their report that they complain about services Nmap lists as "open/filtered". Nmap reports that result when it encounters a port that elicits no reply whatsoever to a probe. This happens only when a firewall is dropping all traffic to a port and not generating any ICMP error packet for the attempt. The TCP spec says if a port isn't open the client should get an ICMP error, so Nmap knows that there's something there even if access to it's being blocked. If this is any indication of the quality of this "analysis", we can discount the article.
I was under the impression from the Treasury Department page that cash was always a valid offer of payment for a debt. I suppose a creditor could refuse to accept it, but no court will let that creditor do a blessed thing against a debtor who's got a current offer of payment in legal tender sitting there that the creditor's refusing to accept.
Solid engines can't throttle. They've got two settings: off, and full power. And once they're lit, they're at full power basically until they run out of fuel to burn. There's a few things you can do to throttle them, but all of them are really hairy and complex. Basically, solid rockets are good for getting you up, not so good for getting you back down in a controlled manner.
Cash must be accepted as payment for debts. IOW if you owe someone money and offer cash in payment, they can't legally refuse to accept it. If you do not owe them money, though, then no debt exists and that rule doesn't apply. A merchant's entirely free to refuse any method of payment for a transaction where no debt exists yet.
For the iPhone, this means that if you walk up to the counter wanting to buy, they're allowed to refuse to sell for cash. Once you've bought the phone and used the service and now owe them money for that service, however, they're not free to refuse a cash payment.
No, it's about the states wanting to write those laws, and the administration saying they can't because the Feds haven't.
I tend to go even further: if it's got an attachment and I'm not expecting a specific attachment from that particular sender at that time, it's spam. A lot of viruses send to addresses in the local address book, so just because I know the sender doesn't mean they haven't gotten infected and it's the virus sending me spam/malware. So my policy is that if people want to send me files they can either put them up on a server and send me the location so I can download it, or they can contact me beforehand and find out what format I need it in and I'll be expecting it.
I get the occasional person who whines because I insist they send their plain text mail to me as plain text, requiring them to jump through hoops to make their mail client stop generating obnoxious HTML or whatnot. But these tend to be the same people whining to me about how many problems they have with viruses on their computer, while I've gone 20+ years without a single successful infection of any of my machines.
Probably habits. I see a lot of bad design when it comes to computer keyboards. Take, for example, wrist rests. When I was taking typing classes, proper typing position was with the wrists straight so the back of your hand was level with the top of your forearm. If you let your wrists collapse far enough to touch where a wrist-rest would be, the teacher'd correct you with a quick smack of the ruler and a "Wrists UP!". Looking back at it, the wrist position they demanded was nearly exactly the right position to minimize irritation of the tendons and nerves running through the wrist. Ditto with seating, my typing teacher would've considered most modern office desks hopelessly inadequate for typing work. An additional 6-9" of chair height would be needed, plus an addition 4-6" more on the work surface around the keyboard (the keyboard should be dropped to allow the forearm to be parallel with the floor when in proper typing position while still keeping the rest of the work surface high enough to be comfortable). As for chairs, she'd've Had Words with someone about standard corporate seating policy (which most places seems to be "steal anything available for the new guy"). I literally have better chairs at home for my workstations than I've ever seen in a corporate office.
That shouldn't be a reason to bump the charge back up to regular rate, though. Standby isn't new, I've done it flying. I buy a standby ticket on a flight, I get a much cheaper rate but I only get to fly if there's an empty seat. And if there is an empty seat and I fly, I do not suddenly have to pay full fare. The discount was for me taking the risk that I wouldn't be able to fly, and if it happens I can that doesn't negate the risk that's the reason for the discount. Same here: if someone's getting a discount because they're willing to have their ad not run on the requested day if there's no space left unused by full-price ads, the fact that there is space available shouldn't negate the deal. Now, if the NYT turned down full-price ads to insure there was space left over, that would be another matter. But absent that, the discount was for taking the gamble, not for losing it.
The stores already won't sell that game to your 8-year-old. Maybe a 17-year-old, or a mature 16-year-old, if the store's lax in carding, but that's about it. And as I said, all the cases that've been the focus of the debate have involved a parent or other relative giving the kid the game. So either there's no problem for the laws this guy proposes to address, or if there is a problem 99% of the time it doesn't involve the store.
And his law will be totally ineffective. If you go back and look at the publicized cases of video games being "sold to a minor", you'll find that in all of them the store did not sell the game to a minor. They sold it to a legal adult, in all the cases I can recall a relative of the kid involved and most often a parent, who then gave it to the minor. Any law targeting the store will simply not do anything about that. You'd need a law targeting the parents, and I don't see him proposing such a law.