commit 2af9c4ef89174ff4c3e650fcfe8f5a3dfa0916c9 Author: Bernd Worsch Date: Mon Jan 12 17:30:56 2026 +0000 Add ProductRequirementsDocument diff --git a/ProductRequirementsDocument.md b/ProductRequirementsDocument.md new file mode 100644 index 0000000..eb9af4b --- /dev/null +++ b/ProductRequirementsDocument.md @@ -0,0 +1,311 @@ +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 \ No newline at end of file