# Website password requirements study

This directory is the unpublished collection workspace for a purposive study
of 100 consumer-facing account services. Collection is in progress. The
records are working research notes, not reviewed findings or a public dataset.

## Research question

What password rules and password-manager usability features are publicly
documented or safely observable across a fixed, cross-sector group of widely
used account services?

The study is descriptive. The sample is purposive, not random, and results must
not be described as representative of all websites or all user accounts.

## Sampling frame

`sample.json` freezes ten services in each of ten sectors before observations
begin. Selection favors recognizable consumer services with account login,
sector breadth, and geographic breadth. A service's inclusion is not a claim
about an exact traffic rank.

The sample must not be changed after collection begins merely because a result
is inconvenient. Any necessary replacement requires a dated amendment here,
with the original site retained in the change log.

## Collection boundary

Collectors may use official help pages, official account documentation, and
password fields that are publicly visible without creating or changing an
account. They must not:

- create accounts or submit registration forms;
- change passwords on existing accounts;
- automate live signup or login flows;
- bypass bot defenses, rate limits, or geographic restrictions;
- enter real, generated, or compromised passwords into a third-party service;
- infer an undocumented rule from an error message that cannot be reproduced
  safely.

When a control cannot be established within that boundary, record `unknown`.
Unknown is a result, not a failure to be hidden.

The canonical JSON may omit an unknown control to keep collection records
readable. Omitted controls are normalized to `unknown` in derived outputs and
must be counted in the missingness denominator.

## Evidence rules

Each non-unknown observation requires at least one evidence record containing
the URL, page title, access date, evidence type, and a short paraphrase. Do not
copy long passages from source pages. Screenshots, when rights and privacy
allow, must contain no account identifiers or user-entered values.

Public documentation and observed interface behavior are separate evidence
types. If they conflict, preserve both and mark the observation for review.

## NIST mapping

Controls are mapped individually to the final NIST SP 800-63B-4 requirements.
The study must distinguish `SHALL`, `SHOULD`, and `MAY`, and must not publish a
single "NIST compliant" score. Server-side controls such as password hashing,
blocklist implementation, and rate limiting are normally not publicly
observable.

## Review and publication gate

Every site requires two passes: collection and a separate evidence-review pass.
The review rechecks account context, distinguishes advice from enforced rules,
and confirms that every published value is supported by the cited page. This
release was collected and reviewed by the same researcher, so it should not be
described as independently replicated. The public report and derived totals may
be generated only when:

1. all 100 sampled services have an observation record;
2. every record has completed the evidence-review pass or is explicitly
   `not_testable`;
3. every asserted value has evidence;
4. denominators and unknown counts are included with every aggregate;
5. the publish check passes.

Run:

```sh
npm run research:policy-template
npm run check:policy-study
npm run check:policy-study:publish
```

The normal check validates the frozen sample and any work in progress. The
publish check intentionally fails until the evidence and review requirements
are complete.