Le 21/12/2016 à 16h 36

uzak a écrit :

C’est comme les producteurs en fait, qu’est ce qui les empêche d’aller vendre leurs produits ailleurs que dans la grande distribution ? Chez les lactalis ? Chez bigard ?



Le producteur/chauffeur cherche une plateforme de distribution/une application de mise en relation avec les acheteurs/clients.
Cette plateforme fixe ses conditions tarifaires (% en plus, prix de vente obligatoire, % de marge…)

Dans le reportage que je mentionne (mais que je ne peux référencer, navré c’était sur Capital il me semble), il s’agissait d’un petit producteur exotique (donc pas de coopérative) qui voulait se faire une image auprès des consommateur. Il était dégouté des conditions tarifaires (qu’il ne peut révéler, clause confidentialité oblige), mais le faisait pour la publicité et comptait arrêter pour repasser dans le circuit de distribution style petit commerce.

Pourquoi le petit commerce disparaît : on peut citer plein de raison, comme par exemple, prix concurrentielle de la grande distribution (justement). Les acheteurs, pour des raisons de pouvoir d’achat, vont la-bas (entre autres raisons).

Dans le cas d’Uber, l’alternatives à Uber:
-VTC (moins souple, mais aussi décrié)
-taxi (ah non, faut pas toucher)
-développer une application qu’un indépendant pourrait utiliser pour sa mise en relation ==> de l’autoentreprenariat en somme. Problème : se faire connaître, assurer un service régulier etc… comme dans toute création d’entreprise… Temps et argent dans tout ça, alors que les gens veulent veulent du gagne-pain.

Si on veut un statut protégé (assurance, retraite etc), autant aller le chercher là où il est fourni (VTC, taxi..).

Si Uber “marche” autant, c’est qu’il y a une demande que les VTC et les taxi ne peuvent complètement servir (raisons à débattre)
Si les choses étaient bien faites, Uber ne devrait pas marcher justement.

Le 21/12/2016 à 16h 04

ActionFighter a écrit :

C’est scandaleux.

Un indépendant qui ne fixe pas son prix et qui utilise une plateforme tierce prenant une commission pour chaque vente de services n’est en rien indépendant.

Ce n’est pas une responsabilité sociale qu’il faut, c’est une requalification en salariat.



Tout producteur dépends d’un circuit de distribution s’il ne dispose pas de la sienne. Les modalités de commission dépends de ce qui a été négocié et accepté. Il y a déjà eu des reportages sur l’opacité des contrats entre les producteurs et la grande distribution. Faut-il dire que ces producteur sont en fait des salariés de la grande distribution ?

Je ne capte pas la polémique avec ce style de fonctionnement. Si le modèle d’Uber dérange pour ces “indépendants” qu’est ce qui les empêche d’aller voir ailleurs ? Voire de se faire embaucher par une vraie société de VTC.

Le 18/07/2016 à 14h 15

Avec leur bridage de youtube sur les lignes adsl (en ce temps là), parce qu’ils voulaient que youtube participe à l’investissement sur les réseaux, je ne suis pas certain que cette fois, free protège les utilisateurs.

Le 20/05/2016 à 12h 32

C’est quoi le rapport ?

Le 20/05/2016 à 08h 06

Moi je dis, un de ces 4, tout ce qui est moteur de recherche, agrégateur etc, devrait faire grève (de toute façon en France…) et suspendre leurs services pendant 1 mois voire 1 an.

Et tant qu’à faire dans l’absurdité, faudrait aussi suspendre le DNS.

Le 13/05/2016 à 16h 31

OlivierJ a écrit :

Dans de l’air raréfié comme il est question ici (1/1000e de la pression atmosphérique, non ?), je vois mal comment une turbine peut être efficace, faute de densité suffisante de l’air.



A 1200km/h, la capsule va agir plutôt comme un piston dans le tube.

En fait, il faut voir si le débit de l’air qui s’écoule entre la capsule et le tube (donc de l’avant vers l’arrière), permettra de/suffira à compenser un accroissement potentiel de la pression d’air en amont (risque de pression de freinage, depression de retenue de l’arrière, mais surtout accroissement des frottements fluides qu’on veut réduire au maximum).

Il faut voir la turbine comme une simple pompe d’air de l’avant vers l’arrière.

Le 13/05/2016 à 16h 15

Commentaire_supprime a écrit :

Sachant que, par exemple, un réacteur à fusion nucléaire peut parfaitement être relié au réseau électrique actuel, et qu’on peut récupérer les sites des centrales nucléaires désaffectées pour installer l’engin.


Oui enfin non, à ce jour, aucune centrale nucléaire n’a été effectivement correctement démantelé + stockage dechet radioactif.
Problématique pour EDF avec ses 58 réacteurs dans les 20 ans à venir.



Commentaire_supprime a écrit :

Là, on a un projet où personne n’est foutu de nous dire à quoi ressemblera une gare et comment elle fonctionnera, avec un machin qui est d’entrée absolument incompatible avec l’existant, pour ne parle que du plus visible à ce stade.



Bien ma peine d’écrire des romans, je vais me mettre au dessin je pense.
Quand ils ont commencé maglev ou aerotrain, idem, rien de compatible avec l’existant.
En ce qui concerne les gares, étrangement, je pense aux roller coasters…

Le 13/05/2016 à 15h 30

Contrairement à l’époque du maglev/aerotrain, la capsule pourra être faite en composite (+léger)

Mais ce n’est pas ce moteur qui va propulser la capsule, c’est le rail.

Le 13/05/2016 à 15h 22

Considère juste:
-le projet hyperloop actuel = test des concept et technique
-le projet hyperloop LA-SF = prototype pour servir de demonstrateur.

Pour l’instant on peut communiquer sur le prototype. Ca ne sert à rien de faire des plans pour l’exploitation.

Mais ca n’empêche pas d’imaginer comme ça serait. Et parmi tout ce que j’ai dit, rien de révolutionnaire, juste des choses déjà connu mais intégré ensemble.

Je me répête, même si c’est du rêve, la R&D c’est faut essayer.
Comme aerotrain/maglev…

C’est pareil que pour ITER.
Les tokamak existent, et ITER doit servir de démonstrateur (ici aussi, la viabilité économique est inconnue, pourtant on a débloqué 50milliard pour le construire).
Et pourtant ITER a encore beaucoup de problème encore non résolu (renouvellement du combustible, neutron rapides, maintenance, autoentretien de la fusion..)alors qu’on n’arrive même pas à tenir un plasma plus de 30s…

Le 13/05/2016 à 15h 00

Pour les transports standards, à grande vitesse, le problème ne vient pas de l’accélération mais des frottements de l’air (résistance de l’air, déjà dit dans les commentaires) (et des frottements de contact au sol).

C’est pour ça qu’en chute libre dans l’atmosphère, la vitesse de descente se stabilise à une vitesse limite en fonction de l’objet.

Par contre, sans frottement, seul l’accélération agit (2ème loi de Newton).

En parallèle, dans l’espace, 1kg de plomb et 1kg de plombe “tombent” avec la même vitesse).

Bon ici, il restera un peu de frottement fluide (air). Le prototype devrait permettre de déterminer quelle pression mettre.

Le 13/05/2016 à 14h 51

OlivierJ a écrit :

Ça me paraît très court aussi. Déjà pour faire monter les gens dans un RER…
Ou alors, il y a plusieurs sas au départ et à l’arrivée, en rateau.



En reprenant mon commentaire précédent, tubes d’insertion et de sorties.

1 sas à l’arrivée, 1 sas pour le départ. (aux extrémités)

4 sas pour les stations intermédiares (2 pour chaque sens)

Dans la zone de gare, tu peux en effet avoir des rateaux (comme dans les gares actuelles).
De plus, dans ces zones, vitesse de circulation standard ( par exemple 40km/h) pour aller de quai vers sas et sas vers quai. Donc déplacement sur rail (rétracté dans la capsule lors de la circulation dans le tube), virage et pente standard possible.

Le 13/05/2016 à 14h 42

Qui parle d’arrêter l’ensemble du système?

Pour le prototype, oui le design est monotube avec une seule capsule. Mais un tel schéma n’est pas viable commercialement.

Pour une mise en service commerciale, on peut:
-avoir des tubes principaux à pression de service constant pour les trajets (au moins 2, 1 dans chaque sens)
-des tubes d’insertion/accélération, de sorties/décélération (imagine des raccords de plomberie) aux bouts dequels se trouvent les sas de pressurisations/depressurisation pour l’accès aux capsules.
L’idée c’est qu’au niveau du raccord, la vitesse de la capsule soit déjà à la vitesse de fonctionnement. Là, il n’y a que le rail de propulsion qui est utile pour la capsule. La sustentation est assurée par l’air. Ce rail peut être permuté entre plusieurs positions comme un essui-glace. Le raccord ressemble plus à un gros triangle très allongé. (et j’ai déjà parlé de la problématique de la complexité d’un tel aiguillage, vitesse de permutation, résistance, longueur…)

Par ailleurs, un tel schéma permet, comme pour les autoroutes, des sorties et entrées, donc pouvoir desservir des villes intermédiaires (distant tout de même à 2 fois la longueur du dit triangle)

Les stations intermédiaires ressemblerait alors à très long losange (le dit triangle 2 fois, collé à la base).

Pour insérer une capsule ou la sortir, c’est comme les aeroports. Une fois connu les temps de commutation de l’aiguillage etc, on peut définir des créneaux.

Le 13/05/2016 à 12h 51

OlivierJ a écrit :

On ne peut pas faire d’aiguillage. Le tube sera maintenu à vide sur toute la longueur, et on montera à l’arrêt à chaque extrémité via un sas, comme dans une station spatiale.



Faux (pour le “à vide”), le design prévu de l’hyperloop est d’avoir quand même une pression résiduelle dans le tube.
L’écoulement de cet air sous la capsule à haute vitesse permettra la sustentation de celle-ci en utilisant la portance (même principe que pour les F1, la portance sous la caisse a tendance a soulever la voiture, d’où le profil hyper bas et les ailerons).
Cela évite d’avoir à installer des rails sustentateurs comme pour le maglev.

D’autre part, comme il est prévu un départ de capsule toutes les 30s, ça ne sera pas un tube où une seule capsule fera des aller retours. Même avec un système bi-tube, il faudra gérer les capsules arrivantes/partantes. Que ce soit dans les tubes, ou en dehors (comme dans une gare), il faudra des aiguillages.

Le 12/05/2016 à 20h 12

linkin623 a écrit :

Freinage : un tube avec de l’air ! Tu as ton “tube principal” avec du vide, et des tubes secondaires avec de l’air. Un aiguillage te balance sur la voie secondaire, et le simple frottement de l’air à 1200 km/h te ralentira pas mal. Sans compter sur un freinage magnétique…


On peut aussi utiliser un champ magnétique pour freiner comme pour l’accélérer.
L’idéal serait aux zones d’arrivée de mettre des bobines, de sorte qu’une fois imprégné du champ de la capsule, un champs magnétique contraire se forme et par la même occasion, un courant électrique que tu récupères et stocke dans des batteries (ou supra condensateur)
Voir Courant de Foucault.
Par rapport à ta solution, ça évite de gérer des sas de (de)pressurisation dans les sections à grande vitesse du tube.



linkin623 a écrit :

Autant un train peut passer dans une gare, qui reste la voie principale, autant là, faut résonner comme un pipeline. Et on sait très bien faire ce genre de chose. Des tubes secondaires, des tubes tertiaires et tu peux sortir des voitures/wagon de la ligne principale sans ralentir tout le monde.
Ne pas oublier que les pipelines de pétrole ne transportent pas toujours que du pétrole!


Je suis d’accord, on ne monte/descend pas directement sur le tube principal. Comme pour les autoroutes.

Sauf que la complexité ici tient à la résistance et à la performance des systèmes d’aiguillages (à définir). Et quel sera l’infrastructure qui représentera un aiguillage.

Le 12/05/2016 à 14h 32

sentryman a écrit :

C’est bien beau de lancer plein de trucs qui ont l’air révolutionnaires, mais sans renta c’est voué à l’échec



Le principe de la recherche est d’étudier des concepts et analyser leur viabilité.

Tout comme maglev, ITER, les concept-cars, concorde etc…

En ce sens, rien de déconnant avec Hyperloop. C’est même très bien.

Le problème est de déjà annoncer que ce sera moins cher que les lignes à grandes vitesses classiques.

Pire, faire du crowfunding. L’engouement fait que des gens investissent, sur l’idée que ça marchera.
En gros, contrairement à la recherche étatique (dettes, impots xD), ou industrielle (budget fournit par une autre activité), ils exposent la populace.
Rien de méchant à la base, mais l’engouement aveugle l’appréciation du risque.

Le 12/05/2016 à 14h 11

Il n’y a pas que la dilatation/rétraction thermique. Il y a aussi l’exposition aux vents.

Les virages ne pourront se faire qu’avec de très grand rayon (à préciser), et par virage il faut aussi comprendre les dénivelés.

Ainsi, d’une part, les traversés style viaduc de millau seront bien exposés.

D’autre part, avec cette contrainte de grand rayon, pour tracer un itinéraire, ça fait pas mal de poteau de tailles différentes à mettre en place (ou des tunnels à percer)

Le 13/05/2016 à 13h 48

Lol,

Quand on paye la SACEM, on doit payer la SPRE. Hors ce diagramme montre que la SACEM reverse au SPRE.

Ceux qui payent SACEM ET SPRE peuvent porter plainte? Class action?

Le 20/01/2016 à 11h 56

Si c’est pour dépanner pourquoi pas.

Si c’est pour empêcher les gens d’être plus consciencieux, bon gestionnaire… bof

Si c’est pour faire de la vente forcée (le lavelinge ne commande que du ariel alors que tu ne voulais que de la lessive lidl…), bof

Il n’y aura même plus besoin de pub, on nous vendra automatiquement tel produit.

Le 06/01/2016 à 09h 32

Le WD Red 4To était à 70€ ?? (prix normal au moins le double)
Normal que ce soit rupture de stock.

Le 10/12/2015 à 16h 58

van25fr a écrit :

 
Ok mais si on n’a pas de Smartphone (le truc qui me sert à rien) comment on fait ?


Ben tu viens de trouver une utilité  :)

Le 12/11/2015 à 10h 40

Ce que je voulais dire, c’est que si on faire quelque chose du style IE sur windows, on s’ajoute de la complexité que ce soit pour les dev (si on rends le playstore non obligatoire), ou les constructeurs (si on scinde playstore et googles services)

Je n’ai rien contre le respect des règles de concurrences etc..

Tant qu’à faire, ils pourraient penser à IOS avec imessage & co aussi…

Le 12/11/2015 à 10h 05

flagos_ a écrit :

L’obligation d’installer Google Maps, elle vient en tant que package du Play Store.

Si tu veux le Play Store, faut signer un contrat avec Google, et du coup il te faut les Play Services… qui repose sur Chrome et Google Maps car il les utilise. Le contrat stipule alors qu’il faut alors obligatoirement installer tous les logiciels Google (hangout, chrome, gmail, maps…) et qu’ils soient sur l’ecran d’accueil. Et c’est ce contrat qui est sous l’oeil de Bruxelles.

L’OHA elle n’a rien a voir avec ca, elle définit juste l’OS de base.


Faudrait développer des markets alternatifs? (bon ça existe déjà). Que chaque constructeur ait son market?

Je suis Mme Michu, comment je sais si les applis sur le market du constructeur sont sûres?

Je suis développeur, si je veux publier mon app, combien de fois je dois me faire * pour avoir une visibilité sur les stores? ==> install hors market

Je suis constructeur : déjà que je me fais par l’ami G pour utiliser Android, combien de fois je dois me faire *, pardon, combien de partenariat je dois signer pour proposer un panel de services. Et combien je dois payer pour maintenir un truc pareil (c’est sûr que tous ont les sous ou la marge de Google/Samsung/Apple…) Et vu les cycles de MAJ des constructeurs….

Le 12/11/2015 à 09h 55

Pensez à Windows et internet explorer.

On va finir par se retrouver avec android 7 qui va te demander, au premier démarrage, de choisir le client mail, l’application de localisation, de gestionnaire de contact, de calendrier, de streaming de musiques, de vidéos, de news, de météo, d’appels, de messagerie instantanée…. Oh wait, le marketplace aussi…

On va finir par avoir le choix de l’OS quand on prends un téléphone. Ou comme pour les pc, qu’ils vendent des téléphones freeOS. A M et Mme Michu de DL un OS compatible (imaginez les contraintes) de se taper les manipulations de bootloader et cie (simple mais bon, quand même)

Edit : grilled 

Le 30/01/2015 à 16h 30

Fuinril a écrit :

Si vraiment il y avait des restrictions géographiques, pourquoi Ubisoft a validé la clé des utilisateurs ne se connectant pas de, disons Russie ? Encore une fois si Ubisoft avait refusé les clés à la validation il n’y aurait même as eu besoin d’en parler. 


Bonne question, aucune idée. 
Autant la restriction géographique (par IP, DNS, FAI etc ) me semble OK pour la vente, autant vérifier que le compte dans lequel la clé est ajoutée est dans le bon pays me semble limite côté protection vie privée. C’est un croisement du fichier des clés au fichier des comptes.
Après, dans la théorie commerciale, ce sont des utilisateurs finaux qui achètent les clés sur le store, soumis aux restrictions d’accès mentionnés, et qui ont coché le “j’atteste sur l’honneur habiter dans le pays déclaré”…
 
 


Fuinril a écrit :

Qu’on se comprenne bien, je n’aurai pas été choqué d’apprendre que ces clés n’avaient pas fonctionné, mais à partir du moment ou Ubi valide la clé (qu’elle soit ou non pré-activée pour l’utilisateur c’est une validation de son achat par l’éditeur) ils s’engagent à fournir un service. C’est la contrepartie des activations de clés en ligne (on nous vend que c’est pour la sécurité, c’est le moment de le prouver).

 
Le problème est qu’entre le moment où la clé est acheté frauduleusement chez Origin, et la validation de la clé dans le compte utilisateur, très peu de temps peu se passer grâce à la liquidité d’internet, même si ça passe par 5 intermédiaires.
Par contre, le fait qu’Origin découvre que les CB utilisées pour le payer étaient volées a pu prendre du temps (le temps que les victimes s’en rendent compte du vol, s’ils sont encore en vie, délais des transactions etc). Ca peut dépasser les 7 jours légaux français. Ce n’est pas comme si chacun scrute son relevé en ligne tous les jours (le vol des chiffres suffit)
D’autre part, pour Ubi, son client c’est Origin, il a donc obligation de service envers Origin seulement. Et c’est Origin lui-même qui lui demande d’invalider des clés suite à la fraude.
Pour Origin, pas de paiement, donc pas d’obligation de service, donc ban des clés. Ubi réponds tout simplement.
Pour le particulier, l’obligation de service doit être garanti par son revendeur. Celui-ci doit remonter à son fournisseur et ainsi de suite.
 

Fuinril a écrit :

 Libre circulation des biens, marché unique, tout ça. Je m’en contre fou

si c'est interdit au niveau des CGV, au niveau européen on se torche       

avec car tout est régit par le code de la conso. Et le code de la conso stipule qu'on a le droit de revendre des licences logicielles, tiens si tu as raté ça :http://www.nextinpact.com/archive/72159-cjue-autorise-revente-licences-logiciels... 

 
OK. Retenons que la fraude à la CB alors.
Après, que certains soupçonnent qu’Ubi ban en raison de revente, c’est une autre histoire. Mais ce n’est pas ce qui est rapporté dans l’article.
Ubi pourrrait noyer les clés revendues parmis les clés frauduleuses, dans ce cas, qu’Origin publie les clés incriminées.
 


Fuinril a écrit :

Pour résumer un peu, ce n’est pas que les clés aient été invalidées qui me choque, c’est qu’elles l’ont été après validation initiale (pour le client), que la seule victime de l’histoire est le client qui lui n’y est pour rien (puisque même Ubi a récupéré ses billes) et qui n’a plus aucun recours car l’achat est trop vieux, et le tout sur la base d’une décision unilatérale.


Origin n’a pas touché l’argent de la vente de ses clés. Il est la première victime.
Le fruit du vol, c’est l’escroc qui l’a, et qui le revends à des revendeurs qui ne procèdent pas à la vérification de la légalité de ce qui leur est fournit.
Le revendeur vend les clés aux particuliers.
Les particuliers sont les secondes victimes.
 
L’argent du crime est dans les poches de l’escroc, intouchable (autre pays, autre législation, introuvable).


Il y a 2 affaires dans cette histoire, il faut rappeler.
 
Pourquoi UBi devrait gracieusement laisser ces clés actives. Même si en pratique, changer des entrées en BDD n’est matériellement pas cher, cela ne ferait qu’encourager l’escroquerie.
Origin y a déjà laissé des plumes normalement, elle devrait encore fournit gracieusement des clés aux autres victimes? victime+ encourage l’escroquerie. 

L’escroc a tiré parti, il va continuer quoi qu’il arrive.
  
Le revendeur est le fautif, car en omettant la vérification de la légalité de la marchandise qu’il a reçu (que la clé soit valide ne suffit pas). Il a brisé la chaine de confiance.
 
Pour les particuliers,  je ne vois pas où est la faute pour Ubi. L’argument validé/invalidé n’est pour moi pas recevable. Dans tout contrat commercial, si le paiement fait défaut, l’accord est rompu même s’il a été entamé (la justice ne fera que confirmer cela). Il peuvent réclamer à Origin s’ils lui avaient acheté les clés incriminés (la facture faisait foi). Sauf que là, ce n’est pas Origin ni Ubi qui ont fait la facture. Le seul recours c’est le revendeur. Mais entre le revendeur et Origin, il y a un problème.

Le 30/01/2015 à 10h 55

slave1802 a écrit :

Pour la justification de coupure de service, c’est certain légal mais moralement… 
Ubisoft n’a pas vendu une licence : c’est un manque à gagner, mais pas un cent n’est sorti de leur caisse 
Le client a acheté une licence qu’il pensait légale et ne peut l’utiliser : C’est une perte nette. L’argent est parti, le service aussi. Le client peut effectivement se retourner contre le vendeur indélicat, mais vu le tarif des avocats, le jeux n’en vaut pas la chandelle si on peut dire… 
Tout ce qu’Ubisoft a à gagner la dedans c’est un manque à gagner encore plus important par la suite, les clients qui se sont fait blacklister par eux ne sont pas près de revenir… 

Pour en revenir aux comparaison automobile: J’achète une Renault auprès d’un vendeur véreux sans le savoir. Il y a un problème sur cette voiture, casse d’un élément moteur. Je vais chez Renault qui me refuse la prise sous garantie parce qu’elle a été acheté dans un réseau parallèle, ils seront sans doute dans leur bon droit mais ma prochaine voiture sera certainement pas une Renault…


Ubi a vendu des licences à Origin, et lui permet de les revendre.
Origin les as vendu mais à eu un manque à gagner en raison des CB volés.
Origin reporte les clés problématiques à Ubi, qui les bans. Les dessous entre Ubi et Ori nous sont inconnu (accord commercial).

Samsung vends des Télé à Darty pour qu’il les revende.
Darty vends ces télés. Un “client” arrive à frauder et vole de fait la télé (CB volé, faux documents, chèque en bois..).
Darty remonte à Samsung le n° de série de la télé déclarée volée.
Ce “client” revends la télé boite non ouverte à un particulier qui pense faire une affaire (broker, leboncoin etc).
La télé tombe en panne. Le particulier veut utiliser la garantie constructeur. (le broker n’a pas de service après vente, par annonce, pas mieux…)
 La facture du “broker” n’est pas reconnue (non conforme car la tracabilité de la télé ne peut être établie) et le n° de série de la télé est reconnue comme étant volée 
===> refus d’appliquer la garantie constructeur + signalement article volé aux autorités
Alternative: pas d’application de la garantie constructeur, le particulier paie plein pot les réparations.


Pour revenir à ton exemple sur la renault, ce n’est pas renault que je “punirais” mais le vendeur qui m’a vendu la voiture. Pas de la faute de Renault si la voiture a été volée. Ni de sa faute si un vendeur l’a revendue. Ni de sa faute si tu l’as acheté. Tu voudrais que Renault prenne ta voiture volée sous la garantie constructeur, garantie payée par l’acheteur légitime. En gros, profiter du service qu’un autre a payé. Et punir Renault parce qu’il ne te permet pas de profiter de ce qu’a payé l’acheteur légitime? L’argent que tu as sorti n’est pas arrivé dans les poches ni de Renault, ni de l’acheteur légitime mais dans celles du vendeur véreux.

Le 29/01/2015 à 22h 46

Fuinril a écrit :

On peut dès lors se poser la question de la responsabilité du fournisseur de vendre des produits à des compagnies n’appliquant pas la même législation financière. Qui est responsable ? Et qui a le droit de punir qui ? (non si on ne paye pas un maçon il n’a pas le droit de venir démolir la maison parce que ça l’a énervé…). D’autant que dans la chaine, le groupe propriétaire du fournisseur initial et le “punisseur” est français…
Ca complique fortement le problème… et ça légitime presque le zonage que j’ai toujours eu en horreur…

Disons pour faire simple j’ai un problème : nous sommes dans une situation où le fournisseur (Ubi) a vendu des produits a un autre fournisseur (EA) de manière tout à fait légal.
 Ce dernier a lui même vendu ces produits a un autre fournisseur mais avec des CB volées (et peut être qu’il ne savait pas lui même que les CB étaient volées, je ne connais pas la méthode d’appro de ces sites - je doute qu’ils achètent chaque clé une par une, ils doivent avoir des fournisseurs).
 Enfin le client final achète de manière légal la clé.

Pourquoi est-ce que c’est le client final qui doit être lésé dans cette histoire ? Et surtout puni directement et sans décision de justice par le fournisseur initial alors que ce n’est pas le fautif de la chaine ? Surtout après que le fournisseur du service, se trouvant par un heureux hasard être aussi le fournisseur initial du produit, ait validé le produit comme étant conforme et donné accès au service… 


Paragraphe 1:
Le problème n’est pas de vendre des produits à des compagnies n’appliquant pas la même législation financière. Le problème est juste que des compagnies ne respectent pas la législation financière de leur fournisseur. Ici le fournisseur (Origin) s’attends à vendre à des utilisateurs finaux dans le pays concerné (par exemple, Roumanie). Une entité étrangère (choississez votre pays), via VPN/proxy etc…, bypasse les restrictions d’accès géocalisées (comme ceux qui achètent leurs clés sur Steam RU ou qui accèdent à Netflix US…) et achète des clés pour les revendre.
Non respect de la localisation de l’acheteur, non respect de la non revente des clés, et en plus transaction frauduleuse par CB volés.

 
Correction:
Le fournisseur (Ubi) a vendu des produits à un revendeur agréé (EA) de manière tout à fait légal.
Ce dernier ne peut et s’attends à les revendre à des utilisateurs finaux uniquement. Or une compagnie étrangère (le revendeur), via la boutique en ligne, achète ces produits comme le ferait un utilisateur final normal. Sauf que non seulement, il utilise des CB volés (transaction frauduleuse) mais en plus, les revends, en totale violation des CGV et CGU.
Pour EA, le revendeur, considéré comme étant utilisateur final, est en violation délibéré des CGV et CGU, donc 
 ban des clés vendues.

Ceux que tu appelles client finaux ne le sont pas juridiquement. Ce sont des victimes secondaires (cf mon précédent commentaire)

Le 29/01/2015 à 22h 22

IMPulsion a écrit :

Moi, il y a tout de même un point qui me chagrine ! De quel droit révoquent-ils des clés. Tout le monde ici se bat à coup de ‘il on bien fait’ où ‘ce sont des pourris’, mais personne ne s’inquiète qu’il fassent justice eux même. Qui sont ils pour juger de la légalité ou de l’illégalité d’un achat ? Nous avons des lois, et des juges pour les appliquer. Et ce ne sont pas à ces sociétés de décider de retirer un bien à quelqu’un qui l’a pourtant acheté. Plus haut, il à été pris l’exemple (mauvais) de l’auto. Et si vous achetez une voiture volée, pensez (aimeriez) vous que ce soit le constructeur automobile qui vienne, sans décision de justice, vous retirer votre bien au prétexte invérifiable que ce que vous avez acheté n’a pas été obtenu de manière légale par le vendeur ?

Non, je ne pense pas !     

Il serait peut être temps de faire cesser ces méthodes de mafieux !


Dans le cas du vol de voiture, ce n’est pas le constructeur qui vient reprendre la voiture mais la justice justement (suite au dépot de plainte) qui saisit le véhicule puis le rend au propriétaire légitime. Le racheteur l’a dans le c.

 Dans le cas ici, quand les clés sont achetés sur Origin:
-avec des CB volés ==> transaction frauduleuse donc demande de ban des clés. La justice va simplement confirmer, en raison de la transaction frauduleuse, le ban des clés.
-revente des clés  ==> violation des CGU donc demande de ban des clés. La justice va aussi valider le ban, tout simplement parce que la transaction est litigieuse (visiblement, le revendeur/acheteur n’est pas dans le pays qu’il déclare être mais en plus, non agrée par Ubi ou Origin, n’est pas autorisé à revendre ces clés L’achat sur Steam, Uplay, Origin est toujours à destination d’utilisateur finaux (même par cadeaux).

Un achat est un accord commercial bipartite, avec accord tacite des CGV et CGU. En cas de non respect,  l’accord commercial est rompu et les sanctions s’appliquent comme stipulé dans ces mêmes CG.

Peu importe tout ce qui se passe après (comprendre la revente des clés à des acheteurs pensant acheter via un moyen légal) , la fraude est déjà faite. Les acheteurs sont des victimes secondaires.


Le revendeur n’est pas clean à la base, c’est tout.



 

Le 29/01/2015 à 17h 49

Je pensais plus aux vendeurs boites (Micromania, gameshop, grandes surfaces) (et donc physique).

 Si on suit cette logique, on n’aurait plus de vente physiques. Parce qu’entre la vente dématérialisé à 15€ et la vente physique à 60€ (et encore ils sont en perte il me semble, merci de trouver une source, ils ont des magasins à louer, des salariés à payer, de la logistique etc)

Ce serait le lobby des vendeurs physiques qui gueuleraient. Tout comme le lobby des libraires qui gueule contre amazon et son 5% + frais de livraison gratos.

Que chacun y trouve son compte est une chose, mais déjà qu’on a 3 millions de chomeurs sur les bras, faudrait pas passer à 10.

Le 29/01/2015 à 17h 05

127.0.0.1 a écrit :

Il l’a déjà acheté (payé).


Se faire escroquer ne veut pas dire la même chose.

 

127.0.0.1 a écrit :

Et pourquoi ca ne serait pas Origin qui demande remboursement ?

 
Reboursement de quoi? Quelle transaction est fautive? De Origin à Ubi, ou du revendeur à Origin?
Origin est victime (pas de gain de sous). Le revendeur est un escroc. Les acheteurs du revendeur sont des victimes conséquentes.


 

127.0.0.1 a écrit :

Oui, bien sur, mais ca serait pareil avec n’importe quelle transaction, pas de rapport direct avec far cry et l’achat de jeux dématérialisés.


Pour faire jouer l’assurance, il faut prouver le caractère litigieux de la transaction  du joueur au revendeur. Porter plainte, attendre la décision de justice. Pour un revendeur à l’étranger sans accord juridique? Aucun espoir. OMC? Pour quelques € et le temps que ça va prendre.


Je rappelle, quand vous faites un achat en France, ce n’est pas seulement un bien/service contre paiement uniquement. Il y a un cadre juridique derrière, une législation et des instances juridiques compétentes pour traiter les litiges.
Mais pour que ce soit valable, toute personne ou organisation exerçant une activité commerciale quelqu’elle soit (vente, service, prestation…) doit être enregistrée au RC (raison sociale, SIRET).

Vous faites un achat à l’étranger, dans un pays qui n’a pas d’accord commercial ni juridique == vous perdez cette “protection”.
Seul l’honnêté et le bon vouloir du vendeur est applicable.

A partir du moment où celui-ci vous escroc déjà (ou est déjà malhonnête…)

Le 29/01/2015 à 16h 43

Citan666 a écrit :

Et pourquoi la mondialisation ne profiterait qu’aux mêmes ? Les éditeurs proposent des prix variables du simple au quintuple selon les pays, pour LA MÊME OEUVRE, et pour des coûts globalement similaires d’adaption et de distribution. Dès lors que les usagers sont conscients de ça, ils n’ont aucune raison de douter à priori d’un tarif inférieur de 50%. Surtout que même les versions boîtes en précommande se trouvent souvent moins cher sur internet que les versions dématérialisées chez l’éditeur. Ce qui souligne la diversité des offres accessibles à celui qui s’informe sur les prix. 


Faut pas confondre mondialisation et adaptation à l’économie locale d’un pays.

Rien à blamer si un pays (reprenons l’exemple de la Roumanie) a une économie beaucoup plus faible que la France. Si le salaire moyen est de 200-300€ et que le prix standard d’un jeu est de 10€ (par exemple), bien sûr que pour nous, c’est profitable (syndrome du partir en vacances dans un pays à l’économie moins forte).

Sauf que, d’une part, si les vendeurs FR devaient vendre à ce prix là, il feront tous faillite (ou plus de vente de jeux, en raison du loyer, des salaires etc au niveau FR).

D’autre part, avec ce raisonnement, il faut considérer l’économie globale (agriculture, industrie etc). Autrement dit, ramener l’économie française à l’économie roumaine. Tu paieras le même prix (content?), mais tu gagneras aussi le même salaire que la-bas (un vendeur fera moins de CA, devra donc payer moins ses salairiés, ses fournisseurs et ça continue en cascade)

La différence de prix vient donc de l’inégalité de niveau des économies (en occurence du pouvoir d’achat)

Comme dit dans un commentaire précédent (navré, trop loin pour quoter), dire “la-bas ils payent moins cher alros que nous on raque”  est une réaction égoiste, coupé des réalités locales du pays.

Le 29/01/2015 à 16h 02

eliumnick a écrit :

Non non, je parlais de revendre la boite tel quel sans même l’avoir ouverte.


Pour cet “instance” du jeu, non installé, donc CGU non accepté, donc pas de pb.

Le 29/01/2015 à 15h 45

Tu es juste en train d’escroquer ton acheteur. Lui pense acheter un jeu avec le droit d’y jouer. Sans la licence, il ne pourra pas (enfin légalement, il n’a pas le droit)

Escroquerie qui se double si tu lui fais payer la boîte + CD plus cher que le DVD gravé (sans la clé, cela revient exactement à ça).

Ce n’est pas le petit fascicule ni l’impression sur le CD ni la jaquette DVD qui justifieront le prix.

Le 13/03/2014 à 11h 32

Oui enfin:
-écran 3k mat?
-écran 3k sur un 15” ça change quelque chose par rapport au FHD?
-écran 3k sur un laptop gamer, si le gain est pas si élevé, je préfère que le GPU bosse sur la fluidité que de ramer pour les pixels en plus

Le 13/03/2014 à 11h 23

yAMiGoHaN a écrit :

Un GS60 ou GS70 avec une 870m ça peut le faire (pas trop loin d’une 780m mais dans des châssis bien plus fins. Reste à voir les températures (aïe) et les dB (aïe aïe aïe) !



Et le prix surtout.

Le 23/07/2013 à 09h 20

Sais pas, liste d’email valide pour envoyer du spam par exemple? arnaques, phising, virus etc….

Le 23/07/2013 à 09h 10

Worlak a écrit :

Vive Google.

Sur les faiblesses du DES (cracké la première fois en 1997) :
http://en.wikipedia.org/wiki/Data_Encryption_Standard

Sur le fait que l’EFF a recommandé depuis 1998 de passer au 3DES :
http://ecommerce.hostip.info/pages/288/Data-Encryption-Standard-DES.html


Sur le fait que Nohl ressort du placard ses propres infos datant de décembre 2011 (donc rien de neuf sous le soleil) :
http://www.mobilemag.com/2011/12/29/gsm-phones-vulnerable-to-hijacking-gsma-unconcerned/

Après, les docs de la GSMA n’étant pas publiques, je ne peux pas pointer dessus.
Mais bon, déjà on peut voir que le problème dénoncé aujourd’hui est loin d’être nouveau.



Que le DES soit weak aucun souci, mais je voulais la source pour dire que le GSMA était au courant depuis 10 ans (et même 2) comme tu le dis.

Après, faut lire l’anglais hein, la news PCI traite d’une vulnérabilité qui permettrait avec des sms forgés d’être traité/exécuté ou ce que tu veux, alors que la news que tu as linké traite du chiffrement weak des communication GSM de l’époque, ce qui autorisait l’écoute en live sur les ondes. Pas la même chose.

Le 23/07/2013 à 08h 13

Worlak a écrit :

C’est carrément une non-information …
Ca fait bien 10 ans que la GSMA est au courant que le DES est troué comme une passoire et qu’elle conseille aux opérateurs de ne plus l’utiliser, mais d’avoir au minimum 3DES (triple DES) ou mieux AES.



source? (que le GSMA est au courant)

Le 15/07/2013 à 15h 33

nucl3arsnake a écrit :

Oui et non, si je te dit de voté pour X en échange de thunes/mort, tu va dans l’isoloire tu est seul, rien ne prouvera que tu a coté pour X =)



Oui certes, mais par exemple, dans une ville, une milice pousse à voter pour X.
Résultat, Y gagne avec 80% (par exemple)
La milice peut prendre au pif n’importe qui par représailles.
Cette peur peut suffire….

Edit : peut/peur

Le 15/07/2013 à 15h 22

Ingénieur informaticien a écrit :

Je ne comprends pas ce qu’il y’a de compliqué à faire du vote électronique sécurisé alors qu’on sait faire des transactions par carte bancaire depuis longtemps …



Quid de vérifier l’authenticité du vote TOUT EN anonymisant le vote…



NEVdD a écrit :

il est impossible de vérifier que le code qui s’exécute est bien celui promis



D’accord



NEVdD a écrit :

et il est impossible de vérifier que le votant n’est pas soumis à une pression



valable pour n’importe quel vote



NEVdD a écrit :

seul un vote dans une salle contrôlée par des assesseurs sélectionnés aléatoirement dans la population d’électeurs peut être relativement fiable.



Eux aussi peuvent subir des pressions/menace une fois qu’ils ont été selectionnés.

Le 12/07/2013 à 09h 34

Khalev a écrit :

Niveau cohérence moi je suis plutôt avec toi. Mais on va dire que je suis juge et partie.



En effet. Malheureusement mais on ne trouvera plus personne dans les bas fonds des commentaires de cet article qui date de 3 jours (je ne parle même pas de celui de la semaine dernière)

On aurait dû faire ça dans un forum.

Le 11/07/2013 à 21h 00

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


Pour ce qui est de la cohérence, j’invite les lecteurs (voir l’auteur de l’article) de PCI qui ont eu le courage de suivre ce qui a été et dire leur avis… (voir les coms sur les 2 articles). Besoin d’un arbitrage.


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é.


Tiens, je n’ai jamais eu l’impression qu’en te corrigeant, j’ai paru anti android. C’est pourtant le contraire.
Ce serait bien si tu pouvais appuyer tes dires avec des sources fiables (comme nous nous l’avons fait). Autrement, tout ce que tu dis n’est que du vent.


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.


Nous n’avons jamais parlé de vérification de l’application par Google à part toi (tu parlais de MAJ hors ligne). La seule vérification dont nous avons parlé est la vérification de la signature de l’apk. L’obfuscation de code est donc hors sujet (mais intéressante je l’admet)


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é.


Je répète, personne n’a critiqué Android en lui même. Ce qui est critiqué est la fragmentation. Fragmentation qui lève le problème de savoir si la faille sera corrigée sur tous les téléphones. Aujoud’hui, oui google a mis en place un mécanisme pour vérifier les applications sur le playstore cf lien. Donc oui, les applis téléchargés depuis le playstore ne sont plus sujet à cette faille normalement. Mais la faille ne sera entièrement colmaté que si tous les téléphones soient patchés (mais ça n’arrivera pas)


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.


Ah bon, on a dit ça? Si tu commences à imaginer des choses…. Allez de plus en plus de HS.

Allez dernière chose, comme tu n’as toujours pas l’air de vouloir reconnaître la faille : ici

Donc ok, si Google vérifie en profondeur les applis avant publication, il n’y aurait pas de problème avec le playstore (comme ça tu es content). Sinon, le playstore est vulnérable vu qu’il ne suffit que de pirater un compte développeur (pas besoin de son keystore).
Sauf que jusqu’ici, j’ai toujours considéré que contrairement à Apple, Google ne le fait qu’après publication (si tu as une source fiable qui dit le contraire, je suis preneur, je ne trouve rien en ce sens, quand même dingue de devoir faire des recherches à ta place pour vérifier tes propos) Il y a certes l’antivirus qu’ils font tourner (Google Bouncer, seulement depuis Février 2012). Ca reste un détecteur à base de “signature” et visiblement, il ne détectait pas la faille.
Autrement, je ne trouve rien.
Mais bon, le playstore a du être patché je te rappelle.

Le 11/07/2013 à 13h 30

(parenthèse débat)

Tu mélanges encore 2 concepts : fiabilité et confiance.

Fiabilité : application vérolé ou pas.

Confiance : crédit accordé par l’utilisateur à l’application qu’il installe lui-même, qu’il soit fiable ou non.

Petite analogie :
Un site web publie un mensonge.
Un lecteur, reconnaît ce site comme de confiance et indûment fiable, reconnaît le mensonge comme vérité.
Le site publie une extension du mensonge.
Le lecteur, par confiance au site et au mensonge, reconnaît le nouveau mensonge comme vérité.

Retour à android:
J’installe et donc je fais confiance à l’application Gmail édité par Google Inc et, ayant une signature valide, est authentifié comme venant de Google Inc. (je n’ai jamais vu le certificat avant, je l’accepte). (remarque qu’on s’en fout de comment j’installe l’application) Implicitement donc, j’accepte l’application comme fiable.
(en réalité, elle peut être non fiable, ….mauvais exemple, bon en fait on ne devrait pas, PRISM xD… bref c’est juste pour l’exemple).

Pour quelle raison ne ferais-je pas confiance à la mise à jour de l’application Gmail édité par Google Inc. , même nom de package, même certificat et signature valide (et donc authentifié)? Parce que je ne fais plus confiance à ce que j’ai fait confiance et considéré comme fiable avant et utilisé? Superbe logique… Parce que j’ai accepté une MAJ que j’ai autorisé par confiance? Retour en haut. Parce qu’une appli malveillante a modifié l’appli de base? Le téléphone est déjà corrompu, ça ne changera rien. Corrompu + corrompu = corrompu. Et l’utilisateurs ne sait pas qu’il est déjà corrompu. A moins d’être paranoïaque… 99% des téléphones android?

Malheureusement, il faut se mettre du côté du téléphone et de l’utilisateur. A part de l’inconscience, je doute de la santé mentale d’un tel utilisateur qui ne ferait pas confiance en ses propres données (sauf paranoïaque)

Ce n’est pas grave, j’ajoute ça à:
mélange hash / signature
mélange validation / authentification

(fin parenthèse débat)

Glubglub a écrit :

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…



Avis personnel : Oui enfin, pour ce qui est du trash et des failles béantes, on est habitué avec Microsoft. Le souci, relevé par tout le monde, n’est pas tant qu’avec la faille béante (que tu n’as toujours pas reconnu dans ton post, navré mais après tout ça…), mais avec la fragmentation android et le non support des anciennes versions, des anciens téléphones, il n’est pas assuré que tout le monde reçoive sa mise à jour de correction.



Glubglub a écrit :

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.


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



Glubglub a écrit :

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.



Il est normal d’informer les gens quand on détecte une faille. (d’où BlueBox communique) Ca ne veut pas dire que l’on “crie” à l’insécurité. A l’origine, on voulait juste déterminer quelle était cette faille. Puis nous sommes parti depuis la semaine dernière dans notre bazar.

Au passage, pour ceux qui ont du bien rigolé….

Le 11/07/2013 à 10h 59

Glubglub a écrit :

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. [
  
  
  
  
  
  Glubglub 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.
  
  
  La seule personne qui peut accéder a tes applis en théorie n’est que l’utilisateur via l’OS ok? (et google pour virer des app interdits).
  Comment tu modifies tes apps?
  Soit MAJ (le cas de notre article)
  Soit une appli malveillante ou un hacker logué sur ton téléphone. Autrement dit, le téléphone est déjà corrompu. Pas la peine de MAJ après.
  Tu es quand même bon dans la mauvaise foi.
  
  Je résume les 2 articles
  
  Moi (et les autres) : Une faille touche 99% des android dans le monde. On cherchait juste à savoir ce que c’était.
  cf mon dernier link (sur le MasterKey, ce serait une histoire de dupliquer des fichier dans un apk, à la vérification de la signature, le fichier d’origine est checké lors de la signature, mais c’est le fichier dupliqué/vérolé qui est installé). Alors vérification ou pas vérification, playstore ou pas playstore, google ou pas google (et fait les mix que tu veux), ça passe tout de même. Difficile à comprendre?
  
  Toi : “Ce n’est pas une faille tant qu’on reste sur Google Play (ou Amazon Store…). ” = l’installation via sources inconnues est faillible. En soit, ce n’est pas une faille, vu que c’est documenté et connu depuis le début.
  
  En gros tu es hors sujet depuis le début.
  
  
  
  
  Glubglub a écrit :
  
  Toi : C’est un système de merde, Google Play ne fait aucune vérification.
  
  
  
  Merci de ne pas déformer mes propos. J’ai dit cela dans un cas précis de conditions à vérifier.
  D’ailleurs, avec tes histoires de MAJ hors ligne, sans vérification, c’est plutôt TA position.
  
  
  
  Glubglub a écrit :
  
  Moi : Android est concu pour fonctionner sans Google, Google ne peut valider une installation externe à Google Play.
  
  
  Oui c’est le principe d’Android. Mais Google ou pas google, playstore ou pas playstore, tu peux vérifier la signature de l’APK POUR vérifier l’AUTHENTICITE. Tu mélanges ! Il n’importe seulement que la MAJ que tu installe provient du même éditeur. Après, pour ce qui est du contenu de l’application ou de la MAJ, c’est a tes risques et périls (même sur le playstore vu que google ne fait qu’une vérification à posteriori)
  
  
  
  Glubglub a écrit :
  
  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.
  
  
  Rebelote, tu mélanges. C’est l’authenticité qu’on vérifie. Tu as fait confiance à un éditeur en installant son application. En partant de là, si tu a la preuve que la MAJ vient de lui (exactement le même certificat et signature vérifiée), tu peux, basé sur la confiance que tu lui as précédemment accordé, installer la MAJ,Google ou pas google, playstore ou pas playstore. Après, que cette MAJ soit sécurisé est une autre histoire. (par exemple, demande de droit des MAJ Facebook)
  Pour la fiabilité des données de la SD, je t’ai déjà répondu.
  
  
  
  Glubglub a écrit :
  
  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.
  
  
  Rebelote, tu mélanges.
  “Rien n’est fiable sur la carte SD ” : C’est plutot TA position. En soit, je suis aussi d’accord. Dans le cas qui nous concerne ici, je t’ai déjà répondu.
  C’est quoi que tu appelles validation? Aucun sens ici. Aucune notion de validation par google dans le problème. Les utilisateurs peuvent installer des app hors playstore. cf résumé article.
  Mais la faille peut aussi s’appliquer sur une appli téléchargée sur le playstore.
  
  
  
  Glubglub a écrit :
  
  Merci ! Enfin !
  On peut enfin clore le débat ? Je crois que l’on est d’accord.
  
  
  
  J’espère bien en avoir fini
  
  
  
  Edit : pour un souci de quote
  

Le 11/07/2013 à 09h 10

Glubglub a écrit :

• 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).
  
  
  
  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.
  
  
  
  Glubglub a écrit :
  
  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 !
  
  
  
  http://developer.android.com/tools/publishing/publishing_overview.html#publishing-release
  
  Android protects users from inadvertent download and install of apps from locations other than Google Play (which is trusted). It blocks such installs until the user opts-in Unknown sources in Settings > Security, shown in Figure 2. To allow the installation of applications from other sources, users need to enable the Unknown sources setting on their devices, and they need to make this configuration change before they download your application to their devices.
  
  
  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é :
  
  
  Cékagé a écrit :
  
  L’équipe BlueBox derrière cet exploit a publié un outil pour tester la faille sur son terminal :https://play.google.com/store/apps/details?id=com.bluebox.labs.onerootscanner (Prenez quelques minutes pour regarder la structure de l’apk " />)
  
  En ce qui concerne le scan de vos applications, l’application se propose de trouver les apk compromises avec MasterKey. J’étais sceptique et sur 3 apk perso corrompues différemment, aucune n’a été détectée.
  
  
  
  Voir https://plus.google.com/113331808607528811927/posts/GxDA6111vYy A confirmer mais l’auteur l’a déduit du bug report sur CM.

Le 10/07/2013 à 19h 51

Glubglub a écrit :

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 ?



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.

Le 10/07/2013 à 16h 12

Glubglub a écrit :

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).



Et on ta déjà dit d’aller réviser tes cours sur le chiffrement asymétrique.


Pour faire simple :

Le premier jour, tu installes une application. Tu acceptes et reconnait donc un DOUBLET (nom package, éditeur) en réalité (nom package, certificat) car le nom de l’éditeur se trouve DANS le certificat.

Une particularité d’un certificat : il contient une clé publique, lié par une relation cryptographique (en fait mathématique à ce jour inviolée) à une clé privée (secrète, que personne ne peut deviner), celle qui a servi à signer l’application.

Autre particularité d’un certificat : il est signé. Qu’il soit autosigné ou par une autorité de certification (AC), la signature lie le nom de l’éditeur à la clé publique. (EDIT : et donc indirectement, la signature lie le nom de l’éditeur à sa clé privée)

Encore une autre : on dit qu’un certificat est valide si, entre autres critères, la signature valide les information du certificat. (après on a les considérations de date de validité, de CRL etc). Dans le cas d’un certificat autosigné, il s’agit de la même clé publique mentionné. Dans le cas d’une signature d’une AC, le certificat de l’AC doit être fournit. Tu reconnaît implicitement cet AC comme valide et de CONFIANCE.

Une clé publique ne correspond qu’à une seule clé privée.

Le jour d’après, tu as une MAJ, la vérification va se passer comme ça:

• vérification du nom du package (facile, tu vérifie qu’il s’agit du même nom)
  


• verification du certificat (tu vérifie notamment que le nom de l’éditeur ET la clé publique sont les mêmes et que le certificat est VALIDE
  


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

Le 10/07/2013 à 15h 26

Glubglub a écrit :

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.



Oui, ce que tu appelles hash est la signature.
Si tu fais une MAJ, en resignant, la siganture change et c’est normal. Mais Google peut vérifier cette signature car le certificat développeur est aussi packagé dans l’apk (cf cryptographie asymétrique).

L’interêt de le tester : justement vérifier que la MAJ founie provient bien du même éditeur. Se limiter au login/mdp est léger tout de même.
D’une part tu vérifies le nom du package et le certificat pour vérifier qu’il s’agit bien de la même appli (identification)
D’autre part, tu vérifies la signature pour confirmer qu’il provient du même développeur (authentification). Avec le login/mot de passe, cela donne au final une sorte d’authentification en 2 étapes.

Enfin ça c’est tel que je le conçoit et ça ne reste qu’un “Google peut”. Après, ta position est que google ne fait pas cette vérification de signature. Et ça, hormis ton experience personnel, aucun des 3 articles (les 2 de pcinpacts, le blog de bluebox), ne le confirme.


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.

Le 10/07/2013 à 14h 40

Bon excuse-moi rappelle-moi du problème alors. (c’est partit dans tous les sens)

Je suis resté à : on peut modifier un apk sans qu’il soit nécessaire de recalculer la signature. De ce fait, on peut faire passer un apk vérolé comme une MAJ et la faire installer sans que le téléphone soulève un problème.

Le 10/07/2013 à 14h 13

Khalev a écrit :

Le truc c’est que dans l’article, et sur le post du blog de BlueBox ils parlent d’Android qui ne fait pas la vérif, donc le téléphone lui-même.
Pour le store vu que c’est Google aussi au mieux on peut penser qu’ils vérifient la signature aussi, mais il y a de fortes chance que se soit fait de la même manière que sous Android (mais dans ce cas google a déjà dû corriger le truc) ou alors ils ne font pas la vérif se disant que la vérif sera faites par le téléphone, mais ça me paraît un peu gros de laisser proposer des mise à jour sans savoir si elles seront validées par les téléphones, et dangereux pour les “primo-installants”.



On en revient au problème de la fragmentation. Si j’étais google, face à la multitude de rom constructeur, de rom opérateur et de rom alternates, je n’aurais aucune certitude que la vérification sera systématiquement faite. Pour assurer l’écosystème Android, il me semble alors normal de vérifier la signature des appli sur le store officiel (après pour les stores secondaires, à vos risques et périls)


La faille décrite est importante. Elle réside dans la manière dont les applications Android sont d’abord vérifiées, puis installées. Chacune est accompagnée d’une clé de chiffrement qui permet de vérifier l’intégrité des données. La brèche permet justement de pouvoir modifier le contenu d’application sans que cette clé soit affectée. En clair, même si une application authentique était modifiée pour devenir frelatée, Android ne verrait plus la différence.



All Android applications contain cryptographic signatures, which Android uses to determine if the app is legitimate and to verify that the app hasn’t been tampered with or modified. This vulnerability makes it possible to change an application’s code without affecting the cryptographic signature of the application – essentially allowing a malicious author to trick Android into believing the app is unchanged even if it has been.


Je ne vois null part où c’est marqué que la vérification n’est pas faite.

Le 10/07/2013 à 13h 51

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

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.
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.


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