Generally speaking the way to enforce your subscription and guarantee your money is to either charge up-front, disable features, or own the data, otherwise you only have people's goodwill to stop you being a free download. Whatever you do is going to p*ss off your users because they'll want it for nothing. Owning the data is very fashionable at the moment.
If you really want to make sure that you get your cash then you charge them at the point of download. You could build in a time-bomb from the date of registration and keep a registry of users on your server with activation keys. When the time bomb goes off the app stops working and they have to come back and buy a license key. Pop up an annoying message reminding them that they haven't paid you anything every few minutes. Or, you could force it to handshake with the server to perform some very valuable function, like print, or save, or perhaps start up, whether running standalone or in the browser. Have you thought of giving it away for free and then extracting your value by some other means like licensing the data format? Worked for Macromedia... --- In [email protected], "Paul Andrews" <[EMAIL PROTECTED]> wrote: > > > ----- Original Message ----- > From: "George" <[EMAIL PROTECTED]> > To: <[email protected]> > Sent: Saturday, January 12, 2008 9:06 PM > Subject: Re: [flexcoders] Application protection > > > > I'm not sure what kind of your application is. I guess it's an > > application could run both in browsers and AIR standalone (I planned a > > project myself like this) > > Yes, exactly that. > > > I would make most of tasks 'call home' for sure. But there could be > > 'off-line' tasks. When the client get back online it will update > > (merge/diff) automatically. I will likely to give chance some > > information to be exported as a format like PDF. If some data useful for > > user even offline, let them exported so they can read anywhere, in a way > > you have some sort of control, help them instead let them hacking. You > > cannot protect anything you display to them, whatever sensitive data is, > > your clients could 'Print screen'. > > The clients are actually providing the data, so print screen is fine. The > worst scenario is that the AIR application is hacked so it no longer needs > the server and people could use it without the subscription. I'm fully aware > that hackers will hack no matter what, I just want it to be harder for the > occassional geek/rougue user to bypass the subscription and pass the > software around. > > As far as I know there's no licence protection support in AIR, so I was > hoping someone might say "I have an AIR app and I'm using product XYZ for > licencing". > > This is also a sensitive issue so I understand that people may be reluctant > to discuss their own arrangements. > > Thanks again, > > Paul > > > > > George > > > > Paul Andrews wrote: > >> > >> > >> Hi Guys, > >> > >> I'm considering producing an application that could be sold commercially > >> to > >> small businesses or even some individuals. I won't say what the > >> application > >> is ;-) > >> > >> As a Flex application much of the logic (it could all be) will be on the > >> client. Strictly speaking the server would only be used for saving data. > >> The > >> application could also work nicely as an AIR application. > >> > >> Ideally, I don't plan to sell the application, but a service - so it > >> would > >> be subscription based. > >> > >> No we all know the world is full of pirates and I'd like to know the best > >> way to make things at least a bit more tricky for them. As a subscription > >> based service, having a logon to a remote server will help since it will > >> at > >> lease make them 'call home'. Is this the only way to protect Flex > >> applications? > >> > >> Presumably the only way to really protect an AIR App is to make it 'call > >> home' too? If the calling home feature became disabled, it would leave > >> the > >> AIR app prone to missappropriation. > >> > >> Finally, potentially some of the data involved will be sensitive. It > >> doesn't > >> have to be sent to the client, but would be good if it was. That would > >> then > >> raise the spectre of data confidentiality on a remote server. > >> > >> My usual experience is with corporate intranets or websites where > >> piracy/security isn't a big issue (at least not my specific problem). > >> > >> So any advice on security issues surrounding Flex/Air apps would be > >> welcome > >> before I finalise my architecture. > >> > >> Paul > >> > > > > > > > > -- > > Flexcoders Mailing List > > FAQ: http://groups.yahoo.com/group/flexcoders/files/flexcodersFAQ.txt > > Search Archives: http://www.mail-archive.com/flexcoders%40yahoogroups.com > > Yahoo! Groups Links > > > > > > > > >
