My normal environment's Linux (Debian). Yes, most programs when run through the menu will, if they require root privileges, ask for permission to elevate. Those programs, though, are primarily system-administration tools. If I try to fire up the program to update my packages or change my e-mail server configuration, I'm going to get an "enter root password" prompt. If I fire up my e-mail client, or my word processor, or a game, I will not get that prompt even if the program needs root to do it's job. I'll get error messages from the application saying it can't write to files or whatever it failed to have privileges for, but the OS and the desktop won't say a word, nor will they hand out privileges unasked-for (that prompt actually comes not from the app or the OS but from a wrapper program the packagers use when creating the icons and menu items for selected apps that the user should be able to run with root privileges).
The problem is that no, in 5-10 years programs will still need UAC. Because if it's as easy as it is to turn off UAC, app vendors will just tell users to turn it off. Fixing their apps costs them money, having users disable the thing that's causing all those pop-ups doesn't. Which do you think the app vendors will pick?
Short-term, enforcing the rules will break a lot of things. But the rules have been published for at least 10 years now and vendors haven't voluntarily complied with them. Conformance is going to have to be non-voluntary, then, and the failure is going to have to be pinned solidly and clearly on the app, not Windows. And in the long term, compliance with the rules will make life a lot easier for everybody.
The basic idea's sound. The problem is that, given the implementation, users view the problem as being UAC and/or Vista, not the apps. After all, the apps work just fine if you turn those annoying dialogs off or go back to XP. If the users don't view the app as the cause of the problem, they won't pressure the app vendor to do anything about it. Idea fails.
I prefer the Unix approach. The OS doesn't pop up any dialog, or offer the user any choice. If an app does something it doesn't have privileges for, it gets an ENOPRIV returned from that call and isn't allowed to do that. How the app handles it from there is up to the app, but there's no easy way to make the errors go away at the system level (most modern Unixes are set up to make it inconvenient to log in or run programs as root, and only root can install a program setuid-root).
Yes. Your registrar submits the master NS records that tell the world where the nameservers for your domain are. So, for example, for example.com there are NS records in the "com" zone that identify the authoritative nameservers for example.com. If your registrar sends an update changing those NS records to identify their nameservers instead of yours, they gain control over name resolution for your domain. A sneaky registrar could have nameservers that, when they get a query, do a query to the nameservers you gave them. If they get a record back, they pass it along as their response. If they get a "does not exist" response from your servers, they send the A record of their parking server back. You might never notice them doing this.
NB: the above is one reason I occasionally do a dig query and check all the records and delegation information for my domains, as well as doing whois queries to check the public view of my domain registration information.
True, but the doors aren't gone. That's where you go astray, trying to eliminate one door from the probability calculation when it's still there. You have three doors to choose from, there's only one car, you have a 1/3rd chance of choosing the correct door and a 2/3rds chance of choosing the wrong one. When Monty opens a door, you still have a 1/3rd chance of having the correct door and a 2/3rds chance of having the wrong one, but that 2/3rds chance is now concentrated behind one door because Monty can't open the door with the car behind it.
Your calculation only works if Monty opens his door before you choose yours, or if you discard your first choice and choose at random after Monty opens a door. The point of the excercise, though, is that you don't have to discard your initial choice and choose at random. Monty knows something you don't, and you can deduce from his actions and the rules what it is that he knows. And that skews the probabilities away from the 50:50 of random choice.
Start with the initial case: you choose from 3 doors, 1 of which has a car and 2 of which have goats behind them. Now, suppose Monty just opens all the doors on the spot, revealing whether you won or not. What's the probability that you chose the car? 1/3rd. It has to be, only 1 door out of three had the car.
Next step, you make the same choice. Monty opens a door but doesn't give you the option of changing your selection. Now, what's the probability of your winning? You made the same choice you did in the previous scenario. Monty's opening of his door has no effect on the outcome or the probabilities. So your probability of winning the car has to still be 1/3rd.
Final step, you make your choice and Monty opens his door, but now he offers you the chance to change your selection. Before you decide, your situation is exactly the same as in the previous scenario. That means your probability of winning has to be the same, 1/3rd. But since Monty showed you one door with a goat behind it, so there's only one door left. Since the total probability has to be 1, the probability that that door is the one with the car behind it is 1 minus 1/3, or 2/3rds.
Because your initial probability of picking the car isn't 50/50, it's 2:1 against the car. You choose from 3 doors, remember, not 2. So initially the probability is 1/3rd that you've chosen the car, 2/3rds that the car is behind one of the doors you haven't chosen. Then Monty opens one of the doors you haven't chosen. He's constrained to open a door with a goat behind it, but the fact that he's opened a door doesn't change the initial probabilities. So the probabilities remain 1/3rd that you've chosen the car, 2/3rds that the car's behind one of the other doors. Monty's helpfully told you which door the car isn't behind, so the 2/3rds-chance door must be the one neither you nor Monty has chosen.
I think it's actually that counting is easy, and people know it. But verifying the count is hard, and people know that too. And the advocates for the voting machines, and the companies that make them, have all been incredibly vehement in their opposition to any form of audit trail. And that immediately makes most people suspicious.
The audit trail itself turns out to be a non-computer problem. It has to be, because the definition of an audit trail is a check against something independent of what you're auditing (in this case, the machine's count). You can't, for example, audit a hotel clerk's tally of rooms sold and revenue taken in by looking only at his transaction sheet. You have to check against something else. In the days of physical room keys, that's what we checked against. Every room had a known number of keys, and the clerks didn't have access to the spares, so every room's key slot should have 3 keys in it minus the number of guests recorded on the room register. A clerk could give someone a room, not record it on the register and pocket the money, but he'd still have to give that someone a key. When I did the audit his transaction sheet and cash bag would all balance but I'd find a room short a key with no explanation. The same independent audit trail is needed with a voting machine: something you can check the machine's count against without having to assume anything about the counts reported by the machine (the memory cards used to hold the count are considered part of "the machine", since their content is completely under it's control). And that pretty much precludes any electronic count being used for the audit.
I'd note that I don't expect these roadblocks to the RIAA getting student's identities to hold forever. It simply isn't permissible in the US legal system to prevent a plaintiff with a legitimate claim from discovering the identity of the person they have that claim against. The best the students can hope for in the long run is to require the RIAA to prove that the IP address and client they have a record of did in fact commit copyright infringement. That's probably a significant hurdle, but if the RIAA clears it then the students will not be able to block discovery of their identities.
I don't think the case'll turn on whether taking notes is fair use as on whether or not the student's notes constituted a copy of a protected work. Facts, remember, can't be copyrighted. I can write down stock market quotes and republish them in my own format all day and the source I get them from can't (absent some contract with me) touch me. The prices are facts, not expression. I can't copy their layout and formatting, but the numbers themselves are fine. So the question would be, are a student's notes recording, in their own words with their own formatting and layout having nothing to do with the professor's written lecture papers, the lecture a copy of the professor's work, as opposed to a wholy new work embodying the facts the professor used in his work? I think the simple analogy should convince the judge: "Is a movie review, summarizing the movie in the reviewer's own words and without copying any footage or exact lines from the movie itself, a copy of the movie?". The likely answer to that question is "No.", and the same for the notes.
This is normal for hardware makers. It's cheaper to set up one production line than two, and to produce one model of board instead of two. If you price the high-end models so that sales pay for the fixed cost of the production line plus the cost of producing those units then you can price the low-end models based only on the marginal cost of running off X more units on a paid-for line, sell them to the people who wouldn't pay the price of the high-end unit and make more profit than just selling the high-end units alone.
Sometimes it can work to the consumer's advantage too. Back before they were bought by 3Com, NetGear was the consumer label of Bay Networks. That NetGear consumer-grade switch you bought was really a full-on Bay Networks unmanaged professional-grade switch with a different silk-screen job on the case.
It's a problem for Creative because often they use identical hardware for multiple sound cards, with the drivers determining which features are active. For instance, they may sell the UltiSound Basic with 5.1 surround for $150, and the UltiSound Extreme with 7.1 and Dolby output for $300. If you look carefully at the cards, they're absolutely 100% hardware-identical. Even the jacks are identical and wired up the same. In other words, the UltiSound Basic is quite capable of outputting 7.1 and Dolby just like the Extreme. The only difference is in a small EPROM chip with the model ID in it. The driver reads that and uses the model ID to decide which firmware to load into the card, and it won't load the 7.1/Dolby-capable firmware into a card with a Basic model ID. If someone hacks the drivers to change the check, then Creative finds their Extreme card not selling very well since everybody's buying the Basic and turning on the high-end features.
They also tend to deprecate their low-end cards on new versions of Windows, forcing people to buy upgraded hardware if they want to upgrade their OS. If hacked drivers allow people to keep using their older hardware, Creative loses sales.
Yes, both tactics are stupid. But to Creative hacked drivers are a threat to a business model based on those tactics. They just discovered here that the PR backlash may be a bigger threat.
Well, it's well-known that cars are used by criminals to flee the scene of a crime. It's also well-known that if I leave a car on the street it could be stolen, especially if I don't lock it. So if I park my car on the street in front of my house and forget to lock the passenger-side door, and someone steals it and uses it to get away after robbing a bank, did I buy that car for the sole purpose of robbing a bank? It's theoretically possible, if I can be shown to be in cahoots with the robber, but the police haven't shown I even knew a robbery had happened let alone that I knew the robber that well.
Actually in both the third and fourth cases they'll have a hard time coming after you. If the table's out next to the sidewalk they may have an easier time, but if the table's up on your porch and you keep books on it to read then even if people come onto your property and take the books the RIAA would have to show that you intended people to take those books, as opposed to intending to have them there for your own use and outsiders abused that while you were gone and didn't know about it happening. That's what the judge's words about "offer" are aimed at. In fact, his ruling eliminates the need for the RIAA to prove actual downloading, it hinges the entire ability to sue on showing either intent or willful recklessness. The RIAA now has to prove that either the defendants put the files there with the intent that others download them or that, at the very least, the defendants knew or reasonably should have known those files would be available to others and failed to take any steps to prevent that. The first is a real tough nut absent a confession from the defendants, and the second, well, it's really easy to argue that the defendants never were exposed to any hint that this software even could make the files available and had no reason to believe it'd allow others to download from them and it'll be real hard for the RIAA to prove these people are tech-savvy enough that they had to have known all about how P2P works.
Not neccesarily. The key phrase is "knew or reasonably should have known". If there's a warning about something in the manual, a reasonable user's expected to have read the manual and so reasonably should have known about the danger. But when there's no apparent mention of something, things become more subjective. The question is usually "What would a reasonable ordinary person know about this?". Now, as a techie I'll know about the upload function of P2P software. But someone who's not an IT professional, doesn't deal with this software every day, what would give them any reason to believe the software would upload what was downloaded? That's the question the court would (or should) ask. If you go through everything the user would've had available and nothing anywhere would hint at the upload functionality, and they don't have contacts in circles where that sort of thing would be regularly discussed, then how would they reasonably be expected to find out about it?
And most P2P software doesn't necessarily require positive action by the user to share downloaded files again. Much of it defaults to sharing unless and until the user turns sharing off. And if the user doesn't know there is a sharing function, why should they know to turn it off?
It's kind of like trespassing. If there's a solid fence with lots of "No trespassing" signs on it, you'll have an easy time nailing anyone you find on the wrong side of the fence. But if there's no fence, no signs, no indication whatsoever of a boundary, and this is the first time that person's been caught on the property, you'll have a hard time getting them convicted of trespassing. And if for the last 50 years everybody's been going across that property with no problems and no objections from the owner, the new owner's going to find it all but impossible to get trespassing charges upheld until after he puts up a fence and posts the property.
Except that that happening by default would undermine the argument. If the software's always discussed in terms of downloading, there's no obvious mention of it uploading and the upload function is enabled by default and doesn't require user intervention to turn it on, then why should a naive, non-technically-savvy user expect that his download software is actually uploading behind his back?
All that's needed is to acknowledge a distinction between what should be and what is. People should know what their equipment's doing, and set it to only do what they want it doing. So in a perfect world, people would secure their wireless routers unless they intended anyone to access them, and people would configure their file-sharing software to not share any files unless they intended to share those files.
But we don't live in a perfect world. Users take the default settings on their shiny-new wireless router because they don't know there's anything to change and, after all, it works just fine so they've no reason to think there's anything more needed. And other users take the default behavior of their wireless card and drivers, and when those drivers connect somewhere and don't give any indication there's any problem the user has no reason to think he's not allowed to connect there. After all, in his view, if whatever he connected to wasn't intended to be open to the public surely it'd've prompted for login information or something, no? The confluence of two naive users results in something happening that neither intended to happen, that neither realized was going to happen. Neither's required to know enough to know better, and until they are required to know enough they can't really be held responsible for not knowing.
Were it me, I'd simply make the manufacturers liable for the default settings on their devices, since they certainly know enough to know what the implications of any settings are. They can set them however they want, but they're on the hook for the consequences. My prediction is that instantly all new wireless gear would default to "no access without a key" and require the user to select a key before the device would work, and you've have to dig around to find the setting to allow access without authentication. End of problem.
That depends. That's the default behavior unless you go and deliberately modify the client's settings. So if I go to a tracker to get say a Linux distribution, treating a BitTorrent client like a fancy FTP program purely for download, I'm going to offer up chunks of what I'm downloading unless I'm technically savvy enough to know this is happening and change the default behavior. If I'm not technically savvy, I probably won't even realize this is happening. And there's the trick of it: if I put something down on a table in my front yard while I go inside and get a drink, not realizing someone will come along and take it, have I made an offer to that someone to distribute what I've left laying there?
The RIAA's undoubtably going to argue that the defendant's P2P software made the file available and that that constitutes the offer of distribution. The trick will be to neuter this argument, and that's going to have to turn on intent. If, for example, I have a table of books in my front yard with a sign saying "Take some", that's clearly an offer to distribute. But if I put a book down on the table on my front porch while I go inside to get something to drink, and while I'm gone someone comes along and takes the book, the book's arguably been distributed but I clearly haven't made any offer to distribute, the book was merely stolen. The argument's going to have to be that the defendant didn't know files in the shared folder would be offered for sharing, that they didn't have any reason to suspect that (non-technical people probably wouldn't, if all they did was use the software to download and never got into the technicalities (I do the same thing all the time, I use BitTorrent to download Linux ISO images with no intention of sharing them out again)), and that if they had known they would've done something to block the sharing (since they had no intention of doing it in the first place). You won't ever be able to win the argument that the files can always unconditionally be available without incurring any liability under any circumstances, but you can win the argument that merely unwittingly and unintentionally putting something down where someone else can take it doesn't incur liability (at least not until you've been told it's happening and have a chance to do something about it).
Possibly. The guard during the test in question knew that specific person was going to be trying to fake the results, and still couldn't tell it was being done. But consider the common cases for abuse of fingerprints. At the bank ATM or the door the public doesn't use, odds on there won't be a guard at all. And if there is, making sure he isn't suspicious is a lot easier than getting past him once he is. Dress right, act right and 9 times out of 10 he'll assume you are right. Especially when the box that he knows will alarm if the wrong fingerprint's seen doesn't alarm.
Except that you won't be whipping it out. It'll already be on your fingertip ready to go. Bear in mind that the test for faking out a fingerprint scanner was that it was done with a human guard watching. And the attacker still succeeded.
Except that with most types of biometric data (eg. fingerprints), they suffer two faults: you leave copies of them everywhere, and once compromised they can't be changed. The first makes it easy for someone to compromise the authentication, as this club demonstrated. I'll bet the minister left his fingerprints on a lot more than just a single plastic cup at a panel, and lifting a fingerprint from a hard surface is relatively easy to do. And the second means that compromises are 100% absolutely fatal for the rest of your life. With a password or a PIN, if it's compromised you can just use alternative authentication and then change it. With a physical key or combination you can just change the lock or the combination on the lock and the old key or combination becomes useless. But how do you change your fingerprint? And if you can't, how does anyone from that point on know that any use of your fingerprint is really you and not an imposter? So the fingerprint check doesn't add significant difficulty in obtaining the additional authentication item, and it makes a compromise much more annoying to recover from.
You have to evaluate any security mechanism not just in terms of it's strength (resistance to compromise), but in terms of it's resilience (the consequences of a compromise and the difficulty of correcting the compromise). Biometrics tend to vary on the first, but all of them are highly brittle: any compromise tends to be total and irreparable.
Even the limits you want him to give are subject to change. Your node may be sparsely populated now, but in 6 months it may get a lot more subscribers and usage that wasn't a problem before becomes problematic. Or they may have to split your node, so usage that's disruptive now may not be a problem anymore with only half the users on each of the resulting nodes.
I ran into this with a dial-up ISP. They wouldn't tell you how much continuous dialed-in time would get you in trouble, since it changed as they adjusted the modem pools over time. But unlike Comcast they would commit to giving warning: you'd be told what you were doing wrong and what you needed to do to correct it, and only if you ignored the warning and didn't correct the problem would they take action. That was fine by me, I may not have known where the boundaries were but I knew I'd never be blind-sided by them.
That's probably because the bandwidth usage needed to disrupt things for other users changes depending on network usage. At 2am when nobody's doing much, you may be able to run full-bore without bothering anyone. At 6pm when usage is starting to peak, running at even 50% solidly for an extended time may cause slow-downs for lots of other people.
I implement variable bandwidth caps myself. Connections get marked based on current bandwidth, and connections that are using lots of bandwidth for extended periods get marked down to "bulk" priority. My traffic-shaping rules are set up to prioritize "bulk" traffic lower than normal traffic, so the bandwidth hogs can soak up all the bandwidth they want when it's available but have to yield the right-of-way to low-bandwidth traffic. The nice thing is that, since it's based on the current traffic volume per connection, it works regardless of protocol.
They did simply take it down. 15 months ago. And when they did, the volume of queries from mailservers nearly killed the.org nameservers. Not the ones for ORDB, the.org TLD nameservers themselves. The ones that have to answer before anyone anywhere on the Internet can resolve any domain name ending in.org. Faced with the possibility of an entire TLD becoming permanently unusable, the ORDB admins relented and brought their servers back up. That's the state they've been in for the last 15 months. They finally got tired of footing the bandwidth bill and said "OK, if nothing else works then maybe this will get your attention.". And judging from the reactions, it worked.
First Rule: the fastest way to get a problem solved is to make it a personal problem for the person who can solve it.
Slashdot Mirror
My normal environment's Linux (Debian). Yes, most programs when run through the menu will, if they require root privileges, ask for permission to elevate. Those programs, though, are primarily system-administration tools. If I try to fire up the program to update my packages or change my e-mail server configuration, I'm going to get an "enter root password" prompt. If I fire up my e-mail client, or my word processor, or a game, I will not get that prompt even if the program needs root to do it's job. I'll get error messages from the application saying it can't write to files or whatever it failed to have privileges for, but the OS and the desktop won't say a word, nor will they hand out privileges unasked-for (that prompt actually comes not from the app or the OS but from a wrapper program the packagers use when creating the icons and menu items for selected apps that the user should be able to run with root privileges).
The problem is that no, in 5-10 years programs will still need UAC. Because if it's as easy as it is to turn off UAC, app vendors will just tell users to turn it off. Fixing their apps costs them money, having users disable the thing that's causing all those pop-ups doesn't. Which do you think the app vendors will pick?
Short-term, enforcing the rules will break a lot of things. But the rules have been published for at least 10 years now and vendors haven't voluntarily complied with them. Conformance is going to have to be non-voluntary, then, and the failure is going to have to be pinned solidly and clearly on the app, not Windows. And in the long term, compliance with the rules will make life a lot easier for everybody.
The basic idea's sound. The problem is that, given the implementation, users view the problem as being UAC and/or Vista, not the apps. After all, the apps work just fine if you turn those annoying dialogs off or go back to XP. If the users don't view the app as the cause of the problem, they won't pressure the app vendor to do anything about it. Idea fails.
I prefer the Unix approach. The OS doesn't pop up any dialog, or offer the user any choice. If an app does something it doesn't have privileges for, it gets an ENOPRIV returned from that call and isn't allowed to do that. How the app handles it from there is up to the app, but there's no easy way to make the errors go away at the system level (most modern Unixes are set up to make it inconvenient to log in or run programs as root, and only root can install a program setuid-root).
Yes. Your registrar submits the master NS records that tell the world where the nameservers for your domain are. So, for example, for example.com there are NS records in the "com" zone that identify the authoritative nameservers for example.com. If your registrar sends an update changing those NS records to identify their nameservers instead of yours, they gain control over name resolution for your domain. A sneaky registrar could have nameservers that, when they get a query, do a query to the nameservers you gave them. If they get a record back, they pass it along as their response. If they get a "does not exist" response from your servers, they send the A record of their parking server back. You might never notice them doing this.
NB: the above is one reason I occasionally do a dig query and check all the records and delegation information for my domains, as well as doing whois queries to check the public view of my domain registration information.
True, but the doors aren't gone. That's where you go astray, trying to eliminate one door from the probability calculation when it's still there. You have three doors to choose from, there's only one car, you have a 1/3rd chance of choosing the correct door and a 2/3rds chance of choosing the wrong one. When Monty opens a door, you still have a 1/3rd chance of having the correct door and a 2/3rds chance of having the wrong one, but that 2/3rds chance is now concentrated behind one door because Monty can't open the door with the car behind it.
Your calculation only works if Monty opens his door before you choose yours, or if you discard your first choice and choose at random after Monty opens a door. The point of the excercise, though, is that you don't have to discard your initial choice and choose at random. Monty knows something you don't, and you can deduce from his actions and the rules what it is that he knows. And that skews the probabilities away from the 50:50 of random choice.
No, you're wrong.
Start with the initial case: you choose from 3 doors, 1 of which has a car and 2 of which have goats behind them. Now, suppose Monty just opens all the doors on the spot, revealing whether you won or not. What's the probability that you chose the car? 1/3rd. It has to be, only 1 door out of three had the car.
Next step, you make the same choice. Monty opens a door but doesn't give you the option of changing your selection. Now, what's the probability of your winning? You made the same choice you did in the previous scenario. Monty's opening of his door has no effect on the outcome or the probabilities. So your probability of winning the car has to still be 1/3rd.
Final step, you make your choice and Monty opens his door, but now he offers you the chance to change your selection. Before you decide, your situation is exactly the same as in the previous scenario. That means your probability of winning has to be the same, 1/3rd. But since Monty showed you one door with a goat behind it, so there's only one door left. Since the total probability has to be 1, the probability that that door is the one with the car behind it is 1 minus 1/3, or 2/3rds.
Because your initial probability of picking the car isn't 50/50, it's 2:1 against the car. You choose from 3 doors, remember, not 2. So initially the probability is 1/3rd that you've chosen the car, 2/3rds that the car is behind one of the doors you haven't chosen. Then Monty opens one of the doors you haven't chosen. He's constrained to open a door with a goat behind it, but the fact that he's opened a door doesn't change the initial probabilities. So the probabilities remain 1/3rd that you've chosen the car, 2/3rds that the car's behind one of the other doors. Monty's helpfully told you which door the car isn't behind, so the 2/3rds-chance door must be the one neither you nor Monty has chosen.
I think it's actually that counting is easy, and people know it. But verifying the count is hard, and people know that too. And the advocates for the voting machines, and the companies that make them, have all been incredibly vehement in their opposition to any form of audit trail. And that immediately makes most people suspicious.
The audit trail itself turns out to be a non-computer problem. It has to be, because the definition of an audit trail is a check against something independent of what you're auditing (in this case, the machine's count). You can't, for example, audit a hotel clerk's tally of rooms sold and revenue taken in by looking only at his transaction sheet. You have to check against something else. In the days of physical room keys, that's what we checked against. Every room had a known number of keys, and the clerks didn't have access to the spares, so every room's key slot should have 3 keys in it minus the number of guests recorded on the room register. A clerk could give someone a room, not record it on the register and pocket the money, but he'd still have to give that someone a key. When I did the audit his transaction sheet and cash bag would all balance but I'd find a room short a key with no explanation. The same independent audit trail is needed with a voting machine: something you can check the machine's count against without having to assume anything about the counts reported by the machine (the memory cards used to hold the count are considered part of "the machine", since their content is completely under it's control). And that pretty much precludes any electronic count being used for the audit.
I'd note that I don't expect these roadblocks to the RIAA getting student's identities to hold forever. It simply isn't permissible in the US legal system to prevent a plaintiff with a legitimate claim from discovering the identity of the person they have that claim against. The best the students can hope for in the long run is to require the RIAA to prove that the IP address and client they have a record of did in fact commit copyright infringement. That's probably a significant hurdle, but if the RIAA clears it then the students will not be able to block discovery of their identities.
I don't think the case'll turn on whether taking notes is fair use as on whether or not the student's notes constituted a copy of a protected work. Facts, remember, can't be copyrighted. I can write down stock market quotes and republish them in my own format all day and the source I get them from can't (absent some contract with me) touch me. The prices are facts, not expression. I can't copy their layout and formatting, but the numbers themselves are fine. So the question would be, are a student's notes recording, in their own words with their own formatting and layout having nothing to do with the professor's written lecture papers, the lecture a copy of the professor's work, as opposed to a wholy new work embodying the facts the professor used in his work? I think the simple analogy should convince the judge: "Is a movie review, summarizing the movie in the reviewer's own words and without copying any footage or exact lines from the movie itself, a copy of the movie?". The likely answer to that question is "No.", and the same for the notes.
This is normal for hardware makers. It's cheaper to set up one production line than two, and to produce one model of board instead of two. If you price the high-end models so that sales pay for the fixed cost of the production line plus the cost of producing those units then you can price the low-end models based only on the marginal cost of running off X more units on a paid-for line, sell them to the people who wouldn't pay the price of the high-end unit and make more profit than just selling the high-end units alone.
Sometimes it can work to the consumer's advantage too. Back before they were bought by 3Com, NetGear was the consumer label of Bay Networks. That NetGear consumer-grade switch you bought was really a full-on Bay Networks unmanaged professional-grade switch with a different silk-screen job on the case.
It's a problem for Creative because often they use identical hardware for multiple sound cards, with the drivers determining which features are active. For instance, they may sell the UltiSound Basic with 5.1 surround for $150, and the UltiSound Extreme with 7.1 and Dolby output for $300. If you look carefully at the cards, they're absolutely 100% hardware-identical. Even the jacks are identical and wired up the same. In other words, the UltiSound Basic is quite capable of outputting 7.1 and Dolby just like the Extreme. The only difference is in a small EPROM chip with the model ID in it. The driver reads that and uses the model ID to decide which firmware to load into the card, and it won't load the 7.1/Dolby-capable firmware into a card with a Basic model ID. If someone hacks the drivers to change the check, then Creative finds their Extreme card not selling very well since everybody's buying the Basic and turning on the high-end features.
They also tend to deprecate their low-end cards on new versions of Windows, forcing people to buy upgraded hardware if they want to upgrade their OS. If hacked drivers allow people to keep using their older hardware, Creative loses sales.
Yes, both tactics are stupid. But to Creative hacked drivers are a threat to a business model based on those tactics. They just discovered here that the PR backlash may be a bigger threat.
Well, it's well-known that cars are used by criminals to flee the scene of a crime. It's also well-known that if I leave a car on the street it could be stolen, especially if I don't lock it. So if I park my car on the street in front of my house and forget to lock the passenger-side door, and someone steals it and uses it to get away after robbing a bank, did I buy that car for the sole purpose of robbing a bank? It's theoretically possible, if I can be shown to be in cahoots with the robber, but the police haven't shown I even knew a robbery had happened let alone that I knew the robber that well.
Actually in both the third and fourth cases they'll have a hard time coming after you. If the table's out next to the sidewalk they may have an easier time, but if the table's up on your porch and you keep books on it to read then even if people come onto your property and take the books the RIAA would have to show that you intended people to take those books, as opposed to intending to have them there for your own use and outsiders abused that while you were gone and didn't know about it happening. That's what the judge's words about "offer" are aimed at. In fact, his ruling eliminates the need for the RIAA to prove actual downloading, it hinges the entire ability to sue on showing either intent or willful recklessness. The RIAA now has to prove that either the defendants put the files there with the intent that others download them or that, at the very least, the defendants knew or reasonably should have known those files would be available to others and failed to take any steps to prevent that. The first is a real tough nut absent a confession from the defendants, and the second, well, it's really easy to argue that the defendants never were exposed to any hint that this software even could make the files available and had no reason to believe it'd allow others to download from them and it'll be real hard for the RIAA to prove these people are tech-savvy enough that they had to have known all about how P2P works.
Not neccesarily. The key phrase is "knew or reasonably should have known". If there's a warning about something in the manual, a reasonable user's expected to have read the manual and so reasonably should have known about the danger. But when there's no apparent mention of something, things become more subjective. The question is usually "What would a reasonable ordinary person know about this?". Now, as a techie I'll know about the upload function of P2P software. But someone who's not an IT professional, doesn't deal with this software every day, what would give them any reason to believe the software would upload what was downloaded? That's the question the court would (or should) ask. If you go through everything the user would've had available and nothing anywhere would hint at the upload functionality, and they don't have contacts in circles where that sort of thing would be regularly discussed, then how would they reasonably be expected to find out about it?
And most P2P software doesn't necessarily require positive action by the user to share downloaded files again. Much of it defaults to sharing unless and until the user turns sharing off. And if the user doesn't know there is a sharing function, why should they know to turn it off?
It's kind of like trespassing. If there's a solid fence with lots of "No trespassing" signs on it, you'll have an easy time nailing anyone you find on the wrong side of the fence. But if there's no fence, no signs, no indication whatsoever of a boundary, and this is the first time that person's been caught on the property, you'll have a hard time getting them convicted of trespassing. And if for the last 50 years everybody's been going across that property with no problems and no objections from the owner, the new owner's going to find it all but impossible to get trespassing charges upheld until after he puts up a fence and posts the property.
Except that that happening by default would undermine the argument. If the software's always discussed in terms of downloading, there's no obvious mention of it uploading and the upload function is enabled by default and doesn't require user intervention to turn it on, then why should a naive, non-technically-savvy user expect that his download software is actually uploading behind his back?
All that's needed is to acknowledge a distinction between what should be and what is. People should know what their equipment's doing, and set it to only do what they want it doing. So in a perfect world, people would secure their wireless routers unless they intended anyone to access them, and people would configure their file-sharing software to not share any files unless they intended to share those files.
But we don't live in a perfect world. Users take the default settings on their shiny-new wireless router because they don't know there's anything to change and, after all, it works just fine so they've no reason to think there's anything more needed. And other users take the default behavior of their wireless card and drivers, and when those drivers connect somewhere and don't give any indication there's any problem the user has no reason to think he's not allowed to connect there. After all, in his view, if whatever he connected to wasn't intended to be open to the public surely it'd've prompted for login information or something, no? The confluence of two naive users results in something happening that neither intended to happen, that neither realized was going to happen. Neither's required to know enough to know better, and until they are required to know enough they can't really be held responsible for not knowing.
Were it me, I'd simply make the manufacturers liable for the default settings on their devices, since they certainly know enough to know what the implications of any settings are. They can set them however they want, but they're on the hook for the consequences. My prediction is that instantly all new wireless gear would default to "no access without a key" and require the user to select a key before the device would work, and you've have to dig around to find the setting to allow access without authentication. End of problem.
That depends. That's the default behavior unless you go and deliberately modify the client's settings. So if I go to a tracker to get say a Linux distribution, treating a BitTorrent client like a fancy FTP program purely for download, I'm going to offer up chunks of what I'm downloading unless I'm technically savvy enough to know this is happening and change the default behavior. If I'm not technically savvy, I probably won't even realize this is happening. And there's the trick of it: if I put something down on a table in my front yard while I go inside and get a drink, not realizing someone will come along and take it, have I made an offer to that someone to distribute what I've left laying there?
The RIAA's undoubtably going to argue that the defendant's P2P software made the file available and that that constitutes the offer of distribution. The trick will be to neuter this argument, and that's going to have to turn on intent. If, for example, I have a table of books in my front yard with a sign saying "Take some", that's clearly an offer to distribute. But if I put a book down on the table on my front porch while I go inside to get something to drink, and while I'm gone someone comes along and takes the book, the book's arguably been distributed but I clearly haven't made any offer to distribute, the book was merely stolen. The argument's going to have to be that the defendant didn't know files in the shared folder would be offered for sharing, that they didn't have any reason to suspect that (non-technical people probably wouldn't, if all they did was use the software to download and never got into the technicalities (I do the same thing all the time, I use BitTorrent to download Linux ISO images with no intention of sharing them out again)), and that if they had known they would've done something to block the sharing (since they had no intention of doing it in the first place). You won't ever be able to win the argument that the files can always unconditionally be available without incurring any liability under any circumstances, but you can win the argument that merely unwittingly and unintentionally putting something down where someone else can take it doesn't incur liability (at least not until you've been told it's happening and have a chance to do something about it).
Possibly. The guard during the test in question knew that specific person was going to be trying to fake the results, and still couldn't tell it was being done. But consider the common cases for abuse of fingerprints. At the bank ATM or the door the public doesn't use, odds on there won't be a guard at all. And if there is, making sure he isn't suspicious is a lot easier than getting past him once he is. Dress right, act right and 9 times out of 10 he'll assume you are right. Especially when the box that he knows will alarm if the wrong fingerprint's seen doesn't alarm.
Except that you won't be whipping it out. It'll already be on your fingertip ready to go. Bear in mind that the test for faking out a fingerprint scanner was that it was done with a human guard watching. And the attacker still succeeded.
Except that with most types of biometric data (eg. fingerprints), they suffer two faults: you leave copies of them everywhere, and once compromised they can't be changed. The first makes it easy for someone to compromise the authentication, as this club demonstrated. I'll bet the minister left his fingerprints on a lot more than just a single plastic cup at a panel, and lifting a fingerprint from a hard surface is relatively easy to do. And the second means that compromises are 100% absolutely fatal for the rest of your life. With a password or a PIN, if it's compromised you can just use alternative authentication and then change it. With a physical key or combination you can just change the lock or the combination on the lock and the old key or combination becomes useless. But how do you change your fingerprint? And if you can't, how does anyone from that point on know that any use of your fingerprint is really you and not an imposter? So the fingerprint check doesn't add significant difficulty in obtaining the additional authentication item, and it makes a compromise much more annoying to recover from.
You have to evaluate any security mechanism not just in terms of it's strength (resistance to compromise), but in terms of it's resilience (the consequences of a compromise and the difficulty of correcting the compromise). Biometrics tend to vary on the first, but all of them are highly brittle: any compromise tends to be total and irreparable.
Even the limits you want him to give are subject to change. Your node may be sparsely populated now, but in 6 months it may get a lot more subscribers and usage that wasn't a problem before becomes problematic. Or they may have to split your node, so usage that's disruptive now may not be a problem anymore with only half the users on each of the resulting nodes.
I ran into this with a dial-up ISP. They wouldn't tell you how much continuous dialed-in time would get you in trouble, since it changed as they adjusted the modem pools over time. But unlike Comcast they would commit to giving warning: you'd be told what you were doing wrong and what you needed to do to correct it, and only if you ignored the warning and didn't correct the problem would they take action. That was fine by me, I may not have known where the boundaries were but I knew I'd never be blind-sided by them.
That's probably because the bandwidth usage needed to disrupt things for other users changes depending on network usage. At 2am when nobody's doing much, you may be able to run full-bore without bothering anyone. At 6pm when usage is starting to peak, running at even 50% solidly for an extended time may cause slow-downs for lots of other people.
I implement variable bandwidth caps myself. Connections get marked based on current bandwidth, and connections that are using lots of bandwidth for extended periods get marked down to "bulk" priority. My traffic-shaping rules are set up to prioritize "bulk" traffic lower than normal traffic, so the bandwidth hogs can soak up all the bandwidth they want when it's available but have to yield the right-of-way to low-bandwidth traffic. The nice thing is that, since it's based on the current traffic volume per connection, it works regardless of protocol.
They did simply take it down. 15 months ago. And when they did, the volume of queries from mailservers nearly killed the .org nameservers. Not the ones for ORDB, the .org TLD nameservers themselves. The ones that have to answer before anyone anywhere on the Internet can resolve any domain name ending in .org. Faced with the possibility of an entire TLD becoming permanently unusable, the ORDB admins relented and brought their servers back up. That's the state they've been in for the last 15 months. They finally got tired of footing the bandwidth bill and said "OK, if nothing else works then maybe this will get your attention.". And judging from the reactions, it worked.
First Rule: the fastest way to get a problem solved is to make it a personal problem for the person who can solve it.