Web credibility and trust signals

Stanford Web Credibility Project (Fogg et al.): The ten guidelines for web credibility — real-world affiliation, named team, clear contact info, transparent design — are from B.J. Fogg and colleagues at the Stanford Persuasive Technology Lab. We use these as the checklist for every marketing page. Guidelines.
Nielsen Norman Group — trustworthiness research: NN/g has maintained decades of research on what makes users trust (or distrust) a website. Their three-part series on trustworthiness is a direct input to our footer, contact, and pricing pages. Trustworthy Design.
The four dimensions of trust (Corritore et al., 2003): Corritore, Kracher, and Wiedenbeck’s “On-line trust: concepts, evolving themes, a model” is the canonical academic framework for how users form trust on the web. It informs our decision to publish concrete security controls on the security practices page rather than relying on logos and badges alone. DOI.

Phishing susceptibility and training

NIST phishing research (2016–): NIST’s ongoing work on why phishing succeeds — particularly the observation that susceptibility correlates with task urgency rather than user vigilance — directly shapes our training module on spotting phishing emails and our AI scam detection pipeline. Phish Scale.
Sheng et al. — “Who falls for phish?” (CHI 2010): Large-scale survey showing that 25–30% of users click phishing links even when they self-report high awareness. Our training content emphasizes hover-before-click as the single highest-leverage habit because this study shows awareness alone is insufficient. DOI.

NIST SP 800-63B Digital Identity Guidelines: The federal standard for digital authentication. Our password requirements, MFA flow, and session management are all NIST SP 800-63B compliant. NIST SP 800-63B.
OWASP Password Storage Cheat Sheet: The source of our Argon2id parameter choices (64 MiB memory, 3 iterations, 4 parallelism). OWASP maintains this as a living document; we track their recommendations closely. Cheat Sheet.
RFC 6238 — TOTP: The IETF standard for time-based one-time passwords. Our MFA flow implements RFC 6238 literally via the otplib library, with a ±30-second clock-skew tolerance. RFC 6238.

CCPA and California Regs §7063: California’s Consumer Privacy Act and its authorized-agent regulations define the legal framework for data broker removal. Our data scrubbing flow captures IP address + timestamp server-side (never client-supplied) so consent receipts meet the §7063 proof-of-authorization standard. California AG.
GDPR Article 17 (Right to Erasure): Our DSAR deletion flow implements GDPR Article 17: one-click full deletion, cascade through every user-linked table, vendor-side deletion before local deletion, and audit log preservation under Article 17(3)(b) “legal obligation” retention grounds. GDPR Article 17.

OWASP Top 10 (2021): The baseline for our threat model on every new feature. Every audit report in docs/security/ maps findings back to OWASP Top 10 categories where applicable. OWASP Top 10.
OWASP ASVS Level 2: The Application Security Verification Standard is our self-assessment target. We don’t claim formal certification but we do review every control in Level 2 on every major feature. ASVS.
OWASP CSRF Prevention Cheat Sheet — Origin check: We use the same-origin check pattern recommended by OWASP (compare Origin and Referer against an allowlist) rather than a double-submit cookie token, because we ship Same-Site=Lax cookies and don’t want to burden every client fetch with an explicit token roundtrip. Cheat Sheet.