SOE learned from SWG:NGE, yes. But they didn't create that mess. If you look at the deal between SOE and LucasArts that resulted in SWG, you find that SOE has no control over the game itself. LucasArts controls game mechanics, artwork creation, content creation, customer-service policies, in-game rules and just about every other aspect of the game. NGE was Lucas' idea, SOE was violently against it but they've no say over that aspect of the game. Essentially they're contractors, providing coders, CS bodies and server hosting to LucasArts and following orders about how Lucas wants the game to be. The blame for NGE rests squarely on Lucas' shoulders. The basic problem seems to be that LucasArts views SWG as nothing more than a nice merchandising tie-in opportunity and occasional source of interesting artwork. The idea that there's people who like the game itself, as opposed to fans of the movies looking for more SW-related material, doesn't seem to have registered.
SOE's attitude internally, BTW, seems to be very much "Never again.".
My first thoughts: How many of those licenses represent Vista licenses bought to run XP on corporate systems only because the corporate contracts don't let them buy XP licenses but do allow downgrading a Vista license to XP? And how many represent bunching of the sale of an entire year's worth of licenses to companies like Dell and HP into the first quarter to make the numbers look good?
Objection. So far MS hasn't actually specified any patents which they claim are infringed. They've given numbers, but they've declined to say which patents are on the list. I think I'll have to borrow the phrasing from IBM's very first few interrogatories to SCO: Please identify with specificity which patents held by Microsoft are alleged to be infringed, and which code (by software project, file, version and line) is alleged to infringe upon those patents.
Despite their accusations of infringement, they state they would rather do licensing deals instead of any legal action.
A prerequisite for licensing is to identify exactly what the licensee will be paying for a license to. Until MS places that on the table, why should I pay good money for a pig in a poke?
A security hole is a bug, plain and simple. There's no excuse for deliberately not fixing a bug. Now, you can make an argument that if the bug's minor and not causing customer problems you should hold the fix for the next regularly-scheduled release, but that's about it. The argument that unannounced holes don't seem to be being exploited is particularly disingenuous. People aren't looking for exploits of holes they don't know about. It's not surprising, then, that few people are reporting problems they aren't looking for. What's more likely is that the small subset of crackers who can find unannounced holes are quietly using them for their own gain, keeping a low profile specifically to avoid having customers raising a stink and forcing the vendor to close the hole, and only after it finally goes public do they release their secret to the wider script-kiddie population since it's no longer of use to them.
Except that using HKCU has another problem: many programs register stuff they need in the registry. On a single-user system HKCU isn't a problem. But when another user tries to use that installed program, BAM, none of the required registry entries are in their HKCU tree. Which means developers have to develop another set of practices as well: either writing programs that can self-register themselves and set up all the neccesary registry entries on their own independently of the installer (at which point the need for an installer goes away), or the installer has to set up the system-wide stuff in HKLM (which requires privileges for the installer) and then the program reads first HKLM and then HKCU for entries but only writes changes back to HKCU. Unix already has a well-developed set of practices for this, but Windows developers are going to have to learn from scratch.
Frankly I disagree with part of the quoted comment in this entry. These problems are the developers' fault. But not developers in general, only Windows developers. They've lived in their own world, ignoring everything that everybody else had learned or was learning about multi-user systems and writing programs for them, and now it's coming back to bite them. Microsoft didn't help by catering to them for so long, but ultimately it's the developers who decided not to learn from everybody else's experience and went along with the recommendations of a company with no experience in a multi-user system.
But, as part of posting a take-down notice, you must state, under penalty of perjury, that you are the owner of the material in question, or an authorized representative of the owner.
Actually that's not the case. If you read USC Title 17 512(c)(3)(A) which describes the elements of a notification, you do not have to declare under penalty of perjury that you are (or are acting for) the owner of the copyright. The "under penalty of perjury" part only applies to your declaration that you're authorized to act on behalf of the party alleging a copyright has been infringed. The part where you declare that it's your material (or belongs to whoever you're acting for) is merely upon good faith.
Except that in 1999 the problem had been long since solved. Back in the late 80s when I was in college, DEC introduced this revolutionary concept: that data file storage formats be seperate from the application. So on VMS they decreed that RTF should be the standard document format. Any word processing program running on VMS should be able to read and write RTF properly, according to the specification, and interpret the formatting in a sane way. The obvious consequence of this being done properly is that I don't care what application the other person is using. If it follows the spec, and my application follows the spec, then we can talk just fine regardless of whether we're using the same application or not. The only requirement placed on the RTF specification was that it had to concentrate on representing the document, not specific details of any particular application.
If we could do this 20 years ago, what's so blasted hard about it today?
Why were those students even able to use proxies? All traffic should be going through a commercial-grade router. A few rules and all TCP 80/443 traffic will be going to the designated filtering system and outbound connects on any other ports will be getting only an "administratively prohibited" ICMP error. Once that's done it doesn't matter what the students do on the client side.
Yes, I know the downsides, but if you want a secure filtering system you can't trust the client end to behave. If you could, you wouldn't need a filtering system.
True on the first, but on Unix systems you typically don't get those password dialogs every time you want to do something. You get them once when you go to start a program that'll need privileges. So users don't get trained by excessive, repetitive prompting to type their password in all the time.
And no, Joe User probably won't do the clean-up. His friendly neighborhood geek will be doing it, and will appreciate not having to reformat and reinstall the entire box to make sure it's clean.
And Unix does extend least-privilege to everything. The default for any application is to run as the current ordinary user. Anything beyond that requires some special action to grant privileges, usually through a wrapper in a GUI environment (the same way the Gnome and KDE desktops handle system programs that need root privileges, their wrapper can be used for anything that needs it). Start-up programs (services) are the same: almost all of them that need root initially drop it as soon as they're done (ie. Apache), and many of them don't need root privileges at all (eg. Postgres) and are run directly as their ordinary user by their startup script (su isn't just for changing to root, after all).
Actually half the purpose of ordinary user accounts being the default is to protect the system from the user. That's why admins routinely work out of ordinary accounts and reserve root for special occasions: as an ordinary user going to type "rm -rf./*" and accidentally getting "rm -rf/*" is recoverable, as root it wouldn't be.
There's also another layer of protection. Even if your ordinary user account gets owned, the system files that the root account depends on can't be altered by the malware. Since those system files and tools can't be infected, you can clean up an infection by logging in as root rather than the infected user and be sure that (modulo a local privilege-escalation vulnerability already having been exploited) your tools won't have been infected too. This makes recovery much easier.
There's a third layer too: humans aren't the only users. Every service on a Unix system is also a user. Since those services typically run as ordinary non-privileged users just like everyone else, vulnerabilities in those services are less critical. If the service is remotely accessible an outsider can crack it, but they don't get any more privilege than an ordinary user (and not even enough privilege to nail the human user's files directly). This limits the amount of damage that can be done.
First rule of security: layers. Design to prevent intrusion. Then design to minimize the damage when an intrusion occurs (note: when, not if). Then design to make clean-up as simple as possible after the damage is done.
I think what Google looks for to identify "link farms" is a cluster of tightly-related circular links. That is, a relatively small set of sites that all link heavily to each other (as opposed to linking outside the cluster). So, if you're site A, having a link-farm site B link heavily to you doesn't hurt. But if you in turn link heavily back to site B, then you're going to get dinged. Now, from what I've seen, one or two links back won't hurt. Link-farm sites tend to have a much higher percentage of links pointed at other sites in the farm than a normal page would have, and Google's looking for that threshold being crossed more than just the existence of a single link.
If you visualize each page as a point in 3-space and inks as lines connecting them, link farms look like "knots" or tangles with a much higher link density than the surrounding Web. Google's looking for that tangled appearance.
Yes, but remember that Google's product has one unique trait: it has legs. Google's product, people running searches, want to find relevant results. Relevant by their criteria, not by the criteria of the sites being found or those buying ads. If they don't get relevant results, they'll stop using Google and then what's Google going to sell? So Google does have to consider the desires of it's product when making decisions. In fact, it has to give it's product more weight than it gives any one customer. If it doesn't, it won't have a product to sell.
I think the article gives a great big hint why Skyfacet ended up on the supplemental index. First the article says "Google's programmers appear to have created the supplemental index with the best intentions. It's designed to lighten the workload of Google's "spider," the algorithm that constantly combs and categorizes the Web's pages. Google uses the index as a holding pen for pages it deems to be of low quality or designed to appear artificially high in search results.". Then it goes on later to say "In retrospect, Sanar thinks he can trace his problem to a search marketing consultant he had paid $35,000 to improve Skyfacet's Google rankings. He now believes the consultant mistakenly replicated content on many of the site's pages, making them look like duplicate--that is, spam--content.". So, basically, the site owner paid an SEO type to try to game Google's system, Google saw it and dropped his site in the trash along with the rest of the bogus sites, and now he's wondering how to get out of the trash. Well, I guess he'll just have to abandon attempts to game the system and wait until Google re-spiders his site and sees it's no longer playing tricks. Yes, that might take a while. That's the price you pay for trying to get cute and getting caught at it.
I believe other posters have indicated that many independent labels and artists are already setting up direct deals with Internet broadcasters. It's the only way to get around the RIAA/SoundExchange bureaucracy and avoid the nasty DRM the RIAA insists on. I think you've got the database thing the wrong way around, though. Yeah, SE probably has a very good database for tracking what they need to collect royalties on. The DDoS would be on the system for keeping track of the exceptions, the things they aren't allowed to collect royalties on. Up until the Internet they really didn't need a complex system, since any exceptions were probably a label (or possibly all the labels) making a blanket deal with a station for a reduced royalty rate and the labels had SE still handling the actual collection. A database set up based on that is likely to break down completely when, instead of no more than half-a-dozen deals for a station, they've got to keep track of hundreds of deals for each station, SE receives no membership fees to cover the expense since the artists aren't SE members, and they still have to keep track of what the station plays that isn't covered by those deals so they can collect the normal automatic royalties too. It's the difference between batching up tens of thousands of transactions into a single daily run vs. actually handling tens of thousands of individual transactions in real-time: a system optimized for the first is just going to die trying to attempt the second.
Note that the article, and some of the implications SoundExchange tries to slide through, are somewhat misleading. SoundExchange is merely the Copyright Office's ordained agency for collecting mechanical-license royalties. Yes, if you want to make use of mechanical licenses through that particular distribution channel, you do indeed have to go through SoundExchange. The RIAA had a big hand in the selection, but it's the Copyright Office that actually has the final say there. And remember that this was set up back when 99% of all music in fact went through the labels. But SoundExchange is not allowed to collect all royalties. If an artist or a label has a direct, non-mechanical license agreement in place with a distributor or venue, SoundExchange may not collect royalties from that distributor/venue. Their purvue is mechanical-license royalties only. The artist or the distributor/venue has to inform SoundExchange of the agreement, but once that's done the distributor can tell SE to go pound sand as far as royalties for that artist go. Caveat: both the artist and the distributor/venue should keep legally-admissable evidence of their informing SE, and have a copy on hand to give to any SE guys who show up (make them sign for it, too), so you've a paper trail if SE decides to push.
Now, this does provide an interesting DDoS against SoundExchange. I guarantee you they are not set up to handle thousands of distributors and venues each with independent, not-neccesarily-identical agreements with many artists. They're set up to handle 99% mechanical licenses, with the few exceptions being almost entirely distributors or venues whose agreements cover entire labels. If every artist and venue and on-line distributor with a direct agreement actually filed the paperwork they're by law allowed and required to file with SoundExchange, I suspect SE would collapse under the deluge. And if they just threw the paperwork out, a consistent policy by those distributors of counter-suing if SoundExchange took any action (and possibly by artists of suing for interference if SoundExchange shut down a distributor of their work) would likely ruin SE as soon as the judgements started coming in.
California's position, unfortunately for the company, is that if the position is in California then California law applies. I believe the logic is that, since this is an issue of law applying to everyone working in California, the governing-law clause simply isn't relevant. I believe your case has happened before, and the CA courts simply ruled that, since the judgement has no basis in law, it can't be enforced in CA. It can, however, cause you problems if you want to go to work outside CA later.
If it's a California-based company, the relevant law is California Labor Code 2870-2872. Those sections put limits on the extent to which that IP agreement is legal. Any attempt by the agreement to exceed those limits is illegal and void as a matter of law according to 2870(b). The employer is also required to give you, in writing per 2872, a notice that any language in the agreement does not apply to inventions which meet 2870's criteria.
Note that California's position is that, since these are law, the fact that an employee agreed to them does not provide an out for the employer. Just to be safe, however, when I had to sign those papers I wrote in a term saying that the agreement was subject to the limitations of those two laws before I signed.
The EU doesn't in fact have a constitution in the sense the US does. It has the treaties that created it, but no supreme law to which it's subordinate. There was supposed to be a vote on a European Constitution (which despite the name still wouldn't have been completely equivalent to the US Constitution) but the French and Dutch rejected it which derailed the entire ratification process and it's future's now in considerable doubt.
European politics and the EU's political/legislative process isn't much like the US's at all. Microsoft's in the trouble they're in there because they failed to grasp that and play by the local rules.
At what point has/will the EU overstepped its bounds?
The EU is a government. They will have overstepped their bounds when their constituents say they've overstepped their bounds. Note that Microsoft is not one of those constituents, nor are any Americans or American companies. This is a concept Microsoft and it's supporters seem to be having a problem getting their heads around.
Not quite. The "attractive nuisance" thing comes from, for example, someone putting in a deep swimming pool and leaving it unfenced and unattended when their neighborhood's full of young children. The pool owner knows the children are there, and that it's dangerous for them to be playing around the pool with no adults there. He knows that without the fence they will get into the pool. So a fence to keep them out would be a reasonable precaution. By not putting one in, he's opening himself up to liability including possible negligent homocide (not murder) charges if the DA decides to push it.
The difference between that and leaving your door unlocked is a bit subtle, but basically it's that the law isn't going to put responsibility on you for someone else breaking into your house. The door, even unlocked, represents enough of a barrier that an ordinary law-abiding person wouldn't be expected to be inside without permission. In the case of a WAP, the distinction would probably be between a completely open one and one where any sort of authentication was enabled (even the rather feeble WEP).
I'm not surprised. I'm sure one of the things the court considered is that someone who knows enough about wireless to raise the "open access point" defense also knows enough to know the risks of an open WAP and to do something about it if only to protect themselves from exactly this sort of problem. And with the amount of publicity, even the average Joe by this point knows the risks of open WAPs. So I'm not surprised the judge essentially said "You knew it was open, you knew what the risks were, you didn't do anything about them. You're responsible for it.". Can you say "attractive nuisance"? Similar deal with probable cause, if the abuse of open WAPs is wide-spread enough for defendant's argument to be even someone probable then it's wide-spread enough that police can treat open WAPs as a known problem.
And of course, if someone were using the WAP then the CDs wouldn't have been in his room. He might be able to make the argument that, given the IM name especially, the CDs belong to his roommate, but it looks like his attempt to get fancy scuttled that option.
Expand or change the internal netblock. The 192.168.0.0/24 netblock that's normal for home routers isn't writ in stone. Corporate networks usually use the 10.0.0.0/8 reserved block instead, allowing for 16 million internal machines. You can also use the entire 256-network range of the 192.168.0.0/16 reserved block (256 contiguous/24 networks), allowing for 64K machines within it, but generally if you're going to do that you just use a/16 network from the 172.16.0.0/12 block (16 contiguous/16 networks) instead. Commercial-grade routers will let you use all networks from all the reserved blocks at the same time if you really really want to, but I'd start to question the sanity of whoever designed that network.
Most people aren't running connections continuously. Web browsing in particular uses ports on a very short-term basis. The hardware also handles the problem to a degree, either delaying until a port's available or simply rejecting the attempt and letting the browser handle it. To users this appears as just normal slow-downs and errors. Errors in particular people tend to ignore. How often have you seen the broken-image link on a page and thought "Oh, another glitch." and paid it no more mind? As ad-laden as a lot of commercial web-site pages are, errors mostly tend to be in advertising images or scripts and the breakage doesn't affect anything the user cares about. They literally won't notice there's a problem.
Unfortunately IP address doesn't work. NAT can put anywhere from a couple (small home network) to thousands (corporate networks) of individual machines behind a single IP address. The common ISP practice of using dynamic addresses can result in a single machine having anywhere from one address for years at a time to a different address every hour. Most web-statistics companies have abandoned IP addresses as a valid identifier.
Most of them do in fact rely on cookies of one sort or another. Most rely on browser cookies, a few are using Flash or media-player cookies. All of them suffer from the fact that cookie deletion or filtering in the browser corrupts the statistics. Blocking of cookies completely is the easiest form to deal with, the server-side code can check whether cookies were in fact set and simply discard data from browsers that don't accept cookies. Cookie deletion, or forcing cookies to have session lifetimes, is harder to deal with since to the server it looks like the cookies are good but in reality they can't provide information about visitors, only sessions. The worst are one-shot cookies, where the browser will let a new cookie be set but then won't permit it to be modified or removed. The big problem with them is that any test will overlap to some degree with normal cookie behavior, so you end up having to balance how much corruption you're getting relative to how much good data you're throwing out by mistake.
Most web-statistics firms are working to avoid the worst of the problems by moving their machines into the DNS namespace of the sites they're collecting statistics on. That helps get around third-party cookie behavior in browsers, and should work until browsers either start having extensive host-specific block lists or start allowing cookie filtering based on IP address instead of URL hostname.
I always considered the intricacies an interesting puzzle, and wringing every bit of validity possible out of the system a challenge. Management, unfortunately, doesn't want to hear about the intricaties, they just want to hear that there's no problems, everything's fine and the numbers they're giving their customers are perfect. Customers, even more unfortunately, don't want to hear about any problems, they just want to hear that the numbers they're getting are perfect. Sooner or later the cluebat will get applied.
Yes, but with the data stored on the business' computers there's a direct contractual relationship between the business and that disgruntled employee. The business can, in court, hold up a contract between them and the employee with specific terms prohibiting what the employee did, which is the basic thing you need to hold the employee liable and recover damages (in theory anyway, in practice the employee doesn't have that much money and all you can do is make an example of him). And if the business doesn't have appropriate contracts in place, it can put them in place.
By contrast, when the data's stored remotely under the control of another company, there's no direct contract between the business and the person selling the data. The contract's only between the business and the company controlling the data (who had nothing to do with the sale, or at least nothing that the business can prove in court), and they're going to raise as defenses that they had no idea the employee was selling the data and that he was breaching his agreements with them and that they shouldn't be held liable because someone other than them breached an agreement. The business may or may not recover damages, but even if they do it's going to be a lot messier and more expensive because of the indirection.
Slashdot Mirror
SOE learned from SWG:NGE, yes. But they didn't create that mess. If you look at the deal between SOE and LucasArts that resulted in SWG, you find that SOE has no control over the game itself. LucasArts controls game mechanics, artwork creation, content creation, customer-service policies, in-game rules and just about every other aspect of the game. NGE was Lucas' idea, SOE was violently against it but they've no say over that aspect of the game. Essentially they're contractors, providing coders, CS bodies and server hosting to LucasArts and following orders about how Lucas wants the game to be. The blame for NGE rests squarely on Lucas' shoulders. The basic problem seems to be that LucasArts views SWG as nothing more than a nice merchandising tie-in opportunity and occasional source of interesting artwork. The idea that there's people who like the game itself, as opposed to fans of the movies looking for more SW-related material, doesn't seem to have registered.
SOE's attitude internally, BTW, seems to be very much "Never again.".
My first thoughts: How many of those licenses represent Vista licenses bought to run XP on corporate systems only because the corporate contracts don't let them buy XP licenses but do allow downgrading a Vista license to XP? And how many represent bunching of the sale of an entire year's worth of licenses to companies like Dell and HP into the first quarter to make the numbers look good?
Objection. So far MS hasn't actually specified any patents which they claim are infringed. They've given numbers, but they've declined to say which patents are on the list. I think I'll have to borrow the phrasing from IBM's very first few interrogatories to SCO: Please identify with specificity which patents held by Microsoft are alleged to be infringed, and which code (by software project, file, version and line) is alleged to infringe upon those patents.
Despite their accusations of infringement, they state they would rather do licensing deals instead of any legal action.
A prerequisite for licensing is to identify exactly what the licensee will be paying for a license to. Until MS places that on the table, why should I pay good money for a pig in a poke?
A security hole is a bug, plain and simple. There's no excuse for deliberately not fixing a bug. Now, you can make an argument that if the bug's minor and not causing customer problems you should hold the fix for the next regularly-scheduled release, but that's about it. The argument that unannounced holes don't seem to be being exploited is particularly disingenuous. People aren't looking for exploits of holes they don't know about. It's not surprising, then, that few people are reporting problems they aren't looking for. What's more likely is that the small subset of crackers who can find unannounced holes are quietly using them for their own gain, keeping a low profile specifically to avoid having customers raising a stink and forcing the vendor to close the hole, and only after it finally goes public do they release their secret to the wider script-kiddie population since it's no longer of use to them.
Except that using HKCU has another problem: many programs register stuff they need in the registry. On a single-user system HKCU isn't a problem. But when another user tries to use that installed program, BAM, none of the required registry entries are in their HKCU tree. Which means developers have to develop another set of practices as well: either writing programs that can self-register themselves and set up all the neccesary registry entries on their own independently of the installer (at which point the need for an installer goes away), or the installer has to set up the system-wide stuff in HKLM (which requires privileges for the installer) and then the program reads first HKLM and then HKCU for entries but only writes changes back to HKCU. Unix already has a well-developed set of practices for this, but Windows developers are going to have to learn from scratch.
Frankly I disagree with part of the quoted comment in this entry. These problems are the developers' fault. But not developers in general, only Windows developers. They've lived in their own world, ignoring everything that everybody else had learned or was learning about multi-user systems and writing programs for them, and now it's coming back to bite them. Microsoft didn't help by catering to them for so long, but ultimately it's the developers who decided not to learn from everybody else's experience and went along with the recommendations of a company with no experience in a multi-user system.
But, as part of posting a take-down notice, you must state, under penalty of perjury, that you are the owner of the material in question, or an authorized representative of the owner.
Actually that's not the case. If you read USC Title 17 512(c)(3)(A) which describes the elements of a notification, you do not have to declare under penalty of perjury that you are (or are acting for) the owner of the copyright. The "under penalty of perjury" part only applies to your declaration that you're authorized to act on behalf of the party alleging a copyright has been infringed. The part where you declare that it's your material (or belongs to whoever you're acting for) is merely upon good faith.
Except that in 1999 the problem had been long since solved. Back in the late 80s when I was in college, DEC introduced this revolutionary concept: that data file storage formats be seperate from the application. So on VMS they decreed that RTF should be the standard document format. Any word processing program running on VMS should be able to read and write RTF properly, according to the specification, and interpret the formatting in a sane way. The obvious consequence of this being done properly is that I don't care what application the other person is using. If it follows the spec, and my application follows the spec, then we can talk just fine regardless of whether we're using the same application or not. The only requirement placed on the RTF specification was that it had to concentrate on representing the document, not specific details of any particular application.
If we could do this 20 years ago, what's so blasted hard about it today?
Why were those students even able to use proxies? All traffic should be going through a commercial-grade router. A few rules and all TCP 80/443 traffic will be going to the designated filtering system and outbound connects on any other ports will be getting only an "administratively prohibited" ICMP error. Once that's done it doesn't matter what the students do on the client side.
Yes, I know the downsides, but if you want a secure filtering system you can't trust the client end to behave. If you could, you wouldn't need a filtering system.
True on the first, but on Unix systems you typically don't get those password dialogs every time you want to do something. You get them once when you go to start a program that'll need privileges. So users don't get trained by excessive, repetitive prompting to type their password in all the time.
And no, Joe User probably won't do the clean-up. His friendly neighborhood geek will be doing it, and will appreciate not having to reformat and reinstall the entire box to make sure it's clean.
And Unix does extend least-privilege to everything. The default for any application is to run as the current ordinary user. Anything beyond that requires some special action to grant privileges, usually through a wrapper in a GUI environment (the same way the Gnome and KDE desktops handle system programs that need root privileges, their wrapper can be used for anything that needs it). Start-up programs (services) are the same: almost all of them that need root initially drop it as soon as they're done (ie. Apache), and many of them don't need root privileges at all (eg. Postgres) and are run directly as their ordinary user by their startup script (su isn't just for changing to root, after all).
Actually half the purpose of ordinary user accounts being the default is to protect the system from the user. That's why admins routinely work out of ordinary accounts and reserve root for special occasions: as an ordinary user going to type "rm -rf ./*" and accidentally getting "rm -rf /*" is recoverable, as root it wouldn't be.
There's also another layer of protection. Even if your ordinary user account gets owned, the system files that the root account depends on can't be altered by the malware. Since those system files and tools can't be infected, you can clean up an infection by logging in as root rather than the infected user and be sure that (modulo a local privilege-escalation vulnerability already having been exploited) your tools won't have been infected too. This makes recovery much easier.
There's a third layer too: humans aren't the only users. Every service on a Unix system is also a user. Since those services typically run as ordinary non-privileged users just like everyone else, vulnerabilities in those services are less critical. If the service is remotely accessible an outsider can crack it, but they don't get any more privilege than an ordinary user (and not even enough privilege to nail the human user's files directly). This limits the amount of damage that can be done.
First rule of security: layers. Design to prevent intrusion. Then design to minimize the damage when an intrusion occurs (note: when, not if). Then design to make clean-up as simple as possible after the damage is done.
I think what Google looks for to identify "link farms" is a cluster of tightly-related circular links. That is, a relatively small set of sites that all link heavily to each other (as opposed to linking outside the cluster). So, if you're site A, having a link-farm site B link heavily to you doesn't hurt. But if you in turn link heavily back to site B, then you're going to get dinged. Now, from what I've seen, one or two links back won't hurt. Link-farm sites tend to have a much higher percentage of links pointed at other sites in the farm than a normal page would have, and Google's looking for that threshold being crossed more than just the existence of a single link.
If you visualize each page as a point in 3-space and inks as lines connecting them, link farms look like "knots" or tangles with a much higher link density than the surrounding Web. Google's looking for that tangled appearance.Yes, but remember that Google's product has one unique trait: it has legs. Google's product, people running searches, want to find relevant results. Relevant by their criteria, not by the criteria of the sites being found or those buying ads. If they don't get relevant results, they'll stop using Google and then what's Google going to sell? So Google does have to consider the desires of it's product when making decisions. In fact, it has to give it's product more weight than it gives any one customer. If it doesn't, it won't have a product to sell.
I think the article gives a great big hint why Skyfacet ended up on the supplemental index. First the article says "Google's programmers appear to have created the supplemental index with the best intentions. It's designed to lighten the workload of Google's "spider," the algorithm that constantly combs and categorizes the Web's pages. Google uses the index as a holding pen for pages it deems to be of low quality or designed to appear artificially high in search results.". Then it goes on later to say "In retrospect, Sanar thinks he can trace his problem to a search marketing consultant he had paid $35,000 to improve Skyfacet's Google rankings. He now believes the consultant mistakenly replicated content on many of the site's pages, making them look like duplicate--that is, spam--content.". So, basically, the site owner paid an SEO type to try to game Google's system, Google saw it and dropped his site in the trash along with the rest of the bogus sites, and now he's wondering how to get out of the trash. Well, I guess he'll just have to abandon attempts to game the system and wait until Google re-spiders his site and sees it's no longer playing tricks. Yes, that might take a while. That's the price you pay for trying to get cute and getting caught at it.
I believe other posters have indicated that many independent labels and artists are already setting up direct deals with Internet broadcasters. It's the only way to get around the RIAA/SoundExchange bureaucracy and avoid the nasty DRM the RIAA insists on. I think you've got the database thing the wrong way around, though. Yeah, SE probably has a very good database for tracking what they need to collect royalties on. The DDoS would be on the system for keeping track of the exceptions, the things they aren't allowed to collect royalties on. Up until the Internet they really didn't need a complex system, since any exceptions were probably a label (or possibly all the labels) making a blanket deal with a station for a reduced royalty rate and the labels had SE still handling the actual collection. A database set up based on that is likely to break down completely when, instead of no more than half-a-dozen deals for a station, they've got to keep track of hundreds of deals for each station, SE receives no membership fees to cover the expense since the artists aren't SE members, and they still have to keep track of what the station plays that isn't covered by those deals so they can collect the normal automatic royalties too. It's the difference between batching up tens of thousands of transactions into a single daily run vs. actually handling tens of thousands of individual transactions in real-time: a system optimized for the first is just going to die trying to attempt the second.
Note that the article, and some of the implications SoundExchange tries to slide through, are somewhat misleading. SoundExchange is merely the Copyright Office's ordained agency for collecting mechanical-license royalties. Yes, if you want to make use of mechanical licenses through that particular distribution channel, you do indeed have to go through SoundExchange. The RIAA had a big hand in the selection, but it's the Copyright Office that actually has the final say there. And remember that this was set up back when 99% of all music in fact went through the labels. But SoundExchange is not allowed to collect all royalties. If an artist or a label has a direct, non-mechanical license agreement in place with a distributor or venue, SoundExchange may not collect royalties from that distributor/venue. Their purvue is mechanical-license royalties only. The artist or the distributor/venue has to inform SoundExchange of the agreement, but once that's done the distributor can tell SE to go pound sand as far as royalties for that artist go. Caveat: both the artist and the distributor/venue should keep legally-admissable evidence of their informing SE, and have a copy on hand to give to any SE guys who show up (make them sign for it, too), so you've a paper trail if SE decides to push.
Now, this does provide an interesting DDoS against SoundExchange. I guarantee you they are not set up to handle thousands of distributors and venues each with independent, not-neccesarily-identical agreements with many artists. They're set up to handle 99% mechanical licenses, with the few exceptions being almost entirely distributors or venues whose agreements cover entire labels. If every artist and venue and on-line distributor with a direct agreement actually filed the paperwork they're by law allowed and required to file with SoundExchange, I suspect SE would collapse under the deluge. And if they just threw the paperwork out, a consistent policy by those distributors of counter-suing if SoundExchange took any action (and possibly by artists of suing for interference if SoundExchange shut down a distributor of their work) would likely ruin SE as soon as the judgements started coming in.
California's position, unfortunately for the company, is that if the position is in California then California law applies. I believe the logic is that, since this is an issue of law applying to everyone working in California, the governing-law clause simply isn't relevant. I believe your case has happened before, and the CA courts simply ruled that, since the judgement has no basis in law, it can't be enforced in CA. It can, however, cause you problems if you want to go to work outside CA later.
If it's a California-based company, the relevant law is California Labor Code 2870-2872. Those sections put limits on the extent to which that IP agreement is legal. Any attempt by the agreement to exceed those limits is illegal and void as a matter of law according to 2870(b). The employer is also required to give you, in writing per 2872, a notice that any language in the agreement does not apply to inventions which meet 2870's criteria.
California Business and Professional Code section 16600 is also relevant to the oh-so-common non-compete clauses.
Note that California's position is that, since these are law, the fact that an employee agreed to them does not provide an out for the employer. Just to be safe, however, when I had to sign those papers I wrote in a term saying that the agreement was subject to the limitations of those two laws before I signed.
The EU doesn't in fact have a constitution in the sense the US does. It has the treaties that created it, but no supreme law to which it's subordinate. There was supposed to be a vote on a European Constitution (which despite the name still wouldn't have been completely equivalent to the US Constitution) but the French and Dutch rejected it which derailed the entire ratification process and it's future's now in considerable doubt.
European politics and the EU's political/legislative process isn't much like the US's at all. Microsoft's in the trouble they're in there because they failed to grasp that and play by the local rules.
At what point has/will the EU overstepped its bounds?
The EU is a government. They will have overstepped their bounds when their constituents say they've overstepped their bounds. Note that Microsoft is not one of those constituents, nor are any Americans or American companies. This is a concept Microsoft and it's supporters seem to be having a problem getting their heads around.
Not quite. The "attractive nuisance" thing comes from, for example, someone putting in a deep swimming pool and leaving it unfenced and unattended when their neighborhood's full of young children. The pool owner knows the children are there, and that it's dangerous for them to be playing around the pool with no adults there. He knows that without the fence they will get into the pool. So a fence to keep them out would be a reasonable precaution. By not putting one in, he's opening himself up to liability including possible negligent homocide (not murder) charges if the DA decides to push it.
The difference between that and leaving your door unlocked is a bit subtle, but basically it's that the law isn't going to put responsibility on you for someone else breaking into your house. The door, even unlocked, represents enough of a barrier that an ordinary law-abiding person wouldn't be expected to be inside without permission. In the case of a WAP, the distinction would probably be between a completely open one and one where any sort of authentication was enabled (even the rather feeble WEP).
I'm not surprised. I'm sure one of the things the court considered is that someone who knows enough about wireless to raise the "open access point" defense also knows enough to know the risks of an open WAP and to do something about it if only to protect themselves from exactly this sort of problem. And with the amount of publicity, even the average Joe by this point knows the risks of open WAPs. So I'm not surprised the judge essentially said "You knew it was open, you knew what the risks were, you didn't do anything about them. You're responsible for it.". Can you say "attractive nuisance"? Similar deal with probable cause, if the abuse of open WAPs is wide-spread enough for defendant's argument to be even someone probable then it's wide-spread enough that police can treat open WAPs as a known problem.
And of course, if someone were using the WAP then the CDs wouldn't have been in his room. He might be able to make the argument that, given the IM name especially, the CDs belong to his roommate, but it looks like his attempt to get fancy scuttled that option.
Expand or change the internal netblock. The 192.168.0.0/24 netblock that's normal for home routers isn't writ in stone. Corporate networks usually use the 10.0.0.0/8 reserved block instead, allowing for 16 million internal machines. You can also use the entire 256-network range of the 192.168.0.0/16 reserved block (256 contiguous /24 networks), allowing for 64K machines within it, but generally if you're going to do that you just use a /16 network from the 172.16.0.0/12 block (16 contiguous /16 networks) instead. Commercial-grade routers will let you use all networks from all the reserved blocks at the same time if you really really want to, but I'd start to question the sanity of whoever designed that network.
Most people aren't running connections continuously. Web browsing in particular uses ports on a very short-term basis. The hardware also handles the problem to a degree, either delaying until a port's available or simply rejecting the attempt and letting the browser handle it. To users this appears as just normal slow-downs and errors. Errors in particular people tend to ignore. How often have you seen the broken-image link on a page and thought "Oh, another glitch." and paid it no more mind? As ad-laden as a lot of commercial web-site pages are, errors mostly tend to be in advertising images or scripts and the breakage doesn't affect anything the user cares about. They literally won't notice there's a problem.
Unfortunately IP address doesn't work. NAT can put anywhere from a couple (small home network) to thousands (corporate networks) of individual machines behind a single IP address. The common ISP practice of using dynamic addresses can result in a single machine having anywhere from one address for years at a time to a different address every hour. Most web-statistics companies have abandoned IP addresses as a valid identifier.
Most of them do in fact rely on cookies of one sort or another. Most rely on browser cookies, a few are using Flash or media-player cookies. All of them suffer from the fact that cookie deletion or filtering in the browser corrupts the statistics. Blocking of cookies completely is the easiest form to deal with, the server-side code can check whether cookies were in fact set and simply discard data from browsers that don't accept cookies. Cookie deletion, or forcing cookies to have session lifetimes, is harder to deal with since to the server it looks like the cookies are good but in reality they can't provide information about visitors, only sessions. The worst are one-shot cookies, where the browser will let a new cookie be set but then won't permit it to be modified or removed. The big problem with them is that any test will overlap to some degree with normal cookie behavior, so you end up having to balance how much corruption you're getting relative to how much good data you're throwing out by mistake.
Most web-statistics firms are working to avoid the worst of the problems by moving their machines into the DNS namespace of the sites they're collecting statistics on. That helps get around third-party cookie behavior in browsers, and should work until browsers either start having extensive host-specific block lists or start allowing cookie filtering based on IP address instead of URL hostname.
I always considered the intricacies an interesting puzzle, and wringing every bit of validity possible out of the system a challenge. Management, unfortunately, doesn't want to hear about the intricaties, they just want to hear that there's no problems, everything's fine and the numbers they're giving their customers are perfect. Customers, even more unfortunately, don't want to hear about any problems, they just want to hear that the numbers they're getting are perfect. Sooner or later the cluebat will get applied.
Yes, but with the data stored on the business' computers there's a direct contractual relationship between the business and that disgruntled employee. The business can, in court, hold up a contract between them and the employee with specific terms prohibiting what the employee did, which is the basic thing you need to hold the employee liable and recover damages (in theory anyway, in practice the employee doesn't have that much money and all you can do is make an example of him). And if the business doesn't have appropriate contracts in place, it can put them in place.
By contrast, when the data's stored remotely under the control of another company, there's no direct contract between the business and the person selling the data. The contract's only between the business and the company controlling the data (who had nothing to do with the sale, or at least nothing that the business can prove in court), and they're going to raise as defenses that they had no idea the employee was selling the data and that he was breaching his agreements with them and that they shouldn't be held liable because someone other than them breached an agreement. The business may or may not recover damages, but even if they do it's going to be a lot messier and more expensive because of the indirection.