Hello -

I work on the mobile partner engineering team, probably known better as the Wikipedia Zero people.

If our servers see that an IP address matches with a given partner mobile network operator (MNO), the pertinent Wikipedia Zero text banner is shown to the mobile web user; additionally, offsite links are rewritten to warn a user when s/he may be entering into a zone that requires data access charges.

This is all fine and well, but partner operators sometimes change IP addresses and our systems get out of sync. Our partners are busy and our partner management team does of course strive to work with partners to proactively manage IP and other technical updates, yet inevitably information can fall through the cracks. Consequently, when IPs drift, the system doesn't show banners and do URL rewriting as well as it could.

In order to in part more proactively remediate the drift of operator exit IP addresses, we're interested in logging two pieces of information server-side via the forthcoming rewrites of the Wikipedia for Android and Wikipedia for iOS apps, and in some future state a rewritten Firefox OS app:

(1) MCC-MNC identification code of operator if present (e.g., 123-45 if the connection is on a particular operator - MCC-MNC is in the format ###-##)

(2) Exit IP address (typically, gateway/proxy in MNO infrastructure)

The MCC-MNC identification code is embedded on SIM cards and accessible by routine app APIs.

We would not want to log this information alongside the other Apache webserver-style elements, but instead have just these two columns in a separate nonpublic file location, purging records older than 90 days.

The thought is to just have the app code add the MCC-MNC value to an HTTP header once in a given app session using an MCC-MNC bearing connection (cellular data), and let the server detect the IP as per normal server operation.

In a nutshell, after normalizing the MCC/MNC codes (some are likely to be malformed) and cross-checking against our own MCC/MNC database, we'd be able to see if the IPs are askew, and then reach out to operators to ask if they have any updated IPs since the last time we received an official update.

We think this is a simple and fairly easy way to observe updated IP addresses for operator partners, and prompt the partner management team to reach out to operators for updated official source IP addresses.

The information could incidentally be useful in gauging rough demand for Wikipedia in markets germane to Wikipedia Zero (e.g., higher data costs, lower disposable income), although that is secondary to keeping the IPs accurate.

Internal review suggests this is in alignment with privacy policy, and we wanted to see if there were other thoughts on this approach. We plan to move the discussion over to wikitech-l and then later a broader list, but to avoid cross-posting problems with people having one membership in one list but not another, wanted to start on mobile-l first.

One last thing - the set of IPs for a given MNO are relatively small. For example, an MNO may have 100 IP addresses representing 1 million cellular subscribers. This has two practical consequences: (1) troublingly, even just a handful of missing IPs has outsize impact, and (2) highly targeted geography and behavioral inferences are unlikely for a data set composed of just two types of data elements submitted.

Thanks.

-Adam