Do not rely on Habitable for a real legal matter yet. Independent security and cryptography review, housing-law review, a real partner evaluation, recorded human screen-reader testing, and signed native distribution remain open.

Integrity is narrower than truth

Technical checks can support

  • whether packaged files match their recorded SHA-256 hashes;
  • whether the bundle signature validates against the included public identity;
  • whether supported timestamp-token signatures and message imprints validate;
  • whether a timestamp authority countersigned the whole bundle, and when — the packet seal, which covers every hash, date, and name in one imprint;
  • whether the custody log is internally consistent and references known records.

They do not establish

  • what a capture depicts, where it was made, or whether it is complete;
  • who controlled a signing key or whether that person had authority;
  • that a timestamp authority is trusted by a particular recipient;
  • who produced a packet: the signing key travels inside it, and a seal attests bytes and time, never an identity;
  • the accuracy, legal significance, or outcome of any housing claim.

Implemented and test-gated in the repository

  • Local encrypted vault storage; the static public site does not host case data.
  • Original capture preservation, content hashing, custody events, and signed bundles.
  • RFC 3161 timestamp support, including an explicit awaiting-timestamp state.
  • A packet seal: an RFC 3161 token over the whole bundle, so a rewritten packet cannot keep it. A packet exported with no network has none, and the verifier says so on every run rather than staying quiet about it.
  • A whole-unit export boundary and a packet disclosure statement covering optional originals and metadata handling.
  • HTML designed for accessibility and covered by automated browser checks, a print-oriented PDF, a machine-readable bundle, and a separate verifier.
  • English and Spanish app interfaces with automated structural and browser accessibility checks.

These are implementation statements, not assurances about a particular device, operator, transfer, authority, recipient, or legal forum. Review the current automated test runs and source rather than relying on this summary alone.

Open gates before real-data use

  • Independent security and cryptography review. The project publishes a threat model and tests, but no independent assessment has been completed.
  • Housing-law and recipient-workflow review. No project statement determines how a court, agency, legal-aid program, union, or inspector should treat a packet.
  • Real partner evaluation. No tenant union, legal-aid organization, or government agency outcome is claimed. The current sample and tests use synthetic data.
  • Human accessibility validation. Automated axe, keyboard, structure, and localization checks exist; recorded human NVDA, VoiceOver, cognitive, and field-use results remain open.
  • Signed distribution and update operations. The Python workflow is intended for technical evaluation. Consumer-grade signed native packages and a supported update channel are not available.

Threats the tool cannot remove

  • A compromised or unlocked device can expose data before or after encryption.
  • A weak, reused, shared, lost, or coerced passphrase can defeat the intended access boundary.
  • Operators can enter inaccurate descriptions, omit events, misidentify sources, or capture misleading context.
  • Recipients can copy, redistribute, screenshot, or retain an export beyond the sender’s control.
  • File names, transfer timing, backups, printer queues, and external tools can reveal metadata outside the vault.
  • Local-only software does not eliminate retaliation, surveillance, coercion, subpoena, discovery, or physical-safety risks.

Read the detailed threat model, security policy, and legal boundaries.

Public-site and disclosure boundaries

The GitHub Pages site is static. It provides documentation and synthetic artifacts; it has no form for collecting evidence. GitHub itself records ordinary request data under its own policies when someone visits the site or repository, and the site counts visits with Google Analytics, described next.

Google Analytics on this website

This website, and only the website, counts visits with Google Analytics 4, a service of Google LLC, which processes that data on this project’s behalf. It receives each page’s address and title, the site you came from, and your browser’s language, screen size, browser and operating system, and Google uses your IP address to estimate your approximate location. The address sent keeps only the page path and campaign tags such as utm_source. With its standard settings, Google Analytics also records scrolling to the end of a page, clicks on links to other sites, and file downloads. The app, the command-line tool and the relay send nothing to Google or anyone else.

Google Analytics sets two cookies, _ga and one whose name begins with _ga_, holding a random identifier for up to two years. In the European Economic Area, the United Kingdom and Switzerland, the site tells Google not to store them, and Google Analytics receives only cookieless measurements. Advertising features are off: Google signals and ad personalization are disabled, and advertising storage is denied everywhere. Google Analytics keeps event-level data for 14 months.

It does not load if your browser sends Global Privacy Control or Do Not Track, or after you choose “Opt out of analytics” at the bottom of any page. That choice is saved in this browser’s local storage and deletes the Google Analytics cookies already set; “Opt back in” undoes it. If a visit to this site could itself put you at risk, turn on Global Privacy Control or opt out before reading further.

Never publish a case to get support. GitHub issues, discussions, pull requests, and repository files are public. Do not submit tenant names, addresses, photos, messages, allegations, keys, evidence, packet files, or case details.

The review hub routes non-sensitive technical feedback to public tasks or Discussions, organization interest to a private no-case-data contact, and vulnerabilities to private reporting. None is an evidence-transfer channel.

Within the app, a deliberate export can still disclose sensitive material. Review the entire whole-unit packet and its disclosure statement, including whether sealed originals are embedded and how metadata is handled. If the whole-unit scope is too broad, do not export: issue/date selection is currently blocked. Choose a safe transfer channel and assume every recipient can make additional copies.

A responsible evaluation sequence

  1. Read the method and threat model. Confirm that the claimed protections address the risks you actually face.
  2. Use a fictional scenario. Do not import or adapt a real tenant’s details, even if names are changed.
  3. Test disclosure and transfer. Look for unintended copies, metadata, confusing status language, and recipient misunderstanding.
  4. Bring independent reviewers. Security, cryptography, accessibility, organizing, inspection, and legal expertise answer different questions.
  5. Record a stop decision. If a gate is not met, remain on synthetic data. A feature demonstration is not evidence that the operational system is safe.