Understanding Dark Patterns in Home IoT Devices

3.3.1 Environment Isolation.

Compared to a neatly isolated environment for testing websites and apps, the single-network, live lab environment presented unique challenges for IoT data collection. Pilot study interactions revealed the potential influence of interaction history or pre-existing data, and logged-in devices prevented insight into device and account setup experiences. With all devices on the same network, some devices and apps could communicate with each other (e.g., light bulbs connected to several smart hub apps, or Amazon devices connected to the same app). This blurred distinctions between similar devices: in some cases, we received notifications from devices we were not intending to interact with if that device shared the same app as the device we were inspecting.

To mitigate these issues during our final data collection, we factory reset each device and—like prior work [26, 42]—created a fresh user account for each device as needed.¹ We also provisioned a separate, isolated network solely for this study, such that only one controller phone and the currently-examined device would be connected to the network at the same time (all other lab devices remained on the original network).

3.3.2 Embedded Browsers and OS Interfaces.

Some devices and companion apps loaded web pages using built-in browsers. Unlike prior work [42], we included dark patterns discovered in such web pages if these (1) transmitted login information or (2) delivered information promised by previous device/app menus or features, but did not count dark patterns in embedded pages that served tertiary purposes. For example, the Google Nest Mini app contains menu items that lead to a logged-in shopping web page hosted by Google that allows users to purchase other Google Home products. In this case, we inspected web pages relevant to the shopping task, but did not visit Google Account pages or other product pages hyperlinked from the same page. This restriction avoids incorporating the entirety of vendor websites into our analysis of specific IoT products. Similarly, some devices and controlling smartphones share the same manufacturer (e.g., HomePod and iPhone; Google Home with Android devices) and leverage both OS-level and companion-app-level interfaces to control the smart device. Thus, we retained dark patterns found in the OS in our dataset if they were encountered naturally within our interaction script and did not explore other OS interfaces beyond those relevant to IoT interactions.

3.3.3 Speaker Interactions.

In the pilot study, we asked our speakers a small set of common queries, suggested verbatim by device documentation and lists from popular consumer electronics websites [36, 50, 83]. These lists, however, tended to mention highly specific one-off use cases like shopping for an item, playing music, or inquiring about the weather. Other desired interactions, like navigating settings or account deletion, were not as readily found.

To keep our speaker interactions as consistent as possible with physical devices and companion apps, we constructed our own list of commands that would exercise the sample commands listed above, as well as attempt to navigate settings and conduct exit interactions (e.g., delete the associated account). We conducted smaller tests of these commands across all three speaker ecosystems in our study to identify ecosystem-specific functionality (like the presence of a guest mode, or the ability to mute the mic by voice command) and test the limits of available voice-controlled actions. Account and device setup interactions were omitted from this list, as we discovered that all speakers in our tests required companion-app-based setup prior to use.

3.3.4 Novel Dark Patterns.

Based on the results of the pilot experiment we added 12 new dark patterns to our codebook. Throughout the pilot experiments, the authors noted all unlabeled device and companion-app behaviors that fit within one or more broad classifications of dark patterns [39, 67]. The authors discussed these behaviors while co-annotating recordings, comparing independent annotations, and when reviewing intermediary analyses. The authors agreed that these behaviors fell within high-level dark pattern categorizations and traits, but were not specifically captured by prior codebooks used during the pilot experiment [26, 42]. We present novel dark patterns in bold in Table 2. We discuss these novel patterns and their implications in section 4.2.

3.4.1 Navigating Interfaces.

Our approach to interactions relied on interaction scripts drawn from prior work [26, 42] with modifications stated in section 3.3. Our script was designed to uncover and explore as many possible features—including settings categories—afforded by each smart device across companion apps and device hardware (which included voice-controlled and visual interfaces). We conducted device and account setup, traversed available features and settings, and performed exit interactions (e.g., logout, device disassociation, data or account deletion, etc.) where possible for each device. When setting up an account we agreed to all options that were preselected or preferred in visual hierarchies. In cases where dark patterns did not steer us towards particular choices we chose the first available option, from top to bottom and from left to right. We focused on traversing as many main features or options as were intuitively provided within the companion app or device interface. Likewise, we conducted a best-effort approach to visit all available settings, subject to limitations where a device’s settings navigation would require an unusually long time to traverse (e.g., each setting was individually paginated, requiring multiple page loads to traverse). In these cases we visited a subset of settings for reasonable coverage.

3.4.2 Device Interactions.

We factory-reset each device, connected them to the isolated network, configured devices using a unique e-mail address for registration if required, and used factory-reset Google Pixel 3 and iPhone 6 phones for any app-based interactions. We recorded companion app interactions using screen recording software and took video footage of device interactions using a smartphone camera on a tripod.

Each IoT device test began with an attempt to interact with the physical device. When prompted by the device or when apparent that the device required a companion app for smart features, we installed the relevant app on a compatible smartphone, began screen recording, and interacted with the device through the app. We followed device or app guidance when determining which modality to use and traversed any remaining features or device-specific settings in the device or app after completing as many available actions as possible for the primary purpose(s) of the device. Following our traversal, we examined any available app-level or physical-device settings and attempted any available exit interactions.

3.4.3 Companion App Interactions.

To preserve ecological validity, we sought to interact with IoT devices as directly as possible, as an average user might. Thus we refrained from using companion apps unless it was the only way to control a device or the device required us to. Of our 57 devices, only 12 could be fully interacted without a companion app: the media devices (e.g., Apple TV and Roku TV), the TVs, and the fridge. If a device prompted login but did not require the companion app, we used a desktop browser for account registration.

We identified cases where the same companion app controlled multiple devices in our tests, which allowed us to save time without loss of coverage by interacting in full only once for all its corresponding devices. For example, both Alexa speakers and the Amazon Plug use the Amazon Alexa app; the Ring Camera, Ring Chime, and Ring Doorbell all share the Ring app; all three Google speakers and the Chromecast use Google Home, etc. In these cases we fully traversed each app only once, and otherwise only interacted with the app as necessary per-device, on demand—typically for fresh account or device setup, or managing relevant settings.

3.4.4 Annotation Procedure and Validation.

We manually annotated the video recordings produced by our device and companion app interactions for dark patterns using the codebook in Table 2. Prior studies using similar methods operationalized dark patterns as binary variables that were either present or not present in each sample [26, 42]. In contrast, Mathur et al. [67] counted the number of each type of dark pattern that appeared on each website and web page during automated crawls. We use both approaches in this study. To achieve this, we used a video annotation software that facilitated observation and coding for compound or multiple instances of dark patterns, and additionally supported timestamps and image coordinates for each label [28, 29]. When encountering multiple dark patterns on the same screen or video frame, we examine the presented interface elements holistically and consider whether the dark patterns appear to be deployed towards a shared immediate purpose. If so, we select relevant designs in a frame and annotate the selection with multiple dark patterns.

All recordings were annotated by the first author. In cases where the first author felt a label was uncertain, the second author was consulted to achieve consensus.

We validated our device annotations by assessing inter-coder reliability between the first two authors. Specifically, the two authors independently annotated the recordings of one device per type and we compute Cohen’s κ to assess agreement. Both authors annotated 585 labels, with 75 and 80 positive unique (binary) labels, and 510 and 505 negative unique labels. For total instance counts, the authors note 169 and 161 positive frequency labels, respectively, and 416 and 424 negative labels per-pattern. For the final dataset, we use the first author’s labels by default to maintain consistency across all device annotations.

Table 3 presents the κ agreement statistics with respect to unique and total dark patterns. Across all 52 patterns in our study, we note κ=0.56 and κ=0.42 for unique and total dark pattern counts respectively, both of which are in the moderate agreement range (0.41 < κ < 0.60) [54]. Given the comparatively large size of our codebook and high granularity of individual dark pattern cases, we also grouped our inter-rater labels according to the context categories in our codebook (adapted from Gunawan et al. [42]) and the 16 dark pattern types from Di Geronimo et al. [26].² We observe improvements when calculating κ for each grouped categorization: unique-count κ=0.60 (mildly significant [54]) for our context categories and κ=0.67 (significant [54]) for the Di Geronimo et al. [26] categories.³ These results demonstrate more agreement between our labelers at the granularity of categories than at the granularity of specific dark patterns.

Figure 2:

View Figure

In the context of our codebook size, manual methods, video length, and corpus-to-validation sample diversity, we consider our agreement consistent with similar studies’ measures [26, 42] and therefore sufficient to proceed with as a reasonable approximation of overall agreement to popular taxonomies. However, as human measurement remains a challenging part of dark patterns study, we further discuss limitations of such methods in section 5.4.

4.1.1 Dark Pattern Popularity.

We first count unique dark patterns and per-pattern frequency for all patterns in our codebook across all devices, to broadly quantify dark patterns in IoT experiences. The cumulative distributive function (CDF) of unique and total dark patterns per device in Figure 2 shows disparity between binary, unique presence counts (whether a dark pattern is found in a device interaction or not) and total frequency counts (how many dark patterns appear in a device interaction, including multiple instances of the same pattern). The x-axis denotes how many dark patterns were discovered (unique count in blue, total in orange). The y-axis represents the percentage of the 57 devices in our study that contained that number of dark patterns for either count. We discovered at least three unique dark patterns in all 57 devices.⁴ On average, devices contained 9 unique dark patterns, and all devices contained < 25 unique patterns.⁵

Figure 3:

View Figure

If the devices in our corpus included only one instance of each unique dark pattern, then the two distributions would be identical and overlaid atop each other. However, beyond the 40^th percentile the distributions diverge, with the highest number of total dark patterns (90, Table 4c) being more than triple the maximum number of unique dark patterns (25, Table 4a). Thus, many devices not only exhibit dark patterns multiple times, but do so in large numbers. Table 4 highlights the top ten devices in our corpus by highest and lowest counts of unique and total dark patterns. Both lowest-count tables (Table 4b and Table 4d) share eight out of ten devices. However, the highest-count tables (Table 4a and Table 4c) share only six devices, suggesting variance between top-offending devices’ propensity to deploy dark patterns multiple times.

Figure 3 presents the percentage of devices with at least one instance of each dark pattern in our codebook, color-coded by context category. Overall, patterns in the Interface Interference, Consent and Permissions, Registration, Seen in Settings, and Leaving categories were most frequently adopted.

4.1.2 High Total Counts and Potential Design Templating.

Figure 4:

View Figure

As shown in Figure 3, two Interface Interference patterns appeared most frequently by total count. A closer look reveals that on average, the visual preference pattern appears 6 times per device (the highest average value across all dark patterns), with general preselection (the second highest average) appearing only around twice per device—this is visualized in Figure 17 in the Appendix, while Figure 18 stratifies the total count averages per device category to demonstrate that speakers, doorbells, and cameras contained the highest frequencies of these two patterns. We hypothesize that the high adoption rate of these patterns may be due to design templates and/or automated design deployment methods, as opposed to unique, conscious decisions by designers. For example, a UX design tool may have checkbox elements set to have preselected defaults, or binary choice buttons that privilege one button over the other even before button text is added. Context-specific versions of these patterns (e.g., preselected consent checkboxes or settings) were also fairly common in our dataset.

4.1.3 Impact of Interaction Duration.

To explore the disparity between unique and total counts, we consider the amount of time we spent interacting with each device as a form of robustness check on our methodology: would the disparities disappear if we simply spent more time with each device?

In our interactions, we noticed that device experiences could vary greatly in interface “richness”—an informal measure of available interaction avenues within the experience. This includes feature offerings (e.g., platforms for third-party skills or apps, third-party integrations, built-in analytics or reporting, etc.), device capabilities (e.g., whether a lightbulb is able to control light color or brightness instead of just on or off modes), level of detail in options, and design complexity. We posit that interface richness is positively correlated with the number of observed dark patterns: the patterns are design components, so an interface that provides more design surfaces may have greater potential to deploy more dark patterns compared to a leaner interface. Richer interfaces should take longer to traverse experimentally, thus we use device interaction length (represented by video recording length in Table 1) as a proxy measure.

We calculate both Pearson’s and Spearman’s correlation coefficient (r) for recording duration against the number of unique and total dark patterns instances for all devices to find positive and significant correlations⁶ between recording length and dark pattern count: Pearson’s r = 0.510 and Spearman’s r = 0.474 for unique counts, then Pearson’s r = 0.591 and Spearman’s r = 0.552 for total counts, with all p < 0.001. Figure 4 presents scatter plots of recording duration (x-axis) against total (4a ) or unique (4b ) dark patterns counts (y-axis), with frequency histograms and a linear regression line of best-fit with confidence intervals. For total dark pattern counts, we see tighter clustering around lower counts and outlier behavior (long tails) for high counts, as compared to looser distribution for unique counts. This echoes the two measures’ divergence in Figure 2. However, more research is needed to better understand the relationship between interaction richness and dark pattern deployment, including using models with more robust controls.

Figure 5:

View Figure

4.1.4 Comparison to Prior Measurement Work.

Figure 6:

View Figure

Figure 7:

View Figure

Prior modality-specific work measured the presence of unique dark patterns in mobile apps: Di Geronimo et al. [26] investigated 240 apps and Gunawan et al. [42] inspected 105. Figure 5 compares our findings against these studies, mapped to the context categories from Di Geronimo et al. [26] to provide an apples-to-apples comparison.⁷ Like Gunawan et al. [42], we caution that distributions heavily depend on corpus and codebook construction (which we discuss further in section 5.4). Additionally, our interaction methodology departs from both studies’ time-bound interactions, which may impact the discoverability of dark patterns across all these studies.

Our findings generally agree with those from prior work, with some exceptions. Our corpus size is smaller than those in Di Geronimo et al. [26] and Gunawan et al. [42], in part due to IoT companion apps being a strict subset of apps in general, which may explain why we do not observe dark patterns in every Di Geronimo et al. [26] category (e.g., Hidden Costs, Sneaking, and Bait & Switch). We do observe more Nagging in our study, potentially because the IoT context presents more opportunities for manufacturers to encourage optional behaviors like linking IoT devices to apps and to each other, or signing-up for optional services. Our study additionally includes more Hidden Information and Trick Questions patterns compared to Gunawan et al. [42], who only correlate these DiGeronimo categories with one dark pattern each.

4.2.1 More Ways to Nag.

Nagging [39] patterns manifest in myriad ways, spanning ad-related nags [26] to spammy behavior [20] to extraneous cues [42, 67]. In this study we add two new cases of such patterns, finding extraneous social media features and nagging self-promotional content in some device experiences.

We considered social media features to be extraneous when they deviated from the primary purpose of a device and were promoted to the user in spammy, aggressive, or otherwise obtrusive manners. Figure 6 presents an example of this pattern that we observed in the Govee Home app for the Govee LED Light Bulb device.

We distinguish nagging self-promotional content from native advertising- or shopping-related dark patterns by identifying cases when device experiences or manufacturers presented nags to endorse their own services or content outside of traditional or expected ad placements. These were especially perplexing in the Fire TV as shown in Figure 7: while scrolling for content on a non-Prime user account, we overwhelmingly encountered Prime content carousels with varying promotional labels, and were unable to avoid these carousels. Of the Prime-promoting carousels, some were labeled as ‘sponsored,’ but the nature of these sponsorships was unclear. Such internal promotions may skirt formal requirements of advertising and disclosure law or guidance. Future research is needed to understand the effect of technically legal but potentially disadvantageous or annoying promotions.

4.2.2 Financial Dark Patterns.

The ‘IoT’ part of a smart device is intended to offer consumers value beyond the analog limitations of the device. This presents additional opportunities for manufacturers to apply the financial models from web modalities, like long-term financial relationships via subscription models or tiered access to features. We relate our new case pay for long term use to the Hidden Subscription [67], Bait and Switch [20], and Obfuscation dark patterns categories, which we added after being alerted by the Amazon Ring app that certain features were inaccessible due to expired subscriptions during our pilot experiment. Similarly, during our pilot interactions with the Govee app, some features were labeled as exclusive for “Savvy” membership users, but were otherwise accessible to us without signing up for membership, leading to our inclusion of the feature seems premium but is not pattern as a counter-case to the previously identified feature seems free but is not. We consider these patterns deceptive when they obfuscate key information about device limitations out-of-the-box or upon initial setup, as not all IoT device users may have made the original device purchase.

Figure 8:

View Figure

Figure 9:

View Figure

Figure 10:

View Figure

Figure 11:

View Figure

4.2.3 Settings Inconsistencies.

We noted that navigating settings on some devices was particularly challenging or confusing, marking such designs as inconsistent settings user interfaces. This falls under Aesthetic Manipulation, with particular regards to the ways in which these dark patterns obscure [19], restrict [68], or otherwise interfere with user access to important controls. Figure 8 provides an example from the Aqara Home app, which concurrently shows preselected notification settings and no bulk toggle. Such designs force users to put in unnecessary additional labor, time, and effort into managing relevant controls, while inconsistencies in the interface potentially prevent users from accessing or understanding available settings.

4.2.4 Detours to Different Modalities.

While attempting to use certain settings or features in a device experience, we were sometimes instructed to open an app or visit a website to access that feature. We call these detours to describe the manner in which the interface redirected our interactions away from the currently-in-use modality and towards another, with an example of a settings detour in Figure 9. Not all features may be feasibly delivered across all modalities in a given service, so we mark this pattern when we are given no notice (prior to attempting to access the setting or feature) that the content is locally unavailable when it should otherwise be reasonable to expect it in the current modality. This dark pattern relates to feature parity issues that have previously been observed across modalities of a singular web service [42], which not only increase time and labor burdens for users but risk inequitable experiences. Prior work did not assign a label to this behavior; we thus relate detour patterns to the restrict and obscure dark pattern strategies [68].

4.2.5 Device Roach Motels.

Prior work [26, 42] articulated several Roach Motel [20] cases. We separately define three new device-specific cases (device sensed without permissions, cannot remove device, and cannot delete data from device) to this set of Roach Motel patterns in order to investigate the range of possible traps users may encounter in IoT interactions. We noted devices sensed without permissions if the app or device itself detected other devices without our active intent to search for other devices within the experiment LAN. One example was the Amazon Alexa app detecting the Amazon Smart Plug device and prompting setup after we removed the previously configured device from the app. The latter two patterns are device-specific versions of the no account deletion or no logout patterns identified in prior work on websites and apps. These patterns help capture different applications of Roach Motels within a single device experience, each with varying degrees of potential impact on user privacy or autonomy. For example, the inability to remove a device from a user account or to delete user data from a device makes it difficult to safely re-sell or gift used devices. Similarly, devices that are detected by apps prior to users providing specific permissions to the app raise privacy concerns.

4.2.6 Opt-Out Traps.

We liken nonpermanent opt-out behavior (shown in Figure 10) to Trick Questions in that such designs can manipulate user interaction towards unintended answers [20]. This dark pattern commonly provides users with binary choices for an option, with one being an affirmative ‘yes’ and the other being some variation of ‘not now,’ ‘later,’ or ‘skip.’ Users are not provided options like ‘no’ or ‘never.’ Such designs are transparent that the question will be asked again in the future, but do not give users a way to effectively avoid this query or notification and thus accentuates nagging behavior. We label such cases when an interface fails to provide permanent negative options, and do not label cases when users are provided some sort of ‘do not ask again’ choice.

4.2.7 Hidden Feature Behavior.

Figure 11 provides an example of hidden feature behavior, a sub-case of hidden information. We separate this case from the parent dark pattern category for its implications in the IoT context: designs that initially imply that features are inherently provided but later reveal additional conditions for use are thus labeled under this dark pattern. This behavior obfuscates the true value of an IoT service and may deceive consumers into perceiving a product as more robust (sans additional caveats) than it truly is. This pattern is similar in method to feature-related Money patterns, which hide the true cost of a feature from the user.

4.2.8 No Local Unsubscribe Options.

We added this case following our pilot experiment to investigate whether services with subscription models offered users the ability to cancel subscriptions within the device experience (i.e., without having to head to a website in a browser or otherwise contact the manufacturer). The instances in which this pattern came up were complex: we initially annotated the Ring app as having this pattern as pertaining to the Ring Doorbells and Cameras but not the Ring Chime due to helper text provided to us during attempts to delete devices from the Ring App. Interfaces originally prompting these annotations are shown in 12a and 12b for the Chime and Indoor Camera, respectively. In 12b , the warning message indicates that the subscription-based Ring Protect Plan must be canceled at ring.com, thus prompting a no local unsubscription option dark pattern. Conversely, the Chime does not include any reference to the Protect Plan and thus we did not mark this dark pattern. However, when we later attempted to delete the entire Ring account via the app, we were presented with the warning message in Figure 12, which explains that any subscriptions on the account will be canceled with account deletion. Due to this technically local unsubscription option, we removed our previous annotations and found no other instances in other devices (seeing as most devices did not mandate or offer subscription models), but retain the dark pattern in our codebook and provide these examples to demonstrate the potential for this behavior in other apps or web services as subscription models are not unique to IoT.

Figure 12:

View Figure

5.1.1 Multi-factor Considerations for Dark Pattern Adoption.

In this work we examine several potential factors that could influence dark pattern adoption in IoT experiences: interaction context, modality, device type, and manufacturer. We found that visual, screen-based interfaces (e.g., on-device touchscreens and TV screens) drove dark pattern prevalence, rather than companion apps exclusively, non-screen physical device interfaces (e.g., a blood pressure sleeve or lightbulb), or voice modalities (see Figure 13 and 14a ).⁹ For example, the Amazon Fire TV contained the largest number of unique dark patterns in our study, but is interacted with only via remote control. Similarly, the fridge, televisions, other media devices, and some smart speakers were fully usable without apps and contained many dark patterns from our codebook. Furthermore, with respect to manufacturers, Amazon and Google adopted more dark patterns among devices in our sample, even when compared to other large manufacturers like Samsung and Apple (see 14b ). Overall, however, we found no singular factor that conclusively predicted the presence or lack thereof of dark patterns in IoT devices.

5.1.2 Design (In)Consistencies and Subverted Expectations.

In section 4.1.2 we note how high dark pattern frequencies may suggest the use of design templates, which can help make UX deployments more efficient at-scale and keep designs consistent (and thus more usable) across a service. This repetition leads users to expect similar behaviors whenever the same design appears. However, this expectation can be subverted to users’ disadvantage. We noted a peculiar example in the SmartThings app; visually consistent designs were used in wildly different manners that made it difficult to determine what features were actually available to us or not out-of-the-box, and to what extent (Figure 11). We considered this to be hidden feature behavior as the initial designs offered little transparency into additional requirements or “strings attached.” Such patterns risk deceiving users, particularly for integrations-oriented devices like smart hubs, as users might not fully understand the limitations of a device’s offering at the time of device purchase. Future research on hidden information-related patterns could further explore how devices or services communicate or promise value to end users in their marketing or sales material, towards a goal of improving consumer protections and disclosures.

5.1.3 Add-Ons for Limited Interfaces as Opportunities for Dark Pattern Adoption.

Some device types (see section 4.4) in our corpus serve single or limited sets of functions but nudge users towards integrations with third-party services. Integrations are also available in app or web services, but one explanation for the increased prevalence of integrations in IoT devices is that doing so can increase the value or functionality of an otherwise purpose-limited device, e.g., by sharing data gathered from device sensors that are not available in other modalities like smartphones. The SmartThings example described in section 5.1.2 notes how hidden feature behavior might obfuscate real device value to cost users time and money. However, multiple patterns may be involved in nudging users; the Withings app delivered nagging, advertising, and hidden information-related patterns to promote third-party integrations and dedicated an entire page in their app to external health-related subscription services as “Programs” for users to join. We also observe similar behavior from devices produced by large manufacturers (e.g., promoting the manufacturer’s internal services or third-party integrations). Such pattern types were similarly prevalent in prior app studies as demonstrated in Figure 5, especially nagging patterns, which were found in over half of apps in both Di Geronimo et al. [26] and Gunawan et al. [42].

Collaborative partnerships can add value to a service. However, failing to disclose whether a feature is included with the price of the device up front may be deceptive. Third-party integrations also raise privacy concerns, especially when the sensitivity of data collected by IoT device sensors is higher than the data accessible to apps and websites.

5.2.1 Perceived Device Value and Financial Harms.

Compared to web- or app-only services, IoT devices necessitate purchase or other means of device ownership, and in some cases require subscriptions in order to ensure continued functionality as described in section 4.2. IoT experiences may also attempt to deliver additional services or features to consumers through third-party integrations, some of which may require payment. This complicates user decision making at time of device purchase by obfuscating the true out-of-the-box value of the device, raising financial and autonomy harms for consumers who make purchases with incomplete or incorrect understandings.

5.2.2 Flawed Privacy Controls.

IoT devices can change ownership through re-selling or secondhand gifting, exacerbating the IoT privacy and security issues noted in section 2. Dark patterns further add to this problem by interfering with user behavior for important privacy controls. For example, around 60% of devices did not offer account deletion within the visited modalities as demonstrated by Figure 3. With other Leaving patterns (e.g., the inability to delete device data or remove a device from an account) as well as the device reset issues we encountered in section 3.1, these dark patterns constitute privacy and autonomy harms by denying users the ability to effectively manage their privacy while using the device and after relinquishing it.

5.2.3 More Roaches in this Motel?

Nags for user interaction are not exclusive to the IoT modality, but the increased consumer risks highlighted above may be worsened by nagging behavior. We found such patterns in many of our devices as demonstrated by Figure 3, particularly non-permanent opt-out (> 60% of devices), extraneous notification badges (> 40% of devices), nagging self-promotion (> 40% of devices), with other nagging patterns discovered across multiple context categories. Amazon and Google devices often containing multiple instances of these patterns as noted in the Appendix, Table 8. In light of the vast data collection capabilities of both large manufacturers and their devices, high rates of nagging patterns may influence user behavior towards trackable engagement that leads to further financial or privacy harms. Emergent scholarship is beginning to explore the effect of nags or similar attentional dark patterns on user outcomes [72, 77], though more research is needed to measure dark patterns in attention ecosystems and their impact on other consumer harms.

5.3.1 Minimize Darkness while Maximizing Value with Design “Appropriateness.”.

Our work highlights the need for mitigations that minimize dark patterns relative to feature richness, as more complex devices should not be synonymous with more dark patterns. Design practitioners might review design templates and their use to identify possible risks of abusive, deceptive, or unfair applications of those templates. This may help reduce the frequency of designs like those in Figure 11 or popular dark patterns like non-permanent opt-out and other interface interference patterns including visual preference and general preselection, which were not only the two most prevalent patterns in our study overall (see Figure 3) but were frequently in the top dark patterns per factor examined in this study (see section A.2 for more detail).

One regulatory mitigation of IoT dark patterns could be the idea of “design loyalty” rules [48], which borrow from the law of fiduciary responsibility to prohibit companies from designing their devices, interfaces, and services in a way that conflicts with the best interests of people who use IoT devices. Such rules have already been imposed in California for designs impacting children [90] and proposed in the bipartisan American Data Privacy and Protection Act [2]. One of the significant benefits of loyalty rules is that they can be enforced without requiring strict evidentiary proof of emotional, repetitional, or financial harm. Such harm requirements are a poor fit for dark patterns because of the dispersed, incremental, and often immaterial nature of autonomy and attention-related dangers. Another advantage of loyalty rules is that they direct enforcement agencies to evaluate the relative benefit that flows to companies as well as risks to users. When benefits of a particular design asymmetrically flow toward manufacturers and risks are largely borne by users, the design is disloyal and, thus, dark. Loyalty rules therefore provide a more structured approach to help lawmakers, companies, and even users identify key choice architectures and understand when design is dark and untrustworthy.

Legislators could additionally borrow “appropriateness” qualities from privacy law’s data minimization principle, which holds that companies should collect, store, and use only data that is adequate, relevant, and limited to what is necessary for a pre-stated purpose [82]. For interactions that are especially important for user controls and autonomy, like consent flows, settings management, or opt-out mechanisms, rules that enforce adequacy and relevancy may improve problems like the use of detour patterns or cross-modality equity issues (section 4.2.4). Design appropriateness perspectives may also address the popularity of nagging or engagement-related dark patterns like extraneous engagement features (section 4.2.1), though more research is needed to better understand resulting harms prior to formal regulation of attentional dark patterns.

5.3.2 Build Templates for Desired Design Patterns.

Standardization efforts can potentially mitigate dark patterns by providing templates for acceptable design patterns that promote autonomy and transparency, countering the effect of templates that lead to consumer harms. One approach is industry standards, inspired by efforts like the Manufacturer Usage Description (MUD) IETF standard [55] that defines the expected behavior of an IoT device and that permits automated compliance tests in deployment [46]. Another approach is to formalize design standards through regulatory rules, similar to the FTC’s .com disclosures [35], the CCPA’s opt-out icon [5], California’s recently enacted Age-Appropriate Design Code Act [90], which provide guidance for avoiding common dark patterns as well as mandates for compliance.

5.3.3 Increase Transparency at Key Interaction Points.

Mitigations for dark patterns in the IoT context should also promote improved transparency—particularly at crucial interaction points like account registration and setup—where users are presented with consequential requests (e.g., for account information, permissions, third-party integrations, and other options). Facilitating informed decision-making at the time of device or account configuration can help reduce future privacy or financial risks to the consumer.

Both design and disclosures should offer transparency to consumers, especially so in IoT/consumer electronics experiences as real money and highly sensitive data are at risk. With Registration and Consent and Permissions dark patterns in > 50% of our devices writ-large (Figure 3) and Consent and Permissions issues in > 60% of all devices when stratified by modality (see section 4.3 and Figure 13), there is ample room for improvement in transparency surrounding privacy harms. Users must be able to expect that device, feature, or interface functionality corresponds with what they can reasonably infer given the designs or templates they are exposed to. Increasing transparency in feature design can help mitigate consumer harms from issues discussed in section 5.1. Lawmakers might consider mandated transparency mechanisms like data protection and design impact assessments, just-in-time disclosure rules, and privacy labeling requirements [4, 35, 82, 90].