Discussion :

[dams78]

On peut raisonnablement imaginer qu'on trouve un accès internet au moins une fois par semaine (via au moins un point d'accès wifi)...

Je suis contre toutes les mesures de protection qui handicapent l'expérience utilisateur, mais là c'est clairement de la mauvaise fois que de dire que c'est le cas, parce que dans une situation ultra-particulière d'une expédition dans le désert sans accès internet, on se retrouve sans GPS.

Perso quand je vais en vacances j'ai autre chose à faire que chercher un accès wifi, effectivement si j'en trouve un et que j'ai que ça à faire, je vais en profiter pour relever mes mails. Mais il m'est déjà arrivé de passer plus d'une semaine sans internet. C'est pas parce qu'on a un smartphone qu'on est un geek accro au net

[GanYoshi]

Perso quand je vais en vacances j'ai autre chose à faire que chercher un accès wifi, effectivement si j'en trouve un et que j'ai que ça à faire, je vais en profiter pour relever mes mails. Mais il m'est déjà arrivé de passer plus d'une semaine sans internet. C'est pas parce qu'on a un smartphone qu'on est un geek accro au net

Mais par contre tu tiens absolument à utiliser les applications qui nécessitent un accès au net toutes les semaines pour se lancer ?

Si non on est d'accord alors

[Oussapik]

C'est une API qui est fourni aux développeurs. Certains faisait déjà ce contrôle de sécurité avant de leur propre manière.
Cette API permet juste de simplifier la mise en place d'un tel système pour les développeurs. Donc à mon avis, ça sera totalement invisible pour les utilisateurs, mais juste plus contraignant pour les pirates.

C'est juste une API, oui, mais sa présence va forcément multiplier le nombre d'appli basées sur ce modèle. Donc ça ne remet pas en cause le fait que ce soit bien ou pas. J'ai l'impression que tu dis : "ça existait, donc c'est bien d'en faire une API". Là je ne suis pas d'accord. Le fait de savoir si c'est bien d'en faire un API ou pas tient aussi du fait de savoir s'il y a un intérêt pour le développeur (là je suis d'accord) ET pour l'utilisateur (là je le suis moins, voire pas du tout).

Et si tu n'actives pas ton 3G pendant plusieurs jours (oui, ça peut arriver à certains), tu te retrouves avec une appli bloquée... En quoi peut-on donc dire que l'utilisation de cette API est "invisible" pour l'utilisateur ?

[MrDuChnok]

C'est vrai que c'est une aberration possible avec ce genre d'API, je suis d'accord avec toi.
Mais je pense pas que beaucoup de sociétés / développeurs, bloquent totalement leurs applications en cas de non vérification de la clé. La vérification sera faite au moins une fois (à l'installation ou au premier lancement de l'application), ensuite les autres vérifications se feront via le cache (sans connexion), ou attendrons que t'aies un accès au net. Enfin c'est une stratégie qui me parait suffisante pour lutter contre le piratage de masse, et suffisante pour ne pas déranger les utilisateurs.
On verra ce que ça va donner dans la pratique, mais chaque application aura sa propre politique (ça je trouve ça bien, plutôt que d'imposer un modèle de fonctionnement), donc impossible de prédire le comportement des développeurs.

[GanYoshi]

Et si tu n'actives pas ton 3G pendant plusieurs jours (oui, ça peut arriver à certains), tu te retrouves avec une appli bloquée... En quoi peut-on donc dire que l'utilisation de cette API est "invisible" pour l'utilisateur ?

Personnellement il me semble que lorsque je désactive la 3G, c'est le réseau GPRS qui prend le relais, c'est juste plus lent.

[Oussapik]

Personnellement il me semble que lorsque je désactive la 3G, c'est le réseau GPRS qui prend le relais, c'est juste plus lent.

Ce que j'entends pas là, c'est les cas où les data ne passent plus. Où tu n'as que (si tu l'as encore) la voix.
C'est le cas qui a déjà été évoqué des déplacements à l'étranger. Si je pars 1/2 semaines à l'étranger, pour ne pas bousiller mon forfait data, je vais couper tout ce qui n'est pas voix/sms. Donc je n'aurai plus la possibilité de synchroniser mon appli avec les serveurs de google.

[MrDuChnok]

Ce que j'entends pas là, c'est les cas où les data ne passent plus. Où tu n'as que (si tu l'as encore) la voix.
C'est le cas qui a déjà été évoqué des déplacements à l'étranger. Si je pars 1/2 semaines à l'étranger, pour ne pas bousiller mon forfait data, je vais couper tout ce qui n'est pas voix/sms. Donc je n'aurai plus la possibilité de synchroniser mon appli avec les serveurs de google.

Mais tu as bien compris que cette vérification de licence ne se fera pas obligatoirement à chaque lancement de l'application ? et que cette vérification pourra également se faire sans connexion internet (via le cache) ?

[Oussapik]

Mais tu as bien compris que cette vérification de licence ne se fera pas obligatoirement à chaque lancement de l'application ? et que cette vérification pourra également se faire sans connexion internet (via le cache) ?

Oui, je l'ai bien compris.
Comme tu le dis, elle ne se fera pas "obligatoirement". Donc cela dépend du développeur. Valider une licence une fois pour toute (validation online j'entends), je ne suis pas contre, je suis même pour. Ce que je reproche c'est de donner la possibilité de demander à plusieurs reprises cette validation.

[dams78]

Mais par contre tu tiens absolument à utiliser les applications qui nécessitent un accès au net toutes les semaines pour se lancer ?

Si non on est d'accord alors

Non non, je parlais de la seule appli que j'ai de payante : CoPilot, il s'agit d'un GPS, qui n'a donc pas besoin de se connecter au net.

[sinople]

Il y a de bonne et de mauvais chose dans cette API à mon avis.

Bien :
- Mettre à disposition une API de protection aux développeur permet à ces derniers d'être correctement rétribué pour leur travail. Et vu que sur smartphone le prix qu'est prêt à payer l'utilisateur est proche de 0, on imagine qu'il n'hésite pas à passer dans l'illégalité quand l'offre gratuite s'étouffe...

Particulièrement les "petits" développeurs qui n'ont ni le temps, ni les moyens de mettre en place leur propres solutions de protection.

Pas Bien:
- Il y a beaucoup trop de paramètre disponible pour le développeur qui peut rendre la protection de transparente à vraiment lourd pour l'utilisateur. Et comme il n'est pas possible pour le client final de savoir à quel point son application va lui casser les c*bip* avec ces protections avant l'achat.
Il suffira d'une mauvais expérience pour que ce dernier développe une certaine paranoia et se tourne définitivement vers les applications piratées.

Un truc développé par des ingénieurs pour des ingénieurs...

[mwyann]

Déjà, le fait même d'avoir implémenté un système de cache des clés, c'est 90% de chances pour que des applis "For Root Users" voient le jour pour débloquer toutes les clés qu'on veut en un clic. Les pirates vont même se réjouir de n'avoir qu'une seule méthode à appliquer pour pirater n'importe quelle appli (par le biais de l'API) là où le piratage de chaque méthode de chaque développeur est bien plus longue. Mais soit.

Je pense que, encore une fois, et comme dans de nombreux cas que j'ai croisé, le plus embêté dans l'histoire ça va finir par être l'utilisateur légitime (exemples : le pirate va utiliser un NoCD là où le joueur légitime devrait à chaque fois insérer son CD, les dongles USB qui prennent un port USB et qui ralentissent l'application, le logiciel qui va avoir besoin de l'accès au net pour valider l'autorisation de fonctionnement, les étapes longues et fastidieuses pour insérer un numéro de série, enregistrement, activation là où un simple fichier exe cracké suffit...).

Maintenant, si je critique il faut bien que je propose autre chose en retour (c'est trop facile de critiquer). Malheureusement, il n'y a aucun système fiable et non contournable à ce jour, mais celui que je préconiserais le plus serait celle-ci :

Pour chaque utilisateur de portable sous Androïd (identifié par son identifiant Google), une clé de type RSA serait créée chez Google. La clé privée chez Google et la clé publique fournie au téléphone. Ensuite, dès lors qu'une application payante doit être installée, Google va au préalable signer le paquet d'installation POUR l'utilisateur (et le téléphone gardera l'apk signé), l'installation décodera l'apk par la suite (un apk marqué comme payant devrait obligatoirement être signé pour s'installer). De cette manière, impossible de se passer les apk car signés pour un utilisateur unique. Cela remettrait en cause l'installation des apk d'Android, mais il n'empêche pas une rétro-compatibilité (les terminaux incompatibles se verraient toujours fournir les anciens apk non signés).

[Idelways]

Android : la protection des licences déjà « facilement » détournée
Google minimise et défend son système de signature


Mise à jour du 25/08/2010 par Idelways

Le système de protection des licences de l'Android Market, mis en place par Google il y a moins d'un mois (lire ci-avant) est déjà craqué. Et d'une manière relativement simple.

Sur un message posté sur AndridPolice, un développeur prétend — démonstration à l'appui — pouvoir briser la protection LVL (Licence Verification Library) en changeant quelque lignes de codes.

Justin Case, l'auteur de l'article se dit pourtant « opposé au piratage et pro-Google » et explique que le but de sa démarche est d'améliorer les systèmes de protection des applications.

Pourtant, même si l'utilisateur lambda n'est pas en mesure d'exploiter directement cette faille, beaucoup d'utilisateurs avancés (dont font partie les membres de ce forum) peuvent craquer les applications et pourraient en distribuer des copies illégales.

La réponse de Google ne s'est pas faite attendre.

Tim Bray tente de clarifier quelques informations à propos de LVL.

Il concède que "la protection à 100% contre la piraterie n'existe pas pour les systèmes qui exécutent du code tiers", mais il dit qu'avec une bonne sécurité, il est possible de rendre extrêmement difficile et coûteux le piratage logiciel.

Bray prend la défense de son système de protection, qu'il qualifie de « très jeune », sa première version inclurait pour l'instant l'implémentation la plus simple et la plus transparente pour des raisons de clarté.

Dans le détail, l'exploit (ou plus exactement le « crack ») s'appuie sur le fait que les applications pour Android sont distribuées sous forme de byte-codes comme toute application Java. Ce bytecode peut être décompilé en un code source très proche du code original.

Une fois ce code obtenu, le « pirate » n'a qu'à trouver la classe LicenceValidator et changer le comportement de l'application quand le serveur de vérification répond que la licence est invalide. Ne reste plus qu'à recompiler et redistribuer l'application.

[ame="http://www.youtube.com/watch?v=eMZ4qYbpN_s"]Vidéo : Briser l'Android Licensing Verification Library (LVL)[/ame]

Une prochaine version de LVL devrait donc assez rapidement voir le jour.

Même si comme Tim Bray le souligne, cette première version est déjà très populaire auprès des développeurs. Et qu'elle rend, quoi qu'on en dise, la crackage des applications Android déjà nettement moins « user friendly » que par le passé.

Source : Site AndroidPolice

Lire aussi :

L'Android Market passe la barre des 100 000 applications

Android : premier « Cheval de Troie » camouflé dans un jeu, Tapesnake envoie le positionnement GPS du smartphone à des tiers

Oracle poursuit Google en justice pour son utilisation de Java dans Android : le succès de l'OS mobile attiserait-il les appétits


Et vous ?

Google arrivera-t-il à protéger les applications Android payantes contre le piratage ?

Quelles protections proposez-vous pour y arriver ?


En collaboration avec Gordon Fowler

[galien]

Pourquoi google n'utilise pas la sécurité de java tout simplement, il ont déjà pompé les 3/4 de la JVM avec Davik, ils en sont pas à ça près.

[MrDuChnok]

C'est quoi cette "sécurité de java" dont tu parles ?

[Médinoc]

En gros, Palladium est arrivé.

Enfin, cette faille est sûrement facile à corriger avec des signatures numériques sur le code...

[galien]

"C'est quoi cette "sécurité de java" dont tu parles ?"

Je sais pas la signature des jars par exemple.
Les politiques de sécurités du class loader, etc...
Bref tout ça

Edit: dire sécurité de la plateforme d'exécution java serait plus précis.

[mwyann]

Et, c'est bien ce que j'avais dit juste avant cette news, une API anti-piratage = une seule méthode pour cracker les programmes = la simplicité pour les pirates. La preuve...

[ferfich25]

j'ai lu sur http://www.apkwow.com que toutes les applications payantes que vous publiez sur Google Play peuvent utiliser le service de gestion de licence de celui-ci, et vous pouvez gérer les licences de toutes vos applications à partir de votre compte sur la console développeur Google Play. Aucun compte spécial ou enregistrement supplémentaire n'est nécessaire. Par ailleurs, du fait que ce service n'utilise aucune API dédiée du framework Android, vous pouvez mettre en œuvre le système de gestion de licence dans n'importe quelle application existante basée sur l'API niveau 3 ou une API de niveau supérieur.

[Paul TOTH]

Je sais pas la signature des jars par exemple.
Les politiques de sécurités du class loader, etc...
Bref tout ça

Edit: dire sécurité de la plateforme d'exécution java serait plus précis.

le lien que tu donnes implique la sécurisation du code, pas l'intégrité de l'application.

Si je prend une appli Java, que je la décompile, la modifie et la recompile, elle pourra toujours s'exécuter.