The Web's Sixth Sense:A Study of Scripts Accessing Smartphone … · movement tracking), immersive gaming, activity and gesture recognition, fitness monitoring, 3D scanning and indoor

The Webrsquos Sixth SenseA Study of Scripts Accessing Smartphone Sensors

Anupam DasNorth Carolina State University

anupamdasncsuedu

Gunes AcarPrinceton Universitygunesprincetonedu

Nikita BorisovUniversity of Illinois at Urbana-Champaign

nikitaillinoisedu

Amogh PradeepNortheastern University

apradeepnortheasternedu

ABSTRACTWe present the first large-scale measurement of smartphone sensorAPI usage and stateless tracking on the mobile web We extend theOpenWPM web privacy measurement tool to develop OpenWPM-Mobile adding the ability to emulate plausible sensor values fordifferent smartphone sensors such as motion orientation proximityand light Using OpenWPM-Mobile we find that one or more sensorAPIs are accessed on 3 695 of the top 100K websites by scripts orig-inating from 603 distinct domains We also detect fingerprintingattempts on mobile platforms using techniques previously appliedin the desktop setting We find significant overlap between finger-printing scripts and scripts accessing sensor data For example 63of the scripts that access motion sensors also engage in browserfingerprinting

To better understand the real-world uses of sensor APIs wecluster JavaScript programs that access device sensors and thenperform automated code comparison and manual analysis We finda significant disparity between the actual and intended use cases ofdevice sensor as drafted by W3C While some scripts access sensordata to enhance user experience such as orientation detection andgesture recognition tracking and analytics are the most commonuse cases among the scripts we analyzed We automated the detec-tion of sensor data exfiltration and observed that the raw readingsare frequently sent to remote servers for further analysis

Finally we evaluate available countermeasures against the mis-use of sensor APIs We find that popular tracking protection listssuch as EasyList and Disconnect commonly fail to block mosttracking scripts that misuse sensors Studying nine popular mobilebrowsers we find that even privacy-focused browsers such as Braveand Firefox Focus fail to implement mitigations suggested by W3Cwhich includes limiting sensor access from insecure contexts andcross-origin iframes We have reported these issues to the browservendors

Permission to make digital or hard copies of all or part of this work for personal orclassroom use is granted without fee provided that copies are not made or distributedfor profit or commercial advantage and that copies bear this notice and the full citationon the first page Copyrights for components of this work owned by others than theauthor(s) must be honored Abstracting with credit is permitted To copy otherwise orrepublish to post on servers or to redistribute to lists requires prior specific permissionandor a fee Request permissions from permissionsacmorgCCS rsquo18 October 15ndash19 2018 Toronto ON Canadacopy 2018 Copyright held by the ownerauthor(s) Publication rights licensed to ACMACM ISBN 978-1-4503-5693-01810 $1500httpsdoiorg10114532437343243860

CCS CONCEPTSbull Security and privacyrarrWeb application security Privacy pro-tections

KEYWORDSSensors Mobile browser On-line tracking Fingerprinting

ACM Reference FormatAnupam Das Gunes Acar Nikita Borisov and Amogh Pradeep 2018 TheWebrsquos Sixth Sense A Study of Scripts Accessing Smartphone Sensors In2018 ACM SIGSAC Conference on Computer and Communications Security(CCS rsquo18) October 15ndash19 2018 Toronto ON Canada ACM New York NYUSA 18 pages httpsdoiorg10114532437343243860

1 INTRODUCTIONThe dominant mode of web browsing has shifted towards mobileplatformsmdash2016 saw mobile web usage overtake desktop [74] To-dayrsquos smartphones come equipped with a multitude of sensorsincluding accelerometers gyroscopes barometers proximity andlight sensors [67] Augmented reality indoor navigation and immer-sive gaming are some of the emerging web applications possibledue to the introduction of sensors The Webrsquos standardization bodythe W3C has thus introduced standards to define how to makesensor data accessible to web applications [80]

Access to the sensors however can also create new securityand privacy vulnerabilities For example motion sensors can beexploited to infer keystrokes or PIN codes [14 51] Ambient lightlevel readings can be exploited for sniffing usersrsquo browsing historyand stealing data from cross-origin iframes [61] Motion sensorshave also shown to be uniquely traceable across websites allowingstateless tracking of users [9 19 23] While the W3Crsquos sensor speci-fications list these and other security and privacy concerns they donot mandate countermeasures In practice mobile browsers allowaccess to these sensors without explicit user permission allowingsurreptitious access from JavaScript

In order to better understand the risks of sensor access we con-duct an in-depth analysis of real-world uses and misuses of thesensor APIs In particular we seek to answer the following ques-tions 1) what is the prevalence of scripts that make use of sensors2) what are the common use cases for accessing sensors 3) aresensors used by third-party tracking scripts specifically those scriptwhich engage in fingerprinting 4) how effective are existing pri-vacy countermeasures in thwarting the use of sensors by untrustedscripts

To answer these questions we perform the first large-scale mea-surement study of the mobile web with a focus on sensor APIsWe extend the OpenWPM [31] measurement platform to study themobile web adding emulation of mobile browsing behavior andbrowser APIs We call this extension OpenWPM-Mobile and havereleased its source code publicly Using the JavaScript and HTTP in-strumentation data provided by OpenWPM-Mobile we survey theAlexa top 100K sites We measure the sensor API access patterns incombination with stateless tracking techniques including canvasbattery WebRTC and AudioContext fingerprinting To understandhow sensors are being used in the wild we develop a clusteringscheme to group similar scripts and then perform manual analysisto identify use cases Furthermore we measure how popular track-ing protection lists perform against tracking scripts that make useof sensors

Below we present a summary of our findingsLarge-scale measurement of sensor API usage (sect4) We findthat on 3 695 of the Alexa top 100K sites at least one of motion ori-entation proximity or light sensor APIs is accessed By emulatingreal sensor data we were able to determine that many third-partyscripts send raw sensor data to remote serversStudy of sensor API use through clustering (sect5) By clusteringscripts based on features extracted from JavaScript instrumentationdata we find a significant disparity between the intended use casesof sensors (as drafted by the W3C) and real-world uses Sensordata are commonly used for tracking and analytics verifying adimpressions and distinguishing real devices from botsMeasurement of fingerprinting on themobile web (sect61) Wepresent the first mobile web measurement of the various finger-printing techniques including canvas WebRTC AudioContext andbattery fingerprinting We find a significant overlap between thefingerprinting scripts and the scripts accessing sensor APIs indi-cating that sensor data is used for tracking purposes For examplewe found that 63 of the scripts that access motion sensors alsoperform canvas fingerprintingEvaluation of existing countermeasures (sect62 and sect63) Weevaluate the efficacy of existing countermeasures against track-ing scripts that use sensor APIs We measure the rate of blockingby three popular tracking protection lists EasyList EasyPrivacyand Disconnect We find that these lists block the most prevalentscripts that access sensor however they only block 25ndash33 ofthe scripts overall We also study the sensor access behavior ofnine popular browsers and find that browsers including more pri-vacy oriented ones such as Firefox Focus and Brave fail to followthe W3C recommendation of disallowing access from insecure ori-gins and cross-origin iframes We have reported these issues to thespecific browser vendors

2 BACKGROUND AND RELATEDWORK21 Mobile Sensor APIsOur study focuses on the following sensor APIs for device motionorientation proximity and ambient light Other sensors commonlypresent on modern mobile devices such as magnetometer barome-ters and infrared sensors are left out as they are not supported bybrowsers We provide a brief description of the sensors below

Motion (devicemotion [68]) Provides acceleration and rotationrate along three axes using MEMS accelerometers and gyroscopesData type is double-precision floating-point with acceleration val-ues expressed inmsminus2 unit and rotation rates expressed in radsminus1

or deдsminus1 unitOrientation (deviceorientation [80]) Provides alpha beta and

gamma components which correspond to orientation along the ZX and Y axes respectively Data type is double-precision floating-point specified in deд unit

Proximity (deviceproximity [72]) Detects if the phone is closeto ear during a call based on light and infrared sensors Providesdouble-precision floating-point readings in cm units

Ambient Light (devicelight [71]) Provides the ambient lightlevel readings in lux units

To access sensor data a script registers an event handler by call-ing the addEventListener function with the specific sensor eventand event handler functions as arguments The event handler func-tion is then called whenever new sensor data is available A samplecode snippet for registering and accessing motion sensor is givenbelow

windowaddEventListener(devicemotion motionHandler)function motionHandler(evt) Access Accelerometer Dataax = evtaccelerationIncludingGravityxay = evtaccelerationIncludingGravityyaz = evtaccelerationIncludingGravityz Access Gyroscope DatarR = evtrotationRateif (rR = null)gx = rRalphagy = rRbeta gz = rRgamma

Note that proximity and ambient light sensors were only sup-ported by Firefox and their support has been deprecated Never-theless our study finds some usage of theses sensors across theweb

22 Different Uses of Sensor DataW3C has listed the following use cases for device sensors [87]

bull Light controlling smart home lighting checking sufficientlight level at work space calculating camera settings (apper-ture shutter speed ISO) and light-based gesturingbull Proximity detecting when device is held close to the mouthor ear (eg WebRTC-based voice call application)bull Motion and Orientation virtual and augmented reality (headmovement tracking) immersive gaming activity and gesturerecognition fitness monitoring 3D scanning and indoornavigation

The potential uses of sensor APIs are not limited to the cases listedabove In section 54 we will summarize the different uses of thesensor APIs found in the wild

23 Related Work

Sensor Exploitation Prior studies have shown a multitude ofcreative ways to exploit sensor data inferring keystrokes and PINcodes using motion sensors [14 51 63 88] capturing and recon-structing audio signals using gyroscopes [53] inferring whetheryou are walking driving or taking the subway using motion sen-sors [73 79] tracking the metro ride or inferring the route thatwas driven using motion data [39 40] sniffing usersrsquo browsinghistory and stealing data from cross-origin frames using ambientlight level readings [61] extracting a spatial fingerprint of the sur-roundings using a combination of acoustic and motion sensors [6]linking usersrsquo incognito browsing sessions to their normal browsingsessions using the timing of the devicemotion event firings [82]Browser Fingerprinting Mayer [49] first explored the idea ofusing browser ldquoquirksrdquo to fingerprint users the the Panopticlickproject was the first to show that browser fingerprinting can be doneeffectively at scale [29] In 2012 Mowery and Shacham introducedcanvas fingerprinting which uses HTML5 canvas elements andWebGL API to fingerprint the fonts and graphic rendering engineof browsers [56] Finally several measurement studies have shownthe existence of these advanced tracking techniques in the wild [12 31 58 60] Recently browser extensions have been shown to befingerprintable [78] Cao et al recently proposed ways in which itis possible to identify users across different browsers [15] Vastel etal have also shown that in spite of browser fingerprints evolvingover time they can still be linked to enable long-term tracking [85]

As mobile browsing became more common researchers exploreddifferent ways to fingerprint mobile devices and browsers Hard-ware and software constraints on mobile platforms often lowerthe fingerprinting precision for mobile browsers [29 41 76] In2016 however Laperdrix et al showed that fingerprinting mobiledevices can be effective mainly thanks to user agent strings andemojis which are rendered differently across mobile devices [48]Others have looked at uniquely identifying users by exploiting themobile configuration settings which are often accessible to mobileapps [46]

Researchers have also studied ways to mitigate browser finger-printing Privaricator [59] and FPRandom [47] are two approachesthat add randomness to browser attributes to break linkabilityacross multiple visits Besson et al formalized randomization de-fense using quantitative information flow [8] FP-Block [81] is an-other countermeasure that defends against cross-domain trackingwhile still allowing first-party tracking to improve usability Somebrowsers such as Tor browser and Brave by default protect againstvarious fingerprinting techniques [11 65]Device Fingerprinting It is also possible to use unique charac-teristics of the userrsquos hardware instead of or in addition to browsersoftware properties for fingerprinting purposes One of the earlyand well-known results showed that computers can be uniquelyfingerprinted by their clock skew rate [55] Later on researcherswere able to show that such tracking can be done on the Internetusing TCP and ICMP timestamps [44]

In recent years researchers have looked into fingerprintingsmartphones through embedded sensors Multiple studies havelooked at uniquely characterizing the microphones and speakers

embedded in smartphones [9 18 89] Motion sensors such as ac-celerometers and gyroscopes have also shown to exhibit uniqueproperties enabling apps and websites to uniquely track users on-line [9 19 20 23] The HTML5 battery status API has also beenshown to be exploitable specially old and used batteries with re-duced capacities have been shown to potentially serve as trackingidentifiers [62]

Taking a counter perspective researchers have also explored thepotential of using browser and device fingerprinting techniques toaugment web authentication [4 66 83] In this setting fingerprintscollected using the sensor or other APIs serve as an additional factorfor authentication Device fingerprinting has also been proposedas a way to distinguish users browsing real devices from bots orother emulated browsers [13]

In this paper we focus on the tracking-related use of sensorsembedded in smartphones Our goal is not to introduce new fin-gerprinting schemes or evaluate the efficacy of existing techniquesRather we identify the real-world uses of sensors APIs by analyzingdata from the first large-scale mobile-focused web privacy measure-ment Moreover we highlight the substantial disparity between theintended and actual use of smartphone sensors

3 DATA COLLECTION AND METHODOLOGY31 OpenWPM-MobileOur data collection is based onOpenWPM-Mobile a mobile-focusedmeasurement tool we built by modifying OpenWPM web measure-ment framework [31]1 OpenWPM has been developed to measureweb tracking for desktop browsers and hence it uses the desktopversion of Firefox browser as a part of its platform To capturethe behavior for mobile websites we heavily modified OpenWPMplatform to imitate a mobile browser This was essential for per-forming large-scale crawls of websites as mobile browsers havemore limited instrumentation capability We specifically emulateFirefox on Android as it uses the same Gecko layout engine as thedesktop Firefox used in the crawls it is also the only browser thatsupports all four of the sensor APIs that we study2

We extended OpenWPMrsquos JavaScript instrumentation to inter-cept access to sensor APIs In particular we logged calls to the add-EventListener function along with the function arguments andstack frames We also used OpenWPMrsquos standard instrumenta-tion that allowed us to detect fingerprinting attempts includingcanvas fingerprinting canvas-font fingerprinting audio-contextfingerprinting battery fingerprinting and WebRTC local IP discov-ery [31]

Sites are known to produce different pages and scripts for mo-bile browsers to ensure that we would see the mobile versionswe took several steps to realistically imitate Firefox for AndroidThis involved overriding navigator objectrsquos user agent platformappVersion and appCodeName strings matching the screen resolu-tion screen dimensions pixel depth color depth enabling touchstatus removing plugins and supported MIME types that may in-dicate a desktop browser We also adjusted the preferences used

1The source code for OpenWPM-Mobile can be found at httpsgithubcomsensor-jsOpenWPM-mobile2Firefox released a version that disables devicelight and deviceproximity events onMay 9th 2018 [43]

to configure Firefox for Android such as hiding the scroll barsand disabling popup windows We relied on the values providedin the mobilejs3 script found in the Firefox for Android sourcecode repository To mitigate detection by font-based fingerprint-ing [2 31] we uninstalled all fonts present on crawler machinesand installed fonts extracted from a real smartphone (Moto G5 Plus)with an up-to-date Android 7 operating system

To make sure that our instrumented browser looked realistic weused fingerprintjs2 [84] library and EFFrsquos Panopticlick test suite [30]to compare OpenWPM-Mobilersquos fingerprint to the fingerprint of aFirefox for Android running on a real smartphone (Moto G5 Plus)We found that OpenWPM-Mobilersquos fingerprint matched the realbrowserrsquos fingerprint except Canvas and WebGL fingerprints Sincethese two fingerprints depend on the underlying graphics hardwareand exhibit a high diversity even among the mobile browsers [48]we expect that sites are unlikely to disable mobile features solelybased on these fingerprints

32 Mimicking Sensor EventsSince the browser we used for crawling is not equipped with realsensors we added extra logic into OpenWPM-Mobile to triggerartificial sensor events with realistic values for all four of the de-vice APIs We ensured that the sensor values were in a plausiblerange by first obtaining them from real mobile browsers through atest page To allow us to trace the usage of these values throughscripts we used a combination of fixed values and a small randomnoise For instance for the alpha beta and gamma components ofthe deviceorientation event we used 431234 329876 216543 asthe base values and added random noise with five leading zeros(eg 0000005468) This fixed base values allowed us to track sensorvalues that are sent within the HTTP requests The random noiseon the other hand prevented unrealistic sensor data with fixedvalues

33 Data Collection SetupWe crawl the Alexa top 100K ranked4 websites [5] using OpenWPM-Mobile The crawling machines are hosted in two different geo-graphical locations one in the United States at the University ofIllinois and the other in Europe at a data center in Frankfurt Weconducted two separate crawls of the top 100K sites in US (produc-ing crawls US1 collected May 17ndash21 2018 and US2 collected May

3httpsdxrmozillaorgmozilla-esr45sourcemobileandroidappmobilejs4Using rankings dated May 12 2018

Table 1 Overview of different types of low-level features

Feature name format Operation

get_symbolName Property lookupset_symbolName Property assignmentcall_functionName Function calladdEventListener_eventName addEventListener call

27ndashJune 1 2018) and one from Germany (EU1 collected May 17ndash212018) US1 is our default dataset and thus majority of our analysis isevaluated on US1 the other crawls are analyzed in section 43 Fig-ure 1 highlights the overall data collection and processing pipelineWe are making our data sets available to other researchers [17]

34 Feature ExtractionTo be able to characterize and analyze script behavior we firstrepresent script behavior as vectors of binary features We extractfeatures from the JavaScript and HTTP instrumentation data col-lected during the crawls For each script we extract two types offeatures low- and high-level as described belowLow-level features Low-level features represent browser prop-erties accessed and function calls made by the script OpenWPM in-struments various browser properties relevant to fingerprinting andtracking using JavaScript getter and setter methods We define twocorresponding features get_SymbolName that is set to 1 when a par-ticular property is accessed and set_SymbolName that is set whena property is written to For example a script that reads the user-agent property would have the get_windownavigatoruserAgentfeature and a script that sets a cookie would have the set_win-dowdocumentcookie feature

OpenWPM also tracks a number of calls to JavaScript APIsthat are related to fingerprinting such as HTMLCanvasElementtoDataURL and BatteryManagervalueOf We represent calls witha call_functionName feature We create a special set of featuresfor the addEventListener call to capture the type of event that thescripts are listening for For example

windowaddEventListener(devicemotion )would result in the addEventListener_devicemotion feature beingset for the script The four types of low-level features are summa-rized in Table 1High-level features The high-level features capture the track-ing related behavior of scripts The features include whether a

Figure 1 Overview of data collection and processing work flow

script is using different browser fingerprinting techniques such ascanvas or audio-context fingerprinting and whether the script isblocked by certain adblocker list or not We use techniques fromexisting literature [1 31] to detect fingerprinting techniques Wecheck the blocked status of the script by using three popular ad-blockingtracking protection lists EasyList [27] EasyPrivacy [28]and Disconnect [25] The full list of high-level features are given inTable 2

35 Feature AggregationWe produce a feature vector for each script loaded by each site inthe crawl For analysis purpose we aggregate these feature vectorsin three different ways site domain and url Site-level aggregationconsiders the features used by all the scripts loaded by a givensite Domain-level aggregation captures all the scripts (across allsites) that are served from a given domain to identify major playerswho perform sensor access We use the Public Suffix + 1 (PS+1)domain representation which are commonly used in the web pri-vacy measurement literature to group domains issued to a singleentity [50 57] We also group accesses by script URL to capture theuse of the same script across different sites When performing thisgrouping we discard the fragment and query string URL compo-nents [7] (ie the part of the URL after the amp or characters)as these are often used to pass script parameters or circumventcaching

When performing this aggregation we essentially compute abinary OR of the feature vectors of the individual instances thatwe incorporate In other words if any member of the groupingexhibits a certain feature the feature is assigned to a script Forexample if any script served by a given domain performs canvasfingerprinting we assign the canvas_fingerprinting feature for thatdomain

4 MEASUREMENT RESULTSIn this section we will first highlight the overall prominence ofscripts accessing different device sensors Next we showcase differ-ent ways in which scripts send raw sensor data to remote serversLastly we will look at the stability of our findings across differentcrawls taking place in the same geolocation and across differentgeolocations US1 is our default dataset unless stated otherwise

41 Prevalence of ScriptsFirst we look at how often are device sensors accessed by scriptsTable 3 shows that sensor APIs are accessed on 3 695 of the 100Kwebsites by scripts served from 603 distinct domains Orientationand motion sensors are by far the most frequently accessed on2 653 and 2 036 sites respectively This can be explained by commonbrowser support for these APIs Light and proximity sensors whichare only supported by Firefox are accessed on fewer than 200 siteseach

Table 3 Overview of script access to sensor APIs Columnsindicate the number of sites and distinct script domains (iedomains from where scripts are served) respectively

Sensor Num ofsites

Num ofscript domains

Motion 2653 384Orientation 2036 420Proximity 186 50Light 181 35

Total 3695 603

We also look at the distribution of the sensor-accessing scriptsamong the Alexa top 100K sites Figure 2 shows the distributionof the scripts across different ranked sites Interestingly we seethat many of the sensor-accessing scripts are being served on topranked websites Table 4 gives a more detailed overview of the mostcommon scripts that access sensor APIs The scripts are representedby their Public Suffix + 1 (PS+1) addresses In addition we calculatedthe prominencemetric developed by Englehardt andNarayanan [31]which captures the rank of the different websites where a givenscript is loaded and sort the scripts according to this metric

Table 4 shows that scripts from serving-syscom which belongsto advertising company Sizmek [75] access motion sensor data on815 of the 100K sites crawled Doubleverify which has a very simi-lar prominence score provides advertising impression verificationservices [26] and has been known to use canvas fingerprinting [31]The most prevalent scripts that access proximity and light sensorscommonly belong to ad verification and fraud detection companiessuch as b2ccom and adsafeprotectedcom Both scripts also usebattery and AudioContext API fingerprinting

Although present on only 417 sites alicdncom script has thehighest prominence score (03303) across all scripts This is largely

Table 2 The list of high-level features and reference to methodology for detection

High-level feature name Description amp Reference

audio_context_fingerprinting Audio Context API fingerprinting via exploiting differences in the audio processing engine [31]battery_fingerprinting Battery status API fingerprinting via reading battery charge level and discharge time [62]canvas_fingerprinting Canvas fingerprinting via exploiting differences in the graphic rendering engine [1 31]canvas_font_fingerprinting Canvas font fingerprinting via retrieving the list of supported fonts [31]webrtc_fingerprinting WebRTC fingerprinting via discovering publiclocal IP address [31]easylist_blocked Whether blocked by EasyList filter list [27]easyprivacy_blocked Whether blocked by EasyPrivacy filter list [28]disconnect_blocked Whether blocked by Disconnect filter list [25]

Table 4 Top script domains accessing device sensors sorted by prominence [31] The scripts are grouped by domain tominimizeover counting different scripts from each domain

Sensor Script Domain Num sites Min Rank Prominence EasyListblocked

EasyPrivacyblocked

Disconnectblocked

Motionserving-syscom 815 67 00485 0 1 1doubleverifycom 517 187 00453 1 0 0adscore 648 570 00275 1 0 0

Orientationalicdncom 417 9 03303 0 0 0adscore 648 570 00275 1 0 0yieldmocom 83 100 00263 1 0 1

Proximityb2ccom 108 498 00114 0 1 0adsafeprotectedcom 36 1418 00023 1 0 1allrecipescom 1 1216 00008 0 0 0

Lightb2ccom 108 498 00114 0 1 0adsafeprotectedcom 36 1418 00023 1 0 1allrecipescom 1 1216 00008 0 0 0

Figure 2 Distribution of sensor-accessing scripts across var-ious ranked intervals

because a script originating from alicdncom accessed device orien-tation data on five of the top 100 sitesmdashincluding taobaocom (Alexaglobal rank 9) the most popular site in our measurement wherewe detected sensor accessmdashand thus this script is served to a verylarge user base Table 5 shows the breakdown of sensor-accessingscripts in terms of first and third parties While web measurementresearch commonly focuses on third-party tracking [50] we findthat first-party scripts that access sensor APIs are slightly morecommon than third-party scripts Our sensor exfiltration analysisof the scripts in section 42 revealed that many bot detection andmitigation scripts such as those provided by perimeterxnet andb2ccom are served from the clientsrsquo first party domains

42 Sensor Data ExfiltrationAfter uncovering scripts that access device sensors we investigatewhether scripts are sending raw sensor data to remote serversTo accomplish this we spoof expected sensor values as describedin section 32 We then analyze HTTP request headers and POSTrequest bodies obtained through OpenWPMrsquos instrumentation toidentify the presence of spoofed sensor values We found several

Table 5 Number of sensor-accessing scripts served fromfirst-party domains vs third-party domains

Num offirst party

Num ofthird party Total

Motion 364 137 501Orientation 350 300 650Proximity 40 56 96Light 30 52 82

Any sensor 518 398 916

domains to access and send raw sensor data to remote servers eitherin clear text or in base64 encoded form

Table 6 highlights the top ten script domains that send sensordata to remote servers perimeterxcom (a bot detection company)and b2ccom (ad fraud detection company) are the most prevalentscripts that exfiltrate sensor readings In addition we found thatpricelinecom and kayakcom serve a copy of the perimeterxcomscript from their domain (as a first-party script) which in turn readsand sends sensor data These scripts send anywhere between oneto tens of sensor readings to remote servers Majority of the scripts(eight of ten) encode sensor data before sending it to a remoteserver Appendix C lists examples of scripts sending sensor data toremote servers We also found that certain scripts send statisticalaggregates of sensor readings and others obfuscate the code thatis used to process sensor data and send it to a remote server Moreexamples are available in section 55

While detecting exfiltration of spoofed sensor values we useHTTP instrumentation data provided by OpenWPM Since Open-WPM captures HTTP data in the browser (not on the wire afterit leaves the browser) our analysis was able to cover encryptedHTTPS data as well

1012 832421

166 51

US1 US2

No of sites

100 20079

113 14

US1 US2

No of script URLs

24 3558

US1 US2

No of script domains

Figure 3 Overlap across different datasets

Table 6 Domains of the scripts that send spoofed sensor datato remote servers

Domain (PS+1) Sensorslowast Encoding of Topsites site

b2ccom A O P L base64 53 498perimeterxnet A base64 45 247wayfaircom A base64 7 1136moatadscom O raw 5 3616queitin A O raw 3 22935kayakcom A base64 1 982pricelinecom A base64 1 1573fiverrcom A base64 1 541luluscom A base64 1 4470zazzlecom A base64 1 5860lowast lsquoArsquo accelerometer lsquoGrsquo gyroscope lsquoOrsquo orientation lsquoPrsquo proximity lsquoLrsquo light

43 Crawl ComparisonIn this section we compare the results from our three data setsUS1 US2 and EU1 Figure 3 highlights the overlap and differencesbetween the three crawls presented as a Venn diagram We conjec-ture that there are two main reasons for the observed differencesbetween the results First most popular web sites are dynamic andchange the ads and sometimes the contents that are displayedwith each load This is supported by the fact that although thereare significant differences between the sites where sensors wereaccessed the overlap between script URLs and domains is generallyhigh

Second the location of the crawl appears to make a differenceThe script domains in the two US crawls have more overlap (Jaccardindex 086) than when comparing either US crawl to the one fromthe EU (Jaccard indices 079 and 083) even though all three werecollected around the same time period The absolute number ofsites accessing sensors in the EU crawl was also smaller than inthe US crawls by about a third (EU1 2 469 US1 3 695 US2 3 400)It is possible that stricter privacy regulation in the EU such asthe EUrsquos General Data Protection Regulation (GDPR) [32] may be

responsible for this disparity but we leave a full exploration of thisquestion as future work

5 UNDERSTANDING SENSOR USE CASESHaving identified scripts that access sensor APIs we next focuson identifying the purpose of these scripts To make this analysistractable we first use clustering to identify groups of similar scriptsand then manually analyze the sensor uses cases

51 Clustering Methodology

Clustering Process In this section we will briefly describe theoverall clustering process We cluster JavaScript programs in threephases to generalize the clustering result as much as possible andto accommodate for clustering errors that may have been causedby random noise introduced by the potentially varying behavior ofscripts such as incomplete page loads or intermittent crawler fail-ures Figure 4 highlights the three phases of the clustering process

DBSCAN Merge ClassifyJS Cluster

Figure 4 The three phases for clustering scripts

In the first phase we apply off-the-shelf DBSCAN [69] a density-based cluster algorithm to generate the initial clusters using thescript features described in Section 3 In the second phase we tryto generalize the clustering results by merging clusters that aresimilar We do this in an iterative manner where in each round wedetermine the pair of clusters merging which would result in theleast amount of reduction in the average silhouette coefficient5 Thisprocess is repeated until any new merges would reduce the averagesilhouette coefficient reduced by more than a given threshold (δ )

In the last phase we try to see if certain samples that are catego-rized as noisy can be classified into one of the other core clustersThe reason behind this step is to see if certain scripts were incor-rectly clustered due to differences in their behavior across different5Here we only consider clusters that are not labeled as noisy

websites The same script may exhibit a different behavior whenpublishers (first parties) use different features of the script or whenthe script execution depends on the loading of dynamic contentsuch as ads To perform classification we use a random forest clas-sifier [70] where the non-noisy cluster samples labeled with theircorresponding cluster label serve as the training data We thentry to classify the noisy samples as members of one of the coreclusters We relabel the scripts only if the prediction probability bythe classifier is greater than a given threshold (θ ) Pseudo-code (inPython) for the three phases is provided in appendix AValidationMethodology To validate our clustering results and todetermine the different use cases for accessing sensor data we takethe following two steps First we generate an average similarityscore per cluster by computing the pairwise code difference betweentwo scripts using the Moss tool [3] Next if the average similarityscore for a given cluster is lower than a certain threshold (ϵ) wemanually analyze five random scripts from that cluster otherwise(if higher than the threshold) we manually analyze three randomscripts per cluster

For manual analysis we follow a protocol of steps given belowbull Inspect the code description copyright statements softwarelicense links to public repositories if any to search for anystated purpose of the scriptbull Statically analyze the registered sensor event listeners todetermine how sensor data is usedbull If static analysis fails (eg due to obfuscation) load a pagethat embeds the script and debug over the USB using Chromedeveloper tools with break points enabled for sensors eventlisteners to analyze runtime behaviorbull Check if sensor data is leaving the browser ie if the scriptmakes any HTTPHTTPS requests containing sensor databull If the script sends some encoded data try decoding the pay-load

52 Clustering ScriptsWe next describe the detailed process and results of clustering thescripts We first try to cluster scripts based on low-level features de-scribed in section 34 Recall that low-level features include browserproperties accessed (by either get or set method) and function callsmade (using call or addEventListener) by the script The reasonbehind the use of low-level features is that it provides us witha comprehensive overview of the scriptrsquos functionality We startby only considering scripts that access any of the four sensorswe study motion orientation proximity or light We found 916such scripts in our US1 dataset Next we cluster these scripts us-ing DBSCAN [69] Figure 5 highlights the clustering results wherethe x axis represents the silhouette coefficient per cluster We seethat there are 39 distinct clusters generated by DBSCAN of whicharound 24 scripts are labeled as noisy (ie scripts that are labeledas lsquo-1rsquo) The red and blue vertical lines in the figure present theaverage silhouette coefficient with and without the noisy samplesrespectively

In order to generalize our clustering results we attempt to mergesimilar clusters ie clusters that result in the least amount of re-duction in silhouette coefficient when merged (see appendix A forcode) We set the total reduction in silhouette coefficient to 001

minus08 minus06 minus04 minus02 00 02 04 06 08 10

Silhouette coefficient values

8910111213141516171819202122232425262728293031323334353637

Figure 5 Clustering scripts based on low-level features

(ie δ = 001) Doing so reduces the total number of clusters to 36but certain clusters such as cluster number 37 becomes a bit morenoisy Figure 6 highlight the merged clustering results

891011121314151617181920212225262728293031323334353637

Figure 6 Merging similar clusters until average silhouettecoefficient reduce by 001

Finally we check if certain noisy samples (ie scripts that arelabeled as lsquo-1rsquo) can be classified into one of the other core clusters

with a certain probability To do this we use a random forest clas-sifier where scripts from non-noisy clusters (ie clusters that arelabeled with a value ge 0) are used as training data and scripts thatare noisy are used as testing data We only relabel noisy samplesif the prediction probability θ ge 076 Also we update labels inbatches of five samples at a time Figure 7 highlights the outcomeof this final step This reduces the total fraction of scripts labeled asnoisy from 24 to 21 However as evident from Figure 7 this alsoincreases the chance of certain clusters becoming slightly morenoisy (eg clusters 16) The average silhouette coefficient with-out the remaining noisy samples (ie ignoring the cluster labeledas lsquo-1rsquo) after this phase is close to 08 which is an indication thatthe clustering outcomes are within an acceptable range For un-derstanding the impact geo-location we also ran our clusteringtechniques on the EU1 dataset and obtained similar results Wefound a total of 46 clusters with approximately 23 of the scriptslabeled as noisy In section 54 we will briefly discuss how in spiteof the total number of clusters being larger compared to the US1dataset they represent similar use cases

89101112131415

17181920212225262728293031323334353637

Figure 7 Classifying noisy samples using non-noisy sam-ples as ground truth only if prediction probability ge 07

53 Validating Clustering ResultsWe use the Moss [3] service which measures source code similarityto detect plagiarism in order to validate the results of our clusteringWe use Moss to calculate the similarity scores between pairs ofscripts from the same cluster For comparison we also calculate thesimilarity between pairs of scripts from different clusters in thiscase we limit ourselves to five random scripts per cluster due tothe rate limitations imposed by Moss6This value was empirically set by manually spot checking how effective the classifi-cation results were

We plot the distribution of these scores in Figure 8 We notethat scripts within the same cluster tend to have high similarity inparticular 81 of pairs have a similarity score exceeding 07 Like-wise scripts from different clusters tend to be dissimilar with 94of samples showing a similarity score of 01 or less This suggeststhat the clusters are identifying groups of scripts that have highsource-level similarity

We also compute the average pairwise similarity score for eachcluster to guide our manual analysis For clusters with high averagepairwise similarity scores (ϵ gt 07) we manually inspect threerandomly-chosen scripts from each cluster For clusters with lowersimilarity scores we inspect five random scripts per cluster7

0 20 40 60 80 100

Similarity score ()

intercluster similarity

intracluster similarity

Figure 8 Distribution of intra- and inter-cluster similarity

54 Real-world Use CasesTable 7 summarizes the different use cases that we have identifiedthrough our manual inspection The table also highlights the aver-age pairwise code similarity score per cluster computed throughMoss [3] It should be noted that the high similarity scores likelyresult from sites using or copying code from common librarieswhereas the low scores result from scenarios where only smallparts of the scripts were either reused or copied from other scriptsWe see that there are broadly seven different use cases for accessingsensor data among which around 37 of the scripts collect sensordata to perform tracking and analytics such as audience recogni-tion ad impression verification and session replay We also see thataround 18 scripts use sensor data to determine whether a deviceis a smartphone or a bot to deter fraud Interestingly 70 and 76of the scripts described in these two categories respectively havebeen identified to be doing some combination of canvas webrtcaudio_context or battery fingerprinting

We found similar use cases for the EU1 dataset Around 19 of thescripts were found to use sensor data to distinguish bots from realsmartphones We did however see somewhat a lower percentage ofscripts (around 31) involved in tracking and analytics We foundthis group of scripts to be loaded on only 330 sites whereas for theUS1 dataset this number was more than three times bigger (1198)

7For any clusters with five scripts or fewer we manually inspect all the scripts

Table 7 Potential sensor access use cases

Cluster IDlowast of of of Sites Ranked Avg Sim() DescriptionJS Sites 1ndash1K 1Kndash10K 10Kndash100K per cluster34 04 4 0 0 4 99 Use sensor data to add entropy to random numbers [77]7 19 20 112 114 2 32 80 89 91 43 Checks what HTML5 features are offered [22 24 54]0 3 5 12 18 177 413 10 53 350 93 69 23 95 99 Differentiating bots from real devices [33 64]22 25 27 31 92 36 81 8326 30 34 35 1 2 32 37 60 Parallax Engine that reacts to orientation sensors [86]6 14 33 32 103 0 9 94 97 98 99 Automatically resize contents in page or iframe [10]8 11 21 28 29 32 67 533 18 118 397 99 96 99 11 43 89 Reacting to orientation tilt shake [35 42 45]1 4 9 10 13 15 368 1198 24 144 1030 99 68 98 99 92 99 Tracking analytics fingerprinting and16 17 35 36 37 91 91 38 87 40 audience recognition [34 75]-1 206 1804 16 176 1612 4 Scripts clustered as noisylowast Clusters with bolded IDs consist of scripts that have been identified as performing some combination of canvas webrtc audio_context or battery fingerprinting

55 Analysis of Specific ScriptsWhile manually analyzing scripts for clustering validation we un-covered interesting uses of the sensor data Here we will brieflydiscuss two such scripts The first script comes from doublever-ifycom [26] an ad impression verification company One of theirscripts computes statistical features such as average and varianceof motion sensor data before sending it to their remote server Suchstatistical features have been shown to be useful for fingerprintingsmartphones [19] The code segment is provided in appendix B(Listing 2) Since this script was sending statistical data insteadof raw sensor data it was not captured through our sensor spoof-ing mechanism We were only able to identify this via manuallydebugging the script on a real smartphone (through USB debug-ging features of the Chrome Devtool) We found doubleverifycomscripts being loaded on 517 websites of which 7 appeared in theAlexa top 1000 sites (in our US1 dataset) However since doublev-erifycom evaluates ad impressions the presence of these scriptsis dependent on the ads that are served on a website and hencewe see it on different sites in different crawls For instance in US2dataset we found 509 sites loading the script from doubleverifycomThe union of these datasets results in 881 unique sites loading thescript of which 145 sites were common (Jaccard index 016) Inthe EU1 dataset (European crawl) however doubleverifycom wasnot present on any of the 100K sites indicating that the loading ofscripts may depend on the location of the visitor

Some sensor reading scripts are served from the first partyrsquosdomain making the attribution to specific providers more difficultFor instance a highly obfuscated script that is present on popularsites like homedepotcom and staplescom is always served onthe _bmasyncjs path under the first party (eg mstaplescom_-bmasyncjs) This script sends encoded sensor data in a POSTrequest to the endpoint _bm_data on the first-party site A codesnippet is provided in appendix B (Listing 4) The prevalence ofthese scripts was more or less similar as it is site dependent ratherthan being ad dependent We found 173 sites loading such scripts intheUS1 dataset 12 of which were ranked in the Alexa top 1000 sitesFor the US2 and EU1 dataset we found 140 and 158 sites loadingsuch scripts respectively

6 EFFICACY OF COUNTERMEASURESIn this section we study the overlap between scripts that accesssensors and scripts that perform fingerprinting We then study theeffectiveness of privacy countermeasures such as ad blocking listsas well as browser limitations on sensor APIs

61 Fingerprinting ScriptsFirst we will showcase to what extent scripts accessing sensorAPIs overlap with fingerprinting scripts To detect fingerprintingscripts we follow methodologies from existing literatures [1 31]which are also listed in Table 2 Table 8 highlights the percentageof sensor accessing scripts that also utilize browser fingerprintingas captured by the features described in section 34 We calculatethe percentage of scripts accessing a given sensor that also performa particular type of fingerprinting For example 627 of scriptsthat access motion sensors also engage in some form of browserfingerprinting

Table 8 Percentage of sensor accessing scripts that also en-gage in fingerprinting All columns except lsquoTotalrsquo are givenas percentage The lsquoTotalrsquo column shows the number of dis-tinct script URLs that access a certain sensor

CanvasFP

CanvasFont FP

AudioFP

WebRTCFP

BatteryFP

AnyFP Total

Motion 567 02 198 68 56 627 501Orientation 362 34 57 62 45 417 650Proximity 21 00 479 00 490 510 96Light 195 12 561 159 573 768 82

Table 9 showcases the numbers from the other angle the fractionof fingerprinting scripts that access different sensor APIs We listthe percentage of distinct script URLs that engage in a particularform of fingerprinting while accessing any of the sensors exploredin our study Both of these tables indicate that there is a significantoverlap between the fingerprinting scripts and the scripts accessingsensor APIs

62 Ad Blocking and Tracking Protection ListsWe next inspect what fraction of these sensor-accessing scriptswould be blocked by different well known filtering lists used for adblocking and tracking protection EasyList [27] EasyPrivacy [28]

Table 9 Percentage of fingerprinting scripts that also accesssensors All columns except lsquoTotalrsquo are given as percentageThe lsquoTotalrsquo column shows the number of distinct fingerprint-ing script URLs that use a particular fingerprinting method

Motion Orien-tation

Proxi-mity Light Any

sensor Total

Canvas FP 14 15 20 20 159 1991Canvas Font FP 329 341 471 471 247 85Audio FP 200 207 286 286 814 140WebRTC FP 105 109 150 150 202 267Battery FP 45 46 64 64 75 625

and Disconnect [25] Table 10 highlight the percentage of trackingscripts that would be blocked using each of these lists In generalwe see that a significant portion of scripts that access sensors aremissed by the popular blacklists which is in line with the previousresearch on tracking protection lists [52]

Table 10 Percentage of script domains accessing device sen-sors that are blocked by different filtering list

Sensor Disconnectblocked

EasyListblocked

EasyPrivacyblocked

Any sensor 29 25 33

63 Difference in Browser BehaviorTo determine browser support for different sensor APIs and po-tential restrictions for scripts in cross-origin iframes we set up atest page that accesses all four sensor APIs We tested the latestversion of nine browsers listed in Table 11 as of Jan 2018 Browsershave minor differences with regards to which sensor they supportand how they block access from scripts embedded in cross-originiframes Table 11 summarizes our findings As shown in the tableproximity and light sensors are only supported by Firefox8 Forprivacy reasons Firefox and Safari do not allow scripts from cross-origin iframes to access sensor data which is in line with W3Crecommendation [80] Privacy-geared browsers such as Firefox Fo-cus and Brave fare worse than Firefox and Safari as they both allowaccess to orientation data from cross-origin iframes where FirefoxFocus further allows access to motion data

Testing the sensor API availability on insecure (HTTP) pages wefound no differences in browsersrsquo behavior We also tested whetherbrowsers have any access restrictions when running in privatebrowsing mode and we found no difference when comparing tonormal browsing mode9 Finally to test whether the underlyingmobile platform has any effect on sensor availability we tested iOS

8As of May 9 2018 Mozilla released Firefox version 60 which disables proximity andlight sensor APIs we used an earlier version of Firefox in our study9Note that Firefox Focus always runs in private browsing mode so it does not have aseparate normal browsing mode

versions of the browsers We found that all browsers behave identi-cal to Safari as Apple requires browsers to use WebKit frameworkto be listed on their app store [21]

Table 11 Browser support for different sensor APIs

Browser Orientationlowast Motionlowast Proximitylowast Lightlowast

Chrome ( ) ( ) ( ) ( )Edge ( ) ( ) ( ) ( )Safari ( ) ( ) ( ) ( )Firefox ( ) ( ) ( ) ( )Brave ( ) ( ) ( ) ( )Focus ( ) ( ) ( ) ( )Dolphin ( ) ( ) ( ) ( )Opera Mini ( ) ( ) ( ) ( )UC Browser ( ) ( ) ( ) ( )lowast Each tuple representing (third-party iframe) access right

We filed bug reports for Brave Android Browser Firefox Focusand Firefox for Android [12 36ndash38] pointing out that they allowsensor access on insecure pages which is against W3C recommen-dations Firefox Focus engineers told us that they will have to waitfor ChromiumWebView to ship an update for this behavior tochange since Firefox Focus on Android uses Chromium under thehood Responding to the issue we filed for Firefox for AndroidMozilla engineers briefly discussed the possibility of requiring userpermission for allowing sensor access We did not get any responseto our issue from Brave engineers We note that Brave Android isalso built on Chromium

7 DISCUSSION AND RECOMMENDATIONSOur analysis of crawling the Alexa top 100K sites indicates thattracking scripts did not wait long to take advantage of sensor datasomething that is easily accessible without requiring any user per-mission By spoofing real sensor values we found that third-partyad and analytics scripts are sending raw sensor data to remoteservers Moreover given that existing countermeasures for mo-bile platforms are not effective at blocking trackers we make thefollowing recommendationsbull W3Crsquos recommendation for disabling sensor access on cross-origin iframes [80] will limit the access from untrusted third-party scripts and is a step in the right direction HoweverSafari and Firefox are the only two browsers that follow thisrecommendation Our measurements indicate that scriptsthat access sensor APIs are frequently embedded in cross-origin iframes (674 of the 31 444 cases) This shows thatW3Crsquos mitigation would be effective at curbing the exposureto untrusted scripts Allowing sensor access on insecurepages is another issue where browsers do not follow theW3C spec all nine browsers we studied allowed access tosensors on insecure (HTTP) pagesbull Feature Policy API [16] if deployed will allow publishersto selectively disable JavaScript APIs Publisher may disablesensor APIs using this API to prevent potential misuses bythe third-party scripts they embed

bull Provide low resolution sensor data by default and requireuser permission for higher resolution sensor databull To improve user awareness and curb surreptitious sensoraccess provide users with a visual indication that the sensordata is being accessedbull Require user permission to access sensor data in privatebrowsing mode limit resolution or disable sensor access alltogether

8 LIMITATIONSOur clustering analysis depends on OpenWPMrsquos instrumentationdata to attribute JavaScript behavior to individual scripts There arepotential imperfections in this attribution task First some websitesconcatenate several JavaScript files and libraries into a single fileThese scripts would be seen as one script (URL) to OpenWPMrsquosinstrumentation potentially adding noise in the clustering stageSecond when attributing JavaScript function calls and propertyaccesses to individual scripts we use the script URL that appearsat the top of the calling stack following the prior work done byEnglehardt and Narayanan [31] Under some circumstances this ap-proach may be misleading For instance when a script uses jQuerylibrary to listen to sensor events we attribute the sensor relatedfeature to jQuery as it appears at the top of the calling stack

OpenWPM-Mobile uses OpenWPMrsquos JavaScript instrumenta-tion which captures function calls made and browser propertiesaccessed at runtime (Section 34) This approach has the advantageof capturing the behavior of obfuscated code but may miss codesegments that do not execute during a page visit

We manually analyzed a random subsample of scripts insteadof studying all scripts per cluster While this process may misssome misbehaving scripts we believe the outcomes will not beaffected as the average intra- and inter-cluster similarity scores aresignificantly apart

OpenWPM-Mobile does not store in-line scripts We found thatonly 121 (111 of 916) of the scripts were in-line We were able tore-crawl sites that included the in-line scripts and stored them forthe clustering step

There are many ways in which trackers can exfiltrate sensor datafor example using encryption or computing and sending statisticson the sensor data as we present in section 55 Therefore ourresults on sensor data exfiltration should be taken as lower bounds

Using fingerprinting test suites fingerprintjs2 [84] and EFFrsquosPanopticlick [30] we verified that OpenWPM-Mobilersquos browserfingerprint matches that of a Firefox for Android running on a realsmartphone to the best extent possible We also observed several adplatforms identify our browser as mobile and start serving mobileads However there may still be ways for example detecting thelack of hand movements in the sensor data stream could potentiallyhelp websites detect OpenWPM-Mobile as an automated desktopbrowser and treat differently

9 CONCLUSIONOur large-scale measurement of sensor API usage on the mobileweb reveals that device sensors are being used for purposes otherthan what W3C standardization body had intended We found thata vast majority of third-party scripts are accessing sensor data for

measuring ad interactions verifying ad impressions and trackingdevices Our analysis uncovered several scripts that are sendingraw sensor data to remote servers While it is not possible to de-termine the exact purpose of this sensor data exfiltration manyof these scripts engage in tracking or web analytic services Wealso found that existing countermeasures such as Disconnect Easy-List and EasyPrivacy were not effective at blocking such trackingscripts Our evaluation of nine popular mobile browsers has shownthat browsers including the privacy-oriented Firefox Focus andBrave commonly fail to implement the mitigation guidelines rec-ommended by the W3C against the misuse of sensor data Basedon our findings we recommend browser vendors to rethink therisks of exposing sensitive sensors without any form of access con-trol mechanism in place Also website owners should be givenmore options to limit the sensor misuse from untrusted third-partyscripts

10 ACKNOWLEDGEMENTSWe would like to thank all the anonymous reviewers for theirfeedback We would also like to thank Arvind Narayanan StevenEnglehardt and our shepherd Ben Stock for their valuable feedbackThis material is based in part upon work supported by the NationalScience Foundation under Grant No 1739966

REFERENCES[1] Gunes Acar Christian Eubank Steven Englehardt Marc Juarez Arvind

Narayanan and Claudia Diaz 2014 The Web never forgets Persistent trackingmechanisms in the wild In Proceedings of the 21st ACM SIGSAC Conference onComputer and Communications Security (CCS) 674ndash689

[2] Gunes Acar Marc Juarez Nick Nikiforakis Claudia Diaz Seda Guumlrses FrankPiessens and Bart Preneel 2013 FPDetective dusting the web for fingerprintersIn Proceedings of the 20th ACM SIGSAC conference on Computer and Communica-tions Security (CCS) 1129ndash1140

[3] Alex Aiken 2018 A system for detecting software similarity httpstheorystanfordedu~aikenmoss

[4] Furkan Alaca and PC van Oorschot 2016 Device fingerprinting for augmentingweb authentication Classification and analysis of methods In Proceedings of the32nd Annual Conference on Computer Security Applications 289ndash301

[5] Alexa 2018 Alexa top sites service httpswwwalexacomtopsites[6] Martin Azizyan Ionut Constandache and Romit Roy Choudhury 2009 Surround-

Sense Mobile phone localization via ambience fingerprinting In Proceedings ofthe 15th annual international conference on Mobile computing and networking261ndash272

[7] T Berners-Lee R Fielding and L Masinter 2005 RFC 3986 Uniform ResourceIdentifier (URI) Generic syntax httpwwwietforgrfcrfc3986txt

[8] Freacutedeacuteric Besson Nataliia Bielova and Thomas Jensen 2014 Browser randomisa-tion against fingerprinting A quantitative information flow approach In NordicConference on Secure IT Systems 181ndash196

[9] Hristo Bojinov Yan Michalevsky Gabi Nakibly and Dan Boneh 2014 Mobiledevice identification via sensor fingerprinting CoRR abs14081416 (2014) httparxivorgabs14081416

[10] David J Bradshaw 2017 iFrame resizer httpsgithubcomdavidjbradshawiframe-resizer

[11] Brave Browser 2018 Fingerprinting protection mode httpsgithubcombravebrowser-laptopwikiFingerprinting-Protection-Mode

[12] Bugzilla 2018 1436874 - Restrict device motion and orientation events to securecontexts httpsbugzillamozillaorgshow_bugcgiid=1436874

[13] Elie Bursztein Artem Malyshev Tadek Pietraszek and Kurt Thomas 2016 Pi-casso Lightweight device class fingerprinting for web clients In Proceedingsof the 6th Workshop on Security and Privacy in Smartphones and Mobile Devices93ndash102

[14] Liang Cai and Hao Chen 2012 On the practicality of motion based keystrokeinference attack In International Conference on Trust and Trustworthy ComputingSpringer 273ndash290

[15] Yinzhi Cao Song Li and Erik Wijmans 2017 (Cross-)Browser fingerprintingvia OS and hardware level features In Proceeding of 24th Annual Network andDistributed System Security Symposium (NDSS)

[16] Ian Clelland 2017 Feature policy Draft community group report httpswicggithubiofeature-policy

[17] Anupam Das Gunes Acar and Nikita Borisov 2018 A Crawl of the mobileweb measuring sensor accesses University of Illinois at Urbana-Champaignhttpsdoiorg1013012B2IDB-9213932_V1

[18] Anupam Das Nikita Borisov and Matthew Caesar 2014 Do you hear what Ihear Fingerprinting smart devices through embedded acoustic components InProceedings of the 21st ACM SIGSAC Conference on Computer and CommunicationsSecurity (CCS) 441ndash452

[19] Anupam Das Nikita Borisov and Matthew Caesar 2016 Tracking mobile webusers through motion sensors Attacks and defenses In Proceeding of the 23rdAnnual Network and Distributed System Security Symposium (NDSS)

[20] Anupam Das Nikita Borisov and Edward Chou 2018 Every move you makeExploring practical issues in smartphone motion sensor fingerprinting and coun-termeasures Proceedings on the 18th Privacy Enhancing Technologies (PoPETs) 1(2018) 88ndash108

[21] Apple developers 2018 App store review guidelines httpsdeveloperapplecomapp-storereviewguidelines

[22] DeviceAtlas 2018 Device browser httpsdeviceatlascomdevice-datadevices[23] Sanorita Dey Nirupam Roy Wenyuan Xu Romit Roy Choudhury and Srihari

Nelakuditi 2014 AccelPrint Imperfections of accelerometers make smartphonestrackable In Proceedings of the 21st Annual Network and Distributed SystemSecurity Symposium (NDSS)

[24] Digioh 2018 We give marketers power httpdigiohcom[25] Disconnect 2018 Disconnect defends the digital you httpsdisconnectme[26] DoubleVerify 2018 Authentic impression httpswwwdoubleverifycom[27] EasyList authors 2018 EasyList httpseasylisttoeasylisteasylisttxt[28] EasyPrivacy authors 2018 EasyPrivacy httpseasylisttoeasylisteasyprivacy

txt[29] Peter Eckersley 2010 How unique is your web browser In Proceedings of the

10th International Conference on Privacy Enhancing Technologies (PETS) 1ndash18[30] Electronic Frontier Foundation 2018 Panopticlick httpspanopticlickefforg[31] Steven Englehardt and Arvind Narayanan 2016 Online tracking A 1-million-site

measurement and analysis In Proceedings of the 23rd ACM SIGSAC Conference onComputer and Communications Security (CCS)

[32] European Commission 2018 The General Data Protection Regulation (GDPR)httpseceuropaeuinfolawlaw-topicdata-protectiondata-protection-eu_en

[33] F5 2018 Silverline web application firewall httpsf5comproductsdeployment-methodssilverlinecloud-based-web-application-firewall-waf

[34] ForeSee 2018 CX with certainty | ForeSee httpswwwforeseecom[35] Alex Gibson 2015 Detecting shake in mobile device httpsgithubcom

alexgibsonshakejs[36] GitHub 2018 Disallow sensor access on insecure contexts httpsgithubcom

bravebrowser-android-tabsissues549[37] GitHub 2018 Disallow sensor access on insecure contexts httpsgithubcom

mozilla-mobilefocus-androidissues2092[38] GitHub 2018 Firefox Focus is making sensor APIs available to cross-origin

iFrames httpsgithubcommozilla-mobilefocus-androidissues2044[39] Jun Han E Owusu L T Nguyen A Perrig and J Zhang 2012 ACComplice

Location inference using accelerometers on smartphones In Proceedings of the 4thInternational Conference on Communication Systems and Networks (COMSNETS)1ndash9

[40] J Hua Z Shen and S Zhong 2017 We can track you if you take the metroTracking metro riders using accelerometers on smartphones IEEE Transactionson Information Forensics and Security 12 2 (2017) 286ndash297

[41] Thomas Hupperich Davide Maiorca Marc Kuumlhrer Thorsten Holz and GiorgioGiacinto 2015 On the robustness of mobile device fingerprinting Can mobileusers escape modern web-trackingmechanisms In Proceedings of the 31st AnnualComputer Security Applications Conference (ACSAC) ACM 191ndash200

[42] jQuery Mobile 2018 Orientationchange event httpsapijquerymobilecomorientationchange

[43] Jonathan Kingston 2018 Bug 1359076 - Disable devicelight deviceproximityand userproximity events httpsbugzillamozillaorgshow_bugcgiformat=defaultampid=1359076

[44] Tadayoshi Kohno Andre Broido and K C Claffy 2005 Remote physical devicefingerprinting IEEE Transaction on Dependable Secure Computing 2 2 (2005)93ndash108

[45] Oleg Korsunsky 2018 Polyfill for CSS position sticky httpsgithubcomwilddeerstickyfill

[46] Andreas Kurtz Hugo Gascon Tobias Becker Konrad Rieck and Felix Freiling2017 Fingerprinting mobile devices using personalized configurations Proceed-ings on Privacy Enhancing Technologies (PoPETs) 2016 1 (2017) 4ndash19

[47] Pierre Laperdrix Benoit Baudry and Vikas Mishra 2017 FPRandom Randomiz-ing core browser objects to break advanced device fingerprinting techniques InInternational Symposium on Engineering Secure Software and Systems Springer97ndash114

[48] Pierre Laperdrix Walter Rudametkin and Benoit Baudry 2016 Beauty and thebeast Diverting modern web browsers to build unique browser fingerprints InProceedings of the 37th IEEE Symposium on Security and Privacy (SampP) 878ndash894

[49] Jonathan R Mayer 2009 ldquoAny person a pamphleteerrdquo Internet anonymity inthe age of Web 20 Undergraduate Senior Thesis Princeton University (2009)

[50] Jonathan R Mayer and John C Mitchell 2012 Third-party web tracking Policyand technology In Proceedings of the 33rd IEEE Symposium on Security and Privacy(SampP) 413ndash427

[51] Maryam Mehrnezhad Ehsan Toreini Siamak F Shahandashti and Feng Hao2015 TouchSignatures Identification of user touch actions based on mobilesensors via JavaScript In Proceedings of the 10th ACM Symposium on InformationComputer and Communications Security (ASIACCS) 673ndash673

[52] Georg Merzdovnik Markus Huber Damjan Buhov Nick Nikiforakis SebastianNeuner Martin Schmiedecker and Edgar Weippl 2017 Block me if you canA large-scale study of tracker-blocking tools In IEEE European Symposium onSecurity and Privacy (EuroSampP) 319ndash333

[53] Yan Michalevsky Dan Boneh and Gabi Nakibly 2014 Gyrophone Recognizingspeech from gyroscope signals In Proceedings of the 23rd USENIX Conference onSecurity Symposium 1053ndash1067

[54] Modernizr 2018 Respond to your userrsquos browser features httpsmodernizrcom

[55] Sue B Moon Paul Skelly and Don Towsley 1999 Estimation and removal of clockskew from network delay measurements In Proceedings of the 18th Annual IEEEInternational Conference on Computer Communications (INFOCOM) 227ndash234

[56] Keaton Mowery and Hovav Shacham 2012 Pixel perfect Fingerprinting canvasin HTML5 In Proceedings of Web 20 Security and Privacy Workshop (W2SP)

[57] Mozilla Foundation 2018 Public suffix list httpspublicsuffixorg[58] Nick Nikiforakis Luca Invernizzi Alexandros Kapravelos Steven Van Acker

Wouter Joosen Christopher Kruegel Frank Piessens and Giovanni Vigna 2012You are what you include Large-scale evaluation of remote JavaScript inclusionsIn Proceedings of the 19th ACM SIGSAC conference on Computer and Communica-tions Security (CCS) 736ndash747

[59] Nick Nikiforakis Wouter Joosen and Benjamin Livshits 2015 PriVaricator De-ceiving fingerprinters with little white lies In Proceedings of the 24th InternationalConference on World Wide Web (WWW) 820ndash830

[60] Nick Nikiforakis Alexandros Kapravelos Wouter Joosen Christopher KruegelFrank Piessens and Giovanni Vigna 2013 Cookieless monster Exploring theecosystem of web-based device fingerprinting In Proceedings of the 34th IEEESymposium on Security and Privacy (SampP) 541ndash555

[61] Lukasz Olejnik 2017 Stealing sensitive browser data with theW3C ambient light sensor API httpsbloglukaszolejnikcomstealing-sensitive-browser-data-with-the-w3c-ambient-light-sensor-api

[62] Lukasz Olejnik Gunes Acar Claude Castelluccia and Claudia Diaz 2015 Theleaking battery In International Workshop on Data Privacy Management 254ndash263

[63] Emmanuel Owusu Jun Han Sauvik Das Adrian Perrig and Joy Zhang 2012ACCessory Password inference using accelerometers on smartphones In Pro-ceedings of the 12th Workshop on Mobile Computing Systems and Applications(HotMobile) 91ndash96

[64] PerimeterX 2018 Stop bot attacks Bot detection and bot protection with unpar-alleled accuracy httpswwwperimeterxcom

[65] Mike Perry Erinn Clark Steven Murdoch and George Koppen 2018 The designand implementation of the Tor browser (DRAFT) httpswwwtorprojectorgprojectstorbrowserdesign

[66] Davy Preuveneers and Wouter Joosen 2015 Smartauth Dynamic context finger-printing for continuous user authentication In Proceedings of the 30th AnnualACM Symposium on Applied Computing 2185ndash2191

[67] Samsung Newsroom 2014 10 Sensors of Galaxy S5 Heartrate finger scanner and more httpsnewssamsungcomglobal10-sensors-of-galaxy-s5-heart-rate-finger-scanner-and-more

[68] Florian Scholz et al 2017 Devicemotion - web APIs | MDN httpsdevelopermozillaorgen-USdocsWebEventsdevicemotion

[69] scikit-learn developers 2018 Python sklearn DBSCAN httpscikit-learnorgstablemodulesgeneratedsklearnclusterDBSCANhtml

[70] scikit-learn developers 2018 Python sklearn RandomForestClassi-fier httpscikit-learnorgstablemodulesgeneratedsklearnensembleRandomForestClassifierhtml

[71] Connor Shea et al 2018 DeviceLightEvent - web APIs | MDN httpsdevelopermozillaorgen-USdocsWebAPIDeviceLightEvent

[72] Connor Shea et al 2018 DeviceProximityEvent - web APIs | MDN httpsdevelopermozillaorgen-USdocsWebAPIDeviceProximityEvent

[73] Muhammad Shoaib Stephan Bosch Ozlem Durmaz Incel Hans Scholten andPaul J M Havinga 2014 Fusion of smartphone motion sensors for physicalactivity recognition Sensors 14 6 (2014) 10146ndash10176

[74] Ronnie Simpson 2016 Mobile and tablet internet usage exceeds desktop forfirst time worldwide | StatCounter Global Stats httpgsstatcountercompressmobile-and-tablet-internet-usage-exceeds-desktop-for-first-time-worldwide

[75] Sizmek 2018 Impressions that inspire httpswwwsizmekcom

[76] Jan Spooren Davy Preuveneers and Wouter Joosen 2015 Mobile device finger-printing considered harmful for risk-based authentication In Proceedings of the8th European Workshop on System Security (EuroSec) ACM 1ndash6

[77] Emily Stark Mike Hamburg and Dan Boneh 2017 Stanford JavaScript CryptoLibrary httpsgithubcombitwiseshiftleftsjclblobmastersjcljs

[78] Oleksii Starov and Nick Nikiforakis 2017 XHOUND Quantifying the finger-printability of browser extensions In Proceeding of the 38th IEEE Symposium onSecurity and Privacy (SampP) 941ndash956

[79] Xing Su Hanghang Tong and Ping Ji 2014 Activity recognition with smartphonesensors Tsinghua Science and Technology 19 3 (2014) 235ndash249

[80] Rich Tibbett Tim Volodine Steve Block and Andrei Popescu 2018 Device-Orientation event specification httpsw3cgithubiodeviceorientation

[81] Christof Ferreira Torres Hugo Jonker and Sjouke Mauw 2015 FP-Block Usableweb privacy by controlling browser fingerprinting In European Symposium onResearch in Computer Security (ESORICS) Springer 3ndash19

[82] Tom Van Goethem and Wouter Joosen 2017 One side-channel to bring themall and in the darkness bind them Associating isolated browsing sessions InProceeding of the 11th USENIX Workshop on Offensive Technologies (WOOT)

[83] Tom Van Goethem Wout Scheepers Davy Preuveneers and Wouter Joosen 2016Accelerometer-based device fingerprinting for multi-factor mobile authenticationIn Proceeding of the International Symposium on Engineering Secure Software andSystems 106ndash121

[84] Valentin Vasilyev 2018 fingerprintjs2 Modern amp flexible browser fingerprintinglibrary httpsgithubcomValvefingerprintjs2

[85] Antoine Vastel Pierre Laperdrix Walter Rudametkin and Romain Rouvoy 2018FP-STALKER Tracking browser fingerprint evolutions In Proceeding of the 39thIEEE Symposium on Security and Privacy (SampP) 1ndash14

[86] Matthew Wagerfield 2017 Parallaxjs httpsgithubcomwagerfieldparallax[87] Rick Waldron Mikhail Pozdnyakov and Alexander Shalamov 2017 Sensor use

cases W3C Note httpsw3cgithubiosensorsusecaseshtml[88] Zhi Xu Kun Bai and Sencun Zhu 2012 TapLogger Inferring user inputs on

smartphone touchscreens using on-board motion sensors In Proceedings of the5th ACM Conference on Security and Privacy in Wireless and Mobile Networks(WISEC) 113ndash124

[89] Zhe Zhou Wenrui Diao Xiangyu Liu and Kehuan Zhang 2014 Acoustic finger-printing revisited Generate stable device ID stealthily with inaudible sound InProceedings of the 21st ACM SIGSAC Conference on Computer and CommunicationsSecurity (CCS) 429ndash440

A CLUSTERING PSEUDO-CODE

1 check if clusters can be combined

2 def pairwise_cluster_comparison(features clusters)

3 pairwise_merge =

4 for i in sorted(set(clusters))5 for j in sorted(set(clusters))6 if i == j or i == -1 or j == -1 continue7 labels = npcopy(clusters) restore original labels

8 labels[labels == j] = i

9 inds = npwhere(labels gt= 0)[0] only consider non-noisy samples

10 val = silhouette_score(features[inds] labels[inds])

11 pairwise_merge[(ij)] = val

12 return pairwise_merge

13 classify noisy samples

14 def classification(features labels thres limit=None)

15 clusters = npcopy(labels)

16 clf = RandomForestClassifier(n_estimators=100 max_features=auto)

17 X_train = features[npwhere(labels gt= 0) ]

18 y_train = labels[npwhere(labels gt= 0) ]

19 X_test = features[npwhere(labels == -1) ]

20 y_test = labels[npwhere(labels == -1) ]

21 clffit(X_train y_train)

22 res = clfpredict(X_test)

23 prob = clfpredict_proba(X_test)

24 max_prob = npmax(prob axis=1) only take the max prob value

25 for i in range(min(limit len(prob)))26 ind = npargmax(max_prob)

27 if max_prob[ind] gt thres

28 y_test[ind] = res[ind]

29 max_prob[ind] = 00 replace the prob

30 clusters[clusters == -1] = y_test

31 return clusters

32 Phase 1 Clustering scripts using DBSCAN

33 dbscan = DBSCAN(eps=01 min_samples=3 metric=dice algorithm=auto)

34 labels = dbscanfit(script_features)labels_

35 Phase 2 Merge clusters

36 first_max = None last_max = None

37 while True

38 res = pairwise_cluster_comparison(script_features labels)

39 last_max = max(resvalues())40 maxs = [i for i j in resitems() if j == last_max]

41 first_max = last_max if first_max == None

42 if first_max - last_max lt 005

43 largest_cluster selected = 0 None

44 for xy in maxs

45 f1 = len(npwhere(labels == x)[0])

46 f2 = len(npwhere(labels == y)[0])

47 if largest_cluster lt max(f1 f2)

48 selected = (x y) if f1 gt f2 else (y x)

49 largest_cluster = max(f1 f2)

50 labels[labels == selected[1]] = selected[0]

51 else break52 Phase 3 Classify noisy samples

53 final_label = None

54 while True

55 nlabels = classification(script_features labels 07 5)

56 if nparray_equal(nlabels labels)

57 final_label = labels

58 break59 else labels = nlabels

Listing 1 Code for different phases of clustering scripts

B EXAMPLE SENSOR-ACCESSING SCRIPTS

1 dvObjpubSubsubscribe(rtnName impId SenseTag_RTN function()

3 var maxTimesToSend = 2

4 var avgX = 0 avgY = 0 avgZ = 0 avgX2 = 0 avgY2 = 0 avgZ2 = 0 countAcc = 0 accInterval = 0

5 function dvDoMotion()

7 if (maxTimesToSend lt= 0)

8 windowremoveEventListener(devicemotion dvDoMotion false)9 return10

11 var motionData = eventaccelerationIncludingGravity

12 if ((motionDatax) || (motionDatay) || (motionDataz))

13 var isError = 0 var x = 0 var y = 0 var z = 0

14 if (motionDatax) x = motionDatax

15 else isError += 1

16 if (motionDatay) y = motionDatay

18 if (motionDataz) z = motionDataz

20 avgX = ((avgX countAcc) + x) (countAcc + 1)

21 avgX2 = ((avgX2 countAcc) + (x x)) (countAcc + 1)

22 avgY = ((avgY countAcc) + y) (countAcc + 1)

23 avgY2 = ((avgY2 countAcc) + (y y)) (countAcc + 1)

24 avgZ = ((avgZ countAcc) + z) (countAcc + 1)

25 avgZ2 = ((avgZ2 countAcc) + (z z)) (countAcc + 1)

26 countAcc++

27 accInterval = eventinterval

28 if (countAcc 400 == 1)

29 maxTimesToSend--

30 sensorObj =

31 sensorObj[MED_AMtX] = Mathmax(Mathmin(avgX 10000) -10000)toFixed(7)

32 sensorObj[MED_AMtY] = Mathmax(Mathmin(avgY 10000) -10000)toFixed(7)

33 sensorObj[MED_AMtZ] = Mathmax(Mathmin(avgZ 10000) -10000)toFixed(7)

34 sensorObj[MED_AVrX] = Mathmax(Mathmin((avgX2 - avgX avgX) 10000) -10000)toFixed(7)

35 sensorObj[MED_AVrY] = Mathmax(Mathmin((avgY2 - avgY avgY) 10000) -10000)toFixed(7)

36 sensorObj[MED_AVrZ] = Mathmax(Mathmin((avgZ2 - avgZ avgZ) 10000) -10000)toFixed(7)

37 sensorObj[MED_ANum] = countAcc

38 sensorObj[MED_AInterval] = accInterval

39 dvObjregisterEventCall(impId sensorObj 2000 true)40

42 catch (e)

44 setTimeout(function()

45 try

46 if (windowaddEventListener == undefined) return47 windowaddEventListener(devicemotion dvDoMotion)

48 catch (e) 3000)

49 catch (e)

Listing 2 JavaScript snippet from doubleverifycom computing average and variance of accelerometer data

https tps10212 doubleverify comevent gif impid=0b86b20d52a84923a41d85da169fd97fampmsrdp=1ampnaral=80ampvct=1ampengalms=83ampengisel=1ampMED_AMtX=28139038ampMED_AMtY=76222534ampMED_AMtZ=40931549ampMED_AVrX=00000000ampMED_AVrY=00000000ampMED_AVrZ=00000000ampMED_ANum=1ampMED_AInterval=16666ampcbust=1508977547663635

Listing 3 doubleverifycom script sending average and variance of sensor data as URL parameters to their servers

1 collecting sensor data

2 cdma function (t)

4 if (cf[_ac[109]] lt cf[_ac[254]] ampamp cf[_ac[497]] lt 2 ampamp t)

5 var e = cf[_ac[374]]() - cf[_ac[253]] c = -1 n = -1 a = -1

6 t[_ac[157]] ampamp (

7 c = cf[_ac[554]](t[_ac[157]][_ac[413]])

8 n = cf[_ac[554]](t[_ac[157]][_ac[190]])

9 a = cf[_ac[554]](t[_ac[157]][_ac[524]]) )

10 var o = -1 f = -1 i = -1

11 t[_ac[310]] ampamp (

12 o = cf[_ac[554]](t[_ac[310]][_ac[413]])

13 f = cf[_ac[554]](t[_ac[310]][_ac[190]])

14 i = cf[_ac[554]](t[_ac[310]][_ac[524]]) )

15 var r = -1 d = -1 s = 1

16 t[_ac[526]] ampamp (

17 r = cf[_ac[554]](t[_ac[526]][_ac[62]])

18 d = cf[_ac[554]](t[_ac[526]][_ac[548]])

19 s = cf[_ac[554]](t[_ac[526]][_ac[515]]) )

20 var u = cf[_ac[109]] + _ac[66] + e + _ac[66] + c + _ac[66] + n + _ac[66] + a +

21 _ac[66] + o + _ac[66] + f + _ac[66] + i + _ac[66] + r + _ac[66] + d + _ac[66] +

22 s + _ac[379]

23 cf[_ac[496]] = cf[_ac[496]] + u

24 cf[_ac[68]] += e

25 cf[_ac[335]] = cf[_ac[335]] + cf[_ac[109]] + e

26 cf[_ac[109]]++

28 cf[_ac[69]] ampamp cf[_ac[109]] gt 1 ampamp cf[_ac[419]] lt cf[_ac[626]] ampamp (

29 cf[_ac[120]] = 7

30 cf[_ac[609]]()

31 cf[_ac[194]](0)

32 cf[_ac[340]] = 1

33 cf[_ac[419]]++ )

34 cf[_ac[497]]++

35 catch (t)

37 sending encoded data to remote server

38 apicall_bm function (t e c)

39 var n

40 void 0 == window[_ac[175]]

41 n = new XMLHttpRequest

43 (n = new XDomainRequest n[_ac[158]] = function ()

44 this[_ac[269]] = 4

45 this[_ac[567]] instanceof Function ampamp this[_ac[567]]())46 n = new ActiveXObject(_ac[450])

47 n[_ac[587]](_ac[291] t e)

48 void 0 == n[_ac[360]] ampamp (n[_ac[360]] = 0)

49 var a = cf[_ac[258]](cf[_ac[75]] + _ac[85])

50 cf[_ac[302]] = _ac[123] + a + _ac[611]

51 void 0 == n[_ac[279]] ampamp (

52 n[_ac[279]](_ac[534] _ac[115])

53 cf[_ac[302]] = _ac[538])

54 var o = _ac[266] + cf[_ac[261]] + _ac[611] + cf[_ac[302]] + _ac[100]

55 n[_ac[567]] = function ()

56 n[_ac[269]] gt 3 ampamp c ampamp c(n)

58 n[_ac[101]](o)

Listing 4 Obfuscated JavaScript snippet from homedepotcom_bmasyncjs collecting sensor data

C SENSOR DATA EXFILTRATION EXAMPLE PAYLOADS

parameter url$0$https mobile reuters com referrer$ 0$ ancestorOrigins$0$na video$0$360x592x24 frame$0$0 hidden$0$0 visibilityState$ 1 $visible window$1$344x521inner$1$360x521outer$1$360x592 localStorage$ 3$1 sessionStorage$3$1

appCodeName$4$MozillaappName$4$NetscapeappVersion$4$50 (Android 70) cookieEnabled$4$true doNotTrack$4$unspecified hardwareConcurrency$4$8language$5$enminusUSplatform$5$Linux armv7lproduct$5$GeckoproductSub$5$20100101sendBeacon$5$1userAgent$5$Mozilla5 0 (Android 70 Mobile rv 55 0) Gecko550 Firefox 550 vendor$5$ vendorSub$5$ fontrender$8$1 webgl$239$1time$240$1526528127627timezone$240$0 plugins$240$Nonetimeminus fetchStart$ 241$321 timeminusdomainLookupStart$241$324timeminusdomainLookupEnd$241$324timeminusconnectStart$241$324timeminusconnectEnd$241$339timeminusrequestStart$241$367timeminusresponseStart$241$383timeminusresponseEnd$241$414timeminusdomLoading$241$418timeminusdomInteractive$241$4533timeminusdomContentLoadedEventStart$241$4828timeminusdomContentLoadedEventEnd$241$4966navigationminusredirectCount$241$0navigationminustype$241$navigateglobalsminustime$266$0705globals$269$a8bb2f85documentminustime$272$043document$274$0a886779clock$288$662intersection$ 293$na battery$299$1 1 0 Infinity devicelight$ 325$987 framerate$461$10 sort$763$121685 deviceproximity$817$3 userproximity$1295$near orientation$ 1297$43123402478330654 3298760746072672 21654300663242278 motion$1305$012560407138550994 -012339847737456243 -018449644504208473 audiocontext$2044$d554bfaa

Listing 5 Orientationmotion light and proximity data is sent to httpsapi-34-216-170-51b2ccomapixparameter=[]on reuterscom website

is_supposed_final_message false message_number1 message_time7736 query_string e 36 ue 1 uu 1 qa 360 qb 592 qc 0 qd 0 qf 360 qe 521 qh 360 qg 592 qi 360 qj 592 ql qo 0 qm0 user_agent Mozilla 5 0 (Android 70 Mobile rv 55 0) Gecko550 Firefox 550 location https i stuff conz referrer https wwwstuffconz numbers[minus99864611549774990071992547409946 2831853071795865 436563656918090 9150885074842403minus18369701987210297eminus16minus054019288100151855551115123125783eminus167600875484570224] plugins 101574 graphics_card cpu_cores 8 canvas_render 1490412693 webgl_render 3707405031 installed_fonts [ DotumDotumCheGulim GulimChe Malgun Gothic Meiryo UI Microsoft JhengHei Microsoft YaHei MONOMS UIGothic] RTCPeerConnectionRTCPeerConnectionWebSocket WebSocket unloadEventStart 0 unloadEventEnd0 sahimap TypeError windowSahiHashMap is undefined color_depth 24 min_safe_int minus9007199254740991gz false gz_cde false input key_times [] key_delta_meanminus1 key_delta_var minus1 mouse[] mousedowns[] orientation [[1526540170271[ false 43123406989295376 3298760380966044 21654305428432068]] [1526540175119[ false 43123405666163535 32987604652675195 21654303695580264]]]

Listing 6 Orientation data is sent to httpspx2moatadscompixelgifv=[] on stuffconz website

payload=[ t PX164d PX165[012560246652278528 -012339765619546963 -018449742637532154 012560876871457533 -012339147047919652 -018449095921522524 01256049922328881 -012339788204758717 -01844980715878096

012560647137074932 -012339009836285393 -01844992891051791] PX63Linux armv7l PX371true ]ampappId=PXpHWOqUmuamptag=v3191ampuuid=b3b264b0minus5987minus11e8minus8ef7minus216942b9c24fampft=24ampseq=3ampcs=a829d69e16358d1daa46d1266c00266e44d900e411d6666bb1b4d9d908e1827camppc=7889002194399290ampsid=b3b8f462minus5987minus11e8minusae82minus6db5f4392e69ampvid=b3b8f460minus5987minus11e8minusae82minus6db5f4392e69

Listing 7 Motion data are sent to httpswwwkayakcompxxhrapiv1collector in base64-encoded form (decoded here)on kayakcom website

Abstract

1 Introduction

2 Background and Related Work

21 Mobile Sensor APIs

22 Different Uses of Sensor Data

23 Related Work

3 Data Collection and Methodology

31 OpenWPM-Mobile

32 Mimicking Sensor Events

33 Data Collection Setup

34 Feature Extraction

35 Feature Aggregation

4 Measurement Results

41 Prevalence of Scripts

42 Sensor Data Exfiltration

43 Crawl Comparison

5 Understanding Sensor Use Cases


52 Clustering Scripts

53 Validating Clustering Results

54 Real-world Use Cases

55 Analysis of Specific Scripts

6 Efficacy of Countermeasures

61 Fingerprinting Scripts

62 Ad Blocking and Tracking Protection Lists

63 Difference in Browser Behavior

7 Discussion and Recommendations

8 Limitations

9 Conclusion

10 Acknowledgements

References

A Clustering Pseudo-code

B Example Sensor-accessing Scripts

C Sensor Data Exfiltration Example Payloads