I think I see the problem here: you consider occupying space and using bandwidth paid for by the recipient, when the recipient hasn't agreed beforehand, to be a legitimate business activity. The state and most of us consider it trespass, just like if you used our front lawn to host a business get-together without asking us first.
Spammers have every right to exist, yes. And if they trespass on private property, to wit the privately-paid-for mailboxes of ISP subscribers, the subscribers have every right to sue the spammers for trespass and the state has every right to prosecute them for trespass. If the spammers don't like this, they can not trespass.
The DGA may be skating on thin legal ice with this one. Paramount already tried suing CleanFlicks (specifically Sunrise Family Video in Utah, one of their stores) over exactly this kind of editing of Titanic. I believe it was heard in Federal court, same circuit as Colorado, and Paramount lost badly. The decision wasn't controversial, it didn't involve any novel interpretations of fair use or anything, it revolved around long-established predecents about first sale and owner use. I can't dig up the text of the decision, but if it was Federal CleanFlicks is certain to cite it and being in the same circuit there's a good chance the court would follow precedent. And if the court rules for the DGA, conflicting decisions are one of the best grounds for getting an appeals court to hear the case to resolve the conflict.
Actually I don't think 2600 tried to invoke 1201(c)(1). They tried some other clauses that didn't turn on standard copyright law. That left them arguing for making precedent, which judges tend to not like to do.
Except for 1201(c)(1), which basically says nothing in the DMCA eliminates rights under copyright law, and the judge's ruling was based on rights under copyright law.
Actually that would probably be incorrect too. There was a case back in the early 80s (I forget the exact cite) involving copy protection to make computer disks unbackupable and contract terms that prohibited making backups or breaking the protection to make backups. The court ruled that copyright law granted the copy owner the right to make backups of what they owned, and that prohibiting backups or making them impossible was illegal (the judge didn't just find the contract terms unenforceable, he found them to violate copyright law). Extending that to other digital media isn't a stretch at all.
There's one point the DRM opponents should be harping on here. The industry has claimed that there's provisions in the systems that insure fair-use rights can't be restricted. The 5C rep says the same in the article. Yet, here we have it, those rights that were supposedly protected were shut down completely at the accidental flip of a switch. DRM opponents should drive home the fact that this shows that those provisions aren't any insurance that fair-use rights can't be interfered with, they're merely a promise by the industry that while they can shut down fair use any time they want they won't actually do it. If they decide to go back on that promise, maybe because a major studio decided to twist their arms, the people affected have no recourse and no way to recover their fair-use rights.
But then there's the dark side to that, specifically what happens when the type of the variable gets changed (say from int to class InterlockedULCounter for a counter). This being C++, the programmer's defined the correct methods to make the ++ and other operators work right, except that the number's now an unsigned long instead of an int, so only a few places where it was output needed touched to keep everything compiling cleanly and working properly. Nobody wants to go to the trouble of tracking down every initialization or increment of the variable across the entire program just to change the type prefix and now you're back to a situation where you can't tell the type of the variable from the prefix. Except that you're assuming you do know, and are in for a nasty suprise in the near future.
The first objection would be false. A company can readily add things to the persistence format, as long as they document them so other software can interoperate with them. Whether that other software then chooses to recognize the new items is up to it.
Note that standards can be designed to be open-ended. For example, the standard could explicitly include a way of adding vendor-specific tags to an XML-based format. Any vendor could adhere to the standard by making their vendor-specific tags conform to the standard's rules, and qualify as "Sincere Choice" by documenting their vendor-specific stuff so others can read what they write and write things they can read.
And yes, this can be done. I do it every day in my job. You'd be suprised how much you can get away with ignoring, too. I can ignore, for example, 99% of the stuff in an MSWord document, apply a simple line-wrapping rule, and get readable results. Not pretty, but readable. In some cases more readable than the original, in fact.
RedHat fixed this and released the OpenSSL RPMs back at the end of July. However, you won't see a version-number change in OpenSSL because of the fix. RH took the fix, ported it to the 0.9.6b codebase they use for their package and released it as an 0.9.6b update RPM. This tends to confuse people, because RH's current 0.9.6b isn't vulnerable even though stock 0.9.6b is.
It sounds like you've got a handle on the situation. Note that the WSS page code itself doesn't do pop-ups (we've got ad partners on our free service that do, but their pop-up code is outside the WSS hit-tracking code). As long as your browser loads images and accepts third-party cookies that don't collect personalized information, you'll be counted by WSS. So you can block pop-ups as much as you want (and personally I highly recommend it) without blocking yourself from being counted for the most part. Since the data those browser-usage numbers come from is global across all our customers, I don't think the pop-up-only sites would have much effect. We count once per browser instance per day, so as long as you hit some site with Hitbox code on it somewhere you'd be counted, even if you weren't counted at that pop-up-only site.
I'm afraid I've got little sympathy for the author of the article. He is running an open relay. Yes, for someone to abuse it they've got to forge the headers. That spammers do this is news? I don't think so. So, he runs an open relay, it gets detected, he gets added to a blackhole list until he closes it, he's now upset that the list operator won't accept "Well, someone would have to lie to abuse my server, so it shouldn't count." as an excuse. Pardon my complete lack of sympathy for him. This isn't vigilante justice, this is simple shunning by the community. If he wants to restrict his server to authorized users, he should do just that. POP-before-SMTP and SMTP AUTH exist, they can be used. Requiring that someone forge his domain in a From: header is not securing a relay.
Yes, it does. However, the only way around this is to do a lot of work with IP addresses and maintain, on WSS's side, a detailed database correlating individual machines to their browsing history. This is, for obvious reasons, not a desirable option. Personally I'm worried that the numbers are skewed exactly so, but there's not much we can do about it.
We do track cookie acceptance, but there's a catch-22: to determine browser instances, as opposed to raw hits, we need to be able to set a cookie in the browser. That means it's almost impossible to get an accurate figure on how many users reject cookies. All we can do is work with the raw-hits numbers for internal estimates, and hope that Mozilla users unblock hitbox.com cookies so we can track their numbers.
I can speak on that. WSS tags your browser with a cookie containing, among other things, the number of times you've visited a site and the last time you visited that site. The WSS server software can take that and determine whether you're a unique visitor to the site that day and/or forever. The browser figures are based not on total hits, but on unique browser instances as determined by the cookies. So it doesn't matter if you hit the site once or 1000 times, you're one unique visitor for purposes of counting browser types.
Note that identifying a particular browser instance isn't needed with cookies, the fact that WSS's servers got that particular cookie automatically does all the work that unique IDs would have been needed for. Of course, it also means that if you block third-party cookies WSS can't keep track of the timestamps and counts and so can't include you in the statistics.
Disclaimer: I write WSS's front-end software, the stuff the browser actually talks to. Take this as you will.
Not quite. I suspect the loophole they're using is the one that cost the movie studio the case when they tried to sue the Utah video store editing copies of Titanic: if it's legal for the copy owner to do, it's legal for them to hire someone to do for them. My guess is that they're selling an original copy of the movie edited per the buyer's request before delivery. It's a fine distinction, but one the courts have consistently recognized.
As for the GPL analogy, the equivalent would be someone selling Linux kernels with a non-GPL'd custom modification. They couldn't legally do what you describe, but they could legally distribute the original Linux kernel accompanied by non-source-available binaries (which could not be further redistribued because of the conflict with the GPL) containing modifications done at the receiver's request.
Re:Great work - but overstated security problems
on
Warflying: San Diego
·
· Score: 3, Insightful
I think there's two problems with unsecured wireless networks. The first is access to data. In business settings often the WAP isn't firewalled off and secured, so it provides an access point into the business's LAN that doesn't require physical access to their wiring. The risks there are obvious. In the home environment lack of a firewall's a given, but there's more risk than would be apparent. If someone searched your computer and you used Quicken, how many account numbers could they find? This is frightening when you consider that banks, when processing electronic checks, don't actually validate much. If an electronic check comes in with a valid account number, they pay it and leave it up to the account holder to screech if it's not kosher.
The second is access to bandwidth. Even if someone can't or doesn't get access to your computers, they can probably use your network connection to reach the rest of the Internet. What they do will then be traceable back to your network, with no obvious indication that the attached machine wasn't legitimate and one of yours. The result of that is that you could be held responsible for that P2P server hosting pirated content, or that huge chunk of child pornography that got downloaded to something attached to your network. You can try to prove it wasn't one of your machines, but that's going to be a tough job and isn't guaranteed to succeed.
Except that what you describe existed a long time ago. It was a service hosted at, unsuprisingly, my.mp3.com. You could download anything from a huge library, the only catch was that before the server would give you a digital copy of your CD you had to provide it with a checksum of the data off your CD. Sure you could hack around this, but for 90% of people it meant that you had to prove you already owned it before you could download it. Legal sharing.
3 guesses what service was the first target of the RIAA, long before Napster even existed, and the first two don't count.
Most of the problem is that the RIAA/MPAA, in their zeal to stop piracy, want to stop all legal uses of their material that they don't approve of. For example, I do have the right to make copies of copyrighted material, if I legitimately own an original copy and the additional copies are for my personal use. That's been litigated, and every court decision on it's supported that as legal. I have the right to sell my legitimate copy to someone else without requiring authorization from or approval by the copyright holder.
Add to that things like the RIAA saying it's unreasonable to demand that they actually show proof of copyright ownership before being allowed to demand the take-down of allegedly copyrighted material, and we've good reason to be annoyed at the RIAA/MPAA.
Probably the best defense against this is to be employed in California. Lots of tech companies here have invention clauses in their employment agreements, and most of them don't have any exclusions, but all of them come with a copy of California's law on the subject. That law limits the scope of any such invention clause to two things:
Things invented, regardless of subject matter, during your period of employment while actually at work.
Things invented, whether actually at work or not, which fall into the category of things your employer is currently doing or is planning on doing in the future.
The law's clear on a bunch of points. Salaried employees ARE NOT always at work. Companies don't get to redefine "what they do" in twisted ways to cover anything under the sun. The contract may not legally contain terms which contradict the law. The contract may not be applied to things invented before you were employed there (provided you list them so the employer knows what they are) nor after your employment ended (although if the idea is in the same area as your work and within a reasonable time after the end of your employment the employer can argue that you actually came up with it before you left and didn't say anything and the burden will be on your to refute that).
The conditions aren't perfect, but they're reasonable enough that most people can live with them..ca.us may be crazy, but sometimes they're crazy in good ways.
When companies like MS make arguments such as the one claiming the government shouldn't use licenses like the GPL that might hinder them exploiting government-funded software, there's a good way to respond. Make the politicians answer this question publically: "Should we, as a matter of public policy, allow private enterprises to appropriate intellectual property (that they consider so valuable when it's theirs) developed with public funds and use that property for their own profit without compensation to the public?".
I think you misunderstand the concept of "leech". The abusers AT&T is talking about have upstream traffic every month of 20-30 gigabytes, with downstream traffic in excess of a hundred gigabytes a month. You're in the 90% of the users who, combined, use less than 20% of the system's bandwidth. The abusers are in the 10% that sucks up the other 80%.
Leeches aren't fictional, and AT&T already knows about traffic shaping. Problem is, traffic shaping throttles your peak or burst bandwidth. For people who don't leech or abuse their connection, it's nice to let them occasionally burst to higher bandwidths. If you apply traffic shaping they won't be able to burst even if it's only 1 time a month for a few tens of megabytes. The billing change AT&T's doing hits leeches for long-term average usage without chopping off bursts for non-abusers.
I like AT&T's approach. Do a single 10-megabyte upload a month, you get full burst rate. Run a file-sharing server transferring at a megabit a second 24x7, you get hit with a big bill and a warning to either curb your transfers or pay full-time for a dedicated chunk of bandwidth.
Sun did it with Ethernet. They set their NICs to use the minimum retry interval instead of minimum + random time like the spec says they must. This got better performance for Sun equipment. Right up to the time where someone put a dozen Suns on a single Ethernet segment and the competition between all of them hammered the network down to 10% of the expected bandwidth.
Various TCP/IP "accelerators" tried this too, by ignoring the exponential-backoff and slow-start parts of the TCP spec. They too improved speeds for the people who used them. Right up to the point where lots of people started to use them, when the competition between them hammered their transfer rates down to a fraction of what's expected.
We've seen it on UDP-based streaming protocols, where lack of flow-control mechanisms causes massive congestion problems and slower transfer rates than when flow-control is applied.
So why didn't anyone expect/predict this when they were designing the Gnutella network and protocols?
Slashdot Mirror
I think I see the problem here: you consider occupying space and using bandwidth paid for by the recipient, when the recipient hasn't agreed beforehand, to be a legitimate business activity. The state and most of us consider it trespass, just like if you used our front lawn to host a business get-together without asking us first.
Spammers have every right to exist, yes. And if they trespass on private property, to wit the privately-paid-for mailboxes of ISP subscribers, the subscribers have every right to sue the spammers for trespass and the state has every right to prosecute them for trespass. If the spammers don't like this, they can not trespass.
The DGA may be skating on thin legal ice with this one. Paramount already tried suing CleanFlicks (specifically Sunrise Family Video in Utah, one of their stores) over exactly this kind of editing of Titanic. I believe it was heard in Federal court, same circuit as Colorado, and Paramount lost badly. The decision wasn't controversial, it didn't involve any novel interpretations of fair use or anything, it revolved around long-established predecents about first sale and owner use. I can't dig up the text of the decision, but if it was Federal CleanFlicks is certain to cite it and being in the same circuit there's a good chance the court would follow precedent. And if the court rules for the DGA, conflicting decisions are one of the best grounds for getting an appeals court to hear the case to resolve the conflict.
Actually I don't think 2600 tried to invoke 1201(c)(1). They tried some other clauses that didn't turn on standard copyright law. That left them arguing for making precedent, which judges tend to not like to do.
Except for 1201(c)(1), which basically says nothing in the DMCA eliminates rights under copyright law, and the judge's ruling was based on rights under copyright law.
Actually that would probably be incorrect too. There was a case back in the early 80s (I forget the exact cite) involving copy protection to make computer disks unbackupable and contract terms that prohibited making backups or breaking the protection to make backups. The court ruled that copyright law granted the copy owner the right to make backups of what they owned, and that prohibiting backups or making them impossible was illegal (the judge didn't just find the contract terms unenforceable, he found them to violate copyright law). Extending that to other digital media isn't a stretch at all.
There's one point the DRM opponents should be harping on here. The industry has claimed that there's provisions in the systems that insure fair-use rights can't be restricted. The 5C rep says the same in the article. Yet, here we have it, those rights that were supposedly protected were shut down completely at the accidental flip of a switch. DRM opponents should drive home the fact that this shows that those provisions aren't any insurance that fair-use rights can't be interfered with, they're merely a promise by the industry that while they can shut down fair use any time they want they won't actually do it. If they decide to go back on that promise, maybe because a major studio decided to twist their arms, the people affected have no recourse and no way to recover their fair-use rights.
Keep hammering home that point.
The ones granted to copy owners by copyright law and fair use, confirmed in a string of cases starting with (for video) Sony v. Betamax.
But then there's the dark side to that, specifically what happens when the type of the variable gets changed (say from int to class InterlockedULCounter for a counter). This being C++, the programmer's defined the correct methods to make the ++ and other operators work right, except that the number's now an unsigned long instead of an int, so only a few places where it was output needed touched to keep everything compiling cleanly and working properly. Nobody wants to go to the trouble of tracking down every initialization or increment of the variable across the entire program just to change the type prefix and now you're back to a situation where you can't tell the type of the variable from the prefix. Except that you're assuming you do know, and are in for a nasty suprise in the near future.
The first objection would be false. A company can readily add things to the persistence format, as long as they document them so other software can interoperate with them. Whether that other software then chooses to recognize the new items is up to it.
Note that standards can be designed to be open-ended. For example, the standard could explicitly include a way of adding vendor-specific tags to an XML-based format. Any vendor could adhere to the standard by making their vendor-specific tags conform to the standard's rules, and qualify as "Sincere Choice" by documenting their vendor-specific stuff so others can read what they write and write things they can read.
And yes, this can be done. I do it every day in my job. You'd be suprised how much you can get away with ignoring, too. I can ignore, for example, 99% of the stuff in an MSWord document, apply a simple line-wrapping rule, and get readable results. Not pretty, but readable. In some cases more readable than the original, in fact.
RedHat fixed this and released the OpenSSL RPMs back at the end of July. However, you won't see a version-number change in OpenSSL because of the fix. RH took the fix, ported it to the 0.9.6b codebase they use for their package and released it as an 0.9.6b update RPM. This tends to confuse people, because RH's current 0.9.6b isn't vulnerable even though stock 0.9.6b is.
It sounds like you've got a handle on the situation. Note that the WSS page code itself doesn't do pop-ups (we've got ad partners on our free service that do, but their pop-up code is outside the WSS hit-tracking code). As long as your browser loads images and accepts third-party cookies that don't collect personalized information, you'll be counted by WSS. So you can block pop-ups as much as you want (and personally I highly recommend it) without blocking yourself from being counted for the most part. Since the data those browser-usage numbers come from is global across all our customers, I don't think the pop-up-only sites would have much effect. We count once per browser instance per day, so as long as you hit some site with Hitbox code on it somewhere you'd be counted, even if you weren't counted at that pop-up-only site.
I'm afraid I've got little sympathy for the author of the article. He is running an open relay. Yes, for someone to abuse it they've got to forge the headers. That spammers do this is news? I don't think so. So, he runs an open relay, it gets detected, he gets added to a blackhole list until he closes it, he's now upset that the list operator won't accept "Well, someone would have to lie to abuse my server, so it shouldn't count." as an excuse. Pardon my complete lack of sympathy for him. This isn't vigilante justice, this is simple shunning by the community. If he wants to restrict his server to authorized users, he should do just that. POP-before-SMTP and SMTP AUTH exist, they can be used. Requiring that someone forge his domain in a From: header is not securing a relay.
Yes, it does. However, the only way around this is to do a lot of work with IP addresses and maintain, on WSS's side, a detailed database correlating individual machines to their browsing history. This is, for obvious reasons, not a desirable option. Personally I'm worried that the numbers are skewed exactly so, but there's not much we can do about it.
We do track cookie acceptance, but there's a catch-22: to determine browser instances, as opposed to raw hits, we need to be able to set a cookie in the browser. That means it's almost impossible to get an accurate figure on how many users reject cookies. All we can do is work with the raw-hits numbers for internal estimates, and hope that Mozilla users unblock hitbox.com cookies so we can track their numbers.
I can speak on that. WSS tags your browser with a cookie containing, among other things, the number of times you've visited a site and the last time you visited that site. The WSS server software can take that and determine whether you're a unique visitor to the site that day and/or forever. The browser figures are based not on total hits, but on unique browser instances as determined by the cookies. So it doesn't matter if you hit the site once or 1000 times, you're one unique visitor for purposes of counting browser types.
Note that identifying a particular browser instance isn't needed with cookies, the fact that WSS's servers got that particular cookie automatically does all the work that unique IDs would have been needed for. Of course, it also means that if you block third-party cookies WSS can't keep track of the timestamps and counts and so can't include you in the statistics.
Disclaimer: I write WSS's front-end software, the stuff the browser actually talks to. Take this as you will.
Not quite. I suspect the loophole they're using is the one that cost the movie studio the case when they tried to sue the Utah video store editing copies of Titanic: if it's legal for the copy owner to do, it's legal for them to hire someone to do for them. My guess is that they're selling an original copy of the movie edited per the buyer's request before delivery. It's a fine distinction, but one the courts have consistently recognized.
As for the GPL analogy, the equivalent would be someone selling Linux kernels with a non-GPL'd custom modification. They couldn't legally do what you describe, but they could legally distribute the original Linux kernel accompanied by non-source-available binaries (which could not be further redistribued because of the conflict with the GPL) containing modifications done at the receiver's request.
I think there's two problems with unsecured wireless networks. The first is access to data. In business settings often the WAP isn't firewalled off and secured, so it provides an access point into the business's LAN that doesn't require physical access to their wiring. The risks there are obvious. In the home environment lack of a firewall's a given, but there's more risk than would be apparent. If someone searched your computer and you used Quicken, how many account numbers could they find? This is frightening when you consider that banks, when processing electronic checks, don't actually validate much. If an electronic check comes in with a valid account number, they pay it and leave it up to the account holder to screech if it's not kosher.
The second is access to bandwidth. Even if someone can't or doesn't get access to your computers, they can probably use your network connection to reach the rest of the Internet. What they do will then be traceable back to your network, with no obvious indication that the attached machine wasn't legitimate and one of yours. The result of that is that you could be held responsible for that P2P server hosting pirated content, or that huge chunk of child pornography that got downloaded to something attached to your network. You can try to prove it wasn't one of your machines, but that's going to be a tough job and isn't guaranteed to succeed.
Except that what you describe existed a long time ago. It was a service hosted at, unsuprisingly, my.mp3.com. You could download anything from a huge library, the only catch was that before the server would give you a digital copy of your CD you had to provide it with a checksum of the data off your CD. Sure you could hack around this, but for 90% of people it meant that you had to prove you already owned it before you could download it. Legal sharing.
3 guesses what service was the first target of the RIAA, long before Napster even existed, and the first two don't count.
Most of the problem is that the RIAA/MPAA, in their zeal to stop piracy, want to stop all legal uses of their material that they don't approve of. For example, I do have the right to make copies of copyrighted material, if I legitimately own an original copy and the additional copies are for my personal use. That's been litigated, and every court decision on it's supported that as legal. I have the right to sell my legitimate copy to someone else without requiring authorization from or approval by the copyright holder.
Add to that things like the RIAA saying it's unreasonable to demand that they actually show proof of copyright ownership before being allowed to demand the take-down of allegedly copyrighted material, and we've good reason to be annoyed at the RIAA/MPAA.
Probably the best defense against this is to be employed in California. Lots of tech companies here have invention clauses in their employment agreements, and most of them don't have any exclusions, but all of them come with a copy of California's law on the subject. That law limits the scope of any such invention clause to two things:
- Things invented, regardless of subject matter, during your period of employment while actually at work.
- Things invented, whether actually at work or not, which fall into the category of things your employer is currently doing or is planning on doing in the future.
The law's clear on a bunch of points. Salaried employees ARE NOT always at work. Companies don't get to redefine "what they do" in twisted ways to cover anything under the sun. The contract may not legally contain terms which contradict the law. The contract may not be applied to things invented before you were employed there (provided you list them so the employer knows what they are) nor after your employment ended (although if the idea is in the same area as your work and within a reasonable time after the end of your employment the employer can argue that you actually came up with it before you left and didn't say anything and the burden will be on your to refute that).The conditions aren't perfect, but they're reasonable enough that most people can live with them. .ca.us may be crazy, but sometimes they're crazy in good ways.
When companies like MS make arguments such as the one claiming the government shouldn't use licenses like the GPL that might hinder them exploiting government-funded software, there's a good way to respond. Make the politicians answer this question publically: "Should we, as a matter of public policy, allow private enterprises to appropriate intellectual property (that they consider so valuable when it's theirs) developed with public funds and use that property for their own profit without compensation to the public?".
I think you misunderstand the concept of "leech". The abusers AT&T is talking about have upstream traffic every month of 20-30 gigabytes, with downstream traffic in excess of a hundred gigabytes a month. You're in the 90% of the users who, combined, use less than 20% of the system's bandwidth. The abusers are in the 10% that sucks up the other 80%.
Leeches aren't fictional, and AT&T already knows about traffic shaping. Problem is, traffic shaping throttles your peak or burst bandwidth. For people who don't leech or abuse their connection, it's nice to let them occasionally burst to higher bandwidths. If you apply traffic shaping they won't be able to burst even if it's only 1 time a month for a few tens of megabytes. The billing change AT&T's doing hits leeches for long-term average usage without chopping off bursts for non-abusers.
I like AT&T's approach. Do a single 10-megabyte upload a month, you get full burst rate. Run a file-sharing server transferring at a megabit a second 24x7, you get hit with a big bill and a warning to either curb your transfers or pay full-time for a dedicated chunk of bandwidth.
It's not like this hasn't happened before.
Sun did it with Ethernet. They set their NICs to use the minimum retry interval instead of minimum + random time like the spec says they must. This got better performance for Sun equipment. Right up to the time where someone put a dozen Suns on a single Ethernet segment and the competition between all of them hammered the network down to 10% of the expected bandwidth.
Various TCP/IP "accelerators" tried this too, by ignoring the exponential-backoff and slow-start parts of the TCP spec. They too improved speeds for the people who used them. Right up to the point where lots of people started to use them, when the competition between them hammered their transfer rates down to a fraction of what's expected.
We've seen it on UDP-based streaming protocols, where lack of flow-control mechanisms causes massive congestion problems and slower transfer rates than when flow-control is applied.
So why didn't anyone expect/predict this when they were designing the Gnutella network and protocols?
Please see hack mode in the Jargon File.