Re: Protecting Software w/ Software License -- a modest proposal
Re: Protecting Software w/ Software License -- a modest proposal
- Subject: Re: Protecting Software w/ Software License -- a modest proposal
- From: Kirk Kerekes <email@hidden>
- Date: Tue, 18 Jun 2002 18:36:19 -0500
3. pirated -- these stamp "PIRATED" over every application window,
or trash the app or whatever.
------------------------------------------------^^^^^^^
From: Rosyna <email@hidden>
Subject: Re: Protecting Software w/ Software License -- a modest
proposal.
NO! NO! NO! NO! No matter how pirated it is or not, do NOT destroy
data. It is very bad and could get you sued.
Obviously you would choose the "whatever" option, which is explicitly
available under this proposal.
Besides, where did you see "destroy data" in my statement? Windows are not
data, they are representations of data. The application is not data, it
_manipulates_ the data.
The data is the user's saved file, which I never proposed to damage. I
would assume that the sensible developer would accompany the "PIRATED"
message by a dialog stating that if the user felt that the "pirated"
annotation was erroneous, they could email all particulars, or call a
number or go to a website form or whatever. This is to handle someone who
persistently enters an erroneous serial number that happens to hit the
million-to-1 shot and actually match one of the "pirate" set. Or maybe to
allow a pirate to actually _buy_ the software...
I note that Microsoft is already using _part_ of this strategy with
Office-x -- the app contains a list of known pirated serial-numbers that MS
appears to have harvested from the web, and if you attempt to register the
app with one of them, the registration fails.
All I am proposing is to tighten the loop a bit, and seed the web with
pirate-branded serial numbers right up front, thus making the process of
using pirated software dramatically more difficult, and pirated software
thus less valuable.
Let's use an econ-101 approach here. If you sell a $400 software package, a
usable serial number for that package has a perceived value of $400,
because a thief can download the package and unlock it and have the same
software that you want to sell for $400. $400 value for a few moments of
download time is an excellent cost/benefits value.
But if only 1% of the available serial numbers actually work, then _each_
serial number's perceived value (in its untested state) is reduced
dramatically -- to far less than $4, because convenience counts for
something.
And if you delay the app's "pirate" response until the product has been
used several times, or for a significant time interval, or both... then the
uncertainty of the testing process further reduces the perceived value of
any given downloaded serial number. It rapidly becomes not worth the user'
s time to try to find a number that works.
Just think about how the rampant abuse of email by spammers has lowered the
value of commercial email communications. Now ponder turning that process
around, and using it on serial-number thieves and krack-downloaders.
We don't have to achieve perfection here, just taint the waters
sufficiently to make piracy less attractive than honesty.
And everybody doesn't have to participate -- after all, there probably are
people sending out good and valuable offers via Unsolicited Commercial
Email -- but we have all been so conditioned to assume (spam == trash) that
we will never see them. They all get sent to the bit-bucket.
You could distribute the plans for a suitcase nuke via spam, and nobody but
3 newbie aol-ers from Iowa would ever see it. Possibly the most secure
open-channel available, spam is.
It doesn't really matter how clever the krackers are -- you don't have to
invest a lot of brain-sweat in a highly secure serialization scheme.
Fighting the crackers with ever-harder technology is perpetual losing
battle, and it tends to annoy your legit customers, as well as sucking up
your time.
You don't really care if an individual hand-kracks your app for their own
use -- that's a drop in the bucket. The percentage of potential customers
that have that ability is vanishingly small.
The damage occurs when that individual uploads the kracked app to the net,
and 10K others download it. That's the problem that my modest proposal
attacks -- the problem that _counts_.
If you seed the web with enough poisoned serial numbers, poisoned
Kracker-apps and poisoned pre-kracked apps, the whole kracking subculture
falls apart.
"Kracked app" becomes a synonym for "garbage that isn't worth your time".
Pretty trivial to write a filter that takes Kracker-apps and just mangles
the app so it crashes. Then the modified app is spread via gnutella, et al.
If such poisoned-krackers are spread from numerous widely separated
sources, they will tend to "dominate the market" for that file.
Such items look just the same as the original to file-sharing systems. To
research what is out-there, just look up popular commercial apps on
gnutella. Download every kracker and kracked app you find, drop it on your
kracker-poisoner filter, and then distribute the results to the
anti-kracker network so everyone can "share".
One could probably automate this process rather easily.
You would need to monitor the net occasionally to see if
kracker-conventions change to adapt to the attack (they might learn how to
spell, for example), and adapt things appropriately.
File sharing systems like LimeWire that will download a file via multiple
parallel streams from different sources are just about guaranteed to
download unusable kracker-krap when multiple differing version of the same
file appear to be identical.
And if a poisoned-kracker or poisoned-krack crashes, who gets blamed?
The kracker, of course.
On Tuesday, June 18, 2002, at 04:16 PM, email@hidden
wrote:
Message: 16
Date: Tue, 18 Jun 2002 13:59:40 -0700
To: Kirk Kerekes <email@hidden>, email@hidden
Ack, at 6/18/02, Kirk Kerekes said:
3. pirated -- these stamp "PIRATED" over every
application window,
or trash the app or whatever.
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.