Bienvenue sur le forum de Exodus-Privacy.

Plusieurs sujets de discussion vous attendent.

Comme tout forum, celui-ci est soumis à la loi française

Les propos discriminants ne sont pas les bienvenus et seront sanctionnés sans aucune pitié. Nous vous demandons d'être bienveillant·e·s les un·e·s envers les autres.

Le forum n'est accessible qu'après enregistrement..



L'Équipe d'Exodus Privacy

 Welcome on the Exodus-Privacy forum.

Many topics are waiting for you

As this forum is under French law, any author of discriminatory comments will be banned without mercy. Please be kind with everybody.

The topics are only available to registered people.



The Exodus Privacy Team.

API authentication



  • Discussion au sujet de l’authentification sur l’API exodus.
    Ci-dessous les précédents messages de @Guinness extraits de Gitea :

    The current status is the following:

    Function Basic description current status
    get_report_info basic information of the tracker (./)
    get_apk get the apk (./)
    get_all_reports returns the list of all reports (x)
    get_all_trackers returns the list of all trackers (x)
    get_all_applications returns the list of all apps (reports, icon, version, version_code excluded) (x)
    search_strict_handle Returns the reports corresponding to the given handle (x)
    get_report_details returns the detailed report of the app (x)
    search returns the applications or reports based on the name (x)
    search_strict_handle_details detailed reports based on the handle (./)

    The routes are here .
    Then, all the views are defined here

    What happens it terms of exposition:
    The decorator authentication_classes defines the authentication method to be used, the permission_classes defines who should be allowed to access the view, and the api_view defines which http request is allowed (GET, POST).
    The documentation of the package is here



  • Bon je me lance.
    À mon avis, il faut que tout soit sous clef d’API sauf la liste des pisteurs.
    Ensuite, il faut qu’on ait des CGU écrites et une licence pour les données.
    Et enfin, une page qui explique comment obtenir une clef avec toutes les infos, et dont l’URL sera dans la réponse envoyée quand tu fais une requête sur l’API sans avoir de clef.

    Je veux bien vos avis là-dessus !



  • Bon du coup je me re-lance.
    Après avoir regardé dans le code, il y a quelques points de l’API qui sont utilisés :

    • /api/search
    • /api/report/<report_id>

    Donc il faudrait laisser ceux-là libres.

    Pour le code, ça se trouve ici :

    Donc il faudrait a priori laisser ces points ouverts, ou alors songer à une autre méthode, mais ça me semble pas gagné au vu de leur utilisation.



  • Coucou,

    Est-ce que /api_search et /api/report/<report_id> sans clef ne peuvent pas servir à nous pomper nos données sans vergogne ?

    Si on laisse cela ouvert cela veux dire qu’on peux avec un script python de 10 lignes nous pomper l’intégralité de de nos rapports. Me trompè-je (je l’espère) ?

    Parce que même si tout est accessible et libre, il ne faudrait pas que des petits malins s’approprie notre travail et celui de la communauté.

    Il reste vrai qu’il fat que nous travaillons d’arrache pied (mon dieu qu’il est drôle) pour produire des CGU et une licence. On devait avoir de l’aide là dessus, mais cela fait bien trop longtemps que nous n’avons pas de nouvelle de ce côté. Va t-on être obligé de pomper les GCU d’autres et les adapter (OSM par exemple) ?


  • ag_2018

    @Lovis_IX a dit dans API authentication :

    Parce que même si tout est accessible et libre, il ne faudrait pas que des petits malins s’approprie notre travail et celui de la communauté.

    N’importe qui peut reproduire ces résultats en fait, vu que tout est librement accessible. Les pomper en l’état par contre c’est être incapable de les « prouver » sans être en possession des apks pour les anciens etc.
    Ya aussi les explications autour etc.



  • Bonjour à tous,
    Pas sur d’être sur le bon sujet pour évoquer cela, mais je voulais continuer https://mamot.fr/web/statuses/102685417977299345 :
    Si je comprend l’API et l’application Android, il y a deux méthodes pour demander les rapports d’une Application:

    • Demander tous les rapport et chercher soi-même dedans (ce que fait l’application Android)
    • Demander application par application la liste des rapports
      La première méthode a l’avantage de respecter la vie privé, le serveur n’ayant pas à connaitre la liste des application installés, mais l’inconvénient d’avoir à télécharger et décoder un blob json de plus de 5mo.
      Serait-il envisageable/souhaitable/intéressant d’avoir un point d’entré d’API genre /api/applications/[partial SHA1]
      [partial SHA1] est le début (3 à 8 caractères par example) du SHA1 du nom de l’application ? Ainsi pour chaque application, ne sont téléchargés que une centaine de rapports, sans toutefois révéler le nom des application réellement installés. (J’ai un doute, en relisant le code de l’application Android, j’ai l’impression qu’après l’appel à /applications il fait un appel par application à /search , révélant ainsi au serveur la liste des applications installés)


  • Hello @tdelmas !

    Du côté de l’API je ne pense pas que cela pose un problème de créer un nouvel endpoint si besoin. Il faudrait voir au niveau de l’implémentation dans l’application Android. Le meilleur endroit pour en discuter est sans doute de créer un issue dans le dépôt Github associé : https://github.com/Exodus-Privacy/exodus-android-app



  • Hum,
    Quel est ton threat model pour ça ?
    On fait des requêtes mettons sur les SHA1-partiels du handle de l’application. Donc de l’autre côté on les a stockés, ok, le serveur a les infos. Ça fait moins de transactions réseau. Mais le serveur a quand même pas mal d’infos. Il faudrait voir le nombre de conflits qu’on a actuellement sur les (mettons SHA1) des handle d’applications pour voir à quel point c’est identifiant et ça change quelque chose ou non ?

    Ensuite, dans mes souvenirs, l’application demande la liste de ses applis installées + d’autres rapports en plus pour ne pas pouvoir «exactement» identifier. Même si en pratique, si tu ouvres l’application et que tu fais l’intersection de tous les rapports demandés, tu identifies bien vite les applications installées à très peu d’erreurs près.

    Donc perso je ne suis pas fermée à l’idée du tout, mais ça demande un poil d’analyse avant pour savoir si on y gagne vraiment quelque chose ?



  • Quel est ton threat model pour ça ?

    Pas de threat model en particulier, juste le principe de laisser trainer le moins d’informations possible. Je n’aime pas l’idée qu’un service, même associatif, aient la liste des applications que j’ai installé sur mon téléphone. C’est personnel. Très personnel. Cela peut révéler ma religion, mon état de santé, mon apartenance politique. Et du coté technique, avoir la liste des applications permet de faciliter le piratage d’un téléphone, (techniquement ou via ingénierie sociale).

    Et que l’application le fasse sans prévenir, c’est moyen. Quand je l’ai installée, je pensait qu’elle téléchargeais en local tous les rapports, et ne fournissait donc aucune information aux serveur d’exodus. Ce n’est apparemment pas le cas.

    Désolé si ma réponse semble agressive, ce n’est pas le but. mais “Quel est ton threat model pour ça ?” a raisonné dans ma tête comme “qu’est-ce que tu a à cacher ?”.

    On ne devrait pas avoir a se justifier lorsque l’on essaye de faire en sorte de limiter la diffusion des données personnelles. Surtout pour une association qui a pour but de montrer l’abus de ces diffusions!

    (issue opened: https://github.com/Exodus-Privacy/exodus-android-app/issues/63)



  • Désolée si j’ai semblé agressive, ce n’était pas le but 😞 . Ma phrase était vraiment très mal tournée, surtout au vu de la suite du post. Un reliquat de mon premier brouillon…

    Je suis tout à fait d’accord avec toi, mais normalement comme je l’ai dit l’application télécharge plus de rapports que nécessaire pour se protéger de ça (je n’ai pas touché au code, mais c’est ce dont on avait parlé à l’époque).
    Cependant, je suis d’accord avec toi qu’il faut un meilleur modèle que celui là.
    Par exemple le modèle avec les SHA1 est très sûrement une bonne idée, il faut juste qu’on prenne le temps de faire une étude des conflits pour pouvoir être sûr·e·s qu’il y a assez de conflits pour que ça ne soit pas identifiant. Parce que sinon on aura rien gagné à part un sentiment de sécurité qui n’en est pas.

    Désolée encore pour ce quiproquo, et j’espère qu’ensemble on réussira à trouver une solution satisfaisante pour toustes !



  • Désolée si j’ai semblé agressive, ce n’était pas le but

    @Guinness Pas de soucis, ça arrive 😉 et demander le threat-model et plutôt un bon réflexe !

    La discussion a aussi continué ici : https://github.com/Exodus-Privacy/exodus-android-app/issues/64


Log in to reply