OVRSEEN: Auditing Network Traffc and Privacy Policies in Oculus VR 

Rahmadi Trimananda,1 Hieu Le,1 Hao Cui,1 Janice Tran Ho,1 Anastasia Shuba,2 and Athina Markopoulou1 

1University of California, Irvine 

2Independent Researcher 

arXiv:2106.05407v4 [cs.CR] 19 Nov 2021

Abstract 

Virtual reality (VR) is an emerging technology that enables 

new applications but also introduces privacy risks. In this 

paper, we focus on Oculus VR (OVR), the leading platform in 

the VR space and we provide the frst comprehensive analysis 

of personal data exposed by OVR apps and the platform itself, 

from a combined networking and privacy policy perspective. 

We experimented with the Quest 2 headset and tested the 

most popular VR apps available on the offcial Oculus and the 

SideQuest app stores. We developed OVRSEEN, a methodology and system for collecting, analyzing, and comparing 

network traffc and privacy policies on OVR. On the networking side, we captured and decrypted network traffc of VR 

apps, which was previously not possible on OVR, and we 

extracted data fows, defned as happ, data type, destinationi. 

Compared to the mobile and other app ecosystems, we found 

OVR to be more centralized and driven by tracking and analytics, rather than by third-party advertising. We show that 

the data types exposed by VR apps include personally identifable information (PII), device information that can be used 

for fngerprinting, and VR-specifc data types. By comparing 

the data fows found in the network traffc with statements 

made in the apps’ privacy policies, we found that approximately 70% of OVR data fows were not properly disclosed. 

Furthermore, we extracted additional context from the privacy 

policies, and we observed that 69% of the data fows were 

used for purposes unrelated to the core functionality of apps. 

1 Introduction 

Virtual reality (VR) technology has created an emerging market: VR hardware and software revenues are projected to increase from $800 million in 2018 to $5.5 billion in 2023 [53]. 

Among VR platforms, Oculus VR (OVR) is a pioneering, and 

arguably the most popular one: within six months since October 2020, an estimated fve million Quest 2 headsets were 

sold [16, 22]. VR technology enables a number of applications, including recreational games, physical training, health 

therapy, and many others [52]. 

VR also introduces privacy risks: some are similar to those 

on other Internet-based platforms (e.g., mobile phones [12,13], 

IoT devices [3, 17], and Smart TVs [37, 67]), but others are 

unique to VR. For example, VR headsets and hand controllers 

are equipped with sensors that may collect data about the 

user’s physical movement, body characteristics and activity, 

voice activity, hand tracking, eye tracking, facial expressions, 

and play area [27, 36], which may in turn reveal information 

about our physique, emotions, and home. The privacy aspects 

of VR platforms are currently not well understood [2]. 

To the best of our knowledge, our work is the frst large 

scale, comprehensive measurement and characterization of 

privacy aspects of OVR apps and platform, from a combined 

network and privacy policy point of view. We set out to characterize how sensitive information is collected and shared 

in the VR ecosystem, in theory (as described in the privacy 

policies) and in practice (as exhibited in the network traffc 

generated by VR apps). We center our analysis around the 

concept of data fow, which we defne as the tuple happ, data 

type, destinationi extracted from the network traffc. First, 

we are interested in the sender of information, namely the 

VR app. Second, we are interested in the exposed data types, 

including personally identifable information (PII), device information that can be used for fngerprinting, and VR sensor 

data. Third, we are interested in the recipient of the information, namely the destination domain, which we further 

categorize into entity or organization, frst vs. third party w.r.t. 

the sending app, and ads and tracking services (ATS). Inspired 

by the framework of contextual integrity [40], we also seek 

to characterize whether the data fows are appropriate or not 

within their context. More specifcally, our notion of context 

includes: consistency, i.e., whether actual data fows extracted 

from network traffc agree with the corresponding statements 

made in the privacy policy; purpose, extracted from privacy 

policies and confrmed by destination domains (e.g., whether 

they are ATS); and other information (e.g., “notice and consent”). Our methodology and system, OVRSEEN, is depicted 

on Fig. 1. Next we summarize our methodology and fndings. 

Network traffc: methodology and fndings. We were 

able to explore 140 popular, paid and free, OVR apps; and 

then capture, decrypt, and analyze the network traffc they 

generate in order to assess their practices with respect to collection and sharing of personal data on the OVR platform. 

OVRSEEN collects network traffc without rooting the 

Quest 2, by building on the open-source AntMonitor [54], 

which we had to modify to work on the Android 10-based Ocu1 
Network Traffic Analysis

Privacy Policy Analysis

App Stores

Raw Data

PCAPNG

JSON

Network Traffic Collection

Oculus Quest 2

App Frida 

Agent

AntMonitor

PC

Unity & Unreal 

Libraries

Frida Client

Oculus/Facebook, 

Unity, Unreal,

Third Parties

Privacy Policies

Data Flows 

In Context

App

Data Type

Destination

Privacy Policy Analyzer

Entity Ontology

Data Ontology Collection 

Statements

App

Data Type

Entity Polisis

Improved

PoliCheck 

Translation

Context

Consistency

Purpose

Other

Data Flows

App

Data Type

Destination

Network 

Traffic 

Analysis

Data Types 

Exposures

ATS 

Ecosystem

1 2 3

4

5

6

7

Figure 1: Overview of OVRSEEN. We select the most popular apps from the offcial Oculus and SideQuest app stores. First, we 

experiment with them and analyze their network traffc: (1) we obtain raw data in PCAPNG and JSON; (2) we extract data 

fows happ, data type, destinationi; and (3) we analyze them w.r.t. data types and ATS ecosystem. Second, we analyze the same 

apps’ (and their used libraries’) privacy policies: (4) we build VR-specifc data and entity ontologies, informed both by network 

traffc and privacy policy text; and (5) we extract collection statements happ, data type, entityi from the privacy policy. Third, 

we compare the two: (6) using our improved PoliCheck, we map each data fow to a collection statement, and we perform 

network-to-policy consistency analysis. Finally, (7) we translate the sentence containing the collection statement into a text 

segment that Polisis can use to extract the data collection purpose. The end result is that data fows, extracted from network 

traffc, are augmented with additional context, such as consistency with policy and purpose of collection. 

lus OS. Furthermore, we successfully addressed new technical 

challenges for decrypting network traffc on OVR. OVRSEEN 

combines dynamic analysis (using Frida [45]) with binary 

analysis to fnd and bypass certifcate validation functions, 

even when the app contains a stripped binary [66]. This was a 

challenge specifc to OVR: prior work on decrypting network 

traffc on Android [37,55] hooked into standard Android SDK 

functions and not the ones packaged with Unity and Unreal, 

which are the basis for game apps. 

We extracted and analyzed data fows found in the collected network traffc from the 140 OVR apps, and we made 

the following observations. We studied a broad range of 21 

data types that are exposed and found that 33 and 70 apps 

send PII data types (e.g., Device ID, User ID, and Android 

ID) to frst-and third-party destinations, respectively (see Table 3). Notably, 58 apps expose VR sensory data (e.g., physical movement, play area) to third-parties. We used state-ofthe-art blocklists to identify ATS and discovered that, unlike 

other popular platforms (e.g., Android and Smart TVs), OVR 

exposes data primarily to tracking and analytics services, and 

has a less diverse tracking ecosystem. Notably, the blocklists 

identifed only 36% of these exposures. On the other hand, 

we found no data exposure to advertising services as ads on 

OVR is still in an experimental phase [44]. 

Privacy policy: methodology and fndings. We provide 

an NLP-based methodology for analyzing the privacy policies 

that accompany VR apps. More specifcally, OVRSEEN maps 

each data fow (found in the network traffc) to its corresponding data collection statement (found in the text of the privacy 

policy), and checks the consistency of the two. Furthermore, 

it extracts the purpose of data fows from the privacy policy, as well as from the ATS analysis of destination domains. 

Consistency, purpose, and additional information provide context, in which we can holistically assess the appropriateness 

of a data fow [40]. Our methodology builds on, combines, 

and improves state-of-the-art tools originally developed for 

mobile apps: PolicyLint [4], PoliCheck [5], and Polisis [21]. 

We curated VR-specifc ontologies for data types and entities, 

guided by both the network traffc and privacy policies. We 

also interfaced between different NLP models of PoliCheck 

and Polisis to extract the purpose behind each data fow. 

Our network-to-policy consistency analysis revealed that 

about 70% of data fows from VR apps were not disclosed 

or consistent with their privacy policies: only 30% were consistent. Furthermore, 38 apps did not have privacy policies, 

including apps from the offcial Oculus app store. Some app 

developers also had the tendency to neglect declaring data 

collected by the platform and third parties. We found that by 

automatically including these other parties’ privacy policies 

in OVRSEEN’s network-to-policy consistency analysis, 74% 

of data fows became consistent. We also found that 69% 

of data fows have purposes unrelated to the core function2 
2 

ality (e.g., advertising, marketing campaigns, analytics), and 

only a handful of apps are explicit about notice and consent. 

OVRSEEN’s implementation and datasets are made available 

at [62]. 

Overview. The rest of this paper is structured as follows. 

Section 2 provides background on the OVR platform and its 

data collection practices that motivate our work. Section 3 

provides the methodology and results for OVRSEEN’s network traffc analysis. Section 4 provides the methodology and 

results for OVRSEEN’s policy analysis, network-to-policy 

consistency analysis, and purpose extraction. Section 5 discusses the fndings and provides recommendations. Section 6 

discusses related work. Section 7 concludes the paper. 

Oculus VR Platform and Apps 

In this paper, we focus on the Oculus VR (OVR), a representative of state-of-the art VR platform. A pioneer and leader 

in the VR space, OVR was bought by Facebook in 2014 [16] 

(we refer to both as “platform-party”), and it maintains to 

be the most popular VR platform today. Facebook has integrated more social features and analytics to OVR and now 

even requires users to sign in using a Facebook account [41]. 

We used the latest Oculus device, Quest 2, for testing. Quest 

2 is completely wireless: it can operate standalone and run 

apps, without being connected to other devices. In contrast, 

e.g., Sony Playstation VR needs to be connected to a Playstation 4 as its game controller. Quest 2 runs Oculus OS, a variant 

of Android 10 that has been modifed and optimized to run 

VR environments and apps. The device comes with a few 

pre-installed apps, such as the Oculus browser. VR apps are 

usually developed using two popular game engines called 

Unity [65] and Unreal [15]. Unlike traditional Android apps 

that run on Android JVM, these 3D app development frameworks compile VR apps into optimized (i.e., stripped) binaries 

to run on Quest 2 [66]. 

Oculus has an offcial app store and a number of thirdparty app stores. The Oculus app store offers a wide range 

of apps (many of them are paid), which are carefully curated 

and tested (e.g., for VR motion sickness). In addition to the 

Oculus app store, we focus on SideQuest—the most popular 

third-party app store endorsed by Facebook [34]. In contrast 

to apps from the offcial store, apps available on SideQuest 

are typically at their early development stage and thus are 

mostly free. Many of them transition from SideQuest to the 

Oculus app store once they mature and become paid apps. As 

of March 2021, the offcial Oculus app store has 267 apps 

(79 free and 183 paid), and the SideQuest app store has 1,075 

apps (859 free and 218 paid). 

Motivation: privacy risks in OVR. VR introduces privacy risks, some of which are similar to other Internet-based 

platforms (e.g., Android [12, 13], IoT devices [3, 17], Smart 

TVs [37, 67]), etc.), while others are unique to the VR platform. For example, VR headsets and hand controllers are 

equipped with sensors that collect data about the user’s physical movement, body characteristics, voice activity, hand tracking, eye tracking, facial expressions, and play area [27,36,38], 

which may in turn reveal sensitive information about our 

physique, emotions, and home. Quest 2 can also act as a ftness tracker, thanks to the built-in Oculus Move app that 

tracks time spent for actively moving and amount of calories 

burned across all apps [43]. Furthermore, Oculus has been 

continuously updating their privacy policy with a trend of 

increasingly collecting more data over the years. Most notably, we observed a major update in May 2018, coinciding 

with the GDPR implementation date. Many apps have no 

privacy policy, or fail to properly include the privacy policies 

of third-party libraries. Please see Appendix A for more detail on observations that motivated our study, and Section 6 

on related work. The privacy risks on the relatively new VR 

platform are not yet well understood. 

Goal and approach: privacy analysis of OVR. In this paper, we seek to characterize the privacy risks introduced when 

potentially-sensitive data available on the device are sent by 

the VR apps and/or the platform to remote destinations for various purposes. We followed an experimental and data-driven 

approach, and we chose to test and analyze the most popular 

VR apps. In Section 3, we characterize the actual behavior 

exhibited in the network traffc generated by these VR apps 

and platform. In Section 4, we present how we downloaded 

the privacy policies of the selected VR apps, the platform, 

and relevant third-party libraries, used NLP to extract and 

analyze the statements made about data collection, analyzed 

their consistency when compared against the actual data fows 

found in traffc, and extracted the purpose of data collection. 

App corpus. We selected OVR apps that are widely used by 

players. Our app corpus consists of 150 popular paid and free 

apps from both the offcial Oculus app store and SideQuest. 

In contrast, previous work typically considered only free apps 

from the offcial app store [12,13,37,67]. We used the number 

of ratings/reviews as the popularity metric, and considered 

only apps that received at least 3.5 stars. We selected three 

groups of 50 apps each: (1) the top-50 free apps and (2) the 

top-50 paid apps from the Oculus app store, and (3) the top-50 

apps from the SideQuest store. We selected an equal number 

of paid and free apps from the Oculus app store to gain insight 

into both groups equally. We purposely did not just pick the 

top-100 apps, because paid apps tend to receive more reviews 

from users and this would bias our fndings towards paid apps. 

Specifcally, this would make our corpus consist of 90% paid 

and 10% free apps. 

Our app corpus is representative of both app stores. Our top50 free and top-50 paid Oculus apps constitute close to 40% 

of all apps on the Oculus app store, whereas the total number 

of downloads of our top-50 SideQuest apps is approximately 

3 
45% of all downloads for the SideQuest store. Out of these 

150 apps, selected for their popularity and representativeness, 

we were able to decrypt and analyze the network traffc for 

140 of them for reasons explained in Section 3.2.1. 

3 OVRSEEN: Network Traffc 

In this section, we detail our methodology for collecting 

and analyzing network traffc. In Section 3.1, we present 

OVRSEEN’s system for collecting network traffc and highlight our decryption technique. Next, in Section 3.2, we describe our network traffc dataset and the extracted data fows. 

In Section 3.3, we report our fndings on the OVR ATS ecosystem by identifying domains that were labeled as ATS by popular blocklists. Finally, in Section 3.4, we discuss data types 

exposures in the extracted data fows according to the context 

based on whether their destination is an ATS or not. 

3.1 Network Traffc Collection 

In this section, we present OVRSEEN’s system for collecting 

and decrypting the network traffc that apps generate ( 1 in 

Fig. 1). It is important to mention that OVRSEEN does not require rooting Quest 2, and as of June 2021, there are no known 

methods for doing so [23]. Since the Oculus OS is based on 

Android, we enhanced AntMonitor [54] to support the Oculus 

OS. Furthermore, to decrypt TLS traffc, we use Frida [45], a 

dynamic instrumentation toolkit. Using Frida to bypass certifcate validation specifcally for Quest 2 apps presents new 

technical challenges, compared to Android apps that have a 

different structure. Next, we describe these challenges and 

how we address them. 

Traffc collection. For collecting network traffc, 

OVRSEEN integrates AntMonitor [54]—a VPN-based 

tool for Android that does not require root access. It runs 

completely on the device without the need to re-route 

traffc to a server. AntMonitor stores the collected traffc 

in PCAPNG format, where each packet is annotated (in 

the form of a PCAPNG comment) with the name of the 

corresponding app. To decrypt TLS connections, AntMonitor 

installs a user CA certifcate. However, since Oculus OS 

is a modifed version of Android 10, and AntMonitor only 

supports up to Android 7, we made multiple compatibility 

changes to support Oculus OS. In addition, we enhanced 

the way AntMonitor stores decrypted packets: we adjust the 

sequence and ack numbers to make packet re-assembly by 

common tools (e.g., tshark) feasible in post-processing. 

We will submit a pull request to AntMonitor’s open-source 

repository, so that other researchers can make use of it, not 

only on Quest 2, but also on other newer Android devices. 

For further details, see Appendix B.1. 

TLS decryption. Newer Android devices, such as Quest 

2, pose a challenge for TLS decryption: as of Android 7, 

apps that target API level 24 (Android 7.0) and above no 

longer trust user-added certifcates [7]. Since Quest 2 cannot 

be rooted, we cannot install AntMonitor’s certifcate as a system certifcate. Thus, to circumvent the mistrust of AntMonitor’s certifcate, OVRSEEN uses Frida (see Fig. 1) to intercept 

certifcate validation APIs. To use Frida in a non-rooted environment, we extract each app and repackage it to include and 

start the Frida server when the app loads. The Frida server 

then listens to commands from a Frida client that is running 

on a PC using ADB. Although ADB typically requires a USB 

connection, we run ADB over TCP to be able to use Quest 2 

wirelessly, allowing for free-roaming testing of VR apps. 

OVRSEEN uses the Frida client to load and inject our custom JavaScript code that intercepts various APIs used to verify CA certifcates. In general, Android and Quest 2 apps 

use three categories of libraries to validate certifcates: (1) 

the standard Android library, (2) the Mbed TLS library [64] 

provided by the Unity SDK, and (3) the Unreal version of the 

OpenSSL library [14]. OVRSEEN places Frida hooks into 

the certifcate validation functions provided by these three 

libraries. These hooks change the return value of the intercepted functions and set certain fags used to determine the 

validity of a certifcate to ensure that AntMonitor’s certifcate 

is always trusted. While bypassing certifcate validation in 

the standard Android library is a widely known technique [9], 

bypassing validation in Unity and Unreal SDKs is not. Thus, 

we developed the following technique. 

Decrypting Unity and Unreal. Since most Quest 2 apps 

are developed using either the Unity or the Unreal game engines, they use the certifcate validation functions provided 

by these engines instead of the ones in the standard Android 

library. Below, we present our implementation of certifcate 

validation bypassing for each engine. 

For Unity, we discovered that the main function that 

is responsible for checking the validity of certifcates 

is mbedtls_x509_crt_verify_with_profile() in the 

Mbed TLS library, by inspecting its source code [6]. This 

library is used by the Unity framework as part of its SDK. 

Although Unity apps and its SDK are written in C#, the fnal 

Unity library is a C++ binary. When a Unity app is packaged for release, unused APIs and debugging symbols get 

removed from the Unity library’s binary. This process makes 

it diffcult to hook into Unity’s functions since we cannot 

locate the address of a function of interest without having 

the symbol table to look up its address. Furthermore, since 

the binary also gets stripped of unused functions, we cannot rely on the debug versions of the binary to look up addresses because each app will have a different number of 

APIs included. To address this challenge, OVRSEEN automatically analyzes the debug versions of the non-stripped 

Unity binaries (provided by the Unity engine), extracts 

the function signature (i.e., a set of hexadecimal numbers) 

of mbedtls_x509_crt_verify_with_profile(), and then 

looks for this signature in the stripped version of the binary 

4 
App Store Apps Domains eSLDs Packets TCP Fl. .2 Network Data Flows Extracted 

Oculus-Free 43 85 48 2,818 2,126 

Oculus-Paid 49 54 35 2,278 1,883 

SideQuest 48 57 40 2,679 2,260 

Total 140 158 92 7,775 6,269 

3.2

We

1,1

scr

Ap Table 1: Network traffc dataset summary. Note that the tai same domains and eSLDs can appear across the three groups 

of “App Store”, so their totals are based on unique counts. 

to fnd its address. This address can then be used to create the 

necessary Frida hook for an app. The details of this automated 

binary analysis can be found in Appendix B.2. 

For Unreal, we discovered that the main function that is 

responsible for checking the validity of certifcates is the function x509_verify_cert() in the OpenSSL library, which 

is integrated as part of the Unreal SDK. Fortunately, the 

Unreal SDK binary fle comes with a partial symbol table 

that contains the location of x509_verify_cert(), and thus, 

OVRSEEN can set a Frida hook for it. 

3.2 Network Traffc Dataset 

3.2.1 Raw Network Traffc Data 

We used OVRSEEN to collect network traffc for 1401 apps 

in our corpus during the months of March and April 2021. To 

exercise these 140 apps and collect their traffc, we manually 

interacted with each one for seven minutes. Although there are 

existing tools that automate the exploration of regular (nongaming) mobile apps (e.g., [30]), automatic interaction with 

a variety of games is an open research problem. Fortunately, 

manual testing allows us to customize app exploration and 

split our testing time between exploring menus within the app 

to cover more of the potential behavior, and actually playing 

the game, which better captures the typical usage by a human 

user. As shown by prior work, such testing criteria lead to 

more diverse network traffc and reveal more privacy-related 

data fows [24, 50, 67]. Although our methodology might not 

be exhaustive, it is inline with prior work [37, 67]. 

Table 1 presents the summary of our network traffc dataset. 

We discovered 158 domains and 92 eSLDs in 6,269 TCP fows 

that contain 7,775 packets. Among the 140 apps, 96 were 

developed using the Unity framework, 31 were developed 

using the Unreal framework, and 13 were developed using 

other frameworks. 

1The remaining 10 apps were excluded for the following reasons: (1) six 

apps could not be repackaged; (2) two apps were browser apps, which would 

open up the web ecosystem, diverting our focus from VR; (3) one app was 

no longer found on the store—we created our lists of top apps one month 

ahead of our experiments; and (4) one app could not start on the Quest 2 even 

without any of our modifcations. 

 processed the raw network traffc dataset and identifed 

35 data fows: happ, data type, destinationi. Next, we deibe our methodology for extracting that information. 

p names. For each network packet, the app name is obned by AntMonitor [54]. This feature required a modifcation to work on Android 10, as described in Appendix B.1. 

Data types. The data types we extracted from our network 

traffc dataset are listed in Table 3 and can be categorized into 

roughly three groups. First, we fnd personally identifable information (PII), including: user identifers (e.g., Name, Email, 

and User ID), device identifers (Android ID, Device ID, and 

Serial Number), Geolocation, etc. Second, we found system 

parameters and settings, whose combinations are known to 

be used by trackers to create unique profles of users [37, 39], 

i.e., Fingerprints. Examples include various version information (e.g., Build and SDK Versions), Flags (e.g., indicating 

whether the device is rooted or not), Hardware Info (e.g., Device Model, CPU Vendor, etc.), Usage Time, etc. Finally, we 

also fnd data types that are unique to VR devices (e.g., VR 

Movement and VR Field of View) and group them as VR Sensory Data. These can be used to uniquely identify a user or 

convey sensitive information—the VR Play Area, for instance, 

can represent the actual area of the user’s household. 

We use several approaches to fnd these data types in 

HTTP headers and bodies, and also in any raw TCP segments that contain ASCII characters. First, we use string 

matching to search for data that is static by nature. For example, we search for user profle data (e.g., User Name, Email, 

etc.) using our test OVR account and for any device identifers (e.g., Serial Number, Device ID, etc.) that can be retrieved by browsing the Quest 2 settings. In addition, we 

search for their MD5 and SHA1 hashes. Second, we utilize 

regular expressions to capture more dynamic data types. For 

example, we can capture different Unity SDK versions using 

UnityPlayer/[\d.]+\d. Finally, for cases where a packet 

contains structured data (e.g., URL query parameters, HTTP 

Headers, JSON in HTTP body, etc.), we split the packet into 

key-value pairs and create a list of unique keys that appear 

in our entire network traffc dataset. We then examine this 

list to discover keys that can be used to further enhance our 

search for data types. For instance, we identifed that the keys 

“user_id” and “x–playeruid” can be used to fnd User IDs. 

Appendix C.1 provides more details on our data types. 

Destinations. To extract the destination fully qualifed domain name (FQDN), we use the HTTP Host feld and the TLS 

SNI (for cases where we could not decrypt the traffc). Using 

tldextract, we also identify the effective second-level domain 

(eSLD) and use it to determine the high level organization 

that owns it via Crunchbase. We also adopt similar labeling 

methodologies from [67] and [5] to categorize each destination as either frst-, platform-, or third-party. To perform the 

5 
0 50 100

Number of Apps

mixpanel.com

cloudfunctions.net

google-analytics.com

googleapis.com

google.com

unity3d.com

oculuscdn.com

oculus.com

facebook-hardware.com

facebook.com

eSLD

Third-party

Platform-party

0 50 100

Number of Apps

www.google-analytics.com

yurapp-502de.firebaseapp.com

api.mixpanel.com

example.com

perf-events.cloud.unity3d.com

cdp.cloud.unity3d.com

config.uca.cloud.unity3d.com

scontent.oculuscdn.com

graph.oculus.com

graph.facebook-hardware.com

ATS FQDN

Third-party

Platform-party

(b) (a) 

Figure 2: Top-10 platform and third-party (a) eSLDs and (b) ATS FQDNs. They are ordered by the number of apps that 

contact them. Each app may have a few frst-party domains: we found that 46 out of 140 (33%) apps contact their own eSLDs. 

categorization, we also make use of collected privacy policies (see Fig. 1 and Section 4), as described next. First, we 

tokenize the domain and the app’s package name. We label a 

domain as frst-party if the domain’s tokens either appear in 

the app’s privacy policy URL or match the package name’s 

tokens. If the domain is part of cloud-based services (e.g., 

vrapp.amazonaws.com), we only consider the tokens in the 

subdomain (vrapp). Second, we categorize the destination as 

platform-party if the domain contains the keywords “oculus” 

or “facebook”. Finally, we default to the third-party label. 

This means that the data collection is performed by an entity 

that is not associated with app developers nor the platform, 

and the developer may not have control of the data being 

collected. The next section presents further analysis of the 

destination domains. 

3.3 OVR Advertising & Tracking Ecosystem 

In this section, we explore the destination domains found in 

our network traffc dataset (see Section 3.2.2). Fig. 2a presents 

the top-10 eSLDs for platform and third-party. We found that, 

unlike the mobile ecosystem, the presence of third-parties 

is minimal and platform traffc dominates in all apps (e.g., 

oculus.com, f acebook.com). The most prominent third-party 

organization is Unity (e.g., unity3d.com), which appears in 

68 out of 140 apps (49%). This is expected since 96 apps in 

our dataset were developed using the Unity engine (see Section 3.2.1). Conversely, although 31 apps in our dataset were 

developed using the Unreal engine, it does not appear as a major third-party data collector because Unreal does not provide 

its own analytics service. Beyond Unity, other small players 

include Alphabet (e.g., google.com, cloudfunctions.net) and 

Amazon (e.g., amazonaws.com). In addition, 87 out of 140 

apps contact four or fewer third-party eSLDs (62%). 

Identifying ATS domains. To identify ATS domains, we 

apply the following popular domain-based blocklists: (1) PiHole’s Default List [46], a list that blocks cross-platform ATS 

domains for IoT devices; (2) Mother of All Adblocking [8], 

a list that blocks both ads and tracking domains for mobile 

devices; and (3) Disconnect Me [10], a list that blocks tracking domains. For the rest of the paper, we will refer to the 

above lists simply as “blocklists”. We note that there are no 

blocklists that are curated for VR platforms. Thus, we choose 

blocklists that balance between IoT and mobile devices, and 

one that specializes in tracking. 

OVR ATS ecosystem. The majority of identifed ATS domains relate to social and analytics-based purposes. Fig. 2b 

provides the top-10 ATS FQDNs that are labeled by our blocklists. We found that the prevalent platform-related FQDNs 

along with Unity, the prominent third party, are labeled as 

ATS. This is expected: domains such as graph.oculus.com 

and perf-events.cloud.unity3d.com are utilized for social 

features like managing leaderboards and app analytics, 

respectively. We also consider the presence of organizations based on the number of unique domains contacted. 

The most popular organization is Alphabet, which has 

13 domains, such as google-analytics.com and frebasesettings.crashlytics.com. Four domains are associated with 

Facebook, such as graph.facebook.com. Similarly, four are 

from Unity, such as userreporting.cloud.unity3d.com and 

confg.uca.cloud.unity3d.com. Other domains are associated 

with analytics companies that focus on tracking how users 

interact with apps (e.g., whether they sign up for an account) such as logs-01.loggly.com, api.mixpanel.com, and 

api2.amplitude.com. Lastly, we provide an in-depth comparison to other ecosystems in Section 5.1. 

Missed by blocklists. The three blocklists that we use in 

OVRSEEN are not tailored for the Oculus platform. As a 

result, there could be domains that are ATS related but not 

labeled as such. To that end, we explored and leveraged data 

fows to fnd potential domains that are missed by blocklists. 

In particular, we start from data types exposed in our network 

traffc, and identify the destinations where these data types 

are sent to. Table 2 summarizes third-party destinations that 

collect the most data types and are not already captured by 

any of the blocklists. We found the presence of 11 different 

6 
FQDN Organization Data Types 

bdb51.playfabapi.com Microsoft 11 

sharedprod.braincloudservers.com bitHeads Inc. 8 

cloud.liveswitch.io Frozen Mountain 

Software 

7 

datarouter.ol.epicgames.com Epic Games 6 

9e0j15elj5.execute-api.us-west1.amazonaws.com 

Amazon 5 

Table 2: Top-5 third-party FQDNs that are missed by blocklists based on the number of data types exposed. 

Data Types (21) 

PII 1st 

Apps 

3rd Pl. 

FQDNs 

1st 3rd Pl. 

% Blocked 

1st 3rd Pl. 

Device ID 

User ID 

Android ID 

Serial Number 

Person Name 

Email 

Geolocation 

6 

5 

6 

0 

1 

2 

0 

64 

65 

31 

0 

7 

5 

5 

2 

0 

18 

18 

0 

0 

0 

6 

5 

6 

0 

1 

2 

0 

13 

13 

7 

0 

4 

5 

4 

1 

0 

2 

2 

0 

0 

0 

0 

20 

17 

-

0 

0 

-

38 

38 

43 

-

50 

20 

50 

100 

-

50 

50 

-

-

-

Fingerprint 

SDK Version 

Hardware Info 

System Version 

Session Info 

App Name 

Build Version 

Flags 

Usage Time 

Language 

Cookies 

VR Sensory Data 

23 

21 

16 

7 

4 

0 

6 

2 

5 

5 

69 

65 

62 

66 

65 

61 

53 

59 

28 

4 

20 

19 

19 

2 

2 

0 

2 

0 

16 

2 

34 

25 

20 

7 

4 

0 

6 

2 

5 

5 

28 

23 

21 

13 

10 

3 

8 

4 

9 

3 

4 

3 

3 

1 

1 

0 

1 

0 

1 

1 

6 

4 

5 

14 

25 

-

0 

0 

0 

0 

46 

39 

43 

46 

40 

100 

50 

50 

56 

33 

0 

33 

33 

100 

100 

-

100 

-

0 

100 

VR Play Area 

VR Movement 

VR Field of View 

VR Pupillary 

Distance 

0 

1 

0 

0 

40 

24 

16 

16 

0 

2 

0 

0 

0 

1 

0 

0 

1 

6 

1 

1 

0 

1 

0 

0 

-

0 

-

-

100 

67 

100 

100 

-

100 

-

-

Total 33 70 22 44 39 5 5 36 20 

Table 3: Data types exposed in the network traffc dataset. 

Column “Apps” reports the number of apps that send the data 

type to a destination; column “FQDNs” reports the number of 

FQDNs that receive that data type; and column “% Blocked” 

reports the percentage of FQDNs blocked by blocklists. Using 

sub-columns, we denote party categories: frst (1st), third (3rd), 

and platform (Pl.) parties. 

organizations, not caught by blocklists, including: Microsoft, 

bitHeads Inc., and Epic Games—the company that created 

the Unreal engine. The majority are cloud-based services that 

provide social features, such as messaging, and the ability to 

track users for engagement and monetization (e.g., promotions 

to different segments of users). We provide additional FQDNs 

missed by blocklists in Appendix C.2. 

7 

3.4 Data Flows in Context 

The exposure of a particular data type, on its own, does not 

convey much information: it may be appropriate or inappropriate depending on the context [40]. For example, geolocation 

sent to the GoogleEarth VR or Wander VR app is necessary 

for the functionality, while geolocation used for ATS purposes 

is less appropriate. The network traffc can be used to partly 

infer the purpose of data fows, e.g., depending on whether 

the destination being frst-, third-, or platform-party; or an 

ATS. Table 3 lists all data types found in our network traffc, 

extracted using the methods explained in Section 3.2.2. 

Third party. Half of the apps (70 out of 140) expose data 

fows to third-party FQDNs, 36% of which are labeled as 

ATS by blocklists. Third parties collect a number of PII data 

types, including Device ID (64 apps), User ID (65 apps), and 

Android ID (31 apps), indicating cross-app tracking. In addition, third parties collect system, hardware, and version info 

from over 60 apps—denoting the possibility that the data 

types are utilized to fngerprint users. Further, all VR specifc 

data types, with the exception of VR Movement, are collected 

by a single third-party ATS domain belonging to Unity. VR 

Movement is collected by a diverse set of third-party destinations, such as google-analytics.com, playfabapi.com and 

logs-01.loggly.com, implying that trackers are becoming interested in collecting VR analytics. 

Platform party. Our fndings on exposures to platformparty domains are a lower bound since not all platform traffc 

could be decrypted (see Section 7). However, even with limited decryption, we see a number of exposures whose destinations are fve third-party FQDNs. Although only one of these 

FQDNs is labeled as ATS by the blocklists, other platformparty FQDNs could be ATS domains that are missed by blocklists (see Section 3.3). For example, graph.facebook.com is an 

ATS FQDN, and graph.oculus.com appears to be its counterpart for OVR; it collects six different data types in our dataset. 

Notably, the platform party is the sole party responsible for 

collecting a sensitive hardware ID that cannot be reset by the 

user—the Serial Number. In contrast to OVR, the Android 

developer guide strongly discourages its use [19]. 

First party. Only 33 apps expose data fows to frst-party 

FQDNs, and only 5% of them are labeled as ATS. Interestingly, the blocklists tend to have higher block rates for frstparty FQDNs if they collect certain data types, e.g., Android 

ID (17%), User ID (20%), and App Name (25%). Popular 

data types collected by frst-party destinations are Hardware 

Info (21 apps), SDK Version (23 apps), and System Version 

(16 apps). For developers, this information can be used to 

prioritize bug fxes or improvements that would impact the 

most users. Thus, it makes sense that only ~5% of frst-party 

FQDNs that collect this information are labeled as ATS. 

Summary. The OVR ATS ecosystem is young when compared to Android and Smart TVs. It is dominated by tracking 
domains for social features and analytics, but not by ads. We 4.1.1 Consistency Analysis System 

have detailed 21 different data types that OVR sends to frst-, 

third-, and platform-parties. State-of-the-art blocklists only 

captured 36% of exposures to third parties, missing some 

sensitive exposures such as Email, User ID, and Device ID. 

4 OVRSEEN: Privacy Policy Analysis 

In this section, we turn our attention to the intended data 

collection and sharing practices, as stated in the text privacy 

policy. For example, from the text ”We may collect your email 

address and share it for advertising purposes”, we want to extract the collection statement (“we”, which implies the app’s 

frst-party entity; “collect” as action; and “email address” as 

data type) and the purpose (“advertising”). In Section 4.1.1, 

we present our methodology for extracting data collection 

statements, and comparing them against data fows found in 

network traffc for consistency. OVRSEEN builds and improves on state-of-the-art NLP-based tools: PoliCheck [5] 

and PolicyLint [4], previously developed for mobile apps. 

In Section 4.1.2, we present our VR-specifc ontologies for 

data types and entities. In Section 4.1.3, we report networkto-policy consistency results. Section 4.2 describes how we 

interface between the different NLP models of PoliCheck and 

Polisis to extract the data collection purpose and other context 

for each data fow. 

Collecting privacy policies. For each app in Section 3, we 

also collected its privacy policy on the same day that we 

collected its network traffc. Specifcally, we used an automated Selenium [59] script to crawl the webstore and extracted URLs of privacy policies. For apps without a policy 

listed, we followed the link to the developer’s website to fnd 

a privacy policy. We also included eight third-party policies 

(e.g., from Unity, Google), referred to by the apps’ policies. 

For the top-50 free apps on the Oculus store, we found that 

only 34 out of the 43 apps have privacy policies. Surprisingly, 

for the top-50 paid apps, we found that only 39 out of 49 

apps have privacy policies. For the top-50 apps on SideQuest, 

we found that only 29 out of 48 apps have privacy policies. 

Overall, among apps in our corpus, we found that only 102 

(out of 140) apps provide valid English privacy policies. We 

treated the remaining apps as having empty privacy policies, 

ultimately leading OVRSEEN to classify their data fows as 

omitted disclosures. 

4.1 Network-to-Policy Consistency 

Our goal is to analyze text in the app’s privacy policy, extract 

statements about data collection (and sharing), and compare 

them against the actual data fows found in network traffc. 

OVRSEEN builds on state-of-the-art tools: PolicyLint [4] and 

PoliCheck [5]. PolicyLint [4] provides an NLP pipeline that 

takes a sentence as input. For example, it takes the sentence 

“We may collect your email address and share it for advertising 

purposes”, and extracts the collection statement “(entity: we, 

action: collect, data type: email address)”. More generally, 

PolicyLint takes the app’s privacy policy text, parses sentences 

and performs standard NLP processing, and eventually extracts data collection statements defned as the tuple P =happ, 

data type, entityi, where app is the sender and entity is the 

recipient performing an action (collect or not collect) on the 

data type. PoliCheck [5] takes the app’s data fows (extracted 

from the network traffc and defned as F =hdata type, entityi) 

and compares it against the stated P for consistency. 

PoliCheck classifes the disclosure of F as clear (if the data 

fow exactly matches a collection statement), vague (if the 

data fow matches a collection statement in broader terms), 

omitted (if there is no collection statement corresponding to 

the data fow), ambiguous (if there are contradicting collection 

statements about a data fow), or incorrect (if there is a data 

fow for which the collection statement states otherwise). Following PoliCheck’s terminology [5], we further group these 

fve types of disclosures into two groups: consistent (clear and 

vague disclosures) and inconsistent (omitted, ambiguous, and 

incorrect) disclosures. The idea is that for consistent disclosures, there is a statement in the policy that matches the data 

type and entity, either clearly or vaguely. Table 4 provides 

real examples of data collection disclosures extracted from 

VR apps that we analyzed. 

Consistency analysis relies on pre-built ontologies and synonym lists used to match (i) the data type and destination that 

appear in each F with (ii) any instance of P that discloses the 

same (or a broader) data type and destination2. OVRSEEN’s 

adaptation of ontologies specifcally for VR is described in 

Section 4.1.2. We also improved several aspects of PoliCheck, 

as described in detail in Appendix D.1. First, we added a feature to include a third-party privacy policy for analysis if it is 

mentioned in the app’s policy. We found that 30% (31/102) of 

our apps’ privacy policies reference third-party privacy policies, and the original PoliCheck would mislabel third-party 

data fows from these apps as omitted. Second, we added a 

feature to more accurately resolve frst-party entity names. 

Previously, only frst-person pronouns (e.g., “we”) were used 

to indicate a frst-party reference, while some privacy policies 

use company and app names in frst-party references. The 

original PoliCheck would incorrectly recognize these frst2For example (see Fig. 3a), “email address” is a special case of “contact 

info” and, eventually, of “pii”. There is a clear disclosure w.r.t. data type if 

the “email address” is found in a data fow and a collection statement. A 

vague disclosure is declared if the “email address” is found in a data fow 

and a collection statement that uses the term “pii” in the privacy policy. An 

omitted disclosure means that “email address” is found in a data fow, but 

there is no mention of it (or any of its broader terms) in the privacy policy. 

8 
Disclosure Type Privacy Policy Text Action : Data Collection Statement (P) Data Flow (F) 

Clear “For example, we collect information ..., and a collect : hcom.cvr.terminus, usage time, wei husage time, wei

timestamp for the request.” 

Vague “We will share your information (in some cases collect : hcom.HomeNetGames.WW1oculus, hserial number, oculusi

personal information) with third-parties, ...” pii, third partyi handroid id, oculusi

Inconsistent Consistent 

Omitted - collect : hcom.kluge.SynthRiders, -, -i hsystem version, oculusi

hsdk version, oculusi

hhardware information, oculusi

Ambiguous “..., Skydance will not disclose any Personally 

Identifable Information to third parties ... 

your Personally Identifable Information will be 

disclosed to such third parties and ...” 

collect : hcom.SDI.TWD, pii, third partyi hserial number, oculusi

handroid id, oculusi

Incorrect “We do not share our customer’s personal information with unaffliated third parties ...” not_collect : hcom.downpourinteractive. 

onward, pii, third partyi

hdevice id, unityi

huser id, oculusi

Table 4: Examples to illustrate the types of disclosures identifed by PoliCheck. A data collection statement (P) is extracted 

from the privacy policy text and is defned as the tuple P =happ, data type, entityi. A data fow (F) is extracted from the network 

traffc and is defned as F =hdata type, entityi. During the consistency analysis, each P can be mapped to zero, one, or more F. 

party references as third-party entities for 16% (16/102) of 

our apps’ privacy policies. 

4.1.2 Building Ontologies for VR 

Ontologies are used to represent subsumptive relationships 

between terms: a link from term A to term B indicates that A is 

a broader term (hypernym) that subsumes B. There are two ontologies, namely data and entity ontologies: the data ontology 

maps data types and entity ontology maps destination entities. 

Since PoliCheck was originally designed for Android mobile 

app’s privacy policies, it is important to adapt the ontologies 

to include data types and destinations specifc to VR’s privacy 

policies and actual data fows. 

VR data ontology. Fig. 3a shows the data ontology we developed for VR apps. Leaf nodes correspond to all 21 data 

types found in the network traffc and listed in Table 3. Nonleaf nodes are broader terms extracted from privacy policies 

and may subsume more specifc data types, e.g., “device identifer” is a non-leaf node that subsumes “android id”. We built 

a VR data ontology, starting from the original Android data 

ontology, in a few steps as follows. First, we cleaned up the 

original data ontology by removing data types that do not 

exist on OVR (e.g., “IMEI”, “SIM serial number”, etc.). We 

also merged similar terms (e.g., “account information” and 

“registration information”) to make the structure clearer. Next, 

we used PoliCheck to parse privacy policies from VR apps. 

When PoliCheck parses the sentences in a privacy policy, it 

extracts terms and tries to match them with the nodes in the 

data ontology and the synonym list. If PoliCheck does not fnd 

a match for the term, it will save it in a log fle. We inspected 

each term from this log fle, and added it either as a new node 

in the data ontology or as a synonym to an existing term in 

the synonym list. Finally, we added new terms for data types 

identifed in network traffc (see Section 3.4) as leaf nodes in 

the ontology. Most notably, we added VR-specifc data types 

(see VR Sensory Data category shown in Table 3): “biometric info” and “environment info”. The term “biometric info” 

includes physical characteristics of human body (e.g., height, 

weight, voice, etc.); we found some VR apps that collect 

user’s “pupillary distance” information. The term “environment information” includes VR-specifc sensory information 

that describes the physical environment; we found some VR 

apps that collect user’s “play area” and “movement”. Table 5 

shows the summary of the new VR data ontology. It consists 

of 63 nodes: 39 nodes are new in OVRSEEN’s data ontology. 

Overall, the original Android data ontology was used to track 

12 data types (i.e., 12 leaf nodes) [5], whereas our VR data 

ontology is used to track 21 data types (i.e., 21 leaf nodes) 

appearing in the network traffc (see Table 3 and Fig. 3a). 

VR entity ontology. Entities are names of companies and 

other organizations which refer to destinations. We use a list 

of domain-to-entity mappings to determine which entity each 

domain belongs to (see Appendix D.1)—domain extraction 

and categorization as either frst-, third-, or platform-party 

are described in detail in Section 3.2.2. We modifed the Android entity ontology to adapt it to VR as follows: (1) we 

pruned entities that were not found in privacy policies of VR 

apps or in our network traffc dataset, and (2) we added new 

entities found in both sources. Table 5 summarizes the new 

entity ontology. It consists of 64 nodes: 21 nodes are new in 

OVRSEEN’s entity ontology. Fig. 3b shows our VR entity 

ontology, in which we added two new non-leaf nodes: “platform provider” (which includes online distribution platforms 

or app stores that support the distribution of VR apps) and 

“api” (which refers to various third-party APIs and services 

that do not belong to existing entities). We identifed 16 new 

entities that were not included in the original entity ontology. 

We visited the websites of those new entities and found that: 

three are platform providers, four are analytic providers, and 

12 are service providers; these become the leaf nodes of “api”. 

We also added a new leaf node called “others” to cover a few 

data fows, whose destinations cannot be determined from the 

IP address or domain name. 

9 
(a) Data Ontology (b) Entity Ontology 

Figure 3: Ontologies for VR data fows. Please recall that each data fow, F, is defned as F =hdata type, entityi. We started 

from the PoliCheck ontologies, originally developed for Android (printed in gray). First, we eliminated nodes that did not appear 

in our VR network traffc and privacy policies. Then, we added new leaf nodes (printed in black) based on new data types found 

in the VR network traffc and/or privacy policies text. Finally, we defned additional non-leaf nodes, such as “biometric info” and 

”api”, in the resulting VR data and entity ontologies. 

Platform Data Ontology Entity Ontology 

Android [5] 38 nodes 209 nodes 

OVR (OVRSEEN) 63 nodes 64 nodes 

New nodes in OVR 39 nodes 21 nodes 

Table 5: Comparison of PoliCheck and OVRSEEN Ontologies. 

Nodes include leaf nodes (21 data types and 16 entities) and 

non-leaf nodes (see Fig. 3). 

Summary. Building VR ontologies has been non-trivial. 

We had to examine a list of more than 500 new terms and 

phrases that were not part of the original ontologies. Next, we 

had to decide whether to add a term into the ontology as a new 

node, or as a synonym to an existing node. In the meantime, 

we had to remove certain nodes irrelevant to VR and merge 

others because the original Android ontologies were partially 

machine-generated and not carefully curated. 

4.1.3 Network-to-Policy Consistency Results 

We ran OVRSEEN’s privacy policy analyzer to perform 

network-to-policy consistency analysis. Please recall that we 

extracted 1,135 data fows from 140 apps (see Section 3.2.2). 

OVR data fow consistency. In total, 68% (776/1,135) data 

fows are classifed as inconsistent disclosures. The large majority of them 97% (752/776) are omitted disclosures, which 

are not declared at all in the apps’ respective privacy policies. 

Fig. 4 presents the data-fow-to-policy consistency analysis 

results. Out of 93 apps which expose data types, 82 apps have 

at least one inconsistent data fows. Among the remaining 

32% (359/1,135) consistent data fows, 86% (309/359) are 

classifed as vague disclosures. They are declared in vague 

terms in the privacy policies (e.g., the app’s data fows contain 

the data type “email address”, whereas its privacy policy only 

declares that the app collects “personal information”). Clear 

disclosures are found in only 16 apps. 

Data type consistency. Fig. 5a reports network-to-policy 

consistency analysis results by data types—recall that in Section 3.2.2 we introduced all the exposed data types into three 

categories: PII, Fingerprint, and VR Sensory Data. The PII 

category contributes to 22% (250/1,135) of all data fows. 

Among the three categories, PII has the best consistency: 57% 

(142/250) data fows in this category are classifed as consistent disclosures. These data types are well understood and also 

treated as PII in other platforms. On Android [5], it is reported 

that 59% of PII fows were consistent—this is similar to our 

observation on OVR. The Fingerprint category constitutes 

69% (784/1,135) of all data fows: around 25% (199/784) of 

data fows in this category are classifed as consistent disclosures. The VR Sensory Data category constitutes around 9% 

(101/1,135) of all data fows—this category is unique to the 

VR platform. Only 18% (18/101) data fows of this category 

are consistent—this indicates that the collection of data types 

in this category is not properly disclosed in privacy policies. 

10 
consistent inconsistent

1st party

facebook

unity

1st party

(platform)

oculus

facebook

unity

(other 3rd parties)

google

playfab

amplitude

epic

avatar sdk

 

1st party

(platform)

oculus

facebook

unity

(other 3rd parties)

google

playfab

dreamlo

amplitude mixpanel microsoft

github

epic

avatar sdk

 

1st party

unity

playfab

 

1st party

oculus

unity

amplitude

Entity

(PII)

user id

device id

android id

serial number

person name

email address

geolocation

(Fingerprint)

sdk version

hardware info

system version

session info

app name

build version

usage time

flags

language

cookie

(VR Sensory Data)

vr play area

vr movement

vr field of view

vr pupillary distance Data Type

1 11 3 24 8 1 2 2 1 1 24 3 2 1 1 1

4 1 1 35 6 2 2 1 1 24 3 2 1 2 1 1

4 9 8 1 17 1 1 1 7 6 1 10 2 2 1 2 1

9 8 1 7 6 1 2

2 2 1 2 1 1

2 1 1 1 1 1 1

2 1 3 1 1

11 9 1 1 13 20 20 49 21 3 3 3 2 2 2 2 2 1

11 1 1 12 1 10 18 17 1 49 18 1 2 3 1 1 2 1

2 7 1 1 12 7 18 17 1 48 16 2 2 3 1 1

11 6 1 1 4 1 1 50 12 2 1 3 2

3 1 1 12 1 1 1 49 6 2 2

12 49

1 11 1 20 1 28

2 1 1 10 4 1 1 43 3 2

4 8 8 14 5 1 2 6 6 9 2 1 2 1

1 2 1 1 2 1 1 4 1 1

7 33

1 4 1 1 1 16 6 2 1 1

3 13

3 10 3

clear vague omitted incorrect ambiguous

0

10

20

30

40

50

Number of Data Flows

Figure 4: Summary of network-to-policy consistency analysis results. Columns whose labels are in parentheses provide 

aggregate values: e.g., column “(platform)” aggregates the columns “oculus” and “facebook”; column “(other 3rd parties)” 

aggregates the subsequent columns. The numbers count data fows; each data fow is defned as happ, data type, destinationi). 

Entity consistency. Fig. 5b reports our network-to-policy 

consistency results, by entities. Only 29% (298/1,022) of thirdparty and platform data fows are classifed as consistent disclosures. First-party data fows constitute 10% (113/1,135) of 

all data fows: 54% (61/113) of these frst-party data fows are 

classifed as consistent disclosures. Thus, 69% (785/1,135) of 

all data fows are classifed as inconsistent disclosures. Thirdparty and platform data fows constitute 90% (1,022/1,135) of 

all data fows—surprisingly, only 29% (298/1,022) of these 

third-party and platform data fows are classifed as consistent 

disclosures. 

Unity is the most popular third-party entity, with 66% 

(746/1,135) of all data fows. Only 31% (232/746) of these 

Unity data fows are classifed as consistent, while the majority (69%) are classifed as inconsistent disclosures. Platform (i.e., Oculus and Facebook) data fows account for 11% 

(122/1,135) of all data fows; only 28% (34/122) of them are 

classifed as consistent disclosures. Other less prevalent entities account only around 14% (154/1,135) of all data fows. 

Referencing Oculus and Unity privacy policies. Privacy 

policies can link to each other. For instance, when using Quest 

2, users should be expected to consent to the Oculus privacy 

policy (for OVR). Likewise, when app developers utilize a 

third party engine (e.g., Unity) their privacy policies should 

include the Unity privacy policy. To the best of our knowledge, 

this aspect has not been considered in prior work [5, 29, 72]. 

Interestingly, when we included the Oculus and Unity 

privacy policies (when applicable) in addition to the app’s 

own privacy policy, we found that the majority of platform 

(116/122 or 96%) and Unity (725/746 or 97%) data fows get 

classifed as consistent disclosures. Thus, 74% (841/1,135) of 

all data fows get classifed as consistent disclosures. Fig. 6 

shows the comparison of the results from this new experiment 

with the previous results shown in Fig. 5b. These show that 

data fows are properly disclosed in Unity and Oculus privacy 

policies even though the app developers’ privacy policies 

usually do not refer to these two important privacy policies. 

Furthermore, we noticed that the Oculus and Unity privacy 

policies are well-written and clearly disclose collected data 

types. As discussed in [5], developers may be unaware of their 

responsibility to disclose third-party data collections, or they 

may not know exactly how third-party SDKs in their apps 

collect data from users. This is a recommendation for future 

improvement. 

Validation of PoliCheck results (network-to-policy consistency). To test the correctness of PoliCheck when applied 

to VR apps, we manually inspected all data fows from apps 

that provided a privacy policy, and checked their consistency 

with corresponding collection statements in the policy. Three 

authors had to agree on the consistency result (one of the fve 

disclosure types) of each data fow. We found the following. 

First, we considered multi-class classifcation into consistent, omitted and incorrect disclosures, similar to PoliCheck’s 

evaluation [5]. The performance of multi-class classifcation 

11 
0 50 100

Number of Data Flows

vr field of view

vr pupillary distance

vr movement

vr play area

(VR Sensory Data)

cookie

language

build version

usage time

flags

app name

session info

system version

hardware info

sdk version

(Fingerprint)

geolocation

email address

person name

serial number

android id

device id

user id

(PII)

Data Type

clear

vague

omitted

incorrect

ambiguous

(a) 

0 200 400 600

Number of Data Flows

microsoft

avatar sdk

mixpanel

github

dreamlo

google

epic

facebook

amplitude

playfab

oculus

unity

1st party

Entity

clear

vague

omitted

incorrect

ambiguous

(b) 

Figure 5: Network-to-policy consistency analysis results aggregated by (a) data types, and (b) destination entities. 

can be assessed using micro-averaging or macro-averaging 

of metrics across classes. Micro-averaging is more appropriate for imbalanced datasets and was also used for consistency analysis of Android apps [5] and Alexa skills [29]. In 

our VR dataset, we obtained 84% micro-averaged precision, 

recall and F1-score3. This is comparable to the corresponding numbers when applying PoliCheck to mobile [5] and 

Alexa Skills [29], which reported 90.8% and 83.3% (microaveraged) precision/recall/F1-score, respectively. For completeness, we also computed the macro-averaged precision, 

recall and F1-score to be 74%, 89%, and 81% respectively 

(see Table 8). 

Second, we considered the binary classifcation case (i.e., 

we treat inconsistent disclosures as positive and consistent 

disclosures as negative samples). We obtained 77% precision, 

94% recall, and 85% F1-score (see Appendix D.2 for more 

details). Overall, PoliCheck, along with our improvements for 

OVRSEEN, works well on VR apps4. 

3In multi-class classifcation, every misclassifcation is a false positive 

for one class and a false negative for other classes; thus, micro-averaged 

precision, recall, and F1-score are all the same (see Appendix D.2). 4However, the precision is lower when distinguishing between clear and 

0 200 400 600

Number of Data Flows

unity

oculus

1st party

Entity

previous results

clear

vague

omitted

incorrect

ambiguous

Figure 6: Referencing Oculus and Unity privacy policies. 

Comparing the results from the ideal case (including Unity 

and Oculus privacy policies by default) and the previous actual results (only including the app’s privacy policy and any 

third-party privacy policies linked explicitly therein). 

4.2 Data Collection in Context 

Consistent (i.e., clear, or even vague) disclosures are desirable 

because they notify the user about the VR apps’ data collection and sharing practices. However, they are not suffcient to 

determine whether the information fow is within its context 

or social norms. This context includes (but is not limited to) 

the purpose and use, notice and consent, whether it is legally 

required, and other aspects of the “transmission principle” in 

the terminology of contextual integrity [40]. In the previous 

section, we have discussed the consistency of the network 

traffc w.r.t. the privacy policy statements: this provides some 

context. In this section, we identify an additional context: we 

focus on the purpose of data collection. 

Purpose. We extract purpose from the app’s privacy policy using Polisis [21]—an online privacy policy analysis service based on deep learning. Polisis annotates privacy policy 

texts with purposes at text-segment level. We developed a 

translation layer to map annotated purposes from Polisis into 

consistent data fows (see Appendix D.3). This mapping is 

possible only for data fows with consistent disclosures, since 

we need the policy to extract the purpose of a data fow. We 

were able to process 293 (out of 359) consistent data fows5 

that correspond to 141 text segments annotated by Polisis. 

Out of the 293 data fows, 69 correspond to text segments annotated as “unspecifc”, i.e., Polisis extracted no purpose. The 

remaining 224 data fows correspond to text segments annotated with purposes. Since a data fow can be associated with 

multiple purposes, we expanded the 224 into 370 data fows, 

so that each data fow has exactly one purpose. There are nine 

distinct purposes identifed by Polisis (including advertising, 

analytics, personalization, legal, etc.; see Fig. 7). 

vague disclosures. Our validation shows 23% vague disclosures were actually clearly disclosed. This is because OVRSEEN’s privacy policy analyzer 

inherits the limitations of PoliCheck’s NLP model which cannot extract data 

types and entities from a collection statement that spans multiple sentences.. 5Polisis did not process the text segments that correspond to the remaining 

66 consistent data fows: it did not annotate the text segments and simply 

reported that their texts were too short to analyze. 

12 
unity 255

Oculus 251

SideQuest 119

advertising 119

analytics 70

merger 64

user id 51

session info 45

usage time 44

1st party 43

additional feature 38

sdk version 29

language 27

android id 27

device id 27

marketing 27

hardware info 20

loggly 20 system version 19

oculus 19

playfab 15 basic feature 17

security 14

personalization 12

flags 11

app name 11

build version 11

email address 10

serial number 9

legal 9

vr movement 7

vr play area 7

person name 6

others 5

cookie 4

epic 4

vr field of view 3

facebook 3

vr pupillary distance 2

avatar sdk 2

google 2 gamesparks 1 firefox 1

Destination (Entity)

App

Purpose

Data Type

Figure 7: Data fows in context. We consider the data fows (happ, data type, destinationi) found in the network traffc, and, 

in particular, the 370 data fows associated with consistent disclosures. We analyze these in conjunction with their purpose 

as extracted from the privacy policy text and depict the augmented tuples happ, data type, destination, purpose i in the above 

alluvial diagram. The diagram is read from left to right, for example: (1) out of 251 data fows from the Oculus app store, no 

more than 51 data fows collect User ID and send it to various destinations; (2) the majority of User ID is collected by Unity; and 

(3) Unity is responsible for the majority of data fows with the purpose of advertising. Finally, the color scheme of the edges helps 

keep track of the fow. From App to Data Type, the color indicates the app store: blue for Oculus apps and gray for SideQuest 

apps. From Data Type to Destination, the color indicates the type of data collected: PII and VR Sensory Data data fows are in 

orange, while Fingerprinting data fows are in green. From Destination to Purpose, we use blue to denote frst-party destinations 

and red to denote third-party destinations. 

To further understand whether data collection is essential 

to app functionality, we distinguish between purposes that 

support core functionality (i.e., basic features, security, personalization, legal purposes, and merger) and those unrelated 

to core functionality (i.e., advertising, analytics, marketing, 

and additional features) [35]. Intuitively, core functionality indicates services that users expect from an app, such as reading 

articles from a news app or making a purchase with a shopping 

app. We found that only 31% (116/370) of all data fows are related to core functionality, while 69% (254/370) are unrelated. 

Interestingly, 81% (94/116) of core-functionality-related data 

fows are associated with third-party entities, indicating that 

app developers use cloud services. On the other hand, data 

collection purposes unrelated to core functionality can be 

used for marketing emails or cross-platform targeted advertisements. This is partly also corroborated by our ATS fndings 

in Section 3.3: 83% (211/254) are associated with third-party 

tracking entities. In OVR, data types can be collected for 

tracking purposes and used for ads on other mediums (e.g., 

Facebook website) and not on the Quest 2 device itself. 

Next, we looked into the data types exposed for different 

purposes. The majority of data fows related to core functionality (56% or 65/116) expose PII data types, while Fingerprinting data types appear in most (66% or 173/254) data fows 

unrelated to functionality. We found that 15 data types are 

collected for functionality: these are comprised of Fingerprinting (41% or 48/116 data fows) and VR Sensory Data (3% or 

3/116 data fows). We found that 19 data types are collected 

for purposes unrelated to functionality: these are comprised 

of PII (26% or 65/254 data fows) and VR Sensory Data (6% 

or 16/254 data fows). Interestingly, VR Movement, VR Play 

Area, and VR Field of View are mainly used for “advertising”, 

while VR Movement and VR Pupillary Distance are used for 

“basic features”, “security”, and “merger” purposes [21]. 

Validation of Polisis results (purpose extraction). In order to validate the results pertaining to purpose extraction, we 

read all the 141 text segments previously annotated by Polisis. 

Then, we manually annotated each text segment with one or 

more purposes (based on the nine distinct purposes identifed by Polisis). We had three authors look at each segment 

independently and then agree upon its annotation. We then 

compared our annotation with the purpose output by Polisis 

for the same segment. We found that this purpose extraction 

has 80%, 79%, and 78% micro-averaged precision, recall, and 

F1-score respectively6. These micro-averaged results are directly comparable to the Polisis’ results in [21]: OVRSEEN’s 

purpose extraction works well on VR apps. For completeness, 

we also computed the macro-averaged precision, recall, and 

6Please note that this is multi-label classifcation. Thus, unlike multi-class 

classifcation for PoliCheck, precision, recall, and F1-score are different. 

13 
F1-score: 81%, 78%, and 78%, respectively. Table 9 in Appendix D.3 reports the precision, recall, and F1-score for each 

purpose classifcation, and their micro- and macro-averages. 

5 Discussion 

5.1 VR-Specifc Considerations 

VR tracking has unique aspects and trends compared to other 

ecosystems, including but not limited to the following. 

VR ads. The VR advertising ecosystem is currently at its 

infancy. Our analysis of destinations from the network traffc 

revealed that ad-related activity was missing entirely from 

OVR at the time of our experiments. Facebook recently started 

testing on-device ads for Oculus in June 2021 [44]. Ads on 

VR platforms will be immersive experiences instead of fat 

visual images; for example, Unity uses separate virtual rooms 

for ads [63]. We expect that tracking will further expand once 

advertising comes into VR (e.g., to include tracking how 

users interact and behave within the virtual ad space). As VR 

advertising and tracking evolve, our OVRSEEN methodology, 

system, and datasets will continue to enable analysis that was 

not previously possible on any VR platforms. 

Comparison to other ecosystems. Our analysis showed 

that the major players in the OVR tracking ecosystem are 

currently Facebook and Unity (see Fig. 2 and 5). The more 

established ecosystems such as mobile and Smart TVs are 

dominated by Alphabet [25,67]; they also have a more diverse 

playing feld of trackers (e.g., Amazon, Comscore Inc., and 

Adobe)—spanning hundreds of tracking destinations [25, 55, 

67]. OVR currently has only a few players (e.g., Facebook, 

Unity, Epic, and Alphabet). OVRSEEN can be a useful tool 

for continuing the study on this developing ecosystem. 

Sensitive data. Compared to other devices, such as mobile, 

Smart TVs and IoT, the type of data that can be collected from 

a VR headset is arguably more sensitive. For example, OVR 

has access to various biometric information (e.g., pupillary 

distance, hand geometry, and body motion tracking data) that 

can be used to identify users and even infer their health [43]. 

A study by Miller et al. [36] revealed the feasibility of identifying users with a simple machine learning model using less 

than fve minutes of body motion tracking data from a VR 

device. Our experiments found evidence of apps collecting 

data types that are unique to VR, including biometric-related 

data types (see Section 3.2.2). While the numbers we found 

are small so far, with the developing VR tracking ecosystem, 

it is important to have a system such as OVRSEEN to detect 

the increasing collection of sensitive data over time. 

Generalization. Within OVR, we only used OVRSEEN to 

analyze 140 apps in our corpus. However, we believe that it 

can be applied to other OVR apps, as long as they are created 

according to OVR standards. Beyond OVR, the network traffc 

analysis and network-to-policy consistency analysis can also 

be applied to other platforms, as long as their network traffc 

can be decrypted, as was the case with prior work on Android, 

Smart TV, etc. [37, 48, 54, 67]. 

5.2 Recommendations 

Based on our fndings, we provide recommendations for the 

OVR platform and developers to improve their data transparency practices. 

Provide a privacy policy. We found that 38 out of the 140 

popular apps, out of which 19 are from the Oculus app store, 

did not provide any privacy policy at all. Furthermore, 97% 

of inconsistent data fow disclosures were due to omitted 

disclosures by these 38 apps missing privacy policies (see 

Section 4). We recommend that the OVR platform require developers to provide a privacy policy for their apps, especially 

those available on the offcial Oculus app store. 

Reference other parties’ privacy policies. Developers are 

not the only ones collecting data during the usage of an app: 

third-parties (e.g., Unity, Microsoft) and platform-party (e.g., 

Oculus/Facebook) can also collect data. We found that 81 

out of 102 app privacy policies did not reference policies of 

third-party libraries used by the app. We recommend that 

developers reference third-party and platform-party privacy 

policies. If they do that, then the consistency of disclosures 

will be quite high: up to 74% of data fows in the network 

traffc we collected (see Section 4.1.3). This indicates that, at 

least at this early stage, the VR ecosystem is better behaved 

than the mobile tracking ecosystem. 

Notice and consent. We found that fewer than 10 out of 

102 apps that provide a privacy policy explicitly ask users to 

read it and give consent to data collection (e.g., for analytics 

purposes) upon frst opening the app. We recommend that developers provide notice and ask for users’ consent (e.g., when 

a user launches the app for the frst time) for data collection 

and sharing, as required by privacy laws such as GDPR [70]. 

Notifying developers. We contacted Oculus as well as the 

developers of the 140 apps that we tested. We provided courtesy notifcations of the specifc data fows and consistency 

we identifed in their apps, along with recommendations. We 

received 24 responses (see the details in Appendix E). Developers were, in general, appreciative of the information and 

willing to adopt recommendations to improve their privacy 

policies. Several indicated they did not have the training or 

tools to ensure consistent disclosures. 

6 Related Work 

Privacy in Context. The framework of “Privacy in Context" [40] specifes the following aspects of information fow: 

14 
(1) actors: sender, recipient, subject; (2) type of information; and (3) transmission principle. The goal is to determine 

whether the information fow is appropriate within its context. The “transmission principle" is key in determining the 

appropriateness of the fow and may include: the purpose of 

data collection, notice and consent, required by law, etc. [40]. 

In this paper, we seek to provide context for the data fows 

(happ, data type, destinationi) found in the network traffc. 

We primarily focus on the network-to-policy consistency, purpose of data collection, and we briefy comment on notice 

and consent. Most prior work on network analysis only characterized destinations (frst vs. third parties, ATS, etc.) or data 

types exposed without additional contexts. One exception is 

MobiPurpose [24], which inferred data collection purposes of 

mobile (not VR) apps, using network traffc and app features 

(e.g., URL paths, app metadata, domain name, etc.); the authors stated that “the purpose interpretation can be subjective 

and ambiguous”. Our notion of purpose is explicitly stated 

in the privacy policies and/or indicated by the destination 

domain matching ATS blocklists. Shvartzshnaider et al. introduced the contextual integrity (CI) framework to understand 

and evaluate privacy policies [57]—they, however, leveraged 

manual inspection and not automation. 

Privacy of various platforms. The research community 

has looked into privacy risks in various platforms, using static 

or dynamic code analysis, and—most relevant to us—network 

traffc analysis. Enck et al. performed static analysis of Android apps [13] and discovered PII misuse (e.g., personal/-

phone identifers) and ATS activity. Taintdroid, frst introduced taint tracking for mobile apps [12]. Ren et al. [49] 

did a comprehensive evaluation of information exposure on 

smart home IoT devices. Moghaddam et al. and Varmarken 

et al. observed the prevalence of PII exposures and ATS activity [37, 67] in Smart TVs. Lentzsch et al. [29] performed 

a comprehensive evaluation on Alexa, a voice assistant platform. Ren et al. [50], Razaghpanah et al. [48], and Shuba et 

al. [54–56] developed tools for analysis of network traffc generated by mobile apps, and inspection for privacy exposures 

and ATS activity. Our work is the frst to perform network 

traffc analysis on the emerging OVR platform, using dynamic 

analysis to capture and decrypt networking traffc on the device; this is more challenging for Unity and Unreal based 

apps because, unlike prior work that dealt with standard Android APIs, we had to deal with stripped binary fles (i.e., 

no symbol table). Augmented reality (AR) is another platform the research community has been focusing on in the 

past decade [1, 26, 28, 47, 51, 69]. While AR augments our 

perception and interaction with the real world, VR replaces 

the real world with a virtual one. Nevertheless, some AR privacy issues are similar to those in VR since they have similar 

sensors, e.g., motion sensors. 

tual keyboards) [11, 31–33], the privacy of VR is currently 

not fully understood. Adams et al. [2] interviewed VR users 

and developers on security and privacy concerns, and learnt 

that they were concerned with data collection potentially performed by VR devices (e.g., sensors, device being always 

on) and that they did not trust VR manufacturers (e.g., Facebook owning Oculus). Miller et al. present a study on the 

implications of the ability of VR technology to track body 

motions [36]. Our work is motivated by these concerns but 

goes beyond user surveys to analyze data collection practices 

exhibited in the network traffc and stated in privacy policies. 

Privacy policy analysis. Privacy policy and consistency analysis in various app ecosystems [4, 5, 21, 58, 68, 71, 72] is becoming increasingly automated. Privee [71] is a privacy policy 

analyzer that uses NLP to classify the content of a website privacy policy using a set of binary questions. Slavin et al. used 

static code analysis, ontologies, and information fow analysis 

to analyze privacy policies for mobile apps on Android [58]. 

Wang et al. applied similar techniques to check for privacy 

leaks from user-entered data in GUI [68]. Zimmeck et al. also 

leveraged static code analysis for privacy policy consistency 

analysis [72]; they improved on previous work by attempting 

to comply with legal requirements (e.g., frst vs. third party, 

negative policy statements, etc.). In Section 4, we leverage two 

state-of-the-art tools, namely PoliCheck [5] and Polisis [21], 

to perform data-fow-to-policy consistency analysis and to 

extract the data collection purpose, respectively. PoliCheck 

was built on top of PolicyLint [4], a privacy policy analyzer 

for mobile apps. It analyzes both positive and negative data 

collection (and sharing) statements, and detects contradictions. Lentzsch et al. also used off-the-shelf PoliCheck using 

a data ontology crafted for Alexa skills. OVRSEEN focuses 

on OVR and improves on PoliCheck in several ways, including VR-specifc ontologies, referencing third-party policies, 

and extracting data collection purposes. 

7 Conclusion 

Summary. We present the frst comprehensive study of privacy aspects for Oculus VR (OVR), the most popular VR 

platform. We developed OVRSEEN, a methodology and system to characterize the data collection and sharing practices 

of the OVR ecosystem by (1) capturing and analyzing data 

fows found in the network traffc of 140 popular OVR apps, 

and (2) providing additional contexts via privacy policy analysis that checks for consistency and identifes the purpose of 

data collection. We make OVRSEEN’s implementation and 

datasets publicly available at [62]. This is the extended version of our paper, with the same title, published at USENIX 

Security Symposium 2022. Please take a look at our project 

page for more information [62]. 

Privacy of VR. Although there is work on security aspects Limitations and future directions. On the networking 

of VR devices (e.g., authentication and attacks on using vir- side, we were able to decrypt, for the frst time, traffc of OVR 

15 
apps, but the OVR platform itself is closed and we could not 

decrypt most of its traffc. In future work, we will explore the 

possibility of addressing this limitation by further exploring 

binary analysis. On the privacy policy side, PoliCheck and 

Polisis rely on different underlying NLP model, with inherent 

limitations and incompatibilities—this motivates future work 

on a unifed privacy policy and context analyzer. 

Acknowledgment 

This project was supported by NSF Awards 1815666 and 

1956393. We would like to thank our shepherd, Tara Whalen, 

and the USENIX Security 2022 reviewers for their feedback, 

which helped to signifcantly improve the paper. We would 

also like to thank Yiyu Qian, for his help with part of our data 

collection process. 

References 

[1] A. Acquisti, R. Gross, and F. D. Stutzman. Face Recognition and Privacy in the Age of Augmented Reality. 

Journal of Privacy and Confdentiality, 6(2):1, 2014. 

[2] D. Adams, A. Bah, C. Barwulor, N. Musaby, K. Pitkin, 

and E. M. Redmiles. Ethics Emerging: the Story of 

Privacy and Security Perceptions in Virtual Reality. In 

SOUPS, Aug. 2018. 

[3] O. Alrawi, C. Lever, M. Antonakakis, and F. Monrose. 

SoK: Security Evaluation of Home-Based IoT Deployments. In IEEE SP, 2019. 

[4] B. Andow, S. Y. Mahmud, W. Wang, J. Whitaker, 

W. Enck, B. Reaves, K. Singh, and T. Xie. PolicyLint: 

Investigating Internal Privacy Policy Contradictions on 

Google Play. In USENIX Security, Aug. 2019. 

[5] B. Andow, S. Y. Mahmud, J. Whitaker, W. Enck, 

B. Reaves, K. Singh, and S. Egelman. Actions Speak 

Louder than Words: Entity-Sensitive Privacy Policy and 

Data Flow Analysis with PoliCheck. In USENIX Security, Aug. 2020. 

[6] ARMmbed. mbedtls: x509_crt.c. https:

//github.com/ARMmbed/mbedtls/blob/

development/library/x509_crt.c, 2021. 

[7] C. Brubaker and Android Security team. Changes to 

trusted certifcate authorities in android nougat. https:

//android-developers.googleblog.com/2016/

07/changes-to-trusted-certificate.html, July 

2016. 

[8] BSDgeek_Jake (XDA Developer). Moaab: Mother of all 

ad-blocking. https://forum.xda-developers.com/

showthread.php?t=1916098, 2019. 

[9] P. Cipolloni. Universal android ssl pinning bypass with 

frida. https://techblog.mediaservice.net/2017/

07/universal-android-ssl-pinning-bypasswith-frida/, July 2017. 

[10] Disconnect, Inc. disconnect-tracking-protection: 

Canonical repository for the disconnect services fle. 

https://github.com/disconnectme/disconnecttracking-protection, 2021. 

[11] R. Duezguen, P. Mayer, S. Das, and M. Volkamer. Towards Secure and Usable Authentication for Augmented 

and Virtual Reality Head-Mounted Displays. arXiv 

preprint arXiv:2007.11663, 2020. 

[12] W. Enck, P. Gilbert, B.-G. Chun, L. P. Cox, J. Jung, 

P. McDaniel, and A. N. Sheth. TaintDroid: An 

Information-Flow Tracking System for Realtime Privacy Monitoring on Smartphones. In OSDI, Oct. 2010. 

[13] W. Enck, D. Octeau, P. McDaniel, and S. Chaudhuri. 

A Study of Android Application Security. In USENIX 

Security, Aug. 2011. 

[14] Epic Games, Inc. Openssl (unreal version). https:

//github.com/EpicGames/UnrealEngine/tree/

master/Engine/Source/ThirdParty/OpenSSL, 

2021. 

[15] Epic Games, Inc. Unreal engine. https://

www.unrealengine.com/, 2021. 

[16] Facebook. Facebook to acquire oculus. 

https://about.fb.com/news/2014/03/facebookto-acquire-oculus/, March 2014. 

[17] E. Fernandes, J. Jung, and A. Prakash. Security Analysis 

of Emerging Smart Home Applications. In IEEE SP, 

2016. 

[18] Google. Android developers - behavior changes: 

all apps. https://developer.android.com/about/

versions/10/behavior-changes-all, 2021. 

[19] Google. Android developers - best practices 

for unique. https://developer.android.com/

training/articles/user-data-ids, 2021. 

[20] Google. Android developers - privacy changes in android 10. https://developer.android.com/about/

versions/10/privacy/changes, 2021. 

[21] H. Harkous, K. Fawaz, R. Lebret, F. Schaub, K. G. Shin, 

and K. Aberer. Polisis: Automated Analysis and Presentation of Privacy Policies Using Deep Learning. In 

USENIX Security, Aug. 2018. 

16 
[22] S. Hayden. Oculus quest 2 surpasses original quest in 

monthly active users. https://www.roadtovr.com/

oculus-quest-2-monthly-active-users/, January 2021. 

[23] D. Heaney. The oculus quest 2 ‘jailbreak’ seems to 

be fake. https://uploadvr.com/oculus-quest-2-

jailbreak-seems-fake/, November 2020. 

[24] H. Jin, M. Liu, K. Dodhia, Y. Li, G. Srivastava, 

M. Fredrikson, Y. Agarwal, and J. I. Hong. Why Are 

They Collecting My Data? Inferring the Purposes of 

Network Traffc in Mobile Apps. In ACM IMWUT, 

2018. 

[25] K. Kollnig, A. Shuba, R. Binns, M. V. Kleek, and 

N. Shadbolt. Are iPhones Really Better for Privacy? 

Comparative Study of iOS and Android Apps. arXiv 

preprint arXiv:2109.13722, 2021. 

[26] A. Kotsios. Privacy in an Augmented Reality. International Journal of Law and Information Technology, 

23(2):157–185, 2015. 

[27] B. Lang. Where to change quest 2 privacy settings and see your vr data collected by facebook. 

https://www.roadtovr.com/oculus-quest-2-

privacy-facebook-data-collection-settings/, 

October 2020. 

[28] K. Lebeck, K. Ruth, T. Kohno, and F. Roesner. Towards 

Security and Privacy for Multi-User Augmented Reality: 

Foundations with End Users. In IEEE SP, 2018. 

[29] C. Lentzsch, S. J. Shah, B. Andow, M. Degeling, A. Das, 

and W. Enck. Hey Alexa, is this Skill Safe?: Taking a 

Closer Look at the Alexa Skill Ecosystem. In NDSS, 

2021. 

[30] Y. Li, Z. Yang, Y. Guo, and X. Chen. DroidBot: a 

Lightweight UI-Guided Test Input Generator for Android. In IEEE/ACM ICSE-C, 2017. 

[31] Z. Ling, Z. Li, C. Chen, J. Luo, W. Yu, and X. Fu. I 

Know What You Enter on Gear VR. In IEEE CNS, 2019. 

[32] S. Luo, A. Nguyen, C. Song, F. Lin, W. Xu, and Z. Yan. 

OcuLock: Exploring Human Visual System for Authentication in Virtual Reality Head-mounted Display. In 

NDSS, 2020. 

[33] F. Mathis, J. H. Williamson, K. Vaniea, and M. Khamis. 

Fast and Secure Authentication in Virtual Reality using Coordinated 3D Manipulation and Pointing. ACM 

ToCHI, 2021. 

https://techcrunch.com/2020/09/23/theoculus-quests-unofficial-app-store-getsbacking-from-oculus-founder-palmer-luckey/, 

September 2020. 

[35] E. McCallister, T. Grance, and K. Scarfone. Guide to 

Protecting the Confdentiality of Personally Identifable 

Information (PII). Technical Report NIST Special Publication (SP) 800-122, 2010. 

[36] M. R. Miller, F. Herrera, H. Jun, J. A. Landay, and J. N. 

Bailenson. Personal Identifability of User Tracking 

Data during Observation of 360-degree VR Video. Scientifc Reports, 2020. 

[37] H. Mohajeri Moghaddam, G. Acar, B. Burgess, 

A. Mathur, D. Y. Huang, N. Feamster, E. W. Felten, 

P. Mittal, and A. Narayanan. Watching You Watch: The 

Tracking Ecosystem of Over-the-Top TV Streaming Devices. In ACM CCS, 2019. 

[38] Mozilla Corporation and Individual mozilla.org 

contributors. Privacy & security guide: Oculus quest 

2 vr headset. https://foundation.mozilla.org/

en/privacynotincluded/oculus-quest-2-vrheadset/, November 2020. 

[39] Mozilla Corporation and Individual mozilla.org contributors. What is fngerprinting and why you should block 

it. https://www.mozilla.org/en-US/firefox/

features/block-fingerprinting/, 2021. 

[40] H. Nissenbaum. Privacy in Context - Technology, Policy, 

and the Integrity of Social Life. 2010. 

[41] Oculus. A single way to log into oculus and unlock 

social features. https://www.oculus.com/blog/asingle-way-to-log-into-oculus-and-unlocksocial-features/, August 2020. 

[42] Oculus. Supplemental oculus data policy. https://

www.oculus.com/legal/privacy-policy/, October 

2020. 

[43] Oculus. Track your ftness in vr with oculus move. 

https://support.oculus.com/move/, 2021. 

[44] Oculus Blog. Testing In-Headset VR Ads. 

https://www.oculus.com/blog/testing-inheadset-vr-ads, Sep 2021. 

[45] Ole André V. Ravnås. Frida - dynamic instrumentation 

toolkit for developers, reverse-engineers, and security 

researchers. https://frida.re/, 2021. 

[34] L. Matney. The oculus quest’s unoffcial app store [46] Pi-hole. Pi-hole: Network-wide ad blocking. https:

gets backing from oculus founder palmer luckey. //pi-hole.net/, 2021. 

17 
[47] P. A. Rauschnabel, J. He, and Y. K. Ro. Antecedents 

to the Adoption of Augmented Reality Smart Glasses: 

A Closer Look at Privacy Risks. Journal of Business 

Research, 92:374–384, 2018. 

[48] A. Razaghpanah, R. Nithyanand, N. Vallina-Rodriguez, 

S. Sundaresan, M. Allman, C. Kreibich, and P. Gill. 

Apps, Trackers, Privacy, and Regulators: A Global Study 

of the Mobile Tracking Ecosystem. In NDSS, 2018. 

[49] J. Ren, D. J. Dubois, D. Choffnes, A. M. Mandalari, 

R. Kolcun, and H. Haddadi. Information Exposure From 

Consumer IoT Devices: A Multidimensional, NetworkInformed Measurement Approach. In IMC, 2019. 

[50] J. Ren, A. Rao, M. Lindorfer, A. Legout, and 

D. Choffnes. ReCon: Revealing and Controlling PII 

Leaks in Mobile Network Traffc. In MobiSys, 2016. 

[51] F. Roesner, T. Kohno, and D. Molnar. Security and Privacy for Augmented Reality Systems. CACM, 57(4):88– 

96, 2014. 

[52] S. Rogers. Virtual reality for good use cases: From 

educating on racial bias to pain relief during childbirth. 

https://www.forbes.com/sites/solrogers/2020/

03/09/virtual-reality-for-good-use-casesfrom-educating-on-racial-bias-to-painrelief-during-childbirth/, March 2020. 

[53] P. Sarnoff. The vr in the enterprise report: How 

retailers and brands are illustrating vr’s potential in 

sales, employee training, and product development. 

https://www.businessinsider.com/virtualreality-for-enterprise-sales-employeetraining-product-2018-12, December 2018. 

[54] A. Shuba, A. Le, E. Alimpertis, M. Gjoka, and 

A. Markopoulou. AntMonitor: A System for On-Device 

Mobile Network Monitoring and its Applications. arXiv 

preprint arXiv:1611.04268, 2016. 

[55] A. Shuba and A. Markopoulou. NoMoATS: Towards 

Automatic Detection of Mobile Tracking. In PETS, 

2020. 

[56] A. Shuba, A. Markopoulou, and Z. Shafq. NoMoAds: 

Effective and Effcient Cross-App Mobile Ad-Blocking. 

In PETS, 2018. 

[57] Y. Shvartzshnaider, N. Apthorpe, N. Feamster, and 

H. Nissenbaum. Going Against the (Appropriate) Flow: 

a Contextual Integrity Approach to Privacy Policy Analysis. In HCOMP, 2019. 

[58] R. Slavin, X. Wang, M. B. Hosseini, J. Hester, R. Krishnan, J. Bhatia, T. D. Breaux, and J. Niu. Toward a 

Framework for Detecting Privacy Policy Violations in 

Android Application Code. In ACM/IEEE ICSE, 2016. 

[59] Software Freedom Conservancy. Seleniumhq browser 

automation. https://www.selenium.dev/, 2021. 

[60] Spatial Systems, Inc. Spatial: Virtual spaces that bring 

us together. https://spatial.io/, 2021. 

[61] StackExchange. Micro Average vs Macro average 

Performance in a Multiclass classifcation setting. https://datascience.stackexchange.com/

questions/15989/micro-average-vs-macroaverage-performance-in-a-multiclassclassification-settin, 2017. 

[62] UCI Networking Group. OVRseen project page. https:

//athinagroup.eng.uci.edu/projects/ovrseen/. 

[63] Unity. The Virtual Room ad: a real way to make money 

in VR. https://create.unity3d.com/virtualroom-ad, 2021. 

[64] Unity Technologies. mbed tls: An open source, portable, 

easy to use, readable and fexible ssl library. https://

github.com/Unity-Technologies/mbedtls, 2021. 

[65] Unity Technologies. Unity - the leading platform 

for creating interactive, real-time content. https://

unity.com/, 2021. 

[66] Unity Technologies. Unity manual: Managed 

code stripping. https://docs.unity3d.com/Manual/

ManagedCodeStripping.html, 2021. 

[67] J. Varmarken, H. Le, A. Shuba, A. Markopoulou, and 

Z. Shafq. The TV is Smart and Full of Trackers: Measuring Smart TV Advertising and Tracking. In PETS, 

2020. 

[68] X. Wang, X. Qin, M. Bokaei Hosseini, R. Slavin, T. D. 

Breaux, and J. Niu. GUILeak: Tracing Privacy Policy 

Claims on User Input Data for Android Applications. In 

IEEE/ACM ICSE, 2018. 

[69] B. Wassom. Augmented Reality Law, Privacy, and 

Ethics: Law, Society, and Emerging AR Technologies. 

2014. 

[70] B. Wolford. What is gdpr, the eu’s new data protection 

law? https://gdpr.eu/what-is-gdpr/, 2019. 

[71] S. Zimmeck and S. M. Bellovin. Privee: An Architecture 

for Automatically Analyzing Web Privacy Policies. In 

USENIX Security, Aug. 2014. 

[72] S. Zimmeck, Z. Wang, L. Zou, R. Iyengar, B. Liu, 

F. Schaub, S. Wilson, N. M. Sadeh, S. M. Bellovin, 

and J. R. Reidenberg. Automated Analysis of Privacy 

Requirements for Mobile Apps. In NDSS, 2017. 

18 
APPENDICES 

A Data Privacy on Oculus 

In this appendix, we provide more details from our observations on data collection practices on OVR that complements 

our explanation in Section 2. In our preliminary observation, 

we discovered two fndings that motivate us to further study 

VR privacy in the context of OVR. 

First, we discovered that Oculus has been actively updating 

their privacy policy over the years. We collected different 

versions of Oculus privacy policy [42] over time using Wayback Machine and examined them manually. Most notably, 

we observed a major change in their privacy policy around 

May 2018. We suspect that this is due to the implementation 

of the GDPR on May 25, 2018 [70]—this has required Oculus 

to be more transparent about its data collection practices. For 

example, the privacy policy version before May 2018 declares 

that Oculus collects information about “physical movements 

and dimensions”. The version after May 2018 adds “play area” 

as an example for “physical movements and dimensions”. Although it has not been strictly categorized as PII, “play area” 

might represent the area of one’s home—it loosely contains 

“information identifying personally owned property” that can 

potentially be linked to an individual [35]. This motivates us 

to empirically study the data collection practices on OVR. We 

report how we use OVRSEEN to collect network traffc and 

study data exposures on OVR in Section 3. 

Second, we found that many apps do not have privacy policies. Even if they have one, we found that many developers 

neglect updating their privacy policies regularly. Many of 

these privacy policies even do not have last updated times 

information. We found that only around 40 (out of 267) apps 

from the offcial Oculus app store and 60 (out of 1075) apps 

from the SideQuest app store have updated their privacy policy texts in 2021. Thus, we suspect that an app’s actual data 

collection practices might not always be consistent with the 

app’s privacy policy. This motivates us to study how consistent an app’s privacy policy describes the app’s actual data 

collection practices. We report how we use OVRSEEN to 

analyze privacy policies in Section 4. 

B Network Traffc Collection Details 

In this appendix, we provide more details on OVRSEEN’s 

system for collecting and decrypting network traffc, introduced in Section 3.1. Fig. 8 depicts a detailed version of the 

network traffc collection system (i.e., 1 in Fig. 1), which 

consists of two main components—AntMonitor and Frida. In 

Appendix B.1, we describe the improvements we made to 

AntMonitor; and in Appendix B.2, we provide the detailed 

workfow of our automated binary analysis technique for fnding addresses of certifcate validation functions so that we can 

hook into them with Frida. 

Oculus Quest 2

App

Android SDK

Certificate verifier 

functions

Frida Agent

Frida Hooks

ADB

PC

Frida Client

Unity SDK

Mbed TLS

mbedtls_x509_crt_

verify_with_profile()

Android-SDK-verifierfunctions Hook

Address-based Hook

AntMonitor

PCAPNG

TLS Certificatepinning Bypass 

Script

Unreal SDK

Open SSL

x509_verify_cert()

Function-based Hook

Frida hook

ADB control

Network 

traffic

Figure 8: Network traffc collection and decryption. 

B.1 Improving AntMonitor 

The original version of AntMonitor has several limitations, 

which we address in this paper. First, the released version of 

AntMonitor supports only up to Android 7. Unfortunately, 

Quest 2 runs Oculus OS that is based on Android 10—a version of Android which underwent a multitude of changes 

to TLS [18] and flesystem access [20], effectively breaking 

AntMonitor’s decryption and packet-to-app mapping capabilities. To restore decryption, we frst downgraded all connections handled by AntMonitor to TLS 1.2 so that we can 

extract servers’ certifcates, which are encrypted in TLS 1.3 

(the default TLS version in Android 10). The servers’ certifcates are needed so that AntMonitor can sign them with its 

own CA and pass them on to the client app. In addition to 

downgrading the TLS version, we also updated to new APIs 

for setting the SNI (server name identifcation), since the original version used Java refection to access hidden methods 

which were no longer available in Android 10. Further, we 

updated how AntMonitor checks for trusted certifcates to 

remain compatible with Android 10’s stricter security requirements. Similarly, in order to fx the packet-to-app mapping, 

which relied on reading the now-restricted /proc/net fles, 

we re-implemented the functionality using Android 10’s new 

APIs from the ConnectivityManager. 

Second, AntMonitor prevents common traffc analysis 

tools, such as tshark, from re-assembling TCP streams because it saves both encrypted and decrypted versions of packets in the same PCAPNG fle and does not adjust the sequence 

and ack numbers accordingly. In our work, we wanted to take 

advantage of tshark’s re-assembly features, namely the desegmentation of TCP streams and HTTP headers and bodies, 

so that we could analyze parsed HTTP traffc with confdence. 

To that end, we modifed AntMonitor to keep track of decrypted sequence and ack numbers for each decrypted fow 

and to save decrypted packets in a separate PCAPNG fle 

with their adjusted sequence and ack numbers. Without this 

improvement, the encrypted and decrypted packets would 

share the same sequence and ack numbers, inhibiting TCP 

re-assembly. 

19 
Figure 9: Our decryption technique. Example on Spatial, 

an app that enables people to meet through VR [60]. 

In order to enable other researchers to continue using 

AntMonitor in newer Android versions, we will submit a pull 

request to its open source repository. 

B.2 Binary Analysis Workfow 

In Section 3.1 we introduced our automated binary analysis technique for fnding addresses of certifcate validation 

functions in Unity’s [64] library so that we can hook into 

them with Frida. Fig. 9 illustrates how this technique is applied on Spatial, an app that enables people to meet through 

VR [60], as our example. First (Step 1), we take the app’s 

APK fle and extract the version of the Unity framework used 

to package the app by scanning its confguration fles—here 

we fnd that the Spatial app uses Unity 2020.1.14f1. Second (Step 2), we try to fnd Unity 2020.1.14f1 from a 

collection of Unity frameworks (we frst have to download 

all versions of Unity onto our system). Third (Step 3), we locate mbedtls_x509_crt_verify_with_profile() in the 

(non-stripped) symbolicated pre-compiled Unity SDK binary fle that comes with Unity 2020.1.14f1. Subsequently, we extract the binary signature of the certifcate 

validation function, which consists of the 4 bytes preceding the start of the function (i.e., FD FD FF 17) and 

the frst 16 bytes starting from the function address (i.e., 

F7 5B BD A9 F5 53 01 A9 F3 7B 02 A9 F4 03 02 AA). 

We found that we could not use the entire function as our 

signature due to binary compilation optimizations and stripping. Fourth (Step 4), we use this binary signature to locate 

mbedtls_x509_crt_verify_with_profile() in the app’s 

stripped binary fle and extract its actual address—for the 

Spatial app the function is located at address 0x814468. Finally, we use this extracted address to set a Frida hook for 

mbedtls_x509_crt_verify_with_profile() in the Frida 

script (see Fig. 8). 

C Data Types and ATS Details 

In Appendix C.1, we provide details about how we identify 

and group data types, which complements our work in Section 3.2.2. In Appendix C.2, we provide the full list of potential ATS destinations that are missed by blocklists, which 

complements our work in Section 3.3. 

C.1 Extracting Data Types 

Please recall that Section 3.2.2 introduced our methodology 

for extracting data types from our network traffc dataset. 

Data types can be identifed through static values (e.g., 

Email, Serial Number, Android ID) which rely on string 

matching of keywords. On the other hand, dynamic values 

can change based on the application being tested (e.g., SDK 

Version), which rely on a combination of string matching 

and regular expressions. Table 6 provides the details on the 

keywords and regular expressions that we use to extract data 

types. For instance, to capture different versions of Unity SDK 

Versions being exposed, we rely on the regular expression 

UnityPlayer/[\d.]+\d. 

Our 21 data types are groups of other fner grain data types, 

detailed in Table 6. For example, the data type SDK Version 

considers both Unity and Unreal versions, while Usage Time 

considers the Start Time and Duration of app usage. Grouping 

of data types allows us to provide a more complete picture of 

data collection on OVR. 

C.2 Missed by Blocklists 

As OVR is an emerging platform, there are currently no specialized blocklists for it. To facilitate the identifcation of domains that are potential ATS, we target domains that collect 

multiple different data types. As a result, we extend Table 2 

from Section 3.3 and provide the full details of domains that 

were missed by blocklists in Table 7. 

D Privacy Policy Analysis Details 

In this appendix, we provide more details about OVRSEEN’s 

privacy policy analysis we described in Section 4. We describe the details of our improvements for PoliCheck in 

Appendix D.1, our manual validation for PoliCheck in Appendix D.2, and how we integrated Polisis into OVRSEEN 

(including our manual validation for Polisis) in Appendix D.3. 

20 
PII Finer Grain Data Types Keywords or Regular Expressions

Android ID - (hard-coded Android ID), android_id, x–android–id 

Device ID - (hard-coded Oculus Device ID), deviceid, device_id, device–id 

Email - (hard-coded user email address), email 

Geolocation Country Code, Time Zone, GPS countryCode, timeZoneOffset, gps_enabled 

Person Name First Name, Last Name (hard-coded from Facebook Account) 

Serial Number - (hard-coded Oculus Serial Number), x–oc–selected–headset–serial 

User ID User ID and PlayFab ID user_id, UserID, x–player, x–playeruid, profleId, anonymousId, PlayFabIDs 

Fingerprint 

App Name App Name and App Version app_name, appid, application_name, applicationId, X–APPID, gameId, package_name, 

app_build, localprojectid, android_app_signature, gameVersion, package_version 

Build Version - build_guid, build_tags 

Cookies 

Flags 

Hardware Info 

-

Do Not Track, Tracking, Jail Break, 

Subtitle On, Connection Type, Install Mode, Install Store, Scripting 

Backend 

Device Model, Device RAM, Device VRAM, CPU Vendor, CPU 

Flags, Platform CPU Count and Frequency, GPU Name, GPU Driver, 

GPU Information, OpenGL Version, Screen Resolution, Screen DPI, 

Fullscreen Mode, Screen Orientation, Refresh Rate, Device Info, Platform 

cookie 

x–do–not–track, tracking, rooted_or_jailbroken, rooted_jailbroken, subtitles, connection– 

type, install_mode, install_store, device_info_fags, scripting_backend 

device_model, device_type, enabled_vr_devices, vr_device_name, vr_device_model, 

Oculus/Quest/hollywood, Oculus[+ ]?Quest, Quest[ ]?2, device_ram, device_vram, Qualcomm Technologies, Inc KONA, ARM64 FP ASIMD AES, 

ARMv7 VFPv3 NEON, cpu_count, cpu_freq, ARM64+FP+ASIMD+AES, arm64-

v8a,+armeabi-v7a,+armeabi, Adreno (TM) 650, GIT@09c6a36, GIT@a8017ed, 

gpu_api, gpu_caps, gpu_copy_texture_support, gpu_device_id, gpu_vendor_id, 

gpu_driver, gpu_max_cubemap_size, gpu_max_texture_size, gpu_shader_caps, 

gpu_supported_render_target_count, gpu_texture_format_support, gpu_vendor, 

gpu_version, OpenGL ES 3.2, \+3664,\+1920 , 3664 x 1920, 3664x1920, width=3664, 

screen_size, screen_dpi, is_fullscreen, screen_orientation, refresh_rate, device_info_fags, 

releasePlatform, platform, platformid 

SDK Version 

Session Info 

Unity Version, Unreal Version, 

Client Library, VR Shell Version 

App Session, Session Counts, 

Events, Analytics, Play Session 

Status, Play Session Message, Play 

Session ID 

Unity[- ]?v?20[12]\d \.\d +\.\d +, Unity[- ]?v?[0-6]\.\d +\.\d +, 

UnityPlayer/[\d .]+\d, UnitySDK-[\d .]+\d, x–unity–version, sdk_ver, engine_version, X–Unity–Version, sdk_ver_full, ARCore, X-UnrealEngine-VirtualAgeStats, 

engine=UE4, UE4 0.0.1 clientLib, clientLibVersion, x–oc–vrshell–build–name 

AppSession, session_id, sessionid, event-id, event_id, objective_id, event-count, 

event_count, session-count, session_count, analytic, joinable, lastSeen, join_channel, JoinParty, SetPartyActiveGameOrWorldID, SetPartyIDForOculusRoomID, JoinOpenWorld, 

partyID, worldID, gameOrWorldID, oculusRoomID 

System Version - (hard-coded OS version strings), x-build-version-incremental, os_version, operatingSystem, os_family 

Usage Time Start Time, Duration t_since_start, startTime, realtimeDuration, seconds_played, game_time, gameDuration 

Language - language, language_region, languageCode, system_language 

VR Sensory Data 

VR Field of View - vr_feld_of_view 

VR Movement Position, Rotation, Sensor Flags vr_position, vr_rotation, gyroscope, accelerometer, magnetometer, proximity, sensor_fags, 

left_handed_mode 

VR Play Area Play Area, Play Area Geometry, Play 

Area Dimention, Tracked Area Geometry, Tracked Area Dimension 

vr_play_area_geometry, vr_play_area_dimension, playarea, vr_tracked_area_geometry, 

vr_tracked_area_dimension 

VR Pupillary Distance - vr_user_device_ipd 

Table 6: Extracting data types. Summarizes how we group data types and the keywords and regular expressions (italicized) that 

we use to identify them (Section 3.2 and Appendix C.1). 

21 
FQDN Organization Data Types 

bdb51.playfabapi.com, 1c31b.playfabapi.com Microsoft Android ID, User ID, Device ID, Person Name, Email, Geolocation, 

Hardware Info, System Version, App Name, Session Info, VR Movement 

sharedprod.braincloudservers.com bitHeads Inc. User ID, Geolocation, Hardware Info, System Version, SDK Version, 

App Name, Session Info, Language 

cloud.liveswitch.io Frozen Mountain Soft- User ID, Device ID, Hardware Info, System Version, App Name, Lanware guage, Cookie 

datarouter.ol.epicgames.com Epic Games User ID, Device ID, Hardware Info, SDK version, App Name, Session 

Info 

9e0j15elj5.execute-api.us-west-1.amazonaws.com Amazon User ID, Hardware Info, System Version, SDK Version, Usage Time 

63fdd.playfabapi.com Microsoft Android ID, User ID, Email, SDK Version, App Name 

us1-mm.unet.unity3d.com Unity Hardware Info, System Version, SDK Version, Usage Time 

scontent.oculuscdn.com Facebook Hardware Info, System Version, SDK Version 

api.avatarsdk.com Itseez3d User ID, Hardware Info, SDK Version 

52.53.43.176 Amazon Hardware Info, System Version, SDK Version 

kingspraymusic.s3-ap-southeast-2.amazonaws.com, Amazon Hardware Info, System Version, SDK Version 

s3-ap-southeast-2.amazonaws.com 

pserve.sidequestvr.com SideQuestVR Hardware Info, System Version, Language 

gsp-auw003-se24.gamesparks.net, GameSparks Device ID, Flags 

gsp-auw003-se26.gamesparks.net, 

gsp-auw003-se30.gamesparks.net, 

live-t350859c2j0k.ws.gamesparks.net 

yurapp-502de.frebaseapp.com Alphabet Hardware Info, SDK Version 

Table 7: Missed by blocklists continued. We provide third-party FQDNs that are missed by blocklists based on the number 

data types that are exposed. This is the full details of Table 2. 

D.1 Other PoliCheck Improvements 

In Section 4.1.1, we mentioned that we have improved 

PoliCheck in OVRSEEN. We detail the improvements below. 

Inclusion of third-party privacy policies. PoliCheck assumes that each app has one privacy policy. In practice, many 

apps do not disclose third-party data collection clearly in the 

privacy policies. Instead, they put links to external third-party 

policies and direct users to read them for more information. 

For example, consider the following sentence from one of the 

privacy policies of apps in our dataset: “For more information 

on what type of information Unity collects, please visit their 

Privacy Policy page <link>...” 

OVRSEEN’s privacy policy analyzer includes statements 

from external privacy policies if they are referred to in the 

app’s privacy policy. In this case, frst-person pronouns (e.g., 

“we”) in the external privacy policies are translated to the 

actual entity names (e.g., “Unity”). Thus, in the above example, the app’s data fows are checked against the policy 

statements extracted both from the app’s privacy policy and 

Unity’s privacy policy. 

Resolution of frst-party entity names. Some privacy 

policies use full company names to refer to the frst party, 

while PoliCheck only considers frst-person pronouns (e.g., 

“we”) as indications of frst-party references. Thus, we found 

that PoliCheck wrongly recognizes these company names as 

third parties. As a result, frst-party data fows of these apps 

were wrongly classifed as omitted disclosure. 

To fx this issue, OVRSEEN privacy policy analyzer uses a 

per-app list of frst-party names—this list was extracted from: 

(1) package names, (2) app store metadata, and (3) special 

sentences in privacy policies such as titles, the frst occurrence 

of a frst-party name, and copyright notices. These names are 

treated as frst party. 

Entities. Entities are names of companies and other organizations. We translate domains to entities in order to associate 

data fows with disclosures in the privacy policies in Section 4. 

Similar to [5], we use a manually-crafted list of domain-toentity mappings to determine which entity that each domain 

belongs to. For example, *.playfabapi.com is a domain of 

the entity Playfab. We started from the original PoliCheck’s 

mapping, and added missing domains and entities to it. We 

visited each new domain and read the information on the 

website to determine its entity. If we could not determine the 

entity for a domain, we labeled its entity as unknown third 

party. Fig. 3b displays a partial view of our entity ontology. 

22 
Label Prec. Recall F1 Support 

three-class classifcation 

consistent 0.93 0.74 0.82 454 

incorrect 0.50 1.00 0.67 2 

omitted 0.77 0.94 0.85 425 

macro-average 0.74 0.89 0.81 

micro-average 0.84 0.84 0.84 

binary classifcation 

inconsistent (positive) 0.77 0.94 0.85 427 

consistent (negative) 0.93 0.74 0.82 454 

Table 8: PoliCheck validation. Multi-class and binary classifcation metrics for each disclosure type along with the averaged performance. Note that support is in terms of number 

of data fows. 

D.2 PoliCheck Validation 

We briefy described our manual validation for PoliCheck 

in Section 4.1.3. To test the correctness of OVRSEEN’s privacy policy analyzer, which is based on PoliCheck that was 

ported into the VR domain, we followed the methodology 

described in the PoliCheck paper [5] and another study that 

applies PoliCheck on Alexa skills [29]. They sampled a portion of consistency results and manually read through the 

corresponding privacy policies to validate the results. 

In PoliCheck, network-to-policy consistency analysis is a 

single-label fve-class classifcation task. To mitigate biases 

from human annotators, PoliCheck authors skipped ambiguous disclosures and did not differentiate between clear and 

vague disclosures during manual validation, which turned 

it into a three-class (i.e., consistent, omitted, and incorrect) 

classifcation task. We followed this validation methodology 

and obtained the complete results that are shown in Table 8. 

The authors reported micro-averaged precision [5]. For completeness and consistency with PoliCheck results, we also 

report recall, F1-score, and macro-averaged metrics. Microand macro-averaging are both popular methods to calculate 

aggregated precision and recall in multi-class classifcation 

tasks [61]. Macro-averaged precision/recall simply reports the 

averaged precision/recall of each class. For example, macroaveraged precision is 

1

Prmacro = (Pr1 +Pr2 +...+PrN) N 

where N is the number of classes and Pri is the precision of 

class i. In contrast, micro-averaging sums numbers of true positives and false positives of all classes frst, and then calculates 

the metrics. Thus, micro-averaged precision is 

TP1 +TP2 +...+TPN Prmicro = (TP1 +TP2 +...+TPN) + (FP1 +FP2 +...+FPN)

where TPi and FPi are numbers of true positive and false 

Label Prec. Recall F1 Support 

additional service feature 0.74 0.70 0.72 20 

advertising 0.94 1.00 0.97 16 

analytics research 0.91 0.80 0.85 25 

basic service feature 0.82 0.45 0.58 20 

legal requirement 0.64 1.00 0.78 9 

marketing 0.92 0.75 0.83 16 

merger acquisition 0.78 0.88 0.82 8 

personalization customization 0.80 0.67 0.73 6 

service operation and security 0.82 0.64 0.72 14 

unspecifc 0.75 0.90 0.81 49 

macro-average 0.81 0.78 0.78 

micro-average 0.80 0.79 0.79 

Table 9: Polisis validation. Multi-label classifcation metrics 

for each purpose along with the averaged performance. Note 

that support is in terms of number of text segments. Text 

segments that Polisis does not annotate with a purpose is 

annotated as “unspecifc”. 

positive samples of class i. In single-label multi-class classifcation, every misclassifcation is a false positive for one class 

and a false negative for other classes. Thus, the denominators 

in precision and recall are always equal to the population of 

samples: micro-averaged precision, recall and F1-score are 

all the same. Micro-averaging is preferable when the distribution of classes is highly imbalanced, which is the case in our 

dataset. 

In addition, we also report, in Table 8, the precision, recall 

and F1-score of the binary classifcation case, where we only 

care about whether the data fows are consistent or not with 

privacy policy statements. In this case, inconsistent fows are 

seen as positive samples. 

D.3 Polisis Integration and Validation 

We described how we used Polisis for purpose extraction in 

Section 4.2. Polisis is available as a black-box online privacy policy analysis service (https://pribot.org/). We 

feed privacy policies (in HTML format) into Polisis and get 

text segments annotated with purposes via Polisis Web API. 

To the best of our knowledge, it internally uses end-to-end 

deep learning classifers to annotate purposes at text-segment 

level [21], which is different from PoliCheck’s sentence-level 

NLP technique. Since Polisis is not open-sourced, we know 

very little about how Polisis segments and processes text internally. 

We developed a translation layer to associate OVRSEEN 

data fows with purposes from Polisis. The translation layer 

emulates PoliCheck’s text processing on Polisis text segments 

to break them into sentences. Next, it compares binary bag-ofwords representation to match sentences from PoliCheck with 

sentences from Polisis. Two sentences from both sides match 

if one sentence contains all the words in the other sentence. 

A successful match yields data type and destination from 

23 
PoliCheck, and purpose from Polisis. Although we made the 

sentence matching very tolerant, it still failed to fnd some 

matches due to edge cases caused by the very different text 

processing pipelines of PoliCheck and Polisis. 

Polisis validation. We evaluated the performance of Polisis 

by manually annotating text segments with purposes. The 

evaluation process is described in Section 4.2 and the complete results are shown in the upper part of Table 9. 

E Responses from Developers 

We sent courtesy notifcation emails to inform Oculus and the 

developers of the 140 apps about our fndings on September 

13 and 14, 2021. We provide a summary of responses from 

these developers in Section 5.2. Within a period of two weeks, 

we received 24 responses from these developers: three developers of Oculus free apps, six developers of Oculus paid apps, 

and 15 developers of SideQuest apps. Most of these developers (21/24) responded positively and thanked us for sharing 

our fndings about their apps; others responded simply that 

they have received the message (e.g., through an automated 

reply), or said that the email address we sent our message 

to was the wrong one. Five of 19 developers reiterated their 

position about their data collection practices and/or referred 

us back to their privacy policy. Notably, 12 of 19 developers 

inquired further about our fndings: they discussed with us to 

gain deeper insights from our fndings, promised to improve 

their privacy policy, and asked for our advice on how they can 

write better privacy policies. In particular, some developers expressed the need for training on privacy policy writing and the 

diffculty in ensuring consistent disclosures—this implicates 

the need for tools, such as OVRSEEN. 

24