Insecure Software Costs US $180B per Year - Application and Perimeter Security News Analysis - Dark Reading

[leichter_jerrold at emc.com (Leichter, Jerry)]

| >     Just as a traditional manufacturer would pay less tax by
| >     becoming "greener," the software manufacturer would pay less tax
| >     for producing "cleaner" code, [...]
| 
| > One could, I suppose, give rebates based on actual field experience:
| > Look at the number of security problems reported per year over a
| > two-year period and give rebates to sellers who have low rates.
| 
| And all of this completely ignores the $0 software "market".  (I'm
| carefully not saying "free", since that has too many other meanings,
| some of which have been perverted in recent years to mean just about
| the opposite of what they should.)  Who gets hit with tax when a bug
| is found in, say, the Linux kernel?  Why?
I'll answer this along my understanding of the lines of the proposal at
hand.  I have my doubts about the whole idea, for a number of reasons,
but if we grant that it's appropriate for for-fee software, it's easy
decide what happens with free software - though you won't like the
answer:  The user of the software pays anyway.  The cost is computed in
some other way than as a percentage of the price - it's no clear exactly
how.  Most likely, it would be the same tax as is paid by competing
non-free software with a similar security record.  (What you do when
there is no such software to compare against is an interesting problem
for some economist to work on.)

The argument the author is making is that security problems impose costs
on *everyone*, not just on the party running the software.  This is a
classic economic problem:  If a party can externalize its costs - i.e.,
dump them on other parties - its incentives become skewed.  Right now,
the costs of security problems for most vendors are externalized.
Where do they do?  We usually think of them as born by that vendor's
customers.  To the degree that's so, the customers will have an
incentive to push costs back on to the vendor, and eventually market
mechanisms will clean things up.  To some degree, that's happened to
Microsoft:  However effective or ineffective their security efforts,
it's impossible to deny that they are pouring large sums of money
into the problem.

To the degree that the vendors' customers can further externalize the
support onto the general public, however, they have no incentive to
push back either, and the market fails.  This is pretty much the case
for personal, as opposed to corporate, users of Microsoft's software.
Imposing a tax is the classic economic answer to such a market failure.
The tax's purpose is (theoretically) to transfer the externalized costs
back to those who are in a position to respond.  In theory, the cost
for security problems - real or simply possible; we have to go with
the latter because by the time we know about the former it's very
late in the game - should be born by those who develop the buggy
code, and by those who choose to use it.  A tax on the code itself
directly takes from the users of the code, indirectly from the
vendors because they will find it more difficult to compete with
vendors who pay lower tax rates, having written better code.  It's
much harder to impose the costs directly on the vendors.  (One way
is to require them to carry insurance - something we do with, say,
trucking companies).

In any case, these arguments apply to free software in exactly the same
way they do for for-fee software.  If I cars away for free, should I be
absolved of any of the costs involved if they pollute, or cause
accidents?  If I'm absolved, should the recipients of those cars also be
absolved?  If you decide the answer is "yes", what you've just decided
is that *everyone* should pay a hidden tax to cover those costs.  In
what why is *that* fair?
                                                        -- Jerry