A US Bill Wants VPNs to Block Access to Piracy Sites From the United States. Deciding Who Is There Is an IP Problem

A US Bill Wants VPNs to Block Access to Piracy Sites From the United States. Deciding Who Is There Is an IP Problem

On September 14, 2026, Rep. Darrell Issa introduced H.R. 10364, the American Copyright Protection Act of 2026, and it went to the House Judiciary Committee the same day. It is the site-blocking machinery that has been circulating in Washington since Zoe Lofgren's Foreign Anti-Digital Piracy Act in January 2025, with one addition the draft Issa circulated to stakeholders in May 2025 did not contain. Section 1601(6)(B) defines a "service provider" to include "providers of broadband internet access services, providers of domain name resolution services, and virtual private networks." VPNs are in the operative text, not implied.

Earlier this month we looked at Utah's SB 73, which deems anyone physically in Utah to be a Utah user whatever their IP address says. That law puts the burden on websites. This one puts it on the network in between, the VPN included, and at federal scale.

The duty itself sits in section 1604(d)(3). A blocking order "requires each named service provider to take all commercially reasonable steps to prevent users or subscribers from using its systems or networks to access the foreign piracy site from the United States." Read that last clause twice. The bill never says how a VPN, a product built to disconnect a user from their location, is supposed to know when a session is from the United States. Section 1604(f)(2) then bars the judge from helping: except as the chapter expressly provides, the order "may not prescribe, recommend, or require specific methods, techniques, equipment, or other specific technical measures or actions to implement the order."

Internet Protocol addresses appear twice in the bill, in 1601(5)(C) and 1604(e)(3)(B), both times as a way of identifying the piracy site. They are never used to identify the user. That gap is the whole story.

What the bill requires, and on what clock

The procedure has two steps. A copyright owner first asks a district court to declare a "foreign online location" a foreign piracy site under section 1602(b), on a preponderance of the evidence. Foreign is defined in 1601(5)(B) as operated by someone outside the United States "or the location of which cannot be determined to be within the United States following a reasonable investigation," so an operator who cannot be traced after a reasonable investigation counts as foreign. With the declaration in hand, the owner petitions for a blocking order naming specific providers.

Named providers get "not less than 14 days after the filing of the petition" to appear and respond, under 1604(c). Unless a provider consents, the court names it only after weighing the six factors in 1604(f)(1)(B)(ii): the burden on the provider, "technical feasibility and efficacy," the harm to the copyright owner, the potential for incidental harm, whether including the provider is likely to impede US access to the site, and any benefit or harm to the public. Once ordered, implementation is due "not less than 14 days and no more than 30 days" after notice. Section 1608(a) lets the court modify any deadline for good cause, "including to address time-sensitive events," which 1601(7) defines as a work first made public at the same time as, or no more than 24 hours after, its first authorized US performance or distribution. The operator or user of an unrelated service blocked in error can be awarded up to $250,000 from the copyright owner under 1606(f)(6) if it shows the owner caused the error, and a provider acting in good faith is shielded from liability by 1610(a).

Action for declaration §1602(a)-(b) preponderance standard Declared a foreign piracy site untraceable operator is foreign, §1601(5) Petition for blocking order names ISPs, resolvers and VPNs, §1604 ≥ 14 days to respond §1604(c); court weighs feasibility, §1604(f) 14 to 30 days to implement §1604(d); method not prescribed Time-sensitive event, §1601(7), §1608(a) at or ≤ 24 h after US release: court may shorten both What the order says: prevent access "from the United States." What it does not say: how a provider determines that a user is there. The court is barred from filling the gap, §1604(f)(2).
The H.R. 10364 procedure. Everything is specified except the one test a VPN would actually have to run.

Issa chairs the Judiciary subcommittee that handles intellectual property and retires at the end of this year, and TorrentFreak notes he "won't be around to reintroduce it if it doesn't pass during the current session." Public Knowledge shared the text with Ars Technica before Congress.gov published it, and its senior policy counsel Meredith Rose said in a statement that "Congress and its entertainment industry allies have decided to build out a sweeping infrastructure for censorship." Nobody we have read on either side has said out loud that the VPN provision is, underneath, a geolocation mandate.

Three ways to read "from the United States"

A VPN session touches three places where a provider could apply the test, and they give different answers for the same person.

Single-hop VPN: entry and exit are the same server, which sees both the client IP and the destination. Multi-hop designs are the ones that split them. Laptop in Denver Comcast, AS7922 consumer address, US tunnel VPN entry node sees the client IP not the destination VPN exit node New York or Frankfurt sees the destination Piracy site foreign under the §1602(b) declaration Reading 2: exit location blocklist on US exits only nothing needed from the client escaped by picking Toronto Reading 3: account country billing address, store region not a network signal no billing country: free tiers Reading 1: entry client IP geolocate every handshake apply blocklist if US needs country + anonymizer check Same Denver user: blocked under reading 1 whatever the exit, unblocked under reading 2 on a Toronto exit.
Three places to apply "from the United States," each observing different evidence. Only the first one asks where the user is.

The first reading is the client address at the tunnel entry. When a laptop in Denver opens a WireGuard session to a server in Frankfurt, the provider's edge sees the laptop's public IP, a Comcast address in AS7922. Geolocate it to US and apply the blocklist to that session, whatever exit the user chose. This is the reading closest to the statute's words, since the user is unmistakably in the United States, and it is also the one that asks the most of IP data: a country-level lookup on every inbound handshake, plus enough sense to notice when the inbound address is itself an anonymizer. Country is the layer geolocation gets right, because RIR delegations, BGP origin and geofeeds under RFC 8805 usually agree on it. The problem is not accuracy. It is that the providers say they do not look. After the first Paris order, a NordVPN spokesperson told TechRadar that "a solution to identify customers in French territories while preserving the services' privacy obligations does not exist at the time of writing." Reading one requires them to build one.

The second reading is the exit. Apply the blocklist on US-located exit servers and leave the rest alone. It is the cheapest thing to build and needs nothing from the client, and it fails the statute in both directions. The same Denver user picks a Toronto exit and is unblocked. A user in Munich who picks a New York exit, perhaps to reach a US streaming catalogue they pay for, is blocked under a US court order that was never about them. There is a subtler flaw too. Exit location is a claim the VPN makes about its own addresses, and several providers sell "virtual" locations where the server sits in one country and presents an address from another. The provider's geofeed usually matches the flag in the app, so a database that takes the geofeed at its word agrees with it. Only latency and routing evidence can show where a virtual exit is actually racked.

The third reading is the account: billing country, app store region, the address on the card. It has the merit of being the most obvious number a provider could use to decide whether it clears the bill's 100,000-user threshold, and the flaw that it is not a network signal at all. Gift cards, cryptocurrency and free tiers leave the billing country blank, and a US account roaming in Lisbon would be blocked in Portugal.

Our view is that only the first reading even attempts what section 1604(d)(3) says, and it is the one the VPN industry has spent a decade telling its customers it will not do. The Paris Judicial Court has already shown how much patience courts have for that argument. When Proton argued in January 2026 that a block could not be technically confined to France and would amount to a global blockade, the court answered that "no quantifiable and verifiable technical evidence corroborates the technical difficulties of implementation cited by the defense." Unless a VPN consents, a US court must find that the factors, "technical feasibility and efficacy" among them, weigh in favor of naming it, but 1604(f)(2) stops it from saying how to achieve it, so a provider contesting feasibility would be wise to bring the evidence the Paris court found missing, and if it is named anyway, choose and build the method itself.

The 100,000 threshold is a geolocation count too

Section 1601(6)(C)(i) carves out any entity with "fewer than 100,000 monthly users or subscribers in the United States." A provider has to count its users in the United States before it can know whether the statute applies to it, and the count has to run on one of the three readings above.

Pick the account reading and a free tier with no payment on file, Proton's or Windscribe's, has no billing country, and only an app store region for mobile installs. Pick the entry-IP reading and the count depends on what you do with addresses. A carrier-grade NAT gateway puts dozens to hundreds of handsets behind one IPv4 address, thousands on the most congested networks, while one iPhone on IPv6 cycles through privacy addresses daily, so counting distinct source addresses on a mixed subscriber base can land on either side of the threshold depending on the address family mix. The bill does not say whether "users" means people, devices, addresses or paying accounts.

For a number that decides who is regulated, that is not a small omission.

ISPs and resolvers already do this abroad, and they can see something a VPN cannot

Intermediary blocking is routine outside the United States. Since 2017 the English High Court has granted the Premier League "live" blocking orders under section 97A of the Copyright, Designs and Patents Act against BT, EE, Plusnet, Sky, TalkTalk and Virgin Media, blocking specific server addresses during match windows. Italy's Piracy Shield, running since February 2024, demands blocks within 30 minutes, and when AGCOM's order 49/25/CONS told Cloudflare in February 2025 to block listed domains and addresses on its 1.1.1.1 resolver, Cloudflare refused and was fined 14.2 million euros in January 2026, a fine an administrative court upheld in July. In Spain, a Córdoba commercial court ordered NordVPN and Proton VPN in February 2026 to block LaLiga streams. India's Delhi High Court issues "dynamic+" injunctions that cover mirrors that do not exist yet, most recently for JioStar's IPL 2026 coverage in March, with ISPs given as little as 36 hours to act.

France is the one that matters here, because it has gone furthest down the stack, season after season. The Paris Judicial Court applied article L. 333-10 of the Code du sport first to ISPs, then to the public resolvers of Google, Cloudflare and Cisco (all three lost on appeal, and Cisco withdrew OpenDNS from France rather than filter), and on May 15, 2025 to VPNs. That first order gave NordVPN, CyberGhost, Surfshark, ExpressVPN and Proton three days from notification to block 203 domains. Further orders followed, among them July 18 and December 18, 2025 and January 28 and 29, 2026, and on July 17, 2026 the court signed fourteen orders covering 73 domains for the new season, naming Proton, CyberGhost and ExpressVPN alongside Google, Cloudflare, Quad9 and DNS4EU on the resolver side. Domains get added through the season once ARCOM has approved them.

Intermediary What it observes How it knows the user is in the country Precedent
ISP Every packet on a subscriber line, source and destination By construction on a fixed line: it sold the line at a street address UK s.97A live orders; Italy Piracy Shield; France under L. 333-10 of the Code du sport
Public DNS resolver Query name and the source address of the query, often a CGNAT pool or forwarder Geolocation of the query source; nothing at all behind an oblivious proxy France: Google, Cloudflare, Cisco ordered, appeals rejected; Italy: Cloudflare fined 14.2 million euros
VPN Entry sees the client address; exit sees the destination; single-hop servers see both Only by geolocating the client at entry, which most providers say they do not do France: five providers ordered from May 15, 2025, three named again for 2026-27; Spain: NordVPN and Proton for LaLiga; US: H.R. 10364 as introduced

A fixed-line ISP does not need geolocation. It sold a subscriber a line at an address in the United States, and every packet on that line is from the United States by construction. Mobile carriers are the exception, because a roaming subscriber's traffic comes home through the carrier's own gateway, as the next section shows. A resolver is one step removed: it sees the source of the query, which is the subscriber's address or their ISP's CGNAT pool, and a country lookup on that source is the only tool it has to scope a block to one jurisdiction. Cloudflare's stated position is that a block on a global resolver is a global block, which is why its transparency report says it has pursued legal remedies, or found alternate ways to comply, rather than block through 1.1.1.1. A VPN is the only one of the three whose product is defined as separating the two ends. It can see the client, on the entry server, but its commercial promise is that it does not look.

Where the test breaks for ordinary users

Suppose a provider builds reading one properly: country-level lookup at entry, anonymizer check, blocklist applied to the session when the client resolves to US. Here is where it holds and where it breaks.

Roaming is the big one. Roaming data is home-routed by default, and we wrote a few days ago about the AeroSims catalogue in which 386 of 392 travel eSIM plans exit the internet in a country other than the one they are sold for, and about a test in the United States in which 10 of 25 eSIM profiles came up in another country entirely. A tourist in Chicago on one of those ten reaches the VPN entry from an address in Hong Kong, England, Poland or Singapore and is not "from the United States" under reading one. An American in Tokyo on a US-issued SIM home-routes through a US gateway and is. Reading one, applied faithfully, blocks the person in Tokyo and waves the person in Chicago through, the reverse of what the statute asks.

Carrier-grade NAT is a smaller problem than it looks at this granularity. The 179 to 207 km median error a recent study measured on mobile networks is a city-level problem; the same study put fewer than 1 percent of observations in the wrong country, so a country test on a domestic mobile user mostly holds. It fails at the count, not the block, since one gateway address stands in for many handsets.

iCloud Private Relay is the case the bill's drafters almost certainly did not think about, and it splits the intermediaries. It never touches a VPN: when a VPN is active, its tunnel takes precedence and the entry server sees the user's real address. For the web traffic it does carry, Apple keeps the relay egress inside the user's country and publishes the ranges with a country, region and city attached, so a Private Relay user reaching a site from a US relay address is correctly in the United States. The DNS side is different. Private Relay sends DNS through Oblivious DoH to resolvers Apple chooses, so a resolver named in an order either never sees the query or sees it with only a relay address behind it, and has nothing to geolocate. The ISP is in the same position: it sees only the connection to Apple's ingress relay, not the site behind it. Tor is the opposite case: a US exit run by a volunteer with no idea who is behind it, which is why Tor exit flags belong in any entry-side check, not so the user can be placed, but so the provider knows it cannot place them.

Situation Person is in Entry node sees Reading 1 result Tourist in Chicago on a travel eSIM home-routed, exits at the sponsor's gateway United States abroad (HK, PL, SG) not blocked (wrong) American in Tokyo on a US-issued SIM home-routed through a US gateway Japan United States blocked (wrong) Handset behind carrier-grade NAT in Ohio one gateway address, many users United States United States blocked; count is off iCloud Private Relay user in Seattle VPN tunnel takes precedence over the relay United States US (home ISP) blocked (right) Client via a Tor exit in Virginia volunteer relay, no client address behind it unknown United States blocked; Tor flag set The two roaming rows are the ones where a faithful implementation of section 1604(d)(3) gets the person wrong.
Five ordinary users under the entry-IP reading. Geolocation is right about the address in every row; the roaming rows are wrong about the person.

Entry and exit in IP data

Here is what a commercial VPN exit in New York looks like in an IP record. The address is on a hosting network, in this case M247 (AS9009), and the anonymizer fields say what the address is for:

{
  "connection": {
    "asn":  9009,
    "type": "hosting"
  },
  "location": {
    "country": { "code": "US" },
    "region":  { "code": "US-NY", "name": "New York" }
  },
  "security": {
    "is_proxy":             false,
    "is_relay":             false,
    "is_residential_proxy": false,
    "is_tor":               false,
    "is_vpn":               true
  }
}

A record like this tells a website that the address is infrastructure and says nothing about where the person behind it is. It is the view from outside the tunnel. A VPN implementing reading one needs the view from inside: a country lookup on the connecting client, with the same anonymizer fields checked on that side, so that a Denver cable modem is scored as "from the United States" and another provider's exit or a residential proxy that happens to resolve there is flagged as unplaceable. The bill leaves open whether drawing that distinction is a commercially reasonable step. It will be argued twice: on feasibility when named providers contest their inclusion under 1604(c) and (f)(1), and on compliance if a copyright owner moves for contempt under 1605. On feasibility, the VPNs named in the French orders have already lost repeatedly.

Ipregistry publishes both halves of that view: country and region for every address, connection type and ASN, and separate VPN, proxy, residential proxy, Tor and relay flags, so a website can tell a Private Relay user from a residential proxy exit, and a VPN entry can tell a home connection from another anonymizer. You can check how your own inbound traffic would score under each reading with 20,000 free lookups to get started.

Engage customers with in-app updates using Noticeable Keep users in the loop Ship release notes that get read. Try Noticeable

Get started with 20,000 free lookups: sign up