iMonitor: An APP-level Traffic Monitoring and

Labeling System for iOS devices

Junqiu Liu, Fei Wang, Shuang Zhao, Xin Wang and Shuhui Chen
College of Computer
National University of Defense Technology, Changsha, China
Email: [email protected]

Abstract—In this paper, we propose the first traffic monitoring Jie et al. made a contribution to P2P traffic classification by
and labeling system for iOS devices, named iMonitor, which not simply counting flows [9] and clustering flows [10]; Enck et
just captures mobile network traffic in .pcap files, but also pro- al. [11] and Song et al. [12] proposed their solutions to privacy
vides comprehensive APP-related and user-related information
of captured packets. Through further analysis, one can obtain leakage detection in mobile network traffic.
the exact APP or device where each packet comes from. The Before studying mobile network traffic, a problem we
labeled traffic can be used in many research areas for mobile should solve is how to capture mobile network traffic effi-
security, such as privacy leakage detection and user profiling. ciently and provide detailed information (user-related or APP-
Given the implementation methodology of NetworkExtension related) for further analysis. Current solutions have three
framework of iOS 9+, APP labels of iMonitor are reliable enough
so that labeled traffic can be regarded as training data for shortcomings: 1) OS limitation: Android and iOS are both
any traffic classification methods. Evaluations on real iPhones primary operating systems for mobile phones and previous
demonstrate that iMonitor has no notable impact upon user methods for mobile traffic monitoring are mostly for Android
experience even with slight packet latency. Also, the experiment devices. However, due to different OS implementation, traffic
result supports our motivation that mobile traffic monitoring generated by iOS and Android devices may differ significantly
for iOS is absolutely necessary, as traffic generated by different
OSes like Android and iOS are different and unreplaceable in and are unreplaceable in research [13], which means a novel
researches. monitoring method for iOS devices is desperately needed. 2)
Index Terms—iOS, traffic label, network monitor, mobile APP, Coarse-grained information: Neither on-device monitoring
mobile network tools for iPhones nor packet capturing tools like Wireshark
can offer fine-grained information of the captured network
I. INTRODUCTION traffic. To perform per-APP investigation such as Information
It has been years since we first used mobile phones as tools Leakage Detection, APP-level traffic labeling is necessary. 3)
to access the Internet. As a survey from Bright Edge indicates, Limited capturing scale: There are still no available methods
mobile network traffic generated by phones or tablets takes to capture network traffic of iPhones with detailed information
62% of all online traffic in 2018 [1]. A report [2] from Smart and on a large scale.
Insights also shows that mobile network traffic is taking a In this paper, we present iMonitor system, which provides
dominant place in minutes spent online across countries, and a solution to monitor, collect and label traffic on iOS devices
over 80% of that mobile traffic is generated by APPs. There with detailed information. Contributions of this paper are listed
are also millions of APPs that can be downloaded by iPhone as follows:
users from Apple APP store of China, which is quite a large • The first mobile traffic monitoring prototype for iOS
number. With mobile devices becoming popular as a tool to devices, called iMonitor system, is presented. This system
access the Internet, the scale of mobile network traffic is ever- offers a new approach for mobile traffic data capturing
increasing, as shown in Cisco research [3]. on iOS devices. Given a pre-set bundleID list of APPs,
With a series of sensors installed, mobile phones are getting iMonitor system can effectively capture all traffic gener-
more and more powerful. Meanwhile, those sensors can be ated by those APPs out of overall traffic of that iPhone,
utilized by APPs installed on mobile phones, and information which fills the gap in traffic monitoring of iOS devices.
obtained from sensors can be uploaded to remote servers ex- • A prior approach to acquiring APP-level information of
plicitly or implicitly. From that information, offenders are able mobile traffic is proposed and integrated into iMonitor
to track every move of a victim, such as location data. There is system. As iMonitor system gets detailed information
already a study [4] using sensors installed on mobile phones from a trusted framework in iOS, all APP labels are
to profile users by stress recognition and many researchers fully credible and can be used as a reliable training set
are working on mobile network traffic to protect users from for traffic classification. iMonitor also provides user-level
threats. Wei et al. [5] built a 4-layer (Static layer, user layer, information for researches like user profiling.
operating system layer, and network layer) model to profile • We comprehensively evaluate the impacts of the pro-
APPs of Android OS; Iliofotou et al. [6], Shuba et al. [7] and posed client of iMonitor system on devices and users.
Vallina et al. [8] built their models for network monitoring; The in-depth analysis of network throughput, resource
 consumption, and label effectiveness demonstrates that will be routed to this VPN server to be handled, which means
our iMonitor system has no notable influence upon user that phone will do a lot of work processing those packets,
experience and can run in nearly a user-transparent style. and store those packets on the phone if needed. This kind of
As a proof-of-concept, we implemented a prototype of VPN requires phones’ performance and may consume lots of
iMonitor system and evaluated the performance of it. We con- battery to complete its jobs. With packets captured are stored
nected our iPhones to iMonitor system and use them in real- on phones, it also needs a mechanism to upload those captured
life scenarios, in the meanwhile, we collected mobile network packets to a given server.
traffic with detailed information, with which we applied to
B. OS-based Traffic Monitoring
mobile traffic classification implemented with Random Forest
and verified the conclusion of research [13] by Hasan et al OS-based traffic monitoring approaches monitor and capture
as a use case (see Section IV-C). Performance evaluation network traffic actively using API provided by OS, such
measured network throughput of proxied iPhones and resource as tcpdump, which is used by ProfileDroid [5]. Using this
consumption of them. We made contrasts between proxied and approach to monitor network traffic of mobile devices requires
unproxied network throughput and resource consumption, and system-level privilege, which means that the device needs
results show that iMonitor system has good performance and to be rooted. With devices rooted, one has full access to
little interference to normal use of network. all the information of those devices, thus making monitor
Rest of the paper is organized as follows. Section II network traffic of mobile devices easier. However, most users
discusses related work. Section III describes the design and are unwilling to have their devices rooted, and if users regret
implementation of iMonitor system. Section IV describes to have their devices rooted, the only method to restore their
evaluation of effectiveness, network throughput and resource devices unrooted is to reinstall the OS, which causes a lot of
consumption of iMonitor. Section V concludes this paper and problems, moreover, for iPhones, if their former installed iOS
describes the future work. is too old, they will not be able to reinstall that version of iOS
back to their iPhones, because the verification channel of that
II. RELATED WORK version of iOS may have been closed.
A. VPN-based Traffic Monitoring C. On-device measurements
In VPN-based traffic monitoring approaches, mobile devices On-device measurements mean to collect information of
are connected to a VPN proxy and network traffic is routed network status on the devices with some installed apps or pro-
to the VPN proxy to be handled, thus making VPN proxy vided web pages, such as Mobilyzer [19], speedtest [20]. This
knows the detailed information of traffic. Privacy Guard [12] kind of collection often does not require root privileges, but
and AntMonitor [14] are two representative results on Android the information collected is not detailed enough for research.
devices and iMonitor also used VPN-based traffic monitoring.
Basically, in Android, people have two alternatives to im- D. Passive Monitoring
plement a VPN, client-server VPN and mobile-only VPN. Passive Monitoring approaches are used on network nodes,
1) Client-Server VPN, such as Meddle [15], which is built such as gateways of LANs. For ISPs and other organizations
with StrongSwan [16], as its name indicates, has two major that provide network services to the public, they have control
parts, a client and a server. Usually, people use an app on the over the network they are providing, thus making it possible
phone as a client, and some programs running on a remote for them to capture packets via their network interfaces [21].
computer or VPS as a server. Between client and server, Weakness of this approach is obvious. For that network traffic
there should be a tunnel obeying some specific protocols, are captured outside the devices, one cannot get fine-grained
which is used to transmit packets between client and server. information of captured network traffic.
Developers of this kind of VPN will be free to use any kind of
protocols, which may provide encryption or private browsing E. Application of Traffic Monitoring
functions, to implement their tunnel, thus making it possible In this section, we roughly enumerate three main applica-
to ensure the security of data transmitting between client tions of mobile traffic monitoring.
and server. However, when people use Client-Server VPN Traffic Classification: Mobile traffic classification is a
to monitor mobile networks, the separation between network topic of mobile network research, and many jobs have been
traffic and information of that network traffic will appear, done before. Researchers have tried to recognize apps using
because information of network traffic, such as which app the packet headers or HTTP request headers [22]–[24], statistical
network traffic comes from, is only accessible on the phone. characteristics of packets [25]. Nevertheless, the encryption of
This requires some mechanism of communication between network traffic is absolutely a trend in the network. Encryption
client and server. 2) Mobile-only VPN, such as Privacy Guard is an excellent way to ensure the security of the network
[11] and Haystack [17], [18], different from Client-Server while protecting information of network users; it makes it a
VPN, requires only one participant, which is the phone itself. tough thing to analyze network traffic. To deal with encrypted
With the support of Android’s VPNService API, people are network traffic, some researchers tried to use machine learning
able to build a VPN server on the phone, and all the packets to recognize apps from HTTPS/TLS network flows. All the
jobs done above are all based on traffic captured from Android
devices, although there are some attempts on network traffic
captured from iOS devices, their collection of iOS network
traffic is restricted to the laboratory environment. There is still
a lack of a solution to capture iOS network traffic on a large
scale.
User Profiling: Mobile APPs now cover almost every single
part of our lives. People have got used to ordering meals,
paying for groceries, chatting with friends, watching movies
Fig. 1. System Architecture
with APPs on phones, in other words, by analyzing what kind
of apps a man is using, we can figure out what kind of people
he is. Taking advantage of this, polices or intelligence agencies the limitation of iOS. 2) CoM (Client of iMonitor system)
will be capable of identifying underlying threats using the should not consume too many resources. In order to reduce the
HMM classifier on network flow records [26] or re-identify burden CoM cast on users’ devices, CoM needs to do its job
users over different web sessions [27]. efficiently and we have to control its resource consumption. 3)
Information Leakage Detecting: Smartphones now have CoM itself should not be too complicated to be used. In the
been installed with a large set of sensors, such as gravity best scenario, users just need to connect to server of iMonitor
sensors, fingerprinting sensors, GPS modules. With network system by a single tap on a toggle switch, and they do not
flows collected by our system, researchers will be able to need to care about CoM anymore after this.
detect information leakage of different APPs on iOS with
network traffic captured by our system. PrivacyGuard [12] and B. System Design
Recon [28] are examples of this application. The iMonitor system consists of a client-side part, CoM,
which is installed as an APP on iOS devices, and a server-side
III. I MONITOR SYSTEM
part, SoM, which is deployed on remote servers. Basically,
A. Design Rationale iMonitor system needs a MDM (Mobile Device Management
Before giving details of iMonitor system, some design ) Server to distribute configurations, but for the reason that
objectives are listed as follows: iMonitor system is built for demonstration at current stage,
Objective 1: Large-scale traffic collection: We are im- MDM server will not appear in this paper. We have already
plementing iMonitor as a system to monitor and collect large- written configurations in CoM before it is compiled and
scale network traffic of iOS devices, which poses requirements distributed. The System architecture of iMonitor is shown in
on iMonitor system. 1) User group of iMonitor is the larger the Figure 1. The CoM includes a PerAppProxy (PAP in short )
better because more users means more mobile network traffic to intercept network traffic of a given list of APPs, a Pack-
we are collecting. For this reason, iMonitor system should etTunnel (PT in short ) to forward those intercepted packets,
provide great user experience. 2) Performance on both client and a Controller Module to deal with user interactions and
and server of iMonitor system should be excellent, thus giving communicate with QueryServer (QS in short ) of SoM. On the
iMonitor system the ability to process more network traffic at server-side, there are different servers responsible for different
the same time. missions. We divide them into three parts, ProxyServer (PS in
Objective 2: Fine-grained traffic information: Informa- short ), DataManageServer (DMS in short ) and QueryServer
tion that iMonitor system collects should be as detailed as (QS in short ). In the following paragraphs, we will discuss
possible. Other than normal properties of a packet, APP label the design of the client and server in detail.
and device identifier of network traffic are also meaningful and Client-side: The client-side is charged with interacting with
should be recorded. All that information should be organized users, collecting information about mobile network traffic,
well so that researchers can use the information conveniently. uploading collected information and forwarding intercepted
Objective 3: Multiple APP traffic monitoring: The iMon- packets in the iMonitor system. To accomplish those missions,
itor system should be able to monitor and collect information we need to implement a Controller Module, a PAP and a PT
of all kinds of APPs, no matter how they are implemented. in CoM. 1) PAP (PerAppProxy ): PAP is a Per-App Proxy
As we all know, communication mechanisms of TCP and containing a list of APPs, which is called rule list. All the
UDP are quite different from each other, for example, TCP is network traffic from those APPs will be directed to PAP in the
connection-oriented but UDP is connectionless. To offer mul- form of network flows. According to different types of packets,
tiple APP traffic monitoring service, iMonitor system should network flows can be divided into TCP network flows and
not only handle TCP packets but also have UDP datagrams UDP network flows. By reading properties of TCP network
well handled. flows and UDP network flows, we can get detailed information
Objective 4: User transparency: User transparency cov- about them. If we want to get specific information about
ers a lot of aspects. 1) Mobile device should remain non- transmitted packets, such as source IP-Port and destination IP-
jailbroken. Most of the users resist to have their Apple devices Port, things are different for each kind of network flow. For
jailbroken, so we have to implement iMonitor system within TCP flows, we are aware of its local address and destination
 Fig. 3. Log item

(a) Main Panel (b) Configuration Panel (c) Log Panel

Fig. 2. User Interface

address once the TCP connection is established. However,

for UDP flows, it is most common for a UDP flow to not
be connected, in other words, a UDP flow allows outgoing
packets to any destination. Once we have collected all the
needed information of network flows, the information should
be uploaded to the DMS of SoM. 2) PT (PacketTunnel ):
After reading the information of those packets, we need to
forward those packets to PS of SoM using PT to guarantee
the network is smooth. Considering that TCP and UDP have
different communication procedures, they should be processed
separately. 3) Controller Module: Controller Module has a
visible part, which is User Interface, and an invisible part,
which communicates with QS of SoM to support CoM. User Fig. 4. Client Structure
Interface should be simple, but functional and comfortable.
There should be a toggle switch to turn PAP on/off, a panel to
display current configuration of PAP , and a panel to display
logs of intercepted network packets. C. System implementation

Server-side: The server-side of the iMonitor system is

mainly divided into three components: PS, DMS, and QS, User Interface: The user interface of CoM consists of three
which can be deployed on single or multiple servers. 1) PS components, Main Panel (Figure 2(a)), Config Panel (Figure
(ProxyServer ): PS is responsible for forwarding packets 2(b)), and Record Panel (Figure 2(c)). Main Panel provides
between CoM and TargetServer, which is the server those a toggle switch for users to turn on/off the PAP of CoM.
proxied packets eventually targeted to. All the packets con- Below the toggle switch is a table cell named testVPNPAP,
cerned will go through this PS, so we can capture packets which contains the configuration of PAP. Figure 2(b) shows
at PS. For the reason that we choose client-server VPN the details of the configuration of PAP, with its name, server
approach to implement the iMonitor system, we have much address, and rule list exhibited. If the user taps Net Logs
freedom to choose servers implemented for various protocols. button in the right-top corner of Main Panel, the Record Panel
2) DMS (DataManageServer ): DMS handles with informa- will appear. The Record Panel shows users the log of proxied
tion uploaded by CoM. This server receives information of packets with detailed information. For the reason that fonts in
packets, and store that information in directories according to Figure 2 are too small, a single network log is presented in
different devices and APPs. Combined with this information, Figure 3.
one can extract filter rules of packets for a specific APP on PT(PakcetTunnel): At the client-side, in theory, we have to
a specific device. This part should be extendable. Researchers implement a PAP and a PT. Figure 4 shows a rough procedure
can feel free to extract information they are concerned about of CoM to handle network flows, in which SOCKS5 Tunnel is
in DMS. 3) QS (QueryServer ): QS provides some essential our PT. PT is responsible for tunneling packets between CoM
information to support CoM, such as public IP of a certain and SoM, which means that CoM and SoM must reach a con-
CoM. With iMonitor system becoming stronger and stronger, sensus on the protocol for data transmission. Considering that
QS will provide more information for CoM. our proxy needs to deal with both TCP and UDP packets and
SOCKS5(defined by RFC 19281 , RFC 19292 , and RFC 19613 )
protocol has excellent support for UDP packet handling, we
finally decided to use SOCKS5 as the tunnel protocol of PT,
thus saving the trouble of implementing a self-defined PT.
Packet information: PAP can intercept network flows of
target APPs. Intercepted network flows are treated as NEApp-
ProxyFlow (APF in short ) in PAP. APF has two subclasses,
NEAppProxyTCPFlow (APTF in short ) and NEAppProx-
yUDPFlow (APUF in short ). By reading the properties of Fig. 5. Recorded information of a captured packet
APF, we can get information related to that flow. For APTF,
the properties we can read are sourceAppSigningIdentifier
of metaData, remoteEndpoint and localEndpoint. SourceApp- UDP Datagrams Handling: For APUF, things are dif-
SigningIdentifier is the bundleID of the APP that network flow ferent. The properties we can read from a APUF includes
comes from, and remoteEndpoint is a data type of Swift 3 sourceAppSigningIdentifier of metaData, localEndpoint. How-
(Swift 3 is a programming language of iOS ), which denotes ever, localEndpoint of APUF is only accessible when APUF
the destination host of current network flow. Apart from the is opened, and there is a parameter setting localEndpoint for
sourceAppSigningIdentifier, remoteEndpoint, localEndpoint, APUF when calling open function, which means that we can
protocol, we also note the current time, packet size and IDFA control the localEndpoint of APUF. Sometimes UDP traffic
of iPhone (IDFA, ID for Advertisement, which is used to comes to our PAP with its local address. In this situation, to
track different iOS devices in iMonitor System) down while make sure UDP communication does work, we have to set
forwarding each packet. However, for APUF, things are more APUF’s localEndpoint to that local address. For other cases,
complicated, so the details are discussed in UDP Datagrams we use the address of UDP socket we use to communicate
Handling. with SOCKS5 server as the localEndpoint of APUF. Details
PAP(PerAppProxy): As for PAP, we first need to set a list about SOCKS5 communication can be found in RFC 1928.
of target APPs that we want to monitor, which we call a rule In APTF, the data items read out is called as packets. Those
list, using a pre-built .plist file. Each APP on this list is denoted packets are actually payloads of TCP protocol. In APUF, we
by its bundleID (BundleID is a unique identifier for iOS call the data items read out as datagrams. Datagrams contain
APPs, for example, bundleID of WeChat is com.tencent.xin). the UDP data payload and destination host of that datagram,
To get bundleID for a certain iOS APP, we also implemented so only when handling with datagrams, can we get known
a small crawler to traverse and save all information of APP of where a certain datagram is going to. We collect the same
on AppStore in China. Information crawled are saved in the information of UDP datagrams as TCP packets and send them
MySQL database, and API written in Python to query that to the same DMS.
collected information is provided as a part of QS. Only after PS (ProxyServer ): PS of the iMonitor system is a SOCKS5
rule list is set, could PAP be started. Detailed workflow of server we download from SourceForge, and it merely forwards
PAP will be discussed in the following paragraph. traffic between CoM and destination server of the CoM. For
Workflow of PAP: When getting started, PAP will try to the reason that all traffic proxied will go through PS, traffic
establish TCP connections with PS and DMS, if these two collection is done here using tcpdump. Captured traffic is
connections are established without any errors, our PAP will stored in .pcap files with a size limit of 100MB. Exceeded part
start handling network traffic and uploading information of of traffic will be stored in a new .pcap files, whose filename
related packets or datagrams. PAP is able to intercept packets is appended with a sequence number.
of APPs on the rule list, but without handling, those packets DMS (DataManageServer ): DMS receives information of
are just abandoned, which makes network of APPs on the traffic with Python scripts. It receives TCP connections, parses
rule list blocked. To forward intercepted packets, we create TCP payloads as JSON objects, and saves that information
a socket for each APTF, and after the socket is created, we according to IDFA and sourceAppSigningIdentifier of the
open APTF to read data from it. The number of data items in information. Figure 5 shows an example of recorded informa-
APTF is uncertain. Every time we read a data item, we will tion of a captured packet. This information contains time of
send it to PS using that socket, so the source address of those recording, IP address of CoM and a JSON object containing
packets will be the address of that socket, which is called as packet details. There are 3 keys in that JSON object, app,
localEndpoint, and packet information is uploaded ever time idfa, and record. Value of app (cn.edu.nudt.MakePost) is the
a packet is forwarded. This information will be sent to DMS bundleID of the source APP of the packet, which denotes
using TCP connection in the form of a JSON object. After an APP named MakePost (MakePost is written to send out
information is noted down, packets will be forward to PS. a HTTP POST request to verify the functions of iMonitor
system). For idfa, it is a UUID generated by iOS to help
1 RFC 1928: https://www.ietf.org/rfc/rfc1928.txt
advertisements to recognize diverse devices, and we use it
2 RFC 1929: https://www.ietf.org/rfc/rfc1929.txt as an identifier to denote different iOS devices here. The key
3 RFC 1961: https://www.ietf.org/rfc/rfc1961.txt record contains detailed information of the captured packet,
including length, protocol, time, dstIP, dstPort, srcIP, and TABLE I
srcPort. With recorded information, one is able to extract filter N ETWORK T ESTS
rules for all kinds of uses (e.g. traffic classification and user Type With iMonitor Without iMonitor
profiling). Taking traffic classification as an example, we can Download Bandwidth(Mbps) 66.10 66.41
use target server addresses combined with APP identifier to Upload Bandwidth(Mbps) 11.37 10.90
Latency(ms) 16.4 12.6
create a filter rule to extract traffic of a specific APP. As
for user profiling, we use target server addresses and APP
identifier combined with IDFA to build another filter rule, and
after applying this filter rule to captured .pcap files, we are
able to extract traffic of a certain user, with preferred APPs of
that user known.
QS (QueryServer ): QS provides essential information to
support CoM. It serves in 2 aspects for current stage, public
IP query and bundleID query. public IP query helps CoM
to know its public IP, and CoM can infer whether it is in a
LAN by comparing its local IP address to public IP. BundleID Fig. 6. Resource Consumption of app Proxy
query provides CoM the service to query bundleID for each
iOS APP. All those two services can be obtained by HTTP
POST request. Other than those two mentioned query services, CoM under this limitation, which guarantees that CoM does
QS will provide models for more aims, such as privacy leakage not take up too much memory. To test the energy consumption
detecting, in the future. Whatever needed by CoM can be of CoM, we connect the tested iPhone to a MacBook, on
provided at QS. which Xcode (Xcode is the IDE for programming on Apple’s
IV. EVALUATION devices) is running, and with the help of Xcode, we are able
to attach to the main process and get full information (usage
A. Network Throughput
of CPU, memory, disk, network and energy) of this process.
To evaluate the influence that iMonitor has on iPhone’s Once Xcode is ready to monitor the primary process of CoM,
network throughput, we installed Speedtest [20] on our tested we use the tested iPhone to download a 1.27GB file with PAP
iPhone 8, and added its bundleID (com.ookla.speedtest) into turned on, and record energy consumption of the appProxy
the rule list of PAP, thus making network traffic of Speedtest process with the help of Xcode’s debugger. The result is shown
goes through PAP. Speedtest is a definitive way to test the in Figure 6. As Figure 6 shows, at that moment, appProxy
speed and performance of internet connections and it is widely used 14% of CPU, 4.3MB of memory, and it did not read
used over the world. We tested network speed using Speedtest or write anything to the disk. That means appProxy requires
with and without PAP for 50 times separately and Speedtest little resources while running. When it comes to network
gave test results from three indicators, download bandwidth, throughput, its download speed was 7 MB/s, which is equal
upload bandwidth, and latency. Results generated are averaged to the high bandwidth of 56 Mbps. High bandwidth means
and shown in Table I. to process more network flows at each moment for appProxy,
As Table I shows, value of network bandwidth and latency which may burden the battery of iPhone, but for appProxy, the
are close no matter it is with iMonitor or not. For the reason energy impact is still Low according to Xcode measurement.
that iMonitor takes some time dealing with incoming packets Compared with resource consumption of 360 VR Player (a
and forwarding them out, network bandwidth and latency with VR player available in Apple AppStore) shown in Figure 7,
iMonitor might be affected, which means smaller bandwidth we can see both of them do not consume too much energy. It
and bigger latency. However, according to our experiment, proves that resource consumption of CoM is low.
upload bandwidth with iMonitor is even greater than that
without iMonitor. After discussion, we think that is not a
coincidence, although upload bandwidth with and without
iMonitor is close. The reason for higher bandwidth of proxied
network is that PAP uploads information of each intercepted
packet to DMS. In conclusion, This experiment shows that
with PAP turned on, normal use of APPs on rule list will not
interfere and iMonitor does little adverse effect to network
throughput of iOS devices.
B. Resource Consumption
The main process of CoM is called appProxy. The memory
consumption of this process is limited by iOS to 15 MB; there-
fore, to make the APP run smoothly, we have to implement Fig. 7. Resource Consumption of 360 VR Player
 TABLE II
N ETWORK T ESTS

APP name version in iOS version in Android

WeChat 6.7.3 6.7.3
QQ International 5.0.2 5.0.2
Tik tok 3.8.1 3.8.1
QQ Music 8.9.5 8.9.5
iQiyi 9.10.0 9.10.0

C. Preliminary Application

Here we pose a preliminary application of mobile traffic

monitor and verify the truth that different OS versions do
influence the correctness of mobile traffic classifiers.
First, we chose five APPs available on both Android and Fig. 8. Experiment Result
iOS devices and their versions are shown in Table II. These
five APPs cover multiple APP categories, with chatting APP,
short video APP, video APP and music APP included. Next, V. CONCLUSION AND FUTURE WORK
we collected network flows (a network flow is defined by a This paper comes up with a method to passively monitor
quintuple (srcIP, srcPort, dstIP, dstPort, and protocol)) for each network traffic on iOS devices with a client-server VPN.
APP we mentioned above from an Android device and an iOS This is the first prototype ever proposed, which provides
device. With collected network flows, we did three sets of fine-grained, pure network traffic captured from iOS devices
experiments trying to recognize different APPs from network classified by APP. There has been a lot of similar work done
flows using a classifier implemented with the Random Forest for Android devices, but rarely did we see such work on iOS
algorithm, and the result is shown in Figure 8. devices. Our iMonitor system fills a vacancy on iOS devices
The first experiment is done using network flows collected of tools to monitor network traffic by APP. Experiments
from an Android device. We took 30% of the collected have shown that our system has little interference on user
Android network flows as test cases, and the others as training experience. For system resources, our client requires no more
cases. With scripts written in Python, we got a model for than 15MB of RAM and takes little CPU and storage on the
Android network flows, and the test result of this model’s phone. As for battery consumption, experiments have shown
accuracy to Android network flows is denoted by the left our proxy consume very little battery. For network throughput,
columns in Figure 8. The result is excellent, with an overall the implementation of our client has guaranteed that it can run
accuracy of 88.0609%, which means that this Android network up the bandwidth.
flow model is suitable for the Android network flow classi- Our iMonitor system provides excellent support for re-
fication. In the second experiment, we used model generated searchers dedicated in mobile network traffic classification,
for Android network flows on iOS network flow classification, mobile APP profile, user profile and so on. With our pilot
whose test result is denoted by the middle columns in Figure 8. development, researchers will have a more convenient way
As we can see, apart from iQiyi, the accuracy of classification to collect the mobile traffic of iOS devices with detailed
has decreased significantly. The result for iQiyi is abnormal, information. The research result can also be applied to the
but we think that is because iQiyi is a video APP, and most server-side of the iMonitor system. We may generate some
of its network flows are encoded video flows, which have privacy leakage detection models for network traffic, and use
common features both in Android and iOS. At last, we did this model to discover privacy leakage in users’ network traffic.
an experiment using all network traffic we collected, which IMonitor is still a prototype. Experiments show that it is
contained both Android and iOS network flows. Just like the powerful, but it is also extendable and can be stronger. With
first experiment, we took 60% of network flows as test cases, full access to proxied network flows, we can also do privacy
and the remaining network flows as training cases. The result leakage detection on the phone using the model generated
of this experiment is denoted by the right columns in Figure by former work. At the current phase, CoM is still simple.
8. As we can see, it is a lot better than the second result. However, to make CoM more attractive to users, in future
Through these experiments, we verified that network flows work, we are going to redesign the UI of the CoM, and
from different OS platforms differ from each other, which will add in some more useful functions in it. As for the server-
interfere with the performance of classifiers implemented with side, our ongoing plan is to make it as a platform providing
machine learning methods. We also showed our readers the support for researchers in the related field. It will provide
convenience and effectiveness to use our iMonitor system for ready-made models of some certain apps, with which we
network traffic collection of iOS devices. can classify network flow by APP. The server-side will also
provide services for researchers. Researchers can download [18] ICSI, “Haystack: Understanding the fate of your private data, project
our CoM and use our server to collect iOS network traffic. website and beta release,” 2018. [Online]. Available: haystack.mobi
[19] A. Nikravesh, H. Yao, S. Xu, D. Choffnes, and Z. M. Mao, “Mobilyzer:
By browsing a specific website, they will get their collected An open platform for controllable mobile network measurements,” in
network traffic and information related. Proceedings of the 13th Annual International Conference on Mobile
Systems, Applications, and Services. ACM, 2015, pp. 389–404.
VI. ACKNOWLEDGMENT [20] “Speedtest,” 2018. [Online]. Available: http://www.speedtest.net
[21] A. Gerber, J. Pang, O. Spatscheck, and S. Venkataraman, “Speed testing
This work is supported by the National Key R&D Program without speed tests: estimating achievable download speed from passive
of China under Grants 2017YFB0802300. measurements,” in Proceedings of the 10th ACM SIGCOMM conference
on Internet measurement. ACM, 2010, pp. 424–430.
R EFERENCES [22] Q. Xu, J. Erman, A. Gerber, Z. Mao, J. Pang, and S. Venkataraman,
[1] BrightEdge, “Brightedge 2018 mid-year mobile research roundup,” “Identifying diverse usage behaviors of smartphone apps,” in Proceed-
2018. [Online]. Available: https://videos.brightedge.com/research-report/ ings of the 2011 ACM SIGCOMM conference on Internet measurement
brightedge-research-roundup-2018.pdf conference. ACM, 2011, pp. 329–344.
[2] SmartInsights, “Mobile marketing statistics compilation,” 2018. [23] S. Dai, A. Tongaonkar, X. Wang, A. Nucci, and D. Song, “Networkpro-
[Online]. Available: https://www.smartinsights.com/mobile-marketing/ filer: Towards automatic fingerprinting of android apps.” in INFOCOM,
mobile-marketing-analytics/mobile-marketing-statistics/ vol. 13, 2013, pp. 809–817.
[3] Cisco, “Cisco visual networking index: Forecast [24] S. Miskovic, G. M. Lee, Y. Liao, and M. Baldi, “Appprint: automatic
and trends, 2017-2022,” 2018. [Online]. Available: fingerprinting of mobile applications in network traffic,” in International
https://www.cisco.com/c/en/us/solutions/collateral/service-provider/ Conference on Passive and Active Network Measurement. Springer,
visual-networking-index-vni/white-paper-c11-741490.pdf 2015, pp. 57–69.
[4] A. Sano and R. W. Picard, “Stress recognition using wearable sensors [25] V. F. Taylor, R. Spolaor, M. Conti, and I. Martinovic, “Robust smart-
and mobile phones,” in Affective Computing and Intelligent Interaction phone app identification via encrypted network traffic analysis,” IEEE
(ACII), 2013 Humaine Association Conference on. IEEE, 2013, pp. Transactions on Information Forensics and Security, vol. 13, no. 1, pp.
671–676. 63–78, 2018.
[5] X. Wei, L. Gomez, I. Neamtiu, and M. Faloutsos, “Profiledroid: multi- [26] N. V. Verde, G. Ateniese, E. Gabrielli, L. V. Mancini, and A. Spognardi,
layer profiling of android applications,” in Proceedings of the 18th “No nat’d user left behind: Fingerprinting users behind nat from netflow
annual international conference on Mobile computing and networking. records alone,” in Distributed Computing Systems (ICDCS), 2014 IEEE
ACM, 2012, pp. 137–148. 34th International Conference on. IEEE, 2014, pp. 218–227.
[6] M. Iliofotou, P. Pappu, M. Faloutsos, M. Mitzenmacher, S. Singh, [27] D. Herrmann, C. Gerber, C. Banse, and H. Federrath, “Analyzing
and G. Varghese, “Network monitoring using traffic dispersion graphs characteristic host access patterns for re-identification of web user
(tdgs),” in Proceedings of the 7th ACM SIGCOMM conference on sessions,” in Nordic Conference on Secure IT Systems. Springer, 2010,
Internet measurement. ACM, 2007, pp. 315–320. pp. 136–154.
[7] A. Shuba, A. Le, E. Alimpertis, M. Gjoka, and A. Markopoulou, [28] J. Ren, A. Rao, M. Lindorfer, A. Legout, and D. Choffnes, “Recon:
“Antmonitor: A system for on-device mobile network monitoring and Revealing and controlling pii leaks in mobile network traffic,” in
its applications,” arXiv preprint arXiv:1611.04268, 2016. Proceedings of the 14th Annual International Conference on Mobile
[8] N. Vallina-Rodriguez, A. Auçinas, M. Almeida, Y. Grunenberger, K. Pa- Systems, Applications, and Services. ACM, 2016, pp. 361–374.
pagiannaki, and J. Crowcroft, “Rilanalyzer: a comprehensive 3g monitor
on your phone,” in Proceedings of the 2013 conference on Internet
measurement conference. ACM, 2013, pp. 257–264.
[9] J. He, Y.-x. Yang, Y. Qiao, and W.-p. Deng, “Fine-grained p2p traffic
classification by simply counting flows,” Frontiers of Information Tech-
nology & Electronic Engineering, vol. 16, no. 5, pp. 391–403, 2015.
[10] H. Jie, Y. Yuexiang, Q. Yong, and T. Chuan, “Accurate classification of
p2p traffic by clustering flows,” China Communications, vol. 10, no. 11,
pp. 42–51, 2013.
[11] 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,”
ACM Transactions on Computer Systems (TOCS), vol. 32, no. 2, p. 5,
2014.
[12] Y. Song and U. Hengartner, “Privacyguard: A vpn-based platform to
detect information leakage on android devices,” in Proceedings of the 5th
Annual ACM CCS Workshop on Security and Privacy in Smartphones
and Mobile Devices. ACM, 2015, pp. 15–26.
[13] H. F. Alan and J. Kaur, “Can android applications be identified using
only tcp/ip headers of their launch time traffic?” in Proceedings of the
9th ACM Conference on Security & Privacy in Wireless and Mobile
Networks. ACM, 2016, pp. 61–66.
[14] A. Shuba, A. Le, M. Gjoka, J. Varmarken, S. Langhoff, and
A. Markopoulou, “Antmonitor: Network traffic monitoring and real-time
prevention of privacy leaks in mobile devices,” in Proceedings of the
2015 Workshop on Wireless of the Students, by the Students, & for the
Students. ACM, 2015, pp. 25–27.
[15] A. Rao, A. M. Kakhki, A. Razaghpanah, A. Tang, S. Wang, J. Sherry,
P. Gill, A. Krishnamurthy, A. Legout, A. Mislove et al., “Using the
middle to meddle with mobile,” CCIS, Northeastern University, Tech.
Rep., December, 2013.
[16] “Strongswan vpn client,” 2018. [Online]. Available: https://play.google.
com/store/apps/details?id=org.strongswan.android
[17] A. Razaghpanah, N. Vallina-Rodriguez, S. Sundaresan, C. Kreibich,
P. Gill, M. Allman, and V. Paxson, “Haystack: In situ mobile traffic
analysis in user space,” ArXiv e-prints, 2015.