generated from coulomb/repo-seed
tegwick
b09290cb83
Implements all requirements from ProductRequirementsDocument.md: - PDF detection via Chrome Downloads API - Secure credential storage with AES-GCM encryption - Binect API integration for PDF uploads - Popup UI with Binect branding - Local transfer tracking (500 entry cap) - Help page with tracking view and CSV export - 60-day credential retention with auto-expiry - Accessibility compliance (WCAG 2.1 AA) Technical implementation: - Chrome Extension Manifest V3 - TypeScript with strict mode - Webpack build system - Jest test suite (22/22 passing) - ESLint configured (0 errors) Build output: 13 KB total (production minified) Test coverage: crypto, pdf-detector, tracker, binect-api Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
312 lines
7.1 KiB
Markdown
312 lines
7.1 KiB
Markdown
BinectChromePrd
|
|
|
|
*Product Requirements Document*
|
|
|
|
# **Product Requirements Document (PRD)**
|
|
|
|
## **Project: BinectChrome**
|
|
|
|
---
|
|
|
|
## 1. Product Overview
|
|
|
|
### 1.1 Purpose
|
|
|
|
**BinectChrome** is a Google Chrome extension that enables users to send PDF documents generated in arbitrary cloud applications directly to Binect for physical printing and postal delivery.
|
|
|
|
It eliminates the manual **download → upload** workflow by adding a lightweight, privacy-preserving integration layer in the browser — without requiring changes to the originating application (A).
|
|
|
|
---
|
|
|
|
### 1.2 Problem Statement
|
|
|
|
Users frequently generate PDF documents (letters, invoices, notices) in cloud applications that are **not integrated** with postal mail services.
|
|
|
|
Today, the workflow requires:
|
|
|
|
1. Downloading the PDF from application A
|
|
2. Uploading the PDF to application B (Binect)
|
|
3. Repeating this for every document
|
|
|
|
This causes friction, errors, and unnecessary time loss.
|
|
|
|
---
|
|
|
|
### 1.3 Solution Summary
|
|
|
|
BinectChrome:
|
|
|
|
* Detects PDF downloads (and supported in-browser PDF views)
|
|
* Offers a **“Send PDF to Binect”** action
|
|
* Securely transfers the PDF to Binect via its API
|
|
* Requires explicit user intent
|
|
* Stores no PDF content
|
|
* Tracks transfers locally for transparency and support
|
|
|
|
---
|
|
|
|
## 2. Goals & Non-Goals
|
|
|
|
### 2.1 Goals
|
|
|
|
* Reduce friction when sending PDFs to physical mail
|
|
* Require **no integration changes** in source systems (A)
|
|
* Preserve user privacy and trust
|
|
* Be simple, reliable, and auditable
|
|
* Minimize permissions and attack surface
|
|
|
|
### 2.2 Non-Goals
|
|
|
|
* No automation or RPA of third-party websites
|
|
* No shared identity or credential federation
|
|
* No document content storage or analysis
|
|
* No backend relay service
|
|
* No multi-browser support in v1 (Chrome only)
|
|
|
|
---
|
|
|
|
## 3. Target Users
|
|
|
|
* Business users producing PDFs in cloud applications
|
|
* Office workers sending recurring physical mail
|
|
* Compliance-conscious users who require explicit control
|
|
* Chrome-based desktop workflows
|
|
|
|
---
|
|
|
|
## 4. Functional Requirements
|
|
|
|
### 4.1 PDF Detection
|
|
|
|
#### 4.1.1 PDF Downloads (MUST)
|
|
|
|
* Detect completed PDF downloads using Chrome Downloads API
|
|
* Identification via:
|
|
|
|
* `.pdf` filename extension
|
|
* or response headers (`Content-Type: application/pdf`)
|
|
|
|
#### 4.1.2 PDF Viewed in Browser (SHOULD)
|
|
|
|
* Detect navigation to resources with `Content-Type: application/pdf`
|
|
* Applies when PDFs are loaded as normal URLs
|
|
|
|
**Accepted limitation:**
|
|
PDFs rendered via blob URLs or complex JavaScript viewers may not be detectable or retrievable.
|
|
|
|
---
|
|
|
|
### 4.2 User Interaction & Sending
|
|
|
|
#### 4.2.1 Toolbar & Popup (MUST)
|
|
|
|
* Chrome toolbar icon opens popup
|
|
* Popup shows:
|
|
|
|
* Last detected PDF (filename, size, timestamp, source domain)
|
|
* Primary action: **Send PDF to Binect**
|
|
|
|
#### 4.2.2 Explicit User Intent (MUST)
|
|
|
|
* PDFs are only sent after a deliberate user click
|
|
* No automatic sending by default
|
|
|
|
---
|
|
|
|
### 4.3 PDF Transfer
|
|
|
|
#### 4.3.1 PDF Acquisition (MUST for downloads)
|
|
|
|
* Extension retrieves PDF bytes for transfer:
|
|
|
|
* Prefer re-fetching from original URL using user session
|
|
* Fallback mechanisms may be implemented as needed
|
|
|
|
#### 4.3.2 Upload to Binect (MUST)
|
|
|
|
* Transfer PDF to Binect via official API
|
|
* Show clear progress and result states:
|
|
|
|
* Uploading
|
|
* Success
|
|
* Failure (with actionable error message)
|
|
|
|
---
|
|
|
|
### 4.4 Authentication & Credential Handling
|
|
|
|
#### 4.4.1 Authentication Method (MUST)
|
|
|
|
* Username + password authentication to Binect API
|
|
|
|
#### 4.4.2 Secure Storage (MUST)
|
|
|
|
* Credentials stored encrypted at rest in extension storage
|
|
* Decrypted credentials only held in memory during use
|
|
|
|
#### 4.4.3 Retention Policy (MUST)
|
|
|
|
* Credentials retained for **60 days since last successful use**
|
|
* “Use” = successful authentication or successful send
|
|
* After 60 days of inactivity:
|
|
|
|
* Credentials are automatically deleted
|
|
* User must re-enter credentials
|
|
|
|
#### 4.4.4 Manual Controls (MUST)
|
|
|
|
* User can manually wipe stored credentials at any time
|
|
* Optional “Lock now” to clear decrypted credentials from memory
|
|
|
|
---
|
|
|
|
### 4.5 Privacy & Data Handling
|
|
|
|
#### 4.5.1 PDF Content (MUST)
|
|
|
|
* Extension never stores PDF files
|
|
* Extension never reports PDF content
|
|
* PDFs are only transmitted to Binect upon explicit send
|
|
|
|
#### 4.5.2 Metadata Minimization (MUST)
|
|
|
|
* No content inspection
|
|
* No filename persistence required
|
|
* Only filesize and technical metadata are tracked
|
|
|
|
---
|
|
|
|
### 4.6 Local Tracking (“Score”)
|
|
|
|
#### 4.6.1 Tracking Scope (MUST)
|
|
|
|
Tracking data stored **locally only**:
|
|
|
|
* Timestamp
|
|
* Source A identifier (URL or domain)
|
|
* Destination B URL
|
|
* PDF filesize
|
|
* Result (success / failure + error class)
|
|
|
|
#### 4.6.2 Tracking Access (MUST)
|
|
|
|
* Tracking view accessible via **“?” Info/Help** link in popup
|
|
* Shows:
|
|
|
|
* Summary counts
|
|
* Chronological list of transfers
|
|
|
|
#### 4.6.3 Retention (SHOULD)
|
|
|
|
* Cap number of entries (e.g. last 500 events)
|
|
* Prevent unbounded growth
|
|
|
|
---
|
|
|
|
### 4.7 Feature Requests & Feedback
|
|
|
|
#### 4.7.1 Feedback Mechanism (MUST)
|
|
|
|
* “Request features / report issue” link
|
|
* Opens email draft to:
|
|
**[bernd.worsch@binect.de](mailto:bernd.worsch@binect.de)**
|
|
|
|
#### 4.7.2 Tracking Export (MUST)
|
|
|
|
* Tracking data prepared as CSV
|
|
* CSV data:
|
|
|
|
* Embedded in email body and/or
|
|
* Copied to clipboard automatically
|
|
* Optional “Download CSV” button
|
|
|
|
**Note:**
|
|
Direct file attachments via `mailto:` are not reliably supported by browsers and are therefore not required.
|
|
|
|
---
|
|
|
|
## 5. Installation & Distribution
|
|
|
|
### 5.1 Distribution Channel (MUST)
|
|
|
|
* Automated publication via **Chrome Web Store**
|
|
|
|
### 5.2 Installation Requirements
|
|
|
|
* Chrome browser (desktop)
|
|
* User installs extension from Chrome Web Store
|
|
* User grants required permissions explicitly
|
|
|
|
### 5.3 Permissions (Principle of Least Privilege)
|
|
|
|
Expected permissions include:
|
|
|
|
* `downloads`
|
|
* `storage`
|
|
* `activeTab` (optional)
|
|
* Host permission for Binect API endpoint
|
|
|
|
---
|
|
|
|
## 6. Deinstallation & Cleanup
|
|
|
|
### 6.1 User-Initiated Deinstallation (MUST)
|
|
|
|
* When extension is removed:
|
|
|
|
* All stored credentials are deleted
|
|
* All local tracking data is deleted
|
|
* No data remains outside the browser
|
|
|
|
### 6.2 No External State (MUST)
|
|
|
|
* No server-side state tied to installation
|
|
* No orphaned accounts or tokens
|
|
|
|
---
|
|
|
|
## 7. Technical Constraints
|
|
|
|
* Chrome Extension Manifest V3
|
|
* No background persistence beyond service worker lifecycle
|
|
* No external backend services
|
|
* No cross-browser guarantees in v1
|
|
|
|
---
|
|
|
|
## 8. Security Considerations
|
|
|
|
* Encrypted credential storage
|
|
* No silent background transfers
|
|
* Clear user confirmation before sending
|
|
* No hidden data flows
|
|
* Minimal permissions to pass Chrome Web Store review
|
|
|
|
---
|
|
|
|
## 9. Success Metrics
|
|
|
|
* Reduction in manual upload steps
|
|
* Successful sends per active user
|
|
* Low error rate
|
|
* No privacy or security incidents
|
|
* Positive user feedback via feature request channel
|
|
|
|
---
|
|
|
|
## 10. Future Considerations (Out of Scope for v1)
|
|
|
|
* Multi-profile destinations
|
|
* Rule-based automation (opt-in)
|
|
* Multi-browser support (Firefox, Edge)
|
|
* Token-based authentication (if API evolves)
|
|
* Organization-level deployment policies
|
|
|
|
---
|
|
|
|
**BinectChrome** is intentionally modest in scope:
|
|
a focused, trustworthy bridge between modern cloud software and physical mail — implemented where the user already works: the browser.
|
|
|
|
|
|
xxx
|