--- title: "The Architecture of Consent: Why Bright Data's Network Cannot Be Used the Way Critics Claim" slug: why-bright-datas-network-cannot-be-used-the-way-critics-claim date: 2026-08-27T13:46:19+00:00 modified: 2026-08-27T13:46:20+00:00 permalink: https://brightdata.com/blog/general/why-bright-datas-network-cannot-be-used-the-way-critics-claim type: blog --- [ Blog ](https://brightdata.com/blog "Blog") / [General](https://brightdata.com/blog/general) [General](https://brightdata.com/blog/general) # The Architecture of Consent: Why Bright Data’s Network Cannot Be Used the Way Critics Claim A technical explainer by Efim Dimenstein, Chief Technology Officer, Bright Data. 6 min read [ ](https://brightdata.com/blog/authors/efim-dimenstein) [Efim Dimenstein ](https://brightdata.com/blog/authors/efim-dimenstein) ![The Architecture of Consent_ Why Bright Data's Network Cannot Be Used the Way Critics Claim](https://media.brightdata.com/2026/08/The-Architecture-of-Consent_-Why-Bright-Datas-Network-Cannot-Be-Used-the-Way-Critics-Claim.png) *This document addresses specific technical claims made about Bright Data’s network in recent security research and reporting. It is written for security researchers, engineers, journalists, and anyone evaluating these claims on technical merit. Where a claim is accurate, we say so. Where a claim confuses correlation with causation, or conflates impersonation with participation, we explain the actual mechanism and why the conclusion doesn’t hold.* ## On “Distributed Proxy” Framing Critics have described Hola’s peer-to-peer design as something that “shifts the risk profile from that of a traditional VPN to something closer to a distributed proxy,” implying that peers connect to or through each other. They don’t. Hola does not operate peer-to-peer. It operates [peer-server-peer](/solutions/p2p-proxies). Every request is routed through Bright Data’s servers. No peer ever connects directly to another peer’s device, and no peer ever has visibility into another user’s system, files, traffic, or information. This distinction is not semantic, it’s architectural, and it’s what makes the rest of this answer possible. Because all traffic terminates at our infrastructure before being routed onward, we can enforce controls at that checkpoint that a true peer-to-peer system could never enforce: Only whitelisted domains are reachable. Backend servers maintain [domain and IP blacklists](/trustcenter/data-security-overview-protection-measures). A peer device cannot be used to reach a site that isn’t pre-approved, regardless of what a customer requests. Only HTTP/HTTPS traffic is permitted. Every other port is blocked at the protocol level. This alone rules out most exploitation techniques a “distributed proxy” framing implies — no arbitrary TCP, no SSH tunneling, no raw socket access. Rate limiting is enforced to prevent brute-force or credential-stuffing patterns from ever using peer infrastructure as a vector. A distributed proxy, in the threat-modeling sense, implies attacker-controlled routing to attacker-chosen destinations. Because of the whitelist controls, our architecture doesn’t allow attacker-chosen destinations. ## On the “Lateral Movement” Claim Critics have also suggested that Hola’s presence on a device “may provide a foothold for malicious behavior, including lateral movement.” Lateral movement requires reaching local or private network addresses, router admin panels, NAS devices, printers, other machines on the same subnet. Here is why that path is closed, at every layer: Plain IP requests are disallowed outright, which removes the simplest vector for targeting a local network directly. Backend servers maintain IPv4 and IPv6 blacklists covering all private and local ranges (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, and equivalents), applied *after* DNS resolution, meaning a request can’t sneak past the filter by resolving a public-looking hostname to a private address. The SDK layer independently enforces the same blacklist. This isn’t a single point of failure, the check happens twice, in two different places, so a bypass of one layer doesn’t bypass the other. Platform-native enforcement is layered on top. On Android, for example, platform-level system functions independently ban local/private IP targeting, which means the restriction doesn’t rely solely on our own code behaving correctly, the operating system itself is part of the control. This is redundant, independently-enforced technical filtering at the network, SDK, and OS level. This is also precisely the design point independently validated by Spur Intelligence Labs, whose testing found Bright Data’s proxy layer to be immune to lateral-network-access vulnerabilities that affected other providers tested, specifically because most competitors do not implement this multi-layer, defense-in-depth blocking. A bad actor cannot use a peer device to reach that device’s home network, because the request never reaches the resolution or routing stage required to do so. It is blocked before DNS, blocked after DNS, blocked at the SDK, and blocked at the OS. To put it plainly: a customer cannot use Bright Data’s network to access someone’s home router, printer, or local devices. Local and private IP ranges are blocked before DNS resolution, after DNS resolution, at the SDK layer, and at the OS layer, independently and redundantly, so no single failure opens that door. ## On Spoofed Identity and the Limits of a User-Agent String A separate but related confusion runs through much of this reporting: the assumption that traffic identifying itself as Hola or Bright Data must have originated from Hola or Bright Data software. It doesn’t work that way. Malware can disguise itself as Hola or Bright Data traffic just as easily as it can disguise itself as a browser or an operating system, any piece of software can spoof a User-Agent string. This is a property of how HTTP works, not evidence of the impersonated product’s design or intent. Attackers borrow the identifying markers of familiar, trusted software precisely because those markers are unauthenticated and trivially rewritable, the presence of a familiar label in malicious traffic says something about the attacker’s tradecraft, not about the software being impersonated. ## The Actual Line Between a Responsible Network and a Malicious One It’s worth stating plainly what separates a responsible, consented network from an unconsented, malicious one because the technology itself is neutral. What differs is verifiable and testable, across four dimensions: sourcing, vetting, governance, and accountability. What actually stops abuse on a responsible network isn’t a line in a legal disclaimer it’s the combination of controls already described here, working together: domain whitelisting, protocol restriction to HTTP/HTTPS, rate limiting, multi-layer private-IP blocking, customer KYC vetting, and independent third-party audits. All of it is independently verifiable, and none of it is present on unconsented, malicious networks. A responsible network’s every IP originates from a peer who saw a standalone consent screen, understood what was being asked, and can exit at any time in a couple of steps. A malicious network’s devices are recruited without the owner’s knowledge, through compromise, not consent. This is testable: pull the actual opt-in flow and read it. A responsible network vets every customer before granting access identity verification, use-case review, ongoing compliance monitoring and rejects applicants that don’t meet a documented standard. A malicious network sells access to anyone, anonymously, with no review. This is testable by attempting to acquire access and observing what’s required. A responsible network detects, blocks, and attributes abuse as it happens, and responds to external abuse reports on a defined timeline. A malicious network has no abuse-reporting channel because it has no interest in being found. This is testable: file an abuse report and measure the response. A responsible network submits to independent, outside audits and publishes the results PwC, ISO 27001/27017/27018, SOC 2 Type II, AppEsteem certification, third-party security research from firms like Spur. A malicious network publishes nothing, because there is nothing it wants examined. This is testable: the audits are public. For further technical detail, see [Bright Data Trust Center ](/trustcenter)[PwC audit report ](/trustcenter/pwc-report)[Bright SDK User FAQ ](https://bright-sdk.com/users) We invite security researchers to test our SDK and network. If you find any security issues, please report them to us through our [Bright Data Security Vulnerabilities Reward Program](/security-vulnerabilities-reward-program). Contact usStart free trial No credit card required [ ](https://il.linkedin.com/in/efimd) Efim Dimenstein Efim Dimenstein, CTO of Bright Data, leads engineering and architecture with a focus on scalable infrastructure and platform innovation. [ View all articles ](https://brightdata.com/blog/authors/efim-dimenstein) Table of Contents [ ](https://news.ycombinator.com/submitlink?t=The+Architecture+of+Consent%3A+Why+Bright+Data%26%238217%3Bs+Network+Cannot+Be+Used+the+Way+Critics+Claim&u=https://brightdata.com/blog/general/why-bright-datas-network-cannot-be-used-the-way-critics-claim) [ ](https://www.linkedin.com/shareArticle?mini=true&title=The+Architecture+of+Consent%3A+Why+Bright+Data%26%238217%3Bs+Network+Cannot+Be+Used+the+Way+Critics+Claim&url=https://brightdata.com/blog/general/why-bright-datas-network-cannot-be-used-the-way-critics-claim) [ ](http://www.reddit.com/submit?title=The+Architecture+of+Consent%3A+Why+Bright+Data%26%238217%3Bs+Network+Cannot+Be+Used+the+Way+Critics+Claim&url=https://brightdata.com/blog/general/why-bright-datas-network-cannot-be-used-the-way-critics-claim) ## You might also be interested in [ ](https://brightdata.com/blog/ai/openhuman-with-bright-data "Production-Ready Web Access in OpenHuman Through the Bright Data CLI") [AI Antonello Zanini Technical Writer ### Production-Ready Web Access in OpenHuman Through the Bright Data CLI Integrate Bright Data CLI with OpenHuman to enable production-ready web access and data collection for AI agents. 09-Sep-2026 12 min read ](https://brightdata.com/blog/ai/openhuman-with-bright-data) [ ](https://brightdata.com/blog/ai/minimax-m3-with-bright-data "Giving self-hosted MiniMax M3 agents live web access with Bright Data") [AI Satyam Tripathi Technical Writer ### Giving self-hosted MiniMax M3 agents live web access with Bright Data Self-hosted MiniMax M3 agents get live web access using Bright Data’s search and scraping tools. Bypass blocks and CAPTCHAs. 09-Sep-2026 54 min read ](https://brightdata.com/blog/ai/minimax-m3-with-bright-data) [ ](https://brightdata.com/blog/web-data/multimodal-web-scraping-with-minimax "Multimodal Web Scraping with MiniMax") [Web Data Antonello Zanini Technical Writer ### Multimodal Web Scraping with MiniMax Pair Bright Data Web Unlocker with MiniMax M3 vision to extract structured data from images and web page screenshots. 09-Sep-2026 4 min read ](https://brightdata.com/blog/web-data/multimodal-web-scraping-with-minimax)