Abortion access is being restricted through network-layer filtering rather than traditional content takedowns. OONI measurements from November 2025 to April 2026 show consistent blocking of Women on Web domains across seven countries using DNS tampering, TLS handshake interference, and IP-level routing manipulation. The pattern is not uniform, but the outcome is the same: interruption of access to abortion information and telemedicine services via standard web infrastructure.
What changed in access to Women on Web?#
The dataset shows expanded and technically diverse blocking of Women on Web across Iran, Türkiye, the Philippines, South Korea, Spain, Kuwait, and Argentina. The most mature enforcement appears in Iran, where blocking has been present since 2019 and is visible across most tested networks, including DNS responses that resolve to government-controlled infrastructure and TLS-level disruption after the ClientHello phase. South Korea shows sustained, technically active enforcement since 2019, including blocking of additional circumvention domains, not just the primary site.
In Spain, blocking persists across multiple major ISPs, including Telefónica and Vodafone networks, despite a 2022 Supreme Court order to restore access. Technical mechanisms vary over time: TLS interference, certificate-based inspection infrastructure, and DNS-level redirection have all been observed in different periods. The Philippines shows DNS injection patterns, including NXDOMAIN responses and redirects to government or telecom-controlled block pages. Türkiye exhibits TLS handshake termination signals and DNS responses tied to state-linked telecom infrastructure. Kuwait shows narrower, network-specific interference windows, while Argentina presents newer and less stable signals of restriction.
Definition capsule: Women on Web is an international nonprofit telemedicine provider offering abortion pills and related medical guidance, alongside research and advocacy work on reproductive health access and decriminalization.
Blocking techniques across countries#
| Country | Primary method | Network behavior signal | Scope/notes |
|---|---|---|---|
| Iran | DNS + TLS + IP routing | Government IPs in DNS, handshake interruption | Long-running, strongest signal |
| Türkiye | TLS interference + DNS signals | ClientHello interruption, telecom-linked IPs | Multi-network enforcement |
| Philippines | DNS injection | NXDOMAIN, redirect to block pages | ISP-level variability |
| South Korea | TLS + domain expansion blocking | Post-ClientHello termination, circumvention ban | Active enforcement model |
| Spain | TLS + certificate inspection | Intermittent Allot-like certificates, TLS shift | Multi-ISP persistence |
| Kuwait | Limited TLS interference signals | Partial network coverage | Uncertain scope |
| Argentina | Emerging DNS/TLS signals | Inconsistent blocking indicators | Early-stage pattern |
Why it matters for security operations and access control#
Blocking in this dataset is not implemented as a single centralized system. It emerges from ISP-level enforcement using different infrastructure layers: DNS resolvers, TLS inspection devices, and traffic routing manipulation. From a security operations perspective, this creates fragmented failure modes. A service may appear online, resolve correctly, and still fail at the TLS handshake stage.
This has direct implications for privacy risk and operational checks in open networks. Users do not see explicit error messages indicating censorship. Instead, they see partial connectivity: resolved domains, successful TCP handshake, and then silent termination during encrypted session setup. That ambiguity is structurally important because it hides enforcement inside normal network failure behavior.
For infrastructure teams and open source security analysis, this aligns with broader patterns documented in operational tooling research such as OpenSSF’s work on making security artifacts verifiable in practice: https://gigatap.top/en/articles/openssfs-april-signal-make-security-artifacts-operational . The same principle applies here: visibility of enforcement requires measurement, not assumptions.
What to check in censorship and interference environments#
Detection depends on layered verification rather than single-request outcomes. DNS resolution alone is insufficient. TCP handshake success does not guarantee application-layer reachability. TLS negotiation behavior becomes a key signal, especially when failures occur after ClientHello.
Operational checks typically include:
- comparing DNS responses across resolvers
- validating TCP connectivity separately from TLS completion
- detecting certificate anomalies or injected certificates
- cross-network measurement aggregation
This mirrors broader reliability thinking in distributed systems, where surface availability metrics can hide deeper failure states. Similar principles appear in testing discipline discussions such as https://gigatap.top/en/articles/100-package-test-coverage-is-the-point-not-the-slogan , where measurement completeness matters more than headline coverage metrics.
What not to overclaim#
The OONI dataset shows strong evidence of blocking in specific networks and time windows, but coverage is not uniform globally. Kuwait and Argentina show limited or emerging signals, not fully mapped enforcement. Some cases may reflect collateral routing effects rather than intentional censorship. Corporate firewall filtering in countries such as Poland, Kenya, Pakistan, and Georgia further complicates attribution, since enterprise systems can mirror ISP-level blocking behavior without state coordination.
The data does not establish a single global policy trend. It shows a distributed set of enforcement decisions implemented through shared technical primitives: DNS manipulation, TLS interruption, and traffic filtering appliances. Attribution must stay local to measurement conditions.
This distinction matters in open source security analysis more broadly. As discussed in https://gigatap.top/en/articles/open-source-security-needs-more-than-code , infrastructure behavior cannot be reduced to code review alone. Network context, deployment environment, and intermediary systems shape actual access outcomes.
FAQ#
How is blocking technically detected in this study?#
Through OONI measurements combining DNS resolution analysis, TCP connection testing, and TLS handshake observation. Failure patterns after ClientHello are a key indicator of active interference.
Why do results differ between countries?#
Because enforcement is implemented at ISP level using different vendor hardware, policy rules, and filtering strategies. There is no single standardized censorship system.
Can DNS errors alone confirm censorship?#
No. NXDOMAIN or redirect responses may indicate blocking, misconfiguration, or resolver behavior. They require cross-validation with network and TLS tests.
Does this prove complete loss of access to Women on Web globally?#
No. It shows partial and network-specific blocking across measured regions, not universal unavailability.