Differences

This shows you the differences between two versions of the page.

--- design:connected_tv [2026/09/12 17:46] – Review round: fix the ATSC broadcaster-app quote (altered and cited to two pages that do not contain it; replaced with what ATSC's own pages say, plus A/344 and the FCC Fifth FNPRM); Roku GetRIDA/IsRIDADisabled casing and doc; alias fold is 27 spellings o karel.kubicek.claude
+++ design:connected_tv [2026/09/13 02:23] (current) – Round-2 review fixes: five false negative claims corrected (LLM use, factory reset, opt-out both-sides, TLS decryption-hole probe width, AndroZoo); EU joint Art.62 smart-TV report and UK ICO connected-TV programme added, replacing a wrong 'Europe is empty karel.kubicek.claude
@@ Line 8: / Line 8: @@
   - **The TV reports what is on screen.** Automatic content recognition (ACR) samples the panel — including the HDMI input from your games console or set-top box — and sends a fingerprint to the manufacturer. This is a measurement object with no web analogue at all: there is no page, no request initiated by a tracker, and no script to attribute it to.
   - **There is a broadcast side.** HbbTV rides the DVB signal and launches an application from the broadcaster the moment you tune to a channel, before any consent interaction exists. A crawler that only speaks HTTP cannot see this channel, and a vantage point on the Internet cannot reach it.
-  - **There is no Tranco for televisions.** Nothing versioned, nothing archived, nothing citable. In this corpus the median TV study is a handful of physical devices in a lab, bought by the authors.
+  - **There is no Tranco for televisions.** Nothing versioned, nothing archived, nothing citable. In this corpus the median stated device-set size is **66**, and 14 of the 20 papers that state one never exceed 96 — but that median is dominated by general IoT testbeds. The studies that are actually about televisions are far smaller: the two ACR papers use **2** and **3** sets, and the largest TV-specific bench is **57**.
 <WRAP important>
@@ Line 21: / Line 21: @@
   - {[moghaddam2019_watching]} — **the instrumentation paper.** Two platforms, 1,000 channels each, an automated crawler built on the vendors' own remote-control APIs, and an honest account of what TLS interception could and could not reach. Read Section 3 before you buy hardware.
-  - {[varmarken2020_smart]} — **the one that reports its decryption hole.** Roku and Fire TV, testbed //and// in-the-wild traffic, and the only paper in this population that publishes a per-app TLS decryption failure distribution.
+  - {[varmarken2020_smart]} — **the one that quantifies its decryption hole.** Roku and Fire TV, testbed //and// in-the-wild traffic. Three of the thirteen Tier A papers say somewhere that they could not decrypt everything; this is the only one that publishes a per-app TLS decryption failure //distribution// rather than a sentence.
   - {[tileria2022_watch]} — **the app-analysis route.** 4,745 Android TV APKs pulled apart statically, plus intercepted traffic from a small subset. The bridge between this page and [[Design:Mobile and app measurement]].
   - {[tagliaro2023_still]} — **the broadcast side.** HbbTV across 36 European channels on real televisions, with a survey of what viewers know about it. There is no other way into this material.
@@ Line 108: / Line 108: @@
 **Your coverage number is platform-specific, not study-specific.** A paper that says "we intercepted TLS" over a mixed device set is reporting an average of 95% and 4%. Report per platform or do not report at all.
-**Almost nobody reports the hole.** Of the 13 Tier A papers, a probe for a phrase describing failed or impossible decryption matches **1** — {[varmarken2020_smart]}, which publishes the distribution: "1 out of 5 (or fewer) TLS connections for 80% of all apps". That single sentence is the thing to copy.
+**Most papers do not quantify the hole.** Of the 13 Tier A papers, **3** say somewhere that they could not decrypt or intercept everything, or that pinning had to be bypassed: {[moghaddam2019_watching]} (Frida, "to bypass certificate pinning" on the Fire TV stick), {[varmarken2020_smart]} ("we cannot install our own self-signed certificates on the Roku") and {[tileria2022_watch]} ("there is no way to install custom certificates on Android TV", so the APKs were instrumented to remove the pinning checks instead). Only **one** turns that into a number: {[varmarken2020_smart]} publishes the distribution — "1 out of 5 (or fewer) TLS connections for 80% of all apps". That single sentence is the thing to copy.
+This paragraph is a worked example of why a probe width is a claim. An earlier version of this page ran a narrow regex (//could not decrypt//, //failed to decrypt//, //decryption fail//, //unable to decrypt|intercept//) over the same 13 papers, matched **1**, and printed "almost nobody reports the hole" — while quoting, three sections earlier, two of the sentences the regex had missed. Widening it to include //cannot install … certificate//, //bypass … pinning// and //no way to install custom certificates// takes the count from 1 to 3. Both widths are printed by the report script, which also asserts that the narrow set is a subset of the wide one — if a narrowing probe ever returns //more//, it is broken, not informative.
 <WRAP tip>
@@ Line 162: / Line 164: @@
 ^ Date ^ Event ^
 | 2017-02-06 | FTC and New Jersey settle with VIZIO for **$2.2 million** over viewing data from **11 million televisions**, collected "second-by-second"; order requires affirmative express consent and deletion of data collected before 2016-03-01((US FTC, [[https://www.ftc.gov/news-events/news/press-releases/2017/02/vizio-pay-22-million-ftc-state-new-jersey-settle-charges-it-collected-viewing-histories-11-million|VIZIO to pay $2.2 million to FTC, State of New Jersey…]]. Checked 2026-09-12.)) |
-| 2024-12-03 | Walmart completes its acquisition of VIZIO((Walmart, [[https://corporate.walmart.com/news/2024/12/03/walmart-completes-acquisition-of-vizio|Walmart Completes Acquisition of VIZIO]]. Checked 2026-09-12. The release announces the acquisition and its close; it does not name VIZIO's Platform+ segment or the Inscape ACR business, so nothing about the ACR business is asserted here on its authority.)) |
+| 2024-12-03 | Walmart completes its acquisition of VIZIO((Walmart, [[https://corporate.walmart.com/news/2024/12/03/walmart-completes-acquisition-of-vizio|Walmart Completes Acquisition of VIZIO]]. Checked 2026-09-12. The release does name the advertising business — "VIZIO's Platform+ segment, which consists largely of its advertising business, now accounts for all the company's gross profit" — but it never mentions Inscape or ACR, so no ACR-specific claim is made here on its authority. (An earlier version of this footnote said Platform+ was not named; that was wrong. The plus sign is HTML-encoded in the page source, which is how a text search missed it.))) |
 | 2025-12-15 | Texas sues **Sony, Samsung, LG, Hisense and TCL**, alleging ACR software "can capture screenshots of a user's television display every 500 milliseconds"((Texas Attorney General, [[https://www.texasattorneygeneral.gov/news/releases/attorney-general-paxton-sues-five-major-tv-companies-including-some-ties-ccp-spying-texans|Attorney General Paxton Sues Five Major TV Companies…]], 15 December 2025. Checked 2026-09-12.)) |
 | 2025-12-17 | Temporary restraining order against Hisense, barring ACR collection and transfer((Texas Attorney General, [[https://www.texasattorneygeneral.gov/news/releases/attorney-general-ken-paxton-secures-court-order-stopping-ccp-aligned-smart-tv-company-spying-texans|…Secures Court Order Stopping CCP-Aligned Smart TV Company…]], 17 December 2025. Checked 2026-09-12.)) |
 | 2026-02-26 | Samsung agreement: no ACR collection or processing without express consent, plus clear and conspicuous consent screens pushed to existing sets((Texas Attorney General, [[https://www.texasattorneygeneral.gov/news/releases/attorney-general-paxton-secures-major-agreement-samsung-ensure-texans-are-protected-smart-tvs|…Secures Major Agreement with Samsung…]], 26 February 2026. Checked 2026-09-12.)) |
 | 2026-05-11 | LG agreement: pop-up disclosure on the set and on the website, a clear opt-out path((Texas Attorney General, [[https://www.texasattorneygeneral.gov/news/releases/attorney-general-ken-paxton-secures-major-agreement-lg-protect-texans-privacy-and-stop-data-being|…Secures Major Agreement With LG…]], 11 May 2026. Checked 2026-09-12.)) |
+| 2025-09-23 | The Dutch, Hungarian, Italian and Liechtenstein supervisory authorities publish the final report of an **EDPB Strategic Case on smart TVs**, a joint Article 62 GDPR operation. It is a regulator running a network measurement: three televisions from different manufacturers, instrumented across first installation, standby, //off//, a second standby and ordinary use. Its headline result is that the sets talk while switched off — of the flows recorded during 24 hours "turned off", **97.52%, 98.84% and 91.10%** went to the operating-system provider's domains, with the rest split between streaming services, the manufacturer and third parties. It also finds device manufacturers reluctant to accept a controller role, and users with "no other realistic option than to accept extensive privacy policies"((Autoriteit Persoonsgegevens, Nemzeti Adatvédelmi és Információszabadság Hatóság, Garante per la protezione dei dati personali and Datenschutzstelle Liechtenstein, [[https://www.autoriteitpersoonsgegevens.nl/documenten/rapport-verkennend-onderzoek-smart-tvs|//Joint operations pursuant Article 62 GDPR carried out by NL, HU, IT and LI SAs on the Smart TVs Strategic Case — Final Report//]], 23 September 2025, 14 pp. Quotes verified in the PDF on 2026-09-13; the host needs a browser User-Agent and a Referer header. The report never uses the phrase "automatic content recognition", which is why an ACR-shaped search does not find it.)) |
+| 2026-06-11 | The UK **ICO** publishes final guidance on consumer IoT products and services — covering, in its own list, "smart speakers, connected TVs, fitness trackers, smart doorbells, home hubs and domestic appliances" — and announces an enforcement-adjacent programme: "We are now turning our attention to connected TVs and how they use people's personal information … We will be engaging with connected TV manufacturers this year to assess whether they are complying with the law and offering consumers meaningful choice over how their data is used."((UK Information Commissioner's Office, [[https://ico.org.uk/about-the-ico/media-centre/news-and-blogs/2026/06/setting-out-our-expectations-for-the-smart-device-industry/|Setting out our expectations for the smart device industry]], 11 June 2026, quoting William Malcolm, ICO Executive Director for Regulatory Risk and Innovation; the guidance is [[https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/online-tracking/guidance-for-consumer-internet-of-things-products-and-services/|Guidance for consumer Internet of Things products and services]]. Checked 2026-09-13; ico.org.uk returns 403 without a browser User-Agent.)) |
 | effective 2027-07-01 | **Kentucky HB 692**, enacted as Acts Chapter 118, amends the Kentucky Consumer Data Protection Act to define "automatic content recognition data" and "smart monitor", and "to prohibit controllers from collecting automatic content recognition data without a consumer's consent" — the first US **statute**, as distinct from an enforcement action, that names ACR((Kentucky Legislative Research Commission, [[https://apps.legislature.ky.gov/record/26rs/hb692.html|26RS HB 692]], summary of the enacted version. Checked 2026-09-12. The bill as introduced instead added ACR data to the definition of //sensitive data//; the enacted text is a direct prohibition.)) |
-**Sony, Hisense and TCL have not settled.** The Attorney General has published agreements with Samsung and LG only; as of 2026-09-12 no settlement, dismissal or further order for the other three appears on its newsroom. So the timeline above is the beginning of a proceeding, not the end of one, and a 2026 measurement of a Sony, Hisense or TCL set is measuring a product whose behaviour is still contested in court. Nothing comparable was found from an EU or UK regulator: the search there came back empty, which is itself worth knowing before someone assumes the GDPR angle is already covered.
+**Sony, Hisense and TCL have not settled.** The Attorney General has published agreements with Samsung and LG only; as of 2026-09-12 no settlement, dismissal or further order for the other three appears on its newsroom. So the timeline above is the beginning of a proceeding, not the end of one, and a 2026 measurement of a Sony, Hisense or TCL set is measuring a product whose behaviour is still contested in court. **Europe is not empty, and an earlier version of this page said it was.** Two European actions were missed on the first pass because both describe the phenomenon without using the words "ACR" or "automatic content recognition", so an ACR-shaped search cannot see them. They are the two rows added to the table above, and the first of them is the most directly useful document on this page for a measurement researcher: a supervisory authority ran the experiment, on a three-device testbed, and published a per-power-state breakdown of where the traffic went. Read it as a paper. What still appears to be absent — searched on 2026-09-13, and this is a negative result from a search, not from the corpus — is any EU or UK **fine or enforcement order** specifically about smart-TV data collection. Guidance and a joint investigation are not an order, and the Texas record remains the only place a television's behaviour has been changed by a legal instrument.
 Three things follow for a study designed today. **The 2024 measurement is a pre-order baseline** for exactly the two vendors that have since settled, which makes a replication unusually valuable and unusually easy to justify. **A US measurement after February 2026 is measuring a consent flow, not a default**, and needs the [[Privacy:Consent]] apparatus — accept, reject, no-interaction — that the ACR literature has never applied. And the Texas filings' "every 500 milliseconds" sits alongside the paper's 500 ms Samsung capture estimate; agreeing with a regulator's pleading is not verification, so say which one you are citing for what.
@@ Line 185: / Line 189: @@
 The current specification is **HbbTV 2.0.5, published 2026-02-25**, an incremental update over 2.0.4 (March 2023) adding DRM and WebAssembly recognition and correcting the accessibility and DVB-I material introduced in 2.0.4.((HbbTV Association, [[https://www.hbbtv.org/resource-library/specifications/|Specifications]]. Checked 2026-09-12.)) A 2023 measurement is therefore two specification revisions old.
-The North American analogue is **ATSC 3.0 / NextGen TV**, which ATSC describes as offering "more accessibility, personalization and interactivity" over the current standard and which it states reaches "more than 76% of U.S. households" as of its July 2026 deployment map.((ATSC, [[https://www.atsc.org/nextgen-tv/|NextGen TV]] and [[https://www.atsc.org/nextgen-tv/deployments/|Deployments]]. Checked 2026-09-12. The broadcaster-application layer is standardised separately as **A/344, "ATSC 3.0 Interactive Content"**; see [[https://www.atsc.org/atsc-documents/type/3-0-standards/|ATSC 3.0 Standards]].)) **No paper in these seven venues measures it**, and that is the largest single gap on this page.
+The North American analogue is **ATSC 3.0 / NextGen TV**, which ATSC describes as offering "more accessibility, personalization and interactivity" over the current standard and which it states reaches "more than 76% of U.S. households" as of its July 2026 deployment map.((ATSC, [[https://www.atsc.org/nextgen-tv/|NextGen TV]] and [[https://www.atsc.org/nextgen-tv/deployments/|Deployments]]. Checked 2026-09-13.)) **No paper in these seven venues measures it**, and that is the largest single gap on this page.((Probed rather than assumed, and the raw count needs reading: a full-text search for ''ATSC'' or ''NextGen TV'' across all 5,859 ''paper.cols.txt'' files returns **4** papers, of which **3 are homonyms or bibliography** — ''ATSc'' as a PHP application name in a randomness-attack paper, ''ATSC'' as an OBD-II AT command in a CAN-bus paper, and an atsc.org URL in a satellite paper's reference list. The one real mention is {[oren2014_aether]}, which notes in passing that ATSC "published a candidate standard for hybrid TV in America" in December 2013. **No paper measures it.** The probe and all four hits are printed in the report script.))
+What a measurement would find is written down. The broadcaster-application layer is standardised as **A/344, "ATSC 3.0 Interactive Content"** — current revision **A/344:2026-04, 14 April 2026** — and a broadcaster application is an HTML5 document in a W3C User Agent talking to the receiver over a JSON-RPC WebSocket. Three parts of it are directly measurable, and each has a web analogue that does not behave the same way.
+  * **A normative advertising identifier.** The ''Query Device Info'' API returns ''deviceId'' and ''advertisingId'', the second "a persistent, globally unique UUID associated with advertising on the device"; the standard expects both to be "initialized once by the Receiver to afford long-term persistence across all Services and Receiver power cycles". Opt-out is **observable rather than inferred**: a refused identifier comes back as all zeros (''urn:uuid:00000000-0000-0000-0000-000000000000''), and an unsupported one is absent, so a measurement can tell "the user declined" from "this receiver does not implement it" without guessing. That is a cleaner signal than any of the platform identifiers below.
+  * **Personalisation is a broadcaster-defined integer.** ''filterCode'' is "an unsigned integer associated with personalization categories as determined by the broadcaster", carried in Filter Code Instances that have their own expiry. The category vocabulary is //not// in the standard, so recovering what a code means is a measurement problem rather than a lookup: there is no published vocabulary to join against, and no equivalent of the shared, inspectable rule sets that [[Programming:Filter lists]] describes for web requests.
+  * **Cookies, on the television.** The broadcaster application "is expected to manage a local name space for setting cookies and other local User Agent storage elements", and "may choose to provide its own settings user interface and store the collected settings as cookies on the Receiver". The object is the one [[Privacy:Cookies]] is about; none of that page's instruments reach it, because there is no profile directory to read and no CDP to attach.((ATSC, [[https://www.atsc.org/wp-content/uploads/2026/04/A344-2026-04-Interactive-Content.pdf|A/344:2026-04, "ATSC 3.0 Interactive Content"]], 14 April 2026; revision list at [[https://www.atsc.org/atsc-documents/3442017-atsc-3-0-interactive-content/|the A/344 document page]]. Every quote in these three bullets was matched verbatim in the PDF on 2026-09-13. Note that the phrase "data collection" appears nowhere in A/344; an earlier version of this page attributed it to ATSC and it was withdrawn — see [[provenance:design:connected_tv|the provenance page]].))
 The regulator has got there first here too. The FCC's **Fifth Further Notice of Proposed Rulemaking** in GN Docket No. 16-142, adopted in October 2025, proposes to remove restrictions on the ATSC 1.0 simulcast whose "substantially similar" rule "was initially scheduled to sunset on July 17, 2023, and was extended to July 17, 2027", and seeks comment on a list of outstanding NextGen TV issues that includes "The sunset of 1.0 service", tuner and labelling standards, and — in its own one-word bullet — "Privacy".((US FCC, [[https://docs.fcc.gov/public/attachments/DOC-415053A1.pdf|Fact Sheet: Authorizing Permissive Use of the "Next Generation" Broadcast Television Standard, Fifth Further Notice of Proposed Rulemaking, GN Docket No. 16-142]], October 2025. Checked 2026-09-12.)) A measurement of what ATSC 3.0 broadcaster applications actually collect would be evidence in a live proceeding, and there is none.
@@ Line 193: / Line 203: @@
 [[Design:Mobile and app measurement]] owns store scraping, static and dynamic analysis, and the reproducibility discipline for app sets. Everything there applies. Four things are different enough to state.
-  * **There is no AndroZoo for TV apps.** The mobile page's whole first section is a comparison of bulk-download routes; for televisions there is no equivalent archive, no research access programme, and no historical corpus. Every paper in this population that analysed TV apps built its own set.
+  * **There is no TV-specific archive, but Android TV apps are inside AndroZoo.** The mobile page's whole first section is a comparison of bulk-download routes; for televisions there is no equivalent //TV// archive, no research access programme and no historical store-chart corpus — nothing you can cite a version of. What there is, for the Android-derived platforms only, is the general Android archive: {[tileria2022_watch]} pulled its 4,745 Android TV APKs from **AndroZoo and APKMirror**, having first found the package names through the Play Store, and {[girish2023_room]} drew 1,348 comparison apps from AndroZoo the same way. So the sampling problem is not "no bulk source" — it is that AndroZoo has no TV facet, so you cannot ask it for TV apps; you have to arrive with package names you obtained somewhere else. For Roku, Tizen and webOS there is no archive at all and every paper built its own set.
   * **The store //is// the platform.** The population sources these papers state are, verbatim: "Roku Channel Store" (3 papers), "Amazon Fire TV channel store", "Fire TV app store", "Amazon curated list 'Top Featured' apps", "Apple iTunes Preview / Apple App Store", "Roku-Top1K", "FireTV-Top1K". There is no cross-platform frame; a "top-1000 TV apps" result is a result about one vendor's chart on one day.
   * **Android TV apps are Android apps, and that is a route in.** {[tileria2022_watch]} obtained 4,745 Android TV APKs and ran ordinary Android tooling on them — LibScout for third-party libraries, a customised FlowDroid for taint flows — finding "at least one sensitive data flow in 78% of the files", advertising libraries in 77% and analytics in 75%. If your question is about SDKs rather than about the television, this is far cheaper than buying hardware.
@@ Line 208: / Line 218: @@
 | Android TV / Google TV | Android Advertising ID | the standard Google Play services API | as on mobile — see [[Design:Mobile and app measurement]] |
-Two measurement points follow. A TV advertising identifier is **device-scoped, not app-scoped**, so every app on the set shares it — which is why {[varmarken2020_smart]} could count 697 Fire TV apps sending the advertising ID alongside a serial number and a device ID, an identifier pairing that defeats the reset. And the opt-out is a **documented, testable control**: run your crawl twice, once each side of it, and report the difference. Exactly one paper in this population does that {[anselmi2024_watching]}.
+Two measurement points follow. A TV advertising identifier is **device-scoped, not app-scoped**, so every app on the set shares it — which is why {[varmarken2020_smart]} could count 697 Fire TV apps sending the advertising ID alongside a serial number and a device ID, an identifier pairing that defeats the reset. And the opt-out is a **documented, testable control**: run your crawl twice, once each side of it, and report the difference. Two papers in this population do that, five years apart and at different layers. {[moghaddam2019_watching]} repeated its whole Roku and Fire TV crawl with "Limit Ad Tracking" and "Disable Interest-based Ads" enabled, and concluded the countermeasures were "practically ineffective". {[anselmi2024_watching]} crossed the ACR opt-out with login state into four conditions — logged in or out, opted in or out — which is the stronger design, because on a television the account is a second identifier the ad control does not touch.
 ===== The Sampling Problem =====
@@ Line 221: / Line 231: @@
 | **A network vantage point** (an ISP, an IXP, a campus) | millions of devices in the wild | you see flows, not devices; identification is itself a classifier with an error rate |
-The sizes are the story. **20 of the 35 papers state an ''iot-devices'' population size**, 39 values between them, and the median stated value is **66 devices**. Taking each paper's largest set, the median is **75.5** and **14 of the 20 never exceed 96 devices** — that is the lab bench, and it is what a TV study looks like. Only six exceed it, and every one of them is a vantage point rather than a bench: 83,000,000 devices inferred from a security product's home-network scans {[kumar2019_things]}, 7,000,000 set-top boxes in an IPTV operator's own logs {[song2011_score]}, 54,950 and 25,123 from device fingerprinting at scale {[jakaria2024_dots]}, 31,850 and 26,478 from public Wi-Fi {[yu2020_broadcast]}, 13,487 from a crowdsourced smart-home dataset {[girish2023_room]}, and 2,014 from vendor certificate collection {[dong2023_behind]}. A separate IPTV study puts roughly **3,000,000** set-top boxes behind its traces {[gopalakrishnan2011_couch]}, though it records them as subscribers rather than as a device population, so it is not one of the 20.
+The sizes are the story. **20 of the 35 papers state an ''iot-devices'' population size**, 39 values between them, and the median stated value is **66 devices**. Taking each paper's largest set, the median is **75.5** and **14 of the 20 never exceed 96 devices** — that is the lab bench, and it is what a TV study looks like. Only six exceed it, and every one of them is a vantage point rather than a bench: 83,000,000 devices inferred from a security product's home-network scans {[kumar2019_things]}, 7,000,000 set-top boxes in an IPTV operator's own logs {[song2011_score]}, 54,950 and 25,123 from device fingerprinting at scale {[jakaria2024_dots]}, 31,850 and 26,478 from public Wi-Fi {[yu2020_broadcast]}, 13,487 from a crowdsourced smart-home dataset {[girish2023_room]}, and 2,014 from vendor certificate collection {[dong2023_behind]}. A separate IPTV study puts roughly **3,000,000** set-top boxes behind its traces {[gopalakrishnan2011_couch]} — the paper's own words are "the average number of set-top boxes provisioned was approximately 3 million" — but the extraction files that tuple under unit ''other'' rather than ''iot-devices'', so it falls outside the 20 by a taxonomy boundary, not by anything the paper did. Count it when you are asking how big an IPTV vantage point gets; do not count it when you are comparing device-set sizes.
 The sampling methods say the same thing: **purposive 19 papers, pre-existing-dataset 11, convenience 10, top-//n// 5, random 5**. In the corpus as a whole ''top-n'' is the signature of web-measurement work ([[Design:Sampling]]); here it is a minority route and it always means a store chart.
@@ Line 280: / Line 290: @@
 | ''browsers'' | **0 (0.0%)** | 529 (49.0%) |
-Read the zeros carefully: ''browsers'' is empty because a television is not driven with a browser, and ''consentAction'' is ''not-applicable'' or ''not-stated'' because none of these studies had a cookie banner to click. But ''statefulness'' is a real gap — **no paper in this population states whether the device was factory-reset between conditions**, which on a TV is the equivalent of a fresh browser profile and is the only way to know whether an ACR opt-out or a login carried over.
+Read the zeros carefully: ''browsers'' is empty because a television is not driven with a browser, and ''consentAction'' is ''not-applicable'' or ''not-stated'' because none of these studies had a cookie banner to click. But ''statefulness'' is a real gap, and the shape of the gap needs stating carefully. All **6** of the papers with an extracted ''crawlConfig'' object record ''statefulness'' as ''not-stated'' — so the structured field is empty for every paper that has one, and silent for the other 29, which is not the same as those 29 saying nothing. A full-text probe for //factory reset// over all 35 returns 2, and one is off-topic — a BLE re-pairing paper where a factory reset is how a device loses its key. The one that means what it says is {[tagliaro2023_still]}: "We perform a factory reset of the TV for each channel analysis to prevent interference in the captured traffic." One paper in thirty-five, and the field that was supposed to capture it is empty even there. On a TV this is the equivalent of a fresh browser profile and the only way to know whether an ACR opt-out or a login carried over, so say what you did.
 On the fields the corpus measures everywhere, this population is at or above the corpus norm:
@@ Line 292: / Line 302: @@
 ^ Paper ^ Availability ^ Artifact ^
-| {[varmarken2022_fingerprintv]} | promised, not yet available | ''github.com/UCI-Networking-Group/fingerprintv'' — last commit 2022-03-14 |
+| {[varmarken2022_fingerprintv]} | dataset released, code still promised | ''github.com/UCI-Networking-Group/fingerprintv'' — last commit 2022-03-14; its README still reads "Once it is ready for release to the public, the code will be added to this repository. Please stay tuned." four years on, while the dataset itself is out((GitHub, [[https://github.com/UCI-Networking-Group/fingerprintv|UCI-Networking-Group/fingerprintv]], README fetched 2026-09-13.)) |
 | {[tileria2022_watch]} | public | ''gitlab.com/s3lab-rhul/watch-over-your-tv-paper'' |
 | {[tagliaro2023_still]} | public | ''github.com/SecPriv/hbbtv-blocker'' — last commit 2024-09-24 |
 | {[anselmi2024_watching]} | public | ''github.com/SafeNetIoT/ACR'' — last commit 2024-09-09 |
 | {[kannan2024_acoustic]} | public | ''github.com/tejaskannan/smart-tv-keyboard-leakage'' — last commit 2023-11-17 |
-| {[ahn2025_watch]} | restricted | Zenodo, ''10.5281/zenodo.15646588'' |
+| {[ahn2025_watch]} | split: public artifact, restricted exploit | two Zenodo records — ''10.5281/zenodo.15646588'' is open (CC-BY-4.0, "[Public Artifact]") and ''10.5281/zenodo.15602938'' is the restricted exploit and peer-data half((Zenodo REST API, ''records/15646588'', ''access_right: open''. Checked 2026-09-13. The extraction records this paper's availability as ''restricted'', which is true of the second record only; an earlier version of this page attached that label to the open DOI.)) |
-None of the five public repositories has been touched in 2025 or 2026 (checked 2026-09-12). Treat them as reference implementations to read, not as maintained tools to depend on — ''mitmproxy'' itself, by contrast, is at v12.2.3 (2026-05-12) with commits this month.((GitHub API, ''repos/mitmproxy/mitmproxy'' and the five repositories above. Checked 2026-09-12.))
+None of the five repositories has been touched in 2025 or 2026 (checked 2026-09-13), and one of the five — {[varmarken2022_fingerprintv]} — has never contained the code it promises. Treat them as reference implementations to read, not as maintained tools to depend on — ''mitmproxy'' itself, by contrast, is at v12.2.3 (2026-05-12) with commits this month.((GitHub API, ''repos/mitmproxy/mitmproxy'' and the five repositories above. Checked 2026-09-12.))
 ==== Measured results you can cite ====
@@ Line 336: / Line 346: @@
 | **Static analysis of TV APKs** with mobile tooling | **Current**, and the cheapest route to scale. But LibScout and the third-party-library detectors it depends on are the same stalled tools flagged on [[Design:Mobile and app measurement]]. |
 | **Vendor remote-control APIs as the automation layer** (Roku ECP, ''adb'' keyevents) | **Current.** Roku's ECP is still documented on port 8060 in 2026. |
-| **Broadcast-side injection with DVB modulators** | **Current and unreplicated.** {[oren2014_aether]} is twelve years old; {[tagliaro2023_still]} did the passive half. Nobody has repeated the active experiment. |
+| **Broadcast-side injection with DVB modulators** | **Current and unreplicated.** {[oren2014_aether]} is twelve years old; {[tagliaro2023_still]} did the passive half. No paper in these seven venues has repeated the active experiment. |
 | **Treating a TV as one row in an IoT device table** | **Still the commonest thing that happens**, and still not a TV measurement. It is how 15 of the 35 papers here touch televisions. |
-| **LLM-based classification** | **Absent.** Not one paper in this population uses an LLM for anything. Compare the corpus-wide picture on [[Statistics:Annotation]]: this is a gap, not a considered rejection. |
+| **LLM-based classification** | **Present, but never pointed at the television.** Two of the 35 use one: {[girish2023_room]} and {[jakaria2024_dots]} both prompt OpenAI's Text Completion API to infer a device's vendor and category from its DHCP hostname and mDNS/SSDP responses — an LLM used as a device-name resolver, not as a content or tracker classifier. Nobody has used one on TV app metadata, store descriptions, ACR payloads or privacy policies, which is where the corpus-wide picture on [[Statistics:Annotation]] says the method has gone. That is the gap, and it is a narrower and more interesting one than "nobody uses LLMs here". |
 ===== What Does Not Transfer =====
@@ Line 360: / Line 370: @@
   * **The automation interface** you used, verbatim — ''adb'' keyevents, ECP URLs, an IR blaster — and how you knew the action landed. Screen capture is a check, not decoration.
   * **The store, the chart, and the date** for any app or channel set, plus the per-app identity you used, since the same title is a different binary per platform.
-  * **Both sides of the opt-out.** If the platform documents an advertising-identifier or ACR control, measure with it on and off, and report the difference. One paper in this literature does this.
+  * **Both sides of the opt-out.** If the platform documents an advertising-identifier or ACR control, measure with it on and off, and report the difference. Two papers in this literature do it ({[moghaddam2019_watching]}, {[anselmi2024_watching]}), and only the second crosses it with login state.
   * **The country**, at the top. Half of the findings here are jurisdiction-specific, and after the 2026 Texas agreements a US result and an EU result are measurements of different products.
@@ Line 366: / Line 376: @@
 <WRAP todo>
-  * **Nobody has re-measured smart-TV tracking since 2024, and the two vendors with the largest ACR businesses settled with a regulator in 2026.** A replication of {[anselmi2024_watching]} against the post-settlement firmware is the single highest-value study on this page, and the authors released their infrastructure.
+  * **No paper in these seven venues has re-measured smart-TV tracking since 2024, and two of the five vendors Texas sued settled in 2026.** A replication of {[anselmi2024_watching]} against the post-settlement firmware is the single highest-value study on this page, and the authors released their infrastructure.
   * **The ACR literature is two televisions.** Not two vendors, not two models per vendor — two sets. Any measurement with a device set in the tens would be the largest in the field.
-  * **ATSC 3.0 is unmeasured in these seven venues.** It reaches more than 76% of US households, its broadcaster applications explicitly support profile-based personalisation and data collection, and no paper in this corpus touches it. The HbbTV work shows exactly how it would be done.
+  * **ATSC 3.0 is unmeasured in these seven venues.** It reaches more than 76% of US households, and A/344 gives its broadcaster applications a standardised persistent ''advertisingId'' with an observable opt-out, broadcaster-defined ''filterCode'' personalisation categories with no public vocabulary, and cookie storage on the receiver. Every one of those is an object this wiki has web instruments for and no TV instrument for, and a full-text probe finds no paper in this corpus measuring any of them. The HbbTV work shows exactly how it would be done.
-  * **Nobody has measured TV consent flows.** The Texas agreements require consent screens on shipped televisions. The methods on [[Privacy:Consent]] cannot see them and no TV paper has ever recorded a ''consentAction''. Somebody has to invent the instrument.
+  * **A regulator has published a testbed result that no paper has replicated.** The four-authority Article 62 report measured three televisions across first install, standby, off and ordinary use, and found 91–99% of the "off"-state flows going to the OS provider. Nobody in these seven venues has measured a television in the off state at all. The UK ICO's guidance, meanwhile, is a **published compliance standard with nothing measured against it** — it says what consent, transparency and rights tooling on these devices should look like, and no study has checked whether any television does it.
+  * **Nobody has measured TV consent flows.** The Texas agreements require consent screens on shipped televisions. The methods on [[Privacy:Consent]] cannot see them, and no paper in this 35-paper population has a stated ''consentAction''. Somebody has to invent the instrument.
   * **There is no maintained TV app corpus.** No AndroZoo, no archived store charts, no versioned frame. Every result here rests on a device list somebody bought and a chart somebody scraped once.
   * **TLS interception on closed TV platforms is an open problem, not a solved one.** The best published Roku result is 4.3% of channels, from 2019. A technique that raises it would be reused by every paper after it.
-  * **Nobody has published the TV share of household traffic in a way this literature can cite.** {[wang2024_characterizing]} classifies device platforms for 100M+ video flows and {[akhtar2018_video]} reports set-top boxes dominating by view-hours, but neither gives a denominator a TV-privacy paper can use to say how much of the problem it is describing.
+  * **No paper in these seven venues publishes the TV share of household traffic in a way this literature can cite.** {[wang2024_characterizing]} classifies device platforms for 100M+ video flows and {[akhtar2018_video]} reports set-top boxes dominating by view-hours, but neither gives a denominator a TV-privacy paper can use to say how much of the problem it is describing.
 </WRAP>