> Thank you to Bruno Lulinski, COO of Pluto, and the rest of the Pluto team for their thoughtful feedback and conversation on this article.

Congratulations!  After months of searching for your dream apartment, you finally found the one.  It’s a cute one-bedroom in the Upper East Side.  Is it a good deal?  Well, no, we already told you it’s in Manhattan.  But it has in-unit laundry and a decent view of the city from your weirdly narrow kitchen window, so you’re going to fight like hell to get it.

You tell the landlord you’d like to apply to get the apartment.  This man, who still has a Hotmail email address and to this point has ignored every single question you’ve asked about the apartment not related to rent, responds, letting you know that it will be “competitive” but to start, you should fill out a form and provide a credit report.  No promises, but he’ll do his best to consider you.

You open the form and are immediately uneasy about the number of personal questions being asked of you.  Provide your social security number.  Provide your date of birth.  List every apartment you’ve ever lived in.  List every job and every supervisor at that job.  Do you own fish?  

Overwhelmed, you scroll to the bottom to see how long this goes on.  You see in small font at the end that you consent to your landlord sharing all of this information with a credit bureau to run a credit check.  All of this makes you uncomfortable—you’re sharing deeply sensitive information to a Hotmail email address to a man you’ve never met so he can share it with a man he’s never met to run a credit check on you?  You start thinking about how many people will apply for this apartment—after all, it’s “competitive”—and the pain of hustling on New York streets for three more weeks to find a place.  You just don’t have the time, so you capitulate, fill out the form, and hope for the best.

There are many broken steps in this flow, but let’s focus on one that feels particularly unnecessary and egregious:  you share personal information with an intermediary (your landlord) for him to simply share it with another party (the credit bureau).  Why does this step exist?  Why can’t you just go to the credit bureau directly and share the results with him?  Well, because your landlord doesn’t trust you; he wants independent verification from the bureau.  The credit bureau may have an authenticated way to share that information, but unlike the free credit report you could get, it will cost you, and your landlord will have to set up an account.  Even if your landlord were to get the information directly from the credit bureau, there’s another problem: information leakage.  For example, your landlord only needs to know if your credit score passes a certain threshold, not precisely what number it is (and whatever other details would be leaked in the report).

Is there a better way to do this?  Yes, using cryptography, specifically, zero-knowledge proofs (ZKP).  The best way to understand how ZKPs work is through an example.  Imagine the following alternative flow.  Your landlord tells you that you must provide an authenticated credit report to apply for the apartment.  Rather than give your landlord sensitive information like your full social security number, you go to Experian.com and get the credit report yourself.  A Chrome Extension you’ve previously installed asks you if you’d like to generate a certificate of the information you see on the page and what information you specifically want to share.  You select that you want a certificate of whether your credit score is 740 or higher without revealing exactly what number your credit score is or other information you provided to Experian.  The Chrome Extension generates this certificate and allows you to click one button to email it to your landlord (there may be other minimum information you need to share with your landlord to demonstrate you are who you say you are).  Your landlord can then verify that certificate on a website of his choice and, with certainty, know that the information was generated by Experian on that specific date for that particular user.

This flow is not hypothetical; the technology underlying what we’ve just described, called zkTLS, is here, right now, and companies like Pluto are beginning to make it available to customers.  The certificate you generate is a ZKP, and it piggybacks off of something called the TLS (transport layer security) protocol that already underpins your web browsing experience to guarantee the information you’re proving (e.g., that your credit score is 740 or higher) came from a specific website’s servers (e.g., Experian) and has not been tampered with.  TLS is that little thing in your browser that gives it the “lock” or secured icon, the “s” in “https.”

Think about this seamlessness and interoperability browser extensions and zkTLS can create far beyond the invasive process of applying for an apartment.  The combination of zkTLS and a browser extension would mean you could share information from any particular website with any other particular website (or person) without revealing sensitive information you don’t want to share.  It would allow you to unchain your data currently siloed within thousands of segregated servers to make it useful outside the specific application it was designed for.

If you’re a reader of this blog and coming from Web3, your spidey senses are probably tingling at this point.  Unchaining data?  Dan and Cooper, did you read Chris Dixon’s book?  Web2 companies hate unchaining data because selling your data is their business model.  Surely, they’ll not be happy with this?

Indeed, if we return to our apartment example and go to Experian’s terms of service, we see the following:

The term “Service” includes, but is not limited to, the provision of any of our products and services, including credit report(s), credit risk score(s), credit monitoring, credit score monitoring and credit score tracking (including all the data and information contained therein), the receipt of any alerts notifying you of changes to the information contained in your credit report(s), regardless of the manner in which you receive the Services, whether by email or mail, through a website or mobile application, by telephone, or through any other mechanism by which a Service is delivered or provided to you.

Except as expressly contemplated by this Agreement, you shall not . . . distribute, publish, transmit or disseminate, in any form or by any means any part of the Services or Websites . . . use any robot, spider, deep-linking or other process or tool, whether manual or automatic, to access, monitor, retrieve, data mine, reproduce or circumvent any portion of the Services or Websites . . . . [emphasis added]

Let’s look at the terms of service of another platform, X:

You retain ownership and rights to any of your Content you post or share, and you provide us with a broad, royalty-free license to make your Content available to the rest of the world and to let others do the same. Conversely, we provide you a license to use the software we provide as part of the Services, such as the X mobile application, solely for the purpose of enabling you to use and enjoy the benefit of the Services. [emphasis added]

You may not do any of the following while accessing or using the Services: access or search or attempt to access or search the Services by any means (automated or otherwise) other than through our currently available, published interfaces that are provided by us (and only pursuant to the applicable terms and conditions), unless you have been specifically allowed to do so in a separate agreement with us (NOTE: crawling or scraping the Services in any form, for any purpose without our prior written consent is expressly prohibited) . . . . [emphasis added]

In both Experian’s and X’s terms, using automated tools to share data obtained from the websites is purportedly forbidden.  X’s is particularly confusing because it states that “[y]ou retain ownership and rights to any of your Content . . . .”  But you can’t share your data using automated tools?  That sure doesn’t sound like ownership, at least not to us.

So is using a Chrome Extension like we described above permitted on these platforms?  It’s ambiguous.  On the one hand, you’re accessing data through the platform’s interface and only interacting with and sharing data that your eyeballs can already see.  But because you’re using an automated tool or sharing data (that you may “own”) it’s prohibited?  What would be the cause of action the platform could pursue against the Chrome Extension provider to try and stop its users from using it on the platform?

These questions are what prompted this article.  Specifically, while there are many causes of action that a platform could pursue to try and enforce its terms against an extension provider, including breach of contract, privacy-related claims, unfair competition torts, and more, we want to focus on one:  the Computer Fraud and Abuse Act (“CFAA”).  Specifically, our goal in this article is to better understand the viability of a CFAA claim brought by a platform against browser extension providers that empower users to share or utilize their data outside of the defined methods the platform establishes.  To this end, we examined CFAA case law in the most influential court in the country for technology law (the Ninth Circuit).  From our review, we conclude that as long as the browser extension provider does not control the user’s account with the platform (e.g., it does not have the user’s login credentials), a CFAA claim brought by the platform against that provider is unlikely to survive.  We thus devise a “user control” theory to understand the CFAA.  

This article proceeds as follows.  First, we’ll provide some short background on the CFAA and the form CFAA claims by Web2 platforms usually take.  Next, we'll do a deep dive into a 2022 Northern District Court of California case called Meta Platforms v. BrandTotal to define the user control theory and see how it operates.  And finally, we’ll pressure test the user control theory against influential Ninth Circuit precedent to demonstrate that it is a cohesive way to understand the CFAA.

The CFAA is a federal statute passed in 1986 “to prevent intentional intrusion onto someone else’s computer—specifically, computer hacking.”  hiQ Labs, Inc. v. LinkedIn Corp., 31 F.4th 1180, 1196 (9th Cir. 2022).  The CFAA states that “[w]hoever . . . intentionally accesses a computer without authorization or exceeds authorized access . . .  and thereby obtains . . . information from any protected computer . . . shall be” liable.  18 USC § 1030(a)(2)(C).  

While the CFAA was originally passed as a hacking statute, over time, Web2 platforms, especially social media companies, have utilized it heavily as a tool to go after scraping services.  LinkedIn, X, and Facebook have all brought CFAA claims against scraping companies and other providers for extracting data from their platforms.  Intuitively, for a browser extension to read the user’s document, it needs to functionally “scrape” its content, so these “scraping” cases are informative for our inquiry into the CFAA and browser extensions.

The facts surrounding a CFAA claim by a Web2 company usually follow a familiar pattern.  First, the Web2 company will have legal terms with its users that purport to require them to agree not to use automated tools on the company’s website or to otherwise extract information from the website, and the terms also specify that the user owns her data (like X’s we pasted above).  Second, the Web2 company will utilize technical tools to proactively prevent bots or other scraping that can make extraction of information at scale feasible (which can be interpreted as enforcing its legal terms with technical measures), such as CAPTCHAs and other bot detection tools and suspicious IP address blocking.  Third, when the Web2 company becomes aware of a specific scraping instance that it believes is unauthorized, it will embark on a targeted version of the first two items, legal terms, and technical measures aimed at the scraper, such as by sending a cease and desist to the scraper and blocking the scraper’s IP addresses.

Returning to the text of the statute, what does it mean to “access[] a computer without authorization or exceed[] authorized access” in the context of a browser extension?  That is the crux of the question and what liability usually hinges upon.  To answer this question, the core of this article takes a deep dive into a 2022 Northern District Court of California case called Meta Platforms v. BrandTotal and reframes the court’s reasoning under a cohesive legal theory based on control over a user’s account.  There are two reasons we’re focusing on this case:

• First, it is the most relevant case we’ve found to discuss browser extensions and the CFAA because a browser extension is one of the core products at issue in the case.

• Second, the court assessed a variety of products and services with different technical underpinnings as part of the CFAA analysis, which helps us determine a theory for how the technical realities of control dictate the legal analysis.

At the end of this article, we will sanity check our legal theory extracted from BrandTotal against other important precedent, although this article does not purport to have reviewed all applicable CFAA case law.

BrandTotal (which now appears to be defunct, but we’ll describe it in the present tense in this article to match the court) is an analytics company that “provides advertising consulting services to corporate clients regarding how those clients’ and their competitors’ digital advertisements are presented to social media users.”  Meta Platforms, Inc. v. BrandTotal Ltd., 605 F. Supp. 3d 1218, 1232 (N.D. Cal. 2022) [“BrandTotal MSJ”].  “One of its primary methods of collecting that information is incentivizing individual users, whom it refers to as ‘panelists,’ to share data about the advertisements they are served while browsing social networks.”  BrandTotal MSJ at 1232.

BrandTotal offered the following products to users to collect data:

1. UpVoice 2021:  A Chrome extension that passively collected data from a user’s experience on Facebook, including on private pages, and did not have access to user credentials.

2. Restricted Panel Extension (“RPE”):  A browser extension that functioned materially the same way as UpVoice 2021, except it was specifically used by contractors BrandTotal hired to surf and scrape data from private pages of Facebook’s website.

3. UpVoice Pre-2021 and legacy products:  A version of the UpVoice extension from before the 2021 version and other legacy products that had access to user credentials and would actively collect data from Facebook’s servers, including on private pages.

BrandTotal also engaged in the following data collection on its own accord:

1. Public scraping:  BrandTotal directly scraped public pages of Facebook’s website using its employees’ accounts and automatic scraping tools.

2. Private scraping: BrandTotal purchased and created Facebook accounts that it controlled to scrape data directly from the private pages of Facebook’s website.

Facebook’s business is built upon having unilateral control over user data.  While Facebook users “‘own the rights in their own information’” per its terms of service, Facebook, like most Web2 companies, engages in two primary mechanisms to lock down data:  (1) contractual restrictions and (2) technical restrictions.   Facebook, Inc. v. BrandTotal Ltd., 499 F. Supp. 3d 720, 728 (N.D. Cal. 2020) [“BrandTotal TRO”].

In terms of contractual restrictions, as cited by the court, Facebook’s terms included the following:

All users of the Facebook Network agree to contractual terms including that users will not do anything that would “impair the proper working or appearance” of Facebook’s products, will not access or collect data from Facebook’s products “using automated means” without Facebook’s permission, and will not attempt to access data that the particular user lacks permission to access. All Instagram users similarly agree not to do “anything to interfere with or impair the intended operation” of Instagram, not to “collect[ ] information in an automated way without [Facebook’s] express permission,” not to access information “in unauthorized ways,” and not to violate anyone else’s rights, including intellectual property rights. Users of both networks agree not to do anything unlawful, misleading, or fraudulent, or to facilitate such activity.  BrandTotal TRO at 725–26 (internal citations omitted).

In terms of technical restrictions, as cited by the court, Facebook implemented the following controls: 

Facebook employs various measures to prevent “scraping”—bulk automated collection—of content from its products, including monitoring usage patterns, using “CAPTCHA” tests to determine whether users are human as opposed to automated programs, and disabling accounts that violate its rules.  BrandTotal TRO at 726.

And, as specific to BrandTotal, Facebook applied the following legal and technical restrictions:

On September 30, 2020, Facebook disabled BrandTotal’s accounts on Instagram and the Facebook Network and instated other technological measures to block BrandTotal’s access to Facebook’s products. On October 1, 2020, Facebook filed a civil action against BrandTotal in California state court alleging that the browser extensions breached Facebook’s terms of service. Later that day, Google removed the browser extensions from its Chrome Web Store, which disabled their functionality.  BrandTotal TRO at 726.

UpVoice 2021:  User Controlled

UpVoice 2021 was the “primary product at issue” in BrandTotal.  BrandTotal MSJ at 1232.  It is described as a “browser extension that automatically sends data to BrandTotal while a user browses websites like Facebook . . . .”  BrandTotal MSJ at 1232.  In exchange for sharing this information, the user would receive “points that can be redeemed for gift cards . . . .”  BrandTotal MSJ at 1232.  While we will discuss other versions of UpVoice, the latest version discussed in the case was developed in 2021, which we will refer to as “UpVoice 2021”.

As cited by the court, here is how UpVoice 2021 works:

UpVoice 2021 . . .  collects only identifying information for advertisements presented to the user while they are browsing, and does so passively by scanning the HTML code that Facebook serves to the user, without the UpVoice 2021 browser extension actively requesting any further information from Facebook. UpVoice 2021 also prompts users to confirm whether they wish to continue sharing that data when a new user logs into a social media account. Once the identifying information for an advertisement—a unique ID number, as well as the name of the page that sponsored the ad—is transmitted to BrandTotal, BrandTotal’s servers (not the browser extension installed by a panelist) use that information to access the ad on a webpage visible to the general public that does not require logging in with a Facebook username and password, and gather further data about the ad from there.  Facebook, Inc. v. Brandtotal Ltd., No. 20-CV-07182-JCS, 2021 WL 2354751, at *3 (N.D. Cal. June 9, 2021) [emphasis added].

We’ve underlined the passive nature of UpVoice 2021 vis-à-vis Facebook, which makes clear the user is in control of her Facebook account and its interaction with Facebook servers, not BrandTotal.  Indeed, UpVoice 2021 “merely logs information that Facebook transmits to the user about advertisements in the course of the user’s regular interaction with the website . . . .”  BrandTotal MSJ at 1232.  There are no allegations that UpVoice collects user credentials, possesses access tokens, or forces BrandTotal’s direct interactions with the Facebook servers.  Rather, UpVoice 2021 simply piggybacks on a user’s browsing experience and shares information the user sees with BrandTotal.  In the course of browsing Facebook, the user has access to password-protected pages that she is authenticated to see.  Information from these pages is also shared with BrandTotal.

The court held that BrandTotal did not violate the CFAA through UpVoice 2021.  The court reasoned that BrandTotal did not “access” Meta’s computers because the program only used “‘reactive’ data collection, logging and sending to BrandTotal data that users receive from Facebook through their normal use of the website.”  BrandTotal MSJ at 1260.  The court rejected Meta’s argument that because BrandTotal “‘listen[s] to network data being transmitted over the wire’ from Meta’s computers” and “‘pars[es] different elements’ from ‘Facebook’s social feed,’” that this constituted “access” under the CFAA. BrandTotal MSJ at 1260.  Specifically, the court stated:

[T]he evidence that Meta cites only describes UpVoice [2021] accessing and processing the data that Meta has sent to the individual users—incidentally, information that Meta has never argued users are not free to share as they see fit—not proactively “accessing” or “communicating with” Meta’s servers. Meta cites no case extending the CFAA to comparable conduct, and the statute is at most ambiguous as to whether it could encompass BrandTotal analyzing data on users' computers that the users are authorized to access from Facebook. Under the rule of lenity, the Court is required to construe such ambiguity narrowly, and holds that the statute does not encompass UpVoice 2021’s data collection, at least where it is installed by individuals who are not subject to any sort of direction by BrandTotal.  BrandTotal MSJ at 1260–61 [emphasis added].

The court’s analysis here clarifies that the user-controlled nature of the browsing experience, including on private pages only authenticated users could access, meant that a CFAA claim could not be substantiated.  The user was authenticated to access her own data, and merely sharing that data with BrandTotal did not constitute unauthorized access, even if Facebook intended to block BrandTotal from its website.   

UpVoice Pre-2021 and other Legacy Products: Extension Provider Controlled

There was an earlier version of UpVoice, what we’re calling “UpVoice Pre-2021”, which was a browser extension that functioned similarly to UpVoice 2021 but had two key differences:  (1) it “actively” and “automatically” requested data from Facebook’s servers for logged-in users, instead of simply scraping information that the user independently requested and (2) it “collected access tokens” and utilized them in its requests to Facebook’s servers.  BrandTotal MSJ at 1266.  In other words, compared to UpVoice 2021, it had complete control over user accounts and utilized a user's access tokens to access information that the user had not directly requested as part of its organic interaction with Facebook.  It “continued requesting data from Facebook and Instagram and sending . . . that data to BrandTotal after Google removed [it] from its online store . . . .”  BrandTotal MSJ at 1266.  Like UpVoice 2021, because the user would have access to password-protected pages she was authenticated to see, she could share that information with BrandTotal.

As described by the court, here is how UpVoice Pre-2021 worked:

BrandTotal offered programs called UpVoice [Pre-2021] and Ads Feed [(which we do not assess in this article)] that users could install as extensions for the Google Chrome internet browser, which Facebook alleges worked as follows: Once installed by the users ... [BrandTotal] used the users’ browsers as a proxy to access Facebook computers, without Facebook’s authorization, meanwhile pretending to be a legitimate Facebook or Instagram user. The malicious extensions contained JavaScript files designed to web scrape the user’s profile information, user advertisement interest information, and advertisements and advertising metrics from ads appearing on a user’s account, while the user visited the Facebook or Instagram websites. The data scraped by [BrandTotal] included both public and non-publicly viewable data about the users. [BrandTotal’s] malicious extensions were designed to web scrape Facebook and Instagram user profile information, regardless of the account’s privacy settings. The malicious extensions were programmed to send unauthorized, automated commands to Facebook and Instagram servers purporting to originate from the user (instead of [BrandTotal]), web scrape the information, and send the scraped data to the user’s computer, and then to servers that [BrandTotal] controlled.  BrandTotal TRO at 726.

The court also discussed other “legacy” products, including “Story Savebox” and “Anonymous Story Viewer” (“ASV”), which functioned similarly to UpVoice Pre-2021 from a CFAA perspective. The court noted that ASV “collected and exfiltrated users session ID tokens and sessions IDs, which would be sufficient for a third party to make requests to Instagram servers as if that third party were the user.”  BrandTotal MSJ at 1234.

The court granted Meta’s motion for summary judgment that UpVoice Pre-2021 and these other legacy products did violate the CFAA.  The court described the way UpVoice Pre-2021 worked as a “method of hijacking a user’s logged-in session with Facebook . . . to manipulate Meta’s servers to divulge further information . . . .”  BrandTotal MSJ at 1267.  The court distinguished between the access of the user versus BrandTotal:

[I]t is of no consequence whether BrandTotal had permission from its panelists [users] to use their accounts for data collection. Once Meta revoked BrandTotal’s authorization to access its platforms, BrandTotal’s continued use of its various programs to actively collect data while panelists were logged into Facebook—which it had the power to stop, but did not before February of 2021—violated the CFAA.  BrandTotal MSJ at 1267.

While UpVoice Pre-2021 and UpVoice 2021 had the same “end”—sharing private Facebook data with BrandTotal—the means to the end completely differed between the applications, which was determinative under the CFAA.  UpVoice Pre-2021 “hijack[ed] a user’s logged-in session,” while UpVoice 2021 had no control over users’ accounts. This completely changed the CFAA analysis because BrandTotal, not the user, directly communicated with Facebook’s servers.  After Facebook attempted to block BrandTotal’s access, its continued direct interaction with Facebook’s servers through users’ accounts violated the CFAA.

RPE:  User Controlled

BrandTotal also engaged in direct scraping of private Facebook pages by “hir[ing] contractors to gather data using a program called the ‘Restricted Panel Extension’ [(RPE)] for advertisements that are not available to the public and instead require a user to be logged in (for example, age-restricted ads for alcohol) . . . .”  BrandTotal MSJ at 1232.  Here, “BrandTotal collects data by directing an individual it has contracted with through a third party to install the RPE and visit specific restricted pages while logged into Facebook using that individual’s own account.”  BrandTotal MSJ at 1268.

From our read of how RPE worked, it functioned similarly to UpVoice 2021, with the only difference being it involved users who were contracted by BrandTotal to use the site.  As the court stated, “Meta’s briefs do not identify any relevant technological difference between the RPE and UpVoice 2021, instead focusing on the fact that the RPE is an ‘internal tool’ used by someone working at BrandTotal’s direction.” BrandTotal MSJ at 1268.  The court continued, "[t]here is no indication that Facebook has denied authorized access to the individual who uses the RPE, in their capacity.”  BrandTotal MSJ at 1268.  The court laid out the issue as follows:

The question, then, is whether someone who lacks authorized access to a computer violates the CFAA by soliciting someone who has access to obtain particular data from the computer.  BrandTotal MSJ at 1268.

From its review of various precedent, the court concluded that “[f]ew courts have addressed that fact pattern, but the limited authority available suggests that hiring an authorized intermediary to obtain data from a computer the principal is not authorized to access does not violate the statute,” and therefore did not violate the CFAA:

Meta highlight’s the court’s conclusion that “once authorization to access a computer has been affirmatively revoked, the user cannot sidestep the statute by going through the back door and accessing the computer through a third party.” But that case [Meta cited, Nosal III,] involved unauthorized parties using an authorized user’s credentials to interact with the computer—more comparable to BrandTotal’s older products that affirmatively requested data from Meta’s servers after an authorized user had logged in—not merely soliciting an authorized user to collect and provide information, or even “look[ing] over the shoulder of the authorized user,” as BrandTotal essentially does with the RPE.  BrandTotal MSJ at 1268–70.

An unauthorized person hiring an authorized agent to extract information from a computer system may violate any number of other laws, particularly if the information at issue is protected as trade secrets or intellectual property. But extending the CFAA to encompass such conduct risks “transform[ing] the CFAA from an anti-hacking statute into an expansive misappropriation statute.” Meta cites no case applying the statute to similar facts, and the Court declines to extend it to do so. While this interpretation of the CFAA . . . might limit its usefulness for services like Meta that generally make authorized access available for the asking, that outcome would be consistent with the Ninth Circuit’s view that the CFAA is focused on hacking and not applicable to public websites. BrandTotal MSJ at 1269–70.

Without access to their credentials, the contractors using RPE maintained full autonomy over their accounts.  This meant that, like UpVoice 2021, BrandTotal’s role was passive, “look[ing] over the shoulder of the authorized user” rather than making requests in the shoes of an authorized user.  The fact that BrandTotal had paid these contractors to act as authorized users did not change the analysis, highlighting how crucial technological realities are to the CFAA analysis.

BrandTotal Scraping:  BrandTotal Controlled

Rather than going through Facebook users, BrandTotal also directly scraped pages on Facebook for data.  It did this in two ways:  (1) through public scraping where no account was needed and (2) by establishing its own Facebook accounts and scraping the data directly.

As to the public scraping, BrandTotal’s “servers collect data directly from webpages that are publicly available for most advertisements on Facebook . . . .”  BrandTotal MSJ at 1232.  Meta revoked BrandTotal’s direct access in October 2020, yet BrandTotal continued to access the site.  BrandTotal MSJ at 1261.  Consistent with binding precedent (hiQ, discussed below), the court granted BrandTotal’s motion for summary judgment that continued access to a public webpage after a party’s access has been revoked does not constitute a violation of the CFAA because “the concept of ‘without authorization’ does not apply to public websites.”  BrandTotal MSJ at 1261 (quoting hiQ).  The court rejected Meta’s argument “that the advertisement pages at issue are not actually public, but instead that ‘the general default for [those pages] is password protection’ because while ‘Meta allows non-authenticated users to access certain ad URLs a very limited number of times, it then redirects them to a log-in page and prevents further access.’”  BrandTotal MSJ at 1261.  The court equated these restrictions to technological measures that “attempt to block automated and otherwise suspicious access, which the Ninth Circuit apparently considered insufficient to bring LinkedIn’s otherwise public pages within the scope of the CFAA” in a prior binding case.  BrandTotal MSJ at 1261.

As stated by the court:

[T]he Court holds that where a website is made available to the public without any authentication requirement in at least the first instance, “the concept of ‘without authorization’ does not apply,” even if the owner employs technological measures to block specific users, suspicious activity, or—as here—repeated access beyond a particular threshold. To hold otherwise could bring conduct ranging far beyond the CFAA’s purpose of preventing “hacking” within its scope of potential criminal liability, such as a user accessing a newspaper’s website from a smartphone after receiving notice on their computer that they had reached their monthly limit of free articles. BrandTotal MSJ at 1262 [internal citations omitted].

As to the private scraping, BrandTotal engaged in direct scraping of private Facebook pages by “us[ing] Facebook accounts that it purchased or created (which BrandTotal refers to internally as ‘Muppets’) to access information on Facebook.”  BrandTotal MSJ at 1232.  The court held that “Meta is entitled to summary adjudication that direct access by BrandTotal to password-protected areas of Meta’s platforms violated the CFAA . . . .”  BrandTotal MSJ at 1268.

Comparing the public versus private nature of direct scraping, we can see the user control theory take hold.  For the public scraping, while BrandTotal was in complete control over the scraping, given the public nature of the pages, there was no account to take control over to begin with, meaning that BrandTotal’s access could not be unauthorized.  But with the private scraping, BrandTotal was in complete control over the “Muppet” accounts as they accessed private data.  Once Facebook removed BrandTotal’s access through these accounts, continued access to private pages violated the CFAA.  

To summarize:  Access to user-authenticated pages that the user requested from the Web2 company’s servers, as well as access to publicly available pages, was not the basis for a CFAA violation for the provider because the provider did not control the user’s account, and therefore, requests.  Conversely, access to a user’s authorization tokens to view pages that the user did not request on her own was a sufficient basis for a CFAA violation.

In this section of this article, we pressure test our control legal theory extracted from BrandTotal by examining influential precedent from the Supreme Court and Ninth Circuit (much of the same precedent BrandTotal reviewed).  We conclude that these cases are consistent with a user control theory of CFAA liability (which makes sense because BrandTotal is bound by and cited such precedent).  We also examine a recent CFAA case outside of the Ninth Circuit, which stands in tension with the user control theory, but explain why we think it has limited applicability to typical extension providers.

Van Buren v. United States (S. Ct.  2021)

In Van Buren v. United States, the Supreme Court held that a “former police sergeant, [who] ran a license-plate search in a law enforcement computer database in exchange for money” did not violate the CFAA.  Van Buren v. United States, 141 S. Ct. 1648, 1652 (2021).  To access the database, “Van Buren used his patrol-car computer to access the law enforcement database with his valid credentials.”  Van Buren at 1653.  The court reasoned that the CFAA “covers those who obtain information from particular areas in the computer—such as files, folders, or databases—to which their computer access does not extend. It does not cover those who, like Van Buren, have improper motives for obtaining information that is otherwise available to them.”  Van Buren at 1652.  While this case is not a perfect parallel to browser extensions, particularly because the third party at issue was not prosecuted, we can see the case is consistent with the user control theory.  This is because an authorized user requested data to share with a third party, and a policy forbidding such a use case could not substantiate a CFAA claim, even if the search was at the request of a third party who was unauthorized.  

hiQ v. LinkedIn (9th Cir. 2022)

In hiQ v. LinkedIn, the Ninth Circuit held that a data scraper extracting information from users’ public pages did not violate the CFAA (at least for the purposes of granting hiQ a preliminary injunction against LinkedIn).  hiQ was a data analytics company that used “automated bots” to “scrape[] information that LinkedIn users have included on public LinkedIn profiles” and “use[d] that information, along with a proprietary predictive algorithm, to yield ‘people analytics,’ which it sells to business clients.”  hiQ Labs, Inc. v. LinkedIn Corp., 31 F.4th 1180, 1187 (9th Cir. 2022).  hiQ did not have any access to users’ accounts and did not need such access because all data it scraped was on publicly available pages.  After becoming aware of hiQ’s conduct, “LinkedIn sent hiQ a cease-and-desist letter, asserting that hiQ was in violation of LinkedIn’s User Agreement and demanding that hiQ stop accessing and copying data from LinkedIn’s server.”  hiQ at 1187.  The letter further stated that LinkedIn had “‘implemented technical measures to prevent hiQ from accessing, and assisting others to access, LinkedIn's site, through systems that detect, monitor, and block scraping activity.’” hiQ at 1187.  Despite this letter and technical measures, hiQ continued to scrape.  The Ninth Circuit held that there were serious questions on whether LinkedIn could invoke the CFAA:

[I]t appears that the CFAA's prohibition on accessing a computer “without authorization” is violated when a person circumvents a computer’s generally applicable rules regarding access permissions, such as username and password requirements, to gain access to a computer. It is likely that when a computer network generally permits public access to its data, a user’s accessing that publicly available data will not constitute access without authorization under the CFAA. The data hiQ seeks to access is not owned by LinkedIn and has not been demarcated by LinkedIn as private using such an authorization system. HiQ has therefore raised serious questions about whether LinkedIn may invoke the CFAA . . . .  hiQ at 1201.

While hiQ is frequently cited for the proposition that the CFAA does not apply to public pages, as discussed in our analysis of BrandTotal, we can reframe its reasoning in terms of a user control theory.  A purely public page has no account to take control over in the first instance, meaning the extension provider exercises no control.  Thus, hiQ is consistent with the user control theory.

Facebook v. Power Ventures (9th Cir. 2016)

In Facebook v. Power Ventures, the Ninth Circuit held that the social networking site that scraped Facebook data, Power.com, violated the CFAA.  Power.com was a site that “aggregate[d] the user’s social networking information” across various social media sites.  Facebook, Inc. v. Power Ventures, Inc., 844 F.3d 1058, 1062 (9th Cir. 2016).  The crux of the case revolved around a promotional campaign Power ran on its website in which a user would click a button and share the Power.com website with her friends in return for the chance to win $100.  Power Ventures at 1063.  Crucially, however, as alleged by Facebook in the complaint, “Power.com requires that users provide it with their Facebook username and password” to Power.com, and Power.com “stores these passwords outside of Facebook’s network . . . .”  Compl. ¶ 45.  With full access to these users’ accounts, “Power.com began to ‘scrape’ proprietary data from Facebook users who had given their login credentials . . . [t]his data was copied from Facebook’s site and re-purposed and re-displayed on Power.com’s site.”  Compl. ¶ 47.  Eventually, Facebook sent Power a cease and desist letter and instituted IP address barriers in an attempt to stop Power, but Power “deliberately disregarded the cease and desist letter” and “circumvented [the] IP barriers,” and continued to carry out its activity.  Power Ventures at 1068.  The Ninth Circuit held that Power violated the CFAA by continuing to access the site after receiving the cease and desist.  In describing why, the court crafted the following helpful (and colorful) analogy:

The consent that Power had received from Facebook users was not sufficient to grant continuing authorization to access Facebook’s computers after Facebook's express revocation of permission. An analogy from the physical world may help to illustrate why this is so. Suppose that a person wants to borrow a friend’s jewelry that is held in a safe deposit box at a bank. The friend gives permission for the person to access the safe deposit box and lends him a key. Upon receiving the key, though, the person decides to visit the bank while carrying a shotgun. The bank ejects the person from its premises and bans his reentry. The gun-toting jewelry borrower could not then reenter the bank, claiming that access to the safe deposit box gave him authority to stride about the bank’s property while armed. In other words, to access the safe deposit box, the person needs permission both from his friend (who controls access to the safe) and from the bank (which controls access to its premises). Similarly, for Power to continue its campaign using Facebook’s computers, it needed authorization both from individual Facebook users (who controlled their data and personal pages) and from Facebook (which stored this data on its physical servers). Permission from the users alone was not sufficient to constitute authorization after Facebook issued the cease and desist letter.  Power Ventures at 1068.

The court’s analogy makes clear that once a party has complete control over an account (or has the “key”) when that party uses the account to access a platform (or the “bank’s property”), if that account is denied access by the party, continued access would constitute a violation of the CFAA.  This is entirely consistent with the user control legal theory; by having complete control over the user’s account, continued use of that account after the party has been banned from the platform will violate the CFAA.  With full access to users’ credentials, Power fully controlled users’ accounts, and its continued access through these accounts after it had been blocked constituted a violation of the CFAA.  

Finally, a word about a specific line in Power Ventures that has been cited for positions that run in tension with the user control theory (which we’ll discuss in Ryanair below).  In its decision, the court reviewed two previous Ninth Circuit opinions that interpreted the “authorization” concept under the CFAA, LVRC Holdings v. Brekka and Nosal I (discussed below).  After providing a review of the cases, the court concluded as follows:

From those cases, we distill two general rules in analyzing authorization under the CFAA. First, a defendant can run afoul of the CFAA when he or she has no permission to access a computer or when such permission has been revoked explicitly. Once permission has been revoked, technological gamesmanship or the enlisting of a third party to aid in access will not excuse liability. Second, a violation of the terms of use of a website—without more—cannot establish liability under the CFAA.  Facebook, Inc. v. Power Ventures, Inc., 844 F.3d 1058, 1067 (9th Cir. 2016). Our analysis also is consistent with United States v. Nosal, 828 F.3d 865 (9th Cir. 2016) (“Nosal II”). Power Ventures at 1067.  [emphasis added]

We’ve underlined the line we’re referring to, which discusses “enlisting of a third party to aid in access.”  Read without context, because this line is silent on whether the third party has control over the account, it could be read for the conclusion that such level of control is not required to establish a CFAA violation.  However, neither Brekka nor Nosal I (or Nosal II, cited at the end of the quote) stands for such a proposition.  Brekka did not involve an unauthorized party enlisting a third party to access a computer system, so if it stands for anything, it would be the “technological gamesmanship” point.  (While the defendant did email the files at issue to his wife, there is no allegation the wife aided his access.)  And while Nosal I does involve a third party, as we’ll discuss next, the “enlisting of a third party to aid in access” is entirely control-rooted because the unauthorized party controlled the third party’s account.  We will return to this line in our Ryanair discussion below. 

The “Nosal Cases” (Nosal I (9th Cir. 2012), Nosal II (N.D. Cal. 2013), and Nosal III (9th Cir. 2016))

The “Nosal Cases,” which involve the same case being brought before the Northern District of California and the Ninth Circuit numerous times with a slightly different fact pattern, provide helpful contours for a user control theory under the CFAA. 

In Nosal I, an employee named David Nosal of an executive search firm, Korn/Ferry, left his job and “convinced some of his former colleagues who were still working [at the firm] to help him start a competing business.”  United States v. Nosal, 676 F.3d 854, 856 (9th Cir. 2012) [“Nosal I”].  “The employees used their log-in credentials to download source lists, names and contact information from a confidential database” called “Searcher” “and then transferred that information to Nosal.” Nosal I at 856.  While “[t]he employees were authorized to access the database,” the firm “had a policy that forbade disclosing confidential information.”  Nosal I at 856.  Nosal was criminally charged “with violations of [the CFAA], for aiding and abetting . . . employees in ‘exceed[ing their] authorized access’ with intent to defraud.”  Nosal I at 856.  The court held that “[b]ecause Nosal’s accomplices had permission to access the company database and obtain the information contained within, the government's charges” on the CFAA must be dismissed.  Nosal I at 864.  This holding is consistent with a user control theory—Nosal may have requested the employees to use their authorized access but did not control those users’ access credentials and, therefore, could not be liable under the CFAA (for these charges).

In Nosal II, “[o]n remand to the district court, the prosecution asserted additional facts regarding other individuals: an authorized user, J.F., ‘logged on to the computer using her credentials, then handed over the computer terminal to M.J. [an unauthorized user], who ran his own searches through the . . . database and then downloaded files therefrom.’”  BrandTotal MSJ at 1269; United States v. Nosal, 930 F. Supp. 2d 1051, 1063 (N.D. Cal. 2013) [“Nosal II”].  With access to the computer with the logged-in user’s credentials, M.J. had complete control over J.F.’s account and was able to carry out the unauthorized searches.  The court “held that was sufficient to allege that M.J. accessed the computer without authorization, as it was equivalent to using J.F.’s credentials to access what M.J. was not himself authorized to access.”  BrandTotal MSJ at 1269.  The court explicitly distinguished this active control over an authorized user’s account from the scenario of an unauthorized user simply “look[ing] over the shoulder of the authorized user to view password protected information or files,” saying it “need not opine” on that issue in this case.  Nosal II at 1063.  Nosal II shows a key distinction from Nosal I that further supports a user control theory:  the unauthorized user in Nosal II had full access to user credentials, which was not the case in Nosal I.  The difference was determinative for CFAA liability.  

Finally, in Nosal III, “the relevant facts were that after Nosal and his accomplices had left the company, the accomplices continued to access its network using the access credentials of Nosal's former executive assistant, who continued to work there at Nosal’s request.”  BrandTotal MSJ at 1269.  The court affirmed Nosal’s conviction for the same reason as in Nosal II—an unauthorized user obtaining full access to an employee’s account through an authorized user’s username and password constituted a violation of the CFAA:

Implicit in the definition of authorization is the notion that someone, including an entity, can grant or revoke that permission. Here, that entity was Korn/Ferry, and [a former employee] had no mantle or authority to override Korn/Ferry’s authority to control access to its computers and confidential information by giving permission to former employees whose access had been categorically revoked by the company. Korn/Ferry owned and controlled access to its computers, including the Searcher database, and it retained exclusive discretion to issue or revoke access to the database. By revoking Nosal’s login credentials on December 8, 2004, Korn/Ferry unequivocally conveyed to Nosal that he was an “outsider” who was no longer authorized to access Korn/Ferry computers and confidential information, including Searcher. Korn/Ferry also rescinded [two other former employees’] credentials after they left, at which point the three former employees were no longer “insiders” accessing company information. Rather, they had become “outsiders” with no authorization to access Korn/Ferry's computer system.  United States v. Nosal, 844 F.3d 1024, 1035–36 (9th Cir. 2016).

Again, an unauthorized user with complete control of an authorized user’s account could substantiate a CFAA violation, further supporting the user control theory.

Koninklijke Philips (N.D. Cal. 2015)

In Koninklijke Philips v. Elec-Tech, the Northern District of California held that unauthorized third parties (ETI, ETI-HK, Mr. Wang, and Ms. Chen, “CFAA Defendants”) to a company’s computer system did not violate the CFAA by receiving documents from an authorized user (Dr. Chen).  Koninklijke Philips N.V. v. Elec-Tech Int’l Co., No. 14-CV-02737-BLF, 2015 WL 1289984, at 4 (N.D. Cal. Mar. 20, 2015).  The plaintiffs alleged that the CFAA Defendants violated the CFAA “through Dr. Chen as their agent – essentially that Dr. Chen, though himself authorized to access the data, was a conduit by which the CFAA Defendants engaged in their own unauthorized access.”  Koninklijke Philips at 4.  The court explained that this agency theory of liability could not stand because the unauthorized third parties did not have control over the account that accessed the computer system:

Plaintiffs here make no allegation that either Mr. Wang or Ms. Chan was given Dr. Chen’s password and then ran searches, nor do they allege that either individual Defendant in any way accessed or downloaded information from Lumileds’ network. By the Complaint's own allegations, none of the CFAA Defendants accessed Lumileds’ information–Dr. Chen did, at a time when he was authorized to download this information. Even if he misappropriated the information, and gave it to the CFAA Defendants, Nosal forecloses a claim against those Defendants under the CFAA because they themselves did not hack Lumileds’ system. Plaintiffs’ argument that Dr. Chen and the CFAA Defendants were essentially “acting as one” for purposes of accessing the files does not save Plaintiffs’ CFAA claim. Rather, it shows that this case is factually quite similar to Nosal: it is alleged that outsiders convinced an insider to access information the insider was authorized to access, then hand that information over to the outsiders. While such allegations could possibly state a claim for misappropriation, they cannot state a claim under the CFAA after Nosal. Reading the CFAA in its context as an anti-hacking statute, “access” means something more than persuading someone to procure information you desire. Instead, as described by the district court in Nosal II, “[t]he common definition of the word ‘access’ encompasses not only the moment of entry, but also the ongoing use of a computer system.” None of the CFAA Defendants entered or used Lumileds’ network. At most, they encouraged Dr. Chen to do so, and stood to benefit from the alleged misappropriation. This action may give rise to a number of claims, but it does not support a theory of liability under the CFAA.  Koninklijke Philips at *4 [internal citations omitted].

The court makes clear that merely “persuading someone to procure information you desire” is not actionable. Control over the account beyond the point of entry was required, and that control is best represented by having access to the authorized user’s login credentials.

Countervailing Theories

While we feel confident in the user control theory as a sensible way to understand the CFAA (particularly in the Ninth Circuit), we must acknowledge that some courts have taken interpretations that are in tension with this view.  For example, in July 2024, a jury in the District Court of Delaware (the Third Circuit) found Booking Holdings (Booking.com, Kayak, etc.) liable for “intentionally direct[ing], encourag[ing], or induc[ing]” a third party to extract booking information from a private portion of the Ryanair website (called myRyanair) in violation of the CFAA.  Booking Holdings had agreements with vendors like Etraveli to collect “Ryanair flight information and book Ryanair flights by sending requests for these actions from their websites to the vendor websites.”  Ryanair DAC v. Booking Holdings Inc., 636 F. Supp. 3d 490, 503 (D. Del. 2022) [“Ryanair MTD”]; Ryanair DAC v. Booking Holdings Inc., No. 1:20-cv-01191 (D. Del. 2024) at 39 [“Ryanair MSJ”].  Under the user control theory we’ve delineated, because Booking Holdings did not control these vendors’ credentials, it should not be liable under the CFAA.  However, in direct contrast to the independent contractors in BrandTotal (“the limited authority available suggests that hiring an authorized intermediary to obtain data from a computer the principal is not authorized to access does not violate the statute,” BrandTotal MSJ at 1268), the court held on a motion to dismiss (and affirmed this reasoning on a motion for summary judgment) that Booking Holdings could be vicariously liable for directing, encouraging, or inducing these vendors’ own CFAA violations:

In sum, to the extent the defendants argue that the complaint was insufficient because it failed to allege the existence of a formal agency relationship between the defendants and the aggregators, the short answer is that the existence of an agency (or master-servant) relationship is not a necessary predicate for liability on a “direct, encourage, or induce” theory. As indicated in the cases cited above, even if the aggregators are independent contractors and not agents of the defendants, the defendants can be held liable simply based on evidence that the defendants induced the aggregators to commit violations of the CFAA.  Ryanair MTD at 503. [emphasis added]

Of the cases the court cites for this proposition (“in the cases cited above”), the only circuit case it cites on the motion to dismiss is Power Ventures, quoting the line we called out above when discussing that case:  “Once permission has been revoked, technological gamesmanship or the enlisting of a third party to aid in access will not excuse liability.”  Power Ventures at 1067.  The court again cites this case in its order on the motion for summary judgment as the only case supporting this proposition.  Ryanair MSJ at 39 (“The defendants cannot now avoid liability simply because third parties access the Ryanair website to obtain the relevant information and make bookings for the defendants’ customers,” citing Power Ventures).  Yet, as discussed above, this line does not support the proposition that it is cited for, that “defendants can be held liable simply based on evidence that the defendants induced the aggregators to commit violations of the CFAA.” Instead, this line is a clear callout to Nosal I, where a user control theory of liability was central to the case:  the “enlisting of a third party to aid in access” is control rooted because the unauthorized party controlled the third party’s account.  While, in its motion to dismiss, the court does cite a series of district court opinions from outside the Ninth Circuit that appear to support its conclusion (and it is not bound by Power Ventures), it is imprecise as it relates to Power Ventures.

Even if we accept the “directing, encouraging, or inducing” with no control over user accounts theory of liability, we think it still has limited applicability to ordinary use of extensions.  We can analogize Ryanair as the platform, Booking Holdings as the extension provider, and the vendor as the user.  In Ryanair, Booking.com had a contractual relationship with the vendors, which “the complaint alleges that the Defendants specifically direct one or more of those third parties to access the myRyanair portion of the Ryanair website when a user purchases a particular Ryanair flight itinerary on one of the defendants’ websites.”  Ryanair MTD at 502.  While an extension provider may have terms of service with an extension user, the purpose of the contract is typically not going to be for the user to act as a service provider for the extension provider (although some extensions/programs, like RPE, may blur the line).  The Ryanair case involves a level of directness that stands in stark contrast to a user who is simply experiencing a website with an extension running and passively shares information with the extension provider.

Furthermore, Ryanair makes clear that a necessary condition for establishing vicarious liability to Booking Holdings is that the vendor itself violated the CFAA.  Ryanair MSJ at 39 (“If the vendors’ actions are in violation of the CFAA, then the defendants can be held liable.” (emphasis added)).  While in Ryanair this presumably involved showing how the vendors evaded the legal and technical restrictions at trial, a typical extension user will not take action besides merely downloading the extension.  

Thus, to the extent that the more indirect control over a third party prevails as a legal theory, the applicability to typical browser extensions is likely limited.

Browser extensions provide a convenient, user-friendly way for end users to access their own data locked behind Web2 platforms, and they help achieve user autonomy and self-custody of personal user data.  Web2 companies understandably do not want to cede user ownership/control over their own data (despite often explicitly stating otherwise in their terms of service) because their business models depend on total control over user data, which they are then able to sell to advertisers, and more increasingly, LLM providers.  We expect Web2 companies to only increase their use of the CFAA as one legal lever to push back against users’ attempts to regain control over their data.

However, from our review of some influential case law, we believe there is a pathway for extension providers to allow users to control their data without running afoul of the CFAA.  This pathway relies on the extension provider not controlling users’ accounts with the given platform.

Zooming out, this theory has intuitive grounding:  if the provider does not have access to the user’s account, it is the user who is making the request to the provider’s servers, not the provider, so the provider cannot reasonably be said to have engaged in “unauthorized access” of the platform’s servers.  The issue this article has highlighted is much bigger than simply browser extensions.  It’s about whether users are entitled to meaningful control over their data.  In this vein, we conclude with an excerpt from the hiQ court to remind us what’s at stake:

[G]iving companies like LinkedIn free rein to decide, on any basis, who can collect and use data—data that the companies do not own, that they otherwise make publicly available to viewers, and that the companies themselves collect and use—risks the possible creation of information monopolies that would disserve the public interest.  hiQ at 1202.

This post is provided for informational purposes only, and should not be relied upon as legal, business, investment, or tax advice. Thus, this post should not be construed as legal advice for any particular facts or circumstances and is not meant to replace competent counsel. It is strongly advised for you to contact reputable legal counsel in your jurisdiction for any questions or concerns. None of the opinions or positions provided in this post are intended to be treated as legal advice or to create an attorney-client relationship. No reader, user, or browser of this site should act or refrain from acting on the basis of information on this site. This analysis might not reflect all current updates to applicable laws or interpretive guidance, and the author disclaims any obligation to update this post. All liability with respect to actions taken or not taken based on the contents of this site are hereby expressly disclaimed. The content on this posting is provided "as is;" no representations are made that the content is error-free.

These charges echo those in SEC v. Coinbase, where the SEC alleged that Coinbase acted as a broker through its non-custodial wallet product, Coinbase Wallet, and engaged in the unregistered offers and sales of securities through its staking program. At the time, I was in private practice and a lead attorney working with the amazing DeFi Education Fund (DEF) team on their amicus brief in Coinbase, which went into technical detail as to why the SEC's charges regarding Coinbase Wallet and Coinbase's staking program could not stand. The court granted Coinbase's motion for judgment on the pleadings as to Coinbase Wallet but allowed the staking program claims to move forward.

Here’s a simple chart summarizing the claims on wallets and staking in these two cases, and you’ll note there is significant overlap:

In this post, I compare the wallet/swaps allegations in Coinbase and Consensys and drill down on some of the specific claims the SEC is making. My overall impression is that the SEC has done a better job in Consensys than in Coinbase of mapping its allegations to the actual elements of what it means to be a broker, but, in some instances, it exaggerates or gets key elements of how the technology functions wrong in its attempt to aggrandize Consensys’s role in users’ swaps.

First, let's define a broker. Like many things in securities laws, the definition of a broker is squishy. It's defined in the Exchange Act as “any person engaged in the business of effecting transactions in securities for the account of others”. The next reasonable question is what on Earth that means. There are a number of factors courts consider, but I'll pull the nine Coinbase cited in its motion for judgment on the pleadings:

Courts look to a number of factors to determine whether an entity is acting as a broker, including whether it “(1) actively solicits investors; (2) receives transaction-based compensation; (3) handles securities or funds of others in connection with securities transactions; (4) processes documents related to the sale of securities; (5) participates in the order-taking or order-routing process; (6) sells, or previously sold, securities of other issuers; (7) is an employee of the issuer; (8) is involved in negotiations between the issuer and the investor; and/or (9) makes valuations as to the merits of the investment or gives advice.” SEC v. GEL Direct Tr., 2023 WL 3166421, at *2 (S.D.N.Y. Apr. 28, 2023)

There is no minimum number of these factors that must be met to qualify as a broker, but the more that are met, the more likely the court will hold the entity in question is a broker. So the SEC's job in writing these complaints is to plausibly allege as many of these factors as it can to survive a motion to dismiss.

Starting with Coinbase, the core reasons the SEC did not prevail on the broker charge for Coinbase Wallet was because (1) the SEC did not allege enough of the broker factors and (2) for the factors it did allege, it did not adequately explain how Coinbase was carrying out those activities.

As explained by the court:

As an initial matter, the SEC’s allegations do not implicate many of the factors courts use in identifying a “broker.” Notably, the SEC does not allege that the Wallet application negotiates terms for the transaction, makes investment recommendations, arranges financing, holds customer funds, processes trade documentation, or conducts independent asset valuations. (SEC Opp. 25-27). Rather, the Complaint alleges that Coinbase: charged a 1% commission for Wallet’s brokerage services (Compl. ¶ 101); actively solicits investors (on its website, blog, and social media) to use Wallet (id. ¶ 75); compares prices across different third-party trading platforms (id. ¶ 82); and “routes customer orders” in crypto-asset securities to those platforms (id. ¶ 64). Upon closer examination, these allegations, alone or in combination, are insufficient to establish “brokerage activities.”

As alleged, Coinbase’s participation in the order-routing process is minimal. While Wallet “provide[s] access to or link[s] to third-party services, such as DEXs” (User Agreement App’x 4 § 8.1.2), the SEC does not allege that Coinbase performs any key trading functions on behalf of its users in connection with those activities. As the Complaint acknowledges, Coinbase has no control over a user’s crypto-assets or transactions via Wallet, which product simply provides the technical infrastructure for users to arrange transactions on other DEXs in the market. (Compl. ¶ 64). Only a user has control over her own assets, and the user is the sole decision-maker when it comes to transactions.

What is more, while Wallet helps users discover pricing on decentralized exchanges, providing pricing comparisons does not rise to the level of routing or making investment recommendations. . . . Similarly, the fact that Coinbase has, at times, received a commission does not, on its own, turn Coinbase into a broker.

As discussed above, because of these deficiencies, the court granted Coinbase’s motion for judgment on the pleadings on this charge.

After taking the "L" in Coinbase on a similar product, how did the SEC approach the broker allegations for MetaMask Swaps in Consensys? As one would expect, I think they tried to address each of the core deficiencies the court delineated in Coinbase by alleging more of the broker factors and painting a picture of Consensys and the software Consensys has built as active in the process of a user making a swap. 

For example, look at how the agency describes MetaMask Swaps in the Consensys complaint at a high-level:

MetaMask Swaps functions as follows. An investor enters the name and amount of the crypto asset that they wish to sell, as well as the name of the crypto asset that they wish to buy in return. MetaMask Swaps then pulls available rates for the requested exchange from a Consensys-curated group of execution venues and other third-party liquidity providers (referred to herein as “third-party liquidity providers”) and displays those rates to the investor, highlighting the option that Consensys deems “best.” With one additional click by the investor, MetaMask Swaps performs the functions necessary to effect the trade, on the investor’s behalf, with the third-party liquidity provider. As described in further detail below, Consensys’s software routes the investor’s order by transferring their asset and trading instructions through Consensys’s own smart contracts on the blockchain, which interface with third-party liquidity providers on the investor’s behalf. As is typically the case in traditional securities markets, the investor here never interacts directly with the third party; all investor interactions are directly with Consensys’s platform. And Consensys collects a fee on most transactions. [emphasis added]

You’ll notice that the SEC uses many of the key words from the broker test (or their synonyms), like “highlighting”, “curated”, “best”, “effect”, “routes”, “trading instructions”, “on the investor’s behalf”, “fee”, etc., and I've underlined all the active roles the SEC is alleging Consensys takes. It is night and day from the SEC’s allegations regarding Coinbase Wallet in terms of what the agency describes as the software provider’s role in making the swap.

For the remainder of this post, I drill down into some of the specific allegations the SEC is making and compare it to how the technology actually functions. I find that the SEC repeatedly aggrandizes Consensys’s role in users’ swaps, at odds with how the technology functions.

Smart Contracts

From the complaint:

MetaMask Swaps will . . . interface with a third-party liquidity provider that executes the investor’s order, thereby selling Crypto Asset A and acquiring Crypto Asset B on behalf of the investor . . . .

Accordingly, the Consensys software transfers Crypto Asset A to Consensys’s Spender.sol smart contract’s blockchain address. 

Consensys’s Spender.sol smart contract address temporarily holds the investor’s Crypto Asset A. . . . Consensys’s Spender.sol smart contract will interact with a number of Consensys-developed “Adapter” smart contracts.

Specifically, through the Adapter smart contract, the third-party liquidity provider will take Crypto Asset A from the Spender.sol smart contract address and place Crypto Asset B into the Spender.sol smart contract address. 

Consensys . . . facilitat[es] trading in crypto asset securities by . . . handling customer crypto asset securities through Consensys-operated smart contract addresses . . . .

As I detail below, my best guess for what the SEC is describing here is a user performing an atomic swap through smart contracts Consensys wrote, which, if true, would entail significantly less control of the swapping process by Consensys than the SEC is implying.

But before diving into that, a general comment:  I was struck by some of the slippery language the SEC uses here that glosses over how blockchains function, particularly “Consensys-operated smart contract” and “Consensys software transfers”. It is not clear what the SEC means by a “Consensys-operated smart contract”. While there is some admin functionality on the smart contract for a multi-sig that Consensys may control, there is no evidence to suggest the company actively operates the smart contract’s code. In fact, the whole point of smart contracts is that the code is run by a dispersed network that no one controls. And it is not “the Consensys software” that “transfers Crypto Asset A to Consensys’s Spender.sol smart contract[]”— it is the user who signs the transaction to authorize the transfer, not Consensys, and it is the blockchain protocol outside of the hands of Consensys that updates the state.

Okay, let’s return to the point on atomic swaps. To see what’s really going on, let’s look at the code of the MetaMask Swap Router smart contract. The key function is _swap() on MetaSwap.sol, which calls swap() on Spender.sol:

// MetaSwap.sol
    function _swap(
        string calldata aggregatorId,
        IERC20 tokenFrom,
        uint256 amount,
        bytes calldata data
    ) internal {
        Adapter storage adapter = adapters[aggregatorId];

        if (address(tokenFrom) != Constants.ETH) {
            tokenFrom.safeTransferFrom(msg.sender, address(spender), amount);
        }

        spender.swap{value: msg.value}(
            adapter.addr,
            abi.encodePacked(
                adapter.selector,
                abi.encode(msg.sender),
                adapter.data,
                data
            )
        );

        emit Swap(aggregatorId, msg.sender);
    }

// Spender.sol
	function swap(address adapter, bytes calldata data) external payable {
        require(msg.sender == metaswap, "FORBIDDEN");
        require(adapter != address(0), "ADAPTER_NOT_PROVIDED");
        _delegate(adapter, data, "ADAPTER_DELEGATECALL_FAILED");
    }

It is not the case that MetaMask Swaps performs a swap “on behalf of the investor”. The user must sign all transactions controlling her tokens, which Consensys cannot do on behalf of a user because it does not have access to the private key stored on the user’s device. And looking at the code, the swap() function is atomic—its job is to send tokens out and return tokens to the user in a single transaction. Even the flow of a user granting approval to Spender.sol prior to the swap and later calling swap() does not change this fact, because (1) the only function that transfers tokens is _swap() and (2) that function’s implementation ensures that the sender must be the owner of the tokens (tokenFrom.safeTransferFrom(msg.sender, address(spender), amount)). Assuming the adapters are not malicious (which would be another issue entirely), their job is to enable a user to perform an atomic swap—in a single transaction take token A and exchange it for token B. This would mean that transactions are "all or nothing"—either the tokens are swapped or they are not, they cannot end up in possession of the Spender.sol contract or Consensys as could be implied from phrases the SEC uses like the “Spender.sol smart contract address temporarily holds the investor’s” tokens, and tokens are “place[d] . . . into the Spender.sol smart contract address”, and “Consensys . . . handl[es] [tokens] through Consensys-operated smart contract addresses”. 

Slippage

From the complaint:

(Setting a slippage tolerance effectively creates a “limit order,” which is an extremely common type of order offered by traditional brokers.) 

Slippage is not “effectively” the same thing as a traditional limit order, and conflating these things implies more active management for Consensys over users’ orders than occurs in reality. 

Here's the key difference: in a traditional limit order, one party tells another party a condition of when a transaction should be executed in the first instance, whereas slippage involves a smart contract running a check when a transaction is executed. This leads to a very different result from a control standpoint because the traditional limit order generally involves trusting another party to watch markets and only submit an order when the condition is met. Slippage, on the other hand, does not involve active management by any third party. Instead, with slippage, the user sets a minimum amount of the token she wants to receive and executes the transaction, with the smart contract (running autonomously) checking that the minimum back is in fact received, else the transaction will fail. 

Put simply, slippage is an emergency break the user sets to protect herself while a traditional limit order is an instruction for when another party should execute an order on behalf of the user. The latter has the intermediation associated with broker activity, while the former does not.

Private Key Storage and Retrieval

From the complaint:

[T]he Consensys software reads the investor’s private key from the MetaMask Wallet. This is the digital password that cryptographically unlocks Crypto Asset A so that it can be transferred out of the investor’s MetaMask Wallet.

To place an order through MetaMask Swaps, the investor does not need to know or enter their private key (the cryptographic “passcode” that is necessary to transfer Crypto Asset A out of their wallet).

First, it’s not clear what the SEC means when it says that the “Consensys software reads the investor’s private key from MetaMask Wallet”. What is the “Consensys software” here?  I would have thought it was the MetaMask Wallet, which the SEC defines as “a Consensys-developed software application for storing investors’ crypto assets”, but read that way, the sentence does not make sense. If the SEC is trying to say that other Consensys software besides the wallet application ever touches the private key, then that is plainly wrong. To be crystal clear, “MetaMask generates passwords and keys on your device”, not in the software application itself, so even saying the private key is read “from MetaMask Wallet” is not really accurate. Rather, MetaMask Wallet requests the private key from storage on the device. 

But the real thing I want to focus on here is the insinuation that the retrieval of private keys via a wallet application somehow implicates brokerage activity. It does not. Everyday we interact on the internet and, to make it usable, we utilize software to abstract away cumbersome technical points. Think about all of the things Chrome does behind the scenes to make your experience usable. Chrome stores your passwords locally so you don’t have to enter them every single time you visit a site, engages in the TLS protocol behind the scenes to ensure private transfer of data over the wire, etc. Does this mean Google, via Chrome, acts as a broker when the user utilizes these features to trade on Fidelity.com?  Of course not. The same consideration applies here with wallet software developers.

The fact that the SEC is citing software abstracting away the nitty-gritty of interacting on the internet as evidence of control is a scary insinuation that goes far beyond crypto.

RPC Nodes

From the complaint:

[T]he Consensys software submits a blockchain transaction to a Consensys-operated and controlled remote procedure call or “RPC” node. The RPC node stores the blockchain transaction in a mempool (a collection of proposed transactions that are in a queue) until it is included in a block and executed, as per the steps below. More specifically, the Consensys software creates, signs (using the investor’s private key), and submits this blockchain transaction to Consensys’s RPC node, which when executed will transfer the specified amount of Crypto Asset A from the investor’s wallet address to a Consensys-developed smart contract called “Spender.sol.”

Consensys . . . facilitat[ed] order execution by submitting blockchain transactions to a Consensys node . . . .

Here, the SEC is describing what I presume is a vanilla RPC Ethereum node but by labeling it "Consensys-operated and controlled", it could be read to suggest that Consensys is doing something special beyond simply participating in the Ethereum blockchain protocol. It has no bearing that Consensys submits transactions to a node it runs—Consensys could submit them to any RPC node it wants and get the same result.

Wallet Account "Creation"

From the complaint:

Consensys . . . facilitat[ed] trading in crypto asset securities by creating customer wallets (i.e., “accounts”) . . . .

This allegation is a repeat of one the SEC made in Coinbase, and as debunked in the DEF brief, this is not faithful to what it means to establish a wallet:

A blockchain has no notion of “open” versus “closed” “accounts,” or which private keys have been selected for use. A simple way to see why this is true is that it is perfectly valid to transfer crypto assets on a blockchain to a public key that no one has ever attempted to derive from a private key; the assets would simply be unobtainable until and unless someone randomly selects the private key associated with that public key. All wallets on a blockchain already exist, and users choose which one is theirs by selecting a random number (a private key). No one, including the developer of any wallet application, authorizes or manages this process; it depends entirely on the fact that, for all practical purposes, no two users will ever pick the same number. There is no checking or approval process, no “approved” versus “not approved” “accounts” or “list” being checked to make sure the user has registered. After a user selects a random number (a private key), she can immediately begin transacting on a blockchain using digital signatures. Therefore, there is nothing Coinbase or Wallet actively does to “open” an “account” because there is no “account” in the way the SEC alleges.

I’m surprised the SEC repeated this allegation with effectively no change from Coinbase, given how detached from the technical reality it is.

From a pleading standpoint, the SEC’s complaint in Consensys does a better job of trying to incorporate the broker test factors, which I think makes it a stronger complaint than Coinbase. However, careful attention to these allegations is still needed to ensure that they are precise about the role Consensys has over users’ swaps. Upon close inspection, the SEC either exaggerates or gets key elements of how the technology functions wrong. This puts into serious question the strength of their charge that Consensys, through MetaMask, acts as a broker.

This post is provided for informational purposes only, and should not be relied upon as legal, business, investment, or tax advice. Thus, this post should not be construed as legal advice for any particular facts or circumstances and is not meant to replace competent counsel. It is strongly advised for you to contact reputable legal counsel in your jurisdiction for any questions or concerns. None of the opinions or positions provided in this post are intended to be treated as legal advice or to create an attorney-client relationship. No reader, user, or browser of this site should act or refrain from acting on the basis of information on this site. This analysis might not reflect all current updates to applicable laws or interpretive guidance, and the author disclaims any obligation to update this post. All liability with respect to actions taken or not taken based on the contents of this site are hereby expressly disclaimed. The content on this posting is provided "as is;" no representations are made that the content is error-free.