Récemment, Mozilla travaille sur les location services, un service geolocalisation à partir du wifi ou du réseau cellulaire, qui a vocation a être intégré dans Firefox/Firefox OS. C’est un service très utile, à un détail près: il est propriétaire.
Les principaux écosystèmes mobiles ont un service de geolocalisation à partir du wifi: c’est très rapide, et pratique quand on a pas de GPS sur sa tablette. C’est aujourd’hui une fonctionnalité incontournable pour un smartphone. Le principe est simple: on envoie la liste des points d’accès wifi qu’on voit et leur puissance à un serveur, qui va ensuite nous renvoyer notre position. Les mobiles qui demandent ces données participent aussi à les remonter une fois le GPS verrouillé: c’est du donnant-donnant.
Mais il peut y avoir des dérives; on se souviendra d’Apple qui stocke l’historique des positions sur les iPhones, des inquiétudes autour de la collecte de Microsoft, ou de celle des Google cars qui enregistraient tout ce qui passait en wifi; ou encore des pratiques anti-concurentielles de Google visant à empécher que Motorola et Samsung utilisent un service de geolocalisation concurrent.
Mozilla a récemment sortie en version 1.0 Mozilla Stumbler, une appli Android qui permet à l’organisation de bâtir son propre service de geolocalisation: les participants volontaires installant l’application uploadent régulièrement les données des points d’accès wifi alentours associés à leur position GPS. Un système de classement ajoute un aspect gamification et compétition entre les plus gros contributeurs.
L’application est libre et même dispo sur f-droid pour les plus puristes d’entres nous. Seulement la base de données n’est pas libre.
On peut accéder aux données de localisation via l’API en demandant des clefs au responsable. On peut même télécharger la base de données des stations cellulaires. Mais impossible de récupérer la base contribuée volontairement pour monter son propre service concurrent.
Et ce n’est pas sans raison. En effet, les implications au niveau de la vie privée sont assez larges, et les plus exposés sont justement les contributeurs dont on peut déduire leur habitation, l’adresse mac du téléphone-qui-partage-sa-connexion, qui permettront ensuite de les tracker en recroisant des informations.
Ce dilemme n’est pas sans laisser un goût amer; alors qu’on aurait pu espérer un service analogue à OSM, on a clone de Google Maps pour la localisation. Le service est fourni par une organisation plus amicale, mais peut s’arrêter du jour au lendemain, et toutes ses données s’évaporeront laissant la communauté reconstruire la base de zéro. Mais ouvrir la base, c’est exposer la vie privée de tout le monde (utilisateur ou pas) à une exploitation non contrôlée.
Pensez-vous que Mozilla fait le bon choix ?
# sur android
Posté par jeekajoo (site web personnel) . Évalué à 6.
pour utiliser la base
Mozilla Location Servicessurandroidde manière transparente (en remplacement deGoogle Location Service), utilisezNetwork Locationdu projetNOGAPPS: http://forum.xda-developers.com/showthread.php?t=1715375# Dérive d'Apple
Posté par flan (site web personnel) . Évalué à -1.
La dérive d'Apple est quand même limitée, les données ne quittent pas le téléphone (enfin, je devrais parler au passé vu qu'elles ne sont plus du tout stockées à ma connaissance). Sauf si tu sauvegardes l'intégralité du téléphone, auquel cas elles sont aussi sauvegardées sur ton ordi (et c'est là l'origine du scandale : tu peux accéder à des approximations des lieux que tu as visités, en plus d'avoir accès à toutes les données de ton téléphone).
[^] # Re: Dérive d'Apple
Posté par groumly . Évalué à 3.
Ya toujours un historique , limité aux 4-5 endroits les plus souvent frequente, sur le telephone. Tu peux le desactiver, evidemment.
Les sauvegardes itunes peuvent (et c'est meme recommende), etre chiffree, ce qui limite bequcoup la surface d'attaque. C'est pas le cas par defaut, cela dit, avec icloud, ca devient rare de voir des gens faire des backups via iunes.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: Dérive d'Apple
Posté par Kerro . Évalué à 2.
Pour savoir quels sont les 5 lieux les plus souvent fréquentés, il faut conserver tous les lieux (ou simplifier avec seulement les lieux récents).
[^] # Re: Dérive d'Apple
Posté par Sufflope (site web personnel) . Évalué à 2.
Il doit bien y avoir moyen de bidouiller un truc avec un HyperLogLog ou autre bizarrerie.
[^] # Re: Dérive d'Apple
Posté par groumly . Évalué à 3.
tu peux hasher les regions et maintenir un compte de cette facons, pour ensuite ne garder que les 4-5 plus frequents.
Bon, après je sais pas si c'est ce qu'ils font en pratique, mais c'est tout a fait possible de tenir le compte sans tout stocker en clair.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
# Comment ça marche
Posté par Strash . Évalué à 2.
Comment fonctionne la géolocalisation par Wifi ? Je comprends le principe de triangulation, etc… mais comment la borne connaît-elle sa position (afin de la diffuser) ?
[^] # Re: Comment ça marche
Posté par Crash . Évalué à 7.
De ce que j'ai compris, quand un smartphone repère des bornes Wifi et qu'il les envoient au serveur, il envoie aussi ses propres coordonnées GPS. Ainsi chaque borne est liée à des coordonnées. Donc la borne elle-même ne connait pas sa position, c'est le GPS du téléphone qui l'assigne.
[^] # Re: Comment ça marche
Posté par Aissen . Évalué à 6.
J’ai pourtant essayé d’expliquer le système dans le journal:
Je retente:
# Au moins on a le choix
Posté par AgentSteel (site web personnel) . Évalué à 5. Dernière modification le 31 octobre 2014 à 10:55.
Ici l'utilisateur fait une démarche volontaire de recensement en installant et en utilisant le logiciel, sur d'autres plate-formes mobiles c'est un peu plus… retors.
Par exemple, au tout premier démarrage d'un appareil sous Android, l'assistant demande gentiment s'il faut autoriser le système de géolocalisation en tâche de fond de google (qui peut se faire même si le wifi est "éteint"…).
Madame Michu peut très bien cocher la case en cas de doute :)
Ce qui veut dire que des millions d'appareils Android tout autour de nous font de la détection en temps réél.
Enfin, MozStumbler devrait offrir une fonction pour limiter la détection autour d'un certain lieu (geofencing)
Voir https://github.com/mozilla/MozStumbler/issues/791
[^] # Re: Au moins on a le choix
Posté par Dr BG (site web personnel) . Évalué à 4.
C'est d'ailleurs très chiant, parce qu'au début, je pensais bêtement que je désactivais le Wifi, il était vraiment éteint. Maintenant que je coupe la localisation et le Wifi, mon téléphone tient deux fois plus longtemps sur batterie.
# Incompatible GPLv3?
Posté par ®om (site web personnel) . Évalué à 2. Dernière modification le 31 octobre 2014 à 12:21.
Impossible donc d'utiliser ce service dans une appli GPLv3 ?
En effet, si une telle appli était en GPLv3, n'importe qui pourrait la recompiler en effectuant éventuellement quelques modifications (je donnais ici l'exemple de la modification du nom d'une Activité). Mais pour faire cela sans casser la fonctionnalité de localisation, cette personne devrait fournir une API key.
Deux cas :
Je ne suis pas sûr de mon raisonnement, des confirmations ou infirmations sont les bienvenues.
blog.rom1v.com
[^] # Re: Incompatible GPLv3?
Posté par Aissen . Évalué à 2.
Sans même parler de GPLv3, il est possible d’extraire des API keys de n’importe quelle application cliente; Twitter l’a apprit à ses dépends:
http://arstechnica.com/security/2010/09/twitter-a-case-study-on-how-to-do-oauth-wrong/
https://gist.github.com/rhenium/3878505
Le système même d’API keys ne fonctionne pas à partir du moment où les applications sont distribuées dans la nature (c’est à dire ne tournent pas sur un serveur).
[^] # Re: Incompatible GPLv3?
Posté par ®om (site web personnel) . Évalué à 2.
Tout-à-fait d'accord. Mais je parlais "légalement" ou "contractuellement", tu fais une appli GPL tu ne vas pas prendre l'API key de Mozilla (ou Twitter) si tu la diffuses.
Au passage, je n'ai peut-être pas tout compris, mais je ne vois pas le rapport avec OAuth (l'article d'ArsTechnica). OAuth c'est pas fait pour "protéger" des API key…
blog.rom1v.com
[^] # Re: Incompatible GPLv3?
Posté par Aissen . Évalué à 2.
Le seul rapport avec OAuth c’est qu’il y a un secret qui est "caché" dans l’application.
[^] # Re: Incompatible GPLv3?
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 3.
Le projet Haiku utilise MLS. On est sous license MIT, mais voilà ce qu'on a mis en place:
Le code source ne contient pas de clé. Elle est injectée dans nos images officielles par nos serveurs de build. Cependant, une autre clé peut etre fournie à la compilation. De plus, l'API permet de spécifier une clé et un service différents à l'exécution. Elle reste donc utilisable pour toute personne qui a une clé MLS ou une clé Google APIs (le service de geolocalisation de Google utilisant le meme format de requetes).
De plus, il existe une clé "test" pour le service de Mozilla. Elle est disponible à condition d'en faire une utilisation raisonable. Dans le cas de Haiku elle est utilisée par notre testsuite.
Il y a donc une petite différence de comportement entre le binaire distribué et les sources fournies, mais rien de grave, je pense. J'ajoute que Mozilla utilise une solution similaire pour distribuer Firefox, qui contient une clé pour utiliser ce service aussi bien avec MLS que l'équivalent chez Google.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.