2IA.org Passive Security, Privacy, and Public-Exposure Audit

Full report

On this page

Executive Summary and Key Judgments

This audit reviewed the public surface of https://2ia.org/ using only passive, ordinary public observation. The reviewed pages consistently present 2IA as an information-only archive that emphasizes privacy minimization, local assets, server-side rendering, no third-party analytics, no external fonts, no browser-side feed collection on core pages, and no active newsletter, donation, or volunteer intake forms. Those statements are materially supported by the site’s own public Privacy Policy, About page, and the status pages for newsletter, support, and volunteer intake.

The strongest confirmed privacy issue is not covert tracking but intentional public exposure of personal contact data on the Contact page. 2IA publicly publishes a full legal name, direct email address, telephone number, a personal website link, and a residential mailing address, and the page explicitly says the residential address is published at the individual’s request. That is not evidence of an accidental breach, but it materially enlarges discoverability, spam, harassment, stalking, and doxxing risk for the listed individual. The exposure is amplified because the contact page title and summary are indexed publicly.

The most notable security-relevant finding concerns the Daily Brief ecosystem. On 2IA itself, the Daily Brief page says it is delivered from a same-origin local snapshot, that readers’ browsers do not contact the upstream publisher during page load, and that synchronization uses an upstream API index with conditional requests and last-good retention. That design is privacy-positive. However, the publicly linked upstream sister site, internationalintelligence.org, also exposes a public status JSON with publication-health details, retry timing, counts, and error codes, and a public Daily Brief page that visibly includes what appear to be operator-style publication controls such as “Check and generate now” and a one-time backfill path, while also disclosing that “The archive, storage, and OpenAI key are ready.” Those disclosures are not on the 2ia.org origin itself, but they are publicly linked from the 2IA Daily Brief experience and are relevant to the Daily Brief implementation boundary requested in this assignment.

The site also demonstrates several strong privacy practices: no account requirement for reading, no application cookie requirement stated for core pages, only minimal local-storage use for interface preference, explicit warnings not to send secrets or unnecessary personal information, a correction process that asks users to share only the minimum needed, and inactive collection routes for email signup, donations, and volunteer intake.

Because this was a strictly passive public-web review and the available retrieval environment did not expose raw TLS or HTTP response headers, several transport and header controls could not be authoritatively verified in this pass. In particular, certificate details, HSTS, CSP, frame-ancestors or X-Frame-Options, Referrer-Policy, Permissions-Policy, and CORS response behavior remain unverified rather than failed. The report therefore distinguishes rigorously between confirmed observations and inference.

Scope, Ethics, and Research Metadata

Testing boundary. This review used only public browsing and passive inspection techniques: public search results, public page retrieval, public linked JSON/HTML, and ordinary observation of page content and publicly exposed routes. No authentication was attempted. No brute forcing, path spraying, malicious inputs, payload injection, denial-of-service behavior, credential testing, or unauthorized access was performed.

Research date and vantage. Research was performed on July 26, 2026. Multiple pages reviewed on both 2IA and the linked Daily Brief upstream also displayed review or server dates of July 26, 2026, which aligns with the audit date. The browser/runtime available through the hosted public-web retrieval tool did not disclose a full browser user-agent, exact egress IP, or egress region, so those items cannot be recorded precisely from this environment. That limitation matters especially for transport- and network-layer observations.

Representative public URLs reviewed. At minimum, the audit reviewed the homepage, Privacy Policy, Contact page, Corrections and Right of Reply, Newsletter Status, Support Status, Volunteer Status, Daily Brief on 2IA, and linked Daily Brief/API pages on the sister domain that 2IA itself references as part of the Daily Brief implementation. Search engine snippets also confirmed public indexing of several key pages.

Important limitations. This environment did not provide raw response-header capture for the target origin, and direct safe-open access to robots.txt and sitemap.xml was not available from the hosted retrieval tool. A same-origin Atom endpoint was discoverable from 2IA’s own Daily Brief page, but the tool could not render its application/atom+xml response body. Accordingly, this report does not claim verified contents for robots.txt, sitemap.xml, or the Atom feed body.

Transport and Security Header Findings

Finding: HTTPS is in active use and HTTP appears to resolve to the HTTPS site. URL: http://2ia.org and https://2ia.org/ Observation: Opening the HTTP URL resolved to the HTTPS homepage, whose final rendered URL is https://2ia.org/. That is consistent with HTTP-to-HTTPS redirection or equivalent HTTPS enforcement at the edge. Evidence: The public retrieval of http://2ia.org returned the same HTTPS homepage content and displayed the final HTTPS URL. Risk: If HTTPS is enforced consistently, downgrade exposure is reduced. Without raw headers, I could not determine whether the redirect is permanent, whether all paths behave the same way, or whether HSTS further hardens the transition. Affected users or data: All visitors. Severity: LOW for the confirmed fact, because the observed behavior is positive. Recommendation: Keep HTTP-to-HTTPS enforcement universal, preferably with a permanent redirect and HSTS once confirmed safe for the domain. Authorized internal testing needed for full confirmation: Yes, if the operator wants authoritative confirmation for status codes, HSTS, and path-wide behavior.

Finding: Daily Brief delivery is same-origin by design on 2IA pages. URL: https://2ia.org/daily-brief/ and homepage Daily Brief section Observation: 2IA states that the Daily Brief is delivered through a private same-origin snapshot, that the server starts with the upstream API index, and that readers’ browsers do not contact the upstream publisher during page load. The site also states that conditional requests, atomic snapshots, and last-good retention protect against replacement of a valid edition with a partial or failed upstream response. Evidence: The Daily Brief page explicitly says, “Readers receive a same-origin snapshot. Their browser does not contact the upstream publisher during page load,” and the homepage echoes that the brief is “delivered from a privacy-preserving local snapshot.” Risk: This reduces cross-origin reader leakage and is a strong privacy pattern. If the implementation matches the public description, it materially limits browser-side exposure to the upstream publisher. Affected users or data: Daily Brief readers. Severity: INFORMATIONAL and positive. Recommendation: Preserve this model and publish a concise technical transparency note with actual current header values, feed/cache policy, and a statement about whether any exceptions exist. Authorized internal testing needed for full confirmation: Yes, to verify network traces and implementation fidelity.

Finding: Raw security-header verification was not possible in this passive pass. URL: Representative pages on https://2ia.org/ Observation: I could not authoritatively verify certificate validity details, HSTS, Content-Security-Policy, frame-ancestors or X-Frame-Options, X-Content-Type-Options, Referrer-Policy, Permissions-Policy, Access-Control-Allow-Origin, cache directives, or other response headers because the available public retrieval tooling did not expose them directly for the target origin. The same limitation prevented direct review of robots.txt and sitemap.xml content. Evidence: Direct safe-open attempts for robots.txt and sitemap.xml were blocked by the hosted retrieval tool, and no raw header view was available in returned page content. Risk: These controls might be correctly configured, partially configured, or absent; this audit cannot responsibly assert any of those states. Affected users or data: All visitors. Severity: INFORMATIONAL for this report, because this is an evidence gap rather than a confirmed weakness. Recommendation: In a passive retest from a standard browser or header-inspection tool, explicitly capture the current values for TLS certificate details, HSTS, CSP, X-Content-Type-Options, Referrer-Policy, Permissions-Policy, framing policy, cache headers, MIME types, and CORS response behavior on the homepage, Privacy Policy, Contact page, search results, and Daily Brief. Authorized internal testing needed for full confirmation: No for ordinary header capture; a standard passive browser session is sufficient.

Privacy Surface, Third Parties, and Client Storage

Finding: Core pages publicly state that they avoid third-party analytics, advertising trackers, external fonts, session replay, heatmaps, and browser-side feed calls. URL: https://2ia.org/privacy-policy/ and https://2ia.org/about/ Observation: The site’s public privacy documentation is unusually specific. It states that core pages use local assets and server-side rendering, and that the application does not add third-party analytics, advertising trackers, external web fonts, session replay, behavioral heatmaps, or browser-side feed calls. The About page repeats the same privacy-forward claim. Evidence: The Privacy Policy states these practices in plain language, and the About page separately reiterates that core pages use local assets and server-side rendering without third-party analytics, external fonts, browser-side feed collection, or unnecessary cookies. Risk: If accurate, this sharply reduces reader telemetry, third-party request leakage, cross-site profiling, and dependency sprawl. Affected users or data: All readers. Severity: INFORMATIONAL and positive. Recommendation: Preserve the design and periodically publish independent third-party verification snapshots of page-load requests and cookies, because the claim is central to the site’s trust posture. Authorized internal testing needed for full confirmation: No; passive browser-network capture would be enough.

Finding: No page-load third-party domains were confirmed on core 2IA pages from public content, but cross-origin destinations are publicly exposed for user-initiated navigation. URL: Homepage, Contact page, Daily Brief page Observation: Based on the site’s own statements and page renderings, I did not confirm any core-page automatic third-party telemetry or feed calls. The clearly exposed cross-origin destinations I did observe are internationalintelligence.org for the Daily Brief/upstream reading path and mikekappel.com for the published personal/professional profile link. The contact email uses the ns12.com domain, but the Privacy Policy says clicking email links opens the visitor’s own mail application and that the web application does not capture the message. Evidence: The homepage and Daily Brief page both link to the upstream Daily Brief at internationalintelligence.org, and the Contact page links to mikekappel.com. The Privacy Policy separately explains that email interactions happen through the user’s mail application rather than through a captured on-site message form. Risk: Cross-origin exposure appears limited and mostly user-triggered rather than automatic. That is materially better for privacy than embedded analytics, fonts, or social widgets. Affected users or data: Readers who click through to external destinations. Severity: LOW. Recommendation: Keep external links clearly labeled as leaving the origin, and consider rel="noreferrer" or equivalent if not already present once response/source inspection is performed. Authorized internal testing needed for full confirmation: No for passive browser-network confirmation; yes only if the operator wants source-level attestation.

Finding: Cookie and storage collection appears intentionally minimal, with only possible local preference storage publicly disclosed. URL: https://2ia.org/privacy-policy/ and homepage wizard Observation: The Privacy Policy states that no login or application cookie is required and that local storage may remember an interface preference such as dismissing a notice. The homepage’s “Who Cares Wizard” separately says selections are local-only and do not leave the browser. Evidence: The site explicitly states, “No login or application cookie is required. Local storage may remember an interface preference,” and the wizard says, “Your selections do not leave your browser.” Risk: Minimal state retention reduces unnecessary device-level persistence and data collection. The remaining residual risk is that local storage can still expose interaction state to anyone with local access to the same browser profile. Affected users or data: Device-local readers. Severity: LOW. Recommendation: Publish a small reader-facing table listing each cookie, local-storage key, and session-storage key actually used, even if the table is empty. That would make a privacy-positive posture auditable. Authorized internal testing needed for full confirmation: No for passive browser inspection.

Forms, Search, and Published Contact Data

Finding: There is no on-site contact form; ordinary contact is by direct email, phone, website, and mail. URL: https://2ia.org/contact/, https://2ia.org/privacy-policy/, https://2ia.org/corrections-and-right-of-reply/ Observation: The site does not currently expose an on-site message-submission contact form. Instead, it publishes direct contact routes and repeatedly warns that email is an ordinary channel and not a secure submission system. The Privacy Policy also says the Contact page does not use an on-site contact form or collect message content in the browser. Evidence: The Contact page publishes email, phone, personal website, and postal address; the Privacy Policy says the page “does not use an on-site contact form or collect message content in the browser”; and the Corrections page says email is an ordinary channel, not a secure submission system. Risk: This avoids form-processor leakage and browser-side capture, but it also means users can easily over-share in ordinary email unless they read the warnings. Affected users or data: People contacting the site. Severity: LOW. Recommendation: Keep the warnings prominent and consider a stronger visual block near every email link stating “ordinary contact only; do not send secrets, private personal data, or source material.” Authorized internal testing needed for full confirmation: No.

Finding: Search boxes are publicly present, but search-submission behavior could not be fully exercised in this toolchain. URL: Homepage and several internal pages Observation: A site-wide public search input is visible on the homepage, Privacy Policy, Contact, Newsletter Status, Support Status, Volunteer Status, and Daily Brief pages. However, this passive environment did not safely expose a submit workflow or resulting search URL pattern for testing with harmless queries. Evidence: Multiple public pages visibly render “Search all public 2IA pages” with an input and submit control. Risk: Search endpoints sometimes leak query strings, referers, or analytics data, but no such leakage was confirmed here. Affected users or data: Visitors using site search. Severity: INFORMATIONAL due to incomplete evidence. Recommendation: In the passive retest, perform one harmless search query and record the method, resulting URL, presence or absence of query-string persistence, and any extra network requests or storage writes. Authorized internal testing needed for full confirmation: No.

Finding: Newsletter, donation, and volunteer collection routes are publicly inactive. URL: https://2ia.org/newsletter/, https://2ia.org/support/, https://2ia.org/volunteer/ Observation: The site explicitly states that newsletter signup is not active, donation processing is not active, and volunteer intake is not active. It also says no payment processor, recurring contribution, donor account, identity-document collection, resume collection, or volunteer-profile intake is active. Evidence: Each service-status page states the inactive state in plain language and notes the absence of active collection. Risk: This materially reduces collection of sensitive or unnecessary personal information. Affected users or data: Prospective subscribers, donors, and volunteers. Severity: INFORMATIONAL and positive. Recommendation: Keep these pages live and explicit until those functions are actually implemented with documented consent, retention, and unsubscribe or deletion processes. Authorized internal testing needed for full confirmation: No.

Finding: The Contact page intentionally publishes a full legal name, email address, telephone number, personal website, and residential mailing address. URL: https://2ia.org/contact/ Observation: The Contact page identifies the public contact as Michael Joseph Kappel, publishes mike@ns12.com, (708) 230-2304, a link to MikeKappel.com, and a residential mailing address in Cicero, Illinois. The page expressly says the residential mailing address is published at Michael Kappel’s request. Evidence: The public page text exposes all of those fields directly. Risk: Even when intentional, publication of a residential address plus direct phone and email materially increases discoverability and the risk of spam, harassment, nuisance contact, real-world safety concerns, and secondary aggregation by data brokers or search engines. Affected users or data: The named individual and potentially household members. Severity: MEDIUM. Recommendation: Replace the residential address with a PO box, registered agent, mail-receiving service, or business mailing address; consider a dedicated contact mailbox and business phone number; and assess whether full legal name in the page title is strictly necessary for the site’s functional purpose. Authorized internal testing needed for full confirmation: No.

Finding: Correction handling is privacy-conscious but still relies on ordinary email. URL: https://2ia.org/corrections-and-right-of-reply/ Observation: The corrections page requests only the page URL, exact statement, explanation, proposed correction, supporting source, and optional contact information, and it explicitly tells users to share only the personal information needed. It also says email is an ordinary channel and not a secure submission system. Evidence: The operational steps and warning are stated explicitly on the public page. Risk: The minimization guidance is good, but users who ignore the warning may still send sensitive or excessive personal information over an ordinary email path outside the site’s control. Affected users or data: People submitting corrections or privacy concerns. Severity: LOW. Recommendation: Preserve the warning and add a short checklist of “do not include” items immediately adjacent to the correction email action. Authorized internal testing needed for full confirmation: No.

Public Private Boundary and Daily Brief Review

Finding: No public evidence of source code, backups, lock files, logs, or debug traces was confirmed in this pass. URL: Public surface of 2ia.org Observation: I did not confirm any publicly exposed backups, lock files, debug pages, stack traces, administrative panels, caches, or source packages on the reviewed public pages. Because this assignment forbids brute forcing and the current toolchain limited direct review of some auxiliary endpoints, this should be read as no confirmed exposure found, not as proof of absence. Risk: If such files exist elsewhere on the public surface, they may still be discoverable by search engines or ordinary linking later. Affected users or data: Site operators and readers, depending on the file type. Severity: INFORMATIONAL. Recommendation: Periodically review public indexing and linked artifacts for backup patterns, manifests, source maps, installer leftovers, and diagnostic files, and explicitly suppress publication of non-public operational artifacts. Authorized internal testing needed for full confirmation: No, but a broader passive crawl from a standard browser environment would improve assurance.

Finding: 2IA publicly documents internal Daily Brief synchronization logic and upstream API discovery. URL: https://2ia.org/daily-brief/ Observation: The 2IA Daily Brief page publicly discloses that the service is “API first,” starts at /en-US/api/, follows documented Daily Brief endpoints, accepts a response only when it contains a valid edition, refreshes every 15 minutes, and uses conditional requests, atomic snapshots, and last-good retention. Evidence: Those implementation details appear directly on the public page. Risk: Most of this is privacy-positive architecture disclosure rather than harmful exposure, but it does reveal synchronization cadence and implementation assumptions that an observer can monitor. Affected users or data: Daily Brief readers and maintainers. Severity: LOW. Recommendation: Keep high-level architectural transparency, but strip details that are not necessary for user understanding if they aid operational timing analysis. Authorized internal testing needed for full confirmation: No for the public disclosure itself; yes if the operator wants to validate actual runtime behavior.

Finding: A linked upstream public status endpoint exposes operational health, retry timing, counts, and error codes. URL: https://internationalintelligence.org/en-US/api/status/ as linked from 2IA’s Daily Brief API docs path Observation: The upstream public status JSON exposes per-source enablement booleans and a daily_brief object with today_published, latest_date, next_missing_date, missing_count, archive count, backfill flags, attempt counts, retry times, and network_error codes. It also says that “The first public page request starts the server-side generation job.” Evidence: The JSON body is directly retrievable and readable without authentication from the linked upstream path. Risk: Even though this is on the sister domain rather than 2ia.org, it is a publicly linked implementation component for the Daily Brief. The endpoint reveals operational state in enough detail for third parties to monitor outages, timing windows, missing publications, and failure modes. Affected users or data: Daily Brief maintainers, and indirectly Daily Brief readers if attackers use timing information to watch or stress public workflows. Severity: MEDIUM. Recommendation: Reduce granularity in public status responses. Keep only reader-relevant states such as “upstream unavailable” or “edition pending,” and remove precise retry times, attempt counters, and low-level error codes from public unauthenticated output. Authorized internal testing needed for full confirmation: No for the public exposure; yes to assess deeper operational impact.

Finding: A linked upstream public page visibly exposes operator-style publication controls and mentions OpenAI key readiness. URL: https://internationalintelligence.org/en-US/daily-brief/ reached from the 2IA-linked Daily Brief flow Observation: The public page shows a “Check and generate now” control, a one-time backfill section, and text stating that “The archive, storage, and OpenAI key are ready.” It also exposes current attempt counts, the next retry time, the latest available edition, missing-date counts, and a description of automatic publication behavior after 8:00 AM Central. Evidence: These controls and statements appear directly on the public Daily Brief page without any observed authentication barrier in the retrieved content. Risk: This is the most significant implementation-related concern surfaced in this audit. From public content alone, I cannot prove whether these controls are actually actionable by unauthenticated users, whether they are cosmetic, or whether server-side authorization blocks them. But their public visibility plus the operational text increases unnecessary disclosure and may indicate insufficient separation between operator and reader surfaces. Affected users or data: Daily Brief publication workflow; possibly readers if publication can be externally influenced. Severity: MEDIUM, rising to HIGH if later passive retesting confirms the controls are actionable without authorization. Recommendation: Remove operator controls from public pages, place them behind authenticated admin surfaces on a separate origin, and eliminate public references to key readiness or automation state. Authorized internal testing needed for full confirmation: Yes. Only authorized testing could determine whether the controls are actually executable by unauthenticated visitors.

Finding: The upstream API documentation is unusually transparent and claims not to expose credentials or private configuration. URL: https://internationalintelligence.org/en-US/api/ and https://internationalintelligence.org/openapi.json Observation: The published API documentation says the interfaces are public, unauthenticated, and read-only, and the OpenAPI document states that the API “does not expose credentials, private configuration, provider response bodies, or destination-owned generated files.” It also documents cache behavior and discovery endpoints, including RSS and OpenAPI. Evidence: These claims are present directly in the HTML and OpenAPI JSON. Risk: Transparent documentation is good practice. The residual issue is that public documentation combined with detailed health/status output may still expose more operational metadata than readers need. Affected users or data: API consumers and maintainers. Severity: LOW. Recommendation: Keep the read-only API docs, but narrow the separate status surface. Authorized internal testing needed for full confirmation: No for the public documentation itself.

Policy Accuracy, Confirmed Exposures, Risks, and Remediation

Privacy-policy accuracy assessment. On the specific items that were publicly reviewable, the Privacy Policy appears substantially accurate. Its claims that core pages use local assets and server-side rendering, avoid third-party analytics and external fonts, require no application cookie for reading, and keep newsletter/donation/volunteer intake inactive are all supported by the corresponding public pages. Its statement that the Contact page publishes direct email, phone, postal, and website details but does not use an on-site contact form is also supported. The strongest caveat is that transport and response-header controls were not directly inspectable in this environment, so the policy’s more general security posture cannot be fully validated from headers alone in this pass.

Confirmed exposures. The confirmed public exposures are: the intentional publication of a full legal name, direct email, telephone number, personal website, and residential mailing address on the Contact page; public indexing of the Contact page and related identity information through search results; public disclosure on 2IA of Daily Brief synchronization logic and upstream API discovery; and, on the linked upstream Daily Brief/public API environment, unauthenticated access to status JSON with operational health details and visible operator-style publication controls. None of these findings required exploitation to observe.

Potential risks labeled as inference. It is reasonable to infer that the residential address and direct phone/email combination make the contact subject more vulnerable to harassment, nuisance traffic, and real-world intimidation, even though the publication is intentional. It is also reasonable to infer that public retry times and publication-health details could help an outside observer track maintenance windows or failed publication cycles, and that public operator-style controls on the upstream Daily Brief page may reflect weak separation between reader-facing and admin-facing surfaces. These are inferences, not exploit findings, because the passive evidence does not prove real-world abuse paths or authorization flaws.

Strong privacy practices. 2IA deserves credit for several unusually explicit privacy-positive choices: no active account requirement for reading; no active newsletter, donation, or volunteer collection; explicit minimization language in corrections; warnings not to send classified, stolen, or unnecessary private information; a local-only browser wizard whose selections do not leave the browser; and a Daily Brief architecture that, by its public description, keeps readers on a same-origin local snapshot instead of making browser-side upstream requests. These are not cosmetic claims only; they are repeated across multiple public pages and form a coherent privacy model.

Prioritized remediation plan. First, remove or reduce the highest-impact personal-data exposure on the Contact page by replacing the residential address with a non-residential mailing address and, ideally, using a dedicated contact mailbox and separate public phone line. This is the clearest privacy win available on the current public surface.

Second, separate reader-facing and operator-facing Daily Brief functionality on the linked upstream system. Public pages should not expose operator-style controls, key-readiness text, or detailed retry/attempt telemetry. If a public publication-status page is required, keep it coarse and reader-focused.

Third, publish an auditable privacy-tech appendix for 2IA itself: current response headers, cookies, local-storage keys, third-party request inventory, cache policy, and feed endpoints. Because the site’s trust proposition is built around privacy-forward publishing, public technical verification would reinforce the existing policy language.

Fourth, perform a passive header-and-network retest from a standard browser environment and preserve the results in a dated transparency page. That retest should cover the homepage, Contact, Privacy Policy, search results, the local-only wizard, and Daily Brief pages, and should explicitly verify the absence or presence of third-party requests, cookies, and storage writes. This will close the main evidence gaps left by the hosted retrieval environment.

Passive retest checklist. A safe follow-up retest should, without changing the ethical boundary, record the final HTTP-to-HTTPS redirect behavior for several representative paths; capture TLS certificate details and the full response-header set; inspect browser-network requests for each representative page; log every cookie, local-storage key, and session-storage key set during ordinary page loads; submit one harmless site-search query and record the resulting URL and network requests; retrieve and review robots.txt, sitemap.xml, and the linked Atom feed; confirm whether the 2IA Daily Brief remains same-origin with no browser-side upstream fetches; and determine, from passive page behavior only, whether the linked upstream publication controls are merely visible or appear to be functionally invoked without authorization.

Overall conclusion. On the available passive evidence, 2IA’s core public site looks more privacy-aware than the average content site. The main confirmed privacy liability is the site’s intentional publication of personal contact information at a residential level of granularity, and the main security-relevant concern is the amount of operational telemetry and operator-style control surface exposed through the publicly linked Daily Brief ecosystem. The rest of the public-facing design appears comparatively restrained, data-minimizing, and unusually explicit about its own limits.