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 fcartegnie . Évalué à -1.
https://www.legifrance.gouv.fr/affichCodeArticle.do?cidTexte=LEGITEXT000006069414&idArticle=LEGIARTI000006278920&dateTexte=&categorieLien=cid
[^] # Re: RE
Posté par vlad59 (site web personnel) . Évalué à 2.
Si je suis le texte de loi :
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 Michaël (site web personnel) . Évalué à 4. Dernière modification le 02 septembre 2018 à 10:32.
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 vlad59 (site web personnel) . Évalué à 2.
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
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 Michaël (site web personnel) . Évalué à 4. Dernière modification le 02 septembre 2018 à 12:22.
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 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 Anonyme . Évalué à 4. Dernière modification le 01 septembre 2018 à 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 nigaiden . É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 vlad59 (site web personnel) . É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 vlad59 (site web personnel) . É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 voxdemonix . Évalué à 0.
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 -=[ silmaril ]=- (site web personnel) . Évalué à 3. Dernière modification le 04 septembre 2018 à 11:18.
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.
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 pralines . Évalué à 2. Dernière modification le 02 septembre 2018 à 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 vlad59 (site web personnel) . É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 pralines . Évalué à 1. Dernière modification le 02 septembre 2018 à 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 NumOpen . Évalué à 0. Dernière modification le 02 septembre 2018 à 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 vlad59 (site web personnel) . É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 NumOpen . Évalué à 2. Dernière modification le 02 septembre 2018 à 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 NumOpen . Évalué à 1. Dernière modification le 03 septembre 2018 à 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 à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.