No, MediaSentry is asking for a copy. If the distributor didn't make a copy upon request from MediaSentry and transmit it to them, they wouldn't receive a copy. It's the same thing as someone walking up to you and asking you for a copy of the CD you've got, and you making a copy for them and giving it to them. The question is, did the person MediaSentry downloaded the file from knowingly make the copy, or was it made by their computer without them realizing their computer would do something like that? Given the state of computer software and the level of knowledge of the average user, one can convincingly argue that they didn't realize.
As far as breaking the file into packets for transmission, the courts will regard that as an irrelevant artifact of the transmission medium, not relevant to the question of whether the distributor made a copy and sent it to the recipient upon request or not. And as a software engineer who writes network software for a living (and has for 25 years), the courts would be right to do so. If I put the entire file into a single huge packet and transmitted it, it wouldn't be broken into pieces but, from the standpoint of the network, that's simply a special case of transmitting a file in N packets (where N=1). And if you play rules mechanic like that with a judge, you'll quickly find out he's got tools to deal with you (like finding your argument unconvincing, and since you haven't presented any other argument he gets to hand your opponent their case on a silver platter).
Them connecting to the IP wouldn't be entrapment. Entrapment in the legal sense involves convincing someone to do something that, absent that pressure from the entrapping party, they wouldn't have had any inclination to do. In the case you posit there's no pressure from MediaSentry to do anything that IP address isn't fully prepared and willing to do in any case, so it's not entrapment any more than an undercover cop buying drugs from a willing dealer is.
The courts, like experienced RPG GMs, are quite familiar with rules mechanics, and have plenty of ways to deal with them.
Because the question isn't whether the recipient's authorized to receive the copy, it's whether the distributor's authorized to make the copy. If the distributor isn't authorized, then the copy is unauthorized regardless of the recipient. If it didn't work that way, it'd be impossible for any author to prosecute copyright infringement. The only evidence the author could produce would be copies he himself received (if he hadn't, he wouldn't have them to introduce into evidence), and the copyright holder of a work is by definition authorized to make copies. If the courts followed your logic, they'd have to immediately dismiss the author's case because the only copies he had introduced were authorized by virtue of his having received them. Which is obviously a ridiculous situation.
The described attack's a nasty tactic. I hadn't thought of it, or rather I had but discarded it under the impression that all DNS software had changed years ago to filter out additional RRs that weren't responsive to the actual query to prevent exactly this sort of attack. I hope Dan's patches include such a filter.
Been there, done that. Touchscreens will replace mice when they figure out how to make a conventional vertical screen that you can touch without holding your arm up in front of you. I'm not betting on that happening any time soon.
What's the problem? Well, first the problem is that you're assuming that every DNS lookup is from a Web browser. What happens to my copy of Eclipse, which is not a Web browser but uses DNS lookups and HTTP to find the servers to check for updated files? It depends on getting a "not found" DNS error to tell it when a server doesn't exist anymore, and it's going to have a real hard time when someone usurps that and hands it an HTML page instead of the file-version XML or HTTP 404 error it expects.
The Internet consists of more than humans looking at Web pages in a graphical Web browser.
In an ideal world, yes. But look at all the different syntaxes for all the different config files. How's the package manager supposed to know that it's just a comment that changed in the config file, as opposed to a critical setting or something major like a change from "name = value" to an XML syntax? As far as automatic migration, you're asking for CVS merge functionality. And being a professional software developer who's worked with version control systems and done merges, I can tell you I never completely trust automatic merges and they're never automatic. You always end up with conflicts that have to be manually resolved, and you always have cases where the merge result isn't right even though there aren't any conflicts. The closest you can get is a system like Debian's, where the configuration's stored by dpkg outside the config files. If there's a change, dpkg recreates the config from the stored answers to the configuration questions. And that's never fully automatic, the admin has to manually answer any new or changed config questions before dpkg can finish it's work and dpkg can't update fully-local config files that aren't under it's control (like the authoritative zones config for BIND).
Remember that, while DWIM sounds good in theory, in practice it results in things like "No results for 'rm *~', trying 'rm *' instead.".
This sounds like how RPM's behaved as long as I can remember. It looks at three versions of a config file: #1 the one from the old package, #2 the one currently on disk and #3 the one in the new package. If the config file hasn't been customized (1 and 2 are identical), it moves the old file to.rpmold (if 1 and 3 differ) and puts #3 into place. If the config file has been customized, it checks whether 1 and 3 differ. If they haven't then nothing's chanced, the customized config file's still valid and it drops #3 in with the.rpmnew extension. But if 1 and 3 differ, then something in the config file may have changed and the customized config file may no longer be valid. But it's got customizations in it that the admin may need to refer to. So it outputs a warning message about what it's doing, moves the customized config file to.rpmsave and installs #3, and the admin's expected to have seen the warning and to merge their customizations into the new config file. You do watch for warnings and errors during the update, right?
In this case RPM is right, old named.conf files aren't valid. If they're based off RH's old stock config files, they have the source port locked and that disables much of the security fix. So the admins do have to check and modify their customized files before the system's finally ready (or at least RPM has to assume they do, since it can't know exactly what their changes were). That's exacerbated by probably having caching-nameserver installed, but I think a stock BIND install has a similar named.conf until you add your own zones to it.
I'd chalk this one up to admins who a) don't understand an inherent limitation of package-management systems (namely, it doesn't know why you changed something, only that you changed it), b) didn't watch the update process for errors, and c) didn't check the systems for functionality after the update.
It's not Dell. When Dell calls up Microsoft to get XP licenses, MS responds "Sorry, no.". Backed up by the threat "If we find you getting OEM XP from anybody else, you lose all volume licensing for all Microsoft products. Vista, Office, everything. You try bypassing us, you get to pay full retail price for all of it. And we'll deactivate any keys we can associate with you, and tell your customers their copy was pirated and leave you to clean up the PR mess.".
And Dell has to suck it up and take it, because they can't afford to not sell computers with some form of Windows on them and they can't compete with other vendors if they've got to tack on an additional $300 or more to the price of every system (and their margins aren't enough to let them absorb that kind of additional cost).
No, only Vista Business and Ultimate OEM versions come with the right to downgrade to XP. Note that you don't have to buy XP, you just have to get access to XP installation media and do the activation over the phone.
Date-based versions don't help me very much. What I need/want from a version number is a clue as to how big the changes are. Is this version just bug-fixes and I shouldn't see much impact beyond fixing those errors? Is this a version that's got some significant enhancements and changes but my existing configuration should convert over without too much trouble and, while I'm going to see some impact, it shouldn't break my workflow and documents/code too badly? Or is this a big change with a whole new way of looking at large parts of the system, where I can expect major things to be a lot different and to have to adapt most everything to the new way the world is? The standard 3-part version numbers give me that kind of hint (at least when the developers stick to that accepted interpretation of the parts).
Simple way to defuse this tactic: maintain your own changelog on the Web site, and record in it when you change things and why. So when McCain comes up with "But did you know that Obama edited his site to change his position on A from X to Y?", Obama can respond "Well, yes, you should have known. It's right there on the "What's New" page: altered position page to reflect changes in my position as a result of studies on A by Doctors M and T. Do you have a reason why I shouldn't be taking their studies seriously?".
The basic problem is instant gratification. Spammers need to be able to create accounts or authenticate for posting quickly. Their business model doesn't allow for individual tries taking any significant amount of time, or requiring a side-channel conversation. CAPTCHAs and other anti-spam tactics all have one thing in common: they want to allow rapid authentication or account creation. And plain and simple, as long as those methods allow what the spammers need, you'll never keep the spammers out. If a computer can do it, a computer can un-do it.
You want to solve the spammer problem? Slow the process down. Make it involve a side-channel exchange. When someone creates an account to post, leave the account inactive and send them an e-mail with a verification code they need to enter to activate the account. Don't send it instantly, delay it by a couple of minutes. No need for fancy graphics or HTML, just plain text with the code in the middle of an explanatory paragraph that's word-wrapped automatically to a random 48-78 character column width to make it annoying to parse out the code automatically. Or if you don't want to block the account completely until verification, make it so any comments posted by it pre-verification aren't visible until a moderator approves them.
What we really need is a global identification scheme that acknowledges that what we want isn't accurate identification, it's continuity of identification. When someone posts to my journal, I don't need to know for certain who they truly are in real life. What I need is to be confident that the same physical person couldn't have gotten very many different, unconnected identities, and that when I see two different posts by the same identity that it's the same person behind both.
In the first case, yes. The EULA specifically prohibits account-sharing. In the second case, no. You paid for your second account, that gave you the license to run 2 copies of the software.
I notice you didn't mention one crucial step: talking to the employee. I wonder what his take on the situation was?
Most software developers are going to get invested in and protective of the systems they work on. In large part that's because they're proud of their work. It's also because they are the ones on the hook when things go south, regardless of who caused it. I don't know how often I've had this scenario play out:
Boss: "Can we do $X?"
Me: "Yes, we can. We'll need to approach it this way."
Boss: "We don't to do it that way. Can we do it this other way instead?"
Me: "Well, we can, but that's going straight against the way the system was designed to work. It'll be a kludge, and it'll make doing $Y all but impossible."
Boss: "We aren't going to have to worry about $Y. Just do it."
Me: "OK, but for the record I think it's a bad idea."
Six months after $X goes live the way the boss wants:
Boss: "Can we do $Y?"
Me: "Afraid not, not without a major reworking of the system. Remember we discussed this back when we were implementing $X, I told you that doing it the way you wanted it done would make doing $Y all but impossible?"
Boss: "WHAT! Why in blazes did you do it that way?! You knew we were going to do $Y! You incompetent idiot!"
Me: "... *sigh*"
After a few rounds like that, I get overly protective of the system design because the only way I know of to prevent that scenario is to stop it before it starts. And in at least one case it's resulted in me handing in my 2-weeks' notice to preserve my sanity.
It hardly beggars belief. Most large shops have a script or utility to change all the root/administrative passwords across the board in a single operation. You have to do that at least a couple of times a year for normal password rotation, having a single utility to do it saves a lot of work and keeps you from doing dumb things like mistyping the password on some of the machines. And of course when you have to terminate a sysadmin it makes it easier to change all the passwords as you revoke his access so he can't sneak in using his administrative access. Odds on the guy just used that same script/utility to change the passwords and then skipped the part of the procedure where the new password gets recorded and given to everybody else.
And there's one of the rubs: it's not just connecting to those servers. It's all the avatar appearance and clothing and objects you own and places you've built. If those don't move transparently, then it becomes a huge headache for users to maintain multiple virtual existences. And they likely won't move transparently.
One glitch in the summary: it don't work that way. Being able to have your own SL server doesn't get you access to Linden's grid. And that's what people want: to be on the grid with everybody else they know. If most of their friends are on the Linden grid, they'll want to be on it too and not off in some alternate grid where their friends aren't. And any alternate servers will have to get past the hurdle of establishing a big enough community to attract people or they won't last long.
It's MUCKs all over again. SL has better graphics and a different programming language, but at it's heart it's a MUCK and MUCK social dynamics applies.
As an end-user, to me it doesn't matter. If patches aren't available, I still need to know the details of the vulnerability so I can judge which of my systems need how much of their external access blocked or removed. To me, keeping it secret doesn't remove the vulnerability. I have to assume that, if it exists, the bad guys know about it and will use it. The only question for me is whether or not I know I need to take protective measures. If you say I don't need to, then I say "OK, let's you sign this contract making you liable for every penny of losses resulting from exploitation of that vulnerability.".
But that's a good reason for Google to look for Viacom employees uploading infringing content. One defense Google can raise is "Plaintiff can't keep it's own employees from doing X. How can they then in all fairness expect us to do what they can't or won't?". And yes, judges do listen to arguments like that. It can leave a plaintiff having to walk a very fine line or risk having their demand thrown out as unreasonable (by their own admission) or barred.
And while you have a right to put up a political sign, you do not have a right to put up a political sign on my property without my permission. This is not held to be an infringement of you right to free speech. You aren't being stopped from "speaking" on your own property, or on public property, or on the property of anyone who gives you permission to use it. You're just being stopped from infringing on someone else's right to control their own property. Roughly summarized, "Your right to swing your fist ends where my nose begins.".
And yes, it's my phone line. If it isn't, why am I the one paying the bill for it every month?
Or the FCC could point to Comcast themselves to support the FCC's position. According to this report at DSLReports, Comcast is arguing before a Federal judge that plaintiffs in California don't have standing to sue Comcast over the throttling because the FCC has sole authority over matters like that. If Comcast does win that argument, then all the FCC has to do is point to Comcast's successful argument and say "They've won the argument that we do have authority over this, they don't get to argue otherwise now.".
Slashdot Mirror
USC Title 17 Chapter 1 Section 117 paragraph (a).
No, MediaSentry is asking for a copy. If the distributor didn't make a copy upon request from MediaSentry and transmit it to them, they wouldn't receive a copy. It's the same thing as someone walking up to you and asking you for a copy of the CD you've got, and you making a copy for them and giving it to them. The question is, did the person MediaSentry downloaded the file from knowingly make the copy, or was it made by their computer without them realizing their computer would do something like that? Given the state of computer software and the level of knowledge of the average user, one can convincingly argue that they didn't realize.
As far as breaking the file into packets for transmission, the courts will regard that as an irrelevant artifact of the transmission medium, not relevant to the question of whether the distributor made a copy and sent it to the recipient upon request or not. And as a software engineer who writes network software for a living (and has for 25 years), the courts would be right to do so. If I put the entire file into a single huge packet and transmitted it, it wouldn't be broken into pieces but, from the standpoint of the network, that's simply a special case of transmitting a file in N packets (where N=1). And if you play rules mechanic like that with a judge, you'll quickly find out he's got tools to deal with you (like finding your argument unconvincing, and since you haven't presented any other argument he gets to hand your opponent their case on a silver platter).
Them connecting to the IP wouldn't be entrapment. Entrapment in the legal sense involves convincing someone to do something that, absent that pressure from the entrapping party, they wouldn't have had any inclination to do. In the case you posit there's no pressure from MediaSentry to do anything that IP address isn't fully prepared and willing to do in any case, so it's not entrapment any more than an undercover cop buying drugs from a willing dealer is.
The courts, like experienced RPG GMs, are quite familiar with rules mechanics, and have plenty of ways to deal with them.
No, P2P doesn't require uploading. I can download just fine from behind a firewall that prevents anybody else from downloading from me. See "leech".
Because the question isn't whether the recipient's authorized to receive the copy, it's whether the distributor's authorized to make the copy. If the distributor isn't authorized, then the copy is unauthorized regardless of the recipient. If it didn't work that way, it'd be impossible for any author to prosecute copyright infringement. The only evidence the author could produce would be copies he himself received (if he hadn't, he wouldn't have them to introduce into evidence), and the copyright holder of a work is by definition authorized to make copies. If the courts followed your logic, they'd have to immediately dismiss the author's case because the only copies he had introduced were authorized by virtue of his having received them. Which is obviously a ridiculous situation.
The described attack's a nasty tactic. I hadn't thought of it, or rather I had but discarded it under the impression that all DNS software had changed years ago to filter out additional RRs that weren't responsive to the actual query to prevent exactly this sort of attack. I hope Dan's patches include such a filter.
Two words: gorilla arm.
Been there, done that. Touchscreens will replace mice when they figure out how to make a conventional vertical screen that you can touch without holding your arm up in front of you. I'm not betting on that happening any time soon.
What's the problem? Well, first the problem is that you're assuming that every DNS lookup is from a Web browser. What happens to my copy of Eclipse, which is not a Web browser but uses DNS lookups and HTTP to find the servers to check for updated files? It depends on getting a "not found" DNS error to tell it when a server doesn't exist anymore, and it's going to have a real hard time when someone usurps that and hands it an HTML page instead of the file-version XML or HTTP 404 error it expects.
The Internet consists of more than humans looking at Web pages in a graphical Web browser.
In an ideal world, yes. But look at all the different syntaxes for all the different config files. How's the package manager supposed to know that it's just a comment that changed in the config file, as opposed to a critical setting or something major like a change from "name = value" to an XML syntax? As far as automatic migration, you're asking for CVS merge functionality. And being a professional software developer who's worked with version control systems and done merges, I can tell you I never completely trust automatic merges and they're never automatic. You always end up with conflicts that have to be manually resolved, and you always have cases where the merge result isn't right even though there aren't any conflicts. The closest you can get is a system like Debian's, where the configuration's stored by dpkg outside the config files. If there's a change, dpkg recreates the config from the stored answers to the configuration questions. And that's never fully automatic, the admin has to manually answer any new or changed config questions before dpkg can finish it's work and dpkg can't update fully-local config files that aren't under it's control (like the authoritative zones config for BIND).
Remember that, while DWIM sounds good in theory, in practice it results in things like "No results for 'rm *~', trying 'rm *' instead.".
This sounds like how RPM's behaved as long as I can remember. It looks at three versions of a config file: #1 the one from the old package, #2 the one currently on disk and #3 the one in the new package. If the config file hasn't been customized (1 and 2 are identical), it moves the old file to .rpmold (if 1 and 3 differ) and puts #3 into place. If the config file has been customized, it checks whether 1 and 3 differ. If they haven't then nothing's chanced, the customized config file's still valid and it drops #3 in with the .rpmnew extension. But if 1 and 3 differ, then something in the config file may have changed and the customized config file may no longer be valid. But it's got customizations in it that the admin may need to refer to. So it outputs a warning message about what it's doing, moves the customized config file to .rpmsave and installs #3, and the admin's expected to have seen the warning and to merge their customizations into the new config file. You do watch for warnings and errors during the update, right?
In this case RPM is right, old named.conf files aren't valid. If they're based off RH's old stock config files, they have the source port locked and that disables much of the security fix. So the admins do have to check and modify their customized files before the system's finally ready (or at least RPM has to assume they do, since it can't know exactly what their changes were). That's exacerbated by probably having caching-nameserver installed, but I think a stock BIND install has a similar named.conf until you add your own zones to it.
I'd chalk this one up to admins who a) don't understand an inherent limitation of package-management systems (namely, it doesn't know why you changed something, only that you changed it), b) didn't watch the update process for errors, and c) didn't check the systems for functionality after the update.
It's not Dell. When Dell calls up Microsoft to get XP licenses, MS responds "Sorry, no.". Backed up by the threat "If we find you getting OEM XP from anybody else, you lose all volume licensing for all Microsoft products. Vista, Office, everything. You try bypassing us, you get to pay full retail price for all of it. And we'll deactivate any keys we can associate with you, and tell your customers their copy was pirated and leave you to clean up the PR mess.".
And Dell has to suck it up and take it, because they can't afford to not sell computers with some form of Windows on them and they can't compete with other vendors if they've got to tack on an additional $300 or more to the price of every system (and their margins aren't enough to let them absorb that kind of additional cost).
No, only Vista Business and Ultimate OEM versions come with the right to downgrade to XP. Note that you don't have to buy XP, you just have to get access to XP installation media and do the activation over the phone.
Date-based versions don't help me very much. What I need/want from a version number is a clue as to how big the changes are. Is this version just bug-fixes and I shouldn't see much impact beyond fixing those errors? Is this a version that's got some significant enhancements and changes but my existing configuration should convert over without too much trouble and, while I'm going to see some impact, it shouldn't break my workflow and documents/code too badly? Or is this a big change with a whole new way of looking at large parts of the system, where I can expect major things to be a lot different and to have to adapt most everything to the new way the world is? The standard 3-part version numbers give me that kind of hint (at least when the developers stick to that accepted interpretation of the parts).
Simple way to defuse this tactic: maintain your own changelog on the Web site, and record in it when you change things and why. So when McCain comes up with "But did you know that Obama edited his site to change his position on A from X to Y?", Obama can respond "Well, yes, you should have known. It's right there on the "What's New" page: altered position page to reflect changes in my position as a result of studies on A by Doctors M and T. Do you have a reason why I shouldn't be taking their studies seriously?".
The basic problem is instant gratification. Spammers need to be able to create accounts or authenticate for posting quickly. Their business model doesn't allow for individual tries taking any significant amount of time, or requiring a side-channel conversation. CAPTCHAs and other anti-spam tactics all have one thing in common: they want to allow rapid authentication or account creation. And plain and simple, as long as those methods allow what the spammers need, you'll never keep the spammers out. If a computer can do it, a computer can un-do it.
You want to solve the spammer problem? Slow the process down. Make it involve a side-channel exchange. When someone creates an account to post, leave the account inactive and send them an e-mail with a verification code they need to enter to activate the account. Don't send it instantly, delay it by a couple of minutes. No need for fancy graphics or HTML, just plain text with the code in the middle of an explanatory paragraph that's word-wrapped automatically to a random 48-78 character column width to make it annoying to parse out the code automatically. Or if you don't want to block the account completely until verification, make it so any comments posted by it pre-verification aren't visible until a moderator approves them.
What we really need is a global identification scheme that acknowledges that what we want isn't accurate identification, it's continuity of identification. When someone posts to my journal, I don't need to know for certain who they truly are in real life. What I need is to be confident that the same physical person couldn't have gotten very many different, unconnected identities, and that when I see two different posts by the same identity that it's the same person behind both.
In the first case, yes. The EULA specifically prohibits account-sharing. In the second case, no. You paid for your second account, that gave you the license to run 2 copies of the software.
I notice you didn't mention one crucial step: talking to the employee. I wonder what his take on the situation was?
Most software developers are going to get invested in and protective of the systems they work on. In large part that's because they're proud of their work. It's also because they are the ones on the hook when things go south, regardless of who caused it. I don't know how often I've had this scenario play out:
Boss: "Can we do $X?"
Me: "Yes, we can. We'll need to approach it this way."
Boss: "We don't to do it that way. Can we do it this other way instead?"
Me: "Well, we can, but that's going straight against the way the system was designed to work. It'll be a kludge, and it'll make doing $Y all but impossible."
Boss: "We aren't going to have to worry about $Y. Just do it."
Me: "OK, but for the record I think it's a bad idea."
Six months after $X goes live the way the boss wants:
Boss: "Can we do $Y?" Me: "Afraid not, not without a major reworking of the system. Remember we discussed this back when we were implementing $X, I told you that doing it the way you wanted it done would make doing $Y all but impossible?"
Boss: "WHAT! Why in blazes did you do it that way?! You knew we were going to do $Y! You incompetent idiot!"
Me: "... *sigh*"
After a few rounds like that, I get overly protective of the system design because the only way I know of to prevent that scenario is to stop it before it starts. And in at least one case it's resulted in me handing in my 2-weeks' notice to preserve my sanity.
It hardly beggars belief. Most large shops have a script or utility to change all the root/administrative passwords across the board in a single operation. You have to do that at least a couple of times a year for normal password rotation, having a single utility to do it saves a lot of work and keeps you from doing dumb things like mistyping the password on some of the machines. And of course when you have to terminate a sysadmin it makes it easier to change all the passwords as you revoke his access so he can't sneak in using his administrative access. Odds on the guy just used that same script/utility to change the passwords and then skipped the part of the procedure where the new password gets recorded and given to everybody else.
And there's one of the rubs: it's not just connecting to those servers. It's all the avatar appearance and clothing and objects you own and places you've built. If those don't move transparently, then it becomes a huge headache for users to maintain multiple virtual existences. And they likely won't move transparently.
One glitch in the summary: it don't work that way. Being able to have your own SL server doesn't get you access to Linden's grid. And that's what people want: to be on the grid with everybody else they know. If most of their friends are on the Linden grid, they'll want to be on it too and not off in some alternate grid where their friends aren't. And any alternate servers will have to get past the hurdle of establishing a big enough community to attract people or they won't last long.
It's MUCKs all over again. SL has better graphics and a different programming language, but at it's heart it's a MUCK and MUCK social dynamics applies.
As an end-user, to me it doesn't matter. If patches aren't available, I still need to know the details of the vulnerability so I can judge which of my systems need how much of their external access blocked or removed. To me, keeping it secret doesn't remove the vulnerability. I have to assume that, if it exists, the bad guys know about it and will use it. The only question for me is whether or not I know I need to take protective measures. If you say I don't need to, then I say "OK, let's you sign this contract making you liable for every penny of losses resulting from exploitation of that vulnerability.".
But that's a good reason for Google to look for Viacom employees uploading infringing content. One defense Google can raise is "Plaintiff can't keep it's own employees from doing X. How can they then in all fairness expect us to do what they can't or won't?". And yes, judges do listen to arguments like that. It can leave a plaintiff having to walk a very fine line or risk having their demand thrown out as unreasonable (by their own admission) or barred.
And while you have a right to put up a political sign, you do not have a right to put up a political sign on my property without my permission. This is not held to be an infringement of you right to free speech. You aren't being stopped from "speaking" on your own property, or on public property, or on the property of anyone who gives you permission to use it. You're just being stopped from infringing on someone else's right to control their own property. Roughly summarized, "Your right to swing your fist ends where my nose begins.".
And yes, it's my phone line. If it isn't, why am I the one paying the bill for it every month?
Or the FCC could point to Comcast themselves to support the FCC's position. According to this report at DSLReports, Comcast is arguing before a Federal judge that plaintiffs in California don't have standing to sue Comcast over the throttling because the FCC has sole authority over matters like that. If Comcast does win that argument, then all the FCC has to do is point to Comcast's successful argument and say "They've won the argument that we do have authority over this, they don't get to argue otherwise now.".
Oh, you will. The shove was towards Earth, normal to the orbital path, remember?