Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

Apple refuse d'implémenter 16 API Web dans Safari en raison de préoccupations liées à la protection de la vie privée
Car elles peuvent être utilisées pour du fingerprinting

Le , par Stéphane le calme

105PARTAGES

15  0 
Cette semaine, Apple a déclaré avoir refusé de mettre en œuvre 16 nouvelles technologies Web (API Web) dans Safari, car elles constituaient une menace pour la confidentialité des utilisateurs en ouvrant de nouvelles voies pour le fingerprinting des utilisateurs.

Apple note que : « le fingerprinting implique de mesurer l'unicité de la configuration statique de l'appareil (par exemple, le matériel intégré), la configuration dynamique de l'appareil ou du navigateur (par exemple, les paramètres utilisateur ou les périphériques installés), et les données de navigation de l'utilisateur (par exemple, vérifier les sites auxquels l'utilisateur est connecté, ce qu'on appelle connexion aux fingerprinting).

« La première ligne de défense de WebKit contre le fingerprinting consiste à ne pas implémenter de fonctionnalités Web qui augmentent le fingerprinting et n’offrent aucun moyen sûr de protéger l’utilisateur ».

Voici quelques exemples de fonctionnalités qu’Apple a décidé de ne pas implémenter en partie en raison de problèmes de fingerprinting :
  1. Web Bluetooth : qui permet aux sites Web de se connecter aux appareils Bluetooth LE à proximité.
  2. API Web MIDI : qui permet aux sites Web d'énumérer, de manipuler et d'accéder aux périphériques MIDI.
  3. Magnetometer API : qui permet aux sites Web d'accéder aux données sur le champ magnétique local autour d'un utilisateur, tel que détecté par le capteur principal de l'appareil.
  4. API Web NFC : qui permet aux sites Web de communiquer avec les balises NFC via le lecteur NFC d'un appareil.
  5. Device Memory API : qui permet aux sites Web de recevoir la quantité approximative de mémoire de périphérique en gigaoctets.
  6. Network Information API : qui fournit des informations sur la connexion qu'un appareil utilise pour communiquer avec le réseau et fournit un moyen de notifier les scripts si le type de connexion change.
  7. Battery Status API : qui permet aux sites web de recevoir des informations sur l'état de la batterie de l'appareil.
  8. Web Bluetooth Scanning : qui permet aux sites Web de rechercher des appareils Bluetooth LE à proximité.
  9. Ambient Light Sensor : qui permet aux sites Web d'obtenir le niveau de lumière ou l'éclairement actuel de la lumière ambiante autour de l'appareil via les capteurs natifs de l'appareil.
  10. HDCP Policy Check extension for EME : qui permet aux sites Web de vérifier les politiques HDCP, utilisées dans la diffusion / lecture multimédia.
  11. Proximity Sensor : qui permet aux sites Web de récupérer des données sur la distance entre un appareil et un objet, telle que mesurée par un capteur de proximité.
  12. WebHID : qui permet aux sites Web de récupérer des informations sur les périphériques HID (Human Interface Device) connectés localement.
  13. Serial API : qui permet aux sites Web d'écrire et de lire des données à partir d'interfaces série, utilisées par des appareils tels que des microcontrôleurs, des imprimantes 3D et autres.
  14. Web USB : qui permet aux sites Web de communiquer avec les appareils via USB (Universal Serial Bus).
  15. Geolocation Sensor (géolocalisation en arrière-plan) : une version plus moderne de l'ancienne API de géolocalisation qui permet aux sites Web d'accéder aux données de géolocalisation.
  16. User Idle Detection : qui permet au site Web de savoir lorsqu'un utilisateur est inactif.

Apple ne ferme pas totalement la porte aux 16 API évoquées. L’éditeur les envisagera plus tard si le nécessaire est fait pour limiter le fingerprinting. Il faut noter que l'entreprise affirme avoir pris cette décision pour protéger la vie privée des personnes. La société a indiqué que ces API Web permettent aux annonceurs ainsi qu'aux sociétés d'analyse de données de développer des scripts qui font du fingerprinting.

Les spécialistes du marketing chargent et exécutent ces petits scripts dans les navigateurs de chaque utilisateur. Comme tous les utilisateurs ont des navigateurs Web et des configurations de système d'exploitation différents, les réponses mesurées par ces scripts sont distinctes selon l'appareil d'un utilisateur. Les spécialistes du marketing peuvent utiliser ces réponses uniques pour développer des identifiants distincts pour chaque utilisateur.


Apple a indiqué que sa prochaine ligne de défense consiste à supprimer les vecteurs de fingerprinting existants dans la mesure du possible, entre autres :
  • La suppression de la prise en charge des polices personnalisées. Cela signifie uniquement présenter les polices intégrées qui sont les mêmes pour tous les utilisateurs avec le même système.
  • La suppression des informations de mise à jour logicielle mineure de la chaîne d'agent utilisateur. La chaîne ne change qu'avec la version marketing de la plateforme et du navigateur.
  • La suppression de l'indicateur Ne pas suivre, ironiquement utilisé comme vecteur de fingerprinting, ajoutant une unicité aux utilisateurs qui l'avaient activé.
  • La suppression de la prise en charge de tous les plug-ins sur macOS. Les autres ports de bureau peuvent différer (les plug-ins n'ont jamais existé sur iOS).

Intelligent Tracking Prevention (ITP)

Blocage complet des cookies tiers

ITP par défaut bloque tous les cookies tiers. Il n'y a aucune exception à ce blocage. L'accès aux cookies tiers ne peut être accordé que via l'API d'accès au stockage et le correctif de compatibilité temporaire pour les fenêtres contextuelles.

Mode de verrouillage du blocage des cookies

Une fois qu'une requête d’utilisation de cookies est rejetée, toutes les redirections de cette demande sont également empêchées d'utiliser des cookies.

Référents tiers déclassés

Tous les référents tiers sont rétrogradés à leur origine par défaut. Cela s'applique aux en-têtes de référence HTTP et à document.referrer. Par exemple, si le référent complet est https://www.social.example/feed?ClickID=123456, il apparaîtra sous la forme https://www.social.example/.

HSTS tiers bloqués

HSTS, ou HTTP Strict Transport Security, ne peut être défini que par le site Web propriétaire et uniquement pour l'hôte / domaine actuel et le domaine enregistrable du site Web. En outre, HSTS n'est pas appliqué aux demandes de tiers qui ne contiennent pas de cookies et, comme tous les cookies tiers sont bloqués par défaut, il en est de même pour les HSTS tiers.

Classification comme ayant des capacités de suivi intersite

Au-delà du blocage généralisé des cookies tiers et des rétrogradations de référents tiers, ITP collecte des statistiques sur les charges de ressources et les associe aux modèles connus de suivi intersite. Si un domaine enregistrable correspond à au moins un tel modèle, il est classé comme ayant des capacités de suivi intersite.

Cache partitionné vérifié

Lorsqu'une entrée de cache partitionnée est créée pour un domaine classé par ITP comme ayant des capacités de suivi intersite, l'entrée est signalée pour vérification. Après sept jours, s'il y a un cache pour une telle entrée signalée, WebKit agira comme s'il n'avait jamais vu cette ressource et la rechargerait. La nouvelle réponse est ensuite comparée à la réponse mise en cache et si elles correspondent de la manière dont nous nous soucions pour des raisons de confidentialité, l'indicateur de vérification est effacé et l'entrée de cache est à partir de ce moment considérée comme légitime. Toutefois, si la nouvelle réponse ne correspond pas à l'entrée de cache, l'ancienne entrée est supprimée et une nouvelle est créée avec l'indicateur de vérification défini, et le processus de vérification recommence.

Détection du suivi intersite via la décoration de lien

Certains traceurs ajoutent des « ID de clic » comme paramètres d'URL dans les liens et les récupèrent via JavaScript sur le site Web de destination du lien. Ensuite, ils stockent les ID de clic dans l'un des formulaires de stockage disponibles. De cette façon, ils peuvent établir une identité d'utilisateur sur les sites Web. C'est ce qu'on appelle le suivi intersite via la décoration des liens.

ITP détecte une telle décoration de lien et limite l'expiration des cookies créés en JavaScript sur la page Web de destination à 24 heures.

Source : Apple

Et vous ?

Que pensez-vous de cette décision d'Apple ?
Quel navigateur Web utilisez-vous sur mobile ? Sur desktop ?
Quels sont les critères qui peuvent vous faire passer d'un navigateur à l'autre ?
Faites-vous systématiquement appel aux fonctionnalités de protection de la vie privée ou y aurait-il des situations/sites spécifiques (par exemple consultation de votre banque en ligne) qui vous conduise à les activer ?
Qu'en est-il des modes comme Incognito ?

Une erreur dans cette actualité ? Signalez-le nous !

Avatar de Chal92
Membre du Club https://www.developpez.com
Le 01/07/2020 à 23:15
Effectivement tout ce qui est utilisable pour scanner le hardware peut être vu comme du fingerprinting...

C'est à mon avis surtout, vu les API, c'est aussi un moyen d'éviter que les navigateurs deviennent des "OS" à part entière...
Cela pour obliger le développeur à faire une véritable application... déployable dans le monde Apple via leur store...
1  0 
Avatar de Doksuri
Membre expert https://www.developpez.com
Le 02/07/2020 à 5:24
quid du canvas ? browserleaks.com/canvas

autant il y en a dans la liste que je comprend... autant "Battery Status API" ...
=> si on bloque la batterie, il faut tout bloquer hein...
0  0 
Avatar de air-dex
Membre expert https://www.developpez.com
Le 02/07/2020 à 13:39
Citation Envoyé par Chal92 Voir le message
Effectivement tout ce qui est utilisable pour scanner le hardware peut être vu comme du fingerprinting...

C'est à mon avis surtout, vu les API, c'est aussi un moyen d'éviter que les navigateurs deviennent des "OS" à part entière...
Cela pour obliger le développeur à faire une véritable application... déployable dans le monde Apple via leur store...
Avec la commission pour l'App Store qui va bien.

Hormis ça les "Browser OS" nous guettent à l'avenir, genre en Web 4.0 ou en Web 5.0 quand WASM sera mature et qu'il permettra à tous de se passer du trio HTML-CSS-JS. Mais nous n'en sommes pas encore là.
0  0 
Avatar de Ehma
Membre averti https://www.developpez.com
Le 05/07/2020 à 9:56
Citation Envoyé par Chal92 Voir le message
Effectivement tout ce qui est utilisable pour scanner le hardware peut être vu comme du fingerprinting...

C'est à mon avis surtout, vu les API, c'est aussi un moyen d'éviter que les navigateurs deviennent des "OS" à part entière...
Cela pour obliger le développeur à faire une véritable application... déployable dans le monde Apple via leur store...
Euh.... Firefox et Chrome alors ? On peut aussi les installer sur Mac et utiliser un WebOs, cette raison devient donc caduque.

Je reconnais la mesquinerie d'Apple, mais ils ne sont pas cons non plus.
0  0 
Avatar de CoderInTheDark
Membre chevronné https://www.developpez.com
Le 22/07/2020 à 20:13
Le détecteur de lumière permet de faire des applications pour les non-voyants complet pour savoir si la lumière est allumée.
Par exemple si je me cogne dans un interupteur la nuit et qu'il n'y a pas de repère c'est bien pratique
0  0