Cela dit (et je dis ça de tête) il me semble que le filtre anti-malware de google marche sur le même principe que haveibeenpwned :
- la donnée (url, email, password) est hachée côté client : hash(email)=d5654fcf96b353d44ead/690f6d11ae5a
- le client récupère auprès du serveur un block de données à partir d'un préfixe du hash : GET /pwned/d5654fcf96b353d44ead.
- le serveur renvoie tous les hashs ayant ce préfixe : d5654fcf96b353d44ead/051d01771f90 ... d5654fcf96b353d44ead/efa897518051 (bien sûr on peut s'épargner de rappeler le préfixe dans la réponse)
- le client vérifie si son hash est dans cette liste : si oui, c'est positif, sinon, c'est négatif.
Le serveur n'est pas vraiment moyen de savoir quelle était la donnée d'origine car les hashs n'ont aucun lien entre eux.
Le compromis se fait sur la longueur du préfixe : plus il est court plus il faut brasser de la donnée, plus il est long plus il y a de risque que la liste soit courte (cas pire : 1) et que le serveur devine quel hash a été demandé réellement et de remonte à la donnée d'origine.
Google is not not evil depuis longtemps mais ils ont quand même besoin que le web "fonctionne" correctement pour faire leur business. Donc tous leurs services n'ont pas forcément immédiatement un usage dans le profiling de l'utilisateur. Mais la méfiance est de mise.
# bloomen ?
Posté par steph1978 . Évalué à 3 (+1/-0). Dernière modification le 10 juin 2025 à 23:50.
Et donc l'extension envoie toutes les URL visitées vers les serveurs de next ou le bloom filter est récupéré par l'extension et utilisé localement ?
[^] # Re: bloomen ?
Posté par Fernando . Évalué à 2 (+2/-0).
Liste locale obfusquée par un filtre de Bloom.
Ce qui remonte chez Next, c'est les sites que tu signales.
Next c'est pas Google !
[^] # Re: bloomen ?
Posté par steph1978 . Évalué à 4 (+2/-0).
Oui, ma crainte était bien là en effet.
Cela dit (et je dis ça de tête) il me semble que le filtre anti-malware de google marche sur le même principe que haveibeenpwned :
- la donnée (url, email, password) est hachée côté client :
hash(email)=d5654fcf96b353d44ead/690f6d11ae5a- le client récupère auprès du serveur un block de données à partir d'un préfixe du hash :
GET /pwned/d5654fcf96b353d44ead.- le serveur renvoie tous les hashs ayant ce préfixe :
d5654fcf96b353d44ead/051d01771f90 ... d5654fcf96b353d44ead/efa897518051(bien sûr on peut s'épargner de rappeler le préfixe dans la réponse)- le client vérifie si son hash est dans cette liste : si oui, c'est positif, sinon, c'est négatif.
Le serveur n'est pas vraiment moyen de savoir quelle était la donnée d'origine car les hashs n'ont aucun lien entre eux.
Le compromis se fait sur la longueur du préfixe : plus il est court plus il faut brasser de la donnée, plus il est long plus il y a de risque que la liste soit courte (cas pire : 1) et que le serveur devine quel hash a été demandé réellement et de remonte à la donnée d'origine.
Google is not not evil depuis longtemps mais ils ont quand même besoin que le web "fonctionne" correctement pour faire leur business. Donc tous leurs services n'ont pas forcément immédiatement un usage dans le profiling de l'utilisateur. Mais la méfiance est de mise.
Envoyer un commentaire
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.