What I don't understand is why ID is needed in the first place. It seems to be tied to the idea of the merchant making a charge against the purchaser's bank account, which means the merchant needs to identify the purchaser to make the charge. But why does the merchant need to make the charge? Instead, have the merchant provide a merchant ID and transaction number to the consumer, who then logs into their bank's site and initiates a payment to the merchant for the transaction. Nobody can initiate a payment without knowing the credentials to my bank's site, which I don't ever have to provide to anybody so I can keep them secure (modulo attacks on the bank itself or me falling for a phishing scheme). If the merchant doesn't ship until they receive the payment they don't have to verify the address, anybody trying to initiate a purchase in my name won't have my bank credentials and won't be able to initiate a payment from my account. And all the information the merchant needs to keep on file long-term is the payment number my bank gave them as part of the payment transaction, which the bank can tie to my account on it's end if the merchant needs to do a refund or anything. All this should be fairly simple, it's just standard EFT initiated by the payer instead of the payee.
I'm of the opinion that the liability should depend in part on whether the data's being kept longer than needed for the transaction or purpose it was provided for or not. For instance, if I buy something from an on-line merchant they need to keep my name and address on file at least long enough to ship my item, and almost certainly for the length of time I'm allowed to return the item for a refund or replacement. They need to keep my credit-card number on file long enough to authorize it, possibly long enough to settle the charges (depending on how they're set up with their clearing house), and possibly as long as I'm allowed to ask for a refund (if for instance the clearing house requires the card number to credit the money back). When a company keeps information around longer than needed, they should be held to a higher standard since now it's their choice that the data's being kept. And "needed" should be determined by the purpose or transaction the data was provided for, not by what the company wants to do. When I provide a billing/shipping address for a purchase, I'm not providing it so the company can do better advertising later. If they insist that I create a profile and leave that information on file permanently for their convenience or benefit, they should be taking more responsibility for it's security than if they're keeping it just long enough to do what I asked of them and then discarding it.
If I were designing it, the extension would have hard-coded into it a certificate that'd be used to sign all the notary SSL certificates. If a notary didn't present an SSL certificate signed by the hard-coded known certificate, it'd be rejected and considered immediate proof of an MitM attack.
hose minutiae aside, though, I am very surprised by how much apparent confusion the GPL and other copyleft type licences inspire.
I'm not. That's because I don't think most of those entities are confused at all. Having heard a lot of them, I'm of the opinion that they understand the GPL and how to comply with it perfectly well, but they've got their own agendas which would be harmed by having to comply with the GPL so they feign ignorance and confusion to try to get out of doing what they know full well they're obligated to do. You can see a perfect example of the same behavior in many young children. Tell them something like "You can't watch television until you've cleaned your room.", or "No, you can't have any more cookies, you've had too many already.", and watch them try and twist and finagle to get what they want. Even to the point of standing there with a handful of cookies and a full mouth mumbling "But I didn't think you meant these cookies...".
There's already problems caused in MMOs by persistence. The classic one is quest mobs. When another player's doing a quest that targets the same mobs as yours, the mobs he's killed aren't there for you to kill and you can't update your quest until the mobs respawn (persistence resets). When the objective's one with a long respawn time (maximum persistence) and has some value to other players, it gets worse because people will go and farm that objective, taking or killing it as often as they can, simply for that other value, making it difficult to impossible to complete quests (at least without dedicating large amounts of time to camping the objective). Instancing in MMOs (decreased persistence) is a direct response to the fact that players don't like this situation. If you increase the amount of persistence even further, make it more and more common for players to be blocked in their quests because some other player's already taken their objective, you're going to increase player frustration big-time. And frustrated players leave your game for one that won't frustrate them as much.
These guys have lots of experience in pen-and-paper and tabletop games, but those games aren't MMOs. The big difference is in one word: "massively". In a pen-and-paper or tabletop game, you have half-a-dozen, maybe a dozen at most, players affecting the world and they're all in typically one group and all have the same or closely-related objectives. In an MMO you've got several tens of thousands of people affecting the world, and they're not all in one group and they're not all synchronized with each other in terms of what they're doing at any given time. If you want to increase persistence, you'll need to read up on "farmers" and "griefers" and figure out how you're going to deal with them in your game. Spending a year or two actually playing existing MMOs to see how players actually interact with them would be good too.
Fine and dandy, as long as I've got the option of not paying the fee and not getting access to the music. I don't care for most of the stuff the major labels put out, and I'd rather not pay for something I've no interest in getting. If I want music from them I'll pay for the items I want, thank you very much.
This holding wouldn't be controlling outside the Federal Circuit, but it'd be considered very persuasive. Basically having two Appeals Courts make contradictory rulings is one of the fastest ways to get the Supreme Court to take the appeal and resolve the conflict, and the only constant there is that if that happens at least one of the Appeals Courts will be told they were wrong. So Appeals Courts try not to make contradictory rulings. And District Court judges try not to make rulings that their controlling Appeals Court will have to overturn. Seeing as how the Federal Circuit appeals court isn't the 9th Circuit one, I'd expect most district courts to take their cue from this ruling. Especially given how clear the CAFC ruling is. Few judges would like to explain in a ruling why they're disregarding the plain language used in a license despite an Appeals Court ruling saying that that language means exactly what it says.
Nope, wrong sense. Subdivision (a) sets the conditions under which an IT employee can be considered exempt from overtime rules. Subdivision (b) gives conditions under which the exemption in subdivision (a) does not apply. So if (b)(3) applies, then the overtime exemption otherwise granted by (a) does not apply and the employee is not overtime-exempt. A broad reading could make sysadmins non-exempt employees, but it couldn't make them exempt if they didn't meet the qualifications of (a).
USC Title 17 Chapter 1 section 117 paragraph (a) grants permission to make certain copies, eg. those neccesary for running a computer program. To be technically picky about it, it says that it is not an infringement of copyright to make those copies or to authorize having them made.
Also bear in mind that, for the IT field, California has additional laws about who's overtime-exempt and who's not based on, among other things, salary and effective hourly rate. Relevant law is California Labor Code section 515.5. As of 2007 the effective hourly rate needed to qualify as overtime-exempt was $49.77/hour. SB 929 changed that effective 1/1/2008 to $36/hour, or not quite $75K/year in salary. Anyone in the IT field not being paid at least that amount is not exempt from overtime in California regardless of other qualifications (the exemption requires that all conditions hold).
There's a number of reasons I'd personally need to get a "pirated" copy of a game, even a game I've actually bought. Let me summarize a few of them.
1. Games that require the disc to be in the CD/DVD drive to play. The game isn't the only thing on my computer, nor the only thing that wants/needs that drive. If I have something else that needs the CD/DVD drive, I have to choose between the game and that something else. That ends up annoying me, and if there's a "pirated" version or a crack that bypasses the disc check I may be inclined to get that just to free up the drive.
2. DRM and anti-cheating software. When a game installs that stuff, it usually winds up affecting more than just the game. Remember, the game is not the only thing I use the computer for. If the DRM and anti-cheat software the game requires is nasty enough to interfere with other legitimate things I'm doing on the computer (and it usually is), I'm going to either dump the game or go looking for ways to get rid of the interference. I'm sorry, but I simply can't afford to dedicate a piece of hardware with a 4-digit price tag to the job of playing one single solitary game. I don't care how good the game is, it's not good enough to justify a 4-digit cost. On-line checks are just as bad. Unless the game's specifically a multi-player on-line game, I may not have an active network connection while playing. If the game demands that I do, it may not be physically possible and even if it is I may not want to go to the hassle of running a wire or setting up wireless on a computer that doesn't otherwise need it.
Notice that the two have a common theme: games that assume they're the only thing on the machine and that satisfying their demands is the only priority. That's fine on a dedicated console, but a PC isn't a console. You want to make it less likely I'll have to go looking for a pirated or cracked copy? As a game designer, start taking into account the fact that your game has to live alongside everything else on my computer and not cause problems for me when I'm doing all the things I do with the computer when I'm not playing your game.
3. Economics. Look at the target market for your game, and how much disposable cash members of that market will have. Then look at the price of your game. Can they afford to buy it? If you're pricing your game at $45, and targeting early teens, you're going to have rampant piracy. 13-15 year old kids don't have $45 burning a hole in their pocket. Especially not with the economy the way it is right now. And no, the fact that your game really is worth $45 isn't relevant. As people trying to sell homes they can't afford are finding out, the value of something isn't what it's worth, it's what a buyer can afford to pay for it. If the buyer can't afford the price, you'll have no buyers regardless of how good a deal it is. If you go about deliberately creating a demand for something in a market that can't afford the price you've set, don't be surprised when piracy goes through the roof. Either re-evaluate your target market, or re-evaluate your price.
4. Accessibility. How easy is it for members of your target market to buy the game? Again, if you're targeting early teens, they aren't going to have a credit card to buy on-line. If the game's also not readily available in stores, how are they supposed to buy it? And when it's available on-line, if it requires physical shipping (meaning a wait of several days to a week) people are going to go looking for alternatives like downloading. If getting your game legitimately is annoying, aggravating and takes a long time, and downloading a copy from a pirate site is convenient and fast, don't be surprised when people choose convenient and fast.
Note that this last one's a good example of a rule I got from an old shopkeeper friend: "Whatever you do as a store owner, never ever make it hard for the customer to give you their money.". A lot of on-line stores could stand to listen to that advice. I put my stuff in the cart, go to
I'm not surprised. Port randomization doesn't make the attack impossible, just harder. It doesn't eliminate the birthday attack, it just increases the space you have to blanket to generate a collision. The only real fix for the attack is DNSSEC, allowing the software to reject forged responses completely. Short of that, I can only think of two more things that'd help:
Ignore additional data in responses, or at least additional data not responsive to the query itself. This goes beyond bailiwick checking. It means, on non-delegation responses, ignoring all additional data that's not for the exact same name as the query was for. On delegation responses, only A records for the names given in NS responses are looked at, nothing more (yes, that still leaves a hole for the attack to work on delegation responses).
Implement a request/response queue in the software. When a new request arrives, if it matches a request in the queue it's attached to that and no new request is sent out. Requests are split so that partial matches result in new requests only for the portions that don't already have a request pending. When received, responses are attached to their respective requests and the requests flagged as complete. After a short interval, completed requests have their responses collected and sent back to the querent. If multiple responses arrive for the same request, all responses to that request are dropped and a new query is generated and sent out. The headache here is appropriate safeguards against a DoS attack.
These don't completely close down the attack, but I can't think of anything else that makes it harder short of having responses cryptographically signed and the signature verified as coming from the expected source. We need to start pounding on domain owners to implement DNSSEC. Yes, that's work. Yes, it's neccesary.
Why's it hard to enforce? Something in an IFRAME isn't clearly and verifiably served by my bank's Web server, therefore I don't enter my account's password into it. Wasn't that easy?:)
The bank logo and custom phrase provide no assurance. Any black-hat that's managed to infiltrate the merchant's site can request the VbV/SC page from my bank and copy the supplied logo and phrase onto their malicious page. Making this worse, most VbV/SC implementations have the authentication in an IFRAME, so the URL bar provides me no information about what site the authentication form's coming from.
For VbV/SC to be secure, it has to work this way:
The merchant's site must not direct me to my bank's site. If it must redirect me, it must redirect me to my bank's recognizable front page at their commonly-known domain.
I must log in through my bank's known and recognized login process and authorize the transaction through my bank's site and my bank's site only.
Anything else involves trusting a third party with my bank credentials, which is obviously insecure by definition.
Hardly impressive. Black-hat VbV site retrieves the legit page, displays a copy of it with only one change: submission goes to the black-hat server instead of the VbV site. When you submit, black-hat page records your information and passes the submit on to the VbV site. The black-hat now owns your bank account credentials and you're none the wiser. If I can figure out the basic method, someone who's actually an expert at Web development certainly can refine it into an actual attack.
If the URL bar doesn't point at the actual hostname your bank uses, you cannot trust anything on the page.
Look at it the other way: where do you think you're going to find experienced employees if they're all bound by non-compete agreements not to work for you?
One of the reasons I've avoided Verified by Visa is that the way they implement the "authentication" page it's impossible for the customer to tell whether they're entering their password into the Visa site or some random black-hat site. And I have a simple rule: I don't enter my account's password into any form that's not on a page clearly and verifiably served by my bank's Web server.
Of course, if I'm buying on a Web site, I'm most likely using my Amex card which doesn't have this issue. If the merchant doesn't take Amex, I'll go to one that does.
Probably CYA for the judge. It'd look bad to the judge if Tufts refused to co-operate with a plaintiff completely. But when Tufts says "If you can give us a formal legal request telling us what to preserve, we'll do our best to try and preserve it while you sort things out with the court. We don't really have to, we're not a party to your lawsuit and aren't obliged to help you out until you come to us with a court order, but being nice guys we're willing to try and work something out.", they look a lot better to the judge. And when, after they've made that offer, the RIAA comes along screaming about how unreasonable Tufts is being and how they should just give the RIAA what's demanded, the judge starts to wonder whether it's really Tufts being unreasonable here. After Tufts making that offer, if the RIAA just rejects it and demands more it makes it easier for the judge to slap the RIAA down for making undue demands on a non-party. And, not coincidentally, from the sounds of it by the time the RIAA goes through the whole legal procedure to get the information from Tufts it'll be long gone through the natural operation of their system (which they're not technically obliged to change until after the RIAA's gone through the legal procedure and served papers on them).
No. You're taking the position that downloads are authorized unless the person making them available knows they're unauthorized. The law takes the position that downloads are unauthorized unless the person making them available either has permission themselves or knows that the person asking for the download is authorized. So even if the person requesting the file is the copyright owner, as the person making it available to them you have to know that they're the copyright owner. If you don't, then the copy you made for them was unauthorized as far as the court's concerned. The recipient may be authorized (by definition, as the copyright holder) to make copies, but he didn't make the copy, you did, and as far as you knew at the time you didn't have authorization.
Bad analogy. To be a parallel the driver would've had to have been speeding upon and after seeing the cop, in which case the cop doesn't need to make any claim about what the driver would've done had he not seen the cop.
And if your position is correct, then no copyright holder can ever possibly make any claim of copyright infringement against anybody. To present the evidence, the copyright holder has to obtain the evidence. If the very act of him obtaining the evidence renders it not evidence of copyright infringement (because his receipt of it was authorized, therefore it's not an unauthorized copy), how can any copyright holder present any evidence of infringement? The law doesn't permit silly situations like that. And in any case, the recipient being the copyright holder is irrelevant. The violation isn't in receiving the copy, it's in making the copy without permission from the copyright holder. When the copyright holder asks you to make him a copy, he has not implicitly granted you any permission because copyright law contains no implicit permissions beyond fair use. So if you make a copy for him, it's still an unauthorized copy (he never gave you permission to make it). The only recourse you have is to show that you knew he was the copyright holder before you made the copy. That would let you take advantage of the shelter of the "acting at the direction of" portions of copyright law (ie. someone who has a right to make copies of something has a right to have someone else make those same copies if that someone else retains no control over the copies once made and delivered and does so only at the direction and under the control of the person with the right). But you can only take advantage of that if you know or have good reason to believe the person asking you really does have the right.
The relevant question the court would ask is "Did you know it was Josh Grobin when you made the copy for him?". If you didn't, then the fact that he was the copyright holder would be set aside as irrelevant. You didn't know that and yet you made the copy for him anyway, so the presumption is that you'd've done the same if he hadn't been Josh Grobin.
Could you, though? Sure, you can redirect me to your site and present a self-signed certificate. But are you hijacking the first connection I've made to this site? If you aren't, then you tip me off. I've already put the site's real self-signed certificate in my browser, so I'm expecting not to get warnings again. When the browser pops up the dialogs triggered by your unknown-to-my-browser self-signed certificate, this is something I'm not expecting. I'm going to look closer at the certificate to figure out why my browser's popping up a warning about something it shouldn't be.
No, mailing lists are not spam (at least not the ones with good opt-in subscription). And no, they don't become unsolicited. When you signed up, you did so knowing you were signing up for an ongoing subscription that would result in future mailings. You asked for those future mailings. From then on, those mailings that you asked for are solicited and remain so until such time as you tell the mailing list that you no longer want them (usually by unsubscribing). Whether you want them now or not is irrelevant to the question of whether you asked for them or not.
Because this isn't argument before the Supreme Court. It's not even before the Appeals Court. This is the original trial court this guy's being brought in for.
Because you're racing against the real DNS server, trying to beat it to providing a response. It's a lot easier to do that if you can start sending your faked responses as soon as you know the target's going to be listening. If you have to wait to see the target's request, you're starting the race already behind by the amount of network latency between you and your target. But if you can guess from the first request what port's going to be used for the second, you can start sending faked responses as soon as you know the target's sent it's request (you don't need to see the actual request to predict that timing in a lot of cases).
It's like winning a drag race. If you can time the sequence of the lights on the starting pole you can get on the gas and start to release the brakes before the light goes green, timing it so you'll start moving when the light will have turned green. That gives you a big jump on the guy who waits for the light to go green before starting to shove the gas pedal down.
Slashdot Mirror
What I don't understand is why ID is needed in the first place. It seems to be tied to the idea of the merchant making a charge against the purchaser's bank account, which means the merchant needs to identify the purchaser to make the charge. But why does the merchant need to make the charge? Instead, have the merchant provide a merchant ID and transaction number to the consumer, who then logs into their bank's site and initiates a payment to the merchant for the transaction. Nobody can initiate a payment without knowing the credentials to my bank's site, which I don't ever have to provide to anybody so I can keep them secure (modulo attacks on the bank itself or me falling for a phishing scheme). If the merchant doesn't ship until they receive the payment they don't have to verify the address, anybody trying to initiate a purchase in my name won't have my bank credentials and won't be able to initiate a payment from my account. And all the information the merchant needs to keep on file long-term is the payment number my bank gave them as part of the payment transaction, which the bank can tie to my account on it's end if the merchant needs to do a refund or anything. All this should be fairly simple, it's just standard EFT initiated by the payer instead of the payee.
I'm of the opinion that the liability should depend in part on whether the data's being kept longer than needed for the transaction or purpose it was provided for or not. For instance, if I buy something from an on-line merchant they need to keep my name and address on file at least long enough to ship my item, and almost certainly for the length of time I'm allowed to return the item for a refund or replacement. They need to keep my credit-card number on file long enough to authorize it, possibly long enough to settle the charges (depending on how they're set up with their clearing house), and possibly as long as I'm allowed to ask for a refund (if for instance the clearing house requires the card number to credit the money back). When a company keeps information around longer than needed, they should be held to a higher standard since now it's their choice that the data's being kept. And "needed" should be determined by the purpose or transaction the data was provided for, not by what the company wants to do. When I provide a billing/shipping address for a purchase, I'm not providing it so the company can do better advertising later. If they insist that I create a profile and leave that information on file permanently for their convenience or benefit, they should be taking more responsibility for it's security than if they're keeping it just long enough to do what I asked of them and then discarding it.
If I were designing it, the extension would have hard-coded into it a certificate that'd be used to sign all the notary SSL certificates. If a notary didn't present an SSL certificate signed by the hard-coded known certificate, it'd be rejected and considered immediate proof of an MitM attack.
hose minutiae aside, though, I am very surprised by how much apparent confusion the GPL and other copyleft type licences inspire.
I'm not. That's because I don't think most of those entities are confused at all. Having heard a lot of them, I'm of the opinion that they understand the GPL and how to comply with it perfectly well, but they've got their own agendas which would be harmed by having to comply with the GPL so they feign ignorance and confusion to try to get out of doing what they know full well they're obligated to do. You can see a perfect example of the same behavior in many young children. Tell them something like "You can't watch television until you've cleaned your room.", or "No, you can't have any more cookies, you've had too many already.", and watch them try and twist and finagle to get what they want. Even to the point of standing there with a handful of cookies and a full mouth mumbling "But I didn't think you meant these cookies...".
There's already problems caused in MMOs by persistence. The classic one is quest mobs. When another player's doing a quest that targets the same mobs as yours, the mobs he's killed aren't there for you to kill and you can't update your quest until the mobs respawn (persistence resets). When the objective's one with a long respawn time (maximum persistence) and has some value to other players, it gets worse because people will go and farm that objective, taking or killing it as often as they can, simply for that other value, making it difficult to impossible to complete quests (at least without dedicating large amounts of time to camping the objective). Instancing in MMOs (decreased persistence) is a direct response to the fact that players don't like this situation. If you increase the amount of persistence even further, make it more and more common for players to be blocked in their quests because some other player's already taken their objective, you're going to increase player frustration big-time. And frustrated players leave your game for one that won't frustrate them as much.
These guys have lots of experience in pen-and-paper and tabletop games, but those games aren't MMOs. The big difference is in one word: "massively". In a pen-and-paper or tabletop game, you have half-a-dozen, maybe a dozen at most, players affecting the world and they're all in typically one group and all have the same or closely-related objectives. In an MMO you've got several tens of thousands of people affecting the world, and they're not all in one group and they're not all synchronized with each other in terms of what they're doing at any given time. If you want to increase persistence, you'll need to read up on "farmers" and "griefers" and figure out how you're going to deal with them in your game. Spending a year or two actually playing existing MMOs to see how players actually interact with them would be good too.
Fine and dandy, as long as I've got the option of not paying the fee and not getting access to the music. I don't care for most of the stuff the major labels put out, and I'd rather not pay for something I've no interest in getting. If I want music from them I'll pay for the items I want, thank you very much.
This holding wouldn't be controlling outside the Federal Circuit, but it'd be considered very persuasive. Basically having two Appeals Courts make contradictory rulings is one of the fastest ways to get the Supreme Court to take the appeal and resolve the conflict, and the only constant there is that if that happens at least one of the Appeals Courts will be told they were wrong. So Appeals Courts try not to make contradictory rulings. And District Court judges try not to make rulings that their controlling Appeals Court will have to overturn. Seeing as how the Federal Circuit appeals court isn't the 9th Circuit one, I'd expect most district courts to take their cue from this ruling. Especially given how clear the CAFC ruling is. Few judges would like to explain in a ruling why they're disregarding the plain language used in a license despite an Appeals Court ruling saying that that language means exactly what it says.
Nope, wrong sense. Subdivision (a) sets the conditions under which an IT employee can be considered exempt from overtime rules. Subdivision (b) gives conditions under which the exemption in subdivision (a) does not apply. So if (b)(3) applies, then the overtime exemption otherwise granted by (a) does not apply and the employee is not overtime-exempt. A broad reading could make sysadmins non-exempt employees, but it couldn't make them exempt if they didn't meet the qualifications of (a).
USC Title 17 Chapter 1 section 117 paragraph (a) grants permission to make certain copies, eg. those neccesary for running a computer program. To be technically picky about it, it says that it is not an infringement of copyright to make those copies or to authorize having them made.
Also bear in mind that, for the IT field, California has additional laws about who's overtime-exempt and who's not based on, among other things, salary and effective hourly rate. Relevant law is California Labor Code section 515.5. As of 2007 the effective hourly rate needed to qualify as overtime-exempt was $49.77/hour. SB 929 changed that effective 1/1/2008 to $36/hour, or not quite $75K/year in salary. Anyone in the IT field not being paid at least that amount is not exempt from overtime in California regardless of other qualifications (the exemption requires that all conditions hold).
There's a number of reasons I'd personally need to get a "pirated" copy of a game, even a game I've actually bought. Let me summarize a few of them.
1. Games that require the disc to be in the CD/DVD drive to play. The game isn't the only thing on my computer, nor the only thing that wants/needs that drive. If I have something else that needs the CD/DVD drive, I have to choose between the game and that something else. That ends up annoying me, and if there's a "pirated" version or a crack that bypasses the disc check I may be inclined to get that just to free up the drive.
2. DRM and anti-cheating software. When a game installs that stuff, it usually winds up affecting more than just the game. Remember, the game is not the only thing I use the computer for. If the DRM and anti-cheat software the game requires is nasty enough to interfere with other legitimate things I'm doing on the computer (and it usually is), I'm going to either dump the game or go looking for ways to get rid of the interference. I'm sorry, but I simply can't afford to dedicate a piece of hardware with a 4-digit price tag to the job of playing one single solitary game. I don't care how good the game is, it's not good enough to justify a 4-digit cost. On-line checks are just as bad. Unless the game's specifically a multi-player on-line game, I may not have an active network connection while playing. If the game demands that I do, it may not be physically possible and even if it is I may not want to go to the hassle of running a wire or setting up wireless on a computer that doesn't otherwise need it.
Notice that the two have a common theme: games that assume they're the only thing on the machine and that satisfying their demands is the only priority. That's fine on a dedicated console, but a PC isn't a console. You want to make it less likely I'll have to go looking for a pirated or cracked copy? As a game designer, start taking into account the fact that your game has to live alongside everything else on my computer and not cause problems for me when I'm doing all the things I do with the computer when I'm not playing your game.
3. Economics. Look at the target market for your game, and how much disposable cash members of that market will have. Then look at the price of your game. Can they afford to buy it? If you're pricing your game at $45, and targeting early teens, you're going to have rampant piracy. 13-15 year old kids don't have $45 burning a hole in their pocket. Especially not with the economy the way it is right now. And no, the fact that your game really is worth $45 isn't relevant. As people trying to sell homes they can't afford are finding out, the value of something isn't what it's worth, it's what a buyer can afford to pay for it. If the buyer can't afford the price, you'll have no buyers regardless of how good a deal it is. If you go about deliberately creating a demand for something in a market that can't afford the price you've set, don't be surprised when piracy goes through the roof. Either re-evaluate your target market, or re-evaluate your price.
4. Accessibility. How easy is it for members of your target market to buy the game? Again, if you're targeting early teens, they aren't going to have a credit card to buy on-line. If the game's also not readily available in stores, how are they supposed to buy it? And when it's available on-line, if it requires physical shipping (meaning a wait of several days to a week) people are going to go looking for alternatives like downloading. If getting your game legitimately is annoying, aggravating and takes a long time, and downloading a copy from a pirate site is convenient and fast, don't be surprised when people choose convenient and fast.
Note that this last one's a good example of a rule I got from an old shopkeeper friend: "Whatever you do as a store owner, never ever make it hard for the customer to give you their money.". A lot of on-line stores could stand to listen to that advice. I put my stuff in the cart, go to
I'm not surprised. Port randomization doesn't make the attack impossible, just harder. It doesn't eliminate the birthday attack, it just increases the space you have to blanket to generate a collision. The only real fix for the attack is DNSSEC, allowing the software to reject forged responses completely. Short of that, I can only think of two more things that'd help:
These don't completely close down the attack, but I can't think of anything else that makes it harder short of having responses cryptographically signed and the signature verified as coming from the expected source. We need to start pounding on domain owners to implement DNSSEC. Yes, that's work. Yes, it's neccesary.
Why's it hard to enforce? Something in an IFRAME isn't clearly and verifiably served by my bank's Web server, therefore I don't enter my account's password into it. Wasn't that easy? :)
The bank logo and custom phrase provide no assurance. Any black-hat that's managed to infiltrate the merchant's site can request the VbV/SC page from my bank and copy the supplied logo and phrase onto their malicious page. Making this worse, most VbV/SC implementations have the authentication in an IFRAME, so the URL bar provides me no information about what site the authentication form's coming from.
For VbV/SC to be secure, it has to work this way:
Anything else involves trusting a third party with my bank credentials, which is obviously insecure by definition.
Hardly impressive. Black-hat VbV site retrieves the legit page, displays a copy of it with only one change: submission goes to the black-hat server instead of the VbV site. When you submit, black-hat page records your information and passes the submit on to the VbV site. The black-hat now owns your bank account credentials and you're none the wiser. If I can figure out the basic method, someone who's actually an expert at Web development certainly can refine it into an actual attack.
If the URL bar doesn't point at the actual hostname your bank uses, you cannot trust anything on the page.
Look at it the other way: where do you think you're going to find experienced employees if they're all bound by non-compete agreements not to work for you?
One of the reasons I've avoided Verified by Visa is that the way they implement the "authentication" page it's impossible for the customer to tell whether they're entering their password into the Visa site or some random black-hat site. And I have a simple rule: I don't enter my account's password into any form that's not on a page clearly and verifiably served by my bank's Web server.
Of course, if I'm buying on a Web site, I'm most likely using my Amex card which doesn't have this issue. If the merchant doesn't take Amex, I'll go to one that does.
Probably CYA for the judge. It'd look bad to the judge if Tufts refused to co-operate with a plaintiff completely. But when Tufts says "If you can give us a formal legal request telling us what to preserve, we'll do our best to try and preserve it while you sort things out with the court. We don't really have to, we're not a party to your lawsuit and aren't obliged to help you out until you come to us with a court order, but being nice guys we're willing to try and work something out.", they look a lot better to the judge. And when, after they've made that offer, the RIAA comes along screaming about how unreasonable Tufts is being and how they should just give the RIAA what's demanded, the judge starts to wonder whether it's really Tufts being unreasonable here. After Tufts making that offer, if the RIAA just rejects it and demands more it makes it easier for the judge to slap the RIAA down for making undue demands on a non-party. And, not coincidentally, from the sounds of it by the time the RIAA goes through the whole legal procedure to get the information from Tufts it'll be long gone through the natural operation of their system (which they're not technically obliged to change until after the RIAA's gone through the legal procedure and served papers on them).
No. You're taking the position that downloads are authorized unless the person making them available knows they're unauthorized. The law takes the position that downloads are unauthorized unless the person making them available either has permission themselves or knows that the person asking for the download is authorized. So even if the person requesting the file is the copyright owner, as the person making it available to them you have to know that they're the copyright owner. If you don't, then the copy you made for them was unauthorized as far as the court's concerned. The recipient may be authorized (by definition, as the copyright holder) to make copies, but he didn't make the copy, you did, and as far as you knew at the time you didn't have authorization.
Bad analogy. To be a parallel the driver would've had to have been speeding upon and after seeing the cop, in which case the cop doesn't need to make any claim about what the driver would've done had he not seen the cop.
And if your position is correct, then no copyright holder can ever possibly make any claim of copyright infringement against anybody. To present the evidence, the copyright holder has to obtain the evidence. If the very act of him obtaining the evidence renders it not evidence of copyright infringement (because his receipt of it was authorized, therefore it's not an unauthorized copy), how can any copyright holder present any evidence of infringement? The law doesn't permit silly situations like that. And in any case, the recipient being the copyright holder is irrelevant. The violation isn't in receiving the copy, it's in making the copy without permission from the copyright holder. When the copyright holder asks you to make him a copy, he has not implicitly granted you any permission because copyright law contains no implicit permissions beyond fair use. So if you make a copy for him, it's still an unauthorized copy (he never gave you permission to make it). The only recourse you have is to show that you knew he was the copyright holder before you made the copy. That would let you take advantage of the shelter of the "acting at the direction of" portions of copyright law (ie. someone who has a right to make copies of something has a right to have someone else make those same copies if that someone else retains no control over the copies once made and delivered and does so only at the direction and under the control of the person with the right). But you can only take advantage of that if you know or have good reason to believe the person asking you really does have the right.
The relevant question the court would ask is "Did you know it was Josh Grobin when you made the copy for him?". If you didn't, then the fact that he was the copyright holder would be set aside as irrelevant. You didn't know that and yet you made the copy for him anyway, so the presumption is that you'd've done the same if he hadn't been Josh Grobin.
Could you, though? Sure, you can redirect me to your site and present a self-signed certificate. But are you hijacking the first connection I've made to this site? If you aren't, then you tip me off. I've already put the site's real self-signed certificate in my browser, so I'm expecting not to get warnings again. When the browser pops up the dialogs triggered by your unknown-to-my-browser self-signed certificate, this is something I'm not expecting. I'm going to look closer at the certificate to figure out why my browser's popping up a warning about something it shouldn't be.
No, mailing lists are not spam (at least not the ones with good opt-in subscription). And no, they don't become unsolicited. When you signed up, you did so knowing you were signing up for an ongoing subscription that would result in future mailings. You asked for those future mailings. From then on, those mailings that you asked for are solicited and remain so until such time as you tell the mailing list that you no longer want them (usually by unsubscribing). Whether you want them now or not is irrelevant to the question of whether you asked for them or not.
Because this isn't argument before the Supreme Court. It's not even before the Appeals Court. This is the original trial court this guy's being brought in for.
Because you're racing against the real DNS server, trying to beat it to providing a response. It's a lot easier to do that if you can start sending your faked responses as soon as you know the target's going to be listening. If you have to wait to see the target's request, you're starting the race already behind by the amount of network latency between you and your target. But if you can guess from the first request what port's going to be used for the second, you can start sending faked responses as soon as you know the target's sent it's request (you don't need to see the actual request to predict that timing in a lot of cases).
It's like winning a drag race. If you can time the sequence of the lights on the starting pole you can get on the gas and start to release the brakes before the light goes green, timing it so you'll start moving when the light will have turned green. That gives you a big jump on the guy who waits for the light to go green before starting to shove the gas pedal down.