{"id":4040,"date":"2021-07-29T07:26:58","date_gmt":"2021-07-29T07:26:58","guid":{"rendered":"https:\/\/freshinbox.com\/blog\/?p=4040"},"modified":"2021-08-17T19:53:08","modified_gmt":"2021-08-17T19:53:08","slug":"a-technical-take-on-ios15-mail-privacy-protection","status":"publish","type":"post","link":"https:\/\/freshinbox.com\/blog\/a-technical-take-on-ios15-mail-privacy-protection\/","title":{"rendered":"A Technical Take on iOS15 Mail Privacy Protection"},"content":{"rendered":"

By now the topic of Apple\u2019s Mail Privacy Protection change for the upcoming iOS 15 is on everyone\u2019s lips.\u00a0<\/span><\/p>\n

A Brief Overview<\/span><\/h2>\n

On June 7, during Apple’s WWDC21 conference, it announced Mail Privacy Protection for their Mail app on iOS 15, iPadOS 15, and macOS Monterey devices, set to launch between September and November of this year.\u00a0According to Apple’s press release<\/a>, \u201cMail Privacy Protection stops senders from using invisible pixels to collect information about the user. The new feature helps users prevent senders from knowing when they open an email and masks their IP address so it can\u2019t be linked to other online activity or used to determine their location.\u201d<\/p>\n

This is not a default setting but something that a user will see when they first open an Apple Mail app, in which\u00a0they\u2019ll get a message prompting them to either \u201cProtect Mail activity\u201d or \u201cDon\u2019t protect Mail activity.\u201d<\/p>\n

The following are some of the technical details I\u2019ve discovered while testing the Apple Mail app on iOS15 beta<\/a>.<\/p>\n

Observations<\/span><\/h2>\n

I downloaded the iOS15 beta onto my device and set up my own pixel. By the way, you can learn how to set up your own pixel here<\/a><\/span>, so you can run your own experiments that way.<\/span><\/p>\n

Also, take the following observations with a grain of salt as this is only the beta and Apple can always tweak their setup at any time.<\/span><\/p>\n

    \n
  1. Images load as if the email is opened:<\/strong>
    \nWhat I\u2019ve found is that if you have desktop and mobile background images that are loaded     using media queries<\/a>, only the mobile background images are loaded. This is consistent with how the client would behave if an email is opened by a user. Unfortunately, this makes it harder to tell if an email is actually read or not by tinkering with media queries.<\/p>\n

    Update:<\/b> Apparently you can detect a real user open as of iOS Beta 5 by using an external CSS pixel<\/a>.<\/li>\n

  2. Interactive pixels can still gauge engagement:<\/strong>
    \nOne very interesting note is that interactive or kinetic background images loaded through :hover or :checked are not pre-fetched by the client. This means if you have pixels that     detect interactive actions<\/a>, they would detect real user actions. Once triggered, though these pixels are cached so you wouldn’t be able to detect subsequent actions. Now would Apple put the kibosh on this, too? Who knows!<\/p>\n<\/li>\n
  3. It takes several minutes to several hours for images to begin downloading:<\/strong>
    \nFrom my tests, once the emails are loaded into the email client on iOS15 beta, it takes the client anywhere from several minutes usually around 20 minutes to more than 8 hours to begin downloading images in the background.<\/p>\n

    Update: Matthew Dunn<\/a> mentioned in the comments that he noticed that the Mail client downloads images almost immediately for emails in accounts configured with push (ie. Exchange\/iCloud) which happens when the messages arrive vs fetch (Gmail\/IMAP) which happens when the client periodically checks for email (I ran my tests with the Mail client connected to Gmail\/IMAP\/POP accounts).<\/p>\n<\/li>\n

  4. Images in the Junk (spam) folder are not downloaded:<\/strong>
    \nWhen an email lands in the Apple Mail’s Junk folder I did not notice the email client downloading images within these emails in the background.<\/p>\n<\/li>\n
  5. Power and WiFi matters:<\/strong>
    \nFor the current version of the beta, it appears that the device tends to hold off on downloading images in the background if the device is not connected to a power source or not on Wifi. I’ve seen cases where images are not downloaded for 5 hours, and the moment I plug in the power cable and turn on Wifi, the images start downloading. .<\/p>\n

    Most times, when the device is on WiFi and connected to a power source, the images of unread emails begin downloading in the background within the first 30 minutes after an email is downloaded.<\/p>\n<\/li>\n

  6. The client needs to be running:<\/strong>
    \nIf the Mail app is killed (not just put into the background), I’ve found that the client does not load images in the background.<\/p>\n<\/li>\n
  7. Proxied IP and “Mozilla\/5.0” User Agent:<\/strong>
    \nAs many have found out, the user agent for the request is masked to \u201cMozilla\/5.0\u201d and the requests come from a proxied IP address.\u00a0 Brian Sisolak also noticed that some of the IPs     originate from Microsoft’s Azure as well as Cloudflare<\/a>. According to Apple’s notes, these IP may be associated with a user’s general region as well.<\/p>\n<\/li>\n
  8. Images are cached for 2-3 days:<\/strong>
    \nOnce the images are downloaded in an email, they are cached, and opening the email does not entail a load from the server. Also, it appears based on     Brian\u2019s observation<\/a> that the caching does not respect the “Cache-Control” headers that specify when a cached image should expire – unlike Gmail, which honors the expiry.<\/p>\n

    What this means is if you’re seeing multiple “opens” over several days from the same recipient from Apple Mail, its likely the subsequent ones were real opens – though it could be due to other factors as well such as the recipient connecting their other Apple devices (Mac\/iPad) to the same email account and not downloading emails until later.<\/p>\n<\/li>\n

  9. Images are cached across emails:<\/strong>
    \nIf you have the same image across multiple emails (and emails across accounts on the same email client), the image is only fetched once. This may not be relevant to tracking pixels since they are unique per email, but it is something I’ve noticed.<\/p>\n<\/li>\n<\/ol>\n

    Learnings<\/span><\/h2>\n

    The first thing to note is that analytics providers and ESPs must now start segregating Apple Mail and non-Apple mail \u201copens\u201d for the stats to make any sense. However, once you can segregate these stats, the Apple Mail stats can still be valuable.<\/span><\/p>\n

    Based on what I\u2019ve found, here are some of my takeaways:<\/span><\/p>\n

      \n
    1. One of the upshots is since the emails must be loaded into a Mail client for the images to be downloaded, you now can tell that these email addresses are live and not going to an inbox that has been abandoned.
      \n
      \n<\/span><\/p>\n<\/li>\n
    2. One of the worries of marketers is if the Mail client downloaded all images immediately after retrieving an email, that may result in a flood of image requests on their server potentially overwhelming their servers. Seeing that there is not only a delay in downloading images, but often a long delay when the device is not connected to a power source, this tsunami of requests may not materialize.
      \n<\/span>
      \n<\/span><\/p>\n<\/li>\n
    3. You can still gain some signals of engagement (for now) by using <\/span>interactive pixel tracking<\/span><\/a>.<\/span>
      \n<\/span><\/p>\n<\/li>\n<\/ol>\n

      So what does this mean for you?<\/span><\/h2>\n

      I think there are many pundits already giving their opinion and I\u2019m not much of a marketer\u2019s marketer, but here are some.<\/span><\/p>\n