Quels sont les détails techniques de ce qui se passe ici ?

Lorsqu'un utilisateur reçoit un email chez son fournisseur de messagerie, l'une des applications Apple Mail précharge le message sans que l'utilisateur interagisse avec lui. Ce préchargement ne se produit souvent pas immédiatement et se produit principalement lorsque le téléphone de l'utilisateur est branché et connecté au wifi. Une fois le message préchargé, le client de messagerie précharge et met en cache toutes les images en utilisant le service proxy d'Apple. Ce préchargement des images déclenche des pixels d'image qui s'activent, entraînant une fausse ouverture.

Quelle est la différence entre quelque chose ouvert derrière un proxy et préchargé ?

Descriptions pour les différents types d'ouvertures dans ce nouveau monde :

“Ouvertures régulières”: Ce sont des emails ouverts par votre destinataire prévu, et l'ouverture transmet avec précision à la fois qu'ils ont ouvert le courrier, ainsi que l'appareil qu'ils ont utilisé pour le visualiser et l'IP à partir de laquelle ils y ont accédé.

Ouvertures via proxy : Ce sont des emails où l'ouverture de l'image se produit via un proxy de confidentialité. L'ouverture a été initiée par votre destinataire, mais le dispositif et les informations IP/emplacement associées à l'ouverture vous sont cachés.

Ouvertures préchargées : Ce sont un nouveau type d'ouvertures où l'appareil de l'utilisateur ouvre l'email, récupère (et met en cache) l'image sans qu'il effectue une action. Pour les ouvertures préchargées, il est impossible de dire si le destinataire a réellement consulté votre courrier ou si son appareil l'a simplement récupéré et il ne l'a jamais regardé.

Avec toutes ces classifications, il est important de savoir qu'une petite portion d'emails (indépendamment des types ci-dessus) est ouverte et inspectée par les services de sécurité et peut déclencher des « fausses ouvertures ». Cela n'est pas courant, mais lorsque nous disons qu'une ouverture peut être « fiable », nous voulons vraiment dire qu'elle peut être considérée comme de haute confiance.

Un utilisateur doit-il utiliser activement Mail.app pour que l'email soit impacté par MPP ?

Considérons un scénario courant : un utilisateur configure son compte email dans Apple Mail.app, l'application mobile Gmail, et utilise également régulièrement l'application web Gmail. Même si l'utilisateur ouvre rarement (ou jamais) son email dans Apple Mail.app, la protection de la confidentialité des emails préchargera toujours les images car le compte email a été configuré dans Mail.app d'Apple. Dans ce cas, un expéditeur verra des ouvertures à partir du proxy d'image d'Apple et du proxy d'image de Gmail.

Apple précharge-t-il maintenant toutes les images ?

Cela se produit uniquement lorsque l'utilisateur est connecté au wifi et que son appareil est branché.

À quelle vitesse se produit le préchargement ?

Selon nos amis de Movable Ink, 85 % des utilisateurs d'Apple Mail qui ont cliqué sur un lien ont vu le contenu rendu moins d'une minute avant l'ouverture.

Dans l'ensemble, étant donné la manière dont MPP précharge les images, nous observons des événements d'ouverture se produire entre quelques minutes et plusieurs heures plus tard. Cependant, étant donné la limitation selon laquelle MPP ne précharge que lorsque l'appareil est connecté au wifi et branché, l'impact réel sur l'optimisation du temps d'ouverture a été plus limité que ce que l'on craignait initialement. Il sera important de continuer à surveiller cela car cela pourrait changer à tout moment dans le futur.

MPP affectera-t-il les pixels de suivi web qui suivent le comportement en ligne ?

À moins que l'utilisateur ait bloqué le suivi via son navigateur, le suivi web fonctionnera comme d'habitude. MPP n'affectera pas le suivi web.

Comment identifier les destinataires qui ont activé MPP ? Que devrais-je rechercher ?

Actuellement, la chaîne de l'agent utilisateur que les serveurs proxy d'Apple envoient lors de la demande des images est Mozilla/5.0. Quant à la manière dont Bird gérera cela spécifiquement, du côté de l'envoi, nous ajouterons un champ aux Webhooks et à l'API des événements pour indiquer qu'une ouverture a été préchargée.

Ces ouvertures seront toujours incluses car elles peuvent être un signal précieux qu'une adresse e-mail est valide. (Spécifiquement, elles indiquent que l'adresse e-mail est liée à un appareil Apple allumé, ce qui est presque certainement associé à un être humain “réel”.) Néanmoins, le nouveau drapeau facilitera la distinction que ces ouvertures sont différentes des événements d'engagement réel et devraient être traitées différemment. Cette capacité sera mise en place dans quelques semaines. Nous incorporerons également cette distinction dans notre interface de rapport analytique et notre API de métriques au 4e trimestre.

Quelle chaîne d'agent utilisateur m'indique que MPP est activé ?

Selon Google, une chaîne d'agent utilisateur d'un navigateur aide à identifier quel navigateur est utilisé, quelle version, et sur quel système d'exploitation. Actuellement, la chaîne d'agent utilisateur que les serveurs proxy d'Apple envoient lors de la demande des images est Mozilla/5.0. Bien qu'il n'y ait aucune indication directe que cela appartienne aux proxies d'image d'Apple, nos tests indiquent que la chaîne identifie avec précision les requêtes provenant des proxies d'images d'Apple. Cela pourrait permettre aux expéditeurs de filtrer les ouvertures provenant des proxies d'Apple de leurs mesures ou de les segmenter différemment. On ignore si Apple changera cela à l'avenir. Ainsi, il sera important pour les expéditeurs de surveiller les changements apportés à cette chaîne et de s'adapter en conséquence.

Apple masque-t-il les adresses IP ?

Les IPs de suivi des clics ne seront obscurcies que si les gens optent pour Apple Private Relay (un produit distinct et faisant partie d’iCloud+, également seulement publié en bêta – ce qui a été une rétractation d'Apple).

Les clics uniques resteront précis de toute façon car Bird suit les clics de manière unique par email envoyé (chaque lien dans chaque email à chaque destinataire est identifié de manière unique).

Le MPP fonctionne-t-il toujours si le message atterrit dans le dossier spam ?

Jusqu'à présent, nous n'avons pas observé de préchargement d'images par MPP pour les emails livrés dans le dossier spam.

Le proxy de messagerie Apple respectera-t-il les en-têtes de mise en cache des images ?

Non, MPP ne respecte pas les en-têtes de cache des images. Les images sont mises en cache pendant une période de 2 à 3 jours. Si aucun en-tête de cache d'image n'est appliqué, les images semblent être mises en cache indéfiniment.

Apple signalera-t-il plusieurs ouvertures s'ils préchargent l'email puis l'utilisateur l'ouvre effectivement ?

Non. L'image sera mise en cache pendant un certain temps et les ouvertures supplémentaires pendant cette période ne seront pas signalées.

Apple applique-t-il la Protection de la Confidentialité des Messages uniquement au pixel classique de 1x1, ou bloque-t-il le chargement de toutes les images (à la Outlook vers 2005) ? Comme beaucoup d'autres contenus seront des images, existe-t-il une solution pour contourner cela en ajoutant des données de suivi à d'autres contenus de l'email ?

Apple ne bloque pas les pixels mais ses appareils préchargent et mettent en cache agressivement toutes les images des emails. Vous obtiendrez donc une ouverture même si l'utilisateur n'a pas réellement ouvert le mail.

Est-il sûr de supposer que les adresses emails rejetées continueront de signaler des rebonds et ne signaleront pas d'ouvertures ?

Oui.

Nous sommes préoccupés par l'impact sur nos contrôles de piège à spam (par exemple, les pièges à spam rapportant l'engagement). Pouvez-vous partager une perspective sur le potentiel des pièges à spam vierges à signaler les ouvertures compte tenu de la réponse à la question ci-dessus (c'est-à-dire que l'opérateur de piège doit-il synchroniser leur boîte aux lettres surveillée dans l'application iOS pour qu'une ouverture soit rapportée) ?

Oui, un opérateur de piège devrait avoir un client Apple Mail attaché à la boîte de réception en question, ce qui semble hautement improbable. Un grand opérateur de piège nous a dit qu'Apple n'est pas impliqué dans leur processus de surveillance. Le plus grand risque dans l'industrie est que les gens abandonnent les non-engagés comme moyen de filtrer leurs listes.

J'ai entendu des rumeurs selon lesquelles Apple ne précharge que lorsque le téléphone est connecté au wifi et branché. Voyez-vous cela aussi ?

Nous avons confirmé nos premières théories selon lesquelles le préchargement ne se produit que lorsque l'utilisateur est connecté au wifi et que son téléphone est branché. À l'heure actuelle, il n'y a aucune indication qu'Apple envisage de modifier ce comportement.

Existe-t-il un hack technique ou une solution de contournement pour surmonter les impacts de MPP ?

L'histoire nous a montré que toute solution de contournement technique pour contourner les fonctionnalités liées à la confidentialité est souvent de courte durée, nuit à votre réputation, et est rapidement fermée. Même si les premiers tests indiquent qu'il existe quelques solutions de contournement pour le préchargement des images d'Apple, nous pensons que les expéditeurs ne devraient pas compter sur ou utiliser ces solutions.

Les limitations suivantes de la Protection de la Confidentialité des Messages ont été observées lors des tests bêta précoces : Les utilisateurs de la Protection de la Confidentialité des Messages ont explicitement exprimé qu'ils ne veulent pas que les fournisseurs les suivent via les ouvertures d'emails. Utiliser ce type de solutions de contournement trahit cette confiance des utilisateurs, est une mauvaise pratique, et nuit finalement à la réputation de votre marque.

• Le préchargement se produit principalement lorsque l'utilisateur est sur wifi et branché. Les premiers tests indiquent que le préchargement ne se produit que lorsque l'utilisateur est connecté au wifi et que son téléphone est branché. Ce comportement est un peu inattendu et sera intéressant à observer à mesure qu'Apple passe à la disponibilité générale d'iOS15. En pratique, cela signifie que les événements d'ouverture sont encore plus aléatoires qu'on ne le pensait initialement. Il semble que des événements d'ouverture puissent survenir lorsque l'utilisateur ouvre effectivement le message, ou lorsque l'utilisateur n'a pas ouvert le message mais qu'il est en wifi et que le téléphone est en charge - ou une autre combinaison d'événements qu'Apple décide. Tout cela indique la même conclusion : le suivi des ouvertures sur les appareils Apple ne peut pas être fiable.

• Les événements d'ouverture initiée par l'utilisateur sont déclenchés lorsque l'image est chargée via CSS externe.

• Les tests indiquent également que les événements d'ouverture initiés par l'utilisateur sont déclenchés lorsque l'image est chargée via un fichier CSS externe. Bien qu'à première vue cela puisse sembler positif, nous déconseillons fortement cette approche. Il est très probable qu'Apple, comme HEY l'a déjà fait, ferme cette brèche. Mais il existe une raison plus fondamentale de ne pas utiliser cette approche : les utilisateurs qui ont opté pour des pratiques de confidentialité explicites ne veulent pas être suivis de cette manière.