U+039b
est avec nous depuis le 24 novembre 2017 ❤️
Oups.
On dirait que quelqu'un ici aime garder ses petits secrets, comme si de par hasard il y avait quelque chose à cacher...
Désolé, ô lectrice de passage, cher lecteur égaré, pas de révélation sensationnelle pour le moment sur ce profil.
Repassez plus tard ?
6 commentaires
L’effet du RGPD sur les trackers des applications Android, selon Exodus Privacy
Le 24/11/2018Le 27/11/2018 à 14h 04
εxodus n’exécute plus les applications durant 80 secondes pour les raisons suivantes :
En bref, εxodus ne fait plus d’analyse d’activités réseau.
Le 27/11/2018 à 13h 55
Effectivement, la décompilation fait partie des méthodes permettant de déterminer si un traqueur est inactif. La décompilation n’est pas une solution légale pour Exodus Privacy. L’autre solution permettant de constater l’activité d’un traqueur est d’analyser les communications réseau entre une applications et des serveurs distants, c’est l’un des objectifs du projet https://piranhalysis.github.io/.
Il est important de noter que certaines applications embarquent certains traqueurs qui seront activés ou non en fonction de campagnes marketing. Ainsi, aujourd’hui un traqueur peut être inactif et être activé demain.
La CNIL s’attaque encore à la publicité mobile, cette fois avec Vectaury
Le 09/11/2018Le 10/11/2018 à 17h 47
La réinitialisation de l’identifiant publicitaire (advertising id sous Android, idfa sous iOS) est bien souvent contourné par les trackers publicitaires de la façon suivante. La première fois qu’un tracker est lancé sur un mobile (lors du premier lancement d’une application qui le contient), ce tracker va générer un identifiant unique (impossible à modifier sans faire un reset d’usine) stocker sur le mobile. Ensuite, le tracker va envoyer systématiquement au serveur auquel il est associé : l’identifiant publicitaire + l’identifiant généré.
Ainsi, Facebook par exemple, connaît la liste de tous les identifiants publicitaires d’un mobile ainsi que les dates auxquelles l’identifiant publicitaire a été changé.
Avec PiRogue, capturer le trafic HTTP(S) d’un smartphone devient plus simple
Le 27/03/2018Le 28/03/2018 à 15h 10
Sur le PiRogue, il est tout à fait possible d’utiliser Wireshark en plus de MITMproxy. Ce duo permet d’avoir l’intégralité du trafic réseau + le trafic HTTPS en clair (lorsque c’est techniquement possible). Il est également possible de décoder, à la volée les messages protobuf. C’est que fait, entre autre, ce plugin MITMproxy :https://github.com/U039b/PiRogue/tree/master/mitmproxy
Et typiquement, le HotSpoot fait exactement ce que tu expliques : garder les IP de destinations + résolution DNS. Le projet est rapidement présenté ici :https://esther.codes/hotspoot-a-privacy-pot/
Enfin, tout dépend de l’objectif. Ici, l’objectif premier est d’analyser les messages envoyés par des applications Android.
Le 28/03/2018 à 14h 17
1Mo dans l’IoT c’est énorme ! Dans l’IoT, la RAM fait quelques centaines de ko et la flash (là où on stocke le programme + les données) fait quelques Mo.
Le 27/03/2018 à 19h 13
Bon nombre d’objets connectés ne font aucune vérification de certificat pour des raisons de coût. En effet, embarquer les certificats racines représente un gros volume de données et donc un espace mémoire plus grand et donc un équipement plus coûteux.