Web content is an essential element for large language model (LLM) services, supporting both training and inference processes. To manage the content access of web bots from LLM service vendors (i.e., LLM bots), web content publishers are increasingly incorporated content access rules into robots.txt, a long-established web content management protocol. However, the rise of proprietary LLM bots, such as OpenAI's ChatGPT-User and Google's Google-Extended, has raised concerns about the transparency of web content access and whether these bots adherence to robots.txt rules. However, there is limited understanding of these LLM bots, concerning their impact on web publishers and broader web content governance. To fill this gap, we present a systematic analysis of 18 LLM bots on 582,281 robots.txt files. Our findings reveal a significant increase in robots.txt rules associated with LLM bots, particularly in domains that fall into the finance and news category. Despite the heightened integration, web publishers face challenges in managing robots.txt configurations due to the complexity of the LLM ecosystem and the involvement of third-party brokers. Furthermore, we identified several cases of robots.txt violations, including instances where LLMs memorized web content from restricted domains, and where ChatGPT-User ignored robots.txt and accessed restricted content. These results highlight the gaps in the current web content governance and underscore the need for enforceable content management mechanisms to respect web publishers' intentions and content control.

As the COVID-19 pandemic fundamentally reshaped the remote life and working styles, Voice over IP (VoIP) telephony and video conferencing have become a primary method of connecting communities together. However, little has been done to understand the feasibility and limitations of delivering adversarial voice samples via such communication channels.

The recent wave of in-browser cryptojacking has ebbed away, due to the new updates of mainstream cryptocurrrencies, which demand the level of mining resources browsers cannot afford. As replacements, resource-rich, loosely protected free Internet services, such as Continuous Integration (CI) platforms, have become attractive targets. In this paper, we report a systematic study on real-world illicit cryptomining on public CI platforms (called Cijacking). Unlike in-browser cryptojacking, Cijacks masquerade as CI jobs and are therefore more difficult to detect, since legitimate CI workflows such as container image building and testing also entail intensive computing. In our research, we leveraged the critical mining information the adversary has to specify, such as wallet addresses and mining pool domains, to recover the attack traces from GitHub repositories and the log files on CI platforms, leading to the discovery of 1,974 Cijacking instances, 30 campaigns across 12 different cryptocurrencies on 11 mainstream CI platforms. Further, our study unveils the evolution of attack strategies, in response to the protection put in place by the platforms, the duration of the mining jobs (as long as 33 months), and their lifecycle. Further discovered is the revenue of the attack, over ${\$}$20,000 per month. Since robust detection of cryptojacking is known to be hard, we developed a novel technique, called Cijitter, to strategically inject delays to the execution of a CI workflow to disproportionally penalize the mining jobs that need to work on a series of tasks under time constraints. Our analysis and evaluation, as conducted on both benchmarks and common CI jobs, show that our approach substantially suppresses the miner’s revenues, rendering them unprofitable, but only has small impacts on the performance of CI jobs and developer productivity (94.3% of CI jobs see a less than 10% delay).

Mobile apps include privacy settings that allow their users to configure how their data should be shared. These settings, however, are often hard to locate and hard to understand by the users, even in popular apps, such as Facebook. More seriously, they are often set to share user data by default, exposing her privacy without proper consent. In this paper, we report the first systematic study on the problem, which is made possible through an in-depth analysis of user perception of the privacy settings. More specifically, we first conduct two user studies (involving nearly one thousand users) to understand privacy settings from the user's perspective, and identify these hard-to-find settings. Then we select 14 features that uniquely characterize such hidden privacy settings and utilize a novel technique called semantics- based UI tracing to extract them from a given app. On top of these features, a classifier is trained to automatically discover the hidden privacy settings, which together with other innovations, has been implemented into a tool called Hound. Over our labeled data set, the tool achieves an accuracy of 93.54%. Further running it on 100,000 latest apps from both Google Play and third-party markets, we find that over a third (36.29%) of the privacy settings identified from these apps are “hidden”. Looking into these settings, we observe that they become hard to discover and hard to understand primarily due to the problematic categorization on the apps' user interfaces and/or confusing descriptions. Further importantly, though more privacy options have been offered to the user over time, also discovered is the persistence of their usability issue, which becomes even more serious, e.g., originally easy-to-find settings now harder to locate. And among all such hidden privacy settings, 82.16% are set to leak user privacy by default. We provide suggestions for improving the usability of these privacy settings at the end of our study.

As a critical feature for enhancing user experience, cross-app URL invocation has been reported to cause unauthorized execution of app components. Although protection has already been put in place, little has been done to understand the security risks of navigating an app's WebView through an URL, a legitimate need for displaying the app's UI during cross-app interactions. In our research, we found that the current design of such cross-WebView navigation actually opens the door to a cross-app remote infection, allowing a remote adversary to spread malicious web content across different apps' WebView instances and acquire stealthy and persistent control of these apps. This new threat, dubbed Cross-App WebView Infection (XAWI), enables a series of multi-app, colluding attacks never thought before, with significant real world impacts. Particularly, we found that the remote adversary can collectively utilize multiple infected apps' individual capabilities to escalate his privileges on a mobile device or orchestrate a highly realistic remote Phishing attack (e.g., running a malicious script in Chrome to stealthily change Twitter's WebView to fake Twitter's own login UI). We show that the adversary can easily find such attack "building blocks" (popular apps whose WebViews can be redirected by another app) through an automatic fuzz, and discovered about 7.4% of the most popular apps subject to the XAWI attacks, including Facebook, Twitter, Amazon and others. Our study reveals the contention between the demand for convenient cross-WebView communication and the need for security control on the channel, and makes the first step toward building OS-level protection to safeguard this fast-growing technology.

Android allows developers to build apps with app installation functionality themselves with minimal restriction and support like any other functionalities. Given the critical importance of app installation, the security implications of the approach can be significant. This paper reports the first systematic study on this issue, focusing on the security guarantees of different steps of the App Installation Transaction (AIT). We demonstrate the serious consequences of leaving AIT development to individual developers: most installers (e.g., Amazon AppStore, DTIgnite, Baidu) are riddled with various security-critical loopholes, which can be exploited by attackers to silently install any apps, acquiring dangerous-level permissions or even unauthorized access to system resources. Surprisingly, vulnerabilities were found in all steps of AIT. The attacks we present, dubbed Ghost Installer Attack (GIA), are found to pose a realistic threat to Android ecosystem. Further, we developed both a user-app-level and a system-level defense that are innovative and practical.