Zoals hierboven beschreven, vindt het voorladen van Gmail alleen plaats in een beperkt aantal situaties. Voorladen gebeurt niet met andere mailclients. In plaats daarvan is dit gedrag specifiek voor wanneer een Gmail-gebruiker de Gmail-app geopend heeft in hun webbrowser of de mobiele app actief gebruikt. Onze beste schatting is dat het een beveiligingsscan is voordat de e-mail aan de gebruiker in hun browser wordt getoond.

De volledige aanvraagheaders voor de afbeeldingaanvraag worden hieronder gedetailleerd. Een paar dingen die je opmerkt:

• De referer is ingesteld op http://mail.google.com. Interessant is dat, hoewel de gebruiker op https:// zit, Gmail nog steeds de referer instelt op het http://-protocol wanneer de aanvraag wordt gedaan.

• De aanvraag komt van Gmail’s servers en niet van de browser van de gebruiker. Het client-IP lost altijd op naar een door Google beheerde IP-ruimte.

• In tegenstelling tot Google Image Cache, identificeert de user-agent string niet dat de aanvraag afkomstig is van een van Google’s bots. In plaats daarvan lijkt de user-agent string op een daadwerkelijke gebruikersafbeeldingaanvraag. We hebben echter bevestigd dat deze user-agent string wel degelijk de Google prefetch-bot identificeert.

• De open aanvraag gebeurt binnen enkele seconden na de bezorging van de e-mail. Verder vindt de aanvraag plaats voordat de e-mail verschijnt in de Gmail-interface van de gebruiker. Dit gedrag doet ons geloven dat de aanvraag bedoeld is voor beveiligingsdoeleinden.

• Het voorladen lijkt slechts één keer per ongelezen Gmail-e-mailreeks te gebeuren. In onze uitgebreide tests, zodra een bericht door de gebruiker is gelezen, initiëren toekomstige e-mails die in die reeks terechtkomen geen voorlaadaanvraag meer.

• Dit voorladen is apart van Google Image Cache. Onze tests geven aan dat, zelfs nadat de afbeelding is voorladen, een afzonderlijke Google Image Cache-aanvraag wordt gedaan wanneer de gebruiker de e-mail opent.

• Als een gebruiker de Gmail mobiele app open heeft, zal het voorladen voor een korte periode doorgaan, zelfs nadat de mobiele app is gesloten.

Hier is een voorbeeld van hoe de aanvraagheaders eruit zullen zien wanneer een afbeelding wordt opgevraagd door de Google Prefetch Bot:

  headers: {
    host: ‘{redacted}.m.pipedream.net’,
    ‘x-amzn-trace-id’: ‘Root={redacted}’,
    ‘accept-language’: ‘en-US’,
    referer: ‘http://mail.google.com/’,
    accept: ‘image/avif,image/webp,image/apng,image/svg+xml,image/*,*/*;q=0.8’,
    from: ”,
    ‘user-agent’: ‘Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/42.0.2311.135 Safari/537.36 Edge/12.246 Mozilla/5.0’,
    ‘accept-encoding’: ‘gzip, deflate, br’
   },
   body: {},
   inferred_body_type: ‘FORM’,
   method: ‘GET’,
   url: ‘https://{redacted}.m.pipedream.net/header-1641a1.gif’,
   client_ip: ‘66.249.92.1’,
   query: {}

Zoals het geval is met Apple's Mail Privacy Protection, moeten afzenders met zorg omgaan met alle open gebeurtenissen. Opens zijn slechts een van, en vaak niet de beste, van de vele betrokkenheidsmetriek die afzenders zouden moeten monitoren en meenemen bij het maken van beslissingen over gebruikersbetrokkenheid.