Skip to content

Conference Digest

ACM IMC 2026

hellt/conference-digest

ACM IMC 2026#

Eighteen items from the IMC 2026 program, tiered by relevance. Note on depth: no full-paper source text was available to this run, and the program page fetch returned only the same abstracts — every write-up below is grounded in the abstract alone. IMC is a measurement conference, so expect empirical characterizations and measurement tooling rather than systems you deploy directly; the value here is calibrated intuition about how the Internet's security and routing layers actually behave.

October 12, 2026 – October 16, 2026 Program

Core#

Honey Configs: Measuring The Emerging Exploitation of Cloud IP Address Reuse #

Authors: Eric Pauley (Virginia Tech & Terrace Networks), Yohan Beugin (University of Wisconsin-Madison), Paul Barford (University of Wisconsin-Madison), Patrick Traynor (University of Florida), Patrick McDaniel (University of Wisconsin-Madison)

Why: The 2021 "cloud IP address reuse" vulnerability class (tenants pinning trust — allowlists, firewall rules, cert SANs — to public IPs that the provider will re-allocate to someone else) is directly relevant to anyone operating multi-cloud infrastructure. This is one of the few papers measuring both whether defenders fixed it and whether attackers are actually exploiting it.
What: A three-year longitudinal study of defender and attacker response. The headline findings are bad on both sides: 60% of originally-observed vulnerabilities were still present years after disclosure, and exploitation has increased 39x since the original disclosures. The active measurement surfaces a global, multi-cloud adversarial apparatus that identifies and exploits latent configurations — hosting malicious content, mal-issuing TLS certificates, and executing cookie-based attacks on target sites. (from abstract only)
How: Combines passive data (the DScope Internet telescope, certificate transparency logs) with a new active technique — honey configurations — deliberately deployed configurations that act as tripwires to directly measure exploitation rather than infer it.
Where applicable: Any organization using public cloud IPs with IP-bound trust relationships. Broadly applicable across major cloud providers; the attacker observations are from research vantage points, so treat specific attacker behaviors as a lower bound rather than a census.

Mind the Gap: Policy vs Reality in Post-Quantum TLS Deployment #

Authors: Nimesha Wickramasinghe (UNSW), Frank Li (Georgia Tech), Sanjay Jha (UNSW), Arash Shaghaghi (UNSW)

Why: If you own or influence TLS-terminated services, the PQC migration is now an operational question, not a planning exercise. This paper tells you where the Internet actually is versus where government roadmaps say it should be — useful both for your own rollout sequencing and for evaluating vendor readiness claims.
What: Three measurement rounds (July 2025–March 2026) covering one million public HTTPS endpoints, with over two billion TLS 1.3 handshakes from 11 distributed vantage points. Key findings: every observed post-quantum negotiation converged on the same hybrid — X25519MLKEM768 — but there is no verified deployment of post-quantum signature algorithms for authentication; hybrid adoption is concentrated in managed infrastructure providers; country/sector deployment does not track published transition timelines; and — counter to earlier experimental studies — hybrid key exchange showed no meaningful latency penalty in Internet settings. (from abstract only)
How: Large-scale active TLS handshake measurement characterizing cryptographic negotiation behavior, cross-referenced against endpoint attribution (provider, country, sector) and against a survey of published PQC transition policies.
Where applicable: Public-facing HTTPS broadly. The latency finding is calibrated to Internet RTT regimes — it does not tell you the handshake cost inside a datacenter fabric, so don't extrapolate it to internal service-to-service TLS.

A First Look at Certificate Revocation Latency #

Authors: Nehal Fooda (University of Maryland), James Larisch (Cloudflare), John Schanck (Mozilla), Bruce Maggs (Duke University and Emerald Innovations), Tijay Chung (Virginia Tech), Dave Levin (University of Maryland)

Why: Revocation is the last line of defense after key compromise, and the entire chain has been measured except one leg: how long a CA takes to turn a revocation request into publicly downloadable revocation data. If you run incident response for key compromise, that leg determines your real remediation window.
What: The first study of CA-side revocation-data publication latency, covering six of the most popular CAs across both CRL and OCSP, plus end-to-end latency through to Mozilla Firefox's CRLite. Headline: CAs generally operate on tighter bounds than the CA/B Baseline Requirements strictly require, but some major CAs still show up to 24-hour delays from request to availability. (from abstract only)
How: A custom tool that requests revocations and polls/downloads the resulting revocation state, varying time of day, distribution mechanism (CRL vs OCSP), reason code, and other factors; separately measures end-to-end propagation into CRLite.
Where applicable: Web PKI broadly — relevant to incident-response playbooks (what "revoked" actually means hour-by-hour), and to CA/BR policy work. The CRLite end-to-end numbers are Firefox-specific.

Calypso's Voyage: Charting Traceroute Paths to Submarine Cables #

Authors: Caleb Wang, Ying Zhang, Qianli Dong, Esteban Carisimo (Northwestern University), Ramakrishnan Durairajan (University of Oregon), Fabian Bustamante (Northwestern University)

Why: Submarine cables are the physical substrate of every intercontinental WAN and cloud-region interconnect. Knowing which cables a path actually rides — and which cables are disproportionately stressed — is foundational to reasoning about interconnect capacity, redundancy, and geopolitical/physical risk.
What: Calypso, a framework that maps traceroute paths to the specific submarine cables they traverse, plus Route Stress, a traceroute-derived metric estimating the relative importance of individual cables. Validated through expert validation, failure analysis, and regional case studies demonstrating SCN dependency discovery. (from abstract only)
How: Integrates cable ownership records, routing metadata, and geographic constraints to infer cable usage despite the opacity of the submarine cable network — handling complications like route virtualization and inland infrastructure before/after landing points.
Where applicable: Research and policy tool rather than an operational one; inference-based, so its accuracy is bounded by public ownership/routing data. Directly useful for WAN/interconnect planners assessing which cable systems their traffic depends on and for resilience studies.

Waiting at the front door: Continuous monitoring of latency in the host network stack #

Authors: Simon Sundberg, Anna Brunstrom (Karlstad University), Simone Ferlin-Reiter (Red Hat and Karlstad University), Jesper Dangaard Brouer (Cloudflare), Toke Høiland-Jørgensen (Red Hat)

Why: Once network paths drop into sub-millisecond territory — RDMA-era fabrics, co-located services — the host itself (NIC–CPU interconnect, kernel network stack, scheduling) becomes a first-order latency source. This is the paper at the intersection of your Linux datapath-internals interest and production reality, with authors from Red Hat and Cloudflare. Promoted from Adjacent: kernel-stack latency instrumentation in a production CDN is squarely core.
What: netstacklat, a monitoring tool that continuously captures latency at multiple points in the host network path, from the earliest parts of the Linux kernel network stack through to the application's read. Evaluated across 144 HTTP workload variations (Nginx and Apache), with monitoring overhead inflating tail latency by no more than ~6%, versus >100% for previous monitoring solutions. Includes initial findings from deployment in Cloudflare's global CDN. (from abstract only)
How: Lightweight instrumentation at several points along the host network path, designed for continuous production use rather than one-off tracing; testbed evaluation for overhead characterization plus real deployment experience.
Where applicable: Linux hosts running latency-sensitive services. The deployment context is Cloudflare's CDN, but the technique is general Linux tooling — applicable to any production fleet where you need to attribute latency between NIC, kernel, and application.

RScope: Unveiling Global ROV Deployments and Dependencies in the Post-ROV Era #

Authors: Weitong Li, Yongzhe Xu (Virginia Tech), Mingwei Zhang, Vasileios Giotsas (Cloudflare), Taejoong Chung (Virginia Tech)

Why: RPKI/ROV is the routing-security mechanism the industry is standardizing on, and this paper answers the question every operator should ask before relying on it: who is actually filtering, versus who merely looks protected because their upstream does? Promoted from Adjacent: empirical routing-security deployment data is core to network-security work.
What: RScope maps ROV deployment and dependencies across 21,827 ASes. Findings: 1,127 ASes actively deploy ROV themselves; 1,815 rely purely on upstream filtering, and 69.6% of those "protected" ASes remain vulnerable to local hijacks. Leverage is starkly concentrated: enabling ROV in the top 100 ASes protects 27.6% of networks, while disabling it in Tier-1s exposes 23.8% to hijacks. Operationally notable: router enforcement lags ROA updates by 37 minutes on average. (from abstract only)
How: Dynamically manipulates Route Origin Authorizations from controlled publication points to isolate the effect of individual Relying Party (RP) servers — selectively invalidating prefixes for specific RPs and probing resulting connectivity changes — which sidesteps the classic confound between local ROV adoption and upstream filtering.
Where applicable: Global BGP routing. The framework requires controlled ROA publication points (research-grade setup, tools and data open-sourced), but the findings — which ASes actually filter, where RP fragility lies — are directly consumable by anyone planning RPKI rollout or assessing hijack exposure.

Adjacent#

Characterizing the Deployment of the STIR/SHAKEN Telephone Network PKI #

Authors: Hamim Hamid, David Adei, Bradley Reaves (North Carolina State University)

Why: A rare natural experiment in federated identity infrastructure: a brand-new, industry-wide, federated PKI mandated and deployed in under two years. For anyone designing or operating federated trust frameworks (and thinking about PKI hygiene generally), the failure modes documented here are the canonical ones to design against.
What: A longitudinal study (Nov 2021–Feb 2026) of STIR/SHAKEN deployment from signaling data on 7.75 million calls collected by telephone honeypots. Rapid adoption, but pervasive standards non-compliance: providers signing calls with root keys, and originating calls with pre-signed attestations copied from unrelated calls. Practices and compliance are improving, but only at a modest pace. (from abstract only)
How: Longitudinal honeypot signaling-data analysis across standards compliance, CA practices, and provider call signatures/metadata.
Where applicable: US telephone network, mandate-specific context. The transferable content is the pattern — what a rushed federated PKI rollout actually looks like in practice — which generalizes to any federated trust ecosystem.

EU Digital Sovereignty in Practice: A Technical Assessment of Digital Infrastructure Dependencies #

Authors: Jürgen Brandl (TU Wien), Florian Holzbauer (IT:U), Aaron Kaplan (European Commission, DIGIT S.2), Johanna Ullrich (IT:U), Adrian Dabrowski (University of Applied Sciences Technikum Wien)

Why: Quantifies, for the first time systematically, how dependent EU institutions are on non-EU infrastructure. If your organization has EU regulatory exposure (NIS2, DORA) or sells into regulated EU sectors, this is a concrete dependency map of your customers' environment.
What: Empirical analysis of 1,988 domains across government, banking, media, and higher education in all 27 EU member states, across six sovereignty dimensions: nameservers, web hosting, external resources, certificate authorities, email, and SaaS. Only 61 domains (3%) show no detectable non-EU dependency. Key exposures: CDN/DDoS services, cloud-hosted email, office suites, and TLS certificates. A neat methodological detail: internal third-party SaaS deployments are detected via domain verification tokens. (from abstract only)
How: Collection of DNS records, TLS certificates, and HTTP responses; dependencies classified by criticality and EU/non-EU status, spanning infrastructure through application layer.
Where applicable: EU-regulated sectors specifically. The dependency categories (CDN, email, CA, SaaS) transfer well to any sovereignty/supply-chain assessment exercise; open dataset released for replication and monitoring.

The Disputed Internet: Quantifying Fragmentation in the IPv6 Internet #

Authors: Vivian Band (University of Glasgow), Romain Fontugne (IIJ Research Laboratory)

Why: As your dual-stack footprint grows, IPv6 reachability is not a clean mirror of IPv4 — peering disputes (the Cogent–Hurricane Electric case being the exemplar) fragment the IPv6 topology. Anyone running IPv6-only or IPv6-preferred infrastructure should understand this failure mode.
What: Quantifies IPv6 fragmentation via BGP-measured reachability differences between large transit providers, and uses forward DNS data to estimate the impact on popular website reachability. Findings: IPv6 fragmentation is substantial relative to the unified IPv4 topology, is worsening over time, and an increasing number of popular sites are partially reachable in IPv6. IPv4 fallback currently masks the user-facing impact. (from abstract only)
How: BGP-based reachability comparison across large transits in both protocols, plus forward-DNS-based estimation of popular-site impact.
Where applicable: Global Internet; most relevant if you operate or depend on IPv6-heavy paths. The mitigating reality today is happy-eyeballs-style fallback, so treat this as a structural risk to monitor rather than a current outage driver.

Split Alignment: Diffusing SPF Vulnerabilities With DMARC #

Abstract Paper Recording

Authors: Muhammad Hamza, Eric Pauley, Taejoong Chung (Virginia Tech), Mattijs Jonker, Raffaele Sommese (University of Twente), Simon Fernandez, Olivier Hureau (Univ. Grenoble Alpes, CNRS, Grenoble INP, LIG)

Play the recording: Split Alignment: Diffusing SPF Vulnerabilities With DMARC

Why: Authentication protocols don't compose safely — SPF weaknesses, when layered with DMARC's organizational context, can enable organization-wide spoofing. This is a good study of how layered auth protocols amplify each other's flaws, with a deployable fix.
What: A comprehensive empirical analysis finding 528k vulnerable SPF policies which, paired with DMARC, enable spoofing of 79k domain hierarchies. The proposed mitigation, Split Alignment, is a configurational technique that protects established sending domains from all SPF failures anywhere in their hierarchy. The validation methodology also surfaced critical DMARC authentication-flow bugs in four major email services (disclosed). (from abstract only)
How: Large-scale dataset analysis of layered email-auth policies; the mitigation is pure configuration — no protocol change — validated with a reproducible security-and-deliverability test methodology.
Where applicable: Any organization that sends email at scale and uses SPF/DMARC. Broadly applicable since it is a domain-owner-side configuration technique; the disclosed service bugs show some receivers may mis-handle the configuration, so roll out with the deliverability validation in mind.

Taming DNS Responses: A Measurement Study of Response Size and Its Impact #

Authors: Zihan Li, Wenhao Wu, Zhaohua Wang, Yu Tian, Chuan Gao, Qinxin Li, Yiming Xia, Zhenyu Li (Chinese Academy of Sciences)

Why: DNS is increasingly a carrier for structured metadata and service-discovery data, and that growth directly feeds UDP amplification risk. If you operate resolvers or reason about DDoS surface, the global response-size picture matters.
What: A year-long measurement of response-size behavior across roughly one million open resolvers. Findings: resolver-enforced UDP response-size limits cluster around a small set of common values; configuration changes at major public resolvers propagate across the ecosystem; and regional differences in limits create uneven amplification risk, exposing limits of existing static and upstream-based defenses. Proposes Adaptive Response Scaling (ARS), a lightweight dynamic response-control mechanism claimed to reduce amplification by over 70% while preserving DNS functionality. (from abstract only)
How: Longitudinal measurement of resolver response-size limits across the open-resolver population, plus analysis of how major-resolver configuration changes propagate.
Where applicable: DNS operators and public resolvers broadly. ARS is a proposal evaluated by the authors, not a deployed standard — the measurement findings are solid ground, the mitigation is directionally promising.

namefill: Synthesizing DNS Naming Conventions #

Authors: Joel Sommers (Colgate University), Calvin Kranig, Wei-Shiang Wung, Paul Barford (University of Wisconsin-Madison), Mark Crovella (Boston University), Eric Pauley (Virginia Tech & Terrace Networks)

Why: DNS naming conventions leak infrastructure topology and operational structure — this work makes them machine-usable both for asset discovery and for auditing your own records. For anyone who cares about IPAM hygiene or infrastructure enumeration, this is a genuinely new tool capability.
What: namefill uses programming by example to synthesize executable functions that summarize DNS naming conventions. Unlike regexes, the synthesized functions can generate predicted FQDNs, enabling active probing for undiscovered names and systematic auditing of existing records. Applied to 1.2 billion PTR records: 313K distinct conventions across 254K domains, covering 67.7% of IP/FQDN pairs (complementary to geotoken-focused tools). Found 991 misconfigurations (43 verified with operators) and, as a discovery tool, surfaced 194M previously unrecorded forward DNS names from 2.76M training names — a 70× expansion. (from abstract only)
How: Programming-by-example synthesis over PTR records; validation against CAIDA's ITDK dataset; systematic anomaly detection using the synthesized functions; active enumeration queries for discovery.
Where applicable: General technique — researchers and operators auditing reverse DNS or discovering infrastructure. Note the dual-use nature: the same discovery capability that finds your misconfigurations finds your unrecorded hosts.

Securing the Missing Link: Encrypted Recursive-to-Authoritative DNS in the Wild #

Authors: Yevheniya Nosyk, Simon Fernandez, Andrzej Duda, Maciej Korczyński (KOR Labs / Univ. Grenoble Alpes, CNRS, Grenoble INP, LIG)

Why: The recursive-to-authoritative hop is the last unencrypted DNS link, and it is the one state censors have demonstratively used for traffic analysis and response injection. RFC 9539 (opportunistic ADoT/ADoQ) is the mechanism intended to close it — this paper tells you how much of the Internet actually speaks it.
What: A measurement of RFC 9539 deployment covering both recursive resolvers and authoritative nameservers. Bottom line: fewer than 1% of registered domains (3.1M) support authoritative DoT or DoQ, with one provider accounting for the vast majority of those deployments. (from abstract only)
How: Probing resolvers and authoritative nameservers for opportunistic DNS-over-TLS / DNS-over-QUIC support per the RFC 9539 mechanism.
Where applicable: DNS operators weighing authoritative-side encryption; also useful context for standards bodies tracking adoption. The near-absence of deployment means privacy-sensitive resolvers currently get almost no recursive-to-authoritative confidentiality in practice.

When BGP Goes MAD: Multi-Scale Anomaly Detection in Internet Routing #

Authors: Justin Loye, Romain Fontugne (IIJ Research Laboratory), Esteban Bautista (Univ. Littoral Cote d'Opale, LISIC)

Why: Outage and route-leak detection that operators could actually run — near real-time, unsupervised, and without large training datasets — has been a persistent gap. This is a credible attempt to close it.
What: MADBGP, an anomaly-detection pipeline combining (i) a temporal-graph modeling of the AS-level Internet, (ii) QuickRIB, a scalable tool for generating temporal graphs from public BGP data, and (iii) an extension of the MAD temporal-graph anomaly-detection method to weighted graphs, applied to real BGP anomalies for the first time. On ten major BGP events (outages and route leaks at different scales), it reportedly significantly outperforms IODA's BGP results. (from abstract only)
How: Unsupervised, multi-scale detection over a temporal graph representation of the AS-level Internet built from public BGP feeds, operating near real-time.
Where applicable: Network operators and researchers monitoring global routing health; consumes public BGP data, so no special vantage required. The outperformance claim is relative to IODA's BGP stream on selected events — validate on your own telemetry before operational reliance.

Wildcard#

Lightscope: Turning Production Machines into Telescopes and Honeypots #

Authors: Eric Kapitanski, Jelena Mirkovic (USC Information Sciences Institute)

Why: A genuinely new vantage point for Internet security measurement. The insight — attackers avoid known dark-space sensors and behave differently toward production endpoints — means your own production fleet is an underused sensor, and this work proves it quantitatively.
What: LightScope, a lightweight application that unifies passive Layer-4 observation with selective proxying to a remote Layer-7 honeypot, running on unused ports of production servers. Two months of data from 235 deployments shows scanner populations, port-targeting profiles, and post-login behaviors only partially visible from dark-space telescopes and honeynets — including 64,686 scanners observed by LightScope and no other vantage point. (from abstract only)
How: Embeds measurement on production hosts themselves, using a subset of unused ports; selective L7 proxying to a remote honeypot captures post-exploit behavior without putting production at risk.
Where applicable: Any production fleet with unused ports — broadly applicable technique, not org-specific. Worth understanding even if you never deploy it, because it changes how you interpret coverage gaps in your own threat telemetry.

Eadem, Sed Aliter: Investigating the Instability of Browser Fingerprinting #

Authors: Xu Lin, Jacob Anthony Eckfeldt (Washington State University), Shujiang Wu, Pengfei Sun (F5, Inc.), Jason Polakis (University of Illinois Chicago)

Why: Browser fingerprinting increasingly shows up as an authentication and fraud signal, so its actual stability matters to identity work. This paper subverts the community's established understanding: fingerprints are inherently unstable even when nothing about the device changes.
What: An in-depth analysis of fingerprints from users authenticating to high-value web services, revealing that prevalent attributes change even in stable execution environments (e.g., minor deviations in browsers' floating-point arithmetic or HTML element-size calculations) — a fundamental obstacle to fingerprinting's real-world effectiveness. It then proposes Predictive-FP, an adaptive strategy that uses historical population-wide information to anticipate unstable values and ignores ephemeral attributes, re-identifying ~51% more devices after 6 months than state of the art. A configurable privacy-preserving browser extension counteracts the technique on non-allowlisted sites. (from abstract only)
How: Longitudinal attribute-stability analysis over a production authentication dataset, followed by adaptive prediction modeling that separates stable-in-principle attributes from ephemeral ones.
Where applicable: Web services using device fingerprinting for auth or fraud. Dual-edged finding: it both improves fingerprint-based re-identification (a privacy risk the authors address) and tells you not to over-trust raw fingerprint stability in your own systems.

A System for Fast, Accurate, and Intuitive Querying of Large-Scale BGP Datasets #

Authors: Thomas Holterbach, Thomas Alfroy (bgproutes.io), Abbas Mohsenpour (UCLouvain), Thomas Krenc (IIJ Research Laboratory), kc Claffy (CAIDA), Cristel Pelsser (UCLouvain)

Why: Not a paper about networking per se, but a strong signal of where infrastructure tooling is heading: LLM-synthesized code over purpose-built compressed data stores. The pipeline — measurement insight (BGP data is highly redundant and compressible) enabling a domain API that an LLM can drive — is a template worth stealing for any large operational dataset you own.
What: ChatBGP, a domain-specific chatbot that turns plain-English BGP questions into Python code running against a compressed BGP database, returning answers in seconds rather than the hours that MRT-archive analysis takes. Four contributions: a measurement study showing BGP data is highly redundant and compressible; a database scheme exploiting that redundancy for fast retrieval; an expressive API over the database; and a prompt-engineering scheme guiding ChatGPT to synthesize optimized, minimal-retrieval Python against that API. (from abstract only)
How: Redundancy-aware compression plus a query-shaped API, with the LLM constrained to synthesize code that retrieves only the data each query needs.
Where applicable: RIPE RIS / RouteViews-class BGP data; aimed at operators diagnosing connectivity issues, researchers, and students. Note the accuracy depends on LLM code synthesis — attractive for triage and exploration, but verify before acting on results in a production incident.

Replicability: Challenging the Myth of Randomness Patterns in Encrypted Traffic #

Authors: Timofey Shpakov (ETH Zürich), Martin Burkhart (armasuisse Science and Technology), Laurent Vanbever (ETH Zürich)

Why: A methodological correction with real consequences: several recent studies (most prominently the often-cited ET-BERT) claim encrypted traffic exhibits detectable randomness deficiencies usable for application classification. If those evidentiary foundations are artifacts, a chunk of the encrypted-traffic-classification literature — and vendor claims built on it — rests on sand.
What: A systematic replication of the randomness experiments, re-implemented with the NIST Statistical Test Suite on encrypted traffic generated under controlled conditions. The reported statistical signals do not provide sufficient evidence of non-randomness beyond what statistical hypothesis testing and finite-sample effects would produce. Observed test failures and discriminative patterns are consistent with methodological artifacts: improper aggregation, p-value misinterpretation, and train/test information leakage. (from abstract only)
How: Controlled-condition re-implementation of prior experiments, examining the evidentiary step — the claim that detectable patterns exist in ciphertext — rather than the downstream classifiers.
Where applicable: Anyone evaluating encrypted-traffic classification research or products, or building on randomness-based classification themselves. The authors are careful to scope the critique: it says nothing about methods exploiting metadata, packet sizes, timing, or other side channels.

Themes#

Accountability measurement is a genre now: Honey Configs, PQ-TLS, and STIR/SHAKEN all return years after a disclosure or mandate to ask "did anything actually change?" The field is increasingly auditing ecosystem outcomes longitudinally, and the recurring answer is that defenders lag while attackers do not.
Routing security is being grounded empirically: RScope (who really deploys ROV vs who free-rides on upstream filtering), MADBGP (near-real-time anomaly detection from public BGP), and the IPv6 fragmentation study collectively replace assumption with measurement across the routing-security stack — and show leverage concentrated in a handful of Tier-1/top-100 ASes.
The host stack re-enters scope: netstacklat's premise — that sub-millisecond network ambitions make NIC–CPU, kernel stack, and scheduling latency first-order measurable bottlenecks — matches where datapath engineering is going, and it ships with Cloudflare production validation.
DNS is being stretched by its new roles: as DNS carries structured metadata and service-discovery data, response size becomes an amplification risk (Taming DNS Responses), authoritative encryption remains a rounding error (ADoT/ADoQ), and naming conventions themselves become synthesizable, auditable infrastructure data (namefill).
Policy versus practice is a measurable gap: EU sovereignty dependencies, PQC transition timelines vs actual handshakes, and PKI mandates vs telephony practice all show regulation running ahead of deployment — useful ammunition for prioritizing real migration work over compliance paperwork.
The community is policing its own citations: the ET-BERT randomness replication and the replication-track website-complexity work show IMC actively challenging widely-cited results — a healthy rigor signal for anyone consuming this literature as product input.

About this digest

ToFaRev picked and wrote this digest on Nebius Token Factory, from the conference's published program. A person reviewed it in a pull request before it was published. Write-ups marked "from abstract only" had no fuller source to read. Source: digests/imc-2026.md · prompt: prompts/imc-2026.md