Please show me in his post where he says that damages should only count for the original download. You seem to be putting words in his mouth.
"record company's lost profit is in the neighborhood of 35 cents"
That statement can only be true if you're talking about the original download. Distribution rights are far more expensive.
Well, the record company didn't lose the distribution rights, so those aren't damanges.
I can see how reasonable actual (not statuary) damages would include the song the downloader didn't pay for, along with all uploaded copies of the song not paid for. That's a bit of double counting, but not outside the scope of reasonable — it counts all damages that the defendant was involved in as completely the defendant's fault, which is normal.
True. Certainly software engineers (in particular, the companies they work for) need to start discussing things like security early in the negotiation process. The civil engineering analogy is overused, but still applicable in many ways.
On the other hand, some things like static code analysis when using unsafe languages don't really cost much time. Would it really take that much longer to complete the project if you had a static code analysis as a commit hook? Certainly some projects do this, but it's far from universal. I can't see anything to blame it on other than laziness or ignorance. (In most cases. I suppose there might be exceptions, but I'm having trouble thinking of one.)
The reason people don't do it is because it is time consuming and therefore expensive. The customers are not willing to pay.
In general, the engineer is the one with the knowledge that this is a big problem. I suspect most customers don't want insecure software. They just don't realize in advance how much insecure software costs them, and how to ask for secure software. What's more, frequently the people hurt by the security problems aren't the ones paying for the software.
To use the (awful, overused) civil engineering analogy, we don't let customers contract for an unsafe building design. As the expert, it's the civil engineer's job to be aware of the safety requirements implied by a contract. Similarly, it's the software engineer's job to be aware of the security implications.
So yeah, there's plenty of blame to go around. To the customers, and the developers, and the lack of regulation of the sort other engineering disciplines have when they put uninvolved people at risk. Security flaws in software don't usually put uninvolved parties at physical risk, but financial risk is certainly common enough, and physical risk isn't completely unheard of. Witness Windows viruses in medical equipment, for example. Of course, given the level of understanding of the issues government regulators are likely to have, regulation might be a cure worse than the disease.
a novel way to prevent them: by drafting contracts that hold developers responsible when bugs creep into applications
Holding a gun to somebody's head won't make them a better developer.
I don't understand why well-known and tested techniques can't be used to catch these bugs.
Yeah, but you can keep them from doing it again.
The reason people don't use these well-known techniques is very simple: it takes time and effort, and people are lazy. So until the customer tells them to, they won't bother.
Which brings me to my biggest objection to this proposed contract. There's lots of documentation requirements, and no assignment of liability. Documentation is expensive to produce, and much of this I really don't care about. (Exception: the document on how to secure the delivered software, and security implications of config options, is an excellent idea.) For most of the documentation requirements, I don't really need to hear how you plan to do it: I just need to know that, if you screw up, you're going to be (at least partially) financially liable. And yet, the contract fails to specify that. What happens when there *is* a security breach, despite all the documentation saying the software is secure? If the procedures weren't followed, then that's obviously a breach of contract — but what if there was a problem anyway?
I actually like designating a single person in charge of security. Finding someone to blame after the fact is a horrible idea. However, having someone who's job it is to pay attention early, with the authority to do something about it is an excellent way to make sure it doesn't just fall through the cracks. By requiring their personal signoff on deliverables, you give them the power they need to be effective. (Of course, if management inside your vendor is so bad that they get forced into just rubber-stamping everything, that's a different problem. But if you wanted to micromanage every detail of how your vendor does things internally, why are you contracting to a vendor?)
It can be very hard to tell whether a specific claim is fraud or not, yet easy to tell approximately how many fraud claims there are. A dramatic rise in claims when a new model is released would be a clue. Of course, that's not a complete indicator -- there are certainly some of those claims where people had a minor problem and weren't willing to deal with the hassle of getting the phone replaced, but were once a new model was available and they could upgrade at the same time. But, in general, the insurance actuaries are smart -- they're probably in the right ballpark about how much fraud there is, even if they can't always tell which claims are fraudulent.
(Of course, they're also motivated to have the numbers come out a certain way. But IMHO that's more likely to distort them somewhat than it is to mean they were completely fabricated.)
At speeds that high, friction doesn't work like you'd expect. Specifically, the gas is sparse enough (and your ship small enough) that the mean free path of the atoms is long; that means you can't establish a bow shock in front that gets the gas out of the way. This actually reduces drag (you interact with less of the gas -- only that portion actually directly in front of you), but means that the drag you do get behaves differently. Each atom hits your ship at full speed, not the reduced (relative) speed that you get in atmosphere after the gas goes through the bow shock. The result is that the gas atoms / molecules don't hit and bounce off; they're going so fast they hit, ionize, chemically react, embed themselves in your hull, and then possibly leak back out much later. In other words, the angle they hit at is irrelevant, and only the frontal area matters.
(This is all somewhat approximate; it's only mostly true at conditions such as those in low Earth orbit. However, it should be a very good approximation at near-c speeds in the interstellar medium.)
In other news, in the real world, adding chips to a design doesn't just cost component + assembly costs. It also increases the size of the device, and possibly the power consumption (though these can probably be put into a low enough power mode that it doesn't matter).
Making the device larger and heavier isn't something that's done lightly. Sure, this would only add a little bit, but *any* individual feature only adds a little bit. You have to draw a line somewhere.
That said, I'd like it better if it supported more networks, too...
You clearly haven't looked at CPU usage graphs by core when using Firefox. On a complex page, one core will stay at 100% for several seconds, while the other sits underused (10-30%, mostly depending on other stuff, it seems). Those hundreds of other processes aren't doing much.
It is a mathematical discovery about the properties of the equations that we think describe the particle behavior. Assuming their math was correct, it is a mathematical discovery like any other, but in a highly limited area (this specific set of equations). Whether it is a mathematical discovery that is also a description of physical reality depends on whether those equations actually describe particle behavior at those energy levels, which we don't yet know.
Most of us who've bothered to think about it much aren't begging the question; we've considered it, answered it, moved on, and see no need to keep bringing it up.
It really shouldn't surprise you that you're in the minority on that view, even among people who've stopped to think about it.
Complex theories often make many complex predictions. If we have a theory that particles and gravity and such behave as described by this set of equations, it isn't necessarily trivial to answer questions like "Is there some set of initial conditions that will produce a state some time later with these properties?" You have to work out how the question should phrased in precise mathematical terms, and then do a lot of math to get an answer. This is properly viewed as something in between a mathematical discovery and a physical one: like discovering a proof of a previously unproven hypothesis in math, the axioms (particle behavior equations) already defined the answer, we just didn't know it yet. Of course, it's based on highly specific models and may have little general applicability, unlike most theorems in mathematics that are based on a fairly simple set of axioms.
Did you read Stevens' dissent? Y'know, the thing that would have resulted as precedent had Kennedy voted with Stevens. No? Cause if you had you would have noticed it treated speech strictly as audible noise.
The dissenting opinion being worse does not make the majority opinion a good one, or an improvement over the status quo.
Have you worked with rockets? I have, both professionally and as a hobby. The current norm for orbital launchers is hugely complex engines. The vast majority of that complexity is in ultra-high-performance turbopumps and the turbines that drive them. The remainder is a direct result of very high chamber pressures, and a desire to make the chamber and nozzle as light as possible.
At the other extreme, a pressure fed rocket can be very simple. It has two tanks, pressurized either before launch or from a pressurant tank plus regulator and valves. Either is very simple. It then has a main propellant valve for each propellant, an optional throttle valve, and a chamber + nozzle. Additionally, there's an igniter (possibly two for redundancy), with their own (small) valves. That's it. There are no pumps or other high-speed machinery. You keep the chamber pressure low, which reduces heat load and wall stress. All of this adds weight (mostly in the heavier tanks that have to contain the pressure) and reduces Isp, but that was the point — trade those off for reduced cost.
The result is an engine that takes some design work (injectors and cooling passages aren't as complicated as pumps, but they're not trivial either), but where the complexity is all in the shapes of parts that don't actually have to move, and are put under stress levels that are no different than you'd find in your car.
Re-entry is complex, and as yet unsolved; but there are many promising options, including things like replaceable ablative heat shields that use well-tested technology. Explosive fuel is a red herring: rockets explode when the engines fail, not because the fuel decides it feels like it. Industrial users have no trouble moving around quantities of LOX and kerosene comparable or larger than even the largest rockets, without incidents.
The problem isn't that rockets have to be complex; it's just that we insist on building them that way. There are other ways.
It's not the barrel that's the hard part (though the barrels tend to wear out too). It's all the valves and compression cylinders associated with getting the propellant gas into the main gun barrel. And the main gun barrel isn't just a smooth bore barrel — at a minimum, it has a bunch of gas inlet ports along its length, with their associated edges.
Light gas guns are most emphatically not the same as simple powder weapons.
No, that isn't what's expensive. What's expensive is the engines that burn that propellant. And those could get vastly cheaper, if that was a serious design goal. Note that "serious design goal" means a willingness on the part of the engineers to pay for it with reduced performance.
As Elon Musk (of SpaceX) put it, the cost of propellant on a large rocket is less than the accounting errors. And that includes the propellant to lift the propellant.
Space launch guns are not nearly as simple as firearms. The proposals I've seen discussed tend to be things like multi-stage light gas guns, which are anything but simple. They have a variety of parts that must operate at high pressures, temperatures, and velocities. That means the parts tend to wear out. Lab experience of people building such guns (for purposes like high velocity impact testing, metallic hydrogen creation via impact, etc) agrees with this assessment. I'm sure that a production gun, with effort spent on reliability and ease of maintenance, would improve things — but the core problem wouldn't simply vanish.
My point is that rockets don't have to be complicated. Rocket engines currently in use are, and they wear out rapidly. But, a pressure fed rocket can be a very simple device. Fundamentally, it can be done with the only moving parts being the main propellant valves and the valves used to fill and pressurize the tanks. In practice, you'll probably also have a couple valves associated with your reusable igniter, and you may want separate on/off and throttle valves on the main engine, for a total of six valves and five actuators (main valves on a common shaft improves safety and reliability and reduces parts count).
A pure pressure fed rocket is a bit overly simple; it sacrifices too much performance due to low chamber pressure and heavy tanks. But there is a whole world of design space that lies in between the ultra-simple pressure fed rocket and the ultra-complex high pressure turbopumped rockets like the SSME and RD-180. That's the space I'm advocating exploring.
You can make rocket engines that are simpler and more reliable, and effectively don't wear out. What you sacrifice is a bit of performance. But, on balance, the result is cheaper. Liftoff mass doesn't matter (directly); cost does.
I'm advocating replacing complex, high-maintenance, mostly-non-reusable or semi-reusable rocket engines with simpler, lower performance, vastly cheaper, low-maintenance ones. Guns are complex, expensive, and high-maintenance, like current rocket engines. (If you think guns are simple, you haven't looked at the sort of multi-stage high-temperature light gas gun designs required to reach orbital or near-orbital velocities.)
The problem with guns, elevators, pinwheels, launch loops, etc is the spectacularly large capital costs. Guns are worse than most because they're special-purpose (high-g-capable cargo only) and wear out relatively quickly. Most people advocating such designs seem to confound the issue by assuming they can build a reasonably low-overhead business around them, but then comparing to rockets built the way they have been in the past. The fair comparison is to the same budget, spent on rocket R&D and fleet construction, in a low-overhead business. At that point, the rockets look a lot more competitive. (Space elevators are particularly guilty; give me a space-elevator class composite, and I'll give you a pressure-fed SSTO rocket fleet for less capital cost.)
The reason space is expensive has more to do with the complexity of the rocket engines and the companies that build them than the propellant. If you want cheap access to space, focus on that. Capital-intensive projects that put heavy wear on their components (like guns) won't make things cheaper. The goal should be to *reduce* the number of parts that need maintenance.
According to the DMCA, someone's signature needs to be on the notice, and that person is asserting under penalty of perjury that the notice is valid. The recipient probably won't fight back, but if they do you might be in trouble.
Would it be possible to use DMCA to force people pull down pics with your face on them?
Sure, assuming you own the copyright to the photos. Normally the photographer owns the copyright, so normally you can't (assuming that, since you were in the photo, you weren't the photographer).
Of course, the stuff around model releases and such gets more complicated, but that has little to do with copyright and therefore the DMCA.
Well, I'm not sure. The effects of porn might well be negligible.
The internet certainly makes porn rather easier to get than it has been in the recent past; but I'm not sure that it is something to get all that worked up over. Heck, the ability to afford enough rooms that the kids don't have to watch their parents, and the whole family doesn't have to watch the livestock, is a fairly recent innovation, on the historical scale.
Given the lack of sexual education our society seems to have, can't watch their parents and livestock might be a better description.
Slashdot Mirror
Please show me in his post where he says that damages should only count for the original download. You seem to be putting words in his mouth.
"record company's lost profit is in the neighborhood of 35 cents"
That statement can only be true if you're talking about the original download. Distribution rights are far more expensive.
Well, the record company didn't lose the distribution rights, so those aren't damanges.
I can see how reasonable actual (not statuary) damages would include the song the downloader didn't pay for, along with all uploaded copies of the song not paid for. That's a bit of double counting, but not outside the scope of reasonable — it counts all damages that the defendant was involved in as completely the defendant's fault, which is normal.
True. Certainly software engineers (in particular, the companies they work for) need to start discussing things like security early in the negotiation process. The civil engineering analogy is overused, but still applicable in many ways.
On the other hand, some things like static code analysis when using unsafe languages don't really cost much time. Would it really take that much longer to complete the project if you had a static code analysis as a commit hook? Certainly some projects do this, but it's far from universal. I can't see anything to blame it on other than laziness or ignorance. (In most cases. I suppose there might be exceptions, but I'm having trouble thinking of one.)
You're still just blaming the engineer.
The reason people don't do it is because it is time consuming and therefore expensive. The customers are not willing to pay.
In general, the engineer is the one with the knowledge that this is a big problem. I suspect most customers don't want insecure software. They just don't realize in advance how much insecure software costs them, and how to ask for secure software. What's more, frequently the people hurt by the security problems aren't the ones paying for the software.
To use the (awful, overused) civil engineering analogy, we don't let customers contract for an unsafe building design. As the expert, it's the civil engineer's job to be aware of the safety requirements implied by a contract. Similarly, it's the software engineer's job to be aware of the security implications.
So yeah, there's plenty of blame to go around. To the customers, and the developers, and the lack of regulation of the sort other engineering disciplines have when they put uninvolved people at risk. Security flaws in software don't usually put uninvolved parties at physical risk, but financial risk is certainly common enough, and physical risk isn't completely unheard of. Witness Windows viruses in medical equipment, for example. Of course, given the level of understanding of the issues government regulators are likely to have, regulation might be a cure worse than the disease.
Holding a gun to somebody's head won't make them a better developer.
I don't understand why well-known and tested techniques can't be used to catch these bugs.
Yeah, but you can keep them from doing it again.
The reason people don't use these well-known techniques is very simple: it takes time and effort, and people are lazy. So until the customer tells them to, they won't bother.
Which brings me to my biggest objection to this proposed contract. There's lots of documentation requirements, and no assignment of liability. Documentation is expensive to produce, and much of this I really don't care about. (Exception: the document on how to secure the delivered software, and security implications of config options, is an excellent idea.) For most of the documentation requirements, I don't really need to hear how you plan to do it: I just need to know that, if you screw up, you're going to be (at least partially) financially liable. And yet, the contract fails to specify that. What happens when there *is* a security breach, despite all the documentation saying the software is secure? If the procedures weren't followed, then that's obviously a breach of contract — but what if there was a problem anyway?
I actually like designating a single person in charge of security. Finding someone to blame after the fact is a horrible idea. However, having someone who's job it is to pay attention early, with the authority to do something about it is an excellent way to make sure it doesn't just fall through the cracks. By requiring their personal signoff on deliverables, you give them the power they need to be effective. (Of course, if management inside your vendor is so bad that they get forced into just rubber-stamping everything, that's a different problem. But if you wanted to micromanage every detail of how your vendor does things internally, why are you contracting to a vendor?)
It can be very hard to tell whether a specific claim is fraud or not, yet easy to tell approximately how many fraud claims there are. A dramatic rise in claims when a new model is released would be a clue. Of course, that's not a complete indicator -- there are certainly some of those claims where people had a minor problem and weren't willing to deal with the hassle of getting the phone replaced, but were once a new model was available and they could upgrade at the same time. But, in general, the insurance actuaries are smart -- they're probably in the right ballpark about how much fraud there is, even if they can't always tell which claims are fraudulent.
(Of course, they're also motivated to have the numbers come out a certain way. But IMHO that's more likely to distort them somewhat than it is to mean they were completely fabricated.)
At speeds that high, friction doesn't work like you'd expect. Specifically, the gas is sparse enough (and your ship small enough) that the mean free path of the atoms is long; that means you can't establish a bow shock in front that gets the gas out of the way. This actually reduces drag (you interact with less of the gas -- only that portion actually directly in front of you), but means that the drag you do get behaves differently. Each atom hits your ship at full speed, not the reduced (relative) speed that you get in atmosphere after the gas goes through the bow shock. The result is that the gas atoms / molecules don't hit and bounce off; they're going so fast they hit, ionize, chemically react, embed themselves in your hull, and then possibly leak back out much later. In other words, the angle they hit at is irrelevant, and only the frontal area matters.
(This is all somewhat approximate; it's only mostly true at conditions such as those in low Earth orbit. However, it should be a very good approximation at near-c speeds in the interstellar medium.)
Furthermore, they won't save a lot of gas when driving at constant and/or high speeds, such as highway or a race track.
Clearly you missed part of the summary: this is not a NASCAR race.
You say that as though they have a monopoly on it. This is not a partisan issue.
In other news, in the real world, adding chips to a design doesn't just cost component + assembly costs. It also increases the size of the device, and possibly the power consumption (though these can probably be put into a low enough power mode that it doesn't matter).
Making the device larger and heavier isn't something that's done lightly. Sure, this would only add a little bit, but *any* individual feature only adds a little bit. You have to draw a line somewhere.
That said, I'd like it better if it supported more networks, too...
You clearly haven't looked at CPU usage graphs by core when using Firefox. On a complex page, one core will stay at 100% for several seconds, while the other sits underused (10-30%, mostly depending on other stuff, it seems). Those hundreds of other processes aren't doing much.
It is a mathematical discovery about the properties of the equations that we think describe the particle behavior. Assuming their math was correct, it is a mathematical discovery like any other, but in a highly limited area (this specific set of equations). Whether it is a mathematical discovery that is also a description of physical reality depends on whether those equations actually describe particle behavior at those energy levels, which we don't yet know.
Most of us who've bothered to think about it much aren't begging the question; we've considered it, answered it, moved on, and see no need to keep bringing it up.
It really shouldn't surprise you that you're in the minority on that view, even among people who've stopped to think about it.
Complex theories often make many complex predictions. If we have a theory that particles and gravity and such behave as described by this set of equations, it isn't necessarily trivial to answer questions like "Is there some set of initial conditions that will produce a state some time later with these properties?" You have to work out how the question should phrased in precise mathematical terms, and then do a lot of math to get an answer. This is properly viewed as something in between a mathematical discovery and a physical one: like discovering a proof of a previously unproven hypothesis in math, the axioms (particle behavior equations) already defined the answer, we just didn't know it yet. Of course, it's based on highly specific models and may have little general applicability, unlike most theorems in mathematics that are based on a fairly simple set of axioms.
Did you read Stevens' dissent? Y'know, the thing that would have resulted as precedent had Kennedy voted with Stevens. No? Cause if you had you would have noticed it treated speech strictly as audible noise.
The dissenting opinion being worse does not make the majority opinion a good one, or an improvement over the status quo.
Have you worked with rockets? I have, both professionally and as a hobby. The current norm for orbital launchers is hugely complex engines. The vast majority of that complexity is in ultra-high-performance turbopumps and the turbines that drive them. The remainder is a direct result of very high chamber pressures, and a desire to make the chamber and nozzle as light as possible.
At the other extreme, a pressure fed rocket can be very simple. It has two tanks, pressurized either before launch or from a pressurant tank plus regulator and valves. Either is very simple. It then has a main propellant valve for each propellant, an optional throttle valve, and a chamber + nozzle. Additionally, there's an igniter (possibly two for redundancy), with their own (small) valves. That's it. There are no pumps or other high-speed machinery. You keep the chamber pressure low, which reduces heat load and wall stress. All of this adds weight (mostly in the heavier tanks that have to contain the pressure) and reduces Isp, but that was the point — trade those off for reduced cost.
The result is an engine that takes some design work (injectors and cooling passages aren't as complicated as pumps, but they're not trivial either), but where the complexity is all in the shapes of parts that don't actually have to move, and are put under stress levels that are no different than you'd find in your car.
Re-entry is complex, and as yet unsolved; but there are many promising options, including things like replaceable ablative heat shields that use well-tested technology. Explosive fuel is a red herring: rockets explode when the engines fail, not because the fuel decides it feels like it. Industrial users have no trouble moving around quantities of LOX and kerosene comparable or larger than even the largest rockets, without incidents.
The problem isn't that rockets have to be complex; it's just that we insist on building them that way. There are other ways.
It's not the barrel that's the hard part (though the barrels tend to wear out too). It's all the valves and compression cylinders associated with getting the propellant gas into the main gun barrel. And the main gun barrel isn't just a smooth bore barrel — at a minimum, it has a bunch of gas inlet ports along its length, with their associated edges.
Light gas guns are most emphatically not the same as simple powder weapons.
No, that isn't what's expensive. What's expensive is the engines that burn that propellant. And those could get vastly cheaper, if that was a serious design goal. Note that "serious design goal" means a willingness on the part of the engineers to pay for it with reduced performance.
As Elon Musk (of SpaceX) put it, the cost of propellant on a large rocket is less than the accounting errors. And that includes the propellant to lift the propellant.
Space launch guns are not nearly as simple as firearms. The proposals I've seen discussed tend to be things like multi-stage light gas guns, which are anything but simple. They have a variety of parts that must operate at high pressures, temperatures, and velocities. That means the parts tend to wear out. Lab experience of people building such guns (for purposes like high velocity impact testing, metallic hydrogen creation via impact, etc) agrees with this assessment. I'm sure that a production gun, with effort spent on reliability and ease of maintenance, would improve things — but the core problem wouldn't simply vanish.
My point is that rockets don't have to be complicated. Rocket engines currently in use are, and they wear out rapidly. But, a pressure fed rocket can be a very simple device. Fundamentally, it can be done with the only moving parts being the main propellant valves and the valves used to fill and pressurize the tanks. In practice, you'll probably also have a couple valves associated with your reusable igniter, and you may want separate on/off and throttle valves on the main engine, for a total of six valves and five actuators (main valves on a common shaft improves safety and reliability and reduces parts count).
A pure pressure fed rocket is a bit overly simple; it sacrifices too much performance due to low chamber pressure and heavy tanks. But there is a whole world of design space that lies in between the ultra-simple pressure fed rocket and the ultra-complex high pressure turbopumped rockets like the SSME and RD-180. That's the space I'm advocating exploring.
You can make rocket engines that are simpler and more reliable, and effectively don't wear out. What you sacrifice is a bit of performance. But, on balance, the result is cheaper. Liftoff mass doesn't matter (directly); cost does.
I'm advocating replacing complex, high-maintenance, mostly-non-reusable or semi-reusable rocket engines with simpler, lower performance, vastly cheaper, low-maintenance ones. Guns are complex, expensive, and high-maintenance, like current rocket engines. (If you think guns are simple, you haven't looked at the sort of multi-stage high-temperature light gas gun designs required to reach orbital or near-orbital velocities.)
The problem with guns, elevators, pinwheels, launch loops, etc is the spectacularly large capital costs. Guns are worse than most because they're special-purpose (high-g-capable cargo only) and wear out relatively quickly. Most people advocating such designs seem to confound the issue by assuming they can build a reasonably low-overhead business around them, but then comparing to rockets built the way they have been in the past. The fair comparison is to the same budget, spent on rocket R&D and fleet construction, in a low-overhead business. At that point, the rockets look a lot more competitive. (Space elevators are particularly guilty; give me a space-elevator class composite, and I'll give you a pressure-fed SSTO rocket fleet for less capital cost.)
The reason space is expensive has more to do with the complexity of the rocket engines and the companies that build them than the propellant. If you want cheap access to space, focus on that. Capital-intensive projects that put heavy wear on their components (like guns) won't make things cheaper. The goal should be to *reduce* the number of parts that need maintenance.
More than once... and it's a lot more likely to happen to you if you don't have lots of money and lawyers.
According to the DMCA, someone's signature needs to be on the notice, and that person is asserting under penalty of perjury that the notice is valid. The recipient probably won't fight back, but if they do you might be in trouble.
Would it be possible to use DMCA to force people pull down pics with your face on them?
Sure, assuming you own the copyright to the photos. Normally the photographer owns the copyright, so normally you can't (assuming that, since you were in the photo, you weren't the photographer).
Of course, the stuff around model releases and such gets more complicated, but that has little to do with copyright and therefore the DMCA.
What ill effects, exactly, do you fear?
Well, I'm not sure. The effects of porn might well be negligible.
The internet certainly makes porn rather easier to get than it has been in the recent past; but I'm not sure that it is something to get all that worked up over. Heck, the ability to afford enough rooms that the kids don't have to watch their parents, and the whole family doesn't have to watch the livestock, is a fairly recent innovation, on the historical scale.
Given the lack of sexual education our society seems to have, can't watch their parents and livestock might be a better description.
How about "Firefox 3.5 passes IE 7 in popularity"?