simonjpalmer escreveu: > 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 flexcoders@yahoogroups.com, "Paul Andrews" <[EMAIL PROTECTED]> wrote: > >> ----- Original Message ----- >> From: "George" <[EMAIL PROTECTED]> >> To: <flexcoders@yahoogroups.com> >> 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 >>> >>> >>> >>> >>> > > > > > -- > 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 > > > > > __________ NOD32 2781 (20080110) Information __________ > > This message was checked by NOD32 antivirus system. > http://www.eset.com > > > > Hi, there's a post by Ted Patrick at onflex.org which might help
http://www.onflex.org/ted/2008/01/loaderload-vs-loaderloadbytes.php Regards, Frederico Garcia
