Getting Tiles Data Into Firefox

A month ago, we announced that the new Tiles experience is available in the stable Firefox build. We experimented earlier this year and found that users do want more than empty boxes or screenshots in Firefox.  The Mozilla project is also working hard to set higher standards for the industry around transparency and control of the use of a user’s data.  With that in mind, we wanted to make it clear what data we do and do not pass from Mozilla servers to Firefox to enable the Tiles experience, and here, we’ll address how Tiles get into Firefox.  You can, of course, inspect the source code, but this might be easier.

Typically, if a web page adds external content, it does so by embedding an unencrypted remote request with cookied identifiers, so the server can respond as fast as possible with relevant content. The server also wants to remember as much as possible about the context of the request such as IP addresses and referrals, so this all is tracked through a persistent identifier that could be shared and triangulated with other data sources. Frequently, where a server wants to gather as much data as possible about users, invisible image beacons and iframes/scripts may be used to gather more information.  This is all done with little understanding by, or permission from, the user.

Tiles Request Headers Graphic

No special request headers or body data sent

What we are doing with Tiles is different

With the November 10th release, Firefox sends a single custom request once per day and then saves data locally to be used for as many new tabs opened by the user.  The Mozilla server sees the IP address of the request, and uses that to determine geotargeting at a country level (e.g., nothing more granular than “United States” or “Germany”).  The request URL contains the locale of the Firefox build to ensure the content Firefox shows is language and location appropriate.

Having received the request, we respond with the appropriate content and then delete the raw data with IP addresses within a week. Even with this minimal actionable data set, we are able to determine the volume of requests for specific country/locale pairs. This helps us decide which tiles to translate to provide a useful experience to new users in those regions.

The JSON response contains display information: Tiles graphics resources, URLs and titles, and is defined for a specific country/locale pair.

Code snippet

Sample en-US response with an array of tile data objects

Tiles is still evolving, and this is an initial release, but there are several things that we like about how we get Tiles data into Firefox.

Very importantly, this is an experience that is controlled by the user, involves the minimal actionable dataset.  “Tracking” has become a loaded term, and we do not consider Tiles to be tracking.  We do not need or try to identify an individual with these data requests, meaning that no cookies need to be set (and no other techniques to “fingerprint” are used).  However, we assume that anyone who has previously set their DNT preference to “do not track” wishes to opt out of the experience, and so no request is sent.  DNT is not how a user will opt out of the Tiles experience: a user who has Tiles can also set “do not track” independently of their Tiles settings.

The architecture reduces the latency requirements of our Tiles experience compared to traditional web pages: because Firefox can request and cache the data, it can pre-load assets, pre-compute personalization, and pre-populate the new tab page, so when users open a new tab, it’s fast and immediately usable.

And even though we send little data and save little data, we secure that data with transport encryption and prevent attacks with key pinning.

There are downsides to this approach: the data file could be outdated in both space and time. For example, a user could download tiles for their home country but then travels elsewhere, or we might accidentally show a Happy New Year tile after that date has passed. Also, because we package additional information in order to let Firefox make decisions, Firefox ends up with some title and URL data of Enhanced tiles that are not shown to users.  These are all potential improvements we’re looking forward to making.

Happy New Year Tile... might be a day late!

Happy New Year Tile… might be a day late!

I’m sure we can improve on our implementation.  We would also love to hear your thoughts on our approach to getting relevant Tiles data to power the default Directory and Enhanced Tiles experiences.  Next time, we will detail how we report data on interactions with Tiles.

Ed Lee on behalf of the Tiles team.

3 responses

Post a comment

  1. Fred wrote on :

    Well done, Ed and team. Proud to see us show off the underpinnings of the Tiles project.

    Reply

  2. Petr Viktorin wrote on :

    Thanks for the explanation.

    I noticed that the JSON response includes https links to the “dtex4kvbppovt.cloudfront.net” domain. Are these links followed to load the images? Is Mozilla in control of this domain (or is it more domains)? Does the “single custom request once per day” promise and the data retention policy apply to these?

    Reply

    1. Ed Lee wrote on :

      The image links are only followed/loaded if the new tab page would show them. Amazon CloudFront is a content delivery network we’re currently using to distribute the JSON and image files. It’s provided by Amazon Web Services, where we can see stats like number of requests and bandwidth usage (as those affect our bill), but we don’t set cookies or persist IP addresses (just like what was described in this blog).

      Reply

Post Your Comment