I Spy with My Little Eye: Analysis and Detection of Spying Browser Extensions
Anonymous Submission
\IEEEauthorblockN{Anupama Aggarwal\IEEEauthorrefmark{1
Several studies have been conducted on understanding third-party user tracking on the web. However, web trackers can only track users on sites where they are embedded by the publisher, thus obtaining a fragmented view of a user's online footprint. In this work, we investigate a different form of user tracking, where browser extensions are repurposed to capture the complete online activities of a user and communicate the collected sensitive information to a third-party domain. We conduct an empirical study of spying browser extensions on the Chrome Web Store. First, we present an in-depth analysis of the spying behavior of these extensions. We observe that these extensions steal a variety of sensitive user information, such as the complete browsing history (e.g., the sequence of web traversals), online social network (OSN) access tokens, IP address, and user geolocation. Second, we investigate the potential for automatically detecting spying extensions by applying machine learning schemes. We show that using a Recurrent Neural Network (RNN), the sequences of browser API calls can be a robust feature, outperforming hand-crafted features (used in prior work on malicious extensions) to detect spying extensions. Our RNN based detection scheme achieves a high precision (90.02\%) and recall (93.31\%) in detecting spying extensions.
analysis.tex
%!TEX root = main.tex
\section{Analysis of Spying Extensions} 
\label{sec:analysis}
\noindent We analyze various aspects of spying extensions, including its behavior, popularity and reputation, and developers. Our analysis serves as a first step towards understanding operational aspects of spying extensions before we explore techniques for automatic detection in Section~\ref{sec:detection}. 
%\noindent We analyze various aspects of spying extensions, including its behavior, and popularity and reputation in the Chrome store. We also investigate characteristics of the developers of spying extensions. Our analysis serves as a first step towards better understanding operational aspects of spying extensions, before we explore techniques for automatic detection in Section~\ref{sec:detection}. 

%We first investigate the modus operandi of spying extensions to understand in detail how permission model and Chrome API endpoints are used in spying behavior. Next, we also extract static signals based on the meta-information of extensions like the source code and descriptive information along with crowdsourced data present on the Chrome Web Store.

\subsection{Modus Operandi of Spying Extensions}
%\noindent We present an in-depth study of types of user information tracked, permissions that enable spying behavior, and where information is sent by the extensions. We later use these signals to model an automatic detection framework for spying extensions.
%\noindent Based on our verification technique to identify spying behavior (Section~\ref{sec:dataset}), we further distill our observations to uncover the modus operandi of spying extensions. We present an in-depth study of types of user information tracked, permissions that enable spying behavior, and where information is sent by the extensions. We later use these signals to model an automatic detection framework for spying extensions.
%We further distill our observations based on these logs to uncover the modus operandi of spying extensions. We present an in-depth study of which permissions enable spying behavior, what user information is tracked and where is this user information being sent. 
%\noindent In this section, we analyze various aspects of spying extensions in detail and understand how spying extensions operate. all that we run each extension in Chrome Web Store in a controlled environment and fetch the generated network logs, storage change logs and browser API call log. We use these logs to detect spying behavior of extensions. 
%Based on our verification technique to identify spying behavior (Section~\ref{}), we further distill our obser
%We further distill our observations based on these logs to uncover the modus operandi of spying extensions. We present an in-depth study of which permissions enable spying behavior, what user information is tracked and where is this user information being sent. 

\subsubsectitle{\textbf{Information Tracked.}}  \label{subsubsec:whatistracked}
\noindent Table~\ref{tab:infotrack} shows the different types of user information tracked by spying extensions. We find that most of the extensions steal browsing history of users (\ie complete URLs of sites visited), albeit there are two extensions that only track domains visited by the users. Information about browsing history can provide access to sensitive and private documents on services like Google Drive, Dropbox and Pastebin where a document can be accessed by anyone with a link to the document. We also found extensions stealing IP address, geolocation, and social media access tokens. Extensions were using social media access tokens to access private information of users such as photos, posts, closed groups and private messages. Overall, once stolen, the user has no control over how any of this data is further used. 
%\acsac{Nevertheless, I  liked the creation of behavioral groups and the classification of the extensions into the five groups.} \anu{My guess is that reviewer is talking about Table 3 here, writing five by mistake instead of four.}

\begin{table}[h]
\centering
\begin{tabular}{@{}ll@{}}
\toprule
Information Tracked     & \#Total  \\ \midrule %& \#Removed \\ \midrule
Browsing History        & 202 \\%   & 1         \\
IP Address, Geolocation & 10   \\%  & 0         \\ 
OSM Access Tokens       & 4   \\%   & 3         \\
Domain Visited          & 2   \\ \midrule % & 1         \\ \midrule
%Web Traversal History   & 192    & 1         \\
%Keypresses              & 0      & 0         \\
Total Unique            & 218   \\ \bottomrule % & 4         \\ \bottomrule
\end{tabular}
\caption{User information stolen by spying extensions}
\label{tab:infotrack}
\end{table}

%Information about browsing history can also provide access to sensitive and private documents on services like Google Drive, Dropbox and Pastebin where a document can be accessed by anyone with a link to the document. Once stolen, the user has no control over how this data is further used. Browsing history may not only expose users to more targetted advertising, but can also lead to differential services and price discrimination on various e-commerce sites~\cite{hannak2014measuring}. Browsing history combined with geolocation and IP address information could be used by governments to track political dissidents or by other entities interested in launching targeted attacks against the user~\cite{marczak2014governments}. 

%\noindent Table~\ref{tab:infotrack} shows the different types of user information tracked by spying extensions.  We find that most of the extensions spy on browsing history of users, albeit there are two extensions that only track domains visited by users. Information about browsing history can also provide access to sensitive and private documents on services like Google Drive, Dropbox and Pastebin where a document can be accessed by anyone with a link to the document. Once stolen, the user has no control over how this data is further used. Browsing history may not only expose users to more targetted advertising, but can also lead to differential services and price discrimination on various e-commerce sites~\cite{hannak2014measuring}. Browsing history combined with geolocation and IP address information could be used by governments to track political dissidents or by other entities interested in launching targeted attacks against the user~\cite{marczak2014governments}. We also found spying extensions stealing Social Media access tokens and using them to access private information of users such as photos, posts, closed groups and private messages. 
%\noindent Table~\ref{tab:infotrack} shows the different types of sensitive information tracked by spying extensions. Once stolen, the user has no control over how this data is further used. We find that most of the extensions spy on the browsing history of users, albeit there are two extensions only track domains that users visit. Browsing history may not only expose users to more targetted advertising, but can also lead to differential services and price discrimination on various e-commerce sites~\cite{hannak2014measuring}. Browsing history combined with geolocation and IP address information could be used by governments to track political dissidents or by other entities interested in launching targeted attacks against the user~\cite{marczak2014governments}. Information about browsing history can also provide access to sensitive and private documents on services like Google Drive, Dropbox and Pastebin where a document can be accessed by anyone with link to the document. We also found spying extensions stealing Social Media access tokens and using them to access private information of users such as - photos, posts, closed groups and private messages.


%\begin{table*}
%\centering
%\subfloat[User information stolen]{\begin{tabular}{@{}ll@{}}
%\toprule
%Information Tracked     & \#Total  \\ \midrule %& \#Removed \\ \midrule
%Browsing History        & 202 \\%   & 1         \\
%IP Address, Geolocation & 10   \\%  & 0         \\ 
%OSM Access Tokens       & 4   \\%   & 3         \\
%Domain Visited          & 2   \\ \midrule % & 1         \\ \midrule
%%Web Traversal History   & 192    & 1         \\
%%Keypresses              & 0      & 0         \\
%Total Unique            & 218   \\ \bottomrule % & 4         \\ \bottomrule
%\label{tab:infotrack}
%\end{tabular}}
%\quad \quad \quad \quad
%\subfloat[Permissions to access user information]{\begin{tabular}{llll}
%\toprule
%	 & 				 &\texttt{CWS\_Spy}    			&$\texttt{CWS\_All} \setminus \texttt{CWS\_Spy}$ \\
%	 & Permission    & \#ext (\%)  			    	& \#ext (\%)    \\ \midrule
%1    & tabs          & 207 (94.95) 					& 22483 (52.24) \\
%2    & cookies       & 181 (83.03)					& 3844 (8.93)   \\
%3    & storage       & 22 (10.09)  					& 13376 (31.08) \\
%4    & all urls      & 14 (6.42)   					& 4022 (9.35)   \\
%5    & history       & 6 (2.75)    					& 862 (2.0)     \\
%6    & geolocation   & 3 (1.38)    					& 378 (0.88)    \\
%7    & activeTab     & 3 (1.38)   					& 5920 (13.76)  \\
%\bottomrule 
%\label{tab:access_cap} 
%\end{tabular}}
%\caption{Table shows what user information is leaked by spying extensions and which Chrome specific permissions are used to access user information}
%\end{table*}

%\begin{table*}
%\begin{tabular}{ll}
%\begin{tabular}{@{}ll@{}}
%\toprule
%Information Tracked     & \#Total  \\ \midrule %& \#Removed \\ \midrule
%Browsing History        & 202 \\%   & 1         \\
%IP Address, Geolocation & 10   \\%  & 0         \\ 
%OSM Access Tokens       & 4   \\%   & 3         \\
%Domain Visited          & 2   \\ \midrule % & 1         \\ \midrule
%%Web Traversal History   & 192    & 1         \\
%%Keypresses              & 0      & 0         \\
%Total Unique            & 218   \\ \bottomrule % & 4         \\ \bottomrule
%\label{tab:infotrack}
%\end{tabular}
%&
%\begin{tabular}{ll|l|l}
%\toprule
%	 & 				 &\texttt{CWS\_Spy}    			&$\texttt{CWS\_All} \setminus \texttt{CWS\_Spy}$ \\
%	 & Permission    & \#ext (\%)  			    	& \#ext (\%)    \\ \midrule
%1    & tabs          & 207 (94.95) 					& 22483 (52.24) \\
%2    & cookies       & 181 (83.03)					& 3844 (8.93)   \\
%3    & storage       & 22 (10.09)  					& 13376 (31.08) \\
%4    & all urls      & 14 (6.42)   					& 4022 (9.35)   \\
%5    & history       & 6 (2.75)    					& 862 (2.0)     \\
%6    & geolocation   & 3 (1.38)    					& 378 (0.88)    \\
%7    & activeTab     & 3 (1.38)   					& 5920 (13.76)  \\
%\bottomrule 
%\label{tab:access_cap} 
%\end{tabular}
%\end{tabular}
%\end{table*}
%\vspace{-1cm}

%\begin{table}[h]
%\centering
%\small
%\begin{tabular}{@{}ll@{}}
%\toprule
%Information Tracked     & \#Total  \\ \midrule %& \#Removed \\ \midrule
%Browsing History        & 202 \\%   & 1         \\
%IP Address, Geolocation & 10   \\%  & 0         \\ 
%OSM Access Tokens       & 4   \\%   & 3         \\
%Domain Visited          & 2   \\ \midrule % & 1         \\ \midrule
%%Web Traversal History   & 192    & 1         \\
%%Keypresses              & 0      & 0         \\
%Total Unique            & 218   \\ \bottomrule % & 4         \\ \bottomrule
%\end{tabular}
%\caption{Information Tracked by Spying Extensions. We found spying extensions to be spying on user's browsing history, IP address, location, social media access tokens, and user visited domains.}
%\label{tab:infotrack}
%\end{table}

\subsubsectitle{\textbf{Spying Behavior.}} \label{subsec:capabilities} 
\noindent To understand how a spying extension works, we investigate the following aspects: (1) ability to access specific types of sensitive user information, (2) ability to store information (may not be used always), (3) ability to send tracked information to a remote server, (4) remote entities stealing the information, and (5) Remote Command-and-Control (CnC) setup used by spying extensions. 

In each part (whenever relevant), we analyze the specific permissions used by extensions to access various privileged Chrome API endpoints. To obtain this information, we first identify the different Chrome API endpoints required by spying extensions for accessing, storing and sending personal data (Section~\ref{sec:dataset}). We then map the different Chrome API endpoints used by an extension to specific permission requirements\footnote{Chrome Permissions~\url{developer.chrome.com/extensions/declare_permissions}}. 

%Extensions require specific permissions to access various Chrome API endpoints. These special privileges are misused by extensions to spy on users and steal personal information. In this section, we present the various permissions required for the three types of capabilities. 

%Lastly, we also investigate how a spying extension is controlled by a remote CnC server and the domains where personal data is sent.
%\noindent To understand how a spying extension works, we break down the capabilities of a spying extension into the following three categories: (1) ability to access specific types of sensitive user information (2) ability to store information (may not be used always) and, (3) ability to send tracked information to a remote server. Extensions require specific permissions to access various Chrome API endpoints. These special privileges are misused by extensions to spy on users and steal personal information. In this section, we present the various permissions required for the three types of capabilities. To obtain this information, we first identify the different Chrome API endpoints required by spying extensions for accessing, storing and sending personal data (Section~\ref{sec:dataset}). We then map the different Chrome API endpoints used by an extension to specific permission requirements~\cite{Google:lr}. Lastly, we also investigate how a spying extension is controlled by a remote CnC server and the domains where personal data is sent.

\subsubsectitle{(1) Accessing sensitive user information.} Table~\ref{tab:access_cap} shows a list of permissions required for accessing sensitive user information. For comparison purposes, we also show the number (and percentage) of all other extensions ($\texttt{CWS\_All} \setminus \texttt{CWS\_Spy}$) that use the same permissions (possibly for other purposes). Spying extensions can continuously monitor user's browsing behavior with the help of `tabs', `activeTab' and `all urls' permissions which enable them to access the URL being visited at the moment by a user. We observe that the `tabs' permission ranks at the top (being used by over 94\% of spying extensions), but also used by a majority of all other extensions. Similarly, the `cookies' permission is also used by most (83\%) of the spying extensions (e.g., to access social media access tokens), but only by a smaller fraction (8.9\%) of all other extensions. Browsing history and location can also be tracked by direct access to `history' and `geolocation' permissions.

\begin{table}[h]
\centering
\begin{tabular}{llll}
\toprule
	 & 				 &\texttt{CWS\_Spy}    			&$\texttt{CWS\_All} \setminus \texttt{CWS\_Spy}$ \\
	 & Permission    & \#ext (\%)  			    	& \#ext (\%)    \\ \midrule
1    & tabs          & 207 (94.95) 					& 22,483 (52.24) \\
2    & cookies       & 181 (83.03)					& 3,844 (8.93)   \\
3    & storage       & 22 (10.09)  					& 13,376 (31.08) \\
4    & all urls      & 14 (6.42)   					& 4,022 (9.35)   \\
5    & history       & 6 (2.75)    					& 862 (2.0)     \\
6    & geolocation   & 3 (1.38)    					& 378 (0.88)    \\
7    & activeTab     & 3 (1.38)   					& 5,920 (13.76)  \\
\bottomrule 
\end{tabular}
\caption{Permissions to access user information}
\label{tab:access_cap} 
\end{table}

%\begin{table}[h]
%\centering
%\small
%\begin{tabular}{ll|l|l}
%\toprule
%\multicolumn{2}{l|}{} & \texttt{CWS\_Spy}    		&$\texttt{CWS\_All} \setminus \texttt{CWS\_Spy}$ \\
%	 & Permission    & \#ext (\%)  			    	& \#ext (\%)    \\ \midrule
%1    & tabs          & 207 (94.95) 					& 22483 (52.24) \\
%2    & cookies       & 181 (83.03)					& 3844 (8.93)   \\
%3    & storage       & 22 (10.09)  					& 13376 (31.08) \\
%4    & all urls      & 14 (6.42)   					& 4022 (9.35)   \\
%5    & history       & 6 (2.75)    					& 862 (2.0)     \\
%6    & geolocation   & 3 (1.38)    					& 378 (0.88)    \\
%7    & activeTab     & 3 (1.38)   					& 5920 (13.76)  \\
%\bottomrule  
%\end{tabular}
%\caption{Permissions required by spying extensions to access sensitive user information.}
%\label{tab:access_cap}
%\end{table}
%\vspace{-0.25cm}
\subsubsectitle{(2) Storing sensitive user information.} %Table~\ref{tab:store_cap} lists the permissions to store user information and their distributions used over spying and other extensions. 
Spying extensions may or may not store user information on the client side. If they do, client-side cookies and `unlimited storage' permissions are used to store information either in plain text or in obfuscated form. This data is stored and accessed by extensions at regular intervals or periodically by a CnC remote server controlling the extension. We find that most of the spying extensions (188 out of 218) are storing user information before sending it to remote servers. We observe that 83\% of spying extensions access `cookie' permission (as compared to only 8.93\% other extensions) and 7\% of spying extensions have access to `unlimitedStorage' (compared to 6\% other extensions). Thus, inspecting local storage could be useful to identify spying behavior.  

%compared to other extensions where the fraction. Thus inspecting local storage would be useful in identifying spying behavior.  
%\begin{table}[h]
%\centering
%\small
%\begin{tabular}{ll|c|c}
%\toprule
%\multicolumn{2}{l|}{}    & \texttt{CWS\_Spy}         & $\texttt{CWS\_All} \setminus \texttt{CWS\_Spy}$    \\ 
% & Permission       & \#ext (\%)  & \#ext (\%)  \\ \midrule
%1    & cookies          & 181 (83.03)  & 3844 (8.93) \\
%2    & unlimitedStorage & 16 (7.34)  & 2737  (6.32)\\ \bottomrule
%\end{tabular}
%\caption{Permissions required by spying extensions to store information on the client-side.}
%\label{tab:store_cap}
%\end{table}
%\vspace{-0.25cm}
\subsubsectitle{(3) Sending sensitive user information.} Spying extensions use various techniques to send user information to third party website. Spying extensions can use Chrome's WebRequest permission to send network request as a POST query with an obfuscated payload containing user information. Sometimes, spying extensions may also use Web API call instead of a specific Chrome API endpoint by making XMLHttpRequest to send a network request to a remote server. We find 64\% spying extensions using Chrome specific WebRequest API call to intercept and send network requests to a third party server, and the rest using Web API call---XMLHttpRequest to make a GET request to remote server.

%The most used methods to send data by spying extensions, to a third party website is by either making a POST request with user information in the payload (64\%) or a GET request with user information in the URL parameters (36\%). Extensions can make Web API call (XMLHttpRequest) to send a network request. However, to have access to more sophisticated information and browsing information of users, extensions can also ask for specific Chrome API permission (webRequest) which lets the extension to even intercept and modify client-side network request before making a call to third party website.\bimal{I don't understand this section. We need to chat again.}

%64\% spying extensions use webRequest permission to send user data as compared to only 11\% other extensions. Extensions use webRequest permission provided by browser to observe and analyze traffic and to intercept, block, or modify requests in-flight. This permission lets the spying extensions make network requests (using POST queries) to a remote server and is the most common method for sending sensitive information. \bimal{Does the remaining spying use GET fetch requests to steal data? Doesn't that still require webRequest permission?} Another method is to pass user information (either as it is, or obfuscated) as parameters of a GET request to fetch resources (e.g., an image) from a remote server. Previous studies have also found that extensions within top 10k on Chrome Web Store which leak sensitive information to third-party mostly use POST requests with obfuscated payload. \anu{to cite WWW17 paper}  %\bimal{what can we say about blocking?}

%\begin{table}[h]
%\centering
%\small
%\begin{tabular}{ll|c|c}
%\toprule
%\multicolumn{2}{l|}{}    & \texttt{CWS\_Spy}         & $\texttt{CWS\_All} \setminus \texttt{CWS\_Spy}$     \\ 
% & Permission       & \#ext (\%)  & \#ext (\%)  \\ \midrule
%1    & webRequest          & 140 (64.22)  & 4784 (11.05) \\ \bottomrule
%%2    & webRequestBlocking & 18 (8.26)  & 3607 (8.33)   \\ \bottomrule
%\end{tabular}
%\caption{Permissions required by chrome extensions to send client information to a remote server.}
%\label{tab:send_cap}
%\end{table}

%\vspace{-0.25cm} 
\subsubsectitle{(4) Remote spying entity.} We find that the 218 spying extensions send sensitive user information to 29 unique (TLD+1) domains. While most of the extensions contact a single domain, there are six extensions contacting more than one domain, thus sharing user data with multiple entities. %\bimal{These numbers don't add up. Can you check?}
%This is inline with previous studies which show leakage of sensitive information by extensions to multiple third-party URLs, with an average leakage to 1.5 trackers per extension \anu{to cite WWW paper}. 
The top 4 domains in our dataset are \url{wips.com}, \url{upalytics.com}, \url{analyticssgoogle.com} (different from Google Analytics) and \url{fairsharelabs.com}. 
%Interestingly, 5 out of 29 tracker domains belong to known browser extension monetization services (see earlier Section~\ref{sec:dataset}). It is unclear how this data is further used by the monetization services, but could probably be sold to other parties for profit or used for highly targeted behavioral advertising.

%In this section, we investigate the remote spying entities (or trackers) associated with each extension. We find that the 218 spying extensions sent sensitive user information to 29 unique tracker domains.\footnote{Tracker domain is the remote server where the user information is sent} We notice that 6 spying extensions were contacting more than one tracker, thus sharing user data with multiple entities. This is inline with previous studies which show leakage of sensitive information by extensions to multiple third-party URLs, with an average leakage to 1.5 trackers per extension \anu{to cite WWW paper}. Most contacted third-party URLs by the spying extensions in our dataset were - wips.com, upalytics.com, analyticssgoogle.com and fairsharelabs.com. Interestingly, 5 out of 29 tracker domains belong to known browser extension monetization services (see earlier Section~\ref{sec:dataset}). It is unclear how this data is further used by the monetization services, but could probably be sold to other parties for profit or used for highly targeted behavioral advertising.

To understand the reputation of the tracking domains, we query three popular blacklisting services---Google SafeBrowsing API~\cite{Google:ij}, VirusTotal~\cite{Virustotal:kk} and Phishtank~\cite{Phishtank:pi}. We also analyze their WoT (Web of Trust~\cite{wot}) ranking which is a crowd-sourced website reputation metric. None of the domains are blacklisted by any of the services, indicating that spying extensions are difficult to identify based on their tracker domains. In fact, eight tracker domains have a WOT score of over 9.0 (out of 10.0) which indicates very positive crowdsourced feedback.

\subsubsectitle{(5) Control of spying extension by a CnC server.} We observe that some extensions do not start spying on users at the time of installation. They need to be triggered by a remote server to either start collecting user data or to send the stored user data to the remote server. We observe two methods being used to control spying state: (1) spying state controlled by toggling flags in cookies and client-side storage, and (2) time-based triggers which send information after a certain period of time. This functionality makes detection of spying extensions a challenging task since they may act as benign during some period of time. We identify 88 extensions where the tracking code was toggled on and off using a state variable in the cookie store using `cookie.set' API call. We find two extensions using time-based triggers which start tracking after fixed periods according to a time defined in a source JavaScript file. These control triggers require the `webRequest' and `cookies' permissions. The remaining 128 extensions did not require any specific triggers to start spying. 
%\acsac{From Kapravelos et al. [23], we already knew the type of malicious behavior of these extensions and, from this point of view, the paper does not add much new}
%We were unable to identify any control triggers in the other spying extensions.


\subsection{Popularity and Reputation}
\noindent We analyze the popularity and reputation (based on crowdsourced feedback) of spying extensions and compare them with all extensions on the Chrome Store.
%We further analyze the meta-information of extensions provided on the Chrome Web Store like the description of the extension, developer, crowdsourced ratings and reviews. These signals can help identify spying extensions and in this section we draw comparison of these features of spying extensions as compared to other extensions on the Chrome Web Store.

%\subsubsectitle
\subsubsectitle{\textbf{User Base and Ratings.}} Figure~\ref{fig:metainfoanalysis} shows the distribution of various popularity statistics. Spying extensions have a similar distribution of number of users, average rating, and number of ratings as all other extensions on the Chrome store. It is important to note that just 218 spying extensions account for over 2.4 million cumulative installs, with a median rating of 4.4 (overall spying extensions). Thus, it would be hard to distinguish between spying and benign extensions based on popularity metrics for both Google (browser platform provider) and for users deciding whether to install an extension. We observe that extensions with large user base also exhibit spying behavior. This is alarming, but not very surprising. Recently, Web-of-Trust extension with 140 million users was taken down for spying~\cite{Lifehacker:pi}. Previous studies have also reported 100 malicious extensions infecting 50 million Chrome users~\cite{jagpal2015trends}.
%\raid{I was surprised to learn that the distribution of number users for spying extensions follows the overall distribution for legitimate extensions.}

%\subsubsectitle{User Base. }In this section, we analyze the reach of spying extensions in terms of number of installs from the Chrome store. Figure~\ref{fig:metainfoanalysis}(a) shows the distribution of number of users (at the time of measurement) of spying extensions and all extensions on the Chrome store. It can be seen that spying extensions exhibit the same popularity distribution as all other extensions. All spying extensions have at least one user, and around 65 (30\%) extensions have more than 1,000 users. 

%, and even YYY\% extensions have more than 100,000 users. 
%In comparison, there are 0.43\% extensions with no users on the Chrome store. 

%Thus, even if the number of spying extensions on the Chrome store are small, it is important to identify and take down spying extensions as they affect a large number of users.

%Prior work found 0.27\% of extensions in the Chrome store to be malicious~\cite{kapravelos2014hulk} and spying extensions were included in the subset of all malicious extensions. 


%Even though we expect the fraction of spying extensions in the Chrome store to be very small\footnote(prior work found 0.27\% of extensions in the Chrome store to be malicious~\cite{kapravelos2014hulk} and spying is a subset of malicious extensions), a significant fraction of spying extensions are widely installed and thus it is important to identify and take down spying extensions from the Chrome store.

\begin{figure}
\centering
\includegraphics[width=0.48\textwidth]{metainfoanalysis}
\caption{(a) Number of current users for all the Chrome store extensions, (b) Crowdsourced average rating of extensions on Chrome Store, (c) Number of votes (count) contributing rating of extensions on Chrome Store}
\label{fig:metainfoanalysis}
\end{figure}
%\vspace{-0.75cm}

%\begin{figure}[h]
%\includegraphics[width=0.45\textwidth]{cdf_usercount}
%\caption{Number of current users for all the Chrome store extensions}
%\label{fig:cdf_usercount}
%\end{figure}

%\subsubsectitle{Crowdsourced Reputation of Spying Extensions.} 
%\label{subsec:char}
%In this section, we first analyze the ratings received by spying extensions. Next, we investigate whether they receive any complaints, bug reports of questions. This would give us a sense for the awareness of Chrome users about the spying behavior of these extensions.

%\subsubsectitle{Ratings. }We analyze the crowdsourced ratings (on a scale from 1 to 5) received by spying extensions. Figure~\ref{fig:metainfoanalysis}(b) shows that spying extensions receive mostly similar ratings as other extensions on the Chrome store. Spying extensions have a median rating of 4.1, while the median rating for all extensions is 4.4. A majority (50.91\%) of spying extensions receive a rating higher than 4.0. Even the distribution of number of ratings received by spying extensions is similar to that received by all extensions on the Chrome store (Figure~\ref{fig:metainfoanalysis}(c)). Thus, it would be hard to distinguish between spying and benign extensions based on crowd-sourced feedback for both Google (browser platform provider) and for users trying to decide whether to install an extension.

%\begin{figure}[h]
%\includegraphics[width=0.45\textwidth]{cdf_ratings}
%\caption{Crowdsourced average rating of extensions on Chrome Store}
%\label{fig:cdf_ratings}
%\end{figure}

%\begin{figure}[h]
%\includegraphics[width=0.45\textwidth]{rating_voting_count}
%\caption{Number of votes (count) contributing rating of extensions on Chrome store}
%\label{fig:rating_count_cdf}
%\end{figure}

\subsubsectitle{\textbf{Bug Reports, Questions and Complaints.}}
Chrome Web Store allows users to submit questions or post suggestions and problems pertaining to extensions. We crawl these text reports associated with each extension and analyze it to identify if users are reporting bugs or complaining about the functionality of the extension. Out of 218 extensions, 103 (47\%) extensions received at least one comment by a user. We scan the text reports using an extensive set of keywords (based on manual investigation) indicating suspicious behavior (e.g., `tracking', `keylogger', `steal', `fake', `don't install', `malware'). Interestingly, only 12 (5.5\%) extensions received some form of comment reporting suspicious behavior. As spying behavior is hidden in background browser activities and traffic, it would be difficult for non-expert users to identify and report such behavior. Our findings suggest that users are mostly unaware of spying behavior. 
%\google{Our findings are inline with a previous survey-based study which shows that users have a general sense of data leakage by web trackers and extensions, but do not fully understand who is tracking them or how this data can be used to make inferences about them. In addition, many participants of the study did not perceive any harm in tracking only while web browsing~\cite{schaub2016watching}.}

%\textcolor{blue}{As spying behavior is difficult to detect, and hence several non-expert users might not have been able to identify and report such behavior.} \raid{Similarly, I was somewhat surprised to see that only 5.5\% of spying extensions receive user complaints. Although, this could simply be because it is very difficult for non-expert users to notice spying behavior that is hidden in background browser activities/traffic.}
%\vspace{-0.25cm}
\subsection{Developers} 
\noindent There are 69 unique developers for our dataset of 218 spying extensions. While a large fraction of developers (89\%), develop only a single extension, we were surprised to find that the remaining 11\% of developers account for a majority (65\%) of extensions. In fact, this small fraction of developers even shows up among the top 100 developers on the Chrome store based on the total number of extensions. This indicates that even popular developers can have a few spying extensions which can go undetected and extensions from popular developers can not be trusted to be safe. We provide more details of a few sample of extensions by popular developers in Appendix~\ref{topdev}. In fact, recently, some extensions by highly rated developers, wips.com and hoverzoom.com were taken down from the Chrome store for spying~\cite{Labs:2015dz}. 

%\acsac{Second, I feel that this analysis is rather disconnected from the rest of the paper and it is not clear how the modus operandi analysis helps the automated classification.}

\subsection{Key Takeaways}
\noindent We highlight the key takeaways from our analysis that would help us build a robust defense (Section~\ref{subsec:rnn}).
%The key insights of our analysis are - 
\begin{itemize}
\item We identify the permissions that are misused to access, store and transmit user information. Later in Section~\ref{sec:detection}, we use these findings to identify a dataset of benign extensions (non-spying) and develop a machine learning based model to detect spying behavior.
\item Extensions can switch between spying and non-spying states based on remote and time based triggers. We devise our detection scheme to capture such dynamic spying behavior.
%\textcolor{blue}{Understanding the permission model which enables the extension to carry out actions (access, store, transmit, remote control) required for spying on user information help us to later identify a dataset of benign extensions and develop an automated model to detect spying behavior in Section~\ref{sec:detection}.}
%Browsing history, IP address, geolocation and social media access tokens are the most common types of user information tracked by spying extensions and sent over to remote servers.
%\item Some of the most misused permissions are \emph{tabs}, \emph{cookies} and \emph{webRequest}, which are used to access, store and transmit user information. %The spying behavior of extensions is enabled by privilege to certain permissions which are required by the extensions to perform actions to be able to access, store and transmit user information. Some of the most misused permissions are \emph{tabs}, \emph{cookies} and \emph{webRequest}.
\item Popularity and other crowd-sourced reputation metrics serve as unreliable signals (prone to manipulation) for differentiating spying extensions from others. Thus, we do not use these metrics to build a detection scheme.
%\item It would be hard to identify spying extensions based on analysis of metadata. It is hard to identify spying extensions based on the reputation of remote domains contacted by the extensions. Reputation metrics based on crowdsourced feedback (e.g., ratings, comments, bug reports) are also poor indicators of suspicious behavior, as users are potentially unaware of the spying activities. Lastly, reputation metrics based on developers are also low quality signals for detection. 
%The crowdsourced ratings, reviews and user base (from Chrome Web Store) of spying extensions are similar to that of benign extensions. Hence, crowdsourced feedback is a poor indicator of spying extensions.
%\item Our dataset of 218 spying extensions have over 2.4 million cumulative installs. Thus, even if the total number of spying extensions on the Chrome store are small, it is important to identify and take down spying extensions, as they affect a large number of users.
\end{itemize}


%In fact, 2 extensions by highly rated developers, wips.com and hoverzoom.com
%Some of the previously reported extensions have also been from highly rated developers like wips.com and hoverzoom.
%\textcolor{blue}{Some of the previously reported extensions have also been from highly rated developers like wips.com and hoverzoom}.  \raid{It is also concerning that the developers that account for a majority of spying extensions also appear in the top 100 developers for all Chrome store extensions.}

%While a large fraction of developers, 89\% develop only a single extension, there is a small number of 12 developers that own more than 65\% of all extensions. It is not surprising that 89\% of developers own a single extension each, because Google might target and investigate other extensions by the same developer if one malicious extension is caught. However, we were very surprised by the 20 developers with a large number of spying extensions. When we further analyze these developers, we find that 22 of them fall among the top 100 developers in the Chrome store based on total number of extensions. This indicates that even popular developers can have a few spying extensions which can go undetected and extensions from popular developers can not be trusted to be safe.

%A large fraction of developers, 89\% develop only a single spying extension. This trend is not surprising, as Google might target and investigate other extensions by the same developer if one malicious extension is caught. However, we observe that a small fraction, 5 spying extension developers also show up among the top 500 out of the total 33,477 developers in the entire Chrome store (based on number of cumulative installs). We also look at the developers who publish maximum number of extensions on the Chrome Web Store. We also observe that 2 of the top 10 developers (by volume of extensions) have published spying extensions. This indicates that even popular developers can have a few spying extensions which can go undetected and extensions from popular developers can not be trusted to be safe.

%\subsection{Summary / Key Takeaways}
%\noindent The key insights of our analysis are - 
%\begin{itemize}
%\item Browsing history, IP address, geolocation and social media access tokens are the most common types of user information tracked by spying extensions and sent over to remote servers.
%\item Some of the most misused permissions are \emph{tabs}, \emph{cookies} and \emph{webRequest}, which are used to access, store and transmit user information. %The spying behavior of extensions is enabled by privilege to certain permissions which are required by the extensions to perform actions to be able to access, store and transmit user information. Some of the most misused permissions are \emph{tabs}, \emph{cookies} and \emph{webRequest}.
%\item It would be hard to identify spying extensions based on analysis of metadata. It is hard to identify spying extensions based on the reputation of remote domains contacted by the extensions. Reputation metrics based on crowdsourced feedback (e.g., ratings, comments, bug reports) are also poor indicators of suspicious behavior, as users are potentially unaware of the spying activities. Lastly, reputation metrics based on developers are also low quality signals for detection. 
%%The crowdsourced ratings, reviews and user base (from Chrome Web Store) of spying extensions are similar to that of benign extensions. Hence, crowdsourced feedback is a poor indicator of spying extensions.
%\item Our dataset of 218 spying extensions have over 2.4 million cumulative installs. Thus, even if the total number of spying extensions on the Chrome store are small, it is important to identify and take down spying extensions, as they affect a large number of users.
%
%\end{itemize}

%\begin{figure}
%\includegraphics[width=0.5\textwidth]{topN_pupular_devs}
%\caption{Top 10 developers (by volume of extensions) on Chrome store}
%\label{fig:topN_pupular_devs}
%\end{figure}


apicalldetection.tex
\section{Sequence Learning based Detection of Spying Extensions} \label{sec:apicalldetection}

We further assess the importance of API calls made by extensions to help detect spying extensions. 

\subsection{Analysis of API Call Sequences}
We observe that most important features to detect spying extesions is the API call sequences made by the extension to the Chrome API. Our emperical analysis shows that it is not just the specific API calls, but the sequence of API calls which can help us to distinguish spying behavior from benign behavior. In this section, we analyse the API call sequences made by spying extensions and draw attention to patterns that can be distinguishing for detecting spying extensions. \anu{To add results after discussion}

\begin{figure}[h]
\includegraphics[width=0.45\textwidth]{sequence_length_eval}
\caption{Precision at different API sequene length}
\label{fig:sequence_length_eval}
\end{figure}

appendix.tex
\appendix \label{sec:appendix}

\subsubsectitle{(1) Spying Extension Data Expansion Techniques} \label{datacol}
After obtaining an initial set of 100 verified spying extensions, we apply the following data exansion techniques over these verified extensions to obtain a larger candidate set using the following --
\begin{itemize}
\item \textbf{Filename Matching:} We extract the file names of the JavaScript files which are responsible for spying behavior found in the previously found seed spying extensions. We search for extensions with same file names in entire Chrome Web Store and find 384 more extensions out of which we verified 49 to be spying.

\item \textbf{Developer Based Signature:} We look for other extensions written by developers of the spying extensions in our seed dataset. We extract the developer name for all the spying extensions and inspect all extensions by the developers on Chrome We Store. Out of 159 such extensions, we verified 8 to be spying.

\item \textbf{URL Based Signatures:} By our definition of spying extensions, every spying extension send user information to an untrusted remote URL. From our seed dataset of spying extensions we create a list of remote URLs used to send over user information. We then extract all the URLs in source code of each extension on chrome webstore and search for extensions that match the URL of a known spying server. Out of 145 matches, we found 46 to be spying. For the remaining set, we suspect that these extensions were no longer tracking (or we could not trigger the spying mode). Also, some of the extensions were not functioning properly. 

\item \textbf{JavaScript Based Signatures:} From our seed dataset of spying extensions, we find the JavaScript code snippets which was used for unsolicited data access or stealthy transfer of data. We search for the same code snippets in the source code of all the extensions of the chrome store and found 155 closely matching extensions. Out of these we verified 15 extensions to be actually spying. 
\end{itemize}
%\vspace{-0.3cm}
%\begin{table}[h]
%%\captionsetup{font=small}
%\centering
%\scriptsize
%\begin{tabular}{ll|ll}
%\toprule
%\multicolumn{2}{c|}{Initially Found (Baseline Methods)} & \multicolumn{2}{c}{After Expansion} \\ \midrule
%Technique                             & \#ext          & Technique                & \#ext    \\ \midrule
%manual inspection                     & 5              & filename matching        & 49       \\
%by monetization services              & 84             & more ext by developer    & 8        \\
%reported extensions        			  & 8              & remote URL match         & 46       \\
%filename based signatures             & 3              & JS based signatures      & 15       \\ \midrule
%Total                                 & 100            &                          & 118     \\ \midrule
%\multicolumn{2}{l}{Total Tracking (\texttt{CWS\_Spy})} &  						  & 218     \\ \bottomrule
%\end{tabular}
%\caption{ by first inspecting an initial dataset of extensions and then expanding the dataset using the expansion techniques. We mark an extension as a spying extension only after verifying that it accesses and sends user data to a remote URL.}
%\label{tab:expansion}
%\end{table}

%\begin{table*}[h]
%%\captionsetup{font=small}
%\centering
%%\scriptsize
%\begin{tabular}{@{}lll|lll@{}}
%\toprule
%Baseline Techniques       & \multicolumn{2}{c|}{\#ext}            & Data Expansion        & \multicolumn{2}{c}{\#ext} \\ \midrule
%                          & candidate & verified                 &                       & candidate    & verified   \\  \midrule
%permission based filter   & 150       & 5   & filename matching     & 384         & 49         \\
%by monetization services  & 115       & 84  & more ext by developer & 159         & 8          \\
%reported extensions       & 30        & 8   & remote URL match      & 145         & 46         \\
%filename based signatures & 79        & 3   & JS based signatures   & 155         & 15         \\ \midrule 
%Total                     & 374       & 100 &                       & 843          & 118        \\ \midrule
%Total Candidate           &           &                          &                       &              & 1217       \\
%Total Spying (CWS\_Spy)   &           &                          &                       &              & 218        \\ \bottomrule
%\end{tabular}
%\caption{We identify spying extensions by first inspecting an initial dataset of extensions and then expanding the dataset using the expansion techniques. We mark an extension as a spying extension only after verifying that it accesses and sends user data to a remote URL.}
%\label{tab:expansion}
%\end{table*}


%backup
\begin{table}[h!]
%\small
\centering
\begin{tabular}{@{}lll@{}}
\toprule
\multicolumn{1}{c}{\multirow{2}{*}{Baseline}}       & \multicolumn{2}{c}{\#extensions} \\ \cmidrule(l){2-3} 
\multicolumn{1}{c}{}                                & Candidate       & Verified       \\ \midrule
permission based filter                             & 150             & 5              \\
by monetization services                            & 115             & 84             \\
reported extensions                                 & 30              & 8              \\
lename based signatures                             & 79              & 3              \\ \midrule
Total (Baseline)                                    & 374             & 100            \\ \midrule
\multicolumn{1}{c}{\multirow{2}{*}{Data Expansion}} & \multicolumn{2}{c}{\#extensions} \\ \cmidrule(l){2-3} 
\multicolumn{1}{c}{}                                & Candidate       & Verified       \\ \midrule
filename matching                                   & 384             & 49             \\
more ext by developer                               & 159             & 8              \\
remote URL match                                    & 145             & 46             \\
JS based signatures                                 & 155             & 15             \\ \midrule
Total (Data Expansion)                              & 843             & 118            \\ \midrule
Total Spying                                        & 1,217           & 218            \\ \bottomrule
\end{tabular}
\caption{We identify spying extensions by first inspecting an initial dataset of extensions and then expanding the dataset using the expansion techniques.}
\label{tab:expansion}
\end{table}

%\vspace{-0.25cm}
\subsubsectitle{(2) Verification of Spying Extension} \label{verification}
Since it is not possible to manually investigate each of the 43k extensions on the Chrome Web Store, we use a combination of semi-automated heuristics and human verification to flag spying extensions. As the first step, we use a record-replay setup and automatically generate -- (1) network request log, (2) changes in client-side storage and (3) browser API calls made by the extension under review.

\balance
\subsubsectitle{\textbf{Capturing Network Request Log using Record-Reply.}}
\begin{itemize}
\item \textbf{Record Run:} In this phase, we prepare a behavioral suit for Top 10 Alexa websites. We use a clean session devoid of any previous cookies, storage, cache or browsing history in this phase. 

\item \textbf{Replay Run:} In the replay run we first load the extension in a new browser session and capture all the HTTP requests. The requests which generate 404 error help us to identify potentially untrusted remote URLs the extension is trying to contact. Next, we execute all the HTTP requests from the first step. This enables us to capture the real behavior of extension in the presence of Internet. We log the resulting redirects and HTTP requests. 
\end{itemize}

\subsubsectitle{\textbf{Capturing Storage and Cookie States.}}
Before we load the extension in the previous step, we capture the local storage and cookie storage of the running browser extension and compare it with the state after extension has been loaded and run. This enables us to capture the storage and cookie changes caused by the extension under inspection. 

\subsubsectitle{\textbf{Capturing Browser API Access.}} 
To capture the browser API access by the extension, we use a tweaked version of Chrome Apps and Extension Developer Tool which helps us to record details of all the API calls made by the extension along with the timestamps. 

\subsubsectitle{\textbf{Data Access, Storage, Sending Cues.}} 
\begin{itemize}
\item \textbf{Data Access:} From the previous sections, we know the permissions and API calls which are needed to access user information (See Section~\ref{sec:analysis}). We look for those API calls from the log we generated to capture the API calls made by the extension. If any of those API calls are made then we mark the extension as trying to access user information.  

\item \textbf{Data Storage:} A spying extension may or may not store user data. We look for storage/cookie state before and after the extension is loaded and run to see if any data was stored by the extension on the client side.

\item \textbf{Data Transfer:} An extension has spying behavior if it access user information  and stealthily sends that information to untrusted remote server. In an extension accesses user information, we aim to check whether the `same' information is being sent to remote untrusted servers or not to flag it as spying or benign. As first step, we check if any information is being sent to remote URLs by extracting the URLs and IP addresses from our network capture in the replay-run and live-run. Once we have these requests and the associated remote URLs, we try to decode the information that was sent to these remote URLs. We look at the GET parameters and the POST request payload to assess if the same information that was accessed by the extension was indeed sent to the remote URL. Sometimes, this information can be in plain text. If not, then we try to decode this information by using some decoding functions like base64, double base64 and hex. If after decoding, the information being sent matches with the information being accessed, we mark the extension as `spying' if the data access and transfer was happening beyond the functionality of the extension as described on the Chrome Web Store.
\end{itemize}  


\subsubsectitle{(3) Popular Developers and their Spying Extensions} \label{topdev}
In this section we present details of spying extensions by top developers (by number of users). Spying extensions by top eight developers have more than 1.5 million users. More details about these extensions, and the information stolen is given in Table~\ref{tab:topdevext}.
%\begin{figure}
%\includegraphics[width=0.4\textwidth]{topN_pupular_devs}
%\caption{Top 10 developers (by volume of extensions) on Chrome store}
%\label{fig:topN_pupular_devs}
%\end{figure}

\begin{table*}[h!]
\centering
\small
\begin{tabular}{@{}llp{2cm}lp{4cm}l@{}}
\toprule
\multirow{2}{*}{Developer} & \multirow{2}{*}{\#SpyExt} & \multicolumn{4}{c}{Top Spying Extension}                                                                                                                                                                             \\ \cmidrule(l){3-6} 
                           &                           & Name                         & \#Users   & Description                                                                                                                                          & Information Stolen \\ \midrule
wips                       & 135                       & Block Site                   & 1,072,111 & ``automatically blocks websites of your choice"                                                                                                      & Browsing History   \\
%similarweb                 & 1                         & SimilarWeb                   & 178,777   & ``see real in-depth website engagement, traffic sources, and site ranking information"                                                               & Browsing History   \\
muz.li                     & 1                         & Muzli 2                      & 107,655   & ``the freshest links about design and interactive, from around the web"                                                                              & Browsing History   \\
topapps                    & 5                         & HolaSoyGerman                & 106,022   & ``... know when a new German video rises, either from HolSoyGerman or JuegaGerman [YouTube channels]..." & Browsing History   \\
padlet.com                 & 1                         & Padlet Mini                  & 84,309    & ``collect and bookmark the best of web..."                                                                                                           & Browsing History   \\
wisestamp.com              & 1                         & Add Email Signature          & 68,651    & ``get a professional email signature.."                                                                                                              & Browsing History   \\
%similarsites               & 1                         & Similar Sites                & 39,790    & ``instant access to the best sites related to the one you are browsing"                                                                              & Browsing History   \\
swytshop                   & 1                         & SwytShop                     & 35,015    & ``automatically,nds lower prices while you shop"                                                                                                     & Browsing History   \\
awesomescreenshot          & 1                         & Smart Shopper                & 32,625    & ``a universal shopping cart to allow cross-site shopping..."                                                                                         & IP Address         \\
rotogrinders               & 1                         & RotoGrinders - FanDuel Tools & 7,818          & Shortcut to manage rotogrinders.com games                                                                                                                                                     &  Browsing History                  \\ \bottomrule 
\end{tabular}
\caption{Top Developers (by number of users) and the top spying extension by each developer}
\label{tab:topdevext}
\end{table*}

%\vspace{-0.25cm}

\subsubsectitle{(4) Generating workload for input to RNN} \label{subsubsec:workload}
For each extension, we pick a set of 4 websites (from Top 10 Alexa websites) and perform all browser actions in a controlled environment with that extension running in the background. In addition, we login to all the social media and email accounts using dummy accounts to increase chances of triggering any malicious activity by an extension. As a result of the dynamic run of the extension, we capture the network log and the API call log generated. We then extract the sequence of API calls from the API call log of each extension. To boost the data for training our classifiers, we repeat this experiment thrice for each extension with a different set of 4 websites each time, hence generating 3 set of sequences for each extension. As a result, we obtain 621 sequences (for 207 extensions) labeled as spying; and 9,315 sequences (for 3,105 extensions) labeled as benign. 

\subsubsectitle{(5) In-the-Wild Study - Newly Found Spying Extensions} \label{falsepos}
Our trained model when applied to the entire Chrome Web Store finds more spying extensions. Here we give details of some of these newly found spying extensions in Table~\ref{tab:falsepos}. 

\begin{table*}[h!]
\centering
\small
\begin{tabular}{@{}p{3cm}llp{4cm}l@{}}
\toprule
Extension                                 & Developer                  & \#Users & Claimed Functionality                                                                                                               & Information Stolen        \\ \midrule
Awesome Screenshot: Screen Video Recorder & awesomescreenshot          & 1,299,595    & ``screencast, record screen as video. Screen capture for full page,,annoate, blur sensitive info, and share with one-click uploads" & Browsing History          \\
Hover Zoom                                & hoverzoom                  & 894,888    & ``enlarge thumbnails on mouse over. Works on many sites (Facebook, Twitter, Flickr, Reddit, Amazon, Tumblr, etc)"                   & Browsing History          \\
SpeakIt                                & skechboy.com                  & 545,715    & ``Select text you want to read and listen to it. SpeakIt converts text into speech so you no longer need to read."                   & Browsing History          \\
MozBar                                    & Moz                     & 375,529    & ``the all-in-one SEO toolbar for research on the go."                                                                               & Browsing History          \\ 
User-Agent Switcher                       & useragentswitcher          & 299,771    & ``...adds a button to switch between user-agents..."                                                                                & Browsing History          \\
Facebook Video Downloader                   & freevideodownloader.online & 272,275    & ``download any video from Facebook"                                                                                                 & Browsing History \\
Ratings Preview for YouTube               & ratingspreview             & 116,745    & ``show the likes and dislikes bar over every video thumbnail in YouTube"                                                            & Browsing History          \\
SafeBrowse                                & safebrowse.co              & 115,265    & ``navigate without waiting in Adfly, Linkbucks and other similar sites. No more waiting, no more annoying advertising"              & Browsing History          \\
SuperBlock Adblocker                      & Superblock                 & 13,887    & Ad blocker                                                                                                                          & Browsing History          \\
Power Zoom                                & powerzoom                  & --    & ``to view larger images on any website automatically, all over the Web"                                                             & Browsing History          \\
\bottomrule
\end{tabular}
\caption{A sample of newly found spying extensions}
\label{tab:falsepos}
\end{table*}


background.tex
%!TEX root = main.tex
%\vspace{-0.25cm}
\section{Background} 
\label{sec:background}
%\vspace{-0.25cm}
\noindent We provide a brief overview of the building blocks of a Google Chrome extension and how developers can publish extensions for end-users. Although we focus on Chrome extensions, most of the concepts apply to other browsers as well, for example, Firefox with WebExtensions. %\footnote{\url{https://developer.mozilla.org/en-US/Add-ons/WebExtensions}}. 
%We provide a brief background about the architecture of extensions which can be leveraged by spying extensions and how developers can publish extensions for end-users.

\subsubsectitle{\textbf{Extension Architecture. }} Browser extensions are software programs running on web browsers, providing extended browsing functionality to users. An extension consists of Javascript, HTML, CSS, and other web resources that are needed for rendering web pages. 
The main logic of an extension is usually placed in a \emph{background page} where programs keep running during the entire browser session. Many extensions also use \emph{content scripts} that are programs injected into a web page to gain access to the page resources. 
%Chrome extensions have two execution models: \emph{background} page, where the extensions keep running during the entire browser session, and \emph{content scripts}, where the extensions was injected onto the web pages, gaining access to the page resources.

Similar to web pages, extensions have access to all Web APIs, such as standard Javascript API, XMLHttpRequest, and DOM. More importantly, 
% Additionally, Chrome extensions are tightly integrated into the browser with access to a set of privileged browser API, called the \emph{Chrome API}. 
Chrome extensions are exposed to a set of privileged browser APIs, called the \emph{Chrome API}. Based on the functionality, Chrome API are bundled as various feature endpoints, such as web requests (e.g., listening or tampering network requests), bookmarks, history, cookies, storage, and tabs.
% Chrome API are bundled into endpoints can be used to listen to browser events, have access to client-side details (\eg cookies, storage, and history), intercept and modify network requests, access information from browser tabs, manage installed extensions, and much more. 
In order to gain access to the Chrome API, extension developers have to specifically request permissions in the \emph{Manifest file}. At the time of installing an extension, users have to decide to accept these permission requests or not. 
% However, extension developers have to specifically ask for permissions to access Chrome APIs by listing them in the \emph{Manifest} file of an extension. 
For example, the \emph{cookie} permission in the Manifest file enables extensions to make API calls to read cookies (\emph{cookie.get}) and change cookies (\emph{cookie.set}). With the necessary permissions, extensions can monitor all user activities in browser.% and can access sensitive user data. 
%\raid{How would this approach be generalized to extensions on other non-Chrome browsers? Do other popular browsers like Firefox or IE have an equivalent of the Chrome API calls that can be used for detection?} 
%\textcolor{blue}{
It should be noted that other browsers, Safari and Firefox also provide a similar privileged Browser API to extensions~\cite{Apple:2017ht}\cite{Mozilla:2017yt}.

%browsers other than Chrome also have a similar set of Web APIs. For instance, Firefox WebExtensions have access to similar JavaScript APIs~\footnote{\url{https://developer.mozilla.org/en-US/Add-ons/WebExtensions/Browser_support_for_JavaScript_APIs}}, and Safari extensions has access to \emph{Safari Extensions JS Framework}~\footnote{\url{https://developer.apple.com/reference/safariextensions}} which has similar API endpoints to access user information like history, cookies, etc., as well as make network requests.}

%~\anu{This could also be moved to a new section where we will evaluate our model, under the title ``Generalizability"} 



%The extensions operate by making calls to the browser via a bundle of special-purpose Browser APIs.~\footnote{Browser APIs are also called JavaScript APIs in context of Chrome} To make the API calls, Chrome extensions need  -- a requisite HTML page (background page) and an optional Javascript file (content script). The \emph{background page} and \emph{content script} together have access to powerful API endpoints to perform browser-wide events. For instance, these APIs can be used to listen to browser events, have access to client-side details (like cookies, storage and history), send network requests, change DOM elements, capture the screen content, and much more. The API endpoints which enable these actions are the backbone of how extensions operate. 
%However, the developers need to specifically ask for permissions to access browser APIs by listing them in the \emph{Manifest} file of extension in JSON format. For example, \emph{cookie} permission in Manifest file enables extension to make API calls to access cookies (\emph{cookie.get}), and modify or add cookies (\emph{cookie.set}). With the necessary permissions, spying extensions can monitor all user activities in the browser and can access sensitive user data.  

\subsubsectitle{\textbf{Chrome Web Store. }} The Chrome Web Store serves as a repository for all extensions and provides a low entry barrier for developers to publish extensions. However, due to the rampant increase of malicious extensions, Chrome now asks for a one-time signup fee to publish extensions~\cite{Chrome:fk} and does not allow users to install extensions sourced outside the Chrome Web Store ecosystem~\cite{Chrome:2015rz}, unless a deliberate developer mode is switched on by the user. Additionally, Google is known for constant development of mechanisms for identifying malicious browser extensions within a short window of time~\cite{jagpal2015trends}.
%Further, Chrome has an in-built framework to detect malicious extensions within a short window of extension installation~\cite{jagpal2015trends}. 
Despite these countermeasures, our findings show persistent presence of spying extensions on the Chrome Web Store.


%\subsubsectitle{Extension Archirecture.} Browser extensions are software programs that can extend the functionality of web browsers. A chrome extension has two main components: a manifest file and web objects (e.g., HTML, CSS, and JavaScript files). A manifest file is used to declare required permissions (e.g., access permission for storage, user cookies). Most manifest files specify a background page---an HTML page or a JavaScript file---as the main entry point of the extension. In Chrome, an extension has two execution models: a long-running model called background pages and a short page-based model called content scripts. The background page is an isolated sandbox environment to perform tasks lasting across the entire browser life cycle. Contrary to the long-lasting background pages, content scripts run in context of only the visiting web pages. However, both the background page and the content script have access to various powerful Chrome APIs.  

%and security contexts (e.g., Content Security Policy, extension's external connectivities). 
%For example, extension developers use background pages to monitor browser-wide events, such as tabbing and networking

%These Chrome APIs provide various functionality to the extensions. For instance, these APIs can be used to listen to browser events, have access to client-side details (like cookies, storage and history), send network requests, change DOM elements, capture the screen content, and much more. With the necessary permissions and security context, spying extensions can monitor all user activities in the browser and can access sensitive user data. For example, extensions can use the cookie API to access user's signed-in tokens, or use specific WebRequest permissions to intercept, block, or modify web requests. 

%All dependent web objects, including ones required by the background page, are packed as resources in the extension.

%In this section, we briefly overview the building blocks of Chrome extension architecture. Although we focus on Chrome extension, most of the concepts apply to other browsers as well, for example, Firefox with WebExtensions \footnote{\url{https://developer.mozilla.org/en-US/Add-ons/WebExtensions}}.

%\paragraph{Permissions: } Extensions can get access to specific features and resources like storage, cookies and user history via browser APIs. These permissions are listed in a static file in extension's source code, called manifest file. The permissions asked for by an extension govern its capability. The developer of an extension needs to list all the required permissions in the manifest file. Spying extensions may be overprivileged and list more permissons than needed to be able to access sensitive user information.


%Background pages are also used for keeping states and sharing information for content scripts. 



%Content scripts uses only the standard web APIs, for example, HTML5, DOM, and JavaScript. Meanwhile, a background page has full access to Chrome's extension APIs, such as browser actions, tab events, and proxy settings, but can only access the web APIs for its own page (a hidden web page for holding dependent web objects). Despite the API differences, content scripts and the background page can communicate and exchange information via postMessage---the standard HTML5 message channel, thus having direct or indirect access to all Chrome API endpoints. These Chrome API events provide various functionalities to the extension and enable privileged access to client-side user information and event listeners. 

%Each page has its own content scripts instance, while a background page is a singleton shared among all web pages. Following declarations in the manifest file, Chrome injects content scripts into the targeted web pages to which the user navigate, as if they were loaded by the web site. 
%To prevent unsafe cross-site scripting, the extension is set to the security context defined in the manifest file.

%Besides the two models having different life cycles, they have access to two sets of browser services with some overlap. Content scripts only uses the standard web APIs, for example, HTML5, DOM, and JavaScript, with the exception of a few Chrome extension APIs. Meanwhile, a background page has full access to Chrome's extension APIs, such as browser actions, tab events, and proxy settings, but can only access the web APIs for its own page (a hidden web page for holding dependent web objects). Despite the API differences, content scripts and the background page can communicate via postMessage---the standard HTML5 message channel. Using this messaging mechanism, developers are able to coordinate content scripts and background pages for some tasks. For example, a spying extension can use content scripts to steal user information, then save the data to persistent storage in background pages.


%In this study, we have found Chrome extensions that steal private user information and send the data to remote servers. 


%\paragraph{Event Page and Content Script: } In Chrome, a extension has two execution models: a long-running model called event pages, and a short page-based model called content scripts. The extension can have scripts running in both models at the same time. Event page is an isolated sandbox environment for the extension to perform tasks lasting across the whole browser life cycle. For example, extension developers use event pages to monitor browser-wide events, such as tabbing and networking. Contrary to the long-lasting event pages, content scripts run in the context of the visiting web pages (i.e., they has the same life cycle as the web pages). Each page has its own content scripts instance, while a event page is a singleton shared among all web pages. Following declarations in the manifest file, Chrome injects content scripts into the targeted web pages to which the user navigate, as if they were loaded by the web site. Content scripts only uses the standard web APIs, for example, HTML5, DOM, and JavaScript, with the exception of a few Chrome extension APIs. Meanwhile, a event page has full access to Chrome's extension APIs, such as browser actions, tab events, and proxy settings, but can only access to the web APIs for its own page (a hidden web page for holding dependent web objects). Despite the API differences, content scripts and the event page can communicate via postMessage---the standard HTML5 message channel. Using this messaging mechanism, developers are able to coordinate content scripts and event pages for some tasks. For example, spying extensions can use content scripts to steal user information, then save the data to persistent storage in event pages.

%With the necessary permissions and security context, spying extensions can monitor all user activities in the browser and can access sensitive user data. For example, extensions can use the cookie API to access user's signed-in tokens, or use webRequests to intercept, block, or modify requests. In this study, we have found Chrome extensions that steal private user information and send the data to remote servers. 

%To prevent unsafe cross-site scripting, the extension is set to the security context defined in the manifest file.




%The Chrome Web Store serves as a repository for all extensions, apps and games and provide a low entry barrier for developers to publish extensions. However, due to rampant increase of fraud and malicious extensions, Chrome now asks for a one-time signup fee to publish extensions~\cite{Chrome:fk} and does not allow Chrome users to install extension in the browser from outside the Chrome Web Store ecosystem~\cite{Chrome:2015rz}. Further, Chrome has an in-built framework to detect malicious extensions within a short window of extension installation~\cite{jagpal2015trends}. Despite such measures, our findings show persistent presence of spying extensions which stealthily access and transmit sensitive user information.








conclusion.tex
%!TEX root = main.tex
\section{Conclusion}
% In this study, we identified a significant sample of spying extensions impacting millions of users. As a first step, we uncovered the modus operandi of spying extensions and explored how extensions interacted with Chrome API for spying activities. We identified an exhaustive set of features for spying extensions detection. Compared to previous literature on detection of malicious activities, we built new features like n-grams of API calls, which captured the sequential operational patterns of spying extensions. Additionally, we proposed a detection model based on LSTM RNN which did not depend on extensive feature engineering. We also showed that this model achieved high performance with relative small training dataset and can be deployed at the client side for an early detection of spying extensions.

%In this work, we presented a large-scale study of 218 spying extensions on the Chrome store. \acsac{A study of 218 extensions is not "large-scale".} 
This work presented a detailed study of browser extensions that steal sensitive user information. We started by building a dataset of 218 spying extensions on the Chrome store using expert manual investigation. Such a dataset allowed us to conduct an in-depth analysis of the modus operandi of these spying extensions.  
%presenting an in-depth analysis of these spying extensions. 
Being a privileged software residing in the user's browser, spying extensions can track the complete online activity of a user. Spying extensions steal a variety of sensitive personal information, including the browsing history of the user. Surprisingly, these extensions are as popular as other extensions on the Chrome store. 
%As of March 2017, that is, 8 months after our detection and analysis, only 3 out of 218 extensions were removed from the Chrome store. 
Our analysis thus helps to highlight the privacy risks facing users of browser extensions. 

Next, we investigated techniques to automatically detect spying extensions using machine learning schemes. We found that an extensive set of hand-crafted features used in prior work for detecting malicious extensions are ineffective in our case. Instead, we showed that browser API call sequences serve as a robust feature to detect spying extensions. Using Recurrent Neural Networks that are best suited for learning patterns in sequential data, we showed that spying extensions can be detected with high precision and recall. Our RNN-based classifier identified 65, as yet unknown, spying extensions (which were not used for training the classifier) on the Chrome store. Lastly, we also discussed the potential for deploying our scheme directly on a user's browser for early detection of spying behavior.

%This is surprising considering the fact that browser platforms are known to catch malicious extensions~\cite{}. Our work highlights the importance of detecting and limiting user tracking within the browser. 


%In this study, we identify a significant sample of spying extensions impacting millions of users. As first step, we uncover the modus operandi of spying extensions and explore how extensions interact with Chrome API framework to get privileges enabling the spying behavior. We identify an exhaustive set of features to detect spying extensions using previsious literature on detection of malicious detection. and adding features like n-grams of API calls based to capture the sequential operational patterns of spying extensions. Our major contribution is that we propose a detection model based on LSTM RNN which does not need such extensive feature engineering. We also show that this model has a high performance and can also be deployed at client-side for an early detection of spying extensions.

%In this work, we conduct the first large-scale study of spying browser extensions. We identify and analyze extensions stealing a variety of sensitive personal information, including the browsing history of the user. In fact, being a privileged software residing in the user's browser, spying extensions can track the complete online activity of a user. Unfortunately, these spying extensions are able to attract a huge user base. Our dataset of 218 spying extensions had over 2.4M cumulative installs. Moreover, at the time of this writing, only 4 out of 218 extensions have been removed from the Chrome store. While prior work on user tracking has largely focused on third-party tracking on the web, our work highlights the importance of detecting and limiting user tracking within the browser. We had an interaction with the Google Chrome Security Team regarding this research work.

%Our analysis of spying extensions show that they work in a stealthy manner leaving most of the users unaware about its presence. 
%Even a sample of 218 spying extensions have over 2.4 Million cumulative installs in the Chrome store.  


%Only 4 extensions were removed by Google since our analysis.

%Fill me..


dataset.tex
%!TEX root = main.tex
\section{Data Collection} \label{sec:dataset}
%\vspace{-0.25cm}

\subsection{Ground Truth Data of Spying Extensions}
To conduct our study, we first need a large sample of spying extensions. In this section, we describe our methodology for obtaining a ground-truth dataset of spying extensions. In the rest of the paper, we use this dataset to uncover the operational aspects of spying extensions and to propose a machine learning-based technique to automatically detect spying extensions. 


%The goal of this study is to uncover the modus operandi of spying extensions, and build an effective prediction model to automatically detect spying behaviour. Therefore, we first need a substantially large set of spying extensions to conduct our study. In this work, we use two types of datasets: (1) A near-complete dataset of all extensions available on the Chrome Web Store as of September 2016 (\texttt{CWS\_All}), (2) A sample of spying Chrome extensions (\texttt{CWS\_Spy}). 
%\vspace{-0.25cm}
\subsubsectitle{\textbf{Spying Extensions:} } We define a \textit{spying} extension as one which accesses and intentionally sends user information to a third-party domain, when the claimed functionality of the extension (on the Chrome store) does not mention the requirement of such user information. Intentional leakage includes communication events based on Web API calls (\eg POST requests via XMLHttpRequest) or those based on Chrome API endpoints. Leakage based on HTTP referrer header is considered unintentional and is not considered as spying behavior. %as in previous study by Starov et al~\cite{starovextended}}. 
%\anu{changed footnote to text for more focus}\anu{to add here that WWW 2017 paper with 618 extensions considers unintentional leakage by referrer header which is not spying according to our definition due to unintentional leakage}

Table~\ref{tab:spyingextdef} gives examples of 5 spying extensions with an apparent disconnect between the claimed functionality of each extension and the user information they collect. For example, an extension called ``Pacman"\footnote{\url{chrome.google.com/webstore/detail/pacman/ffhefikmbepljajkbhedocnmgagdpajo}} provides a launch icon for a game. However, this extension spies on the browsing history of the user and does not provide any description about requiring browsing history for its functionality. We observe that all spying extensions in our dataset have a similar trait, thus suggesting leakage of user information with potential malicious intent.



%\raid{Is it possible that the definition given in the paper is too broad? After all, the extension developers have to ask for permissions, to access potentially sensitive content. Now, is it reasonable to assume that a legitimate developer may consider permission granting as part of letting the user know about access to sensitive information? In other words, is it possible that such behavior is not explicitly reported in details in the textual description of the extension? If that was the case, then some (or maybe several) of the extensions that are labeled as spying could be recategorized as legitimate. Could this explain the fact that developers who apparently have a good reputation end up in the spying extensions dataset?} \textcolor{blue}{We have a conservative definition of \textit{spying}, and we mark an extension as spying only when there is a huge disconnect of the description and functionality of the extension from the required permissions and accessed information. 

%Table~\ref{tab:spyingextdef} gives examples of the such discrepancy in our dataset of spying extensions}



 
%such that the actual functionality of the extension is different from its claimed functionality as per description on the Chrome Web Store. \bimal{definition to be updated.}
%\paragraph{Spying Extensions: } We first define a \textit{spying} extension as one which accesses, stores (optionally) and additionally, sends user information to a remote URL, such that the actual functionality of the extension is different from its claimed functionality as per description on the Chrome Web Store. \bimal{definition to be updated.}

\begin{table*}[]
\centering
\small
\begin{tabular}{@{}p{2.25cm}llp{7cm}p{3cm}@{}}
\toprule
Extension                          & Developer         & \# Users                   & Claimed Functionality                                                                                                   & Information Stolen                                                                                                               \\ \midrule
Block Site & wips & 1,072,111    & ``automatically blocks websites of your choice" & Browsing History \\
HolaSoyGerman              		   & topapps           & 75,962    & ``... know when a new German video rises, either from HolSoyGerman or JuegaGerman [YouTube channels]..."                    & Browsing History                                                                                    \\
SwytShop                           & swtyshop          & 35,015                      & ``automatically finds lower prices while you shop"                                                                         & Browsing History (now taken down from Chrome Store) \\
Pacman                             & wips              & 22,670 & ``one click on the icon and play it {[}Pacman{]} right in your browser"                               & Browsing History                                                                        \\
%Ultraximity Music - YouTube Videos & electrotrackmusic & 27    & Get notified immediately when Ultraximity (Electronic Music) uploads a new video to the channel... & tracks browsing history of user                                                                                                  \\
Koukis Youtube                     & oeurstudio.com    & 2,662  & shortcut to go to Kouki's (a Taiwanese Youtuber) YouTube channel                                  & Domains Visited                                                                                   \\
\bottomrule
\end{tabular}
\caption{Difference in claimed functionality and user information stolen by spying extensions}
\label{tab:spyingextdef}
\end{table*}

%Identifying spying extensions is an arduous task. Therefore, we use the following pipeline to identify a ground-truth dataset of spying extensions --

%which we use throughout the rest of the paper for analysis and extracting signals for detection --

%\paragraph{Data Collection Pipeline: } Figure~\ref{fig:datacollectionflow} provides an overview of our data collection pipeline, which we divide into three parts - \ding{192} We first identify a candidate set of possibly spying extensions by applying semi-automated heuristic based techniques to all extensions on Chrome Web Store. \ding{193} Next, we verify whether this candidate set of suspicious extensions is indeed spying or not. This verdict is given by a human expert based on patterns detected from log files generated by simulating browser actions and installing the suspicious extension in a controlled environment. \ding{194} As final step, we expand the set of spying extensions by applying some data expansion signatures (like filename and code-snippet matches) to find a larger candidate set of suspicious extensions. We then repeat step \ding{193} and \ding{194} till we exhaust getting any new spying extensions.
%%\vspace{-0.25cm}
\subsubsectitle{\textbf{Data Collection Pipeline:} } We first conduct a crawl of all available extensions on the Chrome store and download 43,521 extensions spanning 12 categories. We identify spying behavior by relying on human expert verification. Since this requires considerable manual effort, we first shortlist possible spying candidates among all the extensions in the Chrome store, and manually verify only the short-listed samples. We divide our data collection pipeline into three procedures. \ding{192} We first identify a candidate set of possibly spying extensions among all Chrome store extensions by applying various heuristics. \ding{193} Next, the extensions in the candidate set are verified by three human experts by analyzing behavioral logs generated by running the extension in a controlled environment. \ding{194} We further expand the candidate set by leveraging various signatures (\eg based on file names and source code) extracted from newly identified spying extensions. Steps \ding{193} and \ding{194} are repeated until no new spying extensions are found. 
%As final step, we expand the set of spying extensions by applying some data expansion signatures (like filename and code-snippet matches) to find a larger candidate set of suspicious extensions. We then repeat step \ding{193} and \ding{194} till we exhaust getting any new spying extensions.


\begin{figure}
\centering
\includegraphics[width=0.49\textwidth]{datacollectionflow.jpeg}
\caption{Pipeline to identify spying extensions}
\label{fig:datacollectionflow}
\end{figure}


\subsubsectitle{\textbf{\protect\ding{192} Identifying candidates for verification: }} 
We use the following 4 techniques to build a candidate set.
%As first step shown in Figure~\ref{fig:datacollectionflow}, we collect a candidate set of possibly spying extensions. This is an important and very challenging task since spying extensions can be extremly hard to find. It is not possible to evaluate each and every extension on Chrome Web Store, therefore we first reduce the search space by proposing a set of seed data collection techniques as described below - 
%To create a true positive dataset of spying extensions (CWS\_Spy), we start by building a candidate dataset of spying extensions. Using expert human verification of this data, we flag spying extensions, which we later use to expand the spying extensions dataset. The following describes each candidate data-collection technique in detail --
\begin{itemize}
\item \textit{Browser Extension Monetization Services:} There are browser extension monetization services that incentivize developers to insert Javascript-based user tracking code in the source code\footnote{\eg \url{http://ext.guru}, \url{https://monetizus.com}, \url{http://www.adonads.com}}. The tracking code is used by the monetization services to collect sensitive information about extension users and developers are paid in exchange for such information. The monetization services may also inject advertisements on the client-side and developers earn a fraction of the generated ad revenue. Using web search with specific keywords (\eg \textit{browser extension monetization}), we collect a list of 15 popular monetization services. We short-list 115 extensions from the Chrome store that are developed by one of these 15 monetization services. In step \ding{193}, we verify 84 out of these 115 extensions to be spying.% on t which also advertise their own extensions published on Chrome Web Store.

%Several browser extension monetization services offer easy-to-use JavaScript based user information tracking code to developers which can be embedded in the source code of extensions. This tracking code is used by the mnetization services to collect sensitive information about extensions' users and developers  earn money in exchange of such information. The monetization services may also inject advertisements on client-side and the developers earn a fraction of the generated revenue. The keywords we use to find monetization services are - \textit{browser extension monetization}, \textit{monetize your extensions} and \textit{monetization platform extensions}. We collect a list of 15 popular monetization services which also advertise their own extensions published on Chrome Web Store. We find 115 such extensions, out of which we verify 84 such extensions to be spying. 
%\paragraph{Browser Extension Monetization Services:} Several browser extension monetization services offer easy-to-use JavaScript based user information tracking code to developers which can be embedded in the source code of extensions. This tracking code is used by the mnetization services to collect sensitive information about extensions' users and developers  earn money in exchange of such information. The monetization services may also inject advertisements on client-side and the developers earn a fraction of the generated revenue. The keywords we use to find monetization services are - \textit{browser extension monetization}, \textit{monetize your extensions} and \textit{monetization platform extensions}. We collect a list of 15 popular monetization services which also advertise their own extensions published on Chrome Web Store. We find 115 such extensions, out of which we verify 84 such extensions to be spying. 

%Using the tracking code, the monetization services may also inject advertisements on client-side and the developers earn a fraction of the generated revenue.
%%\vspace{-0.25cm}
\item \textit{Filename Based Signatures:} We look for filename based cues to identify spying extensions. We use regular expressions like - *track*.js, *trk*.js, *user*.js, *stats*.js, *click*.js to locate files within the packaged code of extensions. We discover 79 extensions with suspicious file names matching our criteria and later find 3 to be spying. 

%%\vspace{-0.25cm}
\item \textit{Permission Based Filtering:} Previous work has shown that certain permissions (and their combinations) listed in the Manifest file of extensions can be potentially misused by developers to enable malicious extensions~\cite{kapravelos2014hulk}. We extract a candidate set of 150 suspicious extensions which ask for such permissions (e.g., background, webRequest, and activeTab). Among these extensions, we verify five extensions to be spying.

%Extensions ask for various permissions (listed in their manifest file) which enable them to perform various functionalities. However, these permissions can be misused by developers to enable their extensions to get more than required permissions.  

%From the complete crawl of the Chrome Web Store extensions, we parse all the manifest and content script files to get a list of permissions by all the extensions published on the Chrome Web Store. We then look for extensions which have all of the following permissions asked for - background, webRequest, webNavigation, management, activeTab, unsafe\_eval, externally\_connectable; and mark the extensions which ask for all of these permissions has `suspicious'. We found 150 such suspicious extensions out of which we found 5 extensions to be spying. 

%%\vspace{-0.25cm}
\item \textit{Reported Extensions:} In the past, there have been several reports of spying extensions on the web~\cite{Labs:2015dz}\cite{weissbacherthese}. We search the Chrome Web Store for the reported extensions and find 30 extensions reported to be spying in last one year. Out of these, we find eight extensions to be still available on the Chrome store and spying. 
\end{itemize}
%Overall, we find a candidate set of 374 extensions and later verify 100 of these to be spying (Step \ding{193} of our pipeline). \raid{Many of the numbers in Section 3 do not add up} \anu{Added Table~\ref{tab:expansion}, still working over how to fix this confusion} \anu{1000 in intro and 374 here, causing confusion This can probably called initial candidate set and after expansion call it final candidate set, or mention that later the candidate set will blow uo further after expansion}
%Overall, we find a candidate set of 512 extensions later verify 100 of these to be spying based on the verification technique (Step \ding{193} of our pipeline).

%Overall, we found 100 spying extensions in our true positive dataset using the above techniques. Next, using various signatures extracted from these 100 extensions (described below), we expand this set over the entire Chrome Web Store data to include more spying extensions by searching for a signature match.

% 

\subsubsectitle{\textbf{\protect\ding{193} Verifying whether an extension is spying: }}
We start by installing the extension and apply an exhaustive web workload (covering the top 10 Alexa sites in English) that triggers a variety of browser actions (\eg form filling, tab open, mouse scroll) to collect extension behavioral logs. We collect information about network requests, changes to the client-side storage, and Chrome API calls to aid our manual human verification process. Chrome API calls are logged using the \textit{Chrome Extensions Developer Tool}.\footnote{\url{https://chrome.google.com/webstore/detail/ohmmkhmmmpcnpikjeljgnaoabkaalbgc/}} In order to capture networks requests generated by the extension, we use a \textit{record-replay} network tracing setup\footnote{\url{https://github.com/chromium/web-page-replay}}. In the \emph{record} phase, the workload is applied without loading the extension, and all network requests are cached. In the \emph{replay} phase, we run the workload with the extension loaded and serve requests from the cache when available and log any additional HTTP requests generated by the extension.

 %As the first step, we use a record-replay setup where we run an exhaustive workload to simulate various browser actions in the `record' step, and then load the  extension in `replay' step. We capture and compare the network request logs in both \emph{record} and \emph{replay} phase to identify any additional HTTP requests made in presence of the extension. Further, we also load the extension in a controlled environment with same workload used in record-replay phase and log changes in client-side storage, and browser API calls made by the suspicious extension. 


%and automatically generate -- (1) network request log, (2) changes in client-side storage and (3) browser API calls made by the extension under review. 

%To verify if a suspicious extension is indeed spying, we use manual investigation and heuristic-based techniques to
In our manual investigation process, we attempt to trace the flow of sensitive user information (\eg browsing history, form data) to third-party sites. We start by investigating the client-side storage changes and the Chrome API calls made by the extension to identify any access to user information. Next, we examine the network logs to determine any user information communicated to a third-party site as parameters of a GET request or as payload in a POST request. One of the challenges here is that user information is sometimes communicated in an obfuscated form using various encoding schemes (\eg base64). We apply appropriate decoding schemes (whenever known) to identify such cases. We give more details of spying verification technique in Appendix~\ref{verification}.

%\raid{While this manual effort is impressive, there is little novelty in the remainder of the paper. For example, the application of neural networks for pattern recognition (here on 2/3 grams of API calls) is not a new point in the design space. Furthermore, the paper positions 2/3 grams of API calls as an excellent method for detecting malicious behavior, yet ignores published research that demonstrates how easy it is to thwart detection based on API call traces} 

%, location and web-access tokens. We assess the client-side storage changes and the browser API calls made by the suspicious extensions to pinpoint the user information accessed by the extension. Next, we look at the network logs to find if the accessed information is sent to an untrusted remote server either as parameters of GET request, or as payload in a POST request. Additionally, we mark an extension as spying only if it performs an action to access and send user information to a remote server, which is not part of its listed functionality on the Chrome Web Store. Note that this part is manual and carefully performed by a human expert to ensure that no non-spying extension is added to our true-positive dataset. In each c 

%Since it is not possible to manually investigate each of the 43k extensions on the Chrome Web Store, we use a combination of semi-automated heuristics and human verification to flag spying extensions. As the first step, we use a record-replay setup where we run an exhaustive workload to simulate various browser actions in the `record' step, and then load the  extension in `replay' step. We capture and compare the network request logs in both \emph{record} and \emph{replay} phase to identify any additional HTTP requests made in presence of the extension. Further, we also load the extension in a controlled environment with same workload used in record-replay phase and log changes in client-side storage, and browser API calls made by the suspicious extension. 


%and automatically generate -- (1) network request log, (2) changes in client-side storage and (3) browser API calls made by the extension under review. 

%To verify if a suspicious extension is indeed spying, we use manual investigation and heuristic-based techniques to trace the flow of sensitive user information like browsing history, cookies, form data, location and web-access tokens. We assess the client-side storage changes and the browser API calls made by the suspicious extensions to pinpoint the user information accessed by the extension. Next, we look at the network logs to find if the accessed information is sent to an untrusted remote server either as parameters of GET request, or as payload in a POST request. Additionally, we mark an extension as spying only if it performs an action to access and send user information to a remote server, which is not part of its listed functionality on the Chrome Web Store. Note that this part is manual and carefully performed by a human expert to ensure that no non-spying extension is added to our true-positive dataset.  

%\paragraph{Verifying Data Access and Storage: } To verify if an extension is spying or not, as the first step we look for cues in collected logs of storage changes and browser API calls, which suggest if user information was accessed by the extension via cookies, history, storage, by sniffing the web traversal history or form fills. We also identify the exact information which was accessed by an extension. If the accessed information is obfuscated (for example, base64 encoding), then we try various deobfuscation techniques. We flag an extension to be `accessing user information' only when we find a trace of information being accessed and also decode that information. We use similar cues to identify if the same information was also stored locally by the extension (this is an optional behavior of a spying extension).
 
%\paragraph{Verifying Data Transmitted to Remote URL: } To complete the verification step, we identify if the accessed user information is sent to remote servers. To find a trace of such an activity, we look for cues in the browser API call logs and network logs. We compare the network log generated in the presence of extension with that of a clean session without extension, but using the same behavioral workload and extract additional URLs contacted from the prior logs. This helps us to narrow down a candidate set of remote server URLs. We then study these specific HTTP requests to understand if the same information which was accessed by the extension is also sent to a remote URL. Again, this data can be obfuscated and can be present either as payload or as part of GET parameter values. We use several deobfuscation techniques to decode the data and match it with the previously found information accessed by the extension. If the information matches and this operation is not required for the functionality of the extension as per its description of the Chrome Web Store, our human experts mark the extension as `spying' and add it to \texttt{CWS\_Spy} dataset.

%We perform following operations to every extension under review to identify if it is spying or not --

%\paragraph{Dynamic Run in Controlled Environment: } 
%As first step, we setup a clean browser session and load the enxtension along with an exhaustive workload which is scheduled to perform various browser actions on top 10 Alexa websites. \anu{WWW: to add the names}The workload ensures actions like form fills, creating and closing tabs, signing in email and social networking accounts etc. This allows the extension to exhibit its behavior on various browser events. 

%\paragraph{Capturing Chrome API Calls: }
%Extensions use several Chrome API endpoints to perform various operations like accessing cookies, storage, history, open and close tabs, modifying DOM elements etc. We use a modified version of Chrome Apps \& Extensions Developer Tool to capture the API calls made by the extension once it installs and during its dynamic run in controlled environment. A spying extension can access user information using such API calls. We identify the API calls made specifically to access user information and also decode `what' information is being accessed by an extension in this step.

%\paragraph{Capturing Storage State: Cookies, Local Storag, History}
%A spying extension accesses user information and may also store it temporarily on client side. To capture this behavior, we monitor the state of cookies and local storage of the browser session regularly during the dynamic run explained above. This enables us to monitor any changes in the client side storage by the extension.

%\paragraph{Network Log Analysis: }
%Spying extension also sends user information to a remote server. To capture this behavior, we log the HTTP requests made while the extension is running in the controlled environment. We compare the HTTP log generated with a corresponsing log generated using a browser session without the presence of extensiions. This helps us to identify the domains which are queried only in the presence of extension and allow us to flag potential remote server where the information is being sent to by the spying extension. We further analyse such HTTP calls to identify if previously accessed or stored user information is being sent over to the remote URLs.

%\paragraph{Expert Verification: }
%An extension may access user information and send it to a remote server, but still may not be actually spying if this action is needed for the functionality of the extension. Therefore, we manually assess each extension which accesses user information and send it to a remote server, compare it with its described functionality on the Chrome Web Store and then make a decision if it is spying or not. 


%\subsubsection{Capturing Network Data}
%We first run each extension in a controlled environment and capture the network log generated by the presence of extension using record-replay. \liang{I am confused, why do you have to run three times? Can you only run two times, where the first time you record network traffic without extension, then you record traffic with extension (all traffic can be captured/recorded by a proxy)?} \anu{We do not run it thrice, only twice. We take the event trace generated after replay phase and take all the requests and run them again removing the record-replay proxy in between with access to Internet. This ensures that we capture reditected URLs and help us narrow down on potential remote server URLs from the 404 requests generated in replay phase.}

%\textbf{Record Run:} In this phase, we prepare a behavioral suit for Top 10 Alexa websites. We use a clean session devoid of any previous cookies, storage, cache or browsing history in this phase. \anu{currently the operations to do in behavioral suit are hand-picked} \liang{Did you have a baseline run, where no extension is ever used on a clean session that browse the web pages chosen by your behavioral suit?} \anu{yes}

%\textbf{Replay Run:} In the replay run we first load the extension in a new browser session and capture all the HTTP requests. \liang{Why only catch those 404 ones?} \anu{is it clear now? Its not just 404s} The requests which generate 404 error help us to identify potentially untrusted remote URLs the extension is trying to contact. \anu{automated already}

%\textbf{Live Run:} Next, we execute all the HTTP requests from the first step. This enables us to capture the real behavior of extension in the presence of Internet. We log the resulting redirects and HTTP requests. \anu{automated already}

%\subsubsection{Capturing Storage and Cookie States}
%Before we load the extension in the previous step, we capture the local storage and cookie storage of the running browser extension and compare it with the state after extension has been loaded and run. This enables us to capture the storage and cookie changes caused by the extension under inspection. \anu{automated already}


%\subsubsection{Capturing Browser API Access} 
%To capture the browser API access by the extension, we use a tweaked version of Chrome Apps and Extension Developer Tool which helps us to record details of all the API calls made by the extension along with the timestamps.  \anu{automated already}  

%\subsubsection{Data Access, Storage, Sending Cues} 

%\textbf{Data Access:} From the previous section, we know the permissions and API calls which are needed to access user information. We look for those API calls from the log we generated to capture the API calls made by the extension. If any of those API calls are made then we mark the extension as trying to access user information.  \anu{can be automated to mark any extension accessing data as suspicious but will cause false positives}

%\textbf{Data Storage:} A spying extension may or may not store user data. We look for storage/cookie state before and
%after the extension is loaded and run to see if any data was stored by the extension on the client side. \anu{currently partially automated, the change in values, decoding what information is stored can be automated to some extent}

%\textbf{Data Transfer:} And extension has spying behavior if it access user information \liang{Can you list what we count as user information?} and stealthily sends that information to untrusted remote server. In an extension accesses user information, we aim to check whether the `same' information is being sent to remote untrusted servers or not to flag it as spying or benign. As first step, we check if any information is being sent to remote URLs by extracting the URLs and IP addresses from our network capture in the replay-run and live-run. Once we have these requests and the associated remote URLs, we try to decode the information that was sent to these remote URLs. We look at the GET parameters and the POST request payload to assess if the same information that was accessed by the extension was indeed sent to the remote URL. Sometimes, this information can be in plain text. If not, then we try to decode this information by using some decoding functions like base64, double base64 and hex \anu{The functions used for decoding are handpicked and can be automated, information matching between data access and sent can also be automated. We can also automate finding the remote URL where data is being sent}. If after decoding, the information being sent matches with the information being accessed, we mark the extension as `spying' if the data access and transfer was happening beyond the functionality of the extension as described on the Chrome Web Store. \liang{Are there any cases that the extension indeed need to send user information back to their servers?} \anu{Yes, we read the description of the extensions and do not mark such extensions as spying}

%Using the above verification technique we assess each extension under inspection. The chrome web store has huge number of extensions and our verification technique also needs expert manual intervention. Therefore, we first prune the chrome web store list of extensions to a list of suspicious extensions using techniques in the following sections. We then inspect each suspicious extension using our described verification technique. 


%Note that we do not use the entire suspicious dataset for expansion, but only the true positive dataset of 100 spying extensions after using the previously explained verification technique.

%After the verification step, we find 100 spying extensions in our spying dataset. Now, using various signatures extracted from these 100 extensions (described below), we expand this set over the entire Chrome Web Store data to include more spying extensions by searching for a signature match.

\subsubsectitle{\textbf{\protect\ding{194} Expanding the candidate set: }}
We extract various signatures from the spying extensions identified in step~\ding{193} to search for new extensions to be added to the candidate set. Signatures are extracted based on file names, developer identifiers, URLs in the source code, and Javascript code snippets. Next, we add any extension in the Chrome store with matching signatures to the candidate set. More details of our data expansion procedure are available in the Appendix \ref{datacol}.

Overall, we start with an initial candidate set of 374 extensions, and further expand it to 1,217 extensions after repeating steps~\ding{193} and~\ding{194}. In total, we identify 218 spying extensions.

%By repeating steps~\ding{193} and~\ding{194}, we expand our initial candidate set from 374 to 1,217 extensions, and verify a total of 218 spying extensions from this candidate set. \textcolor{blue}{We detail the number of  candidate extensions and verified spying extensions using the aforementioned techniques in Table~\ref{tab:expansion}}
%\begin{table}[h]
%\captionsetup{font=small}
%\centering
%\scriptsize
%\begin{tabular}{@{}l|ll|l|ll@{}}
%\toprule
%Baseline Techniques       & \multicolumn{2}{c|}{\#ext}            & Data Expansion        & \multicolumn{2}{c}{\#ext} \\ \midrule
 %                         & candidate & verified                 &                       & candidate    & verified   \\  \midrule
%permission based filter   & 150       & 5   & filename matching     & todo         & 49         \\
%by monetization services  & 115       & 84  & more ext by developer & todo         & 8          \\
%reported extensions       & 30        & 8   & remote URL match      & todo         & 46         \\
%filename based signatures & 79        & 3   & JS based signatures   & todo         & 15         \\ \midrule 
%Total                     & 374       & 100 &                       & 843          & 118        \\ \midrule
%Total Candidate           &           &                          &                       &              & 1217       \\
%Total Spying (CWS\_Spy)   &           &                          &                       &              & 218        \\ \bottomrule
%\end{tabular}
%\caption{We identify spying extensions by first inspecting an initial dataset of extensions and then expanding the dataset using the expansion techniques. We mark an extension as a spying extension only after verifying that it accesses and sends user data to a remote URL.}
%\label{tab:expansion}
%\end{table}

%further expand the cand
%Now that we have gathered an initial dataset of 100 spying extensions, we use various techniques to expand this dataset further. We find more suspicious extensions by extracting filename based signatures, comparing developers and searching for known untrusted remote URLs and JavaScript code snippets enabling spying from the current set of spying extensions in the source code of other extensions on the Chrome Web Store. We obtain a candidate set of 705 suspicious extensions using these expansion techniques and verify 118 of them to be spying using Step~\ding{193} of our pipeline. We repeat Step~\ding{193} and Step~\ding{194} till we no longer discover new spying extensions. Overall we find a dataset (\texttt{CWS\_Spy}) of 218 spying extensions which we use for further analysis and detection.  

%Now that we have gathered an initial dataset of 100 spying extensions, we use various techniques to expand this dataset further. We find more suspicious extensions by extracting  based signatures, comparing developers and searching for known untrusted remote URLs and JavaScript code snippets enabling spying from the current set of spying extensions in the source code of other extensions on the Chrome Web Store. We obtain a candidate set of 705 suspicious extensions using these expansion techniques and verify 118 of them to be spying using Step~\ding{193} of our pipeline. We repeat Step~\ding{193} and Step~\ding{194} till we no longer discover new spying extensions. Overall we find a dataset (\texttt{CWS\_Spy}) of 218 spying extensions which we use for further analysis and detection.  

%%\vspace{-0.25cm}
\subsubsectitle{\textbf{Strengths and Limitations of Our Data Collection Methodology.}} The main strength of our manual verification approach is that we never flag an extension that does not steal user information as spying. However, given the manual effort required, our approach is not scalable. In addition, we may not be able to identify all the spying extensions in the Chrome store for two key reasons: \textit{First}, our candidate set building approach is based on a limited set of heuristics and is unlikely to shortlist all spying extensions on the Chrome store. \textit{Second}, spying extensions can use sophisticated encoding schemes to hide user information that we may not be able to identify.

%and our heuristics may not be able to identify all the spying extensions in the Chrome store.
%and hence our dataset of spying extensions has zero false positives. 
 
 %However, identifying spying extensions is a challenging task and can lead to false negatives (spying extensions that are not caught). 

%Two key factors affecting false negatives include the following: 


%\textcolor{blue}{using the manual analysis. The manual analysis is done only to gather an initial dataset of true positive spying extensions and is not scalable.} 

To overcome these limitations, in Section~\ref{sec:detection}, we propose a machine learning based scheme that automatically detects spying extensions (without any manual effort). 
%\raid{The manual analysis heuristics are crude and not scalable}


%\textcolor{blue}{As mentioned earlier, this also means that our negative class of extensions will not be clean and can have spying extensions. This makes our task of automatically detecting spying extensions even more challenging. However, we show promising results in Section~\ref{sec:detection}, and our results would only improve if we have a clean negative class devoid of spying extensions}

%a detection mechanism which can detect new spying extensions

%Lastly, our web workload may fail to trigger spying behavior of some extensions.
%The primary reasons for false negatives are---some spying extensions may trigger only on certain browser events which may not be captured by our behavioral workload. Moreover, the other challenge in verification of spying extension is obfuscated payload (using techniques like base64, ASCII etc.) and parameters while sending the user information to a remote server. We try to decode the information sent to a remote server (if any) and flag an extension as spying only if we successfully decode the HTTP request parameters and match it with the user information accessed. Therefore, we are not able to identify each spying extension in case we are either unable to trigger it or decode the information being sent. Despite these limitations, we later build a detection mechanism which can detect new spying extensions even from the false negative set of annotated data.  

%Our strict verification process ensures that we never flag a benign extension as spying and hence our true positive dataset of spying extension \texttt{CWS\_Spy} has zero false positives. However, verifying whether an extension is spying is a tedious task. Therefore our annotation technique can cause several false negatives. The primary reasons for false negatives are -- Some spying extensions may trigger only on certain browser events which may not be captured by our behavioral workload. Moreover, the other challenge in verification of spying extension is obfuscated payload (using techniques like base64, ASCII etc.) and parameters while sending the user information to a remote server. We try to decode the information sent to a remote server (if any) and flag an extension as spying only if we successfully decode the HTTP request parameters and match it with the user information accessed. Therefore, we are not able to identify each spying extension in case we are either unable to trigger it or decode the information being sent. Despite these limitations, we later build a detection mechanism which can detect new spying extensions even from the false negative set of annotated data.  

%%\vspace{-0.25cm}



%The Chrome Web Store organizes extensions into 12 primary categories~\cite{Google:xe} as shown in Table~\ref{tab:dataset-desc}. We obtain the \texttt{CWS\_All} dataset by crawling all publicly visible extensions in each of the 12 categories (shown in Table~\ref{tab:dataset-desc}). Our crawl conducted in September 2016, discovered 43,521 extensions (which is similar to counts reported in recent prior studies~\cite{kapravelos2014hulk}).

%Table~\ref{tab:dataset-desc} shows high-level statistics for the collected data. 
%We identified 218 spying extensions spanning a wide range of categories. It is interesting to note that spying extension developers target the top categories in \texttt{CWS\_All} (by volume of extensions), namely, ``Productivity'', ``Fun'', and ``Communication'', more than other categories, including ``News".

%We now give an overview of the data collected in \texttt{CWS\_Spy} and \texttt{CWS\_All}. The Chrome Web Store organizes extensions into 12 primary categories~\cite{Google:xe}. We obtain the \texttt{CWS\_All} dataset by crawling all publicly visible extensions in each of the 12 categories (shown in Table~\ref{tab:dataset-desc}). Our crawl conducted in September 2016, discovered 43,521 extensions (which is similar to counts reported in recent prior studies~\cite{kapravelos2014hulk}).

%\vspace{-0.5cm}


%\begin{table}[h]
%%\captionsetup{font=small}
%\centering
%\small
%\begin{tabular}{@{}llll@{}}
%\toprule
%Category        & Chrome Store (\%)  &   Spying (\%) & Spying Extension Examples\\ \midrule
%Productivity    & 14,547 (33.42)    & 31 (14.22)     & Block site, SimilarWeb            \\
%Fun             & 6,613 (15.19)     & 80  (36.69)    & Channel Sub Box for YouTube, Twitch Stream  \\
%Communication   & 5,764 (13.24)     & 35  (16.05)    & HolaSoyGerman, ElrubisOMG           \\
%Web Development & 4,162 (9.56)      & 5  (2.29)      & Web Developer Tools, Website painter       \\
%Accessibility   & 4,062 (9.33)      & 7  (3.21)      & GouQi, Stop Flash           \\
%Search Tools    & 2,493 (5.73)      & 6  (2.75)      & Handy maps, Airbnb search           \\
%Shopping        & 2,060 (4.73)      & 7  (3.21)      & SwytShop, Smart Shopper           \\
%News            & 1,495 (3.43)      & 32 (14.68)     & Custom RSS news, BBC News feed            \\
%Blogging        & 835 (1.92)        & 11  (5.04)     & Koukis Youtube, Videos do Muca Muricoca           \\
%Photos          & 651 (1.49)         & 1  (0.46)     & Take a picture everyday            \\
%Sports          & 569 (1.31)        & 3 (1.38)       & RotoGrinders Fan Duel Tool, Olympics 2012 London           \\ 
%By Google		& 62 (0.14)				& 0							\\ \midrule
%Total           & 43,521 (\texttt{CWS\_All})           & 218  (\texttt{CWS\_Spy})               \\ \bottomrule
%\end{tabular}
%\caption{All Chrome Web Store extensions are assigned a primary category. Table shows distribution of extensions in each category and the corresponding distribution of spying extensions. Spying extensions are predominantly present in Top 3 categories by volume of extensions.}
%\label{tab:dataset-desc}
%\end{table}
%
\vspace*{-0.25cm}
\subsection{Dataset Description} 
In this work, we use two types of datasets: (1) A near-complete dataset of all extensions available on the Chrome Web Store as of May 2016 (\texttt{CWS\_All}), (2) A dataset of spying Chrome extensions (\texttt{CWS\_Spy}). \texttt{CWS\_All} is collected by a crawl of the entire Chrome Web Store and \texttt{CWS\_Spy} is the dataset built using the methodology described previously, between the time period May-July, 2016. For both datasets, we collect the source code for each extension and perform an additional crawl to collect all publicly available metadata associated with each extension. Metadata includes information about the size of the user base, reviews, ratings, bug reports, general functionality of the extension, and the developer. 
%we now explain our collection of \texttt{CWS\_Spy} dataset. .

%We now give an overview of the data collected in \texttt{CWS\_Spy} and \texttt{CWS\_All}. 
Table~\ref{tab:dataset-desc} shows high-level statistics for the collected data. The \texttt{CWS\_All} dataset contains 43,521 extensions (similar to count reported in prior study~\cite{kapravelos2014hulk}) spread over 12 primary categories. For our \texttt{CWS\_Spy} dataset, we identify 218 spying extensions spanning a diverse range of categories. It is interesting to note that spying extension developers target the top categories in \texttt{CWS\_All} (by volume of extensions), namely, ``Productivity'', ``Fun'', and ``Communication'', more than other categories, including ``News". The last column in Table~\ref{tab:dataset-desc} shows the name of the top spying extension in each category based on the number of installs.

\begin{table}[h]
%\captionsetup{font=small}
\centering
\footnotesize
\begin{tabular}{@{}p{1.5cm}p{1.5cm}p{1cm}p{2cm}l@{}}
\toprule
Category        & ChromeStore (\%)  &   Spying (\%) & Top Spying Extension			&	\#Users\\ \midrule
Productivity    & 14,547 (33.42)    & 31 (14.22)     & Block site					&	1,072,111\\
Fun             & 6,613 (15.19)     & 80  (36.69)    & Channel Sub Box for YouTube	&	142,621 \\
Communication   & 5,764 (13.24)     & 35  (16.05)    & HolaSoyGerman           		&	106,022\\
Web Development & 4,162 (9.56)      & 5  (2.29)      & Web Developer Tools			&	2,081\\
Accessibility   & 4,062 (9.33)      & 7  (3.21)      & GouQi 						&	599 \\
Search Tools    & 2,493 (5.73)      & 6  (2.75)      & Handy maps 					&	6,451 \\
Shopping        & 2,060 (4.73)      & 7  (3.21)      & SwytShop						&	35,015\\
News            & 1,495 (3.43)      & 32 (14.68)     & Custom RSS news 				&	6,126\\
Blogging        & 835 (1.92)        & 11  (5.04)     & Koukis Youtube				&	2,662\\
Photos          & 651 (1.49)         & 1  (0.46)     & Take a picture everyday		&	200\\
Sports          & 569 (1.31)        & 3 (1.38)       & RotoGrinders Fan Duel Tool	&	7,818\\ 
By Google		& 62 (0.14)				& 0							&  &\\ \midrule
Total           & 43,521 (\texttt{CWS\_All})           & 218  (\texttt{CWS\_Spy})               & & \\ \bottomrule
\end{tabular}
\caption{Distribution of spying and other extensions across various categories.}
\label{tab:dataset-desc}
\end{table}

%Lastly, it is important to note that 

\subsubsectitle{\textbf{Communication with Google.}} Considering the privacy risks facing users, we followed responsible disclosure procedure and established communication with Google. We shared a version of our draft and on 8 June, 2017 additionally shared the details of spying extensions identified in our work.
%As of 12 August 2017, 207 out of 218 spying extensions are still available on the Chrome store. 
%all spying extensions identified in our work (including those identified using our automated approach in Section~\ref{sec:detection}).
%\google{anu: We did not check if the remaining 215 extensions got a version update with tracking code removed or not on 28 March, 2017} 

%\raid{R3: The paper mentions that only 3 of the identified Chrome extensions have been taken down from the Chrome Store. It is not clear whether the authors disclosed the identified spying extensions to Google, R2: While the paper repeatedly claims that spying extensions are a problem because they are still available on the Chrome-store, the text makes no reference towards any reporting efforts that would inform Google of the findings. Google's reaction would be particularly interesting if the identified leaks would not trigger a response from them. However, the mere observation that spying extensions are still present on the store, might have different reasons, such as Google disagreeing with the severity of the findings presented in the paper. The fact that only 8 of 30 previously reported extensions were removed might indicate that Google indeed has a different measure of what constitutes spying.} \anu{We did not check if the remaining 215 extensions got a version update with tracking code removed or not on 28 March, 2017. How can we concretely claim that only 3 extensions were taken down?}

defense_evaluation.tex
\subsection{RNN based Detection Scheme} \label{subsec:rnn}

\noindent We present a Recurrent Neural Network (RNN) based sequence classification approach to accurately detect spying extensions. In this section, we explain our proposed model, assess its performance, and compare it with existing techniques. 
%\acsac{. I am convinced that RNN can work and the evaluation of RNN is sound. However, I am not convinced that RNNs were indeed strictly necessary.}

\subsubsectitle{RNN Background. } Unlike traditional Neural Networks, a Recurrent Neural Network (RNN) has a notion of ``memory'' that captures information seen so far. An RNN has feedback connections which allow the model to have loops connecting the output layer to the input, enabling the model to build a memory about input fed to the network over time. This enables RNN models to learn patterns in sequential data such as natural language text or time-series data. 

A basic RNN takes a sequence as input, and then at each training step updates a hidden state (that captures the memory) to generate an output vector that can be used to predict the next item in the sequence. Each hidden state is iteratively updated based on the previous hidden state and the current input so that the output vector better predicts the next item in the sequence. While the basic RNN is efficient at capturing short-term sequential patterns, it is unable to capture long-term dependencies (or patterns). We use a special variant of RNN, called Long Short Term Memory networks (LSTM) that is capable of capturing long-term dependencies~\cite{hochreiter1997long}.

An LSTM has multiple memory cells, where each memory cell has special input and forget gates that can capture long-term dependencies. Using the forget and input gate, the hidden state of each memory cell is iteratively updated to forget a fraction of existing memory and to add new memory, respectively, to better predict the next item in a sequence. LSTMs have been shown to outperform traditional sequence classification techniques such as Hidden Markov Models (HMM)~\cite{hochreiter1997long}. LSTM has also been shown to effectively capture dynamic sequential behavior to detect malicious applications~\cite{pascanu2015malware}\cite{shibahara2016efficient}. 

\subsubsectitle{RNN Model Architecture. } We use an LSTM model for our detection task. As input to the LSTM model, we use the sequence of Chrome API calls made to specific API endpoints at a method level. The only pre-processing we perform on the input sequence is converting each API call (e.g. \emph{cookie.set}) to a unique numerical identifier. We use two hidden LSTM layers with 200 neurons in each layer, with a dropout rate of 0.2 (to avoid overfitting) and a reLU activation function at the output layer. Learning rate is tuned using RMSprop gradient descent optimization and training loss is computed using the cross entropy loss function. 
%\vspace{-0.5cm}

\subsubsectitle{RNN Detection Performance. } Table~\ref{tab:model-comarison} shows comparative results and Figure~\ref{fig:lstm-results} shows corresponding Precision-Recall curves. For comparison, we present results for a HMM model using API call sequence as input, and Neural Network and Logistic Regression based models using all features (in Table~\ref{tab:model-comarison}). Our RNN based approach outperforms other approaches with the highest precision (90.02$\pm$1.06\%) and recall (93.31$\pm$0.92\%).
%, and the highest area under the precision-recall curve (0.868). 
From the precision-recall curve, it is also clear that we need not significantly sacrifice precision to improve recall for our approach. 
%\raid{However, even with a 90\% precision (using both Chrome API calls and Web API calls), it may still generate too many  to be deployed on end hosts. There are around 10\% of the spying extensions that the model missed. Why were they not detected?}

\begin{figure}[h]
\centering
\includegraphics[width=0.4\textwidth]{lstm-results}
\caption{Precision-Recall curve using API call sequences as a feature to detect spying extensions.}
\label{fig:lstm-results}
\end{figure}

\begin{table}
\centering
\begin{tabular}{@{}lll@{}}
  \toprule
               & Precision (\%) & Recall (\%)\\ \midrule
  Neural Network-All      & 78.12     & 80.32  \\
  Neural Network-API      & 72.04     & 75.20  \\
  HMM          & 66.23     & 63.27  \\
  %LSTM-sigmoid & 83.07     & 51.29  \\
  %LSTM-tanh    & 87.76     & 82.05  \\
  Logistic Regression (LR)	& 22.35	& 24.18 \\	
  RNN    & \textbf{90.02}     & \textbf{93.31}  \\ \bottomrule
  \end{tabular}
\caption{\small{Precision and recall comparison of various models}}\label{tab:model-comarison}
\end{table}

\subsubsectitle{Analysis of False Positives. } 
There are 22 benign extensions marked as spying by our model. Among them, 17 extensions access and transmit user information to a remote server. However, when we corroborate this behavior with their description on the Chrome Web Store, we find that such access is required for the functionality of these extensions. For example, one such extension is called Honey\footnote{\url{https://chrome.google.com/webstore/detail/bmnlcjabgnpnenekpadlanbbkooimhnj}}, which is a popular extension to find discount coupons on e-commerce websites. In order to operate, this extension requires to capture the URLs visited by the user. We did not find any conclusive reason for the rest 5 benign extensions marked as spying.


%We find 22 benign extensions marked as spying by our model. Among them, 17 extensions access user information (like browsing history, and session cookies) and send this information to a remote server. However, when we corroborate this behavior with their description on the Chrome Web Store, we find that such access is required for the functionality of these extensions. For example, one such extension is called Honey\footnote{\url{https://chrome.google.com/webstore/detail/bmnlcjabgnpnenekpadlanbbkooimhnj}}, which is a popular extension to find discount coupons on e-commerce websites. In order to operate, this extension requires to capture the URLs visited by the user. It is interesting to note that we only had few such cases, even though our defense scheme does not take into account any declaration (in the manifest) of user information extraction by extensions. This is like due to the difference in the sequential patterns between benign and spying extensions that collect sensitive information. We did not find any conclusive reason for the rest 5 benign extensions marked as spying.}

%Recall that our negative class (of all other Chrome extensions) can be noisy and may contain yet unknown spying extensions. In this section, we further analyze the extensions in the negative class that were classified as spying (false positives) by our classifier. There are 23 such extensions and an in-depth evaluation brings out the following highlights:

%\raid{The approach can potentially identify all extensions that send data to third-party sites, even those that have declared this behavior in the manifest (and hence not classified as spying?). How do you distinguish these cases?}

%\begin{itemize}[leftmargin=*]
%\item \textit{Extensions verified to be spying. }We find 9 extensions to be actually spying and steal browsing history, cookies and form fill data. Two of the extensions were taken down at the time of analysis (with external reports of them being spying). Additionally, the remaining 7 extensions are still live and have a large cumulative user base of 3.2 million. \acsac{This paper used 40k extensions and build an automated system to identify spying extensions and overall detected less than previous work, which means that a considerable amount of spying extensions were not correctly identified with the proposed method. What is really surprising is that the automated system did not do identify many more spying extensions compared to the manual analysis of the authors. Since this contradicts previous work, the automated analysis needs more work. I would suggest to manually verify some of the extensions as benign and train on those and the spying ones. In general, in a paper that automates the detection part it is expected many more malicious items to be detected.} %Interestingly, one of these extensions mention that it would collect anonymized click-stream data of users with an opt-out feature; however, the extension was collecting non-anonymized browsing history of users.% which could be easily decoded. 
%\raid{By analyzing the false positives, the authors found 9 additional spying extensions. However, only two have been removed from the store, and the remaining 7 have a user base of 3.2 million. Again, is it possible that this is due to the fact that (some of) these 7 extensions are not really malicious, but simply did not fully disclose technical details in the extension's textual description?}

%\item \textit{Benign but sending sensitive information. }We find 12 extensions which access user information (like browsing history, and session cookies) and send this information to a remote server. However, when we corroborate this behavior with their description on the Chrome Web Store, we find that such access is required for the functionality of these extensions. For example, one such extension is called Honey\footnote{\url{
%https://chrome.google.com/webstore/detail/bmnlcjabgnpnenekpadlanbbkooimhnj}}, which is a popular extension to find discount coupons on e-commerce websites. In order to operate, this extension requires to capture the URLs visited by the user. It is interesting to note that we only had few such cases, even though our defense scheme does not take into account any declaration (in the manifest) of user information extraction by extensions. This is like due to the difference in the sequential patterns between benign and spying extensions that collect sensitive information.

%\item \textit{Unverified. }Remaining 2 extensions send obfuscated information to remote servers which we could not successfully decode. Therefore, we are unable to confirm whether they are spying.  
%\end{itemize}

%Overall 9 out of 23 extensions (and possibly 2 more unverified cases) are new spying extensions caught by our approach. This further highlights the high detection performance of our approach. We give more details about these newly found spying extensions in Appendix~\ref{falsepos}.

\subsubsectitle{Analysis of False Negatives. } There are 7 spying extensions that we are not able to detect. Among them, 2 extensions generated a very small trace of API calls (less than 55 API calls, compared to the average call length of 215). Possibly, these sequences were not long enough for the RNN model to effectively identify patterns. Next, there are 5 spying extensions that do not use Chrome API calls to transmit user information, but instead use a Web API call (XMLHttpRequest) to make network requests. However, it is easy to detect these extensions by augmenting the Chrome API call sequence with Web API calls (discussed next).

%\subsubsectitle{Analysis of False Negatives. } There are 7 spying extensions that we are not able to detect. We further analyze these cases to understand why they are hard to detect. Among them, 2 extensions generated a very small trace of API calls (less than 55 API calls, compared to the average call length of 215). Possibly, these sequences were not long enough for the RNN model to effectively identify patterns. Next, there are 5 spying extensions that do not use Chrome API calls to transmit user information, but instead use a Web API call (XMLHttpRequest) to make network requests. However, it is easy to detect these extensions by augmenting the Chrome API call sequence with Web API calls (discussed next).} 

%\textcolor{blue}{
%Our RNN model to detect spying extensions has a false negative rate of 16\%, and we have 36 spying extensions which we are not able to detect. On further analysis, we hypothesize following reasons for these hard to detect cases:}
%\begin{itemize}[leftmargin=*]
%\item \textcolor{blue}{8 spying extensions have a very small trace of API calls generated (<60). Possibly, this short sequence is not enough for our RNN model to effectively find patterns specific to spying and hence missing these extensions.}
%\item \textcolor{blue}{24 spying extension which our model misses are the ones which do not make Chrome specific WebRequest API, but instead use XMLHttpRequest to make network requests. Therefore, the data transmission action is not captured by the API call sequence. Later, when we augment the API call sequences with Web API calls, then we are able to successfully detect 20 spying extensions of this category.} 
%\item \anu{can not find a good reason for remaining 4}
%\end{itemize}

\subsubsectitle{Augmenting Chrome API calls Sequences with Web API Calls. } One limitation of our approach (using Chrome API call sequences) is that we do not consider the network requests made using the Web API, mainly the XMLHTTP Requests (XHRs) to send user information. To address this limitation, we perform an additional experiment where we train an RNN by merging the XHR calls and Chrome API calls made by  extensions (by ordering the calls based on timestamps). Using this model, we achieve a higher recall of 95.02\% and a higher precision of 91.32\%, compared to the RNN model trained only using the Chrome API call sequence. Hence, our approach can be easily extended to further improve detection performance by incorporating other Web API calls into the RNN input sequence. 
%\raid{The paper discusses briefly about extensions that do not use the API calls to make network requests. It would be helpful to see when API calls are necessary (or not), and discuss how evasion can be performed for an extension that wish to bypass detection.}


\subsubsectitle{Robustness of RNN Model. }An attacker can try to evade detection by perturbing the API call sequence. To test the robustness of our RNN model against such attacks, we perturb the API call sequences of spying extensions and evaluate impact on detection performance. Perturbation is done by inserting a `benign' sequence of certain length at a random position between the first instance of information access and first instance of information transmit. In practice, an attacker strategy might be similar where he tries to hide data leakage by generating noise before sending out the information to a third party. The sequence to be inserted is a randomly chosen n-gram sequence from non-spying extensions. We repeat the experiment for different lengths of inserted sequence ranging from 1 to 200 (215 is the average number of API calls for all extensions using our workload), and perform 5 random trials for each spying extension. We observe that detection performance drops slightly as we increase the length of the inserted sequence. For the longest inserted sequence of 200, our precision drops to 86.08\% (from 90.02\%) and recall drops to 89.9\% (from 93.31\%). This indicates that the RNN model is quite robust against heavy perturbations. 

Theoretically, an attacker can further increase the perturbations to evade detection. However, the downside of such a heavy perturbation would be reduced performance of the browsing session, which might alert the user. The browser operator can also impose rate limits on the API endpoints to limit the number of operations done by an extension, to limit abuse and avoid browser slowdown. In addition, if the attacker increases the perturbations heavily, the extension might become easier to detect by existing machine learning models, as the activity patterns might look abnormal.
% due to abnormally increased activity.




%An attacker can try to evade detection mechanism by generating random API calls. To test the robustness of our RNN model against such attacks, we perturb the API call sequences of spying extensions and then check the detection performance. For this experiment, we first generate a random sequences of API calls of various lengths between 1 to 200 (213 is the average number of API calls for all extensions using our workload). We then insert this noisy sequence at a random position lying between the first instance of information access and first instance of information transmit. In practice, an attacker strategy might be very similar where he tries to hide the leaking of user data by generating noise before sending out that information to third party. After repeating this experiment several times for each extension and every length of API call sequence, our precision drops to 81.22\% (from 88.96\%) and recall drops to 78.1\% (from 83.25\%) when the length of noisy sequence inserted is 200. This is a tolerable drop in performance despite heavy perturbations. Theoretically, an attacker can keep increasing the perturbations to evade detection. However, the downside of such a heavy perturbation would be reduced performance of the browser. The browser operator can also impose rate limits on the API endpoints to limit the number of operations done by an extension, to reduce abuse and avoid browser slowdown. In addition, if the attacker increases the perturbations heavily, the extension might become easier to detect by existing machine learning models due to abnormally increased activity.

\subsection{In-the-Wild Detection of Spying Extensions} \label{subsec:inwilddetection}
\noindent To discover new spying extensions from rest of the extensions on Chrome Web Store, we use our trained model to conduct an in-the-wild detection of spying extensions. Our RNN model marks 90 extensions as spying. A manual investigation and verification confirms 65 extensions to be spying. Here we give details about these 90 extensions marked as spying --

\subsubsectitle{Extensions confirmed to be spying: } Manual verification confirms 65 out of 90 extensions to be actually spying. We found all of the spying extensions sending browsing history to external URLs, when such an operation was not needed for their functionality. 
%One example is a popular extension called \emph{Speakit} with 0.5 million users. 
%While it is supposed to convert text to speech, it was actively sending every URL (obfuscated) visited by the user to \emph{upalytics.com}. 
The newly discovered 65 spying extensions had a user base of 4.2 million and 4 of them were taken down after our analysis. Table~\ref{tab:falsepos} gives details of a sample of these newly found spying extensions which are most popular on Chrome Web Store.

\subsubsectitle{Benign but marked as spying: } Out of the remaining 25 extensions predicted as spying by our model, we verified 20 extensions to be benign. These 20 extensions were accessing and sending user information to remote server, but such an operation was needed for the functionality of the extension. 
%This is in-line with our previous analysis of false positives generated by our model.}

\subsubsectitle{Unverified: } We were not able to confirm whether the remaining 5 extensions are indeed spying. The data transmitted by these 5 extensions was highly obfuscated and we were unable to decode the network requests.
% to confirm if the transmitted data matches with accessed data or not.} 

Overall, our in-the-wild experiment shows that we are able to catch several new spying extensions using a limited training dataset. The operator can further boost the performance of the model by adding new training samples from newly found spying extensions.

 %Since identifying spying extensions is a difficult task, an initial limited number of spying extensions makes the detection challenging. In future, the detection can be boosted by adding more spying extensions to train the model and add the newly detected spying extensions increase performance of the model.




%\textcolor{blue}{In the previous section, we trained and evaluated our model on a dataset of 207 spying and a total of 3,105 benign extensions. To discover new spying extensions from rest of the extensions on Chrome Web Store, we use our trained model to conduct an in-the-wild detection of spying extensions. Our RNN model marks 90 extensions as spying. A manual investigation and verification confirms 65 extensions to be actually spying. Here we give details about these 90 extensions marked as spying --}

%\subsubsectitle{Extensions confirmed to be spying: } \textcolor{blue}{Manual verification confirms 65 out of 90 extensions to be actually spying. We found all of the spying extensions sending browsing history to external URLs, when such an operation was needed for their functionality. One of the most popular newly found spying extension in our dataset is \emph{Speakit} with 0.5 million users. While it is supposed to convert text to speech, it was actively sending every URL (obfuscated) visited by the user to \emph{upalytics.com}. The newly discovered 65 spying extensions had a user base of 4.2 million and 4 of them were taken down after our analysis. Table~\ref{tab:falsepos} gives details of a sample of these newly found spying extensions which are most popular on Chrome Web Store.}

%\subsubsectitle{Benign but marked as spying: } \textcolor{blue}{Out of the rest 25 extensions predicted as spying by our model, we found 20 extensions to be actually benign. We find that these 20 extensions were accessing and sending user information to remote server, but such an operation was needed for the functionality of the extension. This is in-line with our previous analysis of false positives generated by our model.}

%\subsubsectitle{Unverified: } \textcolor{blue}{We were not able to confirm the reason of rest 5 extensions marked as spying. The data transmitted by these 5 extensions was highly obfuscated and we were unable to decode the network request to confirm if the transmitted data matches with accessed data or not.} 

%Our in-the-wild detection shows that we are able to catch new spying extensions. Since identifying spying extensions is a difficult task, an initial limited number of spying extensions makes the detection challenging. In future, the detection can be boosted by adding more spying extensions to train the model and add the newly detected spying extensions increase performance of the model.


defense_overview.tex
\subsection{Our Idea: Leverage Sequential Patterns in API Calls}


\subsubsectitle{Key Insight. }Our key insight is that we can distinguish spying extensions from other extensions based on patterns in Chrome API call sequences. 

We provide a simple illustration of our insight using a spying and benign extension from our dataset. Figure~\ref{fig:timeseries_visualization} shows the Chrome API call sequences for these extensions. For better understanding, the API methods are color coded based on whether they are \textit{access}, \textit{store} or \textit{transmit} methods. Access methods are those associated with the following API endpoints --  bookmarks, cookies, history, storage, and tabs. We focus on these specific endpoints because our dataset of spying extensions uses these endpoints for accessing user information. Store operations includes the following persistent storage endpoints--- bookmarks, cookies, history and storage. Transmit methods include those used to send and receive HTTP requests. The remaining API methods are annotated as \textit{others}. 

In Figure~\ref{fig:timeseries_visualization}, there is a striking difference in the patterns of spying and benign extensions. The spying extension has access operations closely followed by a transmit operation. The benign extension on the other hand exhibits network transmit operations like spying extensions but does not access any user information.

Note that the above is a very simplistic example of sequential patterns exhibited by spying and benign extensions. In practice, these patterns could be more complicated. For example, access and transmit methods may be further apart in the case of spying extensions, or there might be benign extensions that also use access and transmit methods in different ways. In fact, we even do not want to restrict ourselves by annotating API methods as access, store and transmit methods. \textit{Thus, the key challenge is to automatically distinguish between spying and benign extensions based on any available complex patterns in API call sequences.}

\begin{figure}[h]
\includegraphics[width=0.45\textwidth]{timeseries_visualization}
\caption{Time series of events for a sample of spying and benign extensions.}
\label{fig:timeseries_visualization}
\end{figure}

%\vspace{-0.25cm}
\subsubsectitle{Learning Complex Patterns in API Call Sequences to build a Classifier.} Previous study by Canali \textit{et al.} surveyed use of n-gram and bags model on system API calls to extract signatures from malware for malware detection. They found that N-gram models reach a performance threshold after a certain sequence length and triggers more false positives as the sequence length increases~\cite{Canali:2012:QSA:2338965.2336768}. 

%\textcolor{blue}{
To verify if n-grams could yield significantly better detection performance, we repeat our experiments in Section~\ref{subsec:prior} by including n-gram of API calls made by extensions (of size 2 and 3) as a feature. We observe only a marginal increase of 1.01\% precision and 1.23\% recall when using the Neural Network based model with all the existing features along with n-grams.
%}

In fact, RNN based models have been shown to outperform traditional n-gram based models when modeling sequential data~\cite{de2015survey}. Therefore, we leverage recent advances in deep neural networks to learn complex patterns in sequential data. We use a \textit{Recurrent Neural Network (RNN)} based classifier that takes in as input a sequence of API calls to distinguish between spying and benign extensions. 
%\acsac{The comparative analysis does not consider n-grams. The authors assume that n-grams just won’t work, citing the work of Canali et. al [6]. The authors do not provide a precise explanation why and to what extent the problems identified by Canali et al. apply to browser extensions. Second, the authors also refer to De Mulder et al. [9] to support their decision of not using n-grams (limited to RNN). However, also here, the survey of De Mulder et al. is about natural languages and does not necessarily mean that the same results can be transferred to programming languages. If the authors wanted to make a stronger point, they should have considered to include n-grams in the analysis. Also, this would have justified the claim that prior works are inadequate for this problem.}

%LSTM based model with API call sequence as input. Though based on sequence of API calls, LSTM model is more resilient and can learn complex patterns from sequences

%Outline challenge with extracting such patterns. n-grams are not sufficient. We use deep learning and recent advances.

\subsubsectitle{Benefits of using API Call Sequence. } We further motivate the usefulness of API call sequences (and an RNN) by highlighting three key advantages.

\begin{itemize}[leftmargin=*]
\item \textit{Abandon need for hand-crafted features. } Learning patterns in API call sequences using an RNN obviates the need for extensive feature engineering as in previous research. We show that an RNN-based approach can achieve high detection performance using only sequential data of API calls.
%by using a machine learning scheme that can better capture patterns in API call sequences.
\item \textit{Call sequence captures core spying behavior. } Chrome API calls are required for the core functionality and operation of an extension and especially for enabling spying capabilities. Therefore, it would be difficult for a spying extension developer to adapt the API call sequence to bypass a defense (Section~\ref{subsec:rnn} analyzes robustness of defense). On the other hand, defenses based on static features would not be so robust. For example, we have seen in Section~\ref{sec:analysis} that crowd-sourced reviews and ratings of spying extensions are similar to that of benign extensions. Even other static features like file name based signatures can be easily adapted by a developer of a spying extension to bypass defenses. 
\item \textit{Adapt to dynamic spying behavior. }A spying extension may not be triggered at the time of evaluation. Chrome API calls can capture changes in the behavior of an extension which may periodically switch between spying and benign activities. Thus a defense based on API call sequence can adapt to dynamic spying behavior. 
\item \textit{Chrome API call sequence encompasses most other dynamic features. }
Though there exist other dynamic features apart from Chrome API call sequences viz. network log, change in and client-side storage; API call based features form a bigger umbrella encompassing other dynamic features. Most of the operations captured by network logs and cookie/storage logs also reflects in the Chrome API call logs with a corresponding entry, with the exception of Web API calls (which is available to all web pages). An example of a Web API call is an XMLHttpRequest to send and receive information from a remote server. Later, in Section~\ref{subsec:rnn}, we show how we can augment Chrome API calls sequences with Web API calls to further improve detection performance. By tracking such network requests, note that we can also potentially detect spying behavior driven by content scripts.
% By leveraging such different types of network requests, our approach
%\textcolor{blue}{ Since we dynamically run each extension in a controlled environment, our technique is able to catch all actions performed by an extension which require a call to browser APIs including dynamic AJAX requests from content scripts.}\acsac{The paper completely neglected content scripts, the way that browser extensions can inject JavaScript into the visited pages and extract information via an AJAX request directly from there. Since this is declared in the manifest and there is no API to call from the extension, it is most likely that this method completely bypasses the RNN model and Chrome API calls usage as features to detect maliciousness, rendering the whole approach problematic}
%However, even when such network requests are not captured in the Chrome API call logs, we would still capture extension operations that seek to access and store sensitive information (using Chrome API calls) before sending it to a remote server. 
\end{itemize}

defense_priorwork.tex
\section{Automatically Detecting Spying Extensions} 
\label{sec:detection}
\noindent In this section, we explore the use of supervised machine learning to automatically detect spying extensions. We investigate effectiveness of prior approaches, before proposing a new detection scheme that performs better. 
%\acsac{Section 5.1 presents a comparative analysis of a combination of ML algorithms and features. This comparative analysis is an interesting contribution. However, it does a poor job in motivating the need of using RNN and API call sequences.}

%\textcolor{blue}{
\subsection{Training and Evaluation Setup}
\noindent We begin by building a dataset of spying and benign (non-spying) extensions which can be used to train and evaluate ML classifers. Below, we discuss the positive (spying) and negative (benign) samples used in the ML pipeline.

\subsubsectitle{Positive class. } We use previously identified 207 spying extensions (in Section~\ref{sec:dataset}).\footnote{Remaining 11 extensions (out of 218) were taken down at the time of this analysis, and thus could not be included.}

\subsubsectitle{Negative class. } We use observations from Section~\ref{sec:analysis} to identify benign extensions. \textit{First}, we include 10,131 extensions that do not request any of the permissions misused by spying extensions to access, store and send user information (Table~\ref{tab:infotrack}). \textit{Second,} we include 11,235 extensions that do not make any network requests. These extensions might access user information, or perform other browser operations, but do not make network requests. \textit{Lastly,} we add 831 extensions that were marked as not spying in our manual investigation (Section~\ref{sec:dataset}). Note that these 831 extensions add diversity to the benign class because they were initially shortlisted as supsicious, but verified as benign on manual investigation. In total, we identify 16,785 unique benign extensions.

%(manually annotated which belong to the set of suspicious extensions from our analysis in Section~\ref{sec:dataset}, but are actually verified to be benign.}

%\textcolor{blue}{
%We further use our observations from Section~\ref{sec:analysis} to identify 16,785 benign extensions. According to our definition of spying, an extension should necessarily access user information. We previously found that certain permissions are needed by spying extensions to access user information (Table~\ref{tab:infotrack}). Therefore, as first step we identify 10,131 extensions on Chrome Web Store which do not ask for any of these permissions, and add them to the benign set of extensions. Note that these extensions might still be using other browser API calls and making network requests. The second necessary condition for an extension to be spying is that it should make network requests. We leverage the logs generated from dynamic run of extensions and identify 11,235 extensions which do not make any network request; we add these extensions to the benign dataset. These extensions might access user information, or perform other browser operations, but will not make any network requests. To further increase the quality of benign dataset, we add 831 extensions manually annotated which belong to the set of suspicious extensions from our analysis in Section~\ref{sec:dataset}, but are actually verified to be benign.}
 
%\textcolor{blue}{
%To reduce the imbalance of the spying and benign datasets
To reduce the high class imbalance, we use a 1:5 ratio of positive and negative class and repeat our training/validation experiments with different samples of benign extensions. We randomly choose three non-overlapping samples from the benign dataset, each of size 1,035 extensions. We report average precision (percentage of detected extensions that are spying) and recall (percentage of spying extensions that are detected) over the three runs of the experiment, based on 5-fold cross validation.
%, amounting to 3,105 extensions in our negative class.
%\textcolor{blue}{For training the model, we use 1:5 ratio of the positive and negative class with 207 spying extensions and 1,035 benign extensions for a single training instance. We repeat the experiment three times with a different random sample of benign extension to avoid bias. We report average precision and recall of the positive class (spying extensions) over the three runs of the experiment, based on 5-fold cross validation.}

%\footnote{In practice, we observe that such a reduced imbalance ratio (1:5) provides better performance when tested in-the-wild (Section~\ref{}).}
%}

\subsection{Using Prior Work} \label{subsec:prior}
Prior work used machine learning to automatically detect malicious extensions---a broader class of harmful extensions including those that engage in ad manipulation and social network abuse~\cite{jagpal2015trends}. In this section, we first assess if we can use a similar approach for detecting spying extensions.

\subsubsectitle{Feature Engineering. }Prior work by Jagpal \textit{et al.}~\cite{jagpal2015trends} takes significant effort to carefully select and model an exhaustive set of features. We begin by extracting a similar set of features to detect spying extensions. All the features are described in detail in Table~\ref{tab:feat-desc}. Note that our feature set includes all the features (whenever available)\footnote{For example, WoT reputation score of remote URL will be absent for extensions which do not make a query to an external URL.} used in prior work on detecting malicious browser extensions~\cite{jagpal2015trends}. Features are broadly divided into two categories---static and dynamic.
\begin{enumerate}[leftmargin=*]
\item \textit{Static Features: } These features include permissions listed in the manifest file of extensions (F1), signatures extracted from the source code of extensions (F3) and meta-information like the number of users, reviews, ratings, etc. (F6). Static features provide a rich insight into the functionality and structure of extensions.

\item \textit{Dynamic Features: } These features capture the traits of an extension when it is actively running on the client-side. Every extension is run in a controlled environment (using the same workload used in Section~\ref{sec:dataset}) to record client-side changes (F4) and network behavior (F5) along with the Chrome API calls made by the extension (F2). 
%All of these dynamic features have been used in prior research to detect malicious extensions. 
\end{enumerate}

\begin{table*}[t]
\centering
%\small
\begin{tabular}{@{}lll@{}}
\toprule
                    & Feature Set                          & Feature Description                                                                                                                  \\ \midrule
\multirow{1}{*}{F1} & \multirow{1}{*}{Permission}          & \textit{Permissions:} One-hot vector for manifest permissions \\ \midrule

\multirow{1}{*}{F2} & \multirow{1}{*}{Chrome API Calls}    & \textit{API Call:} One-hot vector for invoked Chrome API calls    \\ \midrule
%                    &                                      & \textit{Sequence:} One-hot vector for Chrome API call bigrams \& trigrams \\ \midrule %Vector with tuples of size=2 and 3 denoting the presence of sequence of chrome API calls made                     \\ \midrule
\multirow{2}{*}{F3} & \multirow{2}{*}{JavaScript Based}    & \textit{Eval:} Boolean val. for presence of eval function used in source code                                            \\
                    &                                      & \textit{base64:} Boolean val. for presence of base64 obfuscation                                                 \\ \midrule
\multirow{4}{*}{F4} & \multirow{4}{*}{Client Side Storage} & \textit{Cookies:} Number of cookie values changes                                                   \\
                    &                                      & \textit{Storage:} Number of localstorage changes                                     \\
                    &                                      & \textit{URL in Cookies:} Boolean val. for presence of URL in cookies                                                                  \\
                    &                                      & \textit{URL in Storage:} Boolean val. for presence of URL in localstorage                                                  \\ \midrule
\multirow{5}{*}{F5} & \multirow{5}{*}{Network Log}         & \textit{XML HTTP:} Number of XHR calls made by the extension                                                                                  \\
                    &                                      & \textit{GET:} Number of GET queries invoked by the extension                                                                                  \\
                    &                                      & \textit{POST:} Number of POST queries by the extension                                                                                        \\
                    %&                                      & \textit{Remote URL:} One-hot vector for request to remote URL \\ %A binary value denoting whether a remote URL other than benign URLs in plain run is present                              \\
                    &                                      & \textit{WoT:} Crowd-sourced reputation of remote URL\\ \midrule %Crowdsourced reputation of the remote URL (if any)                                                                              \\ \midrule
\multirow{2}{*}{F6} & \multirow{2}{*}{Others}              & \textit{Filename Match:} One-hot vector for suspicious filenames                       \\
                    &                                      & \textit{Metadata:} Rating, number of reviews, number of users                                                              \\ \bottomrule 
\end{tabular}
\caption{Features used for automated detection of spying extensions.} %\bimal{What do you mean by change of cookies or localstorage? how is it captured?}
\label{tab:feat-desc}
\end{table*}
%\vspace{-0.25cm}

\begin{table*}
\centering
\begin{tabular}{l|l|c|l|c|l|c|l|c|l|c|l|c}
\hline
\multirow{2}{*}{Features} & \multicolumn{2}{p{1.8cm}}{\textbf{LR (used in prior work)}} & \multicolumn{2}{|p{1.8cm}}{DecisionTree} & \multicolumn{2}{|p{2.3cm}}{Random Forest} & \multicolumn{2}{|p{1.9cm}}{SVM (rbf)} & \multicolumn{2}{|p{1.9cm}}{Adaboost} & \multicolumn{2}{|p{2.3cm}}{Neural Network} \\ \cline{2-13} 
                          & P        & R	& P        & R        & P         & R        & P       & R      & P      & R      & P         & R        \\ \cline{1-13}
F1                        & 9.10 & 12.43 & 9.17             & 10.18           & 13.27              & 16.02         & 13.92            & 15.68       & 14.87          & 16.21       & 65.32             & 69.87          \\
F2                        & 18.12 & 16.23 & 17.92            & 13.22         & 24.89             & 25.13         & 25.27           & 25.83       & 26.21          & 24.93       & \textbf{72.04}             & \textbf{75.20}         \\
F3                        & 18.00 & 16.01 & 17.35            & 16.72         & 22.16             & 21.12         & 16.22           & 35.11       & 17.16          & 31.81       & 64.81             & 61.23         \\
F4                        & 15.28 & 18.15 & 15.15            & 17.13         & 15.06             & 19.02         & 17.32           & 23.92       & 20.82          & 32.31       & 64.19             & 61.11         \\
F5                        & 15.09 & 14.51 & 18.09            & 14.08         & 22.8             & 20.15         & 15.12           & 31.99       & 24.83          & 25.15       & 67.09             & 64.28         \\
F6                        & 18.18 & 19.44 & 20.35            & 19.81         & 22.18             & 19.92         & 14.27            & 15.81       & 22.30          & 17.17       & 65.21             & 64.12         \\
All Feats                 & \textbf{22.35} & \textbf{24.18} & 21.73            & 20.19         & 23.96             & 23.99         & 24.83           & 26.79       & 30.03          & 32.32       & \textbf{78.12}             & \textbf{80.32}         \\ \hline
\end{tabular}
\caption{{P(=Precision) and R(=Recall) in \% for detecting spying extensions using machine learning classification}}
\label{tab:ml}
\end{table*}
%\vspace{-0.25cm}

\subsubsectitle{ML Classifiers. } In addition to using the classifier used by Jagpal \textit{et al.}, which is Logistic Regression (LR) with L1 regularization, we experiment with a variety of other high performing classifier families. We include Decision Trees, Random Forest, Adaboost (an ensemble method using Random Forest as the base estimator), SVM (with an RBF kernel) and a Neural Network. For the Neural Network, we use an architecture with a single hidden layer having 100 neurons and use stochastic gradient descent with a reLU activation function. We also use L2 regularization with a high penalty value, $\alpha = 1.0$ to limit overfitting. 

%We train these various classifier models using our 
%\subsubsectitle{Evaluation Dataset. }\textcolor{blue}{Note that our dataset is highly imbalanced with 218 spying extensions. Therefore, to reduce the imbalance, we use a 1:5 ratio of positive and negative class datasets for training. We then repeat the experiment 5 times with different random samples of the negative class. The labeled training dataset includes 218 spying extensions (as positive class) and a random sample of 1,090 extensions from 43,303 all other Chrome Web Store extensions (as negative class).} We acknowledge the limitation that the negative class may contain yet undetected spying extensions, and is not guaranteed to be a clean set. However, prior work estimated that a significant majority of extensions in the negative class are not malicious (estimated percentage of malicious extensions is around 0.27\%~\cite{kapravelos2014hulk}). We use the same dataset for evaluating existing techniques and our new defense approach. 

%Note that our dataset set is highly imbalanced and thus reflects the true imbalance ratio a service provider might encounter when deploying a classifier for identifying spying extensions in the Chrome store. High imbalance in the training set makes our classification problem even more challenging. 


%\raid{Section three claims to establish ground truth. The term ground truth implies that the true labels for all samples are known. Unfortunately, the presented mechanism does in no way instill any confidence into the correctness, particularly for the large and sparsely analyzed set of benign extensions.} \textcolor{blue}{For our study, we identify spying extensions' true positive dataset using the methodology described below. However, we do not identify a set of benign extensions for the negative class because of the complexity to successfully determine spying behavior of an extension. Instead, we consider all the extensions apart from the identified true positive to be in our negative class.} \anu{We can further add in the evaluation section that cleaning the negative class is only going to improve our results}



\subsubsectitle{Detection Performance. }
%Detection performance is evaluated using precision (percentage of detected extensions that are spying) and recall (percentage of spying extensions that are detected). We compute average precision and recall using 5-fold cross validation. 
Precision and recall values for the spying class are reported in Table~\ref{tab:ml}. LR-based classifier used by Japgpal \textit{et al.} performs poorly over the entire feature set yielding very low precision and recall of 22.35\% and 24.18\%. Thus this technique based on prior work is ineffective against spying extensions.

Except Neural Network, all other classifiers also yield low detection performance. Neural Network using all features provides the highest precision of 78.12\%, and a recall of 80.32\%. More importantly, among the different feature categories, we obtain the highest classification performance with category F2, which are features based on Chrome API calls. Thus there is scope for improving detection performance, if we can better leverage the Chrome API call feature category using a class of Neural Networks better suited for learning sequential data. We investigate this further in the next section. 



%We make two main observations. \textit{First}, the classification performance is low across all classifiers. Using Logistic Regression (as used in ~\cite{jagpal2015trends}) over the entire feature set yields very low precision and recall of 22.35\% and 24.18\%. Neural Network using all features provides the highest precision of 78.12\% (as compared to 96\% for malicious extensions in~\cite{jagpal2015trends}), and a recall of 80.32\%. This shows that existing methods to detect malicious extensions work poorly for detecting spying extensions.

%\textit{Second}, among the different feature categories, we obtain the highest classification performance with category F2, which are features based on Chrome API calls. Thus there is scope for improving detection performance, if we can better leverage the Chrome API call feature category. We investigate this further in the next section. 


%\raid{The initial classification results are quite disappointing, and they appear to be much lower than results reported in [12]. In fact, [12] reports an overall recall and precision of 96\% and 81\%, respectively (see Sec.6.2 of that paper), though precision/recall values actually vary significantly in time}

% \raid{The approach feels a little incremental. The features are not novel, but are applied on a new machine learning algorithm.}

discussion.tex
\newcommand{\para}[1]{\vskip0.075in\noindent {\bf{#1}}}
% \renewcommand{\paragraph}[1]{\vskip0.075in\noindent {\bf{#1}}}

\section{Discussion: Defense at the Edge}
\label{sec:edge}
% \begin{itemize}
% \item To write about possible framework which can be in-built within Chrome based on sequence learning using API calls
% \item We further show that our model can be used in real-time and propose the effective length of API sequence needed by our model for an effective detection of spying extensions.
% \item We find out that using our proposed technique, spying extensions can be discovered with a high precision of 88.96\% by just seeing an average sequence length of 210 API calls.
% \item client-side deployment can be done using a light weight JavaScript based ML model
% \item the deployed framework can keep listening to API calls made by the extension and use the sequence for an early detection of spying behavior
% \end{itemize}
Usually browser providers (like Google, Mozilla) detect malicious extensions by running the extensions in a controlled environment~\cite{jagpal2015trends}, which is also possible with our detection scheme. In this section, we discuss the potential for an alternative approach of pushing the detection to the edge at the user's browser.

%In Section~\ref{sec:detection}, we have shown that API call sequence is the most prominent feature for building spying extension classifiers. We obtain an extension's API call sequence by running the extension against our customized workload in a sandbox environment. However this method may be limited in triggering spying behaviors of extensions. In this section, we discuss a client-side model that pushes the detection to user's browser.

% \para{Decentralized detection}
% Argument for pushing the detection to the edge
% -> Privacy is a personal preference. People has different privacy awareness and privacy sensitivity level.
% -> Spying behavior may be triggered by obscure usage pattern, which centralized solution may not discover.
%   -> Centralized solution needs to collect usage pattern (API call sequences, web page traces etc.) for building detection workload. API calls are sensitive data, user may not want to share it to the central solution.
%   -> Centralized solution is hard to rely on global data (e.g., user reviews, ratings, number of installs), which is a poor signal for building a spying extensions classifier as we have shown in previous sections.
% -> Detecting spying extension on the browser push the privacy protection front line to the edge. Users can get notify of spying behaviors from their extensions even the extensions are new (have very little installs)

% Draw back
% -> Performance impact (constant monitoring API calls) (CPU, Memory, energy drain on mobile devices)
% -> Challenges in building a small classification model for the browser (Rich Caruana, Model Compression KDD 2006)

\subsubsectitle{Deployment Model. } We envision a deployment scenario where our pre-trained detection scheme is available on the user's browser as another extension.
In this model, the detection extension needs to be able to monitor API calls of other extensions. In the case of Chrome, this monitoring capability is only available to whitelisted extensions (e.g., Chrome Apps \& Extensions Developer Tool). 
% In the case of Chrome, Google can incorporate the detection tool into their existing Extension Developer Tool. 
The detection tool can analyze the API calls made by any extension on the user's browser (in real time) and alert the user if it detects spying behavior. 
%\raid{The scenario depicted in Sec.6 is only hypothetical. Previously proposed approaches could also be used in the browser directly. The problem is overhead, and the approach proposed in this paper does not seem to solve the overhead problem.}

\subsubsectitle{Benefits of Pushing Detection to the Edge. }  We discuss three key benefits.
\begin{itemize}[leftmargin=*]
\item \textit{Enable detection based on user generated workload.} Spying behavior may be triggered by certain types of usage patterns (e.g., stealing social media access tokens when user logs into a social media site). Client-side detection increases the possibility of covering these cases, making it harder for spying extensions to evade detection. 
\item \textit{Inform privacy leak to users. } In practice, users may have different expectations of privacy. Client-side detection allows users to understand the privacy risk of using an extension for a certain task, helping them to make a decision to uninstall or keep the extension. 
\item \textit{Early detection of spying behavior. } 
% 
% Some spying extensions in our dataset have been taken down by Google after being available on the Chrome store for more than six months. During this period, the entire Chrome user base is exposed to privacy risks of such extensions. Our approach can enable early detection of spying behavior, thus limiting the privacy risk. 
% 
When spying extensions manage to evade centralized detections (such as Chrome Web Store), client-side dection provides a second chance to detect them in the early stage. The question in this case is how quickly can a client-side dection method identify spying extensions.
We perform an experiment to understand the amount of user activity (or API calls) required to detect spying extensions with high precision and recall. For each extension, we apply a workload that includes visiting 10 websites in sequence, and triggering on average 9 different browser events (\eg mouse movement, clicking, and form fill) per site. We observe that our approach can detect extensions with high precision (90.02\%) and recall (93.31\%), after analyzing only 28 browser events (or 189 API calls), which is just 20\% of the entire workload we used in the previous sections. This result illustrates the potential for early client-side detection. 
%\raid{At which point can the classifier make a decision? How long of a API call sequence does it need?}
%all the spying want to explore how much user interaction on the browser does the classifier need to make prediction with high precision. Since user behavior is hard to model, we simplify the experiment by analyzing classification precision with varying length of API call sequence while running the extension in a controlled environment with previously described workload. We observe highest precision (86.8\%) at an average sequence length of 211 API calls (with a recall of 78.3\%). To further investigate, we find that on an average, in our workload, 213 API calls are made after 32 browser events (like mouse moving, clicking, scrolling and following links etc.). These results show that we are able to detect spying extensions with high precision just after a small amount of browser actions. This is a promising result to shows the viability of an early client-side detection mechanism. \anu{removed figure, was taking too much space}   
\end{itemize}

%Compared to detecting extensions with a predefined customized workload, running the classifier on the user's browser provides additional benefits. First, it enables detection of spying behavior on API call sequence generated from user workload. Since spying behavior may be triggered by obscure usage pattern (e.g., spying extensions may be active on a particular website on a specific date), client-side detection increases the possibility of covering these cases, making spying extensions harder to evade detection. Second, users may have different privacy preferences. Client-side detection allows users to understand what privacy information is at risk, helping them to make decision on whether or not to keep using the extension. However, client-side detection requires additional computation resources, which may have performance impact on user's browsing experience. There are a few ways to reduce the impact. For one, client could run a smaller model that takes in less computation power~\cite{bucilua2006model}. We leave this to the future work.
%Third, spying extension found by one user can potentially help other users if the user shares the detection result.


%\begin{figure}[h]
%\includegraphics[width=0.45\textwidth]{sequence_length_eval}
%\caption{Precision at different API sequene length. We achieve the maximum precision at a sequence of 211 API calls, or after 32 browser action simulations. The vertical lines mark the average length of API calls and number of browser actions for each workload segment spanning across different websites. AA: This is old figure for unbalanced workload. Need to replace this}
%\label{fig:sequence_length_eval}
%\end{figure}

%\paragraph{Key challenge. } 
A client-side detection scheme would incur additional computational overhead if we run a full fledged RNN classifier on the browser and can impact the user's browsing experience. However, the browser provider can use ML model compression techniques to build a lightweight high performing ML scheme on the client-side~\cite{bucilua2006model}. Recent studies have shown possibility of deep neural network models on mobile processors with high performance while consuming very low power~\cite{jin2014efficient}. Researchers have also explored light-weight machine learning implementations for web browsers~\cite{meeds2015mlitb}. More recently, Google and Facebook released lightweight real-time deep learning frameworks for mobile platforms~\cite{TensorFlow:2017jf}\cite{Facebook:2016fz}. Therefore, a client-side defense looks promising, given the recent advances in optimized deep learning runtimes. 
%There exist JavaScript based machine learning and deep learning libraries, like Synaptic and ConvNetJS for training entirely in web browser environment~\cite{Cazala:2015qp, karpathy2014convnetjs}. }


%\paragraph{Early detection of spying behavior: } 
%To understand the effectiveness of client-side detection, we want to explore how much user interaction on the browser does the classifier need to make prediction with high precision. Since user behavior is hard to model, we simplify the experiment by analyzing classification precision with varying length of API call sequence while running the extension in a controlled environment with previously described workload. We observe highest precision (86.8\%) at an average sequence length of 211 API calls (with a recall of 78.3\%). To further investigate, we find that on an average, in our workload, 213 API calls are made after 32 browser events (like mouse moving, clicking, scrolling and following links etc.). %Figure~\ref{fig:sequence_length_eval} presents the precision and recall values at various length of API call sequence and the corresponding number of browser actions performed. The vertical lines mark the average length of API calls and number of browser actions for each workload segment spanning across different websites. 


%Figure~\ref{fig:sequence_length_eval} presents the results from our customized web browsing workload used in previous sections. Our workload simulates simple user interactions on the web (e.g., mouse moving, clicking, scrolling and following links). Over the 10 different workloads (i.e., different websites and user behavior simulations), the average browsing time is seven and a half minutes, in which and the average length of API call sequence is 202. 

%We observe that the maximum precious is achieved on 210 API calls. 
%Although our workload is an approximation of user activities on the browser, our experiment still shows a promising results of what we can achieve with the client-side detection. 



introduction.tex
%!TEX root = main.tex
%\vspace{-0.3cm}
\section{Introduction}
%\vspace{-0.25cm}

Many websites today rely on advertising to sustain their services.
%, and this has led to the growth of the online advertising industry. 
Online ad platforms have developed sophisticated user tracking systems to capture user behavior across websites in order to generate highly personalized ads. Several studies have been conducted to understand \textit{third-party user tracking on the web}, where a third-party entity (like social media widget), embedded by the first-party site the user visits, can log the presence and other activities of the user on that site~\cite{englehardt2016online}\cite{roesner2012detecting}. Unfortunately, user tracking has reached to a state where even privileged software running on a user's browser is stealing user information~\cite{starovextended}. In this work, we take a step towards understanding and defending against this new type of privacy risk---{\em browser extensions that spy on user information}.%{\em user spying} (or spying for short) by {\em browser extensions}.

A browser extension is an add-on software that enhances functionality of the browser. We consider a spying extension as one which accesses user information (eg browsing history) and intentionally sends the information to third-party domains, when its core functionality does not require such information communication (Section~\ref{sec:dataset}). Such information theft raises a huge privacy risk for the user. For example, a user's browsing history can contain URLs referencing private documents (eg Google docs) or the URL parameters can reveal privacy sensitive activities performed by the user on a site (eg online e-commerce transactions, password-based authentication). Moreover, any stolen information can be misused in numerous ways. The information could be used to launch targeted attacks against the user~\cite{kapravelos2014hulk}, or be traded in underground marketplaces for profit~\cite{Lifehacker:pi}.

%or to launch targeted attacks against the user~\cite{X}, to set-up price discrimination policies on e-commerce sites~\cite{X}, or be traded in underground marketplaces~\cite{X}.


%Once stolen, the user has no control over their information. 
%For example, a browsing history can contain URLs referencing private documents (e.g., Google docs) or the parameters of the URL can reveal various privacy sensitive activities performed by the user on a site (e.g., online e-commerce transactions, password-based authentication). 
%Further, the remote entity who collects the personal information can potentially sell it for profit.
%Information about browsing history can also provide access to sensitive and private documents on services like Google Drive, Dropbox and Pastebin where a document can be accessed by anyone with a link to the document. Once stolen, the user has no control over how this data is further used. Browsing history may not only expose users to more targetted advertising, but can also lead to differential services and price discrimination on various e-commerce sites~\cite{hannak2014measuring}. Browsing history combined with geolocation and IP address information could be used by governments to track political dissidents or by other entities interested in launching targeted attacks against the user~\cite{marczak2014governments}. 





%Unfortunately, user tracking, which started as a means to enable better personalized advertising, has reached to a state where even privileged software \liang{need citation} running on a user's browser is stealing user information. 
%capturing user information and sending it to remote servers (untrusted by the user),.

%Spying violates user privacy by collecting sensitive personal information without consent from the user. This information can later be used towards targeted attacks, or can be traded in underground markets. 

%Unfortunately, user tracking, which started as a means to enable better personalized advertising, has reached to a state where even privileged software running on a user's browser is capturing sensitive personal information and sending it to remote servers (untrusted by the user). \anu{Can we get rid of this paragraph expect the first sentence? Somebody may argue that giving permission to access active tabs is indeed consent to access any page visited by the user}

%But one might still wonder why spying by browser extensions deserves special attention, when studies have mainly focused on third-party tracking on the web. First, it should be noted that 
%\google{Extensions are an important aspect of a browser. Starov \textit{et al.} have shown that 23\% of top 10k Chrome extensions are fingerprintable, and hence can uniquely identify a user's identity by just the set of extensions used by him~\cite{starovxhound}.} 
Compared to other types of user tracking, spying by browser extensions deserves special attention for two reasons. \textit{First}, unlike web pages, browser extensions persist through the entire browser life cycle, and can access in-depth user browsing activities across all websites. By making privileged API calls to the browser, extensions can access the user's browsing history, current open tabs, record keyboard inputs and more. On the other hand, third-party web trackers can only track users on sites where they are embedded by the publisher, and thus obtain a ``limited'' or fragmented view of a user's entire browsing behavior. \textit{Second}, extensions are available on most popular browsers (eg Chrome, Safari, and Firefox) and have 510 million cumulative installs (in Chrome). However, not all extensions are benign, thus exposing the user base of a browser platform to huge privacy risks. 

 
%Second, extensions are easily accessible via browser platform. Most popular browsers today (e.g., Chrome, Safari, and Firefox) have extension store where users can shop for extensions to add functionality to the browser. Download and install extensions is as easy as browsing websites. However not all extensions are benign. Users obtain extension information (e.g., extension screenshots, text description, and reviews by other users) from the store. There is no ways for users to track extension behavior after the extension has been installed.
% 
% First, it should be noted that today, the browser is the most widely used software and serves as a window to the web. In fact, platforms such as ChromeOS further reinforce the concept that ``your browser is your operating system"~\cite{reis2009web}. Most popular browsers (e.g., Chrome, Safari, and Firefox) provide an \textit{extension platform} that enables third-party software to reside on the browser to improve its core functionality. For example, the Chrome Web Store has a very popular extension platform hosting over 43,000 extensions, with some individual extensions having over 9 million users. 
%These extensions enable a wide range of additional useful functionality such finding better deals in online marketplaces~\cite{Honey:pd}, and checking spelling and grammar~\cite{Grammarly:qd}. 
% Third, not all extensions are benign. Extensions can acquire a significant amount of (unwanted) privileges that would allow them to capture a ``complete'' online browsing footprint of a user, ranging from capturing website visits, mouse movements/clicks, and keypresses as well as access to various browser storage mechanisms. Browsing behavior can potentially be captured across multiple devices of the user as well (as long as the same browser and extension is used across devices). In comparison, third-party web trackers can only track users on sites where they are embedded by the publisher, and thus obtain a ``limited'' or fragmented view of a user's entire browsing behavior.

%Recently, a popular extension - Web of Trust was taken down from Firefox and Chrome after reported to be collecting and selling user data which could be deanonymized~\cite{}. 
%Lastly, unlike extensions, third-party web trackers can only track users on sites where they are embedded by the publisher, and thus obtain a ``limited'' or fragmented view of a user's entire browsing behavior. Extensions enabled on a browser can capture the complete browsing behavior of a user across any site and potentially across multiple devices of the user (as long as the same browser and extension is used across devices).

%In this work, we present an in-depth empirical study of 218 spying extensions on the Chrome Web Store~\footnote{Chrome Web Store~\url{https://chrome.google.com/webstore/category/extensions}} and identify techniques to automatically detect such extensions.

%Prior work on malicious browser extensions has mostly studied ad manipulation~\cite{xing2015understanding}, and online social network (OSN) abuse~\cite{jagpal2015trends} in detail. Most recently, XXX et al.~\cite{starovextended} investigated Chrome extensions that accidentally or intentionally leak user information to third-party domains. Unlike our work, XXX et al. does not present a detailed 
%A recent study has shown accidental as well as intentional leakage of user information by 6.3\% of top 10k Chrome extensions~\cite{starovextended}. 


%From our investigation, we also observe that none of these extensions would need to collect these information for its functionality. 
 

%or even enable a targeted attack (e.g., spear phishing attack) against the user by leveraging the personal information.

% The first challenge to conduct this study is to identify a large sample of spying extensions. 
%The first challenge of conducting this study is to obtain a large sample of spying extensions. 
Identifying spying behavior is challenging. Given an extension, automatically identifying the flow of sensitive user information is a non-trivial task~\cite{bandhakavi2011vetting}. Moreover, we observe spying extensions that obfuscate user information before sending it to remote servers, and those that switch between spying and non-spying states during their life-time (eg using remote Command-and-Control triggers). Such behavior further complicates the identification.

To bootstrap our analysis, we resort to expert manual investigation of behavioral logs (traces of network, storage, and browser API requests made by an extension) of extensions to identify spying behavior (Section~\ref{sec:dataset}). 
%Behavioral logs are automatically generated by applying a realistic workload under a controlled execution environment. 
To reduce manual effort, we apply several heuristics to automatically short-list a candidate set of possible spying extensions, among all the 43,521 extensions on the Chrome store. After manually investigating over 1,000 extensions in the candidate set, we discover 218 spying extensions. This dataset provides an opportunity to better understand spying behavior and to build a defense scheme that can automatically detect spying extensions (ie without any manual effort). 

We start by uncovering the modus operandi of spying extensions and analyze their characteristics (Section~\ref{sec:analysis}). Spying extensions steal browsing history, social media access tokens, IP address and geolocation of users. Surprisingly, spying extensions are as popular (based on user base) and have similar ratings as other extensions on the Chrome store. We suspect that users are mostly unaware of the spying behavior as only 12 out of 218 extensions receive reports of any suspicious behavior from users. 
%Moreover, even after 8 months since we collected our data, Google had only removed 3 (out of 218) extensions from the Chrome store.

Next, we focus on automatically detecting spying extensions. While a lot of prior work has focused on HoneyPages to trigger and catch malicious behavior by extensions~\cite{kapravelos2014hulk}, and information flow control based approaches~\cite{bandhakavi2011vetting}\cite{dhawan2009analyzing}\cite{jang2010empirical}; we take an alternate approach of leveraging the recent advances in machine learning (ML) for detection. Practicality and effectiveness of ML-based defenses has encouraged the industry (\eg Google) to also adopt such approaches to protect against malicious extensions~\cite{jagpal2015trends}. 

As is the case with any ML-based defense, we start by first identifying a robust feature. Prior work on detecting malicious extensions relies on extensive feature engineering to craft a large number of features (\eg features  based on extension meta-data, source code, and network, storage and API requests)~\cite{jagpal2015trends}. Surprisingly, our analysis reveals that most of the existing features are ineffective in detecting spying extensions (Section~\ref{subsec:prior}). Instead, browser API calls modeled as sequential data provides the highest predictive power, thus obviating the need for complex hand-crafted features. We further discuss the benefits and robustness aspects of using API call sequence for detection. 
%\anu{maybe bring related work and our definition of spying much before instead of it being the last section.}

However, browser API call sequences can contain complex sequential patterns which makes traditional n-gram based sequence classification approaches ineffective in our case. We observe that recent developments in a class of deep neural networks called Recurrent Neural Networks (RNN) are well suited for our scenario. We present an RNN based detection scheme that is capable of learning sophisticated patterns in API call sequences~\cite{de2015survey}. An in-depth evaluation of our RNN based approach shows that it outperforms traditional ML schemes and achieves a high precision (90.02\%) and recall (93.31\%) in detecting spying extensions (Section~\ref{subsec:rnn}). Further, our RNN-based classifier additionally identified 65 previously unknown spying extensions. Finally, we discuss deployment aspects of our approach. While our scheme can be used in a centralized setting by analyzing the extensions in a controlled environment, we also explore the potential for pushing the detection to the edge at user's browser (Section~\ref{sec:edge}).

%we find that an RNN based model is capable of learning sophisticated patterns in API call sequences. Our RNN based approach outperforms traditional ML schemes and achieves a high precision (88.96\%) and recall (83.25\%) in detecting spying extensions.

%Traditional n-gram based sequence classification approaches have 

%Using this dataset of spying extensions, we make the following three major contributions:

%over 1,000 extensionsManually investigating over 43,000 extensions
%In this paper, we solve the challenge of identifying a large sample of spying extensions from the Chrome Extension Store. 
%Using expert manual investigation and semi-automated heuristic based techniques, we analyze 43,000 extensions and identify a dataset of 218 spying extensions. In light of this, we make three major contributions as follow:

%\begin{itemize}
%	\item \emph{Uncover the modus operandi of spying extensions and analyze their characteristics (Section~\ref{sec:analysis})}: We present an in-depth analysis of the characteristics and operational aspects of spying extensions. Spying extensions steal browsing history, social media access tokens, IP address and geolocation of users. Surprisingly, spying extensions are as popular (based on user base) and have similar ratings as other extensions on the Chrome store. We suspect that users are mostly unaware of the spying behavior as only 12 out of 218 extensions receive reports of any suspicious behavior from users. Moreover, even after 8 months since we collected our data, Google had only removed 3 (out of 218) extensions from the Chrome store.
%	\item \emph{Identify a robust feature to automatically detect spying extensions (Section~\ref{sec:detection}):} We focus on using a machine learning scheme to automatically detect spying extensions. Prior work on detecting malicious extensions relies on extensive feature engineering to craft a large number of features (\eg features  based on extension meta-data, source code, and network, storage and API requests)~\cite{jagpal2015trends, kapravelos2014hulk}. Our analysis reveals that most of the existing features are ineffective in detecting spying extensions. We find that browser API calls modeled as sequential data provides the highest predictive power, thus obviating the need for complex hand-crafted features. We further discuss the benefits and robustness aspects of using API call sequence for detection.
%	\item \emph{Present a Recurrent Neural Network (RNN) based detection scheme:} Compared to traditional ML schemes, we find that an RNN based model is capable of learning sophisticated patterns in API call sequences. Our RNN based approach outperforms traditional ML schemes and achieves a high precision (88.96\%) and recall (83.25\%) in detecting spying extensions. %
%	\google{anu: We do not talk about robustness here in the explanation of this contribution} 
%\end{itemize}


%Next, we present an in-depth analysis of these spying extensions (Section~\ref{sec:analysis}) to understand the different types of sensitive information being stolen as well as their spying behavior. Our analysis shows that users are mostly unaware of the spying behavior of these extensions. In fact, the 218 spying extensions receive over 2.4 million cumulative installs in the Chrome store.

%Finally, we investigate the potential for automatically detecting these spying extensions using machine learning schemes (Section~\ref{sec:detection}). We develop a comprehensive set of features for the classification problem, and observe that features based on communication end points with the browser (Chrome API) provide the highest accuracy. We further show that  we can achieve high precision and recall using only API call sequences various browser API endpoints. We use an LSTM based model for sequence classification to detect spying extensions. Overall, our work highlights the importance and feasibility of detecting and limiting spying within the browser.




ms.tex

%% bare_conf_compsoc.tex
%% V1.4b
%% 2015/08/26
%% by Michael Shell
%% See:
%% http://www.michaelshell.org/
%% for current contact information.
%%
%% This is a skeleton file demonstrating the use of IEEEtran.cls
%% (requires IEEEtran.cls version 1.8b or later) with an IEEE Computer
%% Society conference paper.
%%
%% Support sites:
%% http://www.michaelshell.org/tex/ieeetran/
%% http://www.ctan.org/pkg/ieeetran
%% and
%% http://www.ieee.org/

%%*************************************************************************
%% Legal Notice:
%% This code is offered as-is without any warranty either expressed or
%% implied; without even the implied warranty of MERCHANTABILITY or
%% FITNESS FOR A PARTICULAR PURPOSE! 
%% User assumes all risk.
%% In no event shall the IEEE or any contributor to this code be liable for
%% any damages or losses, including, but not limited to, incidental,
%% consequential, or any other damages, resulting from the use or misuse
%% of any information contained here.
%%
%% All comments are the opinions of their respective authors and are not
%% necessarily endorsed by the IEEE.
%%
%% This work is distributed under the LaTeX Project Public License (LPPL)
%% ( http://www.latex-project.org/ ) version 1.3, and may be freely used,
%% distributed and modified. A copy of the LPPL, version 1.3, is included
%% in the base LaTeX documentation of all distributions of LaTeX released
%% 2003/12/01 or later.
%% Retain all contribution notices and credits.
%% ** Modified files should be clearly indicated as such, including  **
%% ** renaming them and changing author support contact information. **
%%*************************************************************************


% *** Authors should verify (and, if needed, correct) their LaTeX system  ***
% *** with the testflow diagnostic prior to trusting their LaTeX platform ***
% *** with production work. The IEEE's font choices and paper sizes can   ***
% *** trigger bugs that do not appear when using other class files.       ***                          ***
% The testflow support page is at:
% http://www.michaelshell.org/tex/testflow/



\documentclass[compsoc, conference, letterpaper, 10pt, times]{IEEEtran}
% Some/most Computer Society conferences require the compsoc mode option,
% but others may want the standard conference format.
%
% If IEEEtran.cls has not been installed into the LaTeX system files,
% manually specify the path to it like:
% \documentclass[conference,compsoc]{../sty/IEEEtran}


\usepackage{grumble}
\usepackage{subfig}
\usepackage{color}
\usepackage{epsfig,endnotes}
\usepackage{graphicx}
\usepackage{url}
\usepackage{multirow}
\usepackage{booktabs}
\usepackage{amsmath}
\usepackage{balance}
%\graphicspath{ {figs/} }
%\usepackage{titlesec}
\usepackage{enumitem}
%\usepackage{floatrow}
\usepackage{pifont}
\setlist{nosep}
\usepackage{tikz}
\usepackage{float}
\usepackage{balance}
\usepackage[nocompress]{cite}

\newcommand*\circled[1]{%
    \tikz[baseline=(C.base)]\node[draw,circle,thick, inner sep=1pt](C) {#1};
}
%\titlespacing{\section}{0pt}{0.25cm}{0.25cm}
%\titlespacing{\subsection}{0pt}{0.25cm}{0.25cm}
%\titlespacing{\subsubsection}{0pt}{0.25cm}{0.25cm}
%\titlespacing{\paragraph}{0pt}{0.25cm}{0.25cm}

\newcommand{\subsubsecspace}{\vspace{0.05in}}
\newcommand{\xref}[1]{\S\ref{#1}}

\newcommand{\subsubsectitle}[1]{\subsubsecspace\noindent\textbf{#1}}
\newcommand{\eg}{{\em e.g.,\ }}
\newcommand{\ie}{{\em i.e.\ }}
\newcommand{\etc}{{\em etc.}}


% Some very useful LaTeX packages include:
% (uncomment the ones you want to load)


% *** MISC UTILITY PACKAGES ***
%
%\usepackage{ifpdf}
% Heiko Oberdiek's ifpdf.sty is very useful if you need conditional
% compilation based on whether the output is pdf or dvi.
% usage:
% \ifpdf
%   % pdf code
% \else
%   % dvi code
% \fi
% The latest version of ifpdf.sty can be obtained from:
% http://www.ctan.org/pkg/ifpdf
% Also, note that IEEEtran.cls V1.7 and later provides a builtin
% \ifCLASSINFOpdf conditional that works the same way.
% When switching from latex to pdflatex and vice-versa, the compiler may
% have to be run twice to clear warning/error messages.






% *** CITATION PACKAGES ***
%
\ifCLASSOPTIONcompsoc
  % IEEE Computer Society needs nocompress option
  % requires cite.sty v4.0 or later (November 2003)
  \usepackage[nocompress]{cite}
\else
  % normal IEEE
  \usepackage{cite}
\fi
% cite.sty was written by Donald Arseneau
% V1.6 and later of IEEEtran pre-defines the format of the cite.sty package
% \cite{} output to follow that of the IEEE. Loading the cite package will
% result in citation numbers being automatically sorted and properly
% "compressed/ranged". e.g., [1], [9], [2], [7], [5], [6] without using
% cite.sty will become [1], [2], [5]--[7], [9] using cite.sty. cite.sty's
% \cite will automatically add leading space, if needed. Use cite.sty's
% noadjust option (cite.sty V3.8 and later) if you want to turn this off
% such as if a citation ever needs to be enclosed in parenthesis.
% cite.sty is already installed on most LaTeX systems. Be sure and use
% version 5.0 (2009-03-20) and later if using hyperref.sty.
% The latest version can be obtained at:
% http://www.ctan.org/pkg/cite
% The documentation is contained in the cite.sty file itself.
%
% Note that some packages require special options to format as the Computer
% Society requires. In particular, Computer Society  papers do not use
% compressed citation ranges as is done in typical IEEE papers
% (e.g., [1]-[4]). Instead, they list every citation separately in order
% (e.g., [1], [2], [3], [4]). To get the latter we need to load the cite
% package with the nocompress option which is supported by cite.sty v4.0
% and later.





% *** GRAPHICS RELATED PACKAGES ***
%
\ifCLASSINFOpdf
  % \usepackage[pdftex]{graphicx}
  % declare the path(s) where your graphic files are
  % \graphicspath{{../pdf/}{../jpeg/}}
  % and their extensions so you won't have to specify these with
  % every instance of \includegraphics
  % \DeclareGraphicsExtensions{.pdf,.jpeg,.png}
\else
  % or other class option (dvipsone, dvipdf, if not using dvips). graphicx
  % will default to the driver specified in the system graphics.cfg if no
  % driver is specified.
  % \usepackage[dvips]{graphicx}
  % declare the path(s) where your graphic files are
  % \graphicspath{{../eps/}}
  % and their extensions so you won't have to specify these with
  % every instance of \includegraphics
  % \DeclareGraphicsExtensions{.eps}
\fi
% graphicx was written by David Carlisle and Sebastian Rahtz. It is
% required if you want graphics, photos, etc. graphicx.sty is already
% installed on most LaTeX systems. The latest version and documentation
% can be obtained at: 
% http://www.ctan.org/pkg/graphicx
% Another good source of documentation is "Using Imported Graphics in
% LaTeX2e" by Keith Reckdahl which can be found at:
% http://www.ctan.org/pkg/epslatex
%
% latex, and pdflatex in dvi mode, support graphics in encapsulated
% postscript (.eps) format. pdflatex in pdf mode supports graphics
% in .pdf, .jpeg, .png and .mps (metapost) formats. Users should ensure
% that all non-photo figures use a vector format (.eps, .pdf, .mps) and
% not a bitmapped formats (.jpeg, .png). The IEEE frowns on bitmapped formats
% which can result in "jaggedy"/blurry rendering of lines and letters as
% well as large increases in file sizes.
%
% You can find documentation about the pdfTeX application at:
% http://www.tug.org/applications/pdftex





% *** MATH PACKAGES ***
%
%\usepackage{amsmath}
% A popular package from the American Mathematical Society that provides
% many useful and powerful commands for dealing with mathematics.
%
% Note that the amsmath package sets \interdisplaylinepenalty to 10000
% thus preventing page breaks from occurring within multiline equations. Use:
%\interdisplaylinepenalty=2500
% after loading amsmath to restore such page breaks as IEEEtran.cls normally
% does. amsmath.sty is already installed on most LaTeX systems. The latest
% version and documentation can be obtained at:
% http://www.ctan.org/pkg/amsmath





% *** SPECIALIZED LIST PACKAGES ***
%
%\usepackage{algorithmic}
% algorithmic.sty was written by Peter Williams and Rogerio Brito.
% This package provides an algorithmic environment fo describing algorithms.
% You can use the algorithmic environment in-text or within a figure
% environment to provide for a floating algorithm. Do NOT use the algorithm
% floating environment provided by algorithm.sty (by the same authors) or
% algorithm2e.sty (by Christophe Fiorio) as the IEEE does not use dedicated
% algorithm float types and packages that provide these will not provide
% correct IEEE style captions. The latest version and documentation of
% algorithmic.sty can be obtained at:
% http://www.ctan.org/pkg/algorithms
% Also of interest may be the (relatively newer and more customizable)
% algorithmicx.sty package by Szasz Janos:
% http://www.ctan.org/pkg/algorithmicx




% *** ALIGNMENT PACKAGES ***
%
%\usepackage{array}
% Frank Mittelbach's and David Carlisle's array.sty patches and improves
% the standard LaTeX2e array and tabular environments to provide better
% appearance and additional user controls. As the default LaTeX2e table
% generation code is lacking to the point of almost being broken with
% respect to the quality of the end results, all users are strongly
% advised to use an enhanced (at the very least that provided by array.sty)
% set of table tools. array.sty is already installed on most systems. The
% latest version and documentation can be obtained at:
% http://www.ctan.org/pkg/array


% IEEEtran contains the IEEEeqnarray family of commands that can be used to
% generate multiline equations as well as matrices, tables, etc., of high
% quality.




% *** SUBFIGURE PACKAGES ***
%\ifCLASSOPTIONcompsoc
%  \usepackage[caption=false,font=footnotesize,labelfont=sf,textfont=sf]{subfig}
%\else
%  \usepackage[caption=false,font=footnotesize]{subfig}
%\fi
% subfig.sty, written by Steven Douglas Cochran, is the modern replacement
% for subfigure.sty, the latter of which is no longer maintained and is
% incompatible with some LaTeX packages including fixltx2e. However,
% subfig.sty requires and automatically loads Axel Sommerfeldt's caption.sty
% which will override IEEEtran.cls' handling of captions and this will result
% in non-IEEE style figure/table captions. To prevent this problem, be sure
% and invoke subfig.sty's "caption=false" package option (available since
% subfig.sty version 1.3, 2005/06/28) as this is will preserve IEEEtran.cls
% handling of captions.
% Note that the Computer Society format requires a sans serif font rather
% than the serif font used in traditional IEEE formatting and thus the need
% to invoke different subfig.sty package options depending on whether
% compsoc mode has been enabled.
%
% The latest version and documentation of subfig.sty can be obtained at:
% http://www.ctan.org/pkg/subfig




% *** FLOAT PACKAGES ***
%
%\usepackage{fixltx2e}
% fixltx2e, the successor to the earlier fix2col.sty, was written by
% Frank Mittelbach and David Carlisle. This package corrects a few problems
% in the LaTeX2e kernel, the most notable of which is that in current
% LaTeX2e releases, the ordering of single and double column floats is not
% guaranteed to be preserved. Thus, an unpatched LaTeX2e can allow a
% single column figure to be placed prior to an earlier double column
% figure.
% Be aware that LaTeX2e kernels dated 2015 and later have fixltx2e.sty's
% corrections already built into the system in which case a warning will
% be issued if an attempt is made to load fixltx2e.sty as it is no longer
% needed.
% The latest version and documentation can be found at:
% http://www.ctan.org/pkg/fixltx2e


%\usepackage{stfloats}
% stfloats.sty was written by Sigitas Tolusis. This package gives LaTeX2e
% the ability to do double column floats at the bottom of the page as well
% as the top. (e.g., "\begin{figure*}[!b]" is not normally possible in
% LaTeX2e). It also provides a command:
%\fnbelowfloat
% to enable the placement of footnotes below bottom floats (the standard
% LaTeX2e kernel puts them above bottom floats). This is an invasive package
% which rewrites many portions of the LaTeX2e float routines. It may not work
% with other packages that modify the LaTeX2e float routines. The latest
% version and documentation can be obtained at:
% http://www.ctan.org/pkg/stfloats
% Do not use the stfloats baselinefloat ability as the IEEE does not allow
% \baselineskip to stretch. Authors submitting work to the IEEE should note
% that the IEEE rarely uses double column equations and that authors should try
% to avoid such use. Do not be tempted to use the cuted.sty or midfloat.sty
% packages (also by Sigitas Tolusis) as the IEEE does not format its papers in
% such ways.
% Do not attempt to use stfloats with fixltx2e as they are incompatible.
% Instead, use Morten Hogholm'a dblfloatfix which combines the features
% of both fixltx2e and stfloats:
%
% \usepackage{dblfloatfix}
% The latest version can be found at:
% http://www.ctan.org/pkg/dblfloatfix




% *** PDF, URL AND HYPERLINK PACKAGES ***
%
%\usepackage{url}
% url.sty was written by Donald Arseneau. It provides better support for
% handling and breaking URLs. url.sty is already installed on most LaTeX
% systems. The latest version and documentation can be obtained at:
% http://www.ctan.org/pkg/url
% Basically, \url{my_url_here}.




% *** Do not adjust lengths that control margins, column widths, etc. ***
% *** Do not use packages that alter fonts (such as pslatex).         ***
% There should be no need to do such things with IEEEtran.cls V1.6 and later.
% (Unless specifically asked to do so by the journal or conference you plan
% to submit to, of course. )


% correct bad hyphenation here
\hyphenation{op-tical net-works semi-conduc-tor}


\begin{document}
%
% paper title
% Titles are generally capitalized except for words such as a, an, and, as,
% at, but, by, for, in, nor, of, on, or, the, to and up, which are usually
% not capitalized unless they are the first or last word of the title.
% Linebreaks \\ can be used within to get better formatting as desired.
% Do not put math or special symbols in the title.
\title{I Spy with My Little Eye: Analysis and Detection of Spying Browser Extensions}


% author names and affiliations
% use a multiple column layout for up to three different
% affiliations
%\author{Anonymous Submission}
%\IEEEauthorblockA{School of Electrical and\\Computer Engineering\\
%Georgia Institute of Technology\\
%Atlanta, Georgia 30332--0250\\
%Email: http://www.michaelshell.org/contact.html}
%\and
%\IEEEauthorblockN{Homer Simpson}
%\IEEEauthorblockA{Twentieth Century Fox\\
%Springfield, USA\\
%Email: homer@thesimpsons.com}
%\and
%\IEEEauthorblockN{James Kirk\\ and Montgomery Scott}
%\IEEEauthorblockA{Starfleet Academy\\
%San Francisco, California 96678-2391\\
%Telephone: (800) 555--1212\\
%Fax: (888) 555--1212}}

% conference papers do not typically use \thanks and this command
% is locked out in conference mode. If really needed, such as for
% the acknowledgment of grants, issue a \IEEEoverridecommandlockouts
% after \documentclass

% for over three affiliations, or if they all won't fit within the width
% of the page (and note that there is less available width in this regard for
% compsoc conferences compared to traditional conferences), use this
% alternative format:
% 
\author{\IEEEauthorblockN{Anupama Aggarwal\IEEEauthorrefmark{1},
Bimal Viswanath\IEEEauthorrefmark{2},
Liang Zhang\IEEEauthorrefmark{3}, 
Saravana Kumar\IEEEauthorrefmark{4} 
Ayush Shah\IEEEauthorrefmark{1} and
Ponnurangam Kumaraguru\IEEEauthorrefmark{1}}
\IEEEauthorblockA{\IEEEauthorrefmark{1}IIIT - Delhi, India, email: anupamaa@iiitd.ac.in, ayush13027@iiitd.ac.in, pk@iiitd.ac.in}
\IEEEauthorblockA{\IEEEauthorrefmark{2}UC Santa Barbara, email: viswanath@ucsb.edu}
\IEEEauthorblockA{\IEEEauthorrefmark{3}Northeastern University, email: liang@ccs.neu.edu}
\IEEEauthorblockA{\IEEEauthorrefmark{4}CEG, Guindy, India, email: savkumar90@gmail.com}}




% use for special paper notices
%\IEEEspecialpapernotice{(Invited Paper)}




% make the title area
\maketitle

% As a general rule, do not put math, special symbols or citations
% in the abstract
\begin{abstract}
Several studies have been conducted on understanding third-party user tracking on the web. However, web trackers can only track users on sites where they are embedded by the publisher, thus obtaining a fragmented view of a user's online footprint. In this work, we investigate a different form of user tracking, where browser extensions are repurposed to capture the complete online activities of a user and communicate the collected sensitive information to a third-party domain. We conduct an empirical study of \textit{spying browser extensions} on the Chrome Web Store. First, we present an in-depth analysis of the spying behavior of these extensions. We observe that these extensions steal a variety of sensitive user information, such as the complete browsing history (e.g., the sequence of web traversals), online social network (OSN) access tokens, IP address, and user geolocation. Second, we investigate the potential for automatically detecting spying extensions by applying machine learning schemes. We show that using a Recurrent Neural Network (RNN), the sequences of browser API calls can be a robust feature, outperforming hand-crafted features (used in prior work on malicious extensions) to detect spying extensions. Our RNN based detection scheme achieves a high precision (90.02\%) and recall (93.31\%) in detecting spying extensions.
\end{abstract}

% no keywords




% For peer review papers, you can put extra information on the cover
% page as needed:
% \ifCLASSOPTIONpeerreview
% \begin{center} \bfseries EDICS Category: 3-BBND \end{center}
% \fi
%
% For peerreview papers, this IEEEtran command inserts a page break and
% creates the second title. It will be ignored for other modes.
\IEEEpeerreviewmaketitle


% An example of a floating figure using the graphicx package.
% Note that \label must occur AFTER (or within) \caption.
% For figures, \caption should occur after the \includegraphics.
% Note that IEEEtran v1.7 and later has special internal code that
% is designed to preserve the operation of \label within \caption
% even when the captionsoff option is in effect. However, because
% of issues like this, it may be the safest practice to put all your
% \label just after \caption rather than within \caption{}.
%
% Reminder: the "draftcls" or "draftclsnofoot", not "draft", class
% option should be used if it is desired that the figures are to be
% displayed while in draft mode.
%
%\begin{figure}[!t]
%\centering
%\includegraphics[width=2.5in]{myfigure}
% where an .eps filename suffix will be assumed under latex, 
% and a .pdf suffix will be assumed for pdflatex; or what has been declared
% via \DeclareGraphicsExtensions.
%\caption{Simulation results for the network.}
%\label{fig_sim}
%\end{figure}

% Note that the IEEE typically puts floats only at the top, even when this
% results in a large percentage of a column being occupied by floats.


% An example of a double column floating figure using two subfigures.
% (The subfig.sty package must be loaded for this to work.)
% The subfigure \label commands are set within each subfloat command,
% and the \label for the overall figure must come after \caption.
% \hfil is used as a separator to get equal spacing.
% Watch out that the combined width of all the subfigures on a 
% line do not exceed the text width or a line break will occur.
%
%\begin{figure*}[!t]
%\centering
%\subfloat[Case I]{\includegraphics[width=2.5in]{box}%
%\label{fig_first_case}}
%\hfil
%\subfloat[Case II]{\includegraphics[width=2.5in]{box}%
%\label{fig_second_case}}
%\caption{Simulation results for the network.}
%\label{fig_sim}
%\end{figure*}
%
% Note that often IEEE papers with subfigures do not employ subfigure
% captions (using the optional argument to \subfloat[]), but instead will
% reference/describe all of them (a), (b), etc., within the main caption.
% Be aware that for subfig.sty to generate the (a), (b), etc., subfigure
% labels, the optional argument to \subfloat must be present. If a
% subcaption is not desired, just leave its contents blank,
% e.g., \subfloat[].


% An example of a floating table. Note that, for IEEE style tables, the
% \caption command should come BEFORE the table and, given that table
% captions serve much like titles, are usually capitalized except for words
% such as a, an, and, as, at, but, by, for, in, nor, of, on, or, the, to
% and up, which are usually not capitalized unless they are the first or
% last word of the caption. Table text will default to \footnotesize as
% the IEEE normally uses this smaller font for tables.
% The \label must come after \caption as always.
%
%\begin{table}[!t]
%% increase table row spacing, adjust to taste
%\renewcommand{\arraystretch}{1.3}
% if using array.sty, it might be a good idea to tweak the value of
% \extrarowheight as needed to properly center the text within the cells
%\caption{An Example of a Table}
%\label{table_example}
%\centering
%% Some packages, such as MDW tools, offer better commands for making tables
%% than the plain LaTeX2e tabular which is used here.
%\begin{tabular}{|c||c|}
%\hline
%One & Two\\
%\hline
%Three & Four\\
%\hline
%\end{tabular}
%\end{table}


% Note that the IEEE does not put floats in the very first column
% - or typically anywhere on the first page for that matter. Also,
% in-text middle ("here") positioning is typically not used, but it
% is allowed and encouraged for Computer Society conferences (but
% not Computer Society journals). Most IEEE journals/conferences use
% top floats exclusively. 
% Note that, LaTeX2e, unlike IEEE journals/conferences, places
% footnotes above bottom floats. This can be corrected via the
% \fnbelowfloat command of the stfloats package.


% trigger a \newpage just before the given reference
% number - used to balance the columns on the last page
% adjust value as needed - may need to be readjusted if
% the document is modified later
%\IEEEtriggeratref{8}
% The "triggered" command can be changed if desired:
%\IEEEtriggercmd{\enlargethispage{-5in}}

% references section

% can use a bibliography generated by BibTeX as a .bbl file
% BibTeX documentation can be easily obtained at:
% http://mirror.ctan.org/biblio/bibtex/contrib/doc/
% The IEEEtran BibTeX style support page is at:
% http://www.michaelshell.org/tex/ieeetran/bibtex/
%\bibliographystyle{IEEEtran}
% argument is your BibTeX string definitions and bibliography database(s)
%\bibliography{IEEEabrv,../bib/paper}
%
% <OR> manually copy in the resultant .bbl file
% set second argument of \begin to the number of references
% (used to reserve space for the reference number labels box)


\input{introduction}
\input{background}
\input{dataset}
\input{analysis}
\input{defense_priorwork}
\input{defense_overview}
\input{defense_evaluation}
\input{discussion}
\input{related}
\input{conclusion}

%\bibliographystyle{ACM-Reference-Format}
\bibliographystyle{IEEEtran}
\bibliography{main}

\input{appendix}

% that's all folks
\end{document}



related.tex
%\vspace{-0.5cm}
\section{Related Work}
%\bimal{This section can be very brief. We will cover some important related work in intro and background sections.}

%\bimal{Describe work on tracking on the Web: Talk about user tracking on the Web and different ways in which privacy violations have been exposed. Talk about different types of solutions proposed/implemented: e.g., DoNotTrack, tracker-detection-extensions, PL-based approaches,}

%\bimal{Describe work on malicious extensions: ad injection, service abuse. Talk about papers that expose vulnerabilities, different approaches for defense: (1) ML based classifiers (2) information flow control/PL based approaches}
\subsubsectitle{User Behavior Tracking.}
There have been several studies of third-party user behavior tracking across the Web~\cite{englehardt2016online}\cite{lerner2016internet}\cite{mayer2012third}. A closely related piece of work is a very recent study by Starov \textit{et al.}~\cite{starovextended}, studying tracking by browser extension. \textit{First}, their study mostly focuses on a broader class of tracking extensions, including both unintentional leakage (\eg leakage via referer headers) as well as intentional leakage by benign extensions (\ie sensitive user information is required for the functionality of the extension). Instead, we conduct a detailed study of the more suspicious category of spying extensions. \textit{Second}, their work does not propose a robust detection scheme for spying extensions. 

%We give a detailed definition of \textit{spying} later in Section~\ref{sec:dataset}. 
%\textcolor{blue}{Unlike previous study by Starov et al~\cite{starovextended}, we do not consider accidental referrer header information leakage as \emph{spying} behavior. We focus on extensions which have explicit tracking code embedded to steal user information. We give a detailed definition of spying later in Section~\ref{sec:dataset}} \acsac{a similar study has been published before [34] and although they studied the top 10k extensions from Chrome's Web Store, they identified 618 extensions that leak the browsing history of users to third parties}

 %In the space of tracking by browser extensions, most recently XXX et al~\cite{starovextended} conducted a study to analyze t

 %These studies show the presence of web trackers present on websites which can have access to various sensitive private information of the user like browsing history, user name, OSN identifiers~\cite{krishnamurthy2009leakage}, cookies~\cite{englehardt2015cookies} and even predict user's shopping trends~\cite{guo2010ready}. Studies show that ad-injection over the web can help monitor user's browsing behavior~\cite{thomas2015ad} and user engagement~\cite{dave2012measuring}. There have been active efforts to protect users against web tracking by proving various browser solutions to identify and block third-party trackers~\cite{Mayer:db}. Web-based trackers, however, provide a fragmented view of user behavior. In this paper, we study spying via browser extensions which intentionally track users across the web. 

%A recent study has shown that 6.3\%  of top 10k extensions leak user informarion, where leakage is intentional (using a well defined POST request by the extension) by 373 out of top 10k extensions on Chrome Web Store and rest of the extensions leak informarion accidentally~\cite{starovextended}. Our work focuses on intentional leakage, more specifically only when this information leakage is not required for the functionality of the extension. We call this `spying' behavior, and also provide an in-depth analysis of how spying extensions operate using the browser's permission models and API calls. Further, we propose a detection model to find spying behavior of extensions.  

%Web Tracking happening via third parties has been studied in various capacities \cite{mayer2012third}. The usual approach however deals with tracking happening on individual websites. Presence of social media widgets facilitates OSN to track user behaviour wherever these are present. ShareMeNot \cite{roesner2012detecting} was designed as a Firefox plugin to detect and prevent this tracking. It`s functionality has now been incorporated into the Privacy Badger Tool \cite{PrivacyBadger}. It blocks spying ads and invisible trackers, by detecting storage of browsing behaviour happening in cookies by third parties. Some of the third party trackers might not appear in a browser devoid of any extensions. While we also look at cookies storing sensitive information our approach is targeted towards identifying the extensions which might be causing that behaviour. Tracking happening through browser extensions is more pervasive as it can gain access to possibly every visited site and inject tracking elements into it(provided that the site is vulnerable).
%Third Party Tracking has also been studied across mobile and web devices \cite{leungShould}. Leung et al. found PII, sensitive information and device identifiers being leaked through mobile apps and web services. In our work also we highlight Chrome Identifiers, device specific information being stored and sent over, due to the presence of certain malicious extensions.


\subsubsectitle{Detection of Malicious Browser Extensions.}
While there are very few studies focusing on information leakage by browser extensions, researchers have studied broader class of malicious extensions, which exhibit rogue behavior, such as - injecting ads, spreading malware, OSN account hijacking and information theft~\cite{jagpal2015trends}\cite{kapravelos2014hulk}\cite{xing2015understanding}. In this work, we focus our attention to only spying extensions, i.e., which intentionally track user information beyond the functionality of the extension.

Prior work has also attempted to automatically detect malicious extensions. Kapravelos \textit{et al.} proposed use of HoneyPages to dynamically run extensions and trigger them to capture any malicious activity~\cite{kapravelos2014hulk}. Shahriar \textit{et al.} used an HMM model with code snippets from the source code of Firefox extensions as input to train a model for automatic detection of malicious extensions~\cite{shahriar2014effective}. However, this method fails in case of extensions with obfuscated source code. Recently, DeKovan \textit{et al.} proposed a static heuristic based approach (using indicators from the source code of extensions) to flag malicious Chrome and Firefox extensions which change the layout of Facebook on client-side, or trigger suspicious user activity on Facebook~\cite{205855}. In addition, Jagpal \textit{et al.} proposed a machine learning framework with extensive feature engineering for malicious extension detection~\cite{jagpal2015trends}. In Section~\ref{subsec:prior}, we showed that this approach yields poor performance in detecting spying extensions. Moreover, their approach rely on complex feature engineering and rule based heuristics. Our RNN based approach captures dynamic behavior of extensions, and does not need hand-crafted features.

%\textcolor{blue}{
%While there are very few studies focusing on information leakage by browser extensions, researchers have studied broader class of malicious extensions, which exhibit rogue behavior, such as - injecting ads, spreading malware, OSN account hijacking and information theft~\cite{jagpal2015trends}\cite{kapravelos2014hulk}\cite{xing2015understanding}. In this work, we focus our attention to only spying extensions, i.e., which intentionally track user information beyond the functionality of the extension. }

%\textcolor{blue}{Prior work has also attempted to automatically detect malicious extensions. Kapravelos \textit{et al.} proposed use of HoneyPages to dynamically run extensions and trigger them to capture any malicious activity~\cite{kapravelos2014hulk}. Shahriar \textit{et al.} used an HMM model with code snippets from the source code of Firefox extensions as input to train a model for automatic detection of malicious extensions~\cite{shahriar2014effective}. However, this method fails in case of extensions with obfuscated source code. Recently, DeKovan \textit{et al.} proposed a static heuristic based approach (using indicators from the source code of extensions) to flag malicious Chrome and Firefox extensions which change the layout of Facebook on client-side, or trigger suspicious user activity on Facebook~\cite{205855}. In addition, Kapravelos \textit{et al.} proposed a machine learning framework with extensive feature engineering for malicious extension detection~\cite{jagpal2015trends}. First, we show that machine learning based methods to detect malicious extensions perform worse for specifically spying extensions. Second, previous studies rely on complex feature engineering and rule based heuristics. We propose an RNN based approach which captures dynamic behavior of extensions, and also does not need hand-crafted features.}

%While these studies rely on feature extraction and rule-based heuristics, our work uses API call sequences as input to an RNN, thus avoiding the need of complex feature engineering. Also, we run each extension in a controlled environment and extract the API call sequences from the dynamic run, hence overcoming the limitation of obfuscated source code, which is a common practice in case of malicious extensions. We further show that automatically detecting spying extensions is much more challenging than a broader class of malicious extensions.  

%Studies have uncovered rogue behavior of extensions such as injecting ads, spreading malware, and OSN account hijacking~\cite{jagpal2015trends}\cite{kapravelos2014hulk}\cite{xing2015understanding}. Prior work uses machine learning with extensive feature engineering for detection~\cite{jagpal2015trends}\cite{shahriar2014effective}. \textcolor{blue}{In addition, Kapravelos \textit{et al.} proposed use of HoneyPages to dynamically run extensions and trigger them to capture any malicious activity~\cite{kapravelos2014hulk}.}
%\acsac{[23] does not use machine learning and [19] is Google, so the techniques described in the paper are the techniques that guard the Web Store. Which means that the extensions that spy users are already circumventing those techniques to some extend.}
%Our proposed method leverages the API call sequences as input, thus obviating the need for extensive feature engineering.
% without the need of hand-crafted features to detect spying extensions. 

%To understand how malicious extensions operate, previous research has explored the permission model of extensions and the associated meta information~\cite{bauer2014analyzing}, \cite{felt2011effectiveness}. There have also been other techniques used to detect malicious code, especially which change the DOM elements of web pages by leveraging event based fuzzers and using the static features based on permission and metadata to detect malicious extensions~\cite{jagpal2015trends},\cite{kapravelos2014hulk}, \cite{shahriar2014effective}. While these can be effective in detecting malicious extensions, they require extensive feature engineering. Our proposed method leverages the API call sequences as input without the need of hand-crafted features to detect spying extensions. 


\subsubsectitle{Information Flow Control (IFC) for Malicious Behavior Detection.} 
There has been extensive research involving IFC techniques to detect security vulnerabilities and privacy leaks in Javascript based applications \cite{jang2010empirical}. Information Flow Analysis for Javascript applications focus predominantly on taint analysis \cite{guarnieri2011saving}, unstructured control flows \cite{just2011information} and dynamic information flows \cite{hedin2012information}\cite{hedin2014jsflow}. Previous research has also explored IFC based techniques to discover security vulnerabilities in browser extensions~\cite{bandhakavi2011vetting} and detect malicious extensions which steal sensitive information, such as cookies and saved passwords~\cite{dhawan2009analyzing}. 
%Such IFC based approaches are highly effective since they capture the dynamic behavior of applications under review. 
However, IFC based approaches face certain practical challenges. First, it is hard to find an exhaustive set of flow patterns that can effectively capture vulnerabilities. Second, they suffer from taint explosion and can result in a large number of false positives~\cite{enck2014taintdroid}. In our work, we take an alternate approach of leveraging the recent advances in deep neural networks to build a machine learning scheme to detect spying behavior.
%Given the recent advances in deep neural networks, in this work, we instead detect spying behavior using a machine learning approach. %WebEval, a framework to detect malicious extensions on Chrome Web Store also uses a machine learning framework~\cite{jagpal2015trends}. 

%Extension's source code can give hint about possible malicious behavior. However, extension's source code can be complex and challenging for performing static code analysis due to the presence of obfuscated and minified code. Hence, in this work we rely on dynamic behavior of extensions to flag spying behavior.

%Apart from using static code analysis, researchers have performed information flow analysis of browser extensions and JavaScript based applications to identify security vulnerabilities and track the flow of sensitive information because of malicious functionality of browser extensions~\cite{bandhakavi2011vetting, dhawan2009analyzing,just2011information}.

%Apart from static code analysis, a large body of work uses Information Flow Analysis techniques to detect security vulnerabilities and privacy leaks in Javascript based applications \cite{jang2010empirical}, \cite{lester2012information}. Information Flow Analysis for Javascript applications focus predominantly on taint analysis \cite{guarnieri2011saving}, unstructured control flows \cite{just2011information} and dynamic information flows \cite{hedin2012information} \cite{hedin2014jsflow}. With respect to the detection of malicious, privacy leaking extensions, Information Flow Analysis provides few incremental changes from the original same origin policy with static information flow analysis \cite{bandhakavi2011vetting} and labelling sensitive objects for flow tracking \cite{dhawan2009analyzing}. Although information flow analysis techniques seem sufficient, they are hardly so. Most information flow analysis techniques are based on an arduos process of defining policies to track flow of information \cite{guarnieri2011saving} \cite{chen2012self} \cite{austin2010permissive}. Such an approach lacks the flexibilty necessary to cope with the real world dynamic threats of spying browser extensions for which machine learning based techniques are more viable. In this work we focus on the permissions model and browser API calls available to extensions to identify spying extensions.
%\anu{to add a reference from here in detection section itself}
%\paragraph{RNN based approach for Malicious Behavior Detection: }
%Recent work has used Recurrent Neural Networks (RNN) for detecting malware classification using API call sequence patterns. These methods study the dynamic network behavior~\cite{shibahara2016efficient}, change in patterns of malicious files~\cite{huang2016mtnet} and use API call sequences by malicious applications to model a detection framework~\cite{pascanu2015malware}, \cite{kolosnjaji2016deep} based on sequence pattern. Our work has a similar approach and is the first study to show the viability of an RNN based approach to detect spying extensions on browsers using API call sequences without the need of extensive feature engineering as in previous research~\cite{jagpal2015trends}, \cite{kapravelos2014hulk}.

%Amongst several malicious behaviours an extensions can inject extra advertisements, compromise browsers, spy on users or even act as botnets. User tracking helps in doing targeted Ad-Injection. While we have focused on identifying the tracking behaviour, in this subsection we focus on the other types of malicious behaviours.\\ 
%Thomas et al. found 192 extensions, impacting 14 million users to be deceptively injecting ads \cite{thomas2015ad}. They developed a multi-staged pipeline to identify it and concluded that there is no simple way for this identification. One of the ways for Developers to prevent Ad-Injection is to restrict their sites against DOM changes.

%Malicious Behaviour can be suspected through the presence of different combinations of privacy sensitive permissions, as shown in our paper. Bauer et al. have studied the potential of data-theft, data-forgery, user tracking, and privilege escalation in different chrome extensions and the ratio of the top sites which will be affected by it \cite{bauer2014analyzing}. We however go one step further and pin down specific extensions which are not only capable, but are indeed spying. As studied by Felt et al.\cite{felt2011effectiveness} amongst the top 500 popular extension half of them ask for all-domain access and 91.4\% demand at least one security permission. Hence it is imperative to study the extensions` behaviour through various approaches as mentioned in our paper to discern.

%Lei et al. demonstrate the feasibility of launching bot-net attacks including email spamming, password sniffling and  DDoS through Chrome Extensions \cite{liu2011botnet}. The key facilitator for these attacks is the auto update mechanism of the Chrome Store, which helps the bot-master to send command and control to the bots. 

%Even non-malicious extensions can make the browser and sites vulnerable to attacks. In \cite{carlini2012evaluation} authors conclude that banning HTTP scripts and inline scripts could prevent 47 of 50 most severe vulnerabilities.

%\textbf{Defence Mechanisms: }

%Several defence mechanisms have been proposed for developers to make sites resilient to several popular attacks. In order to prevent Ad-Injection restricting DOM changes \cite{thomas2015ad}. Adding CSP to prevent XSS and Data Injection \cite{bauer2014analyzing}. 

%At the level of Extension Store multiple studies\cite{liu2011botnet}  have re-iterated the need for fine grained permissions. In case of an update required by an extension, that should also be scrutinised and the user consent should be taken or at the very least the user must be notified. During installation the sensitive permissions being asked by an extension should be highlighted \cite{felt2011effectiveness}.

%\textbf{Detection of malicious browser extensions}
%+ 

%Previous work on detecting malicious Chrome extensions has been done in \cite{kapravelos2014hulk}, \cite{jagpal2015trends}, \cite{thomas2015ad}. \cite{kapravelos2014hulk} introduces the concept of Honeypages -  specially-crafted web pages designed to satisfy the structural conditions that trigger an extension - driven by \textit{fuzzers} which is subsequently adapted to develop Generic suites as part of the automated dynamic analysis in the WebEval system of \cite{jagpal2015trends}. In addition to the dynamic analysis, \cite{jagpal2015trends} also performs static analysis of the source code of the extensions and analysis of the meta data of the developer of the extension. \cite{thomas2015ad} combines the ad analysis suite from \cite{jagpal2015trends} and WebEval`s ad analysis suite and network traces with similar tests produced by \cite{kapravelos2014hulk}. Although  \cite{kapravelos2014hulk}, \cite{jagpal2015trends} and \cite{thomas2015ad} have developed excellent methods for capturing the malicious behaviour of Chrome extensions, none are specifically directed at capturing stealing of information by these extensions. This work develops methods focussed on information theft.

%Similar detection of malicious extensions has been done for the Firefox browser. An exclusively machine learning based approach to detect malicious extensions has been developed in \cite{shahriar2014effective}. They employ a Hidden Markov Model trained on distinguishing features of browser extensions to classify Firefox extensions as benign, malicious or vulnerable. The VEX framework developed in \cite{bandhakavi2011vetting} helps in detecting malicious Firefox extensions. The authors identify patterns that lead to privilege escalation through information flow analysis of \\Javascript code.

%Information flow analysis techniques over Javascript code has been developed in \cite{dhawan2009analyzing} in which an alert is raised if objects containing sensitive information are written or sent over the network. Similar techniques can be used to detect tracking of information in Chrome extensions as they are essentially Javascript based add-ons to the Chrome browser.

%Other detection methods have been developed in \cite{guha2011verified} and \cite{mickens2010mugshot}. The IBEX framework developed in \cite{guha2011verified} uses static code analysis for verifying security in browser extensions. The Mugshot system developed in \cite{mickens2010mugshot} performs capture and replay of every event in a Javascript application. It replays the precise previous executions in order to detect instances of malicious behaviour.


ms.bbl
% Generated by IEEEtran.bst, version: 1.14 (2015/08/26)
\begin{thebibliography}{10}
\providecommand{\url}[1]{#1}
\csname url@samestyle\endcsname
\providecommand{\newblock}{\relax}
\providecommand{\bibinfo}[2]{#2}
\providecommand{\BIBentrySTDinterwordspacing}{\spaceskip=0pt\relax}
\providecommand{\BIBentryALTinterwordstretchfactor}{4}
\providecommand{\BIBentryALTinterwordspacing}{\spaceskip=\fontdimen2\font plus
\BIBentryALTinterwordstretchfactor\fontdimen3\font minus
  \fontdimen4\font\relax}
\providecommand{\BIBforeignlanguage}[2]{{%
\expandafter\ifx\csname l@#1\endcsname\relax
\typeout{** WARNING: IEEEtran.bst: No hyphenation pattern has been}%
\typeout{** loaded for the language `#1'. Using the pattern for}%
\typeout{** the default language instead.}%
\else
\language=\csname l@#1\endcsname
\fi
#2}}
\providecommand{\BIBdecl}{\relax}
\BIBdecl

\bibitem{englehardt2016online}
S.~Englehardt and A.~Narayanan, ``Online tracking: A 1-million-site measurement
  and analysis,'' \emph{ACM CCS}, 2016.

\bibitem{roesner2012detecting}
F.~Roesner, T.~Kohno, and D.~Wetherall, ``Detecting and defending against
  third-party tracking on the web,'' \emph{USENIX NSDI}, 2012.

\bibitem{starovextended}
O.~Starov and N.~Nikiforakis, ``Extended tracking powers: Measuring the privacy
  diffusion enabled by browser extensions,'' \emph{WWW}, 2017.

\bibitem{kapravelos2014hulk}
A.~Kapravelos, C.~Grier, N.~Chachra, C.~Kruegel, G.~Vigna, and V.~Paxson,
  ``Hulk: Eliciting malicious behavior in browser extensions,'' \emph{USENIX
  Security}, 2014.

\bibitem{Lifehacker:pi}
Lifehacker, ``Web of trust sells your browsing history, uninstall it now,''
  \url{http://lifehacker.com/1788667989}, 2017.

\bibitem{bandhakavi2011vetting}
S.~Bandhakavi, N.~Tiku, W.~Pittman, S.~T. King, P.~Madhusudan, and M.~Winslett,
  ``Vetting browser extensions for security vulnerabilities with vex,''
  \emph{CACM}, 2011.

\bibitem{dhawan2009analyzing}
M.~Dhawan and V.~Ganapathy, ``Analyzing information flow in javascript-based
  browser extensions,'' \emph{IEEE ACSAC}, 2009.

\bibitem{jang2010empirical}
D.~Jang, R.~Jhala, S.~Lerner, and H.~Shacham, ``An empirical study of
  privacy-violating information flows in javascript web applications,''
  \emph{ACM CCS}, 2010.

\bibitem{jagpal2015trends}
N.~Jagpal, E.~Dingle, J.-P. Gravel, P.~Mavrommatis, N.~Provos, M.~A. Rajab, and
  K.~Thomas, ``Trends and lessons from three years fighting malicious
  extensions,'' \emph{USENIX Security}, 2015.

\bibitem{de2015survey}
W.~De~Mulder, S.~Bethard, and M.-F. Moens, ``A survey on the application of
  recurrent neural networks to statistical language modeling,'' \emph{Computer
  Speech \& Language}, vol.~30, no.~1, pp. 61--98, 2015.

\bibitem{Apple:2017ht}
Apple, ``Safari extensions js,''
  \url{https://developer.apple.com/documentation/safariextensions}, 2017.

\bibitem{Mozilla:2017yt}
Mozilla, ``Firefox webextensions javascript apis,''
  \url{https://developer.mozilla.org/en-US/Add-ons/WebExtensions}, 2017.

\bibitem{Chrome:fk}
Chrome, ``Why am i being asked to pay a registration fee?''
  https://developer.chrome.com/webstore/faq, 2017.

\bibitem{Chrome:2015rz}
{Chrome}, ``Continuing to protect chrome users from malicious extensions,''
  \emph{https://blog.chromium.org/2015/05/continuing-to-protect-chrome-users-from.html},
  2015.

\bibitem{Labs:2015dz}
LabsDetectify, ``Chrome extensions - aka total absence of privacy,'' 2015.

\bibitem{weissbacherthese}
M.~Weissbacher, ``These browser extensions spy on 8 million users,''
  \emph{http://mweissbacher.com/blog/2016/03/31/these-chrome-extensions-spy-on-8-million-users/},
  2016.

\bibitem{Google:ij}
\BIBentryALTinterwordspacing
Google. (2017) Google safebrowing api. [Online]. Available:
  \url{https://developers.google.com/safe-browsing/}
\BIBentrySTDinterwordspacing

\bibitem{Virustotal:kk}
\BIBentryALTinterwordspacing
Virustotal, 2017. [Online]. Available: \url{www.virustotal.com}
\BIBentrySTDinterwordspacing

\bibitem{Phishtank:pi}
\BIBentryALTinterwordspacing
``Phishtank,'' 2017. [Online]. Available: \url{https://www.phishtank.com/}
\BIBentrySTDinterwordspacing

\bibitem{wot}
``Web of trust (wot),'' https://www.mywot.com/, 2017.

\bibitem{Canali:2012:QSA:2338965.2336768}
\BIBentryALTinterwordspacing
D.~Canali, A.~Lanzi, D.~Balzarotti, C.~Kruegel, M.~Christodorescu, and
  E.~Kirda, ``A quantitative study of accuracy in system call-based malware
  detection,'' in \emph{Proceedings of the 2012 International Symposium on
  Software Testing and Analysis}, ser. ISSTA 2012.\hskip 1em plus 0.5em minus
  0.4em\relax New York, NY, USA: ACM, 2012, pp. 122--132. [Online]. Available:
  \url{http://doi.acm.org/10.1145/2338965.2336768}
\BIBentrySTDinterwordspacing

\bibitem{hochreiter1997long}
S.~Hochreiter and J.~Schmidhuber, ``Long short-term memory,'' \emph{Neural
  computation}, 1997.

\bibitem{pascanu2015malware}
R.~Pascanu, J.~W. Stokes, H.~Sanossian, M.~Marinescu, and A.~Thomas, ``Malware
  classification with recurrent networks,'' in \emph{IEEE ICASSP}, 2015.

\bibitem{shibahara2016efficient}
T.~Shibahara, T.~Yagi, M.~Akiyama, D.~Chiba, and T.~Yada, ``Efficient dynamic
  malware analysis based on network behavior using deep learning,''
  \emph{GLOBECOM}, 2016.

\bibitem{bucilua2006model}
C.~Bucilua, R.~Caruana, and A.~Niculescu-Mizil, ``Model compression,''
  \emph{SIGKDD}, 2006.

\bibitem{jin2014efficient}
J.~Jin, V.~Gokhale, A.~Dundar, B.~Krishnamurthy, B.~Martini, and
  E.~Culurciello, ``An efficient implementation of deep convolutional neural
  networks on a mobile coprocessor,'' in \emph{Circuits and Systems (MWSCAS),
  2014 IEEE 57th International Midwest Symposium on}.\hskip 1em plus 0.5em
  minus 0.4em\relax IEEE, 2014, pp. 133--136.

\bibitem{meeds2015mlitb}
E.~Meeds, R.~Hendriks, S.~Al~Faraby, M.~Bruntink, and M.~Welling, ``Mlitb:
  machine learning in the browser,'' \emph{PeerJ Computer Science}, vol.~1, p.
  e11, 2015.

\bibitem{TensorFlow:2017jf}
TensorFlow, ``Tensorflow mobile,'' https://www.tensorflow.org/mobile/, 2017.

\bibitem{Facebook:2016fz}
Facebook, ``Delivering real-time ai in the palm of your hand,''
  https://code.facebook.com/posts/196146247499076/delivering-real-time-ai-in-the-palm-of-your-hand/,
  2016.

\bibitem{lerner2016internet}
A.~Lerner, A.~K. Simpson, T.~Kohno, and F.~Roesner, ``Internet jones and the
  raiders of the lost trackers: An archaeological study of web tracking from
  1996 to 2016,'' \emph{USENIX Security}, 2016.

\bibitem{mayer2012third}
J.~R. Mayer and J.~C. Mitchell, ``Third-party web tracking: Policy and
  technology,'' \emph{IEEE S\&P}, 2012.

\bibitem{xing2015understanding}
X.~Xing, W.~Meng, B.~Lee, U.~Weinsberg, A.~Sheth, R.~Perdisci, and W.~Lee,
  ``Understanding malvertising through ad-injecting browser extensions,''
  \emph{WWW}, 2015.

\bibitem{shahriar2014effective}
H.~Shahriar, K.~Weldemariam, M.~Zulkernine, and T.~Lutellier, ``Effective
  detection of vulnerable and malicious browser extensions,'' \emph{Computers
  \& Security}, 2014.

\bibitem{205855}
\BIBentryALTinterwordspacing
L.~F. DeKoven, S.~Savage, G.~M. Voelker, and N.~Leontiadis, ``Malicious browser
  extensions at scale: Bridging the observability gap between web site and
  browser,'' in \emph{{USENIX} Workshop on Cyber Security Experimentation and
  Test ({CSET} 17)}, 2017. [Online]. Available:
  \url{https://www.usenix.org/conference/cset17/workshop-program/presentation/dekoven}
\BIBentrySTDinterwordspacing

\bibitem{guarnieri2011saving}
S.~Guarnieri, M.~Pistoia, O.~Tripp, J.~Dolby, S.~Teilhet, and R.~Berg, ``Saving
  the world wide web from vulnerable javascript,'' \emph{ACM ISSTA}, 2011.

\bibitem{just2011information}
S.~Just, A.~Cleary, B.~Shirley, and C.~Hammer, ``Information flow analysis for
  javascript,'' \emph{ACM SIGPLAN international workshop on Programming
  language and systems technologies for internet clients}, 2011.

\bibitem{hedin2012information}
D.~Hedin and A.~Sabelfeld, ``Information-flow security for a core of
  javascript,'' \emph{IEEE Computer Security Foundations Symposium}, 2012.

\bibitem{hedin2014jsflow}
D.~Hedin, A.~Birgisson, L.~Bello, and A.~Sabelfeld, ``Jsflow: Tracking
  information flow in javascript and its apis,'' \emph{ACM ACSAC}, 2014.

\bibitem{enck2014taintdroid}
W.~Enck, P.~Gilbert, S.~Han, V.~Tendulkar, 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,'' \emph{ACM TOCS},
  2014.

\end{thebibliography}
