Forum général.général Question sur la légalité de l'analyse du traffic réseau d'une application Android

11
1
sept.
2018

Bonjour,

Depuis le début d'année j'ai un capteur chez mois qui alimente des données dans le cloud qui sont ensuite accessibles via une application Android / IOS (même pas de site Web).

J'aurais voulu avoir aussi accès à ces données donc j'ai contacté le service support pour leur demander si une API était disponible et documentée, après des échanges assez comiques j'ai compris que non, la seule utilisation était l'application mobile.

Cette réponse ne me satisfaisant pas j'ai installé sur mon téléphone un outil qui capture le traffic réseau (via un VPN interne). J'ai pu récupérer l'intégralité des échanges faits que j'ai pu retranscrire dans un programme en python qui se lance dans un cron tous les jours chez moi.

Bref ça marche depuis plusieurs mois. Hier je me suis dit que c'était stable et j'ai créé un dépôt Github (Avec un compte attaché à mon nom réél), commencé à écrire une documentation sommaire et je m’apprêtais à faire mon push quand je me suis posé la question sur la légalité de ce que j'ai fait.

J'ai essayé de faire quelques recherches et je n'ai pas trouvé de réponse claire. Je n'ai pas désassemblé l'APK (ce qui semble illégal), j'ai juste analysé le traffic avec une application tout ce qui a de plus normal (même pas besoin de root). Si il y avait un client web j'aurais fait la même chose avec la console de développement de mon navigateur.

Qu'en pensez vous ? A noter que je suis Français et que je réside en France si cela a une importance.

Merci d'avance.

  • # RE

    Posté par . Évalué à -1.

    • [^] # Re: RE

      Posté par (page perso) . Évalué à 2.

      Si je suis le texte de loi :

      • III : J'ai donc le droit de l'observer (voir ses communications avec l'extérieur via le réseau). Pour l'instant je reste dans le cadre de la loi.
      • IV :
        • Condition 1 : Techniquement l'application est gratuite et j'ai un compte officiel donc c'est OK.
        • Condition 2 : J'ai demandé au service technique la doc de l'API et on m'a dit que ce n'était pas possible donc c'est OK.
        • Condition 3 : Je n'utilise qu'une seule URL d'API qui me sert et pas le reste donc c'est OK aussi
        • Limite d'utilisation 1 : Premier doute j'explique comment créer un token JWT qui peut être utilisé pour tout sur ce logiciel (la sécurité pourrait être meilleure).
        • Limite d'utilisation 2 : Deuxième doute je n'ai pas besoin de le communiquer à des tiers, c'est juste pour être sympa.
        • Limite d'utilisation 3 : Dans mon cas ce n'est pas le but mais cela pourrait être utilisé pour faire un service Web concurrent.

      Pour l'instant je ne suis pas chaud. J'ai bien fait de ne pas pousser sur Github comme un con. Je vais relire les conditions d'utilisation du logiciel et du service pour voir si il n'y a pas des petites lignes en plus.

      Merci du lien.

      • [^] # Re: RE

        Posté par . Évalué à 4. Dernière modification le 02/09/18 à 10:32.

        Pour l'instant je ne suis pas chaud. J'ai bien fait de ne pas pousser sur Github comme un con. Je vais relire les conditions d'utilisation du logiciel et du service pour voir si il n'y a pas des petites lignes en plus.

        Je pense que tu devrais relire plus en détail, parce qu'à première vue cet article de loi me semble te protéger. Si je te comprends, le résultat de ton analyse est un logiciel créé de façon indépendante et qui interagit avec une partie de l'autre logiciel proprio dont tu parles. Ou bien j'ai raté un détail?

        • [^] # Re: RE

          Posté par (page perso) . Évalué à 2.

          2° Ni communiquées à des tiers sauf si cela est nécessaire à l'interopérabilité du logiciel créé de façon indépendante ;

          C'est cette phrase qui m’embête le plus : je poste sur Github je communique à des tiers le logiciel complet (les urls, comment générer le token JWT) avec les sources.

          Et en plus je ne suis pas sur le terme interopérabilité corresponde à utiliser une API qui n'est pas censée être publique

          V. Le présent article ne saurait être interprété comme permettant de porter atteinte à l'exploitation normale du logiciel ou de causer un préjudice injustifié aux intérêts légitimes de l'auteur.

          Pour cet article, le logiciel que je met à disposition pourrait être exécuté dans une boucle infinie sur plusieurs threads pour tenter de faire tomber leur serveur. Je pousse le bouchon au maximum, je sais mais c'est le problème avec la loi, l'interprétation est au coeur de tout.

          • [^] # Re: RE

            Posté par . Évalué à 4. Dernière modification le 02/09/18 à 12:22.

            C'est cette phrase qui m’embête le plus : je poste sur Github je communique à des tiers le logiciel complet (les urls, comment générer le token JWT)

            Oui mais c'est le logiciel que tu as écrit, pas le code source du logiciel propriétaire que tu aurais désassemblé, ou obtenu d'une autre manière par des moyens d'analyse. Or il me semble comprendre que le texte porte sur ce dernier code, pas ton code original.

            Pour les questions d'interopérabilité, tu vas trop loin dans les détails techniques: si ton but est d'implémenter un traitement supplémentaire ou un logiciel supplémentaire qui interagit avec l'autre, cela devrait être de l'interopérabilité.

            Pour cet article, le logiciel que je met à disposition pourrait être exécuté dans une boucle infinie sur plusieurs threads pour tenter de faire tomber leur serveur.

            Pour n'importe quel expert dans les métiers de l'informatique, se protéger contre ce genre de problème est le b.a.ba du déploiement. Et ce que tu dis, n'importe qui peut essayer de le faire avec curl, n'importe quel langage de programmation avec une interface HTTP, pour tenter de porter préjudice à un service. D'autre part, le préjudice serait sur le service et non sur le logiciel. Pour moi ce que dit le texte, c'est que c'est interdit de déplomber ou cracker un logiciel et de l'utiliser sans payer de licence par exemple. Et si quand-bien même un loulou utilisait ton code pour causer du tort aux services que tu mentionnes, ce serait en premier lieu sa faute à lui. D'autant qu'un individu malveillant ayant les compétences techniques pour monter ce type d'attaque a probablement la capacité de mener la même analyse que toi. Je pense que tu surestimes largement ta possible responsabilité… mais peut-être que des cas précédents me contrediront!

  • # je dirais que oui c'est legal

    Posté par . Évalué à 4. Dernière modification le 01/09/18 à 20:38.

    vu que tu regarde 2 communication en clair. Le projet samba repose un peu la dessus, regarder les communications puis le retranscrire.

    mais les hébergeur possède une gâchette facile lorsqu'il ont des demande concernant le droit d'auteur.

    le compte github ne devrait avoir que ce projet en cas de clôture impromptu.

    sinon ton vpn pour capturer le réseaux c'est un truc connu ? pourrais je avoir le nom stp :).
    vu qu'il marche super bien …

    • [^] # Re: je dirais que oui c'est legal

      Posté par . Évalué à 4.

      Sans être juriste, j'abonde aussi dans ce sens. Pour ce que j'en vois, il s'agit ici d'une implémentation d'un protocole non documenté à des fins d'interopérabilité, ce qui semble être autorisé par la loi (recherche Google "législation interopérabilité").

      Plus que légal, je pense que le risque est technique puisqu'un changement de protocole cassera cette implémentation libre.

      • [^] # Re: je dirais que oui c'est legal

        Posté par (page perso) . Évalué à 0.

        Comme je l'ai indiqué dans un autre post, j'ai un doute sur le partage à des tiers de mes recherches (qui est une limite définie dans la loi).

        Ensuite je suis d'accord avec toi qu'il y a un risque technique, je le sais et ça personnellement je l'assume. Je n'ai pas tout expliqué mais dans mes 6 mois d'utilisation, jusqu'à juin il y avait une autre API mais elle était tellement pourrie (autant au niveau sécurité que cohérence des appels) que je n'aurais jamais pris le risque de la partager, depuis juin c'est beaucoup plus propre et c'est pour ça que je voulais la partager. En pratique le changement m'a pris 20 minutes (l'URL avait changée et l'appel passait de POST en GET, le résultat était le même).

        Ensuite si il faut que je la corrige 2 fois par an, ça me va. Tant que ça m'est utile, je veux bien le faire.

    • [^] # Re: je dirais que oui c'est legal

      Posté par (page perso) . Évalué à 1.

      L'outil est Packet Capture : https://play.google.com/store/apps/details?id=app.greyshirts.sslcapture&hl=en

      Par contre la communication n'est pas en clair, c'est du HTTPS mais Packet Capture me permet de le consulter quand même (c'est l'intérêt de passer par un VPN dont il maitrise les clefs). Mon téléphone m'informe d'ailleur qu'une app peut être en train d'écouter le réseau.

      Plus je lis le texte de loi, plus je pense que le fait de le faire dans mon coin est légal mais que le partage tel quel à des tiers l'est moins.

      Surtout que dans mon cas dans la doc j'explique comment créer un token JWT et que vu les données qu'il y a dedans, n'importe qui d'un peu malin pourra comprendre que la sécurité pourrait être meilleure.

      • [^] # Re: je dirais que oui c'est legal

        Posté par . Évalué à 0.

        L'outil est Packet Capture : https://play.google.com/store/apps/details?id=app.greyshirts.sslcapture&hl=en

        Il ne semble pas capable de zieuter les applications système :( (en tout cas pas moyen de choper les requêtes en claire qui pointent vers captive.apple.com)

        🇪🇺

      • [^] # Re: je dirais que oui c'est legal

        Posté par (page perso) . Évalué à 3. Dernière modification le 04/09/18 à 11:18.

        c'est l'intérêt de passer par un VPN dont il maitrise les clefs

        Heu pour le coup ça n'a rien à voir avec un VPN, il s'agit plus certainement d'un proxy https intercepteur, avec génération de certificats en live pour les domaines visités.

        Plus je lis le texte de loi, plus je pense que le fait de le faire dans mon coin est légal mais que le partage tel quel à des tiers l'est moins.

        Je crois que tu te prend la tête pour rien, il existe tant d'exemples d'outils publiés sur base de reverse enginering qu'une liste exaustive est impossible:

        Samba => ré-écriture d'un protocole propriétaire
        support fat32,vfat,ntfs,exfat, … (80% du kernel linux a vue de nez) => écritures de drivers pour systèmes de fichiers propriétaires et sous licences, de matériels, ..
        weboob,

    • [^] # Samba

      Posté par . Évalué à 2. Dernière modification le 02/09/18 à 09:11.

      c'est vieux, mais je crois me souvenir que pour éviter les risques juridiques, les équipes de Samba s'étaient organisées d'une façon spécifique :

      équipe 1 qui faisait la rétro-ingénierie du protocole

      et équipe 2 qui utilisait le résultat final/publié de l'équipe 1 pour coder un service de partage réseau,

      les 2 équipes étant "étanches" (aucun membre commun je suppose, ni aucune réunion/communication)

      Envoyé depuis mon Archlinux

      • [^] # Re: Samba

        Posté par (page perso) . Évalué à 0.

        Le principe est séduisant pour un gros projet, dans mon cas on parle de 3 à 4 heure de boulot donc on est pas dans quelque chose de comparable.

        • [^] # Re: Samba

          Posté par . Évalué à 1. Dernière modification le 02/09/18 à 16:22.

          c'est sur, se faire séparer chirurgicalement les 2 hémisphères cérébraux, c'est un peu exagéré pour se mettre à l'abri d’hypothétiques attaques juridiques… :-)

          en fait je répondais à un commentaire précédent qui se voulait rassurant sur le fait que tu avais probablement le droit de faire la rétro-ingénierie dans un but d'interopérabilité, il y a peut-être des conditions (d'où mon rappel du cas Samba)

          Envoyé depuis mon Archlinux

  • # Solution radicale

    Posté par (page perso) . Évalué à 0. Dernière modification le 02/09/18 à 10:55.

    Tu peux aussi choisir d'utiliser un autre système plus respectueux de l'utilisateur et le faire savoir au fabricant de ton système actuel. Au final, c'est l'utilisateur qui oriente le marché, acheter est un pouvoir décisionnaire, tout comme le vote.

    • [^] # Re: Solution radicale

      Posté par (page perso) . Évalué à 1.

      Je me doutais que quelqu'un allait me faire cette remarque car elle est complètement légitime et j'aurais du en parler dans mon post initial.

      En effet j'aurais du me renseigner avant sur l'accès aux données.

      Je l'avais fait l'an dernier en changeant mon Thermostat de chaudière par un Netatmo qui met à disposition une API correctement documentée (même si les données ne sont toujours accessible sur le LAN). Le reste de mes capteurs domotiques sont faits maison depuis des années donc pas de problèmes mais là j'ai été faible et j'ai cédé au capteur du commerce (pas cher) qui fait tout tout seul.

      • [^] # Re: Solution radicale

        Posté par (page perso) . Évalué à 2. Dernière modification le 02/09/18 à 11:59.

        Le marché du bio en France a une croissance de plus de 20% par an et on est obligé d'importer, la production en France ne suit pas. Ce sont les consommateurs qui ont imposé cela en achetant de plus en plus de bio et en en parlant. Lorsque la masse critique d'utilisateurs de Linux sera atteinte, les fabricants de composants seront obligés de faire du libre. Je crois beaucoup en la démarche de Purism, il répondent à une demande forte des utilisateurs pour avoir des smartphones et des ordinateurs que l'on contrôle vraiment.

  • # Coïncidence

    Posté par (page perso) . Évalué à 1. Dernière modification le 03/09/18 à 08:41.

    Justement, un article qui explique jusqu'à quel point notre acte d'achat (ou de don dans ce cas) a du pouvoir : https://framablog.org/2018/08/29/les-logiciels-libres-meurent-lentement-sans-contributions/

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.