Fog revealed: A guided tour of how the police can browse your location data

This article is part of an EFF survey of location data brokers and fog data science. Be sure to check out our Location Data Proxy Issues page.

At we are about Part 1 of the fog data science series , we saw that when you give some app permission to see your location, it can end up being packaged and sold to many others company. One of them is Fog Data Science, which created a sleek search engine called Fog Reveal that allows police officers to browse that location data as if they were a Google Maps result.

In this article, we’ll take a deep dive into the capabilities of Fog Reveal. While Reveal’s accounts are typically only open to police departments, we were able to analyze the app’s public-facing code to better understand how it works, how it’s used, and what it looks like when police don’t have access to your location data.

What did we find

Fog Reveal’s home page that allows users to create geofence device queries anywhere in the US

Fog Reveal provides law enforcement with a powerful and highly intrusive tool for sifting through massive cellphone datasets location data. Reveal’s workflow allows police to perform “geofencing” device searches, searching for all devices in a designated area on the map and then finding all other locations of those devices at other times. The powerpoint presentation we received from the Chino Police Department describes how police use these features to identify so-called “” Bed-down” position and establish a “life mode” for the device owner. These features significantly undercut Fog’s claim that their product only contains “anonymous” data “without PII [personally identifiable information].”

We also found that Reveal’s front-end code contains traces of a more robust “federal” feature set that would allow users to pass Displays device advertiser ID , IP address and other phone details. As we’ll discuss, we don’t know if these features are currently in use, but anyway, they show how simply showing more fields of data can make data aggregation tools like this more intrusive.

method

To properly interpret our findings, it is important to understand what type of software Fog Reveal is and to explain our research methodology. Fog Reveal, like Google Maps, is a web application that runs in your browser. In order to study its functionality, we rebuilt the application locally based on web resources provided by visiting www.fogreveal.com. This is possible because when the page loads, without logging in or even clicking anything, the site automatically requests almost all the javascript/HTML needed for a fully functional application. In this document, we will refer to the javascript and HTML extracted from Reveal as “front-end” or “front-end code” and its server-side application as “back-end” or “back-end code”.

By saving Reveal’s front-end files and organizing them into directories that mirror their original URL paths The resource is replicated locally. From there, we wrote a mock backend server to serve files and handle API calls made by the frontend, then systematically worked out the data format expected by the API. Once that’s done, we have a semi-functional local replication of Reveal that doesn’t make requests to Fog’s actual servers, but allows us to explore its capabilities.

Because our mock server is not an exact replica of Reveal’s actual backend, we should say at the beginning of this article that our findings only apply to front-end code, since our mock server functions based on educated guesses and only returns false location data. Therefore, our local replication behavior may differ from the actual application of Fog. Where appropriate, we will cite the relevant front-end code (which we have made available on DocumentCloud) and point out where uncertainties remain, and will generally describe our estimates of Fog Reveal’s actual capabilities, with as little as possible Assume backend.

Beyond that, let’s now look at our findings on the Fog Reveal feature. All data described in the following documentation, including latitude/longitude coordinates and IP addresses, is fake data randomly generated by our simulated backend server. All screenshots are of our refactored app, not Fog’s production app.

Query

After logging into Reveal, the user will see a Google Maps view of the United States and the Toolbox in the upper right corner of the screen:

Users (most likely law enforcement) can zoom in on locations of interest and use the toolbox to draw geofences.

Reveal’s frontend showcases several tools for drawing geofences, the most basic of which is just a circle:

Here we are targeting the EFF office in San Francisco.

If that’s not specific enough, users can also draw arbitrary shapes to draw more detailed geofences :

We have now excluded EFF’s neighbors as well as our yard. The

front end limits the size of these geofence queries, although these limits are quite large. For example, the front-end circular tool will allow a query radius of 2500 meters1, up to a maximum of nearly 20 square kilometers when performing a “signal search”. Backends may impose further restrictions.

Users can also specify date and time ranges for their queries, and it appears that these ranges go back months : copy of Fog Reveal User Manual received from Greensboro Police Department stating date/time range can be extended to 90 days and can search for “back to June 2017[e]”.

search result

After specifying the geofence and date/time range, users can run their queries. The query returns a set of data points, referred to in the user manual as “signals”, which represent the position of the device at a given point in time 2. The user can then perform operations on these signals Further analysis, such as grouping them by the device that produced them, or showing the paths that devices took over time:

Our query results show 10 signals from 2 separate devices.

By the way, in this example we have been using the EFF office in San Francisco, coincidentally , which used to be home to a family planning clinic. While we have no evidence that Fog or its law enforcement clients are using Reveal to search for people seeking reproductive health care, it is conceivable that it could be used in this way: We have Police use Reveal Search for examples of individual buildings , and location data for example family planning patients sold by other data brokers (although SafeGraph stopped this practice after the story broke). After the Supreme Court overturned Roe v. Wade, and As states across the country pass increasingly tougher bills restricting people from having abortions, it’s important to consider the new threat Reveal and similar tools pose to people seeking reproductive health care.

Drill down device query

The front-end code indicates that Fog creates a unique internal identifier for the device – called the “Fog ID” (or “Registration ID”, 3, which we understand to be the same as Fog’s) “Device Registration Number”). These unique identifiers can be directly queried, allowing users to get all Signals generated by a device over a period of time, whether or not they are within the original geofence:

In the user manual, this The function is called “device query” and is described as including data from “local, regional or global travel” of the device. The user manual also describes a feature called “Generic Device Query” that allows the user to determine “whether any devices are generic to multiple locations.”

Federal Features

If some users With parameter set to 4, Reveal will update its logo to show “Reveal Federal” and enable the front end to request a more powerful suite of query tools from the back end. The front-end code indicates that these situations may arise if the user is a federal law enforcement officer5, but since we do not mention any public records of such federal users, we do not Will determine which users (if any) this applies to. For the purposes of this document, we refer to these hypothetical users as federated users.

Federal users have access to the internal device ID (“FOG ID”) used in Fog and the actual advertiser of the device Interface for conversion between ID6:

This is remarkable for several reasons. First, if this feature were operational, it would be done with the example of the national search warrant that Fog sent to the client Contradicted guarantees FOG IDs cannot be converted back to Advertiser IDs. Second, if users can retrieve the advertiser IDs of all devices in the query results, that would give Reveal a better ability to reveal the identities of those device owners. This is because if you have access to a device, you can read its advertiser ID, so law enforcement will be able to verify that a particular person’s device is part of the query results.

Additionally, the frontend is designed to show federated users more information when they view a device in the results7 Information about each device compared to non-federal users. Assuming this data is available from the backend, federated users can view device information such as:

OS version

Equipment series
• Equipment Brand
• Device Model
  Whether the device is an EU resident
• Last seen IP address

Also provides an interface for federated users to query signals/devices based on one or more IP addresses:

Connection to Venntel

Many of the functional resources we analyze in this article are powered by API calls referencing Venntel, a major player in the field of data brokering and DHS Contractor. While it’s true that Fog’s engineers could name these API endpoints arbitrarily, the way they operate does seem to suggest that Venntel is the source of Reveal’s location and device data.

It is worth noting that when a Reveal user performs any geofence device query, the query will be submitted to the URL path /Ventel/GetLocationData. Additionally, queries for a specific device location will be sent to /Venntel/GetDeviceLocationData send request , when federated user requests more device details, the front end sends a request to /Venntel/GetDeviceDetails. This means that almost all front-end requests related to searching for device or location data are prefixed with "Venntel". This will not be the only connection between Fog and Venntel: Numerous records received by the EFF indicate a strong connection between the two companies .

Conclusion

As we have seen, Fog Reveal provides law enforcement A powerful intrusive tool for searching large amounts of commercial location data. With just a few clicks, its users can find not only a device in a certain location, but also anywhere else Each of these devices operates at other time periods. Its federated feature set, whether currently in use or not, shows how intrusive the tool can be by revealing only a handful of other areas.

If you’re unhappy with the idea that your location data could be sold to companies like fog, we don’t blame you.Fortunately, there is one simple step you can take to enable data brokering It’s harder for people and companies like Fog to tie your location data to your device: Disable advertising ID tracking on your phone . Beyond that, we believe that changes are needed at both a technical and legal level to prevent this intrusive data collection and use. To learn more, check out our other articles in this series on data brokers .

Read about fog data More information on science:

Press release: Data Agents Help Police See Anywhere You Go Mouse Clicks: EFF Investigation

What is fog data science? Why are surveillance companies so dangerous?

Inside Fog Data Science, the secretive company that sells mass surveillance to the local police Fog Data Science sells our Fourth Amendment rights How law enforcement agencies across the country buy mobile phone location data wholesale

How Ad Tech Became Police Spy Tech