This repository contains the ToS;DR browser extension (Manifest V3) for Chrome, Firefox, and Edge. It downloads a local database of website service ratings from the ToS;DR API, then detects which service a visited domain corresponds to by progressively reducing the hostname. When a match is found, it updates the toolbar icon with the service's grade (A–E) and enables the popup to show detailed summaries of terms-of-service points. The popup also fetches live service details from the API if needed. The codebase is written entirely in TypeScript with strict type checking, uses Vite for building, and includes CI/CD workflows for linting, type-checking, and creating release artifacts. The architecture is a standard single-page browser extension with a background script (or background page for Firefox), popup UI, and settings page. No test suite is present, but the code is well-organized and modular.
Ackee is a self-hosted, privacy-focused web analytics tool. It tracks page views, durations, referrers, browsers, devices, operating systems, screen sizes, languages, and custom events without using cookies or collecting personally identifiable information. Visitor identity is anonymized via SHA-256 hashing of IP + user agent + domain ID with a daily rotating salt. The architecture is a full-stack Node.js application: an Express server with Apollo Server for GraphQL, a React single-page application frontend (using `createElement` instead of JSX), and MongoDB for persistence. The backend provides a GraphQL API for querying aggregated statistics and managing domains, events, and authentication tokens. The frontend consumes this API via Apollo Client and renders a dashboard with reusable card and presentation components. Key design patterns include a `pipe` utility for chaining resolver middleware (auth, demo mode blocking), modular MongoDB aggregation stages stored in `src/stages/`, and a custom build pipeline using Rosid handlers. The application supports multiple deployment targets: Docker, Heroku, Vercel, Netlify, and manual Node.js processes.
FairEmail is a fully-featured, open-source, privacy-oriented email client for Android. It supports IMAP, POP3, SMTP, OpenPGP, S/MIME, and OAuth for major providers (Gmail, Outlook, Yahoo). The app is built as a standard Android application with Activities, Fragments, Services, and WorkManager workers. It uses Room for local persistence, LiveData for reactive UI, and a custom async pattern (SimpleTask) for background operations. The codebase is notable for its extensive use of vendored libraries: it includes modified copies of JavaMail (javax.mail, com.sun.mail), AndroidX internals (Room, Paging, Emoji2, RecyclerView Selection), Google Protocol Buffers, and native language/encoding detection engines (CLD3, compact_enc_det). This hybrid approach provides deep email protocol support and privacy features like tracker blocking, certificate transparency, and DANE, but also introduces maintenance overhead and potential drift from upstream versions. The app integrates AI features (Gemini, OpenAI) for summarization and rule actions, and includes a full rule/filter engine. Despite the heavy vendoring, the core application code demonstrates solid engineering with clean abstractions, custom views that work around Android platform bugs, and a consistent async pattern. The repository is actively maintained with frequent releases and responsive issue triage.
This repository provides a Docker container that runs the Transmission BitTorrent client exclusively through an OpenVPN tunnel, ensuring that all torrent traffic is routed through the VPN. The container is designed as a monolithic application with a shell-based orchestrator (`start.sh`) that initializes the VPN connection, configures Transmission, and optionally starts a Privoxy HTTP proxy. The system relies on external VPN provider configs (either bundled scripts for dynamic download or a community-maintained config repository) and enforces a kill-switch pattern: Transmission runs only when the VPN tunnel is active. The codebase is well-structured with clear separation of concerns (OpenVPN setup, Transmission management, health checks, and optional plugins). It demonstrates mature Docker container patterns, including user permission handling, persistent environment variable injection, and runtime configuration modification. While the architecture is not groundbreaking, it is robust and battle-tested (4.5k stars, 1.1k forks). Notable components include reusable Python scripts for environment variable persistence and JSON settings overlay, and a configurable OpenVPN config modifier.
This repository is the data pipeline used by Mullvad VPN to produce DNS blocklists for ads, trackers, adult content, gambling, social media, and malware. It ingests multiple upstream blocklists (from oisd, hagezi, AdGuard, Firebog, etc.) and custom lists via an Ansible playbook, cleans and normalizes them (removing localhost IPs, comments, special characters), combines them by category, and outputs plain-text domain lists and RFC-compliant zone files for both encrypted DNS (DoH) and VPN relay servers. The output files are GPG-signed for integrity. A CI workflow validates zone files using named-checkzone. The repository also includes scripts for generating social media blocklists by enumerating subdomains (via subfinder) and fetching IP ranges for major social platforms (Facebook, TikTok, Snapchat) using ASN lookups. While tightly coupled to Mullvad's infrastructure, the ETL pattern and zone file generation logic are well-structured and could be adapted for similar DNS blocking pipelines.
Vanadium is a hardened fork of Chromium for Android, developed by GrapheneOS. It serves as both the default browser and the system WebView provider on GrapheneOS devices. The repository contains a large set of patches (over 300) applied to the Chromium source tree, modifying default settings to enhance privacy and security: disabling telemetry, network prediction, third-party cookies, safe browsing, sign-in, media router, background sync, sensors, and many other features. It enables strict security policies like HTTPS-only mode, strict site isolation, partitioned connections, and Do Not Track. The build system uses GN with custom extension files to inject downstream code into Chromium targets. A separate 'config APK' delivers runtime feature flags and ad-blocking filter lists. The repository also includes patches for GrapheneOS-specific OS integration (custom permissions, connectivity checks, seccomp-bpf sandboxing). The codebase is actively maintained with frequent rebases to upstream Chromium, but the high patch count introduces significant merge conflict risk.
This monorepo houses the entire Start9 ecosystem, centered on StartOS—a self-hosted Linux distribution for personal servers. The repository encompasses multiple products: StartOS (server OS with container orchestration, backup, networking, and marketplace), StartWRT (router firmware based on OpenWrt), StartTunnel (WireGuard-based tunnel service), StartCLI (command-line tool), StartRegistry (package registry), and StartSDK (TypeScript SDK for building service packages). The architecture is a hybrid of Rust backend services (using async Tokio, axum, and a custom RPC toolkit) and Angular frontends (using Taiga UI and a reactive PatchDB state store). Key orchestration is handled by the container runtime (Node.js with LXC) and a custom diff-based database (PatchDB) for real-time UI synchronization. The system manages service lifecycle, ACME certificates, DNS, port forwarding, VPNs, encrypted backups, and firmware updates. External dependencies include Linux kernel features (LXC, btrfs, eCryptFS, FUSE, nftables), WireGuard, and standard Rust/Angular libraries. The codebase is actively maintained with frequent version migrations and CI/CD pipelines, but carries some duplication across products and technical debt from rapid evolution.
Spam Call Blocker is an Android application written in Kotlin that blocks unwanted incoming calls using a combination of local blocklists, pattern matching, and real-time checks against multiple online phone reputation services (UnknownPhone, Tellows, Truecaller, and regional directories). It registers a call screening service to intercept calls, evaluates them against user-defined rules and external APIs, and can block, mute, or answer-and-hangup spam calls. The app provides a full settings UI for managing blocked/whitelisted numbers, pattern-based blocking, API toggles, and export/import of configuration. It also includes a donation screen and automatic update checking via GitHub releases. The codebase is well-structured with clear separation of concerns, uses Kotlin coroutines for concurrent API checks, and supports multiple languages.
photoscrawl is a macOS CLI tool that crawls, archives, and analyzes Apple Photos libraries. It extracts metadata, faces, search indexes, and performs classification using local multimodal models (Ollama/OpenAI). The tool stores observations and evidence in a local SQLite database (photos.sqlite) rather than final truth, enabling later hypothesis generation for people, trips, and places. It provides subcommands for crawling, importing, classifying, searching, ranking, similarity, place backfill, and evaluation card generation. Architecture: The system is a Go CLI with a modular internal structure. It uses a crawlkit shared library for crawler mechanics, control, output, and store. The Apple Photos library is accessed via PhotoKit (cgo/Objective-C bridges) and direct SQLite snapshots. Data flows: snapshot Apple Photos database -> import metadata, faces, search indexes -> classify assets (metadata observations, then optional local model inference) -> store evidence in archive. Place backfill uses a subprocess bridge for reverse geocoding with rate limiting. Eval cards prepare images and run Ollama models for evaluation. Key entry points: cmd/photoscrawl/main.go (CLI), internal/archive/crawl.go (crawl logic), internal/archive/classify.go (classification queue), internal/place/backfill.go (batch geocoding), internal/evalcard/evalcard.go (model evaluation). External dependencies: Apple Photos (macOS), SQLite, Ollama/OpenAI (optional), crawlkit, Go standard library. The codebase demonstrates strong engineering practices with comprehensive tests, CI/CD, vulnerability scanning, and schema migrations. It is actively maintained with frequent dependency updates and a focus on privacy (all model calls local by default, no private data in repo).
Berty is a full-stack, privacy-focused, peer-to-peer messaging application. The system consists of a Go backend implementing the Wesh protocol (based on IPFS, libp2p, and OrbitDB) that provides core messaging, push notifications, authentication, replication, and directory services. The backend is exposed via gRPC and consumed by multiple clients: a React Native mobile app (with both a legacy JS variant and a newer Expo-based variant), a Go CLI with a terminal UI (mini) and a desktop GUI (Fyne), and native bridges for iOS and Android. The architecture is modular, with separate packages for error handling, authentication, push relay, and bot framework. Key entry points include the `berty daemon` CLI command, the mobile app entry points (`App.tsx` in both `js/packages` and `berty-bridge-expo/mobile`), and the bridge framework (`go/framework/bertybridge`). Data flows involve gRPC streams from the Go backend to the mobile clients, with event-driven state management and local encrypted storage via SQLCipher. External dependencies include libp2p, OrbitDB, gRPC, protobuf, and various platform-specific native modules for BLE, mDNS, and push notifications. The repository also contains auxiliary tools for infrastructure testing, rendezvous servers, and debugging (Tyber).
Min is a production desktop web browser built on Electron, focused on speed, minimal UI, and privacy. The repository contains the complete application: main-process window and view management, tab/task state, a plugin-driven search/address bar, session restore, download handling, reader mode, PDF viewing, content blocking, translation, and password-manager integrations. The dominant architecture is an Electron main/renderer split with IPC-driven communication, several hidden service pages (places, translation), and a custom module bundling pipeline for main, browser, and preload scripts. Although it embeds data-oriented components such as a history full-text search engine and a bookmark tag index, this is an application, not a data/research project; those components serve browser features rather than analytical workflows. The primary entry points are `main/main.js` for the Electron main process, `js/default.js` for browser UI initialization, and `index.html` for the renderer shell. Core data flows are local: browsing history and bookmarks are persisted through Dexie/IndexedDB in a hidden places service, full-text history search uses a custom BM25-style ranking implementation, and network requests are filtered by a modified ABP filter parser. External dependencies include Electron, Dexie, pdfjs-dist, Readability, drag-and-drop libraries, external CLI password managers, EasyList-style filter lists, the Public Suffix List, and Bergamot translation models. The searchbar plugin system and password-manager abstraction are the most notable architectural patterns. The codebase is actively maintained but shows medium technical drift: it relies on a custom concatenation-based build instead of a standard bundler, mixes legacy callbacks with modern async/await, vendors modified forks of third-party code, and contains Electron-version-specific workarounds. No automated test suite is present in the repository, and some platform-specific code is fragile across Electron upgrades. Overall it is a solid, working desktop application with several clean abstractions and a small number of genuinely reusable components, but it would benefit from test coverage and modernization.
CtxPort is a browser extension and companion documentation website that lets users copy AI conversations (from ChatGPT, Claude, Gemini, DeepSeek, Grok, Doubao, GitHub) as structured Markdown Context Bundles. It solves 'context rot' by enabling portable, lossless migration of conversations between AI tools without uploading data to third parties. The architecture is a modern monorepo using pnpm workspaces and Turborepo, with separate packages for schema validation (Zod), markdown serialization, plugin-based extraction, and shared UI components. The browser extension (Manifest V3, WXT, React 19, Tailwind CSS 4) injects copy buttons and sidebar list icons into supported platforms, while the documentation website (Next.js + Nextra) provides multilingual (en/zh) user guides and feature descriptions. All processing is client-side; no data is uploaded. The codebase demonstrates strong engineering practices including a plugin system for extensibility, a strategy pattern for content flatteners, clean separation of concerns, and comprehensive CI/CD pipelines. Some fragility exists in DOM selectors and platform APIs, but the architecture is well-structured for adaptation.
Sophia Script for Windows is a PowerShell-based system administration utility for fine-tuning Windows 10 and 11 installations. It provides over 150 configuration functions covering privacy, telemetry, UI personalization, security hardening, debloating, and system optimization. The tool is distributed as a PowerShell module with per-edition variants (Windows 10/11, LTSC, ARM, PowerShell 5.1/7) and includes a closed-source GUI wrapper (SophiaScriptWrapper.exe) for visual configuration. Architecture: The core is a PowerShell module (Sophia.psm1) with a preset file (Sophia.ps1) that users edit to select tweaks. The module loads private helper functions (Add-Policy, Get-Hash, WinAPI, etc.) and localization files. Execution flow: Import-TabCompletion.ps1 → InitialActions.ps1 (preflight checks) → user-selected tweaks → PostActions.ps1 (system refresh, toasts, restore points). The tool modifies Windows via registry keys, group policy (LGPO.exe), service management, scheduled tasks, and file association hashes. Key entry points: Sophia.ps1 (per edition) is the main preset; Import-TabCompletion.ps1 provides tab-completion; the Wrapper/ directory contains GUI config JSONs and the wrapper executable. External dependencies include LGPO.exe (Microsoft), WinRAR for packaging, and runtime downloads for HEVC codecs and cursor packs. The project is distributed via Chocolatey, WinGet, Scoop, and direct GitHub releases. Data flows: The script reads Windows build/version info, checks remote JSON manifests for updates, and applies changes based on user preset. It exports/imports file associations as JSON and creates restore points. Localization is handled via ConvertFrom-StringData .psd1 files in 12 languages. The tool is not a data pipeline or research project; it is a pure system configuration utility.
RetroShare is a decentralized, peer-to-peer communication and file-sharing application built with C++ and Qt. It provides encrypted messaging, chat lobbies, forums, channels, file transfer, photo sharing, microblogging (The Wire), and a plugin system (VOIP, FeedReader). The architecture is a monolith with a core library (libretroshare) providing services like GXS (Generic eXchange System) for distributed group data, a Qt-based GUI (retroshare-gui), a headless service (retroshare-service), and a standalone friend server for Tor-based peer introduction. The codebase is large and mature, with extensive unit tests and a simulation framework for peer-to-peer testing. While many components are well-crafted, there is unfinished code, disabled tests, and some technical debt from long-term evolution.
This repository is the deployment system for Internet-in-a-Box (IIAB): an offline-first learning server for schools and communities without reliable Internet. It is an Ansible configuration-management application that installs and configures a complete local network stack — nginx reverse proxy, PHP-FPM, MySQL/PostgreSQL, hostapd WiFi access point, dnsmasq DNS/DHCP, Squid proxy, captive portal, Samba, CUPS — alongside a catalog of educational services such as Kiwix (offline Wikipedia/ZIM), Kolibri, WordPress, MediaWiki, Nextcloud, Gitea, JupyterHub, Moodle, Calibre-Web, and an offline OpenStreetMap/vector-tile mapping system with geocoding. Python, PHP, and Jinja2 templates generate systemd units, nginx virtual hosts, and app configs for every deployed service. Architecture is a staged Ansible pipeline: eleven role groups (0-init through 9-local-addons, then network) are driven from top-level playbooks (iiab-stages.yml, iiab-from-cmdline.yml) invoked by shell entry points (iiab-install, iiab-configure, iiab-network). Every role follows consistent conventions: defaults in defaults/main.yml, an install.yml and enable-or-disable.yml, boolean *_install/*_enabled flags validated up front with Ansible assert tasks, install state recorded in /etc/iiab/iiab_state.yml, and disk usage audited into iiab.ini. A custom Ansible module (get_curl) performs resumable/atomic downloads used across roles. Content provisioning is data-driven: maps and ZIM catalogs are generated (roles/maps/generate-catalog.py) and fetched at install time; offline search and geometry utilities (FQR, static_search.js) are bundled into the served front end. The project is actively developed (Ubuntu 24.04 and Raspberry Pi OS CI matrices, expected-state integration tests) but carries heavy legacy baggage: a large 0-DEPRECATED-ROLES tree, numerous .unused files, Python 2 support scripts, hardcoded versions/vendor URLs, plaintext default secrets, and fragile per-distro workarounds. The reusable gems — the custom download module, the tested geographic FQR geometry utility, the client-side static geocoder, the Ansible facts script, and the pdsm proot service manager — are isolated enough to extract into new projects. Overall it is a solid, professional infrastructure-as-code project with a few genuinely reusable components, tempered by significant accumulated technical debt.
iKy (I Know You) is a modular OSINT (Open Source Intelligence) aggregation platform built with FastAPI, Celery, Redis, and an Angular frontend. The system ingests a username or email and concurrently executes 26+ parallel tasks across social media, data breaches, search engines, and dark web sources, returning a structured JSON contract (module, param, validation, raw, graphic, profile, timeline, tasks) consumed by a visual graph/timeline UI. Key architectural patterns include a dynamic module registry that maps route names to Celery task paths, a decorator-based task wrapper (@iky_task) that centralizes dev-mode golden-file bypass, error classification, and performance logging, and a pluggable search provider orchestration layer. The codebase demonstrates a strong separation of concerns between API routing, task execution, and data enrichment, but suffers from fragile scraping logic (LinkedIn RSC parsing, TikTok SSR regex), heavy reliance on browser session cookies, and several deprecated external APIs (Twitter v1.1, FullContact). The project is actively maintained with an extensive test suite (~4K lines) and Docker Compose deployment, though many tests are heavily mocked and may not detect real API drift.
The SmartNoise SQL/Synth/Eval monorepo is a differentially private (DP) data analysis toolkit. It provides three main packages: `snsql` (DP SQL query rewriting with calibrated noise), `snsynth` (DP synthetic data generation via MWEM, GANs, MST, and other mechanisms), and `sneval` (evaluation of synthetic data quality). The SQL package includes a custom ANTLR-based SQL parser (`SqlSmall.g4`) that rewrites queries to enforce DP, supports multiple backends (Pandas, Spark, PostgreSQL, SQL Server, BigQuery), and tracks privacy budgets via an odometer. The synth package offers a rich set of synthesizers (DPCTGAN, PATECTGAN, MWEM, MST, AIM, etc.) with a consistent `fit`/`sample` API and a `TableTransformer` pipeline for preprocessing. The eval package provides metrics for comparing real vs. synthetic data, including accuracy, bias, and suppression/fabrication counts. The repository includes extensive tests (SQL parsing, mechanism accuracy, synthesizer round-trips) and sample notebooks demonstrating DP workflows.
This repository is a comprehensive, curated collection of step-by-step privacy configuration guides for a wide range of software, services, and operating systems (e.g., browsers, messaging apps, social media, Windows, Android, macOS). It is purely documentation—no executable code, APIs, or data pipelines. The content is organized into Markdown files under 'Privacy Settings' and 'Extensions Settings', with a central README serving as an index. The guides are consistently formatted, include notes and tips, and are actively maintained with regular updates reflecting the latest stable versions. While not a software application, it serves as a high-quality reference for users seeking to harden privacy settings across their digital footprint.
Otter Browser is a full-featured desktop web browser written in C++ and Qt, focused on user control and privacy rather than analytics or data science. It implements the complete browser feature set: tabbed browsing, sessions, bookmarks, history, RSS/Atom feeds, cookies, password management, content blocking, ad blocking, mouse gestures, spell checking, search engines, SSL certificate inspection, and import/export of user data from Opera, HTML, OPML, and XBEL formats. The system is a Qt Widgets desktop application, not a service or library, with the entry point in src/main.cpp and central orchestration in Application and MainWindow. Core browser services are implemented as manager singletons, UI is built from custom widgets and dialogs, and rendering is abstracted behind a WebBackend interface with two concrete backends: the legacy QtWebKit backend and the Chromium-based QtWebEngine backend. Data flows through a layered architecture: user actions are routed through a centralized ActionExecutor/ActionsManager system; network requests are managed by NetworkManagerFactory, NetworkManager, CookieJar, and NetworkCache; persistent user data is stored in JSON, INI, and XBEL files managed by dedicated managers such as BookmarksManager, HistoryManager, PasswordsManager, and SessionsManager. The browser also bundles significant third-party code, including Google Breakpad for crash reporting, KDE Sonnet for spell checking, a mouse gesture recognizer, and libmimeapps for freedesktop MIME integration. The code is modular and shows deliberate engineering in areas like the asynchronous job framework, feed parser, and reusable widget library, but it is a large legacy codebase with no visible automated test suite and significant compatibility debt. This is purely an application repository, not a data research project. The only data involved is user browsing data and configuration files. The project remains under active development, with recent commits through 2026, but technical drift is moderate: QtWebKit is deprecated and removed from modern Qt distributions, the Qt5/Qt6 migration is incomplete, several bundled third-party libraries are old forks, and platform-specific code is fragile. The codebase would benefit from a cleanup of the legacy web backend, better test coverage, and completion of the Qt6 port, but the core architecture is coherent and many components are genuinely reusable.
The banking-apps-compat-report repository is a crowdsourced initiative that tracks the compatibility of international banking apps with GrapheneOS by leveraging GitHub issues as a data collection mechanism. Rather than containing traditional source code or data processing pipelines, the project relies on users submitting detailed compatibility reports through a standardized issue form, which are then curated and published by maintainers on the PrivSec.dev website. The cornerstone of this repository is the GitHub issue template located at .github/ISSUE_TEMPLATE/app_report.yml. This template defines a comprehensive form for collecting structured data on banking app compatibility, including fields for app metadata, device and profile specifications, security settings (such as exploit protection and memory tagging), installation methods, NFC payment functionality, and user-reported issues. Its careful design ensures consistent and high-quality data input, making it a reusable asset for similar crowdsourced data collection efforts in other domains. The project is actively maintained, with recent commits and ongoing issue triage, and exhibits low technical drift due to its minimal dependencies and use of stable GitHub features. However, reproducibility of the published compatibility lists is limited because the raw data resides exclusively in the GitHub issue tracker and is not bundled within the repository. Despite this, the initiative successfully provides a valuable, community-driven resource for GrapheneOS users seeking reliable information on banking app functionality.