Recommendation: Privacy & Data-Handling Improvements for Public Feedback Workflow

[asiakay]

The current feedback workflow appears to automatically convert user-submitted form data into a publicly visible GitHub issue without filtering or redacting personally identifiable information (PII). This creates a repeated, systemic privacy exposure that disproportionately affects vulnerable users who may not understand that their submissions become public artifacts.

From a UX and security standpoint, there are several areas of concern:

⸻

1. Lack of PII Sanitization Prior to Publication

Unfiltered publication of free-text fields allows:
• Phone numbers
• Physical addresses
• Email addresses
• Age identifiers
• Sensitive personal context

to be posted directly into a public code repository indexed by search engines.

Technical Recommendation:
Implement server-side filtering or a sanitization middleware layer that automatically detects and redacts PII prior to publishing. Libraries exist for pattern-matching phone numbers, SSNs, and address formats (e.g., regex-based scrubbing, NER models for entity detection).

Tools/approaches that can be used:
• pii-sanitizer or similar utilities
• Custom regex scrubbing (simple but high-impact)
• Named Entity Recognition with spaCy or Presidio for higher accuracy

This drastically reduces downstream exposure risk.

⸻

2. Absence of User Awareness of Public Posting

From a UX-informed privacy perspective, users should be explicitly informed when their input is routed to a public endpoint.

Recommendation:
Add a clear disclosure near the submission button stating that comments may become public. Provide:
• An explicit “public submission” notice
• A private submission option
• A modal confirmation if high-risk input is detected

This aligns with established privacy-by-design principles and reduces accidental disclosure.

⸻

3. No Alternative Channel for Sensitive Feedback

A binary system (submit → publish publicly) does not account for sensitive, personal, or safety-related submissions.

Recommendation:
Implement a dual-track system:
• Track A: Public comments (auto-redacted, user-consented)
• Track B: Private submissions routed to an internal queue or ticketing system (e.g., JIRA, ServiceNow, or GitHub private issues)

This is a low-lift architectural improvement that respects different user needs without redesigning the entire form.

⸻

4. Risk of Long-Term Data Persistence

Once the issue is published to GitHub, it becomes:
• Permanently indexed
• Archivable
• Scraped by bots and third-party mirrors
• Potentially included in FOIA-related datasets

Even if later edited, the original exposure persists in public history, forks, and caches.

Recommendation:
For public-sector systems, implement a “scrub on publish” model so no raw PII is ever written to the repository in the first place.

⸻

5. Misalignment with Modern Federal UX & Privacy Best Practices

Federal guidelines (e.g., 21st Century IDEA, NIST 800-53, OMB Circular A-130) emphasize:
• Minimizing data collection
• Protecting user privacy
• Providing informed consent
• Reducing harm through design

The current workflow unintentionally conflicts with these standards.

Recommendation:
Audit the submission pipeline and introduce a privacy review checkpoint for any automated publication workflow.

⸻

Summary

A small technical adjustment — adding a PII-sanitizing middleware and a consent mechanism — would significantly improve user safety and reduce institutional risk. These solutions are low-cost, technically straightforward, and align with federal UX and data-handling expectations.

I’m offering this recommendation because the current process exposes sensitive user information unnecessarily, and a small architectural adjustment would prevent future harm.