Wat zijn de technische details van wat hier gebeurt?

Wanneer een gebruiker een e-mail ontvangt bij zijn postbusprovider, haalt een van de Apple Mail-apps het bericht vooraf op zonder dat de gebruiker interactie heeft met het bericht. Dit vooraf ophalen gebeurt vaak niet onmiddellijk en gebeurt voornamelijk wanneer de telefoon van de gebruiker is aangesloten en op wifi werkt. Zodra het bericht vooraf is opgehaald, laadt de e-mailclient alle afbeeldingen vooraf op en plaatst deze in de cache met behulp van de proxyservice van Apple. Dit vooraf laden van de afbeeldingen zorgt ervoor dat afbeeldingspixels worden geactiveerd, wat resulteert in een valse opening.

Wat is het verschil tussen iets dat achter een proxy wordt geopend en pre-fetched?

Beschrijvingen van de verschillende soorten openingen in deze nieuwe wereld:

"Normale' Opent: These are emails that are opened by your intended recipient, and the open accurately conveys both that they opened the mail, as well as the device they used to view the mail and the IP that they accessed it from.

Gevolmachtigd opent: These are emails where the image open happens through a privacy proxy. De open was still initiated by your recipient, but the device and the IP/location information associated with the open are hidden from you.

Vooraf ingestelde openingen: These are a new and special kind of open where the user's device opens the email and fetches (and caches) the image without them taking any action. For pre-fetched opens, it is impossible to tell if the actual recipient truly looked at your mail or if their device just pulled it and they never looked at it.

Bij al deze classificaties is het belangrijk om te weten dat een klein deel van de e-mails (onafhankelijk van de bovenstaande typen) wordt geopend door en geïnspecteerd door beveiligingsdiensten en "valse openingen" kan veroorzaken. Dit komt niet vaak voor, maar als we zeggen dat een opening "te vertrouwen" is, bedoelen we echt dat er met een hoge mate van betrouwbaarheid op kan worden vertrouwd.

Moet een gebruiker Mail.app actief gebruiken voor e-mail om beïnvloed te worden door MPP?

Laten we een veelvoorkomend scenario bekijken: een gebruiker stelt zijn e-mailaccount in op Apple Mail.app, de mobiele app van Gmail en maakt ook regelmatig gebruik van de Gmail webapp. Zelfs als de gebruiker zijn e-mail zelden (of nooit) opent in Apple Mail.app, zal Mail Privacy Protection toch afbeeldingen vooraf laden omdat het e-mailaccount is ingesteld in Apple's Mail.app. In dit geval ziet een afzender opens van Apple's image proxy en Gmail's image proxy.

Haalt Apple nu alle afbeeldingen vooraf op?

Dit is alleen zichtbaar als de gebruiker wifi gebruikt en zijn apparaat is aangesloten.

Hoe snel gebeurt het pre-fetchen?

Volgens onze vrienden van Movable Ink zag 85% van de Apple Mail-gebruikers die op een link hebben geklikt, de inhoud minder dan een minuut voor opening weergegeven.

Over het algemeen zien we, gezien de manier waarop MPP vooraf beelden ophaalt, open events die enkele minuten tot uren later plaatsvinden. Echter, gezien de beperking dat MPP alleen vooraf beelden ophaalt als er wifi is en het apparaat is aangesloten, is de werkelijke impact op de optimalisatie van de open tijd beperkter dan aanvankelijk werd gevreesd. Het is belangrijk om dit in de gaten te blijven houden, omdat het in de toekomst op elk moment kan veranderen.

Heeft MPP invloed op webtrackingpixels die webgedrag bijhouden?

Tenzij de gebruiker tracking via zijn browser heeft geblokkeerd, werkt webtracking zoals normaal. MPP heeft geen invloed op webtracking.

Hoe kunnen we bepalen welke ontvangers MPP hebben ingeschakeld? Waar moet ik naar zoeken?

Op dit moment is de user-agent string die Apple's proxyservers versturen bij het opvragen van afbeeldingen Mozilla/5.0. Wat betreft hoe Bird hier specifiek mee om zal gaan, aan de verzendkant zullen we een veld toevoegen aan zowel Webhooks als de Events API om aan te geven wanneer een opening vooraf is ingesteld.

Deze opens worden nog steeds opgenomen omdat ze een waardevol signaal kunnen zijn dat een e-mailadres geldig is. (Ze geven met name aan dat het e-mailadres is gekoppeld aan een ingeschakeld Apple apparaat, dus het is vrijwel zeker gekoppeld aan een "echt" mens). Met de nieuwe vlag is het echter eenvoudig om te zien dat deze opens anders zijn dan echte engagementgebeurtenissen en anders moeten worden behandeld. Deze mogelijkheid komt over een paar weken. We zullen dit onderscheid ook opnemen in onze Analytics Report UI en Metrics API in Q4.

Welke user-agent string vertelt me dat MPP is ingeschakeld?

Volgens Google helpt de user-agent string van een browser te identificeren welke browser wordt gebruikt, welke versie, en op welk besturingssysteem. Momenteel is de user-agent string die de proxyservers van Apple verzenden bij het opvragen van afbeeldingen Mozilla/5.0. Hoewel er geen directe aanwijzing is dat dit hoort bij de image proxies van Apple, blijkt uit onze tests dat de string nauwkeurig verzoeken identificeert die afkomstig zijn van de image proxies van Apple. Dit kan verzenders dan weer in staat stellen Apple proxy opens uit hun statistieken te filteren of anders te segmenteren. Het is niet bekend of Apple dit in de toekomst zal veranderen. Daarom is het belangrijk dat verzenders in de gaten houden of deze string verandert en zich daaraan aanpassen.

Camoufleert Apple IP-adressen?

IP's voor het volgen van klikken worden alleen verborgen als mensen kiezen voor Apple Private Relay (een apart product en onderdeel van iCloud+, dat ook alleen in bèta wordt uitgebracht - dat was een stap terug van Apple).

Unieke klikken zullen hoe dan ook accuraat zijn, omdat Bird klikken uniek bijhoudt per verzonden e-mail (elke link in elke e-mail naar elke ontvanger wordt uniek geïdentificeerd).

Werkt MPP nog steeds als het bericht in de spammap terechtkomt?

Tot nu toe hebben we nog niet gezien dat MPP afbeeldingen vooraf afhaalt voor e-mails die in de spammap terechtkomen.

Zal Apple Mail proxy de image caching headers respecteren?

Nee, MPP respecteert geen cache-headers voor afbeeldingen. Afbeeldingen worden in de cache opgeslagen voor een periode van 2-3 dagen. Als er geen image cache header wordt toegepast, lijken afbeeldingen voor onbepaalde tijd in de cache te staan.

Zal Apple meerdere opens rapporteren als ze de e-mail vooraf ophalen en de gebruiker deze vervolgens opent?

Nee. De afbeelding wordt voor een bepaalde tijd in de cache geplaatst en extra openingen binnen dat venster worden niet gerapporteerd.

Past Apple de Mail Privacy Protection alleen toe op de klassieke 1x1 pixel, of blokkeren ze het laden van alle afbeeldingen (à la Outlook circa 2005)? En aangezien veel andere inhoud uit afbeeldingen zal bestaan, is er een manier om dit te omzeilen door trackinggegevens toe te voegen aan de andere inhoud in de e-mail?

Apple blokkeert geen pixels, maar laat hun apparaten alle afbeeldingen in e-mails op een agressieve manier vooraf ophalen en in de cache opslaan. Je krijgt dus een open, ongeacht of de gebruiker de e-mail daadwerkelijk heeft geopend.

Is het veilig om aan te nemen dat bounced e-mailadressen bounces blijven melden en geen opens terugmelden?

Ja.

We maken ons zorgen over de impact op onze spamtrap controles (bijvoorbeeld spamtraps die betrokkenheid rapporteren). Is er een perspectief dat u kunt delen over het potentieel voor ongerepte spamtraps om opens te melden, gezien het antwoord op de bovenstaande vraag (d.w.z. zou de spamtrap operator zijn gecontroleerde mailbox in de iOS app moeten synchroniseren om een open te kunnen melden)?

Ja, een exploitant van een val zou een Apple Mail-client gekoppeld moeten hebben aan de inbox in kwestie, wat hoogst onwaarschijnlijk lijkt. Een grote exploitant van valstrikken vertelde ons dat Apple niet betrokken is bij hun controleproces. Het grotere risico in de industrie is dat mensen afzien van het niet gebruiken van e-mail als een manier om hun lijsten te filteren.

Ik heb geruchten gehoord dat Apple alleen pre-fetcht als de telefoon op wifi staat en is aangesloten. Zie jij dit ook?

We hebben bevestiging gezien voor onze vroege theorieën dat preloaden alleen gebeurt als de gebruiker wifi gebruikt en de telefoon is aangesloten op het lichtnet. Tot nu toe zijn er geen aanwijzingen dat Apple van plan is om dit gedrag te veranderen.

Is er een technische hack of workaround om de gevolgen van MPP te omzeilen?

De geschiedenis heeft ons geleerd dat technische omwegen om privacy-gerelateerde functionaliteit te omzeilen vaak van korte duur zijn, je reputatie schaden en snel worden gesloten. Ook al blijkt uit de eerste tests dat er een aantal omwegen zijn om het vooraf laden van afbeeldingen door Apple te omzeilen, zijn wij van mening dat verzenders niet op deze omwegen moeten vertrouwen of ze moeten gebruiken.

Bij de eerste bètatests zijn de volgende beperkingen van de Mail Privacy Protection geconstateerd: into Mail Privacy Protection have explicitly said they do not want providers tracking them via email opens. Using these sort of workarounds betrays that user trust, is bad practice, and ultimately harms your brand’s reputation.

- Pre-fetching gebeurt voornamelijk wanneer de gebruiker op wifi is en wanneer de telefoon is aangesloten op het stopcontact. Uit de eerste tests blijkt dat het vooraf laden alleen gebeurt als de gebruiker verbinding heeft met wifi en de telefoon is aangesloten op het lichtnet. Dit gedrag is een beetje onverwacht en zal interessant zijn om te observeren wanneer Apple overgaat op General Availability voor iOS15. In de praktijk betekent dit dat de open events nog willekeuriger zijn dan aanvankelijk gedacht. Het lijkt erop dat open events kunnen optreden wanneer de gebruiker het bericht daadwerkelijk opent, of wanneer de gebruiker het bericht niet heeft geopend maar op wifi is en de telefoon aan het opladen is - of een andere combinatie van gebeurtenissen die Apple bepaalt. Dit alles wijst op dezelfde conclusie: open tracking op Apple apparaten is niet te vertrouwen.

- Door de gebruiker geïnitieerde openingsgebeurtenissen worden geactiveerd wanneer de afbeelding wordt geladen via externe CSS.

- Testen geven ook aan dat door de gebruiker geïnitieerde open events worden getriggerd wanneer de afbeelding wordt geladen via een extern CSS-bestand. Hoewel dit op het eerste gezicht goed nieuws lijkt, raden we het gebruik van deze aanpak sterk af. Het is zeer waarschijnlijk dat Apple, net als HEY, deze maas in de wet zal dichten. Het is zeer waarschijnlijk dat Apple, zoals HEY al heeft gedaan, deze maas in de wet zal dichten. Maar er is een meer fundamentele reden om deze aanpak niet te gebruiken: gebruikers die hebben gekozen voor