Authors: Jakub Dalek (lead), Katie Kleemola (lead), Adam Senft (lead), Christopher Parsons, Andrew Hilts, Sarah McKune, Jason Q. Ng, Masashi Crete-Nishihata, John Scott-Railton, Ronald Deibert
Download PDF version.
Read the CBC News story.
Read our primer on mobile privacy and security.
Read the summary: Privacy and security issues with UC Browser.
Read the summary in Chinese: 啰嗦的松鼠：UC浏览器的隐私与安全问题
Section 1 – Introduction & Overview
UC Browser is the most popular mobile web browser in China and India, boasting over 500 million users. This report provides a detailed analysis of how UC Browser manages and transmits user data, particularly private data, during its operation. Our research was prompted by revelations in a document leaked by Edward Snowden on which the Canadian Broadcasting Corporation (CBC) was preparing a story. The CBC contacted us requesting our comment. The document, apparently prepared in 2012 by Canada’s signals intelligence agency, the Communications Security Establishment (CSE), noted the existence of security vulnerabilities in UC Browser. Given the Citizen Lab’s ongoing research into popular Asian communications tools, and the possibility of vulnerabilities affecting a large number of users, we decided to conduct an independent investigation of UC Browser. While media outlets are publishing a story about the CSE document, we cannot determine if the problems we identify in UC Browser and that are described in this report are identical to those referenced in the 2012 CSE document.
Summary of findings
We have identified a series of major security and privacy issues in the English language and Chinese language editions of the Android version of UC Browser. Our notification to the parent companies is described below in detail. We found that both versions of the application leak a significant amount of personal and personally-identifiable data; as a result, any network operator or in-path actor on the network can acquire a user’s personally identifiable information (including cellular subscriber information, mobile device identifiers, geolocation data, and search queries) through trivial decrypting of traffic or by observing unencrypted traffic. Specifically, the issues we found include:
Transmission of personally identifiable information and user search queries without encryption:
User data, including IMSI, IMEI, Android ID, and Wi-Fi MAC address are sent without encryption to Umeng, an Alibaba analytics tool, in the Chinese language version.
User geolocation data, including longitude/latitude and street name, are transmitted without encryption by AMAP, an Alibaba mapping tool, in the Chinese language version.
User search queries are sent without encryption to the search engine Shenma (in the Chinese language version) or Yahoo! India and Google (in the English language version).
Reason for concern: The transmission of personally identifiable information, geolocation data and search queries without encryption represents a privacy risk for users because it allows anyone with access to the data traffic to identify users and their devices, and collect their private search data.
Transmission of personally identifiable information and geolocation data with easily circumvented encryption:
Location and user data, including IMSI, IMEI, and data about nearby cellular towers and Wi-Fi access points, are sent with easily circumvented encryption by AMAP, an Alibaba mapping tool, in the Chinese language version.
Reason for Concern: UC Browser’s transmission of personally identifiable subscriber data, mobile device identifiers, and user geolocation data without effective encryption presents a security and privacy risk for users.
Private user data is retained on the device even after clearing the application’s cache:
In the Chinese language version, when users attempt to delete their private data by clearing the application’s cache their DNS lookups are not deleted.
Reason for concern: The cached record of DNS lookup data would allow for a third party with access to the device to identify the websites that a user visited.
This report is a continuation of our prior work examining the security and privacy of popular mobile applications in Asia. Our previous research includes investigations of censorship practices of search engines offered by Google, Microsoft, and Yahoo! in the Chinese market along with domestic Chinese search engine Baidu. In addition, we have analyzed keyword censorship and surveillance in TOM-Skype (the Chinese version of Skype at the time) and keyword censorship in Sina UC, another Chinese instant messaging platform. We are currently conducting comparative analysis of mobile chat applications used in Asia including WeChat, LINE, and KakaoTalk.
For those who may be interested in more context on mobile security and privacy, please see our general introduction to mobile communications. Click on the image below to read “The Many Identifiers in our Pockets.”
Figure 1: Overview of mobile device data transmission.
Notification
We disclosed our findings to Alibaba and UCWeb on April 15, 2015, and informed them that we would publish this report on or after April 29, 2015. Alibaba responded to our notification on April 19, 2015, indicating that their security engineers were investigating the issue. We followed up on April 23, 2015 to reiterate our intention to publish this report on or after April 29, 2015. As of May 19, 2015 we have not received further communication from Alibaba or UCWeb.
On May 19, 2015 we tested version 10.4.1-576 of the Chinese language version of UC Browser, which was downloaded from the uc.cn website. This version does not appear to send location data insecurely to AMAP as described in this report. However, the issues we describe in this report relating to insecure data transmission to the Umeng component, as well the lack of encryption on search queries, remain in this version. Users who use the Chinese version of UC Browser should upgrade the application and ensure they are running version 10.4.1-576 or above.
Section 2 – UC Browser: Quick Background
UC Browser is a mobile web browser for Android, IOS, Windows Phone, and other platforms. A Windows version was released in April 2015. The application is the flagship product of UCWeb Inc., a Guangzhou, China-based company founded in 2004. After an initial investment by e-commerce giant Alibaba, the two companies launched the joint mobile search service Shenma. Shenma reportedly has more than 100 million users per month. In June 2014, Alibaba purchased the remaining stake in UCWeb in the biggest ever merger of Chinese Internet firms.
UC Browser is among the most popular mobile apps in the Chinese Internet space. UC Browser claims to have more than 500 million registered users, and is reported to be the most popular mobile browser in China and India. Overall, the application is the fourth most popular mobile browser globally, and is behind only pre-installed Chrome, Android, and Safari browsers.
UCWeb Inc. claims the app has 100 million daily active users, while parent company Alibaba’s 2014 prospectus reported the number of active users at 264 million in June 2014. UC Browser was ranked as the second most popular app by usage in China in January 2013. The company has also increased its global push, and claims it has at least 10 percent market share in 10 different countries.
UC Browser offers a custom default homepage with links to search engines and social media integration, as well as news, weather, and shopping services. A set of features are aimed at reducing bandwidth usage on mobile clients. “Cloud download,” for example, allows users to send downloads directly to UDisk (a UC cloud offering) in order to save on bandwidth costs. In addition to this feature, UC Browser can act as an optional proxy and compress web sites it fetches to reduce bandwidth consumption.
Section 3 – Methodology and Technical Analysis
This section describes the methods we used to analyze UC Browser, and presents detailed findings from our analysis.
We isolated specific versions of the Chinese- and English-language builds of UC Browser for Android and analyzed their mobile (cellular network) data and Wi-Fi traffic. We also analyzed the application’s data retention and deletion practices. Our analyses revealed major privacy and security issues with all of the tested versions of UC Browser. Figure 2 highlights the major findings for the Chinese language version of UC Browser.
Figure 2: A visual summary of privacy and security issues presented by UC Browser.
Test Setup
We isolated specific versions of the Chinese- and English-language builds in order to examine UC Browser’s security and privacy features. Specifically, we monitored the data that was transmitted between the application and external servers. We were specifically interested in what, if any, personally identifiable information was transmitted by UC Browser, and whether encryption was used to secure those transmissions. We analyzed the state of the application, both in-idle state (soon after the app was opened) as well as during use of the app’s features, such as searching. Lastly, we examined the data UC Browser stored on the device, and whether that data was protected with encryption.
Tests were conducted within an Android emulator and on an Android handset. All traffic sent to and from the device was collected and analyzed using the packet-capture utility WireShark. We decompiled the downloaded APKS with APKtool and then analyzed the code for functionality related to the transmission of user data.
Versions Analyzed
We analyzed two versions of UC Browser for Android. We downloaded the two versions from different app stores: the Chinese-language version of UC Browser (UC浏览器) was downloaded in March 2015 from the Xiaomi mobile app store. Henceforth we will refer to this app as UC Browser (Chinese) to distinguish between versions. We downloaded the English version, henceforth UC Browser (English), in April 2015 from the UCWeb website. These two versions have differences beyond language: by default, the Chinese version uses Shenma (sm.cn) for search, while the English version uses Yahoo! India and Google; the Chinese version has links to China-based services such as Baidu, Sina Weibo, and Youku, while the English version uses services such as Google, Facebook, and Twitter.
Figure 3: Side-by-side comparison of UC Browser (Chinese) and UC Browser (English).
Figure 4: Side-by-side comparison of permissions requested during installation of UC Browser (Chinese) (left) and UC Browser (English) (right) versions of UC Browser.
Figure 4 shows the permissions that the Chinese and English versions of UC Browser requires when being installed on an Android device. For the purposes of this report, it is notable that the application requests access to phone status and identity, geolocation information, the ability to read Web bookmarks and history, as well as to extensive networking information. As discussed further in the report, UC Browser (Chinese) accesses phone identity and geolocation information and transmits it insecurely.
Table 1 summarizes the two versions of UC Browser we analyzed:
Platform
Version (Language)
Version
Date Downloaded
Source
Android
UC Browser (Chinese) (UC浏览器)
10.2.1_161
March 12, 2015
Xiaomi App Store: http://app.mi.com/detail/1363
Android
UC Browser (English)
10.4.1.565
April 10, 2015
Direct from UC website: http://www.ucweb.com/ucbrowser/download/android.html
3.1 UC Browser (UC浏览器) Chinese language version 10.2.1_161
This section describes our findings from analyzing the Chinese language version of UC Browser (UC浏览器), downloaded from the Xiaomi mobile app store. Our test results are summarized in Table 2:
Table 2: Summary of test results for UC Browser (Chinese).
Test
Mode
Results
Idle test
Cell only
The AMAP component of UC Browser (Chinese) contacts apilocate.amap.com, and sends user and device identifiers (IMSI, IMEI) and location data (cell tower data) with easily circumvented encryption.
The Umeng component of UC Browser (Chinese) sends device identifiers (including IMSI, IMEI, Android ID) without encryption.
Idle test
Cell + Wi-Fi
The AMAP component sends, with easily circumvented encryption, the same data as noted in the row above (“Cell only” mode). In addition, it sends device Wi-Fi MAC address, SSID, and MAC address of the Wi-Fi access point to which the user is connected, and nearby wireless access points.
The Umeng component sends the same device identifiers as noted in the row above (“Cell only” mode), with the addition of the device Wi-Fi MAC address, without encryption.
Search
Cell only & Cell + Wi-Fi
Search queries using the search bar are sent to Alibaba’s Shenma search engine without encryption.
Data storage
Cell only & Cell + Wi-Fi
After clearing the application’s private data, the cached record of DNS lookup data remains.
Idle test
In our first test, we launched the application, let UC Browser (Chinese) idle for 270 seconds, and collected all network traffic sent to and from the device. We then analyzed that traffic to determine what data was being sent and its destination. We performed the test first by connecting the mobile device to the Internet using a cellular connection, and, second, by connecting the device to the Internet using a Wi-Fi network.
Testing UC Browser (Chinese)’s Cellular-Only Communication
Upon starting the application, the application communicated with the following hosts over HTTP:
Figure 5: Hosts communicated with by UC Browser (Chinese) within 270 seconds of launching the app
Easily decrypted data sent to AMAP
As seen in Figure 5, the majority of communications (57% of HTTP packets in our 270 second sample) are between the application and apilocate.amap.com. AMAP is a mobile mapping application that was originally developed by Autonavi, a company acquired by Alibaba in April 2014. AMAP is estimated to have more than 100 million users.
Investigating these communications further, we saw that a typical exchange with apilocate.amap.com looked as follows:
Figure 6: Sample communication between UC Browser (Chinese) and apilocate.amap.com. The user-agent string indicates this communication is from “AMAP Location SDK Android 1.0.5.” We have redacted personally identifiable data.
As we were interested in determining what, if any, data the application transfers from the device, the block of data sent to apilocate.amap.com was of interest. We used a freely available tool, pyhttpextract, to decipher the contents of this encoded data block. After using this tool, we saw that UC Browser (Chinese) sent the following data to apilocate.amap.com:
Figure 7: Deciphered communication between UC Browser (Chinese) and apilocate.amap.com. Personally identifiable data redacted with asterisks.
The encoded data sent within the ‘<sreq>’ structure intrigued us because it was a relatively large block of data. Its size suggested that it might contain user data. To confirm if user data was present we first analyzed how the data was encrypted. Using apktool we decompiled UC Browser (Chinese) to see how the application created and serialized the ‘<sreq>’ structure. After decompiling, we looked for the string ‘sreq’ in the outputted code and found this in a directory associated with the com/aps class (Android programs often incorporate a mix of components, called classes, sometimes from different developers).
Since the com/aps/* directory serializes the ‘sreq’ structure in which we were interested, we next examined this directory to see which .smali files (code format used by Android) translated to which .java filenames:
Figure 8: Mapping of smali files in com/aps directory to java source code.
We examined the file Aes.java in searching for the component of the application that encrypted data in the ‘sreq’ structure (AES is a widely used form of encryption). The file showed that encryption was performed using symmetric AES/CBC encryption that used the hard-coded key ‘autonavi_amaploc’. The encryption process is shown in Figure 9:
Figure 9: Aes.java smali code showing AES/CBC encryption with a hard-coded key.
The use of symmetric encryption with a hard-coded key means that anyone who knows the key can decrypt UC Browser (Chinese) traffic in transit. Moreover, key holders can also retroactively decrypt any historical data that they have collected or obtained.
We used a standard AES decryption tool to decrypt the ‘sreq’ data structure in order to demonstrate that retroactive decryption was possible. After formatting the structure for readability, the data sent looked as follows:
Figure 10: Decrypted data sent via AMAP service. Personally identifiable data redacted with asterisks.
The data sent to apilocate.amap.com included a number of unique identifiers. The first set referred to the mobile device itself: the IMSI, IMEI, and unique user data related to this installation of UC Browser (Chinese). The second set referred to details of the cell tower to which the device is connected: the Mobile Country Code (MCC), Mobile Network Code (MNC), Location Area Code (LAC), Cell Tower ID, and the cell tower signal strength. In aggregate, these sets of information can be used to identify the cellular subscriber, the physical handset, and the physical location of the device.
After transmitting this location information, the application received an unencrypted response that included the longitude/latitude of the user (the ‘cenx’ and ‘ceny’ values seen below), as well as the specific street name where the user was located, as shown below in Figure 11:
Figure 11: Unencrypted response received by UC Browser (Chinese).
Such identifications are problematic because, using the information and the rate at which the application transmits it, we can determine a cell tower location with considerable accuracy and thus geolocate the person using the application. As an example, we were able to pinpoint the location of our lab where we conducted the testing, as shown in Figure 12:
Figure 12: Example of location identified from MCC, MNC, LAC, and CellID.
In summary, we strongly suspect that AMAP is the component of UC Browser (Chinese) that is responsible for transmitting the geolocation information. Our belief is based on the fact that the user-agent string (“AMAP Location SDK Android 1.0.5”), the location where the data is sent (apilocate.amap.com), and the text of the hard-coded key (‘‘autonavi_amaploc”) all reference AMAP. Given the apparent integration between AMAP and UCWeb we believe that it is likely that AMAP was incorporated into UC Browser (Chinese) to provide mapping and geolocation functionality.
Unencrypted data transfer to Umeng
As seen in Figure 5, UC Browser (Chinese) also periodically contacted utop.umengcloud.com and upoll.umengcloud.com when idle. Umeng is a mobile analytics service that is reportedly used by over 180,000 applications. It was purchased by Alibaba in 2013. The data structure sent, unencrypted, to utop.umengcloud.com hosts looked as follows:
Figure 13: GET request made to utop.umeng.cloud with a cellular Internet connection showing that application sends IMSI, IMEI, Android ID, and build serial number without encryption. Personally identifiable data redacted with asterisks.
A number of unique personal identifiers are included in this data structure. This included the IMEI, IMSI, device Android ID (‘c6’), and the build serial number (‘c5’). Like AMAP, we believe it is likely that Umeng was incorporated into UC Browser (Chinese) to provide in-app analytics.
Testing UC Browser’s Wi-Fi Communication
Easily decrypted data sent to AMAP
Upon starting the application and letting it idle for 270 seconds while connected to a Wi-Fi network, we found that UC Browser (Chinese) sent the same easily-decrypted user data seen in Cell only communication. However, in addition the application sent data about nearby Wi-Fi access points, including their MAC address. These data elements are identified in Figure 14:
Figure 14: Data sent by UC Browser (Chinese) to AMAP when Wi-Fi is enabled. Personally identifiable data redacted with asterisks.
Unencrypted data transfer to Umeng
When connected to a Wi-Fi network, personal user data is also sent unencrypted to Umeng. In addition to the data sent while connected to a cell network, the application also sent the device’s Wi-Fi MAC address. Figure 15 shows a sample of traffic sent to utop.umengcloud.com while connected to a Wi-Fi network:
Figure 15: Traffic sent to utop.umengcloud.com during idle. Personally identifiable data redacted.
Re-formatting the above traffic for readability shows the following GET request to utop.umengcloud.com:
Figure 16: GET request made to utop.umengcloud.com with Wi-Fi enabled showing that IMSI, IMEI, Android ID, and device Wi-Fi MAC address are sent unencrypted. Personally identifiable data redacted with asterisks.
In summary, when connected to a Wi-Fi network, the IMSI, IMEI, Android ID, and Wi-Fi MAC address are sent unencrypted by UC Browser (Chinese) to umengcloud.com.
Examining the Search Functionality of UC Browser (Chinese)
The Chinese version of UC Browser uses the mobile search engine Shenma, a joint venture between UCWeb and Alibaba. Search queries that are entered into the search bar were sent without encryption to http://m.sm.cn, as seen in Figure 17:
Figure 17: Search for “cntower” using Shenma mobile search engine via UC Browser (Chinese) search bar.
Insecure Data Deletion in UC Browser (Chinese)
As part of our research we conducted tests to determine what, if any, personal user data was stored on the device. We began by selecting the option in the application allowing users to delete private information from the device, such as cookies and browser history. After selecting this option, we examined whether user data remained on the device by checking the cache directory for the application. While most user data was deleted, a record of the application’s DNS lookups remained, as shown in Figure 18:
Figure 18: DNS records found in cache after private information was deleted.
This DNS data was stored in the cache as a serialized LinkedHashMap, and persisted even after all other data in the cache had been cleared using the application’s feature to clear private browsing data. There was sufficient plaintext remaining that the records could be read using a simple text editor. In other words, even if a user attempts to clear browsing records their personal data remains available for scrutiny and can be trivially accessed.
3.2 UC Browser (English) language version 10.4.1.565
We next conducted tests of the English language edition of UC Browser version 10.4.1.565. This version was downloaded as an APK directly from the UCWeb English-language website. Our test results are summarized in Table 3:
Table 3: Summary of test results for UC Browser (English).
Test
Both
Results
Idle test
Cell only & Cell + Wi-Fi
No issues identified
Search
Cell only & Cell + Wi-Fi
Search queries sent through the search bar are sent unencrypted to Yahoo! India
Search queries sent through the address bar are sent unencrypted to Google
Data storage
Cell only & Cell + Wi-Fi
No issues identified
Idle test
We performed the same idle test described previously with the English language version: the application was launched, left idle for 270 seconds, and all traffic sent to and from the device was collected. We first performed the test by connecting the mobile device to the Internet using a cellular connection and, second, by connecting the device to the Internet using a Wi-Fi network.
Our analysis showed that UC Browser (English) did not send and receive traffic through the AMAP or Umeng component as in the Chinese language version. We were not able to identify any easily decrypted traffic sent in the English language version.
Search
UC Browser (English) has two methods for performing web searches. The first method is by tapping the “Search” button shown in the upper-right hand corner of the application. The second method is by entering a search term in the address bar to the left of the search button. Both of these methods can be seen in the following screenshot:
Figure 19: Screenshot of search features of UC Browser (English). Both the “Enter URL” and “Search” fields can be used to perform a web search.
We performed searches through both methods and observed the traffic sent and received by UC Browser (English). Performing the search through the search bar sent data unencrypted to Yahoo! India search, as shown in this packet capture:
Figure 20: Packet capture of search for ‘toronto bluejays’ (highlighted in blue) performed using search bar in UC Browser (English). Search query is sent unencrypted to Yahoo! India.
In addition, the results of such a search are displayed with a green checkmark at the far left of the search bar:
Figure 21: Search results for an unencrypted search to Yahoo! India with a green checkmark.
The use of this green checkmark could lead to some confusion with users, as most web browsers use a green icon to the left of the search bar to reflect an encrypted connection. UC Browser (English) displays a green padlock to the left of the browser bar if the HTTPS-encrypted version of a site is opened manually in a browser.
Next, we performed a search by entering a search term in the address bar of UC Browser (English). This search was sent unencrypted to Google search:
Figure 22: Packet capture of search for “go jays” (highlighted in blue) performed using the address bar of UC Browser (English).
In summary, both methods of performing a search in UC Browser (English) sent the search query unencrypted to either Yahoo! India or Google. The standard web version of each of these search engines uses HTTPS encryption by default.
Data storage
Finally, we analyzed how UC Browser (English) stored personal user data on the device. The English language version, unlike the Chinese language version, did not store DNS lookup data as part of the private browsing data. Further, using the option within the application to delete private browsing data did delete all such data.
Section 4 – UC Browser Leaks Sensitive User Data
Our analysis shows that both versions of UC Browser leak information to third parties, but that privacy and security concerns for the Chinese language UC Browser are much greater. The Chinese UC Browser version we tested (“UC Browser (Chinese)” in this report) leaks a significant amount of personally identifiable information, raising major security and privacy concerns. The leakage of the IMSI, IMEI, and geolocational information can identify a cellular subscriber, the device that they are using, and their specific location. As a result of the weak encryption used by UC Browser, any party with access to the data traffic — either real-time or historical — can link specific devices to specific places at specific times. And if the decrypting party has a large volume of data they can track subscribers vis-a-vis their mobile devices as they move around the world.
Just by installing and opening UC Browser (Chinese), users unwittingly expose a significant number of personal identifiers and location information to numerous third parties. Although users must agree to grant the application permission to access personal identifiers and location data, it is not made clear to the user how this data will be shared. This exposed information includes:
Device info sent unencrypted: IMSI, IMEI, Android ID, and Wi-Fi MAC address
Search queries sent unencrypted
Location data received unencrypted: longitude/latitude and street name
Device and location sent with breakable encryption: IMSI, IMEI, MCC, MNC, LAC, CellId, nearby cellular towers and Wi-Fi access points
In many political jurisdictions (including China and India) it is common for authorities to require telecommunications companies, cellular providers, and Internet cafes to share the data they collect with security agencies as a condition of obtaining an operating license. By leaking a large volume of fine-grained data points to multiple network operators, the UC Browser app is increasing the risks to its users that such data may be used against them by authorities, criminals, or other third parties.
The data leakages we outline are particularly problematic for individuals who use their devices to engage in sensitive communications or for whom disclosing their physical location could place them at increased risk. Similarly, individuals concerned with protecting sensitive activities related to their work while traveling or communicating should be concerned about the potential for industrial espionage.
While we concluded that UC Browser (English) leaks considerably less identifying information, users might be surprised to realize that, despite the presence of an icon suggesting security in one of the search bars, their search terms are transmitted without encryption to Google and Yahoo! India servers.
On the issue of mobile security and privacy
Ultimately, the concerns identified here with respect to UC Browser demonstrate the larger challenges of ensuring user security and privacy within the burgeoning market for mobile applications. The mobile ecosystem is complex and multi-layered, involving large volumes of personally identifiable information that are transmitted across networks, devices, operating systems, and applications owned and operated by numerous private companies across many political and regulatory jurisdictions. Such a complex system underscores the importance of systematically evaluating the privacy and security of mobile communications as they become integral to the everyday lives of individuals and communities worldwide.
Would Encryption Solve UC Browser’s Problems?
We have highlighted the lack of encryption for personally identifiable data as a key reason for concern over UC Browser. Encrypting data that is this sensitive certainly represents an industry best practice, and it is unclear why only the English version seems to implement encryption consistently. Modifying the Chinese version to match the encryption used in its English counterpart could be an important step in increasing user security, as would encrypting queries to Google and Yahoo! India in the English version.
However, even if all data were strongly encrypted, this step would simply simply make it more difficult for unauthorized parties to read the contents of data transmissions. Encrypting sensitive user data can limit the number of actors who can access the data but does not prevent the inappropriate collection, retention, and analysis of the data by application developers and their commercial partners. Put bluntly: increases in transport security do not necessarily improve corporate data handling practices.
The core advantage of better encrypting data traffic is to engage, and hopefully make more transparent, the processes that government agencies and other third parties must engage in to access information that is collected, retained, and processed by application developers. In many jurisdictions, authorities will first have to obtain a court order before lawfully accessing the application developers’ data. Nevertheless, when data is held in jurisdictions where this process is not enshrined, or where there are strong incentives to share the data, encryption alone does not solve the problem.
Acknowledgments
This project was supported by the John D. and Catherine T. MacArthur Foundation.
The post A Chatty Squirrel: Privacy and Security Issues with UC Browser appeared first on The Citizen Lab.