Le 18/07/2013 à 09h 06

psn00ps a écrit :

Fais aussi interdire les navigateurs tant que tu y es, ils parsent le site " />



Je sens une petite critique, mais infondée si tu es famillier au monde du web.

C’est pourtant tout ce qu’il y a de plus simple comme raisonnement :
Si tu es un humain, tu appelles le site HTML, il est fait pour ça.
Si tu es un robot, tu appelles le webservice dédié, il est fait pour ça.

Les systèmes automatiques parsant du HTML, c’est crado, c’est pas fiable, ça fout la merde sur les serveurs dédiés aux humains, et c’est surtout interdit.
Alors la Tam n’avait aucun scrupule à faire retirer les apps ne jouant pas le jeu.

C’était pas fait avec méchanceté, on leur signalait les webservices pour qu’ils mettent à jour leur app. Mais la sanction tombait s’ils ne réagissaient pas.

Mais si TF1n’a pas envie d’ouvrir ses données, il ne fait pas de webservice, et il est parfaitement dans son droit à bloquer les parseurs d’HTML automatiques.

Le 18/07/2013 à 07h 59

zglurb a écrit :

Je comprend un peu TF1 sur le coup qui ne diffuse pas ses replay pour du vent non plus ou par pure générosité.

Par contre peut-être existe-t-il d’autres solutions techniques qui permettraient à TF1 de monétiser ce service même en passant par des logiciels tiers ?
Comme mettre une API à disposition des développeurs en échange de l’affichage d’une pub dans le logiciel. Tout le monde y gagnerait. Le développeur n’aurait plus besoin de parser des pages HTML toutes crades et n’aurait plus à tout refaire quand le design change. TF1 gagnerait des sous.

Enfin je suis peut être trop rêveur / naïf ?



Ouf ! Le premier commntaire censé depuis 15 pages.
Le parsage de page HTML par un logiciel automatique pour récupérer les données d’un site est pas vraiment légal.

A montpellier, j’ai bossé pour la Tam, et on ne comptait plus le nombre d’apps mobiles qui parsaient le site d’horaires officiels du tram.
Même si c’étaient des données publiques, elles se faisaient interdire parce que la méthode des récupération des données n’était pas légale.

Captvtv utilise les mêmes méthodes ? Il est en tort. TF1 est dans son bon droit.
Le problème du droit d’auteur ou de la copie privée ne se pose même pas.

Le 12/07/2013 à 08h 43

J’aimerais qu’elle lance un kickstarter pour que la communauté lui vienne en aide.
Et elle pourra ensuite prêcher un bon gros doigt d’honneur pour les ayant droit lui ayant foutu sa vie en l’air pour 24 chansons.

Le 11/07/2013 à 16h 17

Raknor a écrit :

(parenthèse débat)
Pour le peu que je connais d’iOS, Apple vérifie les applis avant publication non? Sempiternelle différence de modèle.



Je comprends le questionnement validité / confiance, c’est l’un des rares questionnements qui m’a paru cohérent depuis une bonne semaine…

Mais (encore une fois) tu sembles facilement critiquer Android sans vraiment creuser le sujet…
Pour le peu que je connaisse d’Android, Google vérifie aussi les apps avant publication. Sempiternelle équivalence de modèle, avec quelques sécurités supplémentaires pour Google.
Ces sécurités supplémentaires ont des failles? Le reste est toujours aussi solide que l’AppStore, et le système reste inviolé.

Mais puisque tu lances ce sujet : Renseigne-toi sur l’offuscation de code, et demande-toi comment Apple et Google peuvent “vérifier” les apps…

D’expérience, dans ma boite, les seules apps s’étant vues refuser l’entrée sur l’AppStore étaient seulement celles contenant “Google” dans une chaîne de caractère.
(un des seuls éléments à échapper à l’offuscation, le reste du code étant illisible.)
Tout le reste passe sans aucun problème tant que ce n’est pas une app qui peut concurrencer une autre officielle d’Apple.



Khalev a écrit :

Le fait de rajouter une sécurité déresponsabilise les gens qui s’appuient sur cette sécurité. Ils lui font confiance et font des choses qu’ils n’aurait jamais fait sans.



Je suis entièrement d’accord.
Mais je trouve amusant le fait que tout le monde critique celui qui a deux sécurités dont une faible, alors que le principal concurrent n’a même pas installé la deuxième sécurité.


Ceci dit, si vous voulez continuer de croire la perfection du modèle Apple, tout en crachant sur Google, allez-y.
Et vous avez raison d’y ajouter du mépris, c’est d’autant plus savoureux.

Le 11/07/2013 à 12h 12

Raknor a écrit :



Je crois qu’effectivement on peut mettre un terme au débat.

Tu argumentes sur la fiabilité des données stockées chez l’utilisateur pour me contredire…
Et tu conclues le même post, en affirmant finalement être “plutôt d’accord” avec leur non-fiabilité.

Je crois que l’on peut effectivement s’arrêter là.

Android s’est fait littéralement craché dessus depuis cette semaine !
Tout le monde affirme que c’est une faille béante au système, que Google Play ne sera plus jamais fiable…

Je ne critique absolument pas Android, au contraire !
L’une des deux vérifications lors d’une soumission de MaJ à été fragilisée? iOS n’en a jamais eu qu’une seule : le login du dev.
Le système de permission d’Android a été fragilisé ? Sur iOS il n’y en a même pas ! Une simple installation et on peut faire n’importe quoi.

Si tu sembles faire partie des alarmistes, qui crient à l’insécurité sur Google Play, alors tant mieux pour toi.
Le temps nous dira si l’immense majorité des téléphones sans correctifs de sécurité vont devenir des portes ouvertes.

… Mais à mon avis, même avec cette “faille” non colmatée, le système est toujours au moins aussi fiable que son concurrent direct.

Le 11/07/2013 à 09h 50

Raknor a écrit :

La faille dans ton raisonnement est simple :
N’importe qui ayant déjà accès à ta carte SD peut déjà directement véroler tes appli ou ton téléphone que de se faire chier à modifier des apk, des certificats, des signatures et attendre que l’utilisateur télécharge la mise à jour vérolée…. Pourquoi se rajouter une étape ? Fat logique.



Exactement !
Ce n’est pas une faille dans mon raisonnement, c’est EXACTEMENT ce que je voulais dire.
C’est la raison pour laquelle une MaJ hors ligne n’est pas sécurisée.
Tu semblais soutenir l’inverse sur TOUS tes posts de la page 9.



Raknor a écrit :

http://developer.android.com/tools/publishing/publishing_overview.html#publishing-release



Merci de valider mon point de vue par ce lien :
Il y est écris noir sur blanc que toutes les installations hors Google Play nécessitent de désactiver manuellement les vérifications des sources de l’APK dans les options d’Android !



Raknor a écrit :

Le playstore est reconnu comme de confiance, probablement à l’aide d’une connexion SSL (à voir sur quel protocole, capture de trame?). Pour installer un apk d’une source AUTRE que le playstore, il faut activer cette option. Enfin, pour moi, une personne censée devrait se faire qu’avec “sources inconnues”, il faut commencer à être méfiant. voir capture d’écran ici pour illustration Sur ce point, nous sommes d’accord. C’était déjà connu. Donc certainement pas le sujet de la soit-disante faille.
Va falloir que tu précises ce que tu veux dire par le mode hors ligne (et link moi une source tangible). Store alternatif? Depuis USB?


Mais au final, on discute de quelque chose qui n’a rien à voir avec la prétendu faille. Déjà soulevé par Cékagé : (…)



Je résume notre débat :

Moi (depuis une semaine) : Ce n’est pas une faille tant qu’on reste sur Google Play (ou Amazon Store…).
Toi : C’est un système de merde, Google Play ne fait aucune vérification.
Moi : Android est concu pour fonctionner sans Google, Google ne peut valider une installation externe à Google Play.
Toi : Avec la vérification du certificat et du hash sur la carte SD de l’utilisateur, on peut avoir une installation sécurisée sans avoir besoin de Google.
Moi : Les données présentes sur une carte SD d’un utilisateur ne peuvent être considérées comme fiables.
Toi (à l’instant) : Rien n’est fiable sur la carte SD de l’utilisateur, les installations hors Google Play ne sont pas validées (cf doc), et la faille n’en est pas une si l’on télécharge l’app depuis Google Play.

Merci ! Enfin !
On peut enfin clore le débat ? Je crois que l’on est d’accord.

Le 11/07/2013 à 00h 55

Raknor a écrit :

Sachant que tu as TRUSTE l’appli que tu as installé (en acceptant de l’installer, tu acceptes le certificat qui lui est associé, donc tu installes ce certificat), si le certificat de la MAJ est exactement le même (reconnaissable par la clé publique, le nom de l’éditeur, de l’émetteur, le numéro de série, voire une comparaison binaire du certificat si ça t’enchante), pour quelle raison tu ne ferais pas confiance à un certificat qui, en fait, implicitement, TU AS DEJA AUTORISE ET INSTALLE??? (je te rappelle que nous sommes dans le cas d’une MAJ)

J’ai déjà linké ceci dans l’autre article, un peu de lecture :
http://android-developers.blogspot.fr/2011/06/things-that-cannot-change.html

Je n’ai pas envie de te faire l’exemple du serveur web d’une banque, ni te présenter Alice et Bob.



Tu as répondu à côté de ma remarque :
Tu as beau avoir installé une application valide sur ta carte SD, tu ne peux être certain qu’elle n’a pas été altérée trois mois après.

Si tu souhaites vérifier la validité de la MaJ en mode hors-ligne, tu ne peux la vérifier qu’en la comparant avec ce que tu as déjà d’installé sur ta carte SD.
Autrement dit, tu la testes en la comparant avec des données LOCALES.
N’importe quel informaticien te dira que les données stockées localement chez l’utilisateur NE SONT JAMAIS FIABLES.

La faille dans ton raisonnement est simple :

• Tu installes un APK valide, tu as un certificat et une signature la validant enregistré sur ta carte SD.
  


• N’importe qui ayant accès à ta carte SD peut modifier ces données enregistrées par un autre certificat, et une nouvelle signature la validant (avec une nouvelle clef privée).
  


• Tada ! Ton app peut se faire mettre à jour en hors ligne par le premier venu.
  
  Tu as beau me sortir avec mépris les exemples théoriques qui pourraient rendre ça possible, mais je suis à peu près certain qu’une MaJ en mode hors ligne n’existe ni sur Google Play, ni sur AUCUN autre store, et pour cause !
  
  Quoi qu’il en soit, une MaJ en mode hors-ligne avec vérification n’est pas disponible sur Android (ni iOS, ni WP….).
  
  La faille de sécurité décriée reste donc particulièrement ridicule :
  Seul un store pirate ou un APK téléchargé depuis un site obscur peut mettre en péril un appareil Android… Mais c’était déjà le cas avant !
  
  Et effectivement, si tu veux vraiment avoir raison, dans l’hypothèse où une MaJ hors-ligne avait été disponible, ça aurait pu créer une faille de plus.

Le 10/07/2013 à 16h 39

Raknor a écrit :

Voilà, pas besoin de Google pour vérifier qu’un paquet vient du même éditeur.



Désolé, j’avais aussi invalidé cet argument, mais encore une fois je me suis mal exprimé. (c’est encore ma faute…)

Premièrement, tu as raison dans le cas d’une vérification hors-ligne.
Cette fameuse faille permettrait donc tout à fait ce que me dit : Tu peux mettre à jour ton app téléchargée depuis Google Play avec un APK vicié téléchargé sur eMule.

Donc tu me proposes de vérifier le certificat de la nouvelle APK… Avec le certificat de l’app déjà sur ta carte SD ?
Je ne crois pas que quiconque considère comme fiable ce qui est enregistré en local sur l’appareil de l’utilisateur (sur une carte SD ou la mémoire interne).
Toutes les données sur lesquelles tu vas appuyer ta vérification hors-ligne sont altérables, donc je ne pense pas qu’une telle vérification soit fiable.

Le 10/07/2013 à 15h 45

NeVeS a écrit :

T’es gonflé, t’as raconté un peu n’importe quoi pendant un moment, quand même, ce n’était pas juste “une erreur de vocabulaire”.



Désolé, tu peux relire tous mes posts en remplaçant “signature” par “certificat”, et tu comprendras mon argument.
Tu remarquera aussi que je n’utilise plus le mot “signature” depuis, mais “hash” et “certificat”…



Raknor a écrit :

(…)


Mais au final, on s’en fout royalement de cette vérification puisque la faille, telle expliquée, permet de bypasser (dans le sens passer avec succès) cette vérification (qu’on se dispute depuis la semaine dernière) malgré une altération de l’apk.
Cela se traduit par la violation au niveau de cet authentification. Conceptuellement, un apk vérolé ne provient plus de l’éditeur d’origine. Mais la faille fera authentifier l’apk comme venant de lui tout de même.

Edit: grillé par Khalev.



On est d’accord sur tous les points précédents, et Google vérifie bien la partie “certificat du dev” de la signature lors d’une soumission.

Mais la partie en gras est la base de mon non-inquiétude :
Auprès de qui comptes-tu vérifier que l’apk vient bien de l’éditeur?
Si une application est falsifiée, elle ne peut finir sur Google Play ou Amazon Store (à moins d’avoir les logins, blablabla).

Puisque Android est un système indépendant de Google, il n’a pas à lui demander une vérification pour un APK téléchargé depuis un store pirate !

Il n’y a donc pas de faille à proprement parler :
Elle permet de contourner une vérification qui n’a pas lieu d’être !

Petit détail rigolo : J’ai un dev iOS dans mon bureau voisin qui m’a expliqué que le keystore (ce qui permet de signer l’app) n’existe pas vraiment chez eux.
Ils signent l’application depuis le compte dev de l’AppStore, ils y ont une procédure pour ça…

S’il m’a dit vrai, cette “faille” sur Android est une porte grande ouverte sur iOS…
Pourtant, je n’entends personne s’en inquiéter (et pour cause, c’est une faille qui ne donne accès à rien en l’état)

Le 10/07/2013 à 14h 55

Raknor a écrit :

Et il y a quelque jours, on t’expliquait que c’est une SIGNATURE (cf doc officielle)

D’après la doc officielle, pour publier une MAJ, il y a 2 paramètres qui doivent rester invariants : le nom et le certificat (autrement, l’appli sera considérée comme une nouvelle appli).

Du côté du playstore:
Soit il n’y a pas de vérification certificat/signature. Dans ce cas, seul le vol du compte du dev est suffisant pour publier une MAJ corrompue. Ce serait le cas d’après Glubglub. Et vu la politique de validation à posteriori, ça a du sens.

Soit il y a vérification (possible car le certificat permet de vérifier la signature). Là il faut donc aussi pirater la clé privée du développeur pour pouvoir publier



Du côté du PlayStore, il y a lors d’une MaJ, il y a une vérification du certificat et du nom de package de l’app.

Il y a quelques jours, vous me souteniez qu’il y avait une vérification de la signature, et que le hash de l’apk était la signature.
Je soutennait que c’était impossible : puisqu’il y a eu MaJ, le hash avait forcément changé. Il ne sert à rien de le tester.

Même s’il y a eu une erreur dans mon vocabulaire, tout le reste était valable :
Google Play ne teste pas le hash de l’app lors d’une soumission d’une MaJ.
Il ne peut tester que le certificat, et le nom du package.

C’est donc la solution n°1 : Vérification du certificat, et validation à postériori.
Et oui, un “simple” vol de compte permet de mettre à jour l’app officielle.
Et c’est pareil sur tous les stores : si tu laisse ta porte d’entrée ouverte, tu peux facilement te faire cambrioler.



Raknor a écrit :

Mais il ne faut pas oublier cette partie, du côté de l’utilisateur :
Soit il y a vérification. Dans ce cas, pas possible d’installer une MAJ sans qu’elle ait été signée par le développeur d’origine. Mais je ne sais pas ce que fait le téléphone en tel cas.

Soit il n’y a pas de vérification. Dans ce cas, on revient au vol de compte du développeur.

Dans l’article mentionnée, la faille consiste à modifier l’apk sans changer la signature ; le magasin considérant que l’apk resterait légitime. Nous ne sommes pas dans le débat si google vérifie la signature ou pas, la faille est justement de bypasser cette vérification de signature.



C’est un point que j’ai voulu aborder sans m’exprimer clairement :
Si tu télécharges sur Google Play, tout va bien.

Mais si tu télécharge un APK ailleurs, il n’y a aucune requête de vérification envoyée à Google Play.

Android a été concu pour pouvoir fonctionner sans Google Play.
Si l’on télécharge une app sur l’Amazon Store, on n’a aucune raison de demander quoi que ce soit à Google.
Si l’on télécharge un apk en torrent, on n’a aucune raison de faire une demande à un quelconque store.



Raknor a écrit :

Soit il y a vérification : punaise de faille (et c’est le but de l’article il me semble)
Soit il n’y a pas vérification : tout l’écosystème est merdique à la base.



C’est donc la solution n°2 : il n’y a pas de vérification, et le système n’est pas “merdique à la base”.
il est juste conçu pour être indépendant de Google, et vous vous plaignez que Google ne fasse pas toutes les vérifications.

Si un store est hacké, alors oui, il y aura une faille massive à ce moment là.
Mais jusqu’à présent, les seuls hacks de comptes Google Play que je connaisse sont dûs à des failles humaines (MDP trop simples ou bêtement divulgués).



Raknor a écrit :

Mais nous sommes d’accord sur un point, il faut voler les identifiants du dev pour publier sur le store.



Oui !

Le 10/07/2013 à 12h 59

Khalev a écrit :

C’est là où mes connaissances de publication sur l’app store arrivent à leurs limites, y-a-t-il d’autres vérifications mise en place que celle du Login-mdp? Si je publie une app via mon login et que le certificat fourni avec l’application est toujours le même, cela est-il suffisant pour poster un appli?

Si c’est le cas, alors il y a bien risque de faille en cas de vol de compte.
Si non, le Gplay peut-être considéré comme sûr, sauf Grosse compromission du compte avec tous les autres moyens en plus. (Je rappelle que le compte Gplay de SkyNews avait été piraté il y a quelques temps, leur appli a quand même quelques autorisations sympas, mais pas d’accès au contacts par contre).



C’est exactement ça, on n’a besoin que du certificat, et du login du dev pour publier une maj sur Google Play.
Google ne peut tester le hash lors d’une nouvelle soumission : si c’est une maj, le hash sera forcément différent.

Il y a effectivement un risque de faille en cas de vol de compte, mais sans ça, il n’y a aucune faille possible pour Google Play.
C’est ce dont j’ai essayé de te convaincre en vain il y a quelque jours : c’est une faille exploitable seulement si toutes les autres portes sont ouvertes.

Ceci dit, c’est exactement la même sur tous les stores du monde : si l’on a le login du dev, on peut tout faire.

Le 04/07/2013 à 15h 15

NeVeS a écrit :



Bien, dans ce cas je vais utiliser le vocabulaire du cryptographe, pour éviter les confusions.
Désolé si Android ne respecte pas les normes.

On peut aisément copier un certificat sans problème, et l’appliquer à un tout autre APK.
Les mises à jour sur le store (à condition d’avoir les accès au compte Google Play du Dev) ne vérifient que ça, lorsqu’une mise a jour est soumise.
Lorsqu’une mise à jour est validée et publiée, la vérification du dld se fait avec le hash.
Jusqu’ici, on est d’accord…

Bien, maintenant la terrible faille est que la gestion des tokens est basée sur le certificat, et non pas sur le hash.
A bien y réfléchir, la plupart des stores ne re-demandant pas les permissions à chaque maj a un fonctionnement identique.

Mais la faille est donc que l’on peut falsifier un apk, et utiliser les permissions d’une autre appli.

C’est mal, mais cet APK falsifié n’a aucun moyen d’être publié sur un store sérieux.
Donc on en revient à la conclusion que je répète depuis tout l’après midi :
Tant que l’on ne télécharge pas ses apk sur un store obscur ou un site de torrent, cette “faille” ne pourra pas infecter 99% des machines, comme son titre raccoleur le clame.

Le 04/07/2013 à 14h 38

NeVeS a écrit :




Khalev a écrit :




millman42 a écrit :

En faite c’est dans le fichier apk, dans le dossier META-INF, il y a un fichier cert.sf qui contient le hash de tout les fichiers présent dans l’apk. Il est fournis avec son certificat cert.rsa.

http://en.wikipedia.org/wiki/APK_(file_format)



Merci, millman42.
J’ai pu vérifier du coup, je ne savais pas où était ce hash.

Voilà un exemple d’une de ces fameuses signatures :
AB" />6:10:91:EF" />1:5C" />8:57:38:08:03:0B:3F:7E:00" />8:EB:9E:5D
Il ne suffit que de ça pour publier un APK sur Google Play, ou autre.
Il est même pas masqué lorsqu’on tente de publier un APK signé avec un mauvais keystore sur Google Play.
C’est cette donnée qui est falsifiable, mais elle est complètement inutile sans avoir un accès total au compte Google Play Dev lié.
Elle ne change jamais, même lorsqu’on met à jour l’APK. C’est ce que renvoie le keystore.

Ce n’est pas un hash.
Ce qui est appelé “signature” sous Android n’est QUE ça.

Le hash, cripté, vérifiant la validité de l’application, fait 190ko.
Celui là est nettement plus critique s’il est cassé. Ce n’est toujours pas le cas.
Il est généré avec la clé publique, et c’est ce que NeveS et Khaley appellaient certainement la signature.

Voilà, voilà.

Le 04/07/2013 à 13h 43

NeVeS a écrit :

Hola, du calme. Ce n’est pas parce que tu répètes quelques choses 50 fois que ça en devient vrai. En attendant je n’ai toujours pas vu cette fameuse ligne de code qui permettrait de copier la signature d’un APK à l’autre et que ce dernier soit valide.

BlueBox parle de “modify APK code without breaking an application’s cryptographic signature”, ils ne disent pas “la signature n’en est pas une et il suffit de la copier pour que l’APK soit valide”.



Il n’y a que deux possibilités :

• Soit c’est effectivement possible de changer la signature, et je bosse dans l’une des nombreuses boites dans le monde qui savent le faire, et je ne vais pas fournir du code appartennant à mon entreprise.
  


• Soit c’est totalement impossible à faire… Et dans ce cas là les auteurs de cet article prétendent qu’un truc impossible provoque une faille de sécurité.
  
  
  
  
  NeVeS a écrit :
  
  Visiblement tu as des lacunes en chiffrement asymétrique. Le hash change, évidement, d’une version de l’application à l’autre, mais pas la clé publique. Et c’est cette dernière qui permet de dire si la signature (qui change d’une version à l’autre) est valide ou non. Et sans connaissance de la clé privée, tu ne peux pas forger de signature valide.
  
  
  
  
  Khalev a écrit :
  
  (même argument)
  
  
  
  Je suis d’accord avec vous deux.
  Mais si la signature ne change pas d’une version à l’autre, ça veut bien dire que ce n’est pas une “vraie” signature ?
  Dans ce cas, je vous invite à tester le dev Android (c’est gratuit), et à vérifier cette fameuse signature…
  
  
  

Le 04/07/2013 à 13h 15

Khalev a écrit :

signature = hash chiffré.

En gros pouvoir modifier le code sans modifier la signature c’est comme modifier le code sans modifier le hash. C’est à dire que tu fais confiance à un code qui n’est pas celui initialement fourni par le développeur officiel.

Tu le vois le problème là? Maintenant tu associes ça à une protection des comptes officiels qui laisse parfois à désirer et tu obtiens un joli cocktail explosif.



Râââh !
Ok, donc tu as raison. La signature EST un hash chiffré.
Effectivement, cela engendre des failles énormes.

Si seulement cette fameuse signature n’était pas un hash chiffré de l’APK, et que le hash était ailleurs, alors il n’y aurait plus de problème !

Si seulement…
Ceci dit, c’est quand même étonnant qu’ils arrivent à faire des MaJ d’applis (donc changer le hash de l’APK), tout en gardant la même signature…
C’est même la condition sinéquanone pour faire une MaJ.
C’est à croire qu’il n’y a pas de hash chiffré de l’APK dedans !



NeVeS a écrit :

Tu es d’accord que ce que tu dis est en totale opposition avec le site d’Android ?

https://developer.android.com/tools/publishing/app-signing.html



J’en ai un peu marre d’argumenter, et de recevoir 60 notifications à l’heure.

Alors relis-le, et teste des trucs. Je serai le premier à te féliciter si tu arrives à contaminer 99% des appareils Android.
Si tu préfères penser que tu as raison, alors il y a manifestement un énorme problème sur Android depuis 4 ans, et Google distribue depuis toujours les outils pour l’exploiter.

C’est quand même un coup de bol énorme que personne ne l’ait exploité, non?
C’est d’autant plus étonnant que les seuls problèmes sur Android viennent des APK téléchargées depuis des sites peu fiables, et des pseudo stores obscurs !

Comment Google Play, Amazon et compagnie ont pu éviter les problèmes pendant 4 ans avec un système aussi bancal ?

Le 04/07/2013 à 12h 50

Khalev a écrit :

Justement, la signature contient le hash (*) tel que vu par l’expéditeur. Toi de ton côté tu calcules le hash de ce que tu as reçu, tu compares ce hash à celui contenu dans la signature. Si c’est le même tu peux supposer que le code signé reçu est le même que le code signé envoyé.

(*) une signature c’est un hash chiffré.

Je veux t’envoyer un message A et je veux le signer:

• je génère un coupe de clé privé/publique p/P.
  


• je calcule le hash de mon message : h(A)
  


• je chiffre ce hash avec ma clé privée : p(h(A))
  


• je t’envoie p(h(A)), A, P (ma clé publique)
  


• tu déchiffres la signature : P(p(h(A))). Tu obtiens h(A) le hash tel que vu de mon côté.
  


• tu calcules de ton côté le hash du A que je t’ai envoyé avec un autre logiciel de hash : h’(A)
  


• tu compares h(A) et h’(A). S’ils sont égaux c’est bon, sinon c’est qu’il y a eu un soucis pendant le transfert.
  
  http://commons.wikimedia.org/wiki/File" />igital_Signature_diagram.svg
  
  Tu stockes P de ton côté comme ça lors des futures mise à jour tu peux comparer ton P à celui envoyé par moi. S’il est différent c’est que j’ai changé de clé, si ce n’était pas prévu c’est que c’est la grosse merde et je te déconseille de tenir compte de mon message.
  
  Pas besoin de faire intervenir un quelconque tiers, sauf que sous Android, quand on passe par Gplay, celui-ci s’occupe en plus d’authentifier P histoire d’assurer le coup, mais rien n’empêche un store tiers d’assurer ce rôle aussi, il suffit de stocker P+le store qui gère l’appli associée à P.
  
  
  
  Je vais devenir chèvre…
  En fait on est d’accord depuis le début.
  
  Donc selon toi, chaque store doit faire ses vérifications?
  Dans ce cas là, on est bien d’accord : il y aurait toujours un risque si l’on ne télécharge pas un APK depuis un store, ou si l’on fait confiance à un store malhonnête…
  
  Et c’est exactement ce que je dit depuis le début !
  Il y a déjà d’autres vérifications, et des hash pour le transfert de l’APK. Mais ce n’est pas le rôle de cette signature incriminée.
  
  

Le 04/07/2013 à 12h 31

psn00ps a écrit :

L’installeur pourrait garder la trace du store d’origine de l’APK, comme c’est fait dans les repositories Linux. Elles ont leur propre clé pour authentifier les paquets. Et ce tout en autorisant les packages non signés.



C’est une possibilité, mais dans la pratique, c’est impossible.
Si l’on stocke cette info sur l’appareil de l’utilisateur, elle sera forcément altérable, et donc pas fiable.



canti a écrit :

et justement, vu que ton app (vérolé) réutilise une clé Rovio, déjà publié sur le play store, google refusera de la publier non ?



Exactement, donc on sera bloqué si l’on a pas accès au compte dev de Rovio.



NeVeS a écrit :

Encore une fois je ne sais pas comment ça marche sur Android, mais c’est le principe d’une PKI.



C’est ce que je dis depuis le début, cette signature n’est pas une clef publique, c’est juste un tag.
Tu dis ne pas croire ça possible, mais c’est exactement ce que soulève cet article.
C’est tout à fait possible, et ça n’a pas de conséquence sur la sécurité.

Le 04/07/2013 à 12h 03

madjawa a écrit :

Sauf que sous iOS l’application est signée après la compilation avec la clé privée du client. Il n’est pas possible de modifier le package après qu’il soit signé à moins de posséder cette clé privée (même si on a accès au compte développeur, car la clé privé ne peut pas être retéléchargée naturellement)



Ok, donc la signature n’est pas seulement l’identifiant du compte Itunes du vendeur. Elle contient donc aussi un hash de l’app.

J’imagine que ce hash est vérifié par l’AppStore, et qu’il interdit l’installation s’il est falsifié?
Donc, en suivant cette logique, un iPhone aura forcément besoin de l’AppStore pour installer une app.

Mais (pour la 100ème fois), Android a été fait pour pouvoir fonctionner sans Google Play, et les stores tiers officiels sont légions.
Une vérification par hash est donc impossible (auprès de quel store on vérifierait la validité du hash ? Tous ?).

Forcément, ça ouvre des failles si quelqu’un fait confiance à un store vérolé. Mais si on s’en tient à Google Play, ou à d’autres stores de confiance, il n’y a pas de faille exploitable.

Le 04/07/2013 à 11h 51

Khalev a écrit :

Que toi tu ne parles pas de la signature numérique de l’APK peut-être, mais la faille porte sur la signature numérique. Et dans ce cas tu es hors sujet depuis le début

Je comprends pas ce que viennent faire les lois anti-trust dans la vérification par le hash. C’est le genre de méthode qui est utilisé… quasiment partout où il y a échange de fichier sans que ça pose problème.



Dans ce cas, je me clarifie :
La “signature numérique” consiste uniquement à un tag dans l’apk, rien de plus.
On peut récupérer un tag (cette fameuse “signature”), et l’appliquer à un autre APK depuis toujours en une ligne de code.
Tous les outils nécessaires sont disponibles dans les outils du SDK oficiel de Google.

Donc oui, tu peux prendre un APK vérolé, et le signer avec la clé d’Angy Birds. C’est très simple, rien ne nous en a jamais empêché.
Par contre, ce fameux APK falsifié ne pourra jamais être distribué à grande échelle. On ne peut le publier sur Google Play sans avoir le mot de passe du compte Google Play Dev de Rovio.

Donc à moins de publier ton APK falsifié sur un store obscur, ou un site de torrents, tu ne peux “contaminer” personne.
Mais si tu arrives à faire en sorte que des gens l’installent, il n’y aura aucun hash de l’application, ni aucune vérification envoyée à Google Play (pour la simple et bonne raison qu’Android a été conçu pour pouvoir fonctionner sans Google).

C’est plus clair?

Le 04/07/2013 à 10h 32

Khalev a écrit :

Si l’appli modifiée est signée côté dev, Google voit une modification, mais si la signature est légitime il va la laisser passer pensant à une màj.



Pas vraiment, il ne considère une mise à jour que si le numéro de version est changé. Cela est indépendant de la signature avec le keystore.

Il ne fait aucun hash de l’app. Jamais.
Google ne voit pas de modification, il n’a aucun moyen de le faire :

• Une fois l’appli installée, toutes les données stockées sur l’appareil sont potentiellement modifiées. Il n’y a donc aucun hash/identifiant fiable possible.
  


• Si le hash est vérifié par Google à l’installation de l’APK, cela obligerait à passer par Google play en permannence. Cela verrouillerait tous les autres stores (Amazon, Ouya, etc…) et imposerait encore plus le monopole de Google (pour lequel il se fait déjà taper sur les doigts).
  
  
  
  Khalev a écrit :
  
  En fait j’ai un problème avec ce bug. Si c’est dû à l’algo de signature et que le bug a été corrigé ça veut dire qu’en ce moment les APK sont envoyés avec 2 signatures différentes en fonction si le smartphone possède le correctif ou pas.
  Mais ça me semble un peu étrange comme façon de faire (surtout le faire de façon silencieuse comme ça)
  
  
  
  La même appli ne peut pas être publiée avec deux signatures différentes.
  Et oui, on peut même changer la signature en une ligne de code sur le terminal.
  C’est juste un tag ! Il n’a pas la vocation de servir à plus que ça.
  
  
  
  Khalev a écrit :
  
  T’es sûr qu’il change pas la signature? Pour publier l’app il faut pas passer par un outil spécial sur lequel le dév doit se loguer? Ça serait pas cet outil qui s’occupe de signer l’apk?
  
  Comme je l’ai dit je ne connais pas le système de publication sous Gplay, mais ce que tu me décris ne correspond pas du coup à ce qui se fait en matière de signature électronique. À moins que les ressources autres que le code ne sont pas signées, du coup modifier les images/URL/etc. n’influerai pas sur la signature, mais ça me semble encore plus tordu. (Quitte à signer un truc autant tout signer).
  
  
  
  Certain, il y a tous les outils pour décompiler/modifier/recompiler les APK dans le SDK de Google.
  Encore une fois : la “signature” n’est pas un hash. Il n’a jamais eu la vocation de l’être. C’est juste un tag pour Google Play, rien de plus.
  Elle a peut être un nom ambigu, (en tout cas en français), mais ce n’est pas une faille au système.
  
  Et je pense que la vérification par le hash est probablement impossible sans violer pas mal de lois antitrusts.

Le 04/07/2013 à 10h 16

Khalev a écrit :

Si la signature ne change pas en fonction du binaire, c’est pas une signature.
Ça serait pas la “clé publique” de la signature qui ne change pas par hasard?

La cryptographie c’est mon métier. Je ne connais pas exactement le fonctionnement de Gplay mais je connais le fonctionnement de signatures électroniques.

Globalement le fonctionnement d’une signature électronique c’est:
Je génère un couple clé publique - clé privé.
Je calcule un hash de mes données
Je chiffre mon hash avec ma clé privée.
J’envoie mes données, mon hash chiffré et ma clé publique (*)
Le destinataire calcul le hash des données, déchiffre le hash que je lui ai envoyé avec la clé publique et compare les 2. Si les hash sont identique on suppose que les données reçues sont identiques à celles envoyées par la personne possédant le clé privée.

Un schéma représentant la chose :http://commons.wikimedia.org/wiki/File" />igital_Signature_diagram.svg

*:normalement la clé publique est transmise par un autre canal, dans le cas de Gplay c’est possible que se soit avec l’APK et que ce serait donc ce que toi tu appelles la “signature”, c’est normal qu’elle ne change jamais, c’est la seule façon de garantir que celui qui envoie est bien la même personne à chaque fois.

Ceci dit si tu as un lien vers le doc Gplay à ce sujet je suis preneur.



Pour avoir étudié la cryptographie à la fac, je comprends tes réserves.
Mais la signature de Google Play n’en est pas une. Elle n’en a que le nom (et en français, en anglais ça s’appelle une clé).
Ce n’est vraiment qu’un tag, et ce n’est utilisé que comme tel.

Cela e pose un problème que si l’on a déjà un accès total au compte Google Play Developper, cela n’est pas une faille.
Encore une fois, ce n’est pas plus une faille que la possibilité de forker une application opensource. Pourtant les applications opensource avec des payements inapp existent.

La doc Google play est très complète, si tu veux de la lecture.

Le 04/07/2013 à 09h 51

Khalev a écrit :

Actuellement (sous réserve qu’il n’y existe pas une faille du même genre) la seule façon de réaliser la même chose sous iOS et WP c’est de trouver des collisions ou d’avoir la clé privée.



Dans ma boite, on vend des templates d’app tous les jours, et des outils pour les modifier à la volée.
La signature reste, et on laisse au client de changer les images, les couleurs, les liens URL de son choix…
Il recompile l’app sans nous, et sans changer la signature, et il publie l’app comme il veux.

Je ne travaille que sur la version Android, mais le même outil est fonctionnel sur iOS.
Donc je peux affirmer que c’est tout à fait possible chez la concurrence de Google.

Le 04/07/2013 à 09h 46

dj0- a écrit :

Comme évoqué plus haut par Khalev, imagine que le compte de facebook (ou gameloft) sur le play store soit compromis, et que soit proposé au téléchargement une application qui possède la même signature que l’app légitime mais qui est vérolée?
Tu imagines les dégâts?



Oui, ce serait catastrophique.
Mais c’est pareil pour tous les stores du monde : téléphoniques, consoles de jeu, etc.
Dès que l’on a accès au compte du dev, on peut faire ce que l’on veut.
(et encore, pas tout à fait : il y a des vérifications de faites par Google lors d’une publication, et un délai qui peut aller jusqu’à une semaine)

Bref, une faille est viable quand elle permet de contourner, ou de compromettre les avantages énormes de ce compte développeur.
Mais cette faille ne le permet pas, donc ce n’en est pas une.

Le 04/07/2013 à 09h 38

Khalev a écrit :

Euh…https://en.wikipedia.org/wiki/Digital_signature

Au lieu de dire des bêtises, renseigne-toi avant.



Désolé, mais le dev Android est mon métier.
Ce que l’on appelle signature sur Google Play n’est qu’un tag, pas un hash.
La signature est la même quelle que soit la version de l’app.

Et j’ai expliqué plus haut qu’un verrouillage via le hash est inenvisageable, cela enfreindrait pas mal de lois.

Le 04/07/2013 à 09h 31

dj0- a écrit :

Sauf que si cette faille n’existait pas, google pourrait connaître sur quels appareils est installée une app vérolée et les désinstaller à distance.
Avec la faille tu ne fais plus la différence entre les app vérolées et les app légitimes



Je comprends ton raisonnement, mais cette “fonctionnalité” serait impossible à mettre en place :
Google n’a aucun moyen de référencer tous les hashs des stores ne lui appartennant pas. (et encore une fois, il devrait se baser sur les hash et non pas sur la signature des APK pour ça).
Cela assurerai un monopole total du store GooglePlay. Il l’a déjà un peu, c’est vrai, cela tuerai instantanément le store Amazon par exemple.

Bref, je ne pense pas que cet argument soit valable au regard de toutes les lois antitrusts.
Je reste affirmatif sur le fait que ce ne soit pas une faille. C’est tout aussi possible sur iOS, et très certainement sur WindowsPhone.

Le 04/07/2013 à 09h 17

Ce n’est absolument pas une faille de sécurité !
La signature n’est pas un hash vérifiant la validité d’une app, c’est plutot un tag qui lui est accolé pour pouvoir vérifier les mises à jour, et avoir une validité lors d’un achat inApp.
On peut décompiler et recompiler n’omporte quel APK depuis toujours sans avoir à re-signer. Si cette fonctionnalité est bloquée, beaucoup de boîtes qui vendent des IDE vont couler.

C’est ridicule, pour nuire au public, on devrait soit :

• Faire en sorte que les gens téléchargent les APK sur des sites de torrent ou des markets obscurs.
  


• ou récupérer le MDP du compte Google Play developer de l’app.
  
  Si l’une de ces deux condition n’est pas remplie, il n’y a absolument aucun moyen de nuire.
  Et même si cette “faille” n’existait pas, l’une de ses deux conditions aurait déjà été suffisante pour faire faire ce que l’on veut à n’importe quel téléphone…
  
  Autant affirmer que tous les projets opensources ont une faille de sécurité :
  On peut les forker et rajouter un virus…
  C’est presque tout aussi ridicule comme alerte.

Le 01/07/2013 à 08h 34

Blastm a écrit :

Bon, mario foot c’est fait, mario golf aussi, mario baston/abeille/arrosoir aussi…
vu ce qu’il reste comme concept très différents, je crois qu’on peut ouvrir les paris entre mario pogo stick et mario zumba :o



Encore un qui confond “jeu original” et “univers original”.
Nintendo innove sans cesse, il y a plus de différences de gameplay entre deux Papier Mario qu’entre deux FPS quelconques sur PS360.

Mais effectivement, ils ne changent jamais le background de leurs jeux.
Il faut voir ce que tu préfères : des jeux au gameplay innovant avec le même background, ou toujours le même jeu avec juste un décor qui change.

Le 28/06/2013 à 15h 44

Cool, est-ce qu’ils ont saisi leurs serveurs ?
Ça va faire du spam en moins !

Le 28/06/2013 à 12h 44

Séphi a écrit :

Heuuu la PS2 n’est plus produite depuis le 30 novembre 2012, même avec de gros stocks il n’y a pas de quoi faire la différence….

Et depuis le 7 janvier de cette année elle n’est même plus vendue nulle part :http://fr.wikipedia.org/wiki/PlayStation_2#Commercialisation



Tiens, c’est vrai, je l’ignorais…
La magouille ne tient plus, mais elle aura duré un petit moment.
Fin 2009, la PS2 avait encore des sorties nationales en Afrique, les années 2010 à 2012 ont clairement fait du chiffre. Même dans l’hémisphère nord.

Les journalistes soulevant régulièrement cette “omission” estiment à au moins 10 millions de moins le nombre de ventes réèles de PS3.
Et depuis la fin de la PS2, les chiffres fournis par Sony n’ont pas du tout été corrigés.

Ah, et la PS3 n’a pas 512mo de mémoire vive, elle n’en a que 256.

Le 28/06/2013 à 09h 31

Sony fausse ses chiffres de vente de la PS3.
Depuis deux ans, ils ne communiquent que les chiffres de vente des consoles de salon en général.
Les gens prennent ça pour les ventes de PS3, mais ils oublient que la PS2 se vent toujours très bien dans les pays émergents.
Leurs ventes sont donc ajoutés au total, et les ventes de PS3 sont artificiellement gonflées.

Bref, selon Sony, les ventes de consoles ne fléchissent pas, à condition de traffiquer les chiffres, et de laisser les journalistes dans le flou.

Le 22/06/2013 à 18h 40

Etant un assez gros trekkie, je suis allé voir Into Darkness avec des amis qui découvraient l’univers.
Ils ont eu à peu près la même réaction que l’auteur de cet article, mais pour ma part, j’ai vécu le plus grand nerdgasm de l’année.

Cependant, j’ai du mal à admettre qu’on puisse prétendre connaître Star Trek et crier au plagiat paresseux de La Colère de Kahn. Oui, le méchant revient, et quelques références sont là.
Mais un trekkie averti pourra trouver encore plus de similitudes avec le 6ème film (le terrorisme au sein de Starfleet, les causes d’une guerre avec l’empire Klingon…), ce qu’aucun critique ne semble soulever…

Bref, l’histoire du 12 vaut clairement plus qu’un simple plagiat du 2. Prétendre le contraire “au nom des fans de Star Trek” est un peu maladroit.
Si d’autres se plaignent d’une relecture différente des thèmes, ponctuée de quelques références explicites, je pense pour ma part que c’est exactement ce que doit offrir un reboot.

Le 21/06/2013 à 13h 49

Il est pas obligé d’avoir des idées… Il peut aussi déléguer !
Les Zeldas auxquels il n’a pas vraiment participé sont très bons (les Oracles, Majora’s Mask, Link’s awakening…)

Le 21/06/2013 à 13h 29

Romain Lacombe…
Je savais que je connaissais son nom : il était passé sur le podcast e-Dixit, pour expliquer son boulot pendant plus d’une heure.
Il avait pas l’air d’un mauvais bougre.

Le 19/06/2013 à 14h 17

Munsh a écrit :

Ca n’est pas de la présomption, mais simplement une constatation.



Tu es l’exemple parfait du client à qui Nintendo ne sait pas communiquer.

Nintendo fait des jeux innovants, mais réutilise le même background : “Oh, encore un Mario, c’est toujours pareil”
Pendant ce temps, les autres éditeurs te vendent 40 fois le même jeu en changeant uniquement le background : “Oh, super, j’ai jamais joué à celui-là !”

C’est là le vrai problème. Nintendo n’arrive pas à te faire comprendre qu’il y a bien plus d’innovations de gameplay entre Paper Mario 64, Wii et 3DS qu’entre CoD, Crysis et Battlefield (qui sont pourtant des licences différentes !).

Et pour le marronier sur la puissance d’une console, c’est un débat cyclique dont le PC sort toujours gagnant.

Le 19/06/2013 à 09h 24

Munsh a écrit :

• Des exclus repompées made in Nintendo refourguées Ad Nauseam, avec prostitution de mario jusqu’à plus soif… Et ce n’est pas le magnifique Zelda WW HD dévoilé lors de l’E3 qui me contredira.
  
  
  
  C’est exactement le genre de pensée commune qui nuit à Nintendo.
  Là est le vrai problème de communication de la boîte.
  
  Le gamer moyen pense sincèrement que Nintendo fait toujours les mêmes jeux, et que la machine la plus puissante est toujours la meilleure.
  
  Ces présomptions erronées sont les pires ennemis de Nintendo, et malheureusement beaucoup de joueurs pensent pareil.

Le 13/06/2013 à 17h 14

Le Rayman Legends a eu un mal fou à voir ses ventes décoller.
Vous vous souvenez? Il est sorti le même mois que le nouveau Zelda, le Mario 3DS, Skyrim, Batman, CoD, Battlefield, le FIFA, Uncharted 3, etc…
Ils ont sorti leur nouveau jeu dans le mois l’un des mois les plus chargé imaginable, et se sont pris une tôle…

Le Rayman Legends est prêt depuis plus de 6 mois pour la WiiU.
Au lieu de le sortir tranquilement et faire plein de ventes, ils préfèrent le repousser jusqu’en fin d’année.
Ils vont tomber en concurrence avec GTA5, les FIFA, CoD, Battlefield, Batman, et les nouvelles consoles…

A moins que tout le monde aie 1000€ de budget jeux en fin d’année, je ne vois pas comment toutes ces sorties majeures ne vont pas s’entre-tuer.
Les gens vont faire des choix, et toutes les sorties vont subir des ventes en deçà de leurs prévisions nombrilistes.

Retarder le nouveau Rayman à été non seulement une erreur de communication, mais sera aussi certainement une énorme erreur commerciale.
Ceci dit, les ventes du nouveau Rayman décolleront certainement quelque temps après sa commercialisation, exactement comme le Origins.

Ubi n’est pas très malin sur ce coup là, ils snobent la WiiU, agacent les fans de Nintendo, pour perdr de l’argent.

Le 12/06/2013 à 13h 30

ste6616 a écrit :

La Wii est loin d’être le grand vainqueur de la gen actuelle. Elle risque de finir avec la PS3 et 360 pas très loin derrière. La PS3 et 360 sont actuellement à environs un rythme de 7.5 millions de consoles vendues en plus par an que la Wii (chiffres basés sur les ventes de 2011 & 2012, où la Wii était encore le fleuron de Nintendo). On en est à 22 millions d’avance pour la Wii..



Ça fait trois ans que Sony gonfle artificiellement les ventes de la PS3.

Ils ne communiquent que les chiffres de vente des “consoles de salon” :
une petite astuce pour ajouter les ventes de la PS2 (qui se vend encore très bien dans les pays émergents) à la PS3.

Je vous encourage à écouter radio01, un podcast très sympa avec des professionnels du milieu comme intervenants, où l’astuce est souvent énnoncée.

Le 05/06/2013 à 09h 36

Pauvre AMD, ils sont souvent critiqués, mais pour un budget de 100€, ils ont toujours été mon choix.

Les comparatifs de processeurs à prix équivalent sont trop rares, effectivement. Mais je suis sûr qu’ils ne s’en sortiraient pas aussi mal que ce que leur réputation présumme..

Le 28/05/2013 à 09h 25

desmopro a écrit :

Ils ont un DevKit de Pinpin en boite ( http://fr.wikipedia.org/wiki/Pipp!n ) qu’ils estime a seulement 500/600E (PS : C’est PLUS que rare.) et ils veulent vendre goldeneye 64 a un prix entre 12000 et 15000 ?

WTF ?



Tu confonds “rare” et “demandé”.

Ça a beau être bien plus rare que n’importe quel jeu 64 sous scellé, je ne vois pas qui oserais mettre 600€ là dedans.
Ça n’a qu’une valeur spéculative, mais aucune valeur réèle.

C’est un phénomène un peu trop présent dans le rétrogaming.
Beaucoup d’objets sont maintenus artificiellement à des prix beaucoup trop élevés, au point qu’ils ne se vendront plus qu’à d’autres spéculateurs.
Une sort de chaîne de Ponzi qui ne demande qu’à s’écrouler.

Le 23/05/2013 à 13h 14

Moi je le crois.
Le meilleur PC du marché est sûrement plus lent qu’une console “new gen” chez EA.

Mais si l’on désinstalle Origin, la tendance s’inverse.

Le 21/05/2013 à 22h 18

Winderly a écrit :

Ah intéressant car j’ignorais tout de la partie en gras.
D’un autre côté ça a pas empêché certains de faire l’inverse (fenêtre, pomme…).
Mais est-ce que ce site risquait réellement de rendre commun le mot Nutella ?



Oui, rien n’empêche d’utiliser un nom commun comme marque.
A condition que ce nom soit déposé dans chaque zone (pays, continent…), dans chaque domaine d’utilisation (informatique, gastronomie…) et surtout que la marque soit défendue.

Si Apple a déposé sa marque en gastronomie, sans jamais sortir de produit alimentaire, alors un fabriquant de gâteaux aux pommes pourra utiliser le nom pour ses propres produits. La marque (dans le domaine alimentaire) serait perdue pour Apple.

Et effectivement (malgré nos quelques commentaires éclairés, pas grand monde ne comprend) : pour le Nutella, c’est pareil.
Le terme a un bon pied dans le langage commun, et n’importe quel vendeur de crêpe utilise cette marque pour du chocolat fondu. Ferrero risque de le perdre.
S’ils ne peuvent pas taper sur chaque snack-bar pour utilisation abusive de leur marque, ils peuvent faire un exemple avec quelque chose d’attaquable.

Ferrero n’a rien contre ce site, et ça les embête certainement de s’attirer cette pub négative…
Mais ne pas défendre la marque ouvrirait une brèche qui permettrait à Carrefour à écrire le mot “Nutella” sur sa pâte à tartiner Carrefour Disount.
Peu importe la cible, il se doivent de prouver qu’ils défendent un minimum leur marque s’ils ne veulent pas la perdre.

C’est un mécanisme qui est à l’étude sur les brevets, en Europe, pour calmer les patent trolls :
Si tu n’utilise pas ton brevet, tu le perds.

Le 21/05/2013 à 13h 58

J’ai lu très peu de commentaires comprennant vraiment les raisons de Ferrero…
Nutella est une marque déposée. Si ce nom propre devient trop courant dans le langage commun, il devient un nom commun.

Et si la marque devient un nom commun, Ferrero peut perdre l’exclusivité du nom de leur création. (comme sopalin, frigidaire et mobylette).
IPhone, PlayStation, Coca et Nintendo ont du des problèmes similaires.

L’arrivée de “Google” dans la langue courante pose exactement les mêmes problèmes à l’entreprise : ils doivent défendre leur marque pour ne pas voir la concurrence réutiliser légalement leur nom dans 15 ans.

Le 17/05/2013 à 15h 45

Vieux_Coyote a écrit :

en même temps actuellement, c’est kickstarter (ou autres) qui perçoivent des sous sur chaque projet, non ? (edit : si oui, du coup je préfère que les bénéfs aillent en France …)

Si l’État met en place un système avec une juridiction claire et intraitable dessus, pourquoi pas. Au pire des cas, ben on continue comme maintenant avec kickstarter et compagnie …



Si l’état met en place sa plateforme sur laquelle il prélève des taxes, PERSONNE ne postera de projets dessus.
Ceux qui veulent monter un projet vont se tourner vers un kickstartr non taxé.
Même si l’état impose son outil, ça ne fera qu’accentuer le nombre de startups qui vont fuir la France.

On ne tape pas sur les riches multinationales là, on tape sur les petites boîtes qui émergent… C’est idiot.

Mais d’un autre côté, laisser faire en toute impunité peut mener à de graves dérives…
C’est un problème complexe.

Le 17/05/2013 à 08h 24

Djaron a écrit :

Non non non non non ne dis jamais ca malheureux !
si jamais tu oses traiter Anita Sarkeesian de voleuse tu passeras toi aussi pour un odieux macho fachiste à abattre sans sommation.
elle en a eu besoin de cet argent, pour pouvoir cracher sur la gueule de l’ensemble du genre masculin drapée dans sa dignité. c’est que ca revient cher d’insulter les gens avec de gros amalgames aussi racistes que ceux qu’on denonce quand on est seule, il faut des moyens mediatiques, ca coute cher m’voyez….

you know i used to respect women… then i took a feminist to the knee !



En fait, son opinion ne me dérange pas.
Elle a le droit de dire ce qu’elle veut, même si beaucoup sont en désaccord.
Mais la polémique qui entoure son message masque complètement son excroquerie.

C’est un bel exemple de dérive du crowdfounding. Elle a réussi à embrouiller tout le monde, et à engranger énormément d’argent sans mettre a exécution son projet.
Il y a de quoi faire une loi, et encadrer tout ça.

Le 16/05/2013 à 16h 42

Les systèmes de crowfunding sont neanmoins discutables.
Il y a du bon, voire du très utile.

Mais il y a aussi des dérives :
Déjà, c’est un excellent moyen de blanchir de l’argent.
Mais c’est aussi un bon outil pour escroquer les gens.

Quand je vois qu’Anita Sarkeesian a récolté plus de 150,000 dollars sur kickstarter grâce à l’acharnement qu’elle a subi…
Avant de disparaitre dans la nature avec l’argent d’associations qui croyaient en elle.
Je trouve ça dégueulasse, et je ne serais pas choqué que chaque état y impose un peu de régulation.

Le 16/05/2013 à 12h 54

@brazomyna : Merci de reconnaître que je peux critiquer Java sans être un troll.
Pour répondre à ta question, j’utilise java parce que le projet de ma boite est sur Android. Et on a parfois dû porter des morceaux sous le NDK d’Android (du C, grosso modo), justement à cause des limites de Java.

Java n’est pas à la ramasse partout, mais il l’est pour les algorithmes décisionnels.
Et je suis sûr qu,‘il y en a pas mal besoin dans un IDE, pour l’aide automatisée au dev.

L’absence d’héritage multiple est assez gênant, et peut compliquer la modé sur un lourd projet. et je pense aussi que c’est préjudiciable à un IDE.

Au final, j’ai quelques raisons de penser que ce n’est pas le meilleur choix pour développer un IDE.
Et quitte a voir Google changer de crèmerie, j’aurais préféré le voir partir sur un truc vraiment différent.

Là, on a juste du droit a un import d’une librairie déjà existante, dans un IDE pas si différent. Je grince donc un peu des dents quand je vois des developpeurs plutot occasionnels crier au génie.

Le 16/05/2013 à 11h 36

brazomyna a écrit :

Je ne vais pas m’étendre sur le truc qui n’est qu’un troll des années ⁸⁰⁄₉₀.
Il y a des millions de pages web sur le sujet, qui montrent au moins autant que 1) Java s’en plutôt très bien dans la plupart des situations à quelques % près de langages compilés, mieux dans quelques rares cas et beaucoup moins bien dans d’autres cas spécifiques et 2) vouloir mettre un chiffre global sur un comparatif de perf est juste idiot tellement d’un algo à l’autre les perfs relatives peuvent varier.



OK, soit.
Je vais donc préciser, pour ne pas me faire accuser de troll :
Dans mon métier, inge en IA, j’implémente des souvent des algos. Même dans les plus simple (namedrioping des plus courants : Floyd-Warshall, A*), Java met en moyenne 10 fois plus de temps.

Pour un appel à la BDD, ou le lancement d’une fenêtre, je ne dis pas.
Java fait aussi bien que n’importe quel autre language.

Mais pour un algorithme d’IA quelquonque, je n’ai jamais vu Java faire des merveilles.
Je n’ai jamais mis les mains dans un IDE, mais je pense que ce genre d’algos dans les aides apportées au développement.

La propreté du code esst importante, je ne dis la le contraire, mais c’est aussi possible tailleur qu’en Java. Ce n’est pas un argument valable selon moi.

Encore une fois, je ne trolle pas Java : c’est mon language principal, et mon métier.
Mais je ne ferme pas les yeux sur ses nombreux défauts par pur fanatisme :
Je suis souvent confronté à ses limites, que ce soit en termes de conception ou de performances.

Le 16/05/2013 à 09h 25

HarmattanBlow a écrit :

Ce troll. " />


Je ne voit pas en quoi c’est trollesque : exécuter un programme dans une machine virtuelle est forcément plus lent qu’un programme compilé en assembleur.
10 fois plus lent, selont quelques profs de mon ancienne fac.



lordzeon a écrit :

Est-ce que l’installation est plus simple qu’Eclipse et ses plugins ?
Si oui, c’est toujours ça de gagné.
Je développe occasionnellement pour Android et je ne garde pas forcément Eclipse sur ma machine en permanence. A chaque fois je rêve d’un setup qui me donnerait un environnement de travail opérationnel (ce qui n’est pas le cas avec Eclipse, cela à été décrit un peu plus haut).




C’est exactement pareil ! Ce sont les mêmes plugins.
L’installation est simple si l’on prends le Bundle avec IDE+Android préconfiguré…

Mais le même bundle existait avec Éclipse depuis plus d’un an.
Rien n’a vraiment changé !

Le 16/05/2013 à 09h 08

J’y ai passé la matinée, et c’est honnêtement une douche froide.
Rien n’a changé dans le SDK, le simulateur n’a pas bougé.
Les plugins propre au dev Android (interface graphique pour créer les layouts en XML, etc) n’ont pas été changées d’un iota…

Bref, cela n’apporte rien de plus au dev Android qu’un changement d’IDE.
Je n’ai rien contre Intellij, mais je n’avais pas grand chose conte éclipse non plus…
Surtout, les deux souffrent du même manque de réactivité, et pâtissent du fait qu’ils sont développés en java.

Bref, cette migration n’apporte pas grand chose. Juste un changement d’IDE, pour un autre franchement similaire.
Je ne comprends pas les commentaires qui applaudissent ce changement : ça n’a rien d’une avancée ! C’est tout juste une pirouette et un atterrissage au même endroit…

Porter quelques librairies Java d’un programme à un autre n’est pas franchement compliqué… C’est sympa de l’avoir fait, mais ça ne mérite pas tout ce battage.
Google changera la vie des devs en portant ses outils sur Xcode, VisualStudio… Voire en créant son propre IDE. Et pas en Java.

Le 15/05/2013 à 20h 36

nikkolei a écrit :

Non. Persona 4 ca date de la PS2, ce n’est pas un jeu multiplateforme.


Je ne comprends pas, tu semble te contredire dans ton propre contre-argument…
S’il existe sur une autre plate-forme, c’est donc un jeu multi-plateforme.



nikkolei a écrit :

Pour moi MH3 n’est pas un seller : c’est la version ++ du jeu déjà existant sur Wii


Oui, c’est vrai, c’était pas le meilleur exemple.
Mais ce n’est pas un remake, et c’est une licence historiquement portable, alors ça a faisait sens dans ma tête.
Mais même malgré ça, MH est clairement un seller, ce n’est pas la PSP qui dira le contraire.
Son pouvoir attractif est dans une toute autre catégorie que Soul Sacrifice, Persona ou Zero Escape.
(Tiens, Soul Sacrifice… Tout comme Gravity Rush : un bon jeu, mais clairement surévalué à cause de son manque de concurrence, et certainement pas un seller.)



nikkolei a écrit :

Et la PSV n’a pas Mario Cart mais il a son Wipeout (certes, moins vendeur sur le multiplayer).


Je pense sincèrement que Wipeout a fait vendre autant de Vita que Pilotwings Resort a fait vendre de 3DS.

Pour le reste, je suis d’accord avec toi :
La WiiU est un presse-papier à 300€ tant que Nintendo ne sort pas de jeux, parce que personne d’autre ne le fera à leur place.

Mais le cas de la Vita, c’est plus inquiétant :
Leur seule licence qui ferait vraiment vendre des consoles est Gran Turismo.
Toutes leurs autres cartes sont des jeux sympas, qui feront certainement plaisirs à ceux qui ont déjà la console, mais sans qui n’en feront pas vendre beaucoup plus.

La 3DS est déjà bien installée, et a encore plein de sellers en réserve : Zelda, Pokemon, Smash Bros… Même un F-Zero serait un seller potentiel s’il était correctement marketté !

C’est dommage, le monopole d’un constructeur sur un marché est toujours néfaste…
Je préfèrerais que 3DS et Vita se livrent à une guerre équitable, les consommateurs/joueurs y gagneraient.

Mais même Sony n’y crois plus : déjà à l’E3 2012, le seul jeu Vita annoncé à la conf’ Sony était PS All Star Battle. C’est triste.