Daniel Barabander
Daniel Barabander and Cooper Kunz
> 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:
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.
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.
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:
Public scraping: BrandTotal directly scraped public pages of Facebook’s website using its employees’ accounts and automatic scraping tools.
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.
With the rise of agents that heavily interact with Web2 applications, primitives that help users unchain their Web2 data will become increasingly important. These primitives include account encumbrance using TEEs, zkTLS to prove something about a user account, etc. These primitives allow crypto companies to offer products/services that empower users to unlock their data without giving these companies access to users' credentials. Examples include Flashbot's Teleport (account encumbrance) and Pluto's Web Proofs (zkTLS).
Obviously, Web2 companies do not like users controlling their own data. One of their favorite legal hammers to stop this is the Computer Fraud and Abuse Act (CFAA), which provides a private right of action against a person who “intentionally accesses a computer without authorization.” Specifically, Web2 companies love to sue products/services that empower users to export their data under the CFAA. Here's an example of X doing this against a scraping company: https://natlawreview.com/article/x-corp-lawsuits-target-data-scraping.
I wrote a long article about the CFAA back in August. In that article, I focus on a court case called BrandTotal (and test it against influential precedent). The TLDR of that article is that I believe that products/services that empower users to unchain their data from a Web2 platform without accessing their credentials have a strong argument that they do not violate the CFAA.
Let’s quickly review the BrandTotal case to see why. BrandTotal was an analytics company that collected Facebook ad data using browser extensions used by end users and its own scraping services. Facebook really did not like this. It used contractual (TOS, cease and desist) and technical (CAPTCHAs, account bans) methods to block BrandTotal, but BrandTotal kept on collecting anyway. Facebook sued BrandTotal under the CFAA. In analyzing the claim, the court made key distinctions between different BrandTotal products/services. These products/services varied in whether they had access to user credentials. From the court’s reasoning, we can see a pattern emerge: whether BrandTotal violated the CFAA came down to whether it had access to user credentials. Here’s a summary table depicting this:
1/ What are agents good at? We debated internally and came up with at least four things: (1) meeting humans where they are; (2) doing work for nudging humans; (3) aggregating and synthesizing information and (4) being entertaining.
2/ First, meeting humans where they are. Agents can process human language, so any app where a human can be a user, an agent can in theory too. But unlike human users, agents can offer services to other users on these platforms at scale.
3/ Thus, agents can act as a layer on top of existing apps users already love, extending their utility. Take @bountybot on Farcaster. Users could post bounties externally, but that adds friction. Waiting for the Merkle team to build this feature takes time. It’s a service on top.
4/ By meeting users where they are, agents offer convenience, utility, and a way to capture value within existing apps. But note: not all apps are created equal for supporting agents — the best apps to build on top of are those w/ an unruggable API, like @farcaster.
did you make sure to run this through compliance
Connect it to deterministic code, and agents are capable of doing actions as well.
In my latest post on my blog Proofs and Protocols, I teamed up with my colleague, Variant Investment Partner Cooper Kunz, to dissect the Computer Fraud and Abuse Act (CFAA) and browser extensions (e.g., Chrome Extensions). Here’s a thread with the TLDR 👇
The CFAA is a federal statute originally passed to prevent hacking. Facebook, X, and LinkedIn have utilized the CFAA heavily in recent years to go after scraping services they view as a threat to their business models that rely on locking data within their platforms
We review case law in the 9th Circuit and devise a “user control” theory to understand the CFAA. Under this theory, we conclude that if a browser extension 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
If you’re a Web3 company building a browser extension and find this interesting, please reach out; would love to hear what you’re working on
Hi. Are you Satoshi Nakamoto? No hidden meanings, just answer.