It's hard to get into all the dynamics of it, but I'll gladly have a
conversation offline with you if you'd like to have one. I'll try to
touch briefly upon most of this though.
Yes - I agreed the protection Google has implemented does not suffice
for now. One would have hoped it could have been resigned to run
specifically on that phone, or some type of protection like that.
Instead we have a "forward-locked" application that essentially
doubles in size since it has a zip file in /data/apps and it's actual
apk in /data/app-private which is just a simple linux permission based
protection.
I agree with nEx on this one, that your asking a bit much for some
applications to be granted internet permission, more importantly, your
now asking for someone to grant READ_PHONE_STATE. This is something
I've been more protective of over the internet permission. Your no
longer using the ANDROID_ID and now using an IMEI. Since the IMEI is
specific to the phone, why not use the ANDROID_ID? It is also linked
to that phone and does not require any addition permissions... From
the other side of things, it is also spoofable - so your not risking /
more/ than you would by using the IMEI.
You've touched on a few products and mentioned that they are all
activation required. I completely agree that this is the activation
method people should be taking, but you must also know -- all the
products you've listed are easily available for a pirate... So why do
people buy them then? Activation often /comes/ with something.
Continued program update, patches, data updates, incentives to things,
SUPPORT, plug-ins, etc. That's why these things can sell. Your always
going to have the kiddies who download things for the sake of, I have
this and I got it for free, always. Your always going to have people
who can get it to them, because you've developed some crazy
protection, and it's a game for them to break it. What needs to be
done is put up some protection, and make your product better. If you
spending more time on developing your protection system than your next
feature, you need to re-evaluate your business plan. Protection
schemes will probably add no business value compared to the next
cutting edge feature...
I'd like to just quickly rebase in saying, I'm not against your scheme
- I just don't see how you plan to make this work. If you open up your
blacklisting, it just seems like it will be too easy to circumvent and
even easier to abuse. Circumvention isn't too much of an issue, but
the abuse is just going to land you in problems with good customers.
Yes, they could always email you and defend their IMEI. Though unless
you've developed a /must have/ app that no one else has, why would a
customer put up with having to defend themselves - you should always
want to give customers a path a least resistance :)
On Nov 16, 4:49 pm, AlexK <kucherenko.a...@gmail.com> wrote:
> sounds like conservation talks. I'm afraid because I don't understand
> what they are doing. I will not sit into train, because I don't know
> who in the front of it...
>
> Good application on which spent a lot of efforts requires good
> protection. You pay money for application and it services, and in
> rights ask explanation from developers site, may be even ask about
> some special guaranties... But in any case It is completely your
> choice do you want to use best application on market and did security
> prerequisites with guaranties from developer side, or use free
> software with open source and etc.
>
> On Nov 16, 11:28 pm, "nEx.Software" <email.nex.softw...@gmail.com>
> wrote:
>
> > No, I completely understand that developers might use it but... Given
> > the generic permission, I'd prefer not to use it unless completely
> > necessary. That being said, if a developer is up front about it and
> > tells me why they want those permissions, I am far less cautious...
> > Generally speaking, I don't approve of analytics such as Flurry and/or
> > Google because the developers don't tell me that they are being used.
> > Google Analytics for Mobile actually requires disclosure, if I
> > remember correctly.
>
> > On Nov 16, 2:22 pm, Dan Sherman <impact...@gmail.com> wrote:
>
> > > I understand your point completely, but just pointing out a very
> > > legitimate
> > > reason for some of those apps would be user stats (flurry, google
> > > analytics), or ad serving (admob, etc). :)
>
> > > - Dan
>
> > > On Mon, Nov 16, 2009 at 4:17 PM, nEx.Software
> > > <email.nex.softw...@gmail.com>wrote:
>
> > > > If I don't believe an application should require Internet, I don't
> > > > install it. I hope that there are others who do the same. To require
> > > > internet permissions (with the current generic internet permission) on
> > > > an app which really does not need it, such as aiFlashlight, gives me
> > > > reason to question the motives of that developer. I ask myself "Now,
> > > > why the heck would a flashlight app require internet permissions?" and
> > > > then move along to another app that does the same thing without
> > > > requiring those permissions. I usually recommend to others that they
> > > > do the same thing. Taking this route is, in my opinion, a band-aid,
> > > > not a solution.
>
> > > > On Nov 16, 2:09 pm, AlexK <kucherenko.a...@gmail.com> wrote:
> > > > > Yes, INTERNET permission required.
>
> > > > > For example In our application we show activation dialog with
> > > > > description about activation process.
> > > > > In your cases can be done something different.
>
> > > > > On Nov 16, 8:16 pm, "nEx.Software" <email.nex.softw...@gmail.com>
> > > > > wrote:
>
> > > > > > Of course, now you have to add Full Internet permission to every app
> > > > > > and thus negate any usefulness of this permission for actual use.
> > > > > > As if this permission was not already useless enough in telling the
> > > > > > user what the app intended to do...
>
> > > > > > On Nov 16, 11:13 am, AlexK <kucherenko.a...@gmail.com> wrote:
>
> > > > > > > Source code which you can integrate into own application for
> > > > > > > checking
> > > > > > > black list.
>
> > > > > > > /**
> > > > > > > * Determines status of device's IMEI.
> > > > > > > *
> > > > > > > * @return -1 - imei status retrieval failed. 0 - Green status 1
> > > > > > > to 3
> > > > -
> > > > > > > Yellow
> > > > > > > * status 3 to 5 - Brown status above 5 - Red status
> > > > > > > */
> > > > > > > public int getIMEIStatus()
> > > > > > > {
> > > > > > > // 1. Get device ID
> > > > > > > TelephonyManager manager = (TelephonyManager)getSystemService
> > > > > > > (Context.TELEPHONY_SERVICE);
> > > > > > > String sDeviceID = manager.getDeviceId();
> > > > > > > // 2. Fetch for IMEI data.
> > > > > > > // Will look like
> > > > > > > //
> > > >http://www.artfulbits.com/android/antipiracycheck.ashx?IMEI=123456789...
> > > > > > > String url = "
> > > >http://www.artfulbits.com/android/antipiracycheck.ashx?
> > > > > > > IMEI="
> > > > > > > + sDeviceID;
> > > > > > > // Server will return 200 if request post was successful.
> > > > > > > final int http_ok = 200;
> > > > > > > // Create new http client.
> > > > > > > HttpClient client = new DefaultHttpClient();
> > > > > > > // Create new http post.
> > > > > > > HttpPost post = new HttpPost(url);
> > > > > > > // Cache http response.
> > > > > > > HttpResponse response = null;
> > > > > > > // Will return -1 unless server provides its own value.
> > > > > > > int imeiStatus = -1;
> > > > > > > try
> > > > > > > {
> > > > > > > // Executind post.
> > > > > > > response = client.execute(post);
> > > > > > > // Making sure we've received correct status code.
> > > > > > > if(response.getStatusLine().getStatusCode() == http_ok)
> > > > > > > {
> > > > > > > // Retrieving content stream.
> > > > > > > InputStream stream = response.getEntity().getContent();
> > > > > > > // Decorating stream with Input stream reader
> > > > > > > InputStreamReader isr = new InputStreamReader(stream);
> > > > > > > // Decorating input stream reader with buffered stream
> > > > > > > reader.
> > > > > > > BufferedReader reader = new BufferedReader(isr);
> > > > > > > // Reading imei status from stream.
> > > > > > > imeiStatus = Integer.parseInt(reader.readLine());
> > > > > > > // Closing buffered reader will recursively close decorated
> > > > > > > input stream
> > > > > > > // reader and input stream.
> > > > > > > reader.close();
> > > > > > > }
> > > > > > > }
> > > > > > > catch(Exception e)
> > > > > > > {
> > > > > > > e.printStackTrace();
> > > > > > > }
> > > > > > > return imeiStatus;
>
> > > > > > > }
>
> > > > > > > On Nov 16, 7:57 pm, AlexK <kucherenko.a...@gmail.com> wrote:
>
> > > > > > > > I just did publishing of the web service!
>
> > > > > > > > All details can be found here:
>
> > > > > > > >http://www.artfulbits.com/Android/antipiracy.aspx
>
> > > > > > > > In 5 minutes I'll update database by our latest catched pirate
> > > > phones.
>
> > > > > > > > On Nov 16, 2:19 pm, "admin.androidsl...@googlemail.com"
>
> > > > > > > > <admin.androidsl...@googlemail.com> wrote:
> > > > > > > > > +1
>
> > > > > > > > > This keeps coming up but I am bumping because it shouldn't be
> > > > ignored
> > > > > > > > > by Google.
>
> > > > > > > > > Problem is people can buy and refund within 24 hours. So we
> > > > > > > > > need
> > > > a web
> > > > > > > > > service apps can call where we can send a device ID plus a
> > > > > > > > > google
> > > > > > > > > checkout number which confirms a valid non-cancelled order. If
> > > > this
> > > > > > > > > web service could be centralised to check other app markets
> > > > > > > > > too,
> > > > we
> > > > > > > > > would all be laughing.
>
> > > > > > > > > Its not cost effective for a single dev to work out a
> > > > > > > > > solution. A
> > > > team
> > > > > > > > > of people should be driving this forwards where they can keep
> > > > > > > > > an
> > > > eye
> > > > > > > > > on what the pirates are doing and continue to improve the
> > > > > > > > > system
> > > > as
> > > > > > > > > the pirates continue to break it.
>
> > > > > > > > > So the question then becomes a monetary one. No one has the
> > > > motivation
> > > > > > > > > to build a system without a monetary incentive. So how about
> > > > > > > > > all
> > > > app
> > > > > > > > > devs who are interested in the scheme support the anti-piracy
> > > > > > > > > developers by paying a monthly subscription. Most app devs
> > > > > > > > > would
> > > > be
> > > > > > > > > happy to do so if they can claw back 100's of pirated copies
> > > > > > > > > of
> > > > their
> > > > > > > > > apps.
>
> > > > --
> > > > You received this message because you are subscribed to the Google
> > > > Groups "Android Developers" group.
> > > > To post to this group, send email to android-developers@googlegroups.com
> > > > To unsubscribe from this group, send email to
> > > > android-developers+unsubscr...@googlegroups.com<android-developers%2Bunsubs
> > > > cr...@googlegroups.com>
> > > > For more options, visit this group at
> > > >http://groups.google.com/group/android-developers?hl=en
>
>
--
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
