Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
1 change: 1 addition & 0 deletions CHANGELOG.md
Original file line number Diff line number Diff line change
Expand Up @@ -23,6 +23,7 @@
- Narrowed homepage and category privacy copy to production file-content processing and localized shared navigation and summary accessible names across all six interface languages.
- Added a live v2 promotion QA matrix that keeps blocked browser evidence separate from passing automated checks.
- Recorded completed manual Chrome release QA and verified EXIF Orientation preservation, advancing the documented v2 status to READY FOR PROMOTION without creating a release.
- Reorganized project documentation around a concise README and focused architecture, privacy, dependency, tool-status, and audit references.

- Removed the standalone planned Rotate PDF card; page rotation remains available as part of PDF Organizer.
- Moved shared browser image validation and decoding into `tools/shared/image.js` for PDF and Image tools.
Expand Down
432 changes: 42 additions & 390 deletions README.md

Large diffs are not rendered by default.

1 change: 0 additions & 1 deletion README.original.md

This file was deleted.

23 changes: 23 additions & 0 deletions docs/README.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,23 @@
# Secure Tools documentation

The root [README](../README.md) introduces Secure Tools. This directory owns detailed design, operational, privacy, and audit information.

## Current documentation

| Document | Responsibility |
| --- | --- |
| [Architecture](./architecture.md) | Static application structure, shared browser foundations, delivery, and future ecosystem direction |
| [Privacy model](./privacy-model.md) | Local-processing and network boundaries, storage, security controls, and bounded privacy claims |
| [Dependencies](./dependencies.md) | Production runtime inventory, versions, vendoring, licenses, and integrity ownership |
| [Tool status](./tool-status.md) | Production and planned surfaces, supported formats, behavior, and resource boundaries |
| [Image Metadata privacy](./image-metadata-privacy.md) | Format-specific inspection, cleaning, preservation, and verification semantics |
| [UX consistency audit](./ux-consistency-audit.md) | Shared interaction, accessibility, responsive, theme, and historical browser-QA findings |
| [i18n copy review](./i18n-copy-review.md) | Localization coverage and editorial review record |

## Release evidence

- [v1.0.0 release QA](./release-qa.md) is a historical Sprint 11 release-candidate snapshot. Its unchecked items remain historical and are not current requirements.
- [v2 promotion QA](./v2-release-qa.md) preserves the automated, manual Chrome, Orientation-regression, and promotion evidence for the v2.0.0 pre-release line.
- The root [changelog](../CHANGELOG.md) records release and change history; it is not a technical specification.

Detailed artifact hashes and upstream provenance remain beside each dependency under [`assets/vendor/`](../assets/vendor/), where automated release gates verify them.
72 changes: 72 additions & 0 deletions docs/architecture.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,72 @@
# Architecture

## Application model

Secure Tools is a static GitHub Pages application built with semantic HTML, CSS, and Vanilla JavaScript ES Modules. It has no framework, build step, backend, database, authentication service, runtime API, or required package installation.

Production routes load application code and pinned libraries from the same origin. File-processing workflows run through browser APIs and in-memory data. The [privacy model](./privacy-model.md) defines the limits of that statement.

## Information architecture

The homepage points to stable category hubs instead of maintaining a flat list of every utility:

- PDF: six production tools;
- Image: four production tools;
- Privacy: a cross-category hub for the two metadata tools;
- Scan/OCR and Media: planned, non-interactive surfaces.

Each production tool owns a route under `tools/<category>/<tool>/`. The legacy `/tools/image-to-pdf/` route is a static migration page to `/tools/pdf/images-to-pdf/` with a visible fallback link.

```text
.
├── index.html, 404.html
├── about/, privacy/
├── css/ shared design and page styles
├── js/ theme, i18n, configuration, locale catalogs
├── tools/
│ ├── shared/ input, validation, output, save, PDF, and UI foundations
│ ├── pdf/ PDF hub and production tools
│ ├── image/ Image hub and production tools
│ ├── privacy/ metadata-tool navigation hub
│ ├── scan/, media/ planned category pages
│ └── image-to-pdf/ legacy static redirect
├── assets/vendor/ pinned same-origin runtime libraries
├── docs/ technical, privacy, and audit records
└── tests/ static and functional validation
```

The current production inventory and tool-specific behavior live in [tool status](./tool-status.md).

## Shared browser foundations

- `js/main.js` initializes shared theme and internationalization behavior.
- `js/theme.js` owns Light, Dark, and System selection, OS preference observation, and persistence.
- `js/i18n.js` resolves six supported languages, applies translations without reload, updates document metadata and `<html lang>`, and preserves tool state when language changes.
- `js/config.js` centralizes repository links.
- `tools/shared/` owns common file admission, signature validation, image/PDF helpers, queue conventions, local save behavior, and shared tool presentation.
- The File System Access API is used when available; a revoking Blob-download fallback serves other browsers.

Tool implementations retain specialized models when their workflows differ. Organizer uses a page grid and PDF rendering lifecycle; Metadata tools use bounded inspection models and fail-closed output verification. Shared UI does not erase these tool-specific guarantees.

## Dependencies and processing

Runtime libraries are checked into `assets/vendor/` with their package metadata, license, upstream provenance, and integrity information. Production does not install packages or fetch CDN code. See [dependencies](./dependencies.md).

Image conversion, resizing, and compression use browser decode, Canvas, and encode APIs. PDF manipulation uses pinned PDF libraries; PDF rendering uses a same-origin PDF.js module and worker with optional remote assets disabled. Metadata cleaning uses format-specific paths documented in [tool status](./tool-status.md) and [Image Metadata privacy](./image-metadata-privacy.md).

## Development and delivery

Local development requires only an HTTP server. The authoritative test entry point is `node tests/run-all.mjs`.

`.github/workflows/ci.yml` validates pull requests and pushes to `main` using Node.js 24. It checks commit-range whitespace, JavaScript syntax, and the repository test suite without installing a production dependency or adding deployment behavior.

Development uses short-lived branches and normal merge commits. Shared `main` history is not force-pushed or rewritten. GitHub Pages can publish `main` from the repository root; relative links support both the `/Secure_Tools/` project path and root-hosted deployments.

## Ecosystem direction

Secure Tools may evolve as both:

- a host for lightweight built-in browser tools; and
- a discovery hub for separately deployed companion applications that need different runtime or resource models.

This is a direction, not a current integration contract. There is no companion registry, external-application schema, plugin framework, service discovery mechanism, or v3 navigation implementation in the present architecture.
25 changes: 25 additions & 0 deletions docs/dependencies.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,25 @@
# Production dependencies

Secure Tools pins production libraries as same-origin static files under `assets/vendor/`. Runtime pages do not install packages, use a CDN, or automatically check for updates.

| Dependency | Version | Purpose | License | Detailed record |
| --- | ---: | --- | --- | --- |
| jsPDF | 4.2.1 | Images to PDF generation | MIT | [Vendor README](../assets/vendor/jspdf/README.md) |
| pdf-lib | 1.17.1 | PDF inspection, document-info cleaning, page copying, merge, split, and organization | MIT | [Vendor README](../assets/vendor/pdf-lib/README.md) |
| JSZip | 3.10.1 | Local multi-file Image and PDF archives | MIT license choice | [Vendor README](../assets/vendor/jszip/README.md) |
| PDF.js (`pdfjs-dist`) | 6.2.108 | PDF Organizer thumbnails and PDF to Images rendering | Apache-2.0 | [Vendor README](../assets/vendor/pdfjs/README.md) |
| secure-metadata | 0.1.1 | JPEG, PNG, and WebP metadata inspection, cleaning, and verification | MIT | [Vendor README](../assets/vendor/secure-metadata/README.md) |

## Vendoring and integrity

Each vendor directory contains the deployed runtime files plus its license and package/provenance metadata. The vendor README is the human-readable source of truth for upstream artifacts and exact runtime hashes. `tests/release-gate.test.mjs` verifies the approved file inventory, versions, metadata, licenses, and runtime SHA-256 values.

The summary table intentionally does not duplicate every artifact hash. Keeping exact values beside the bytes they validate reduces drift while preserving a navigable inventory here.

## secure-metadata integration

The current runtime is `secure-metadata v0.1.1`, release commit `cdcd138e48d30618b6d76f7c6538cd43ad660b53`. Its browser artifact is `secure-metadata-0.1.1.browser.js` with SHA-256 `4bfcc9e0e484db12192e46f076c19cf69cd36c496c7cfbb5a71c1057cbcccba1`.

The browser and package artifacts were verified against the published `SHA256SUMS` manifest and GitHub asset digests. The deployed browser bytes match the build inside the release package. Secure Tools imports that artifact only from its own origin; replacement requires a new explicit provenance and integrity review.

The supported privacy and preservation behavior is documented separately in [Image Metadata privacy and verification](./image-metadata-privacy.md).
42 changes: 42 additions & 0 deletions docs/privacy-model.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,42 @@
# Privacy and local-processing model

## What local processing means

For supported production workflows, Secure Tools reads and transforms file contents in the browser on the user's device. It does not send those contents to an application upload service. The site requires no account and includes no analytics, advertising, behavioral telemetry, or tracking pixels.

This guarantee applies to documented production tools and supported formats. It is not a claim that every browser extension, operating system component, external destination, unsupported file structure, or future companion application has the same behavior.

## Network boundary

Production pages load HTML, CSS, JavaScript, and vendored libraries from the Secure Tools origin. First-party processing code does not use `fetch`, `XMLHttpRequest`, `WebSocket`, `EventSource`, or `sendBeacon` for file processing. It does not load runtime codecs, workers, fonts, translations, or libraries from a CDN.

Production Content Security Policy uses `connect-src 'none'` and restricts scripts, styles, frames, objects, base URLs, and form actions to the documented static model. User navigation to an external source link is a deliberate browser navigation governed by the destination's policy, not a processing request.

Blob URLs and data URLs are browser-local references used for previews, prepared images, and downloads. The application revokes temporary object URLs when they are no longer needed.

## Storage and source handling

Theme and language preferences are the only application values stored in `localStorage`. Source files and outputs are not placed in application cloud storage. Tools retain in-memory source state only as needed for the active workflow and release object URLs, rendering tasks, models, or byte references when sources are cleared or replaced.

Save operations use the browser's File System Access picker where available and a local Blob-download fallback elsewhere. Cancellation and write failures do not silently convert into successful saves.

## Input and resource boundaries

Tools validate supported signatures and apply bounded file, queue, dimension, pixel, page, render, metadata-display, and aggregate-work limits appropriate to each workflow. These controls reduce accidental memory and workload pressure; they are not malware scanning or a guarantee that arbitrary hostile files are safe.

The exact production surface and shared image limits are recorded in [tool status](./tool-status.md). Automated tests cover spoofed signatures, corrupt and protected inputs where applicable, runtime network invariants, dependency integrity, safe DOM sinks, save paths, and resource boundaries.

## Bounded privacy claims

Secure Tools does not claim that a file is “100% private,” completely anonymous, universally sanitized, or free of all hidden information.

- Canvas-based Image Converter, Resize, and Compressor create new pixel encodings and do not preserve EXIF metadata, but they are not configurable forensic metadata cleaners.
- Image Metadata reports only structures supported by the pinned parser. Partial or opaque results remain explicitly non-exhaustive; unknown structures are not guessed away.
- PDF Metadata removes and verifies the eight supported document-info fields. It does not claim complete XMP, attachment, annotation, hidden-content, or structural sanitization.
- Images to PDF and PDF page-copying tools preserve or transform content according to their documented workflow; they are not privacy cleaners.

Format-specific Image Metadata semantics—including decoded versus opaque data, EXIF Orientation and ICC preservation, unknown structures, and fail-closed verification—live in [Image Metadata privacy and verification](./image-metadata-privacy.md).

## Verification

Privacy behavior is inspectable through source code, Content Security Policy, the browser Network panel, vendored dependency records, and automated tests. Release-specific automated and manual results are retained in the [documentation index](./README.md#release-evidence).
Loading
Loading