On Nov 17, 12:01 am, strazzere <str...@gmail.com> wrote:
> 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.
>
IMEI code gives justice possibility to find phone owner and punish
him. Other IDs can not help in that.
In many countries exists IMEI code database created by cellular
operators, and you can ask for phone place detection and switching
off, of course if you have proper papers in hands. I think "pirate"
should now that if he steal and rich some kind of our pations limit,
then we can punish him or at least force him to buy all applications
and compencate sales losts.
> 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'm easy on piracy. My idea: You have to try product for some time and
only after that decide do you want it or not. But in most cases It's
easy to contact product developer and ask about trial version. It's a
common practice to give people trial for trying the product.
> 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 :)
>
In my case, I even reduce price to stimulate pirates to buy product
after they install it. I give them a chance to recover own "good
face".
> 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...
>
> read more »
--
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
