Vidéo Camille 3



  • Hello les ami.e.s,

    Jamais deux sans trois, comme on dit par chez moi. Donc, après une première vidéo qui expliquait ce que sont les pisteurs et une seconde sur le type de données collectées, je propose d’en faire une troisième.
    J’hésite entre plusieurs thématiques :

    • Comment les pisteurs se retrouvent-ils dans les applications ?
    • Comment se font les analyses sur la plateforme d’EP ?

    Je pense que la première est plus intéressante car plus généraliste. Vous me direz.
    Je pourrai faire une vidéo sur comment se font les analyses, mais peut-être sans Camille, avec une vidéo plus classique et se destinant à un public peut-être plus connaisseur ?

    Bref, revenons à "comment les pisteurs se retrouvent-ils dans les applications ?"
    Voici une proposition de scénario, qui est tout à fait améliorable :

    Camille, maintenant qu’elle sait qu’il existe des pisteurs dans les applications qui peuvent collecter des données sur elle.
    Elle a bien compris que la principale motivation à la collecte des données, c’est l’argent. En effet, une application gratuite dont le modèle économique repose sur la publicité cherchera à faire de la publicité la plus ciblée possible. Une société qui revend des données personnelles cherchera également à augmenter son profit au maximum.
    Mais, ce qui étonne Camille, c’est d’apprendre que certaines entreprises ne sont même pas au courant de l’existence de pisteurs dans leurs applications ! En effet, certains créateurs et créatrices d’applications utilisent des bibliothèques de code prêtes à l’emploi : il suffit de les rajouter dans l’application. Mais certaines bibliothèques embarquant déjà des pisteurs, c’est comme ça qu’on peut se retrouver avec une application qui collecte de la donnée, sans que la personne à l’origine de l’application en ait connaissance.

    Je cherche une chute 🙂



  • Celle qui m’intéresserait personnellement serait la seconde. Cette vidéo devrait comme tu le dis être beaucoup moins “ludique” et plus technique, madame Michu ne la regardera pas de toute façon…

    Après, en parcourant le forum j’ai vu qu’un point était souvent levé, la sensibilisation du grand public et la phrase que les gens doivent se poser “il y a des pisteurs et je fais quoi maintenant ?”. Je trouverais donc plus logique de continuer un peu les vidéos dans la veine des deux premières, et d’expliquer déjà comment arrivent ces pisteurs sur nos applications.

    Pour la chute je sais pas trop, mais c’est une bonne idée de parler du fait que l’ajout des pisteurs n’est pas forcément volontaire (bon, que ça ne soit pas non plus une excuse pour les devs^^). Ça peut ne pas être trop exagéré de dire que les utilisateurs ne sont pas seules victimes et seuls concernés par cette chasse aux pisteurs, et qu’Exodus peut aussi servir aux développeurs soucieux de ces principes à vérifier leurs applications.
    Cela pourrait être une autre façon de vendre Exodus, permettre aux développeurs de vérifier leurs applications (avant leur publication sur le PlayStore) pour voir s’ils n’ont pas malencontreusement ajouté de pisteurs. Exodus ne viserait plus seulement les utilisateurs mais aussi les développeurs pour cette prise de conscience.



  • Sur irc, @U-039b proposait de faire une vidéo plus technique en effet sur “comment se fait l’analyse” et balayer cette légende des faux positifs chez EP. Affaire à suivre (@U-039b n’hésite pas si tu as besoin d’aide 🙂 )

    Et merci pour toutes tes remarques. En effet, j’ai du mal à trouver le point d’équilibre entre “les dev mettent des pisteurs car iels veulent les mettre ou s’en foutent” et “les dev ne maîtrisent pas totalement ce qu’iels font”. Je pense néanmoins que le grand public n’a aucune connaissance de ces histoires de bibliothèques et que les dev maîtrisent finalement pas tant que ça ce qu’iels font. Du coup, appuyer la dessus peut être intéressant

    Et la chute peut donc être un peu comme dans Camille 1, que la plate-forme permet d’analyser les applis.
    Bon, ça demande à être affiné, tout ça.
    Le but c’est d’être accessibles et justes à la fois.

    Du coup, si tu veux retoucher le premier jet de scénario, n’hésite pas @BarbossHack !


  • administrators

    @MeTaL_PoU @BarbossHack réponse courte https://www.youtube.com/watch?v=o55Ap9EW8XA

    Une réponse détaillée à ce thread arrivera ensuite.



  • @U-039b Merci ! Un talk que je n’avais pas vu 🙂


  • administrators

    Comment EP fait ses analyses ?

    Il faut que je me motive à faire une vidéo technique pour expliquer ce que j’explique depuis début décembre. Il y a déjà des éléments dans les slides de nos talks. Je vais faire une vidéo step-by-step permettant à un dev niveau CE1 de refaire l’analyse à la maison. Et je vais bien insister sur le fait que si on trouve des morceaux de code d’un tracker dans une appli alors c’est qu’il y est !

    Comment les pisteurs se retrouvent-ils dans les applications ?

    Dans ma tête à moi, on peut dégager 3 cas :

    1 - Promis c’est pas moi !
    On retrouve des pisteurs dans certaines applications pour lesquelles les devs n’ont jamais eu l’intention d’en mettre. Par exemple, lorsque l’on développe une application avec Unity, ce logiciel rajoute automatiquement ChartBoost sous certaines conditions sans que la personne faisant le dev ne l’ait demandé.

    2 - J’ai pas RTFM !
    Oui, la lecture c’est so 19eme siècle ! Par exemple, lorsque l’on développe une application dans laquelle on souhaite permettre aux end users de se connecter avec un compte Facebook et bien Facebook Connect (enfin le SDK) va collecter tout un tas d’infos sans que les devs n’en aient conscience parce que pas RTFM.
    Ou encore, cas récent avec Ring qui utilise Firebase Cloud Messaging (FCM) pour faire du push dans l’application. FCM a une dépendance sur Firebase Core (FC) et FC embarque Firebase Analytics (FA). Donc si je résume : je veux faire du push de messages vers mon application alors j’utilise FCM et sans le vouloir, j’ai embarqué FA ! Alors maintenant je plonge mon nez dans the fucking manual, Google explique très bien cela et explique même que FA collecte par défaut (sans demander l’avis de quiconque) et qu’il est de la responsabilité des devs de désactiver la collecte de données programmatiquement.

    2-bis - J’étais presque pas au courant, promis
    Les devs, marketeux & co. ne comprennent pas qu’en monétisant leurs bouses avec de la pub, ce sont toutes les données des end-users qui sont servies sur un plateau à destination des régies publicitaires et autres. Donc, contre quelques centimes gagnés avec un bandeau de pub, la régie derrière, elle, elle enrichit sa base de profils. C’est le schéma classique de Google, Facebook, MAdvertise et tellement d’autres. Ici, je prends l’exemple de la pub mais ça s’applique aux autres types de pisteur.

    3 - Ouais, et alors ?
    La dernière catégorie, les winners, sont les devs qui volontairement embarquent une tripotée de trackers parce que le marketing a dit que, parce qu’il faut monétiser, etc C’est le cas de Grindr qui envoyait volontairement le statut VIH à des services tiers parce que Grindr se fait du cash en revendant ces données à des tiers. Ces devs là sont des pourritures.

    Il y a des pisteurs et je fais quoi maintenant ?

    De mon point de vue, il n’existe aucune solution parfaite mais plutôt un ensemble de bonnes pratiques avant tout. Par exemple, un site existe (Le Monde) et y a aussi la version appli alors j’utilise le site dans un navigateur auquel j’ai ajouté un bloqueur de pubs. Et, lorsque passer par le site n’est pas possible, alors installer Blokada ou installer PiHole quelque part. Bref, pas de solution miracle. Il faut responsabiliser tout le monde et accepter que certaines personnes s’en fichent de filer leur vie privée à Facebook.
    [edit] Comme dirait B. Bayart : avant d’utiliser un service, posez-vous la question “quel est son business-model”

    Même s’il serait légitime de penser que dans le cadre des opérations de vulgarisation menées par EP il faudrait inclure les devs, cela me pose un problème éthique. Ces gens sont payés et sont donc responsables des bouses produites. EP leur fournit déjà des outils mais EP n’ira pas leur expliquer comment fonctionne Facebook. Par contre, EP peut expliquer les enjeux liées aux trackers mais ne leur fournira jamais des conseils gratuitement !

    My two cents


  • administrators

    <avis personnel>
    Concernant la vulgarisation, de mon point vue, il est très important de laisser de coté nos fantasmes. J’illustre :
    Vais-je renier ma mère parce qu’elle n’utilise pas une smartcard avec un trousseau GPG généré offline pour chiffrer ses mails ?
    Vais-je renier ma meilleure amie car elle trouve un intérêt à la pub ciblée ?

    Tout le monde n’a pas le même modèle de menace pour sa vie privée. Certaines personnes resteront convaincues qu’elles n’ont rien à cacher. Et alors ? Pour moi, l’objectif de la vulgarisation est d’offrir des éléments buvables permettant à quiconque de pourvoir faire des choix en connaissance de cause. Encore une fois, j’illustre : je sais que mon dentifrice contient une substance cancérigène et oui, je n’ai pas changé de dentifrice. Je prends le risque et je sais que c’est un risque. Fournir des clefs de compréhension à un public qui, de prime abord, n’y connaît rien. Et on ne peut pas lui reprocher de rien y comprendre puisqu’on fait tout pour qu’il n’en sache rien. Et il faut accepter que tout le monde n’a pas forcément envie de se plonger dans la technique, dans les textes de loi, etc. Le meilleur exemple est ma kiné.

    Pour moi, il est impératif de ne jamais tomber dans un discours moralisateur voire culpabilisant. Montrons les choses, les gens ne sont pas débiles (même si l’actualité nous laisserait penser le contraire). J’affirme que le simple fait de montrer les requêtes DNS (noms de domaine) qu’un ordiphone émet au lancement d’une application frappe les gens. Et oui, quand une personne pas du tout “avertie” se rend compte que son application de suivi cardiaque contacte Facebook, ce n’est pas bon pour ses maux.

    Si nous tentons de vulgariser c’est pour éviter les omertas. Plusieurs sociologues affirment que la disparition de l’intimité à cause d’Internet représente un risque majeur pour la société tout comme a pu l’être le scandale de l’amiante. Oui, on nous fait croire que tout va bien, tout est sous contrôle, que c’est pour notre bien jusqu’à ce qu’il y ait des morts.

    Enfin, je trouve que tout le travail de @MeTaL_PoU sur les vidéos est d’une qualité remarquable car elle a su exposer des réalités complexes d’une façon courte, simple, abordable sans jamais biaiser la réalité.

    Keep going!

    </avis personnel>



  • Ouahhhh.
    Merci pour tout ça 🙂


  • administrators

    Coucou,
    Je suis d’accord avec tout le monde 🙂

    La vidéo Camille3doit expliquer comment les pisteurs viennent dans les applications, parfois à l’insu du plein des devs. Il ne faut surtout par les pointer du doigt sous peine de les voir se braquer contre nous.
    Même si les catégories décrites par @U-039b sont bien réelles, il ne faut pas faire de distinction dans Camille3.

    Pour la chute je pense à un truc du genre
    « Maintenant que Camille sait comment les pisteurs arrivent dans les applications, elle peut chercher des alternatives à ces applications préférées en utilisant les rapports d’EP »

    Il nous faut aussi cette vidéo plus technique qui explique comment fonctionne Exodus et pourquoi les faux positifs sont impossibles.



  • <mytwocents>

    Pour expliquer l’histoire des bibliothèques il pourrait être possible d’utiliser des métaphores comme la construction/fabrication.
    Pour le moment je pense à la construction d’une maison, il est très certainement possible de trouver mieux. Globalement le dev va ‘chercher des matériaux’ (les briques, les fenêtres, les portes, le plan de travail, et les assembler pour que ça tienne debout et que ça ait plus ou moins une belle tête. Mais ce n’est pas lui qui cuit les briques ou peint les fenêtres, il les prends toutes faites. Et, pour x ou y raisons, il ne vérifie pas si la fenêtre contient une caméra ou des micros.

    Je plussoie le fait qu’alerter les gens c’est bien, proposer des solutions comme celle du site oueb c’est mieux, mais ce sont deux axes différent.
    AMHA il est aussi possible de parler de l’impact ‘collatéral’. Si j’installe linkedin (ou je sais plus quoi) qui, au premier lancement, envoie la liste de tous mes contacts chez eux, alors je n’ai pas envoyé que mes données, mais aussi des choses concernant des personnes qui me sont plus ou moins proches.

    </mytwocents>



  • Bonjour,
    A partir de vos remarques et de la proposition de @nailyk d’utiliser la métaphore de la construction, j’ai fait un nouveau scénario. J’ai également expliqué comment se fabrique une application, parce qu’en fait, il y a sûrement plein de gens pour qui ce n’est pas évident. N’hésitez pas à me corriger ou faire des critiques.

    Comment des pisteurs se retrouvent dans les applications – par Exodus Privacy

    Dans les deux premiers épisodes de Camille (lien vers les vidéos), cette dernière a découvert qu’il existe des pisteurs dans les applications de son téléphone, que ceux-ci peuvent collecter des données sur elle et quels types de données sont concernés. Comme Camille aime bien se poser des questions, elle se demande comment les pisteurs se retrouvent dans les applications ! Et pour ça, il faut qu’elle comprenne comment se fabrique une application.
    Une application, c’est un peu comme une voiture, ça se fabrique en plusieurs temps :
    Un jour, des personnes décident de créer une voiture, elles définissent donc quel sera son but : permettre à des personnes comme Camille de se rendre d’un point A à un point B et ses caractéristiques : un moteur plus ou moins puissant, une apparence colorée, des équipements pour le confort de l’utilisatrice, etc. Pour la création de l’application c’est pareil : des personnes définissent ce que doit faire l’application, ses principales caractéristiques. C’est après aux développeuses et développeurs de fabriquer réellement l’application, en écrivant du code informatique.

    Mais alors, comment les pisteurs se retrouvent-ils dans les applications ?
    Cela peut être une décision des personnes à l’origine de l’application, par exemple si leurs revenus vient de la publicité. Des pisteurs permettront une publicité plus efficace car plus ciblée.
    Mais il arrive également que les personnes à l’origine de l’application mettent des pisteurs sans s’en rendre compte. Si on reprends la fabrication de la voiture : les personnes qui fabriquent la voiture peuvent soit tout fabriquer de A à Z, soit assembler des morceaux fabriqués par d’autres. Pour la fabrication des applications, c’est la même chose : les développeuses et développeurs peuvent soit tout coder de A à Z, soit utiliser des bibliothèques de code déjà prêt. Et dans celles-ci, il peut y avoir des pisteurs ! En installant des bouts d’application, les pisteurs se retrouvent dans l’application finale.



  • Les remarques de @nailyk qui ne peut plus se connecter ici :

    Comment des pisteurs se retrouvent dans les applications – par Exodus
    Privacy

    Dans les deux premiers épisodes de Camille (lien vers les vidéos),
    cette
    dernière a découvert qu’il existe des pisteurs dans les applications de

    son téléphone, que ceux-ci peuvent collecter des données sur elle et
    quels types de données sont concernés. Comme Camille aime bien se poser

    des questions, elle se demande comment les pisteurs se retrouvent dans
    les applications ! Et pour ça, il faut qu’elle comprenne comment se
    fabrique une application.

    Une application, c’est un peu comme une voiture. Elle sont toutes deux faites pour emmener camille au super marché, a la poste, dans une sale de jeu, etc…

    Une application, c’est un peu comme une voiture, ça se fabrique en
    plusieurs temps :
    Un jour, des personnes décident de créer une voiture, elles définissent

    donc quel sera son but : permettre à des personnes comme Camille de se
    rendre d’un point A à un point B et ses caractéristiques : un moteur
    plus ou moins puissant, une apparence colorée, des équipements pour le
    confort de l’utilisatrice, etc. Pour la création de l’application c’est

    pareil : des personnes définissent ce que doit faire l’application, ses

    principales caractéristiques. C’est après aux développeuses et
    développeurs de fabriquer réellement l’application, en écrivant du code

    informatique.

    Une application ou une voiture, c’est complexe a concevoir. Il y a beaucoup d’elements différents. Les portières, le moteur, la carosserie.
    Certains ingénieurs vont utiliser des moteurs tout faits, qu’il vont acheter et mettre dans la carosserie qu’ils ont fabriqués. (Exemple Dacia et renaud)
    D’autres vont au contraire concevoir des nouveaux moteurs pour mettre dans des carosseries existantes.
    Pour une application, c’est pareil. Les développeurs peuvent choisir d’utiliser des briques de code toutes faites, comme la carosserie, pour se concentrer sur autre chose.

    Mais alors, comment les pisteurs se retrouvent-ils dans les
    applications
    ?
    Cela peut être une décision des personnes à l’origine de l’application,

    par exemple si leurs revenus vient de la publicité. Des pisteurs
    permettront une publicité plus efficace car plus ciblée.
    Mais il arrive également que les personnes à l’origine de l’application

    mettent des pisteurs sans s’en rendre compte.

    Par exemple, lorsque le développeur choisi sa brique de code moteur, faite par une autre entreprise, il va embarquer un GPS qui suivra a la trace tous les déplacements du moteur. Sauf que le moteur, étant dans votre voiture, va forcément indiquer tous vos déplacements.

    Si on reprends la

    fabrication de la voiture : les personnes qui fabriquent la voiture
    peuvent soit tout fabriquer de A à Z, soit assembler des morceaux
    fabriqués par d’autres. Pour la fabrication des applications, c’est la
    même chose : les développeuses et développeurs peuvent soit tout coder
    de A à Z, soit utiliser des bibliothèques de code déjà prêt.

    Et dans
    celles-ci, il peut y avoir des pisteurs ! En installant des bouts
    d’application, les pisteurs se retrouvent dans l’application finale.



  • Hello,
    Proposition de scénario pour une vidéo d’environ 3 minutes à partir des propositions de @nailyk :
    Comment des pisteurs se retrouvent dans les applications – par Exodus Privacy
    Précédemment dans les aventures de Camille : (reprendre extraits des vidéos précédentes, comme dans les séries qui résument les épisodes précédents).
    Camille est interrogative : dans certaines des applications de son téléphone, il y a des pisteurs qui collectent des données sur elle. Elle se demande à quel moment ils s’y sont retrouvés. Pour répondre à cette question, elle va devoir comprendre comment se fabrique une application.
    Une application, c’est un peu comme une voiture.
    Elles ont toutes deux un but : permettre à Camille de faire ses courses, d’aller dans une salle de jeu ou de poster un colis.
    Elles sont toutes deux complexes a concevoir. Beaucoup d’éléments (les éléments passeront par les dessins) et de professions différentes participent à la création.
    Pour la fabrication du moteur d’une voiture, deux choix s’offrent aux ingénieur.e.s : soit fabriquer le moteur soit utiliser un moteur créé par d’autres. Pour une application, c’est pareil. Les développeurs et développeuses, cad les personnes qui écrivent le programme informatique, peuvent choisir d’utiliser des morceaux de code tout fait dans des bibliothèques de code ou bien tout écrire de A à Z.
    Mais alors, à quel moment les pisteurs se retrouvent-ils dans les applications ?
    Un pisteur, c’est un bout de code, donc il faut que quelqu’un l’écrive à un moment dans le programme de l’application.
    Cela peut être une décision des personnes à l’origine de l’application, par exemple si leurs revenus viennent de la publicité.
    Mais il arrive également que les personnes à l’origine de l’application mettent des pisteurs sans s’en rendre compte.
    Par exemple, si une développeuse utilise un bout de code fait par d’autres, qui comprend un pisteur de géolocalisation sans qu’elle le sache, alors l’application finale comprendra ce pisteur. Et si Camille l’installe sur son téléphone, elle sera suivie à la trace par ce biais.
    Pour voir les autres aventures de Camille, vous pouvez aller voir les deux premiers épisodes et vous abonner à la chaîne d’Exodus Privacy sur YT ou PT. Suivez-nous également sur Mastodon, Twitter et facebook.


  • administrators

    J’ajouterais quelque chose comme : comme on trouve le même moteur dans différentes voitures, on trouve les mêmes pisteurs dans différentes applications.

    Sinon, c’est très bien





  • @metal_pou J’ai trouvé la vidéo vraiment top, le sujet est primordial et bien expliqué.
    Personnellement je trouve le rythme de la vidéo un poil trop lent (mais vraiment un chouïa).



  • Alors, sur le rythme, il manque la musique que je n’ai pas encore composée.
    Donc ça peut améliorer ta sensation.

    Mais je fais attention à parler dis-tin-cte-ment, ce qui peut ralentir le tout.

    On verra avec la musique pour se faire une idée plus précise de l’ensemble, au pire je réenregistrerai.





  • La vidéo finale est sur le Git.

    Ma proposition de présentation :

    "Dans cette troisième vidéo des aventures de Camille, cette dernière découvre comment les pisteurs se retrouvent dans les applications et peuvent ainsi collecter des données sur elle.

    Episode 1 : Titre + Lien

    Episode 2 : Titre + Lien

    Exodus Privacy est une association qui a développé des outils d’analyse des applications Android et sensibilise le grand public aux questions du pistage et de la collecte des données + lien vers le site."

    Une fois cette présentation validée, je peux uploader la vidéo sur PT. @Lovis_IX, tu pourras le faire sur YT ?


  • administrators

    Je dois pouvoir le faire plus facilement sur peertube. Je peux même le faire pour les deux si tu veux.