Re: Detecting Illegitimate OS X Installations?
Re: Detecting Illegitimate OS X Installations?
- Subject: Re: Detecting Illegitimate OS X Installations?
- From: Greg Herlihy <email@hidden>
- Date: Mon, 19 Jun 2006 07:27:44 -0700
- Thread-topic: Detecting Illegitimate OS X Installations?
However high-minded the intention, attempting to detect pirated OS X
installations is simply misguided. Because only those empowered to define a
legitimate installation, can test for one. Or to put it another way, by
performing a test for a legitimate install, the app is defining (on Apple's
behalf) what a legit installation must be.
Moreover this feature is a disaster in the making: because at some time in
the near future, some number of customers would buy a new model Macintosh,
take it home, excitedly launch this application for the first time on this
new machine - only to have the program immediately - and falsely - accuse
them of having committed a federal offence. In other words, this is not the
right approach toward building brand loyalty and customer satisfaction.
Even if that accusation is toned down - simply not having the software work
when it has no reason not to - unjustly denies the user the services of the
program. And in reality the only people most likely to be affected by this
behavior are not pirates - but first-time Mac buyers and the early adopter
types - exactly the kind of individuals for whom a positive initial
impression matters a great deal.
If still not persuaded, then answer this question: Would it be appropriate
for the same program to scour the user's hard drive looking for Adobe
products that appeared to be pirated? Of course not. Only Adobe and its
designated agents can decide licensing terms for its own products. And that
observation is just as true for Adobe as it is for Apple - or for any other
third party.
Greg
On 6/19/06 5:54 AM, "Andrei Tchijov" <email@hidden> wrote:
> Isn't a little too ambitious to assume that you will succeeded were
> Apple fails (if it will fail)? If Apple fails to prevent Mac OS X
> from running on "un-authorized" hardware, what chances yours (or
> anyone else) application has to achieve the same goal? If your
> application will be wildly successful and huge number of people will
> run Mac OS X on none-Apple hardware, you should have no doubts that
> some one will break through what ever protection you will care to
> devise (and it will be even easier if they will search through Cocoa-
> Dev archives and look into this discussion ). Otherwise (your
> application is mildly successful and just a few people running Mac OS
> X on "wrong" hardware) why bother? Disclaimer stating that you are
> not supporting "un-authorized" hardware will do just fine.
>
> Andrei
>
> On Jun 19, 2006, at 8:21 AM, Uli Kusterer wrote:
>
>> Am 17.06.2006 um 21:55 schrieb Colin Cornaby:
>>> I want to write code to explicitly keep my application from
>>> running on non-Apple branded Intel hardware. I've seen this done
>>> in several other applications, and I was wondering what indicators
>>> other developers usually look for to tell if an application is
>>> running on some other vendor's hardware. Until Apple officially
>>> condones OS X on non-Apple hardware I don't want to support users
>>> running pirated copies of OS X, on hardware that Apple doesn't
>>> support. Along with the ethical stuff, I also don't want to bother
>>> supporting systems running a hacked kernel and oddball graphics
>>> drivers.
>>
>> Have you checked what ASP returns for unknown computers running OS
>> X? I'd guess that it'd be much easier to just ask people for an ASP
>> report (which helps with most bug reports anyway) and if it's an
>> odd CPU/hardware combo you'd know they're running either a third-
>> party-upgraded Mac (I think there's some hacks like a bigger Core
>> Duo for Mac minis) or a PC.
>>
>> Cheers,
>> -- M. Uli Kusterer
>> http://www.zathras.de
>>
>>
>> _______________________________________________
>> Do not post admin requests to the list. They will be ignored.
>> Cocoa-dev mailing list (email@hidden)
>> Help/Unsubscribe/Update your Subscription:
>>
>> This email sent to email@hidden
>
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Cocoa-dev mailing list (email@hidden)
> Help/Unsubscribe/Update your Subscription:
>
> This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden