Blocking Without Breaking: Identification and Mitigation of Non-Essential IoT Traffic

Abstract

Despite the prevalence of Internet of Things (IoT) devices, there is little information about the purpose and risks of the Internet traffic these devices generate, and consumers have limited options for controlling those risks. A key open question is whether one can mitigate these risks by automatically blocking some of the Internet connections from IoT devices, without rendering the devices inoperable. In this paper, we address this question by developing a rigorous methodology that relies on automated IoT-device experimentation to reveal which network connections (and the information they expose) are essential, and which are not. We further develop strategies to automatically classify network traffic destinations as either required (i.e., their traffic is essential for devices to work properly) or not, hence allowing firewall rules to block traffic sent to non-required destinations without breaking the functionality of the device. We find that indeed 16 among the 31 devices we tested have at least one blockable non-required destination, with the maximum number of blockable destinations for a device being 11. We further analyze the destination of network traffic and find that all third parties observed in our experiments are blockable, while first and support parties are neither uniformly required or non-required. Finally, we demonstrate the limitations of existing blocklists on IoT traffic, propose a set of guidelines for automatically limiting non-essential IoT traffic, and we develop a prototype system that implements these guidelines.

Your Echos are Heard: Tracking, Profiling, and Ad Targeting in the Amazon Smart Speaker Ecosystem

“…A difference between our findings and the ones of the above works is that Amazon smart speakers in our study contact additional endpoints from Amazon, skills vendors, and third-parties that have never been reported before. For example, with respect to the endpoints reported in a 2021 study [72], we have observed 4 new Amazon domains (acsechocaptiveportal.com, amazon-dss.com, a2z.com, amazonalexa.com. ), 2 skills-specific endpoints (see skills row in Table 1) and 12 new third-party endpoints (see third party row in Table 1).…”

“…Having such interface unlocked for developers and auditors would reveal the actual data being shared. Another example of a possible user defense is to selectively block network traffic that is not essential for the skill to work (e.g., using an approach similar to [72]). TABLE 14: Endpoint organizations observed in the network traffic from skills run on the Amazon Echo: only 32 skills exhibit non-Amazon endpoints.…”

“…Several IoT works have measured network traffic to detect data sharing. For example, [73], [65], [79], [80], [72] have shown that tracking is common in several IoT platforms, regardless of the presence of specific apps/skills. A difference between our findings and the ones of the above works is that Amazon smart speakers in our study contact additional endpoints from Amazon, skills vendors, and third-parties that have never been reported before.…”

Blocked or Broken? Automatically Detecting When Privacy Interventions Break Websites

“…Finally, recent work by Mandalari et al [19] describes a system that determines when privacy interventions break user desirable systems, but for internet-of-things devices instead of websites. Their system automatically distinguishes necessary traffic flows from noncore flows, and only applies privacy protections (i.e.…”

Peekaboo: A Hub-Based Approach to Enable Transparency in Data Processing within Smart Homes (Extended Technical Report)

“…Peekaboo's hub is similar in spirit to cloudlets [67], but the key difference is that the computation running on the hub is structured and enforced using the operator-based manifest. Peekaboo is also inspired by past smart home hub/gateway/firewall projects [11], [14], [39], [51], [76]. Peekaboo has two major differences.…”