Skip to content

Logged Out Is Doing All the Work: The Distinction That Decides Your Scraping Exposure

Every load-bearing step in the Bright Data ruling depends on nobody being logged in. What that means for your contract risk, and for your architecture.

9 min read · 20 Aug 2026

Almost everything that separates a defensible scraping setup from an indefensible one comes down to a single question: was anyone signed in?

That sounds too simple to carry the weight. It carries it anyway. Read the decisions in what the scraping cases actually held and the pattern is hard to miss — the scraper who stayed logged out walked away paying nothing, and the two who had accounts lost the contract claim, one of them for $500,000. It is also the one variable you fully control, which is more than can be said for anything else in this area.

This post is about what that distinction rests on, what adopting it costs you in coverage, and where it stops helping.

This is not legal advice. It is a developer's reading of published decisions. Whether any of it applies to you depends on your jurisdiction, your terms, and what your system actually does. Talk to a lawyer about your situation.

Three separate mechanisms, all hinging on the same fact

1. Whether a contract exists at all. When you create an account you click through terms — a "clickwrap" agreement, and courts enforce those routinely. A visitor who never signs in is at most subject to "browsewrap": terms linked at the bottom of a page they never opened. US courts are markedly less willing to enforce browsewrap; in Nguyen v. Barnes & Noble Inc., 763 F.3d 1171 (9th Cir. 2014), a conspicuous link to terms was not enough to bind a user with no actual notice.

This is where Meta Platforms, Inc. v. Bright Data Ltd. (N.D. Cal., 23 January 2024) was decided. Meta's terms govern "your use" of the products. Judge Chen read that as binding people while they use the service as users. Bright Data did hold Facebook and Instagram accounts, and the court found them incidental and unrelated to the logged-off scraping. Meta's survival clause, which purported to bar scraping in perpetuity even after an account closed, was not read to reach logged-off conduct. Meta dropped its remaining claim a month later and waived appeal.

Run the same facts with an authenticated session and each of those steps inverts. "Your use" would cover it. The accounts would not be incidental. Meta would probably have won.

2. Whether access is "authorised." The CFAA is about gates. In Van Buren v. United States, 593 U.S. 374 (2021), the Supreme Court described liability as a gates-up-or-down inquiry, and the Ninth Circuit applied that in hiQ to hold the statute simply does not fit pages any browser can load. A login is a gate. That is why Ryanair v. Booking.com — where fares were obtained through the password-protected myRyanair area — got to a jury on a CFAA theory at all, while public-page cases keep getting dismissed. (The Ryanair verdict was later set aside on the damages threshold and is on appeal, but the point stands: the login is what put the claim in play.)

3. What the data-protection analysis looks like. Logging in usually reveals more about people than logging out does: contact details, full comment threads, follower lists, content a person restricted to signed-in viewers. Under GDPR the balancing test for legitimate interest turns heavily on the reasonable expectations of the people in the data, and "they chose to show this only to logged-in users, and you took it anyway" is a bad fact in that assessment. This is a separate question from contract and from the CFAA, and it does not go away just because you stayed logged out — it has its own post — but authenticated collection makes every part of it harder.

The four postures, compared

Posture Contract exposure CFAA-type exposure Data-protection posture What happens in practice
Public page, logged out Weak — browsewrap, and "your use" arguments have failed Weak in the Ninth Circuit after hiQ Still fully in scope; only the balancing gets easier Rate limits and IP blocks
Logged in, your own account Strong — you clicked through and agreed Live question; a gate exists Access to restricted data cuts against you Account suspension, then contract claims
Fake or purchased accounts Strong, plus fraud-shaped facts Strongest; and the fact pattern courts dislike most Worst case This is what gets litigated
Official / sanctioned API Governed by the API terms you accepted None, by definition Best — often published by regulatory mandate Token revocation

The bottom row deserves more attention than it gets. Where a platform is legally required to publish data — ad transparency archives under the EU's Digital Services Act are the clearest example — you get an official, documented, sanctioned interface to data the platform cannot withdraw. There is no defence to work around, nothing that breaks on a frontend deploy, and no argument about authorisation. That is why ad-library scrapers keep breaking while the official API keeps working and why we treat that category as the lowest-risk data in this business.

"Public" is not one thing

A URL is not public or private; a view is. The same profile page returns different data depending on who is asking, and the delta is exactly where the risk lives.

Worth knowing before you write any code:

  • Some platforms show almost nothing logged out. Instagram's public surface degrades hard for anonymous traffic, and a large fraction of what people mean by "Instagram data" is only visible to a signed-in session.
  • Some platforms have a genuinely open public surface. YouTube's is the most open of the major platforms, which is why it needs no residential proxies and costs close to nothing to read at volume.
  • Some have a narrow public path that survives. A single public tweet is reachable through the syndication endpoints that render embeds; profiles and timelines are much harder. What still returns public tweets, tested has the current picture.
  • A "public" page behind a dismissible interstitial is still an argument. If you have to get past something to reach it, someone will eventually characterise that as circumventing an access control.

The design consequence: decide what your product needs before you decide your posture, because the honest version of the logged-out rule is that it will make some products impossible.

What the posture costs — ours, specifically

We collect public data logged out, hold no platform accounts, use no credentials or session cookies, and do not get past login walls. Probed on 2026-08-20, here is what that buys and what it does not:

  • Fully working, unproxied: YouTube channel, video, channel videos, search and transcripts. Five endpoints, no proxy, marginal cost near zero.
  • Working, unproxied: a single public tweet, via the syndication path.
  • Rate-limited from datacenter IPs: Twitter profile and user timeline, Instagram profile and user posts. These need residential proxies to be usable at all.
  • Untested because we cannot reach it yet: the Instagram single-post endpoint.
  • Official API, not scraping: the Meta Ad Library endpoints, which use Meta's Graph API and are currently blocked on an access token rather than on any defence.

That is four platforms and fifteen endpoints, and the shape of the list is the point. The logged-out constraint does not distribute evenly — it costs almost nothing on YouTube and a great deal on Instagram. Anyone who tells you their logged-out coverage is uniform across platforms is describing a different architecture than the one they run.

The rules that follow if you adopt it

Once "logged out" is a commitment rather than a default, it turns into a short list of engineering constraints:

  1. No accounts on the platforms you read. Including dormant ones, including ones the marketing team opened, including a company page. Bright Data's accounts were found incidental — do not plan on being that lucky.
  2. No credentials, cookie jars, or session tokens in the fetch path. If your code has a place to put a cookie, someone will eventually put one there. Ours sends exactly one cookie header anywhere: a static CONSENT=YES+cb; SOCS=CAI string to YouTube, which carries no session and identifies nobody. If you are going to claim a posture, that is the level of detail at which you should be able to defend it.
  3. No buying or renting accounts, and no crowd workers creating profiles. That fact is what sank hiQ on the contract claim.
  4. No getting past login walls or bot challenges. Solving a challenge that exists to stop you is the conduct at the centre of the newest claims.
  5. Honour throttles and blocks as answers, not obstacles. How that ladder escalates is worth knowing in advance.
  6. Prefer the sanctioned interface wherever one exists, even when scraping would be faster to build.
  7. Write the posture down where your customers and your own engineers can read it. A posture nobody can state is one you will drift out of in a sprint.

Where logged-out does not save you

Being honest about the limits is the only way the rest of this is worth anything.

  • GDPR does not care. Public, logged-out personal data is still personal data, still needs a lawful basis, and still carries minimisation, transparency and deletion obligations.
  • Copyright and derived works are a separate question. How you store, republish or train on what you collect raises issues that reading it does not.
  • Circumvention theories bypass the whole debate. Reddit's 2025 case against Perplexity and three collection intermediaries is pleaded under the DMCA's anti-circumvention provision rather than the CFAA. Motions to dismiss were argued on 30 June 2026, with no ruling as of August 2026. If claims like that succeed, the question stops being "was this page public" and becomes "what did you get past."
  • Non-US law differs. The EU's sui generis database right and the CJEU's position that contractual restrictions may bind users of unprotected databases (Ryanair v PR Aviation, C-30/14) both cut against the American intuition that public means unrestricted.
  • One district judge read one company's terms. Meta v. Bright Data is persuasive, not universal. A platform that rewrites "your use" to say "any access, by anyone, at any time" is writing directly at that opinion, and some already have.

Logged out is the most defensible posture available, and it is not a safe harbour. It is the difference between a hard argument and an easy loss, which in this area is the largest difference on offer.

Everything described here runs on the same API. You are never charged for a failed request, an empty result, or a cache hit.