Suite de Google ordered to turn over foreign emails. On est en appel, cette fois-ci.

Pour le cas de Microsoft cité en exemple, le juge souligne que le stockage des données était lié à l’emplacement de l’utilisateur, alors que pour Google, la situation est bien différente. […]

« Google dispose d'un système distribué où les algorithmes déterminent la façon dont il envoie et stocke les données - en paquets ou parties de composant - pour des raisons d'efficacité globale du réseau », explique le juge. Laurel Beeler estime donc que nous nous trouvons dans une situation où le contenu recherché est couvert par le mandat même s’il est stocké en dehors des États-Unis.

Le juge avance également que Google a une équipe juridique aux États-Unis qui produit des informations en réponse à des mandats de perquisition et à d'autres demandes de procédure légale. Et c’est seulement cette équipe qui est autorisée à accéder et à produire le contenu des communications des utilisateurs ; ce qui veut dire que les informations demandées ne peuvent être obtenues autrement.

« Le tribunal ordonne donc à Google de produire tout contenu (demandé dans le mandat de perquisition) qui est récupérable à partir des États-Unis, quel que soit l'emplacement réel des données ».

http://www.silicon.fr/mails-stockes-hors-etats-unis-google-somme-collaborer-173081.html :

[…] Pour l’heure, le jugement de la Cour de Californie semble protéger de la curiosité du gouvernement américain les données qui seraient stockées ailleurs dans le monde, dans le cadre d’offres strictement segmentées en régions, un des critères soulevés par la juge Beeler pour souligner les différences entre l’affaire de Microsoft et celle de Google.

StreetComplete est un logiciel libre (licence GNU GPL v3) pour Android (et dérivés) en cours de développement mais déjà fonctionnel et disponible depuis F-Droid. Cette application permet de contribuer à OpenStreetMap de manière ludique en remplissant des quêtes en se promenant dans la rue ; les contributeurs du Libre ayant le droit d’être aussi ridicules que les chasseurs de Pokémons en regardant leur écran de téléphone plutôt que leur environnement.

Si vous ne savez pas comment contribuer à OpenStreetMap, cette application semble être une bonne façon de commencer : son utilisation est simple, même pour quelqu'un n'ayant jamais contribué, et on se retrouve vite à faire des centaines de contributions en se promenant dans des endroits insuffisamment référencés […]

Aujourd'hui, on me fait remarquer que la règle ip6tables suivante ne fonctionne pas (elle ne laisse pas passer les paquets que l'on pense avoir désignés) : ip6tables -A INPUT -p ipv6-icmp -m icmp6 --icmpv6-type 134 -m state --state NEW -m comment --comment RA -j ACCEPT. Évidemment, aucune erreur n'apparaît quand on pousse cette règle et il n'y a rien dans les logs lorsqu'elle est censée être activée par un paquet reçu. La même règle sans état (pas de -m state --state NEW) fonctionne.

En regardant une partie du code source (http://lxr.free-electrons.com/source/net/ipv6/netfilter/nf_conntrack_proto_icmpv6.c ), on constate que :

• Seuls les messages ICMP Echo Request et Node Information Query peuvent avoir un état NEW (lignes 120 et suivantes). En conséquence, seuls les messages ICMP Echo Reply et Node Information Reply auront un état ESTABLISHED (lignes 74 et suivantes). Donc, on peut les désigner avec une règle ip6tables comportant l'instruction -m state --state NEW,ESTABLISHED.
  
  
• Les messages ICMP Router Solicitation/Advertisement, Neighbor Solicitation/Advertisement, Multicast Listener Query/Report/Done, Multicast Listener Report v2 n'ont pas d'état dans Netfilter (lignes 63 et 225), ils ne sont pas suivis. Une règle ip6tables les concernant et comportant -m state --state XXXX ne capturera donc aucun paquet.
  
  
• J'imagine que les autres messages ICMP à but informatif comme ceux associés à la mobilité IPv6 sont gérés par les modules adéquats…
  
  
• Les autres messages ICMP (exemples : Destination Unreachable, Packet Too Big, Time Exceeded, Parameter Problem, etc.) sont des messages d'erreur dixit les RFC. Ils doivent avoir un type compris entre 1 et 127 (lignes 232-233) et ils doivent être liés (relatifs) à une connexion (TCP, UDP, SCTP, etc.) en cours suivie par Netfilter (lignes 158 et 179). Donc, on peut les désigner avec une règle ip6tables comportant l'instruction -m state --state RELATED.