So Barry Abrahamson's Previously Sealed Testimony in the Automattic Trial... ![rw-book-cover](https://pbs.twimg.com/profile_images/1509994126183444488/va4X6Ozk.jpg) 🔗 **Source:** [So Barry Abrahamson's Previously Sealed Testimony in the Automattic Trial...](https://twitter.com/DuaneStorey/status/2105556221990187368/?rw_tt_thread=True) > [!note]+ Document Notes > tags: [wordpress-org-api, data-collection-transparency, plugin-privacy, court-testimony, wpengine-v-automattic] > author: Duane Storey > source: X > reference: https://x.com/DuaneStorey/status/2105556221990187368 > date created: 2026-10-01 09:20 > > > [!info] Generated analysis — not the author's words. Sections below are machine-written > > from the captured source. Only text inside `> [!quote]` blocks is verbatim from the author. > > Do not quote or attribute any other line to the named author. > > # 🏷️ Title: So Barry Abrahamson's previously sealed testimony in the Automattic trial... > <!-- deep-read:sections start --> ## 🧭 Table of contents - [📝 Summary](#-summary) - [📖 Main content](#-main-content) - [🗒️ Notes](#️-notes) - [📚 References](#-references) - [🗣️ Paraphrase](#️-paraphrase) - [📰 Newsletter](#-newsletter) - [✅ Action items](#-action-items) - [🧪 Hypotheses](#-hypotheses) - [📊 Methodology](#-methodology) - [❓ Questions](#-questions) - [🔮 Future research](#-future-research) - [💡 Implications](#-implications) - [🧠 Learning styles assessment](#-learning-styles-assessment) - [📊 Accessibility assessment](#-accessibility-assessment) - [🌍 DEIB assessment](#-deib-assessment) - [✅ Logical validity](#-logical-validity) - [🛡️ DARVO analysis](#️-darvo-analysis) - [🎯 Conclusion](#-conclusion) - [🔄 Refactor appendix](#-refactor-appendix--so-barry-abrahamsons-previously-sealed-testimony-in-the-automattic-trial) ## 📝 Summary Read this first: the source is a social-media opinion thread by one WordPress developer, 8 paragraphs and about 420 words, posted on X on 2026-10-01. It is one-sided commentary. Testimony is a party's sworn answers under questioning, and the excerpt contains counsel's objections. Nothing in this analysis is legal advice. The labels below keep three layers apart: (a) what the thread says the testimony says, (b) Storey's own inferences, and (c) what the deposition excerpt (Dkt. 419) shows. "The excerpt" means only the 5-page filing. Where a point is absent from it, this analysis says "the excerpt does not show." - **What happened.** Duane Storey posted a thread the day after Dkt. 419 was filed (the excerpt's header reads "Filed 09/30/26"). The thread tells readers to read Barry Abrahamson's newly public testimony in WP Engine v. Automattic (¶0), links Storey's earlier post on the WordPress.org update API (¶1, ¶2), and links the excerpt (¶4, ¶5). - **(a) What the thread says the testimony says.** The data that plugin update calls send to WordPress.org feeds a dashboard called "MC Dashboard," where MC stands for Mission Control (¶3). The data is described as anonymized yet stored in a database (¶3). Abrahamson was asked pointed questions about the ACF Pro section of that dashboard (¶4). Separately, Matt testified that some data existed for only 24 hours before destruction (¶7). That last item is not Abrahamson's testimony. - **(b) Storey's inferences.** The update call sends a full plugin list, including private and paid plugins, plus the site name (¶1). ACF Pro is a paid plugin not served from the WordPress.org repository (¶4). Install information for non-.org plugins therefore sits in the dashboard and can be viewed at will (¶4). The dashboard holds competitive information on every paid plugin and theme (¶6). Nobody opted in, and the collection is buried in WordPress.org legal text (¶6). Matt's 24-hour statement conflicts with all-time aggregation (¶7). Storey hedges several of these ("if I read it right," "I believe," "as far as I know"). - **(c) What the excerpt shows.** It covers deposition pages 26-29 and 606-609 of a December 19, 2025 30(b)(6) deposition of Abrahamson on behalf of Automattic. On pages 607-609 the witness says MC.WordPress.org is a dashboard of statistics, that its plugin data is powered by calls to API.WordPress.org, and that a script collects, anonymizes, aggregates and stores that data in a database (called something like "Stats"). The excerpt gives no payload contents: it cuts off at a question about what information is sent. It does not show the paid-plugin status of ACF Pro, who can view the dashboard, any consent flow, or any 24-hour statement. - **Why it matters.** The thread targets an open question in the WordPress community: what does the WordPress.org update API receive, and what happens to it. The excerpt confirms a stored, aggregated statistics path. The thread's larger claims need the omitted pages or other evidence. - **Key stakeholders.** Storey (author, and publisher of a counter-plugin per the earlier post), Abrahamson (witness for Automattic), Matt Mullenweg (a defendant in the caption, and the likely referent of "Matt"), WP Engine and Automattic (parties), plugin authors with paid or private plugins, site owners, hosts, and the WordPress.org Meta, Plugins and Core teams. - **Risks and tradeoffs.** A reader who takes the thread as a summary of the testimony will overstate it. A reader who dismisses the thread will miss that the excerpt does confirm a collect, anonymize, aggregate, store path with an ACF Pro install graph. Court filings are partial by design, so absence from the excerpt is not absence from the record. - **Bottom line.** Treat the thread as a pointer to a primary source. Verified by the excerpt: the dashboard, its name, the data path, and an ACF Pro active-installs graph. Not verified by it: payload contents, paid-plugin visibility mechanics, access, consent, retention, and the 24-hour statement. ## 📖 Main content **What kind of source this is.** The thread is advocacy-adjacent commentary. Storey's earlier post (read here from a local text extraction, not fetched) argues that WordPress sends too much data to WordPress.org without consent, and describes a counter-plugin Storey published to strip that data. The thread continues that argument using newly public testimony. Neither the thread nor the earlier post discloses a commercial interest in the captured text. Storey's position is visible: the earlier post says it no longer considers the WordPress.org repository trustworthy. **What the thread claims, in order.** - ¶0: Abrahamson's previously sealed testimony went online yesterday, readers should read it, and Abrahamson is roughly the head of IT and infrastructure at Automattic. - ¶1 and ¶2: A year-earlier post described the plugins API. It "calls home" a few times a day with all plugins, including private and paid ones, and the site name, so even an unlaunched site would leak by design. The ¶2 link points to that post. - ¶3: The open question was what WordPress.org does with this data. Per the testimony, it becomes the Mission Control dashboard, anonymized but stored in a database. - ¶4 and ¶5: Abrahamson was asked about ACF Pro on the dashboard. ACF Pro is a paid plugin outside the repository, so Storey reads the testimony as saying install information for non-.org plugins is in the dashboard and viewable at will. The ¶5 link points to the excerpt. - ¶6: Storey calls this competitive information on every paid plugin or theme, says nobody opted in, and says WordPress can be installed without a .org account. - ¶7: Matt reportedly testified that only some data existed for 24 hours and was then destroyed. Storey does not see how that holds if the data is aggregated for all time, and says the trial will show. **Claim-by-claim check against the excerpt.** | Thread claim | Layer | What the excerpt shows | |---|---|---| | Testimony went online "yesterday" (¶0) | Framing | Header: Document 419, filed 09/30/26. The caption says refiled pursuant to court order at Dkt. 381, and page 5 carries a CONFIDENTIAL stamp. The excerpt does not itself describe the sealing history. | | Abrahamson heads IT and infrastructure (¶0) | (b) | The excerpt does not show a title. It shows a 30(b)(6) deposition on behalf of Automattic Inc., December 19, 2025. | | Plugins API calls home a few times a day (¶1) | (b), partly (c) | Transcript sheet for pages 26-29: asked about a phone-home function, the witness says WordPress sites by default check the WordPress.org API for updates, "I believe" every 12 hours, to tell users about available updates. Objections (form, beyond the scope) appear. | | Payload is a full plugin list, including private and paid, plus site name (¶1) | (b) | The excerpt does not show it. The question "what information is sent" is the last readable question on that sheet and is cut off. The payload claim rests on Storey's earlier post (see below). | | Data becomes the MC Dashboard, MC = Mission Control (¶3) | (a) | Shown. Page 607: MC.WordPress.org is a dashboard showing some statistics about WordPress.org. Page 608: plugin data is powered by calls to API.WordPress.org, and MC stands for Mission Control. Page 609: MC is a website that reads from several sources, not itself a database. | | Data is anonymized but stored in a database (¶3) | (a) | Shown by the witness's words on page 608: a script collects the data, anonymizes it, aggregates it and stores it in a database, then named as something like "Stats." The excerpt does not show how anonymization works or how long data is kept. | | Abrahamson was asked about ACF Pro on the dashboard (¶4) | (a) | Shown. Pages 607 and 609: Exhibit 44 is titled Advanced Custom Fields Pro, and the witness agrees the graph shows active installs of ACF Pro that WordPress.org knows about. | | ACF Pro is paid and not served from the .org repository (¶4) | (b) | The excerpt does not show it. | | Install information for non-.org plugins is in the dashboard and viewable at will (¶4) | (b) | Not established. The examiner's question on page 609 about which ACF Pro instances WordPress.org knows about is the last readable question and has no answer in the excerpt. Nothing shows who can view the dashboard. Storey hedges this reading. | | Competitive information on every paid plugin or theme (¶6) | (b) | The excerpt shows one plugin's chart. Exhibits 45 to 47 are also from MC.WordPress.org, but their contents are not in the excerpt. Themes are not mentioned. | | Nobody opted in; buried in legal text; WordPress installs without a .org account (¶6) | (b) | The excerpt does not show it. It says only that the update check runs "by default." | | Matt testified data was kept 24 hours then destroyed (¶7) | (a) | The excerpt does not show it. It contains no testimony by Matt. The only hour figures are the 12-hour update-check interval and the tracker crawler's schedule (every few hours or once a day). | | That statement conflicts with all-time aggregation (¶7) | (b) | Not established. Raw requests and anonymized aggregates may be different datasets. The excerpt shows an aggregate store but not raw-data retention. Counsel's question on page 609 refers to a graph of installs over time, which the witness did not dispute. | **What Storey's earlier post adds, and its limits.** The earlier post reports reading the WordPress code and capturing traffic with a packet sniffer on a WordPress 6.6 install. It reports that the update-check requests carry the site URL in the User-Agent header, and header data for every installed plugin and theme, including ones from outside WordPress.org and ones declaring an Update URI. It also describes core update-check fields and two non-standard headers. This is the only source in the file set for the payload claim in ¶1. It is a single author's observation of one version. The captured text has no date. The task metadata calls it a 2024 post, and its references to WordPress 6.6 and the tracker's launch fit that. The thread says "last year," which does not match a 2024 date for a 2026 post. Whether current versions send the same fields is not addressed by either file. **Other items in the excerpt that the thread does not claim.** - Pages 26-28: the witness says the WP Engine tracker crawler started from third-party domain data sources, not from WordPress.org data, then checked DNS records, HTTP headers and some HTML at intervals. The request for the tracker came from Matt Mullenweg, and the stated purpose was to show the community that WP Engine customers were leaving. The earlier post speculated that API data might have fed the tracker. This sworn answer says no. It is a party's answer and does not settle the point. - Page 606: a short exchange about search results for a custom-fields plugin (SCF), where the witness says it has the same ranking rules and weights as any other plugin. It is unrelated to data collection. **Uncertain or contested.** - Which fields reach the Stats database is not in the excerpt. - The mechanism linking paid-plugin installs to the update payload is the thread's inference. - The excerpt is two-column text extracted from a PDF, so questions and answers interleave around separators. Page labels for the lower half of the first sheet were not captured, so the 12-hour answer is placed on the sheet for pages 26-29, most likely page 29. - Objections of "outside the scope" recur on pages 607-609. What they mean for how a court treats those answers is a legal question this analysis does not address. ## 🗒️ Notes #### 📄 ¶0 Framing and the call to read the testimony - The thread says Abrahamson's previously sealed testimony went online the day before and urges people to read it. - It describes Abrahamson as head of IT and infrastructure at Automattic. The excerpt does not show a title. - The filing date in the excerpt (2026-09-30) matches "yesterday" for a 2026-10-01 post. #### 📄 ¶1-¶2 The earlier post and the payload claim - Storey recalls a prior post saying the plugins API calls home a few times a day and submits all plugins, including private and third-party paid ones, plus the site name. - Storey infers that an unlaunched private site would leak data back to WordPress.org by design. - The ¶2 link is a t.co short link to Storey's earlier post on the WordPress API. The excerpt shows a 12-hour default check interval, not the payload. #### 📄 ¶3 What the data becomes - Storey says the old question was what WordPress.org does with the data, and the hopeful answer was version statistics such as PHP versions. - Per the thread, the testimony says it feeds the MC Dashboard, anonymized but stored in a database. - The excerpt supports this on page 608, with the nuance that MC reads from the Stats database among other sources. #### 📄 ¶4-¶5 ACF Pro and the dashboard - The thread says Abrahamson was asked deliberate questions about ACF Pro and that ACF Pro is a paid plugin outside the repository. - Storey's reading, hedged: install information for non-.org plugins is in the dashboard and viewable at will. - The ¶5 link goes to Dkt. 419 Exhibit 2. The excerpt shows an ACF Pro active-installs graph and an unanswered question about which instances are known. #### 📄 ¶6 Competitive information and consent - Storey calls the dashboard competitive information on every paid plugin or theme in the industry. - Storey says nobody opted in as far as Storey knows, that the collection is buried in WordPress.org legal text, and that WordPress installs without a .org account, so no agreement was needed. - The excerpt contains no consent testimony and no theme data. #### 📄 ¶7 The 24-hour statement - Storey says Matt testified that some data lived 24 hours and was destroyed. - Storey guesses this could mean web access logs, then argues that aggregation for all time would make the statement hard to reconcile, and defers to the trial. - The excerpt has no such testimony. The hedging in this paragraph is the strongest of the thread. ## 📚 References I read local text extractions of both linked sources (read-only, not fetched live). The link list for the thread has two entries. - [Duane Storey's earlier post on the WordPress API](https://duanestorey.com/posts/down-the-rabbit-hole-a-deep-look-at-the-wordpress-api): the t.co link in ¶2, which the thread calls "a post last year" in ¶1. It is the source for the payload claim. - [Dkt. 419, Exhibit 2, Abrahamson 30(b)(6) deposition](https://storage.courtlistener.com/recap/gov.uscourts.cand.437474/gov.uscourts.cand.437474.419.0.pdf): the t.co link in ¶5. It is the primary source for everything attributed to the testimony here, and I used deposition pages 26-29 and 606-609 only. - [The thread](https://x.com/DuaneStorey/status/2105556221990187368): the subject of this analysis. - Claims with no link in the captured markup: Matt's 24-hour statement (¶7), ACF Pro's paid and outside-repository status (¶4), the legal-text and no-account consent points (¶6), and Abrahamson's title (¶0). The link at ¶5 covers the Abrahamson testimony only. ## 🗣️ Paraphrase Storey says Abrahamson's newly public testimony is worth reading. In an earlier post, Storey described the update call that WordPress sites make to WordPress.org: it lists every plugin, even private and paid ones, and includes the site's name, so unreleased sites would leak too. What WordPress.org does with that data had been unclear. Per the thread, the testimony says the data feeds a dashboard called Mission Control, in anonymized form, stored in a database. Storey adds that Abrahamson was asked about ACF Pro, a paid plugin not hosted on WordPress.org. Storey reads that as meaning install data for such plugins is in the dashboard and can be viewed whenever someone wants. Storey sees that as industry-wide competitive information gathered without opt-in, and notes that Matt reportedly said some data lasted only 24 hours, which Storey finds hard to square with all-time aggregation. Storey expects the trial to address it. ## 📰 Newsletter **A new court exhibit gives the WordPress.org update API its first sworn description.** On September 30, a deposition excerpt from WP Engine v. Automattic went public (Dkt. 419), and developer Duane Storey pointed at it the next day. The excerpt has Barry Abrahamson, testifying for Automattic, say that plugin data on the Mission Control dashboard comes from calls to API.WordPress.org, and that a script anonymizes, aggregates and stores it in a database the witness thinks is called Stats. Exhibit 44 is an ACF Pro active-installs graph. Read it with two hats on. The excerpt confirms the dashboard and the data path. It does not show what the update call contains, whether paid-plugin installs reach the dashboard through that call, who can see it, or anything about consent. Those come from Storey's inferences and a 2024 post about one WordPress 6.6 install. The 24-hour statement attributed to Matt is not in the excerpt. If you maintain a plugin with an Update URI, this is a good week to capture your own update-check request and see what leaves your site. Links: [the thread](https://x.com/DuaneStorey/status/2105556221990187368), [Storey's earlier post](https://duanestorey.com/posts/down-the-rabbit-hole-a-deep-look-at-the-wordpress-api), [Dkt. 419 Exhibit 2](https://storage.courtlistener.com/recap/gov.uscourts.cand.437474/gov.uscourts.cand.437474.419.0.pdf). This is commentary on a court filing, not legal advice. ## ✅ Action items Scope note: items below tie only to data-collection transparency, opt-in and consent, and plugin-API privacy, and only where the thread or the excerpt supports them. Where neither does, the line says so. #### DevRel - Developer advocacy: in any talk or post on this topic, label each claim as testimony, inference, or code-level fact, and cite the deposition page. The ¶1 payload claim is code-level (earlier post), the dashboard path is testimony (pages 607-609), and the competitive-information claim (¶6) is inference. - Education: run a short session on reading a deposition excerpt as a primary source: page and line cites, who objects, what "outside the scope" signals, and why an excerpt can cut off mid-question. State that it is not legal advice. - Developer experience: publish a reproducible capture script for the update-check request on current WordPress. The excerpt cuts off at the question on what information is sent, and the 2024 post covers only one version. - Developer marketing: don't repeat "competitive information on every paid plugin or theme" as established. The excerpt shows one plugin's graph. - Community management: in discussion threads, ask contributors to tag claims (a), (b) or (c) and to discuss the data flows, not the witness. - Internal/external/cross-project: ask the Meta and Core teams for a written description of which fields the Stats store keeps, how anonymization works and the retention period. The excerpt gives the verbs (collect, anonymize, aggregate, store), not the details. #### OSPO - Policy & Governance: draft a disclosure policy for any project-run service that receives site telemetry: fields, purpose, retention, access, opt-in or opt-out. The thread's core complaint (¶6) is the absence of such a statement as Storey sees it. - License Compliance: no direct action from this source. - Security Management: treat site URL plus plugin inventory as sensitive data when it leaves your network. ¶1 raises unlaunched private sites. Add an egress review for pre-launch sites. - Software Inventory: record, per site, the outbound update endpoints and which plugins use a non-.org update source, so you know what each check could reveal. - Developer Support: give teams working on unreleased client sites guidance on update-check traffic, with legal review for confidentiality terms. Not legal advice. - Community Engagement: if your organization funds upstream work, request a public data-handling note for api.wordpress.org as part of that relationship. - Strategic Alignment: add one KPI: the share of third-party APIs your WordPress fleet calls that have a published data-flow description. #### Community - Maintainers: maintainers of paid or private plugins can capture an update-check request and list which header fields appear. That list tells their customers what a check reveals. The earlier post reports headers being sent even with an Update URI, as of WordPress 6.6. - Contributors: a first-issue candidate is repeating the 2024 capture on a current core release and posting the field list. - Sponsors: fund an independent write-up of the update-API data flow that cites the full transcript, not an excerpt. - Ecosystem: agree on a shared vocabulary for "behavior by design" versus "privacy defect" before any coordinated disclosure of a data-flow issue. #### WordPress - Core: compare the update-check fields against the witness's stated purpose (telling users about updates, page 29 sheet) as a data-minimization review. The earlier post lists the fields. - Core Performance: none from this source. - Core AI: none from this source. - **Core Program Team:** track this as a cross-team item among Core, Meta, Plugins, Documentation and Support so the community gets one factual answer. - Mobile: none from this source. - Playground: build a Blueprint that logs outbound update-check requests so people can inspect payloads on a throwaway site. Supported by the thread's ¶1 concern about unlaunched sites. - Community: none from this source. - Training: add a lesson on what outbound HTTP calls from WordPress reveal about a site. - Marketing: none. Avoid amplifying the unverified competitive-information claim. - Support: prepare a plain reply to "does WordPress send my plugin list?" that states only what is documented, notes the witness's belief in a 12-hour default check, and routes payload questions to a Meta contact. - Design: no direct action. Nearest relevance: if a disclosure or opt-in is ever added, the admin interface that presents it. - Documentation: publish a page listing what each update-check request transmits and what is stored, with unknowns marked as unknown. It fills the gap the excerpt leaves. - Photos: none from this source. - TV: none from this source. - Polyglots: none now. Any disclosure text would need translation. - Accessibility: none now. Any consent interface would need WCAG review. - Meta: publish a data-handling note for api.wordpress.org covering fields stored, anonymization method, retention, and who can view the Mission Control dashboard. The excerpt shows none of those last three. - CLI: none from this source. - Hosting: tell customers whether the host filters or leaves default update checks on. The excerpt says the check runs by default. - Tide: none from this source. - Openverse: none from this source. - Themes: none. The excerpt shows no theme data, although ¶6 extends the claim to themes. - Plugins: the earlier post quotes Plugin Guideline 7 on explicit consent for contacting external servers and asks for the same standard for core. The review team can state whether and how that guideline applies to core services. The guideline text is not in the thread or the excerpt. #### The WPOCC - Programs: consider a small grant for an independent privacy review of the update API data flow, published with the full record. - Projects: a documentation sprint on update-check data, using the Documentation action above. - Funding experiments: none from this source. ### FAIR - Technical independence: compare what a FAIR client sends when it checks for updates against the field list in the earlier post. A decentralized check could expose less to a central party, but neither the thread nor the excerpt tests that. - Policies and covenants: write down what an update service logs, anonymizes and keeps, and for how long. - Productized governance artifacts: add scorecard rows for "telemetry disclosed," "retention stated" and "opt-in available" to any operator agreement. ## 🧪 Hypotheses 1. The omitted pages of the Abrahamson transcript, after the question on what information is sent, state which fields reach the Stats database, and that list is narrower than the full plugin headers described in the earlier post. 2. A current WordPress core release still sends the site URL in the User-Agent header and header data for plugins that declare a non-.org Update URI. 3. The ACF Pro active-installs figure in the dashboard comes from update-check traffic, not from another source such as crawling or vendor-supplied counts. 4. Raw update-check requests are retained for a short window while anonymized aggregates persist, which would let the 24-hour statement and the aggregate store both be accurate. 5. Adding a visible disclosure and opt-out to the install flow changes the share of sites that stop sending plugin inventories to a measurable degree. ## 📊 Methodology - **H1.** Retrieve the complete Abrahamson transcript from the docket, or file a public-records style request through counsel for the omitted pages. Read the pages after transcript pages 29 and 609. Tabulate each field named as sent or stored, with page and line. - **H2.** On a fresh install of the current release, route update checks through a local proxy over http in a test environment, capture the headers and body, and diff them against the field list in the earlier post. Repeat with a plugin that declares an Update URI. Publish the capture. - **H3.** Ask the dashboard's operators, or read the Stats collection script if published, for the source of the ACF Pro count. Alternatively compare the graph with the number of sites reporting ACF Pro in an instrumented test fleet. - **H4.** Read the 24-hour testimony in context (not in the excerpt) and separate datasets: raw logs, update-check payloads, aggregates. Interview the data owners in discovery material if public. - **H5.** A controlled test across matched test sites: one arm sees a disclosure and opt-out, the control does not. Measure opt-out rate and plugin-inventory transmissions over 30 days. - **Controls throughout.** Record the WordPress version, PHP version and plugin set for every capture. Separate quotes from testimony from the author's inferences before counting any finding. ## ❓ Questions - What did the witness answer to the question about what information is sent on the update check, and how do the fields compare with the earlier post's list? - What does anonymization remove before storage: the site URL, the IP address, both, or neither? - How long are raw update-check requests kept, and how long is the aggregate Stats data kept? - How does the dashboard know about ACF Pro installs, and which instances does WordPress.org know about, which is the question that has no answer in the excerpt? - Who can view the Mission Control dashboard, and under what policy? - Where did Matt's 24-hour statement come from, which docket entry holds it, and which dataset does it describe? - Does the WordPress.org privacy policy cover API traffic from installed sites, and what text addresses consent? - Do current WordPress releases send the same fields as the release in the earlier post? ## 🔮 Future research - **Full-record reading.** The excerpt is 8 transcript pages out of a deposition scheduled from 10:34 a.m. to 7:08 p.m.. A page-cited summary of the full record, once public, would replace the inferences here. - **Retention and anonymization audit.** No source in the file set gives a retention period or an anonymization method. An independent review could specify both. - **Update-check data minimization.** Compare what update services in other ecosystems send against the stated purpose of finding updates. - **Consent models for core services.** Research how plugin directory consent rules and core behavior differ, using the plugin guideline text the earlier post cites. - **Reading commentary against filings.** A short method for checking a social thread's claims against docket text could serve many future filings. ## 💡 Implications - **Practice.** Anyone writing about this topic can tie each claim to a page cite and a layer (testimony, inference, code observation). The table in Main content is a template. - **Policy.** The excerpt says the data path exists. Whether it needs a disclosure or consent mechanism is a policy question the community can pose with evidence, and the thread supplies one view. - **Security.** Site URL plus plugin inventory identifies a site and its attack surface. The earlier post argues this for unlaunched and development sites. Egress review is a cheap control. - **Education.** Reading primary legal documents is a skill for open-source contributors, because trials now generate public technical testimony. - **Funding.** Independent privacy and data-flow reviews are fundable work. Neither source in the file set describes funding. - **Legal caution.** Nothing here concerns liability or compliance. Counsel is the right route for those questions. ## 🧠 Learning styles assessment - **Reading level estimate.** Flesch-Kincaid Grade Level 11.6 and Flesch Reading Ease 55.7, computed with a syllable-count heuristic on 417 words and 17 sentences of the thread text with links removed. Long sentences with embedded clauses drive the grade level, not vocabulary. #### 👀 Visual learners - Present: no images or charts in the captured text. The links lead to a blog post and a PDF. - Improve: a one-box data-flow diagram (site, API, script, Stats database, Mission Control) with each arrow marked as testimony or inference. #### 🔊 Aural learners - Present: the text is written conversationally, and it spells out "dot org," which reads aloud cleanly. - Improve: a 3-minute audio summary that separates what the witness said from what the author infers. #### 🗣️ Verbal learners - Present: explanations of the question ("what are they doing with this data?") and the hopeful answer. - Improve: define payload, aggregate, anonymize, 30(b)(6), and Update URI at first use. #### 🧩 Kinesthetic learners - Present: none in the thread. - Improve: add a copy-paste proxy setup so readers can capture their own update-check request and compare it with the claims. #### 🧠 Logical learners - Present: a clear chain: payload, dashboard, paid plugin, competitive use, consent, retention. - Improve: number the premises and mark which ones the excerpt supports. The table in Main content does this. #### 🧑‍🤝‍🧑 Social learners - Present: the thread invites readers to read the testimony themselves. - Improve: a moderated discussion with a rule to cite deposition page numbers. #### 🧘‍♀️ Solitary learners - Present: two primary-source links allow self-paced checking. - Improve: a self-check list, for example "Which of my installed plugins declare an Update URI?" #### 🌿 Naturalistic learners - Present: nothing explicit. - Improve: none needed for this topic. ## 📊 Accessibility assessment Judged as captured text of an X thread. Rendering, alt text and contrast are unknowable from the text file. #### Screen reader semantics - Present: eight short paragraphs in reading order. Spelled-out "WordPress dot org" avoids ambiguity for speech output. - Improve: ¶2 and ¶5 are bare t.co short links on their own lines, so a screen reader announces a code, not a destination. The sentences before them give context, which helps. WCAG 2.4.4 (Link Purpose in Context) is met only if the link is read with the preceding paragraph. #### Keyboard navigation - Present: not assessable from captured text. - Improve: X's own interface is outside this assessment. Plain text links are keyboard focusable by default. #### Contrast and readability - Present: unknowable from text. - Improve: no way to judge 1.4.3 on X. The paragraphs are short and the capture shows no all-caps or color-only emphasis. #### Text resizing and reflow - Present: plain paragraphs reflow in principle. - Improve: link cards that X may render for the t.co links were not captured, so reflow at 320 CSS pixels (1.4.10) is untested. #### Media and captions - No media referenced in the captured text. The t.co links may render as preview cards, and their alt text is unknown. #### Forms and interactions - Present: no forms in the thread text. - Improve: none for the text. #### Standards reference - Candidate gaps, each unverified: **2.4.4** (bare short links in ¶2 and ¶5), **1.1.1** (alt text for any link-card image), **1.4.10** (card reflow). These need checks on the rendered page. ## 🌍 DEIB assessment #### Cultural breadth - Present: the topic affects sites worldwide, and the thread mentions private and unlaunched sites generally. - Improve: the legal context is a U.S. federal case. A note about privacy rules in other regions would help readers outside the U.S., though the thread does not cover them. #### Inclusive language - Present: plain wording. - Improve: "calls home," "payload," "opt-in," "MC" and "ACF Pro" appear without definition. A typo in ¶6 ("ever Pro/Paid plugin") and "hosting" for "hosted" in ¶4 add friction for non-native readers. #### Neurodiversity support - Present: short paragraphs and a linear argument. - Improve: the two bare links and a long ¶6 with parentheticals raise load. Numbered claims would help. #### Representation - Present: two named people, Barry Abrahamson and Matt, and the author. - Improve: no voice from Automattic, the WordPress.org team or a privacy specialist appears in the thread. #### Psychological safety - Present: hedged language ("if I read it right," "I believe") limits overstatement about named people. - Improve: ¶7 questions a named person's reported statement without a quote or link. A cited page would let readers check it without taking sides. ## ✅ Logical validity Source type: social-media opinion and analysis by a WordPress developer who has published a critical earlier post and a counter-plugin. The thread is one-sided commentary on a party's sworn answers, where counsel's objections appear in the record. Nothing here is legal advice. #### Strong reasoning - **Pointer to the primary source, ¶0 and ¶5.** The thread tells readers to read the testimony and links it. That lets a reader check every claim. - **Marked uncertainty, ¶4 and ¶7.** "If I read it right" and the defer-to-trial ending in ¶7 flag the inference as an inference. - **Stated prior question, ¶3.** Framing the old question (what are they doing with this data) and what would count as a hopeful answer makes the testimony's relevance clear. Page 608 of the excerpt supports the path described. - **Consistent hedge on retention, ¶7.** Noting that 24 hours could refer to web logs shows the author sees that two datasets could be involved. #### Fallacies - **Missing premise in a causal chain, ¶1 to ¶4.** The thread joins a payload (earlier post, one WordPress 6.6 install), a dashboard graph for ACF Pro (testimony), and ACF Pro's paid status (not in the excerpt) to conclude that non-.org install data is viewable at will. The excerpt's question about which ACF Pro instances WordPress.org knows about has no answer in it. Fix: cite the omitted pages, or state the chain as a hypothesis. - **Hasty generalization, ¶6.** One chart for one plugin becomes competitive data on every paid plugin and theme in the industry. Fix: say what the excerpt shows (one plugin), and list what would have to be shown for the rest. - **Loaded naming, ¶6.** "Competitive information" under the heading "Mission Control" implies use for competition. The witness describes MC as a dashboard of statistics, and the excerpt shows no competitive use. Fix: separate a name from evidence of purpose. - **Argument from silence, ¶6.** "Nobody ever opted into this as far as I know" reasons from not having seen consent text. The author hedges, and the earlier post reports checking the download package and admin screens. Fix: cite the install flow, privacy policy and terms with their text. - **Equivocation on "the data," ¶7.** The 24-hour statement and the all-time aggregate may describe different datasets: raw requests versus anonymized aggregates. The thread notes web logs but then treats the statements as in tension. Fix: ask which dataset each statement covers, with page cites. - **Unsourced attribution, ¶7.** Matt's 24-hour statement has no link in the captured markup. Fix: link the transcript page or the filing. #### Tone of voice - Urgent, skeptical and conversational, with frequent hedges ("apparently," "if I read it right," "I believe," "I don't really get how"). It moves from a recommendation (¶0) to alarm over "competitive information" (¶6) to a measured wait-and-see close (¶7). ## 🛡️ DARVO analysis Not applicable to this source. DARVO describes an accused party's response to an accusation. The thread is the accusing side's commentary and contains no response by the accused. **Deny:** the only denial-like content is Matt's reported 24-hour statement in ¶7, which is secondhand and not in the excerpt. **Attack:** the thread does not attack a critic. Storey is the critic, and the earlier post and counter-plugin show that stance. **Reverse victim/offender:** no such move appears. The thread does cast the ecosystem's users and plugin businesses as the affected party. Objections that appear in the excerpt are counsel's procedural objections, not DARVO behavior. ## 🎯 Conclusion The thread's useful contribution is the pointer: a newly public exhibit, with page-level material to check. The excerpt confirms a dashboard named Mission Control, a data path from API calls through a script that anonymizes, aggregates and stores, a database called something like Stats, and an ACF Pro active-installs graph. It does not show the update payload, how paid-plugin installs are known, who views the dashboard, whether anyone consented, or Matt's 24-hour statement. The thread's larger conclusions (competitive information on every paid plugin and theme, no consent, an irreconcilable retention statement) are Storey's inferences. Several are hedged by Storey and none is established by the excerpt. This is one-sided commentary, testimony is a party's answers under questioning, and nothing here is legal advice. **Next steps for readers:** read the five pages yourself, then ask for the pages after transcript pages 29 and 609. Capture your own update-check request on a test site and compare it with the earlier post. Keep claims labeled as testimony, inference, or code observation. ## 🔄 Refactor Appendix — So Barry Abrahamson's previously sealed testimony in the Automattic trial... > Density: 2–5 Literature atoms (H1 pad), 0–3 Permanent candidates (H4 pad). > Emitted: 5 Literature, 2 Permanent. Resonance filter applied: Abrahamson's job title and the > ¶0 filing-date point were dropped as low-value for the privacy thread. > > Konik claim-header rules: present tense, declarative, ≤10 words, searchable, unique. > > Atomicity: one declarative sentence per atom. "and"/"also" → split. > > Tag pool: #bmf · #addendum · #xref · #articleseed · #storystem · #share · #aphorisms ### 📚 Literature Split Pad #### [H1] The update API calls home with the plugin list > [!quote] [¶1] > That API 'calls home' likely a few times a day and submits a full list of all the plugins on your site **Context & use**: - ¶1, the payload claim. The excerpt shows only the default update check (witness believes every 12 hours), not the payload. The payload comes from Storey's earlier post, a single WordPress 6.6 observation. - Use as the claim to test with a fresh capture on a current release. **Tags**: #xref #share <!-- atomicity: 1 idea ✓ --> #### [H2] Testimony describes anonymized data stored in a database > [!quote] [¶3] > This data is "anonymized", apparently, but stored in a database. **Context & use**: - ¶3. Matches the witness's description on deposition page 608: a script collects, anonymizes, aggregates and stores the data. - The scare quotes are Storey's skepticism. The excerpt does not show the anonymization method or retention. **Tags**: #xref <!-- atomicity: 1 idea ✓ --> #### [H3] The thread infers non-.org plugin installs are in the dashboard > [!quote] [¶4] > if I read it right, is saying that install information, including plugins not hosting by WordPress dot org, is part of their MC Dashboard **Context & use**: - ¶4, the central inference. The excerpt shows an ACF Pro active-installs graph but not ACF Pro's paid status or how its installs are known. - The page 609 question on which ACF Pro instances WordPress.org knows about has no answer in the excerpt. Test this link first. **Tags**: #xref #articleseed <!-- atomicity: 1 idea ✓ --> #### [H4] The thread asserts no one opted in > [!quote] [¶6] > Nobody ever opted into this as far as I know **Context & use**: - ¶6, a hedged claim from silence. The excerpt says only that the update check runs by default and contains no consent testimony. - Maps to the opt-in and consent action items for Meta, Plugins and Documentation. **Tags**: #xref #share <!-- atomicity: 1 idea ✓ --> #### [H5] The thread doubts the 24-hour statement > [!quote] [¶7] > I don't really get how Matt's statement can be true as it was given. **Context & use**: - ¶7. The statement is not in the excerpt and has no link in the captured markup. The tension depends on whether the 24-hour data and the aggregate store are the same dataset. - Storey ends by deferring to the trial, which is the right posture. **Tags**: #xref #aphorisms <!-- atomicity: 1 idea ✓ --> ### 🧠 Atomic Split Pad #### [P1] Cite the layer for every claim **Claim** (one sentence, Courtney's voice): A commentary thread about testimony earns trust only when each claim carries a page cite and a label saying whether it is testimony, inference, or an outside observation. **Evidence pointer**: [[#H1]] · [[#H3]] **Scope & conditions**: Holds for commentary on court filings and other partial primary sources. Breaks when the primary source is complete and short enough to read directly. In this case the excerpt supports the dashboard claims and not the payload or paid-plugin claims. **Links**: - [[Primary source over commentary]] — because extends - [[Source triangulation]] — because applies-in legal filings - [[Opinion thread versus evidence]] — because contrasts on whether each claim has a cite <!-- atomicity: 1 idea ✓ --> #### [P2] A data-flow claim needs every link in the chain **Claim** (one sentence, Courtney's voice): Showing that a payload exists and that a dashboard exists does not show that the payload feeds the dashboard. **Evidence pointer**: [[#H2]] · [[#H3]] **Scope & conditions**: Applies to telemetry and privacy claims. Breaks when a source states the link outright. The excerpt names API calls as the dashboard's plugin data source on page 608 but not which fields or which plugins. **Links**: - [[Plugin update API telemetry]] — because evidence-for - [[Opt-in consent for data collection]] — because applies-in plugin and core services - [[Data minimization]] — because extends <!-- atomicity: 1 idea ✓ --> ### ✏️ Fleeting Queue - [F1] Find the transcript pages after deposition pages 29 and 609 on the CourtListener docket: https://storage.courtlistener.com/recap/gov.uscourts.cand.437474/gov.uscourts.cand.437474.419.0.pdf #fleeting #inbox - [F2] Open question: where is Matt's 24-hour statement filed, and which dataset does it describe? ¶7 gives no link #fleeting #inbox - [F3] Article seed: "What the update API sends, field by field, on current WordPress" #fleeting #inbox #articleseed - [F4] Compare the update-check field list with what FAIR clients send when checking for updates #fleeting #inbox - [F5] Check how Plugin Guideline 7 on consent applies to core services, citing the guideline text #fleeting #inbox ### → Things 3 (max 2 actions) - [ ] Capture an update-check request on current WordPress via a local proxy and diff it against the 2024 field list, plugin API privacy, 45 min #things - [ ] Look up the docket for the Abrahamson transcript pages after 29 and 609 and the Matt 24-hour testimony, WP Engine v. Automattic reading #things <!-- deep-read:sections end --> 📄 **Full text:** [[Full Document Contents/Tweets/So Barry Abrahamson's Previously Sealed Testimony in the Automattic Trial....md|So Barry Abrahamson's Previously Sealed Testimony in the Automattic Trial... by Duane Storey]] ## Highlights - I did a post last year talking about all the data WordPress dot org has the ability to capture via their plugins API. That API 'calls home' likely a few times a day and submits a full list of all the plugins on your site, even private and third-party paid ones. It also includes as part of the payload the site name, so a private site not even launched yet would likely leak data by design back to WordPress dot org. ([View Highlight](https://read.readwise.io/read/01m3vt39memy67ga8xvhpexvqv)) - Note: [H1] The update API calls home with the plugin list - Tags: atom/literature/h1 - One of the questions has always been "what are they doing with this data?" The hopeful answer was always that they were just using it to understand what versions of PHP etc people were using etc. It turns out, according to Barry's testimony, that this gets turned into their "MC Dashboard", where MC apparently stands for Mission Control. This data is "anonymized", apparently, but stored in a database. ([View Highlight](https://read.readwise.io/read/01m3vt3c7gkp88mmm43aq85e5d)) - Note: [H2] Testimony describes anonymized data stored in a database - Tags: atom/literature/h2 - In his testimony he's asked deliberate questions about the ACF Pro part of that dashboard. ACF Pro is not served from the WordPress dot org repository, it's a paid plugin. It would be included in that data payload I talked about in my post. So Barry's testimony, if I read it right, is saying that install information, including plugins not hosting by WordPress dot org, is part of their MC Dashboard and can be viewed at will. ([View Highlight](https://read.readwise.io/read/01m3vt3emns51cvs4pabg44kvq)) - Note: [H3] The thread infers non-.org plugin installs are in the dashboard - Tags: atom/literature/h3 - So basically they have competitive information on basically ever Pro/Paid plugin or Theme the entire industry, sitting in a dashboard under the heading "Mission Control". Nobody ever opted into this as far as I know, this is just buried in the legal verbiage on WordPress dot org I believe that they collect this at all (which is strange because you can install WordPress itself without needing a dot org account, which means you never had to agree to this). ([View Highlight](https://read.readwise.io/read/01m3vt3h140f1em3enn4wbbajr)) - Note: [H4] The thread asserts no one opted in - Tags: atom/literature/h3 - Matt also. testified at some point that they only had some data for 24 hours and then it was destroyed. Presumably that could have probably meant web access logs, but if they take all this data anyways and aggregate it in MC Dashboard for all time, which apparently Barry's testimony supports, then I don't really get how Matt's statement can be true as it was given. But I guess we'll see during the trial, because I'm sure that point will come up. ([View Highlight](https://read.readwise.io/read/01m3vt3k93ryhzz5wmf6fwyn45)) - Note: [H5] The thread doubts the 24-hour statement - Tags: atom/literature/h3