memojang Privacy Policy

한국어 안내 ↑

1. Information processed and why

Note titles, bodies, and tags may contain personal or sensitive information you choose to enter, such as names, contact details, or health-related information. The extension also processes local note IDs, creation and modification dates, pinned status, revisions, and deletion state. History of earlier saved notes may include their previous titles, bodies, tags, other note details, and capture times. Preferences such as language, theme, and autosave, plus open note tabs and caret/session details, may be retained locally.

These details support writing, saving, displaying, searching titles/bodies/tags, tag filtering, sorting, conflict resolution, reviewing earlier saved versions, migration, and user-requested backup or recovery. The extension does not require a developer account or sign-in and has no feature for reading browsing history or behavioral advertising analytics. The v4.7.2 manifest requests only the storage extension permission and no host permissions.

Important: Not collecting notes on a developer server does not mean notes contain no personal data or that the extension does not process personal information locally.

2. On-device storage and legacy records

• Current notes and tags: Titles, bodies, tags, and note metadata are stored in the docs store of the extension's local IndexedDB database (memojang_workspace_v2). Tags are note metadata separate from the body HTML and support searching and filtering. There may be up to 12 tags per note, each 1–32 UTF-16 code units after normalization; case-insensitive duplicates, commas, and control characters are disallowed. Revisions are used to handle edits from multiple tabs.
• Per-note edit history (since v4.7.0, with tags in v4.7.1): Earlier committed note titles, bodies, optional tags, pinned status, note IDs, creation and modification dates, revisions, and capture times may be retained in the same local IndexedDB meta store (keys beginning note_history_v1:<note ID>). A meaningful change to the title, body, pin, or tags makes the previously saved version eligible for capture, but snapshots are spaced at least 30 seconds apart. Each note is limited to 20 snapshots and a combined 512Ki UTF-16 code units of stored title/body/tag text; capture is skipped when the earlier body exceeds 64Ki code units, while ordinary saving continues. Limits may cause snapshots to be skipped or older ones to be discarded; there is no fixed expiration date that automatically erases all snapshots. This is not a complete record of every edit or unsaved keystroke.
• Deletion records: IndexedDB may retain a minimal tombstone containing a deleted note's ID and revision to prevent stale tabs from reviving it. The tombstone does not retain the note title or body, but earlier content can remain separately in legacy storage or your backup files.
• Legacy notes: Original records under memojang_workspace_docs_v1 in chrome.storage.local are not automatically removed after migration. Old and current note data can therefore coexist in one browser profile.
• Internal metadata: IndexedDB can contain migration/reconciliation records and markers preventing duplicate user-approved recovery copies. Preferences and shared tab-session state can be stored in chrome.storage.local, localStorage, and sessionStorage.

3. Reviewing and manually recovering older notes

After a downgrade and re-upgrade, notes with new IDs present only in the older store can be added to current storage. Existing current notes and deletion records are never automatically overwritten by older content.

If a legacy note and current note share an ID but differ in title, body, or pinned status, you must review them and explicitly approve that individual recovery. This creates a separate note with a new ID; valid tags in the recovered legacy record are preserved, but a tags-only difference does not by itself create a review candidate. The operation does not alter the current note or any deletion tombstone. A local record prevents duplicate recovery copies. Because older versions did not keep enough per-note history, the extension cannot reliably establish which version is newer. Compare important notes before choosing to recover a copy.

Restoring edit history: You can compare earlier committed versions of the current note. Only after explicit confirmation does restoration create a separate new-ID note with the snapshot's content and valid tags. It never overwrites the current note or undeletes a tombstone, and refuses a requested restore if the source has since changed or been deleted in another tab. Edit-conflict copies and restored copies created when backup note IDs collide also retain valid tags. Copies are stored locally like other notes.

4. Backup files and security

• You can manually export a .jsonl backup through your browser's download function and import .jsonl or legacy .json files locally. Individual text/Markdown export and Print/PDF are also user-initiated. Imports are processed in the browser, not uploaded to a developer server.
• v4.7.2 JSONL format: Export includes current note titles, bodies, metadata, and some preferences. For notes with tags, an optional seventh tags field (an array of tag strings) is added to the six-field note record and covered by the per-note SHA-256 and whole-file integrity checks. Notes without tags retain the six-field layout. v4.7.2 can import older six-field .jsonl files and legacy .json files containing valid tags. However, a tagged v4.7.2 JSONL backup may be rejected by v4.6.4 or earlier importers. Keep older backups if you may downgrade.
• Downloaded JSONL backups may contain full current notes, tags, and related preferences. SHA-256 integrity checks do not provide encryption. JSONL backups and plain-text exports receive no app-level encryption. Protect them when sharing a device, attaching files to email, or storing them on cloud drives; apply separate encryption if necessary.
• Earlier per-note edit history and history snapshots are NOT included in full v4.7.2 JSONL backups. Backing up current notes and tags does not transfer earlier revisions to another Chrome profile or guarantee they survive clearing extension storage.
• No application-level password lock, note encryption, cloud sync, or remote recovery service is provided. Anyone with access to your browser profile, device, or downloaded files may be able to read your notes. Operating-system disk encryption or backups/sync configured by you are separate.

5. Autosave, deletion, and retention

With autosave enabled, changes are written after a short delay. When autosave is off, you must save manually. Storage quotas or errors, abrupt browser/tab closure, or power loss before a write completes can cause the most recent changes to be lost. Check the save status and keep independent backups of important notes.

Deleting a note in v4.7.2: Successful normal deletion replaces its current title, body, and tags with a minimal deletion tombstone and removes its previous edit history (including older body and tags) within the same IndexedDB transaction. If history deletion fails, deletion of the note also rolls back. When a note with v4.7.0/v4.7.1 history was deleted during a v4.6.4-or-earlier downgrade, the old version may leave plaintext history in local meta. When you open a v4.7.2 New Tab page after re-upgrading and its note store initializes, the extension removes that history only if the note's exact ID is still an authoritative deletion tombstone. History belonging to live notes or IDs whose deletion cannot be verified is preserved. An interrupted or failed maintenance transaction rolls back its changes and can be retried at the next initialization. This does not delete earlier chrome.storage.local records, downloaded backups, or other browser/OS copies, and cleanup does not occur until a v4.7.2 New Tab page initializes the note store. Back up important data before clearing any extension storage.

Notes and settings can remain locally until you delete them or clear browser/extension storage. Deleting a note within the app does not guarantee erasure of its tombstone, earlier legacy copies, downloaded backups, or other browser/OS copies. You must manage downloaded files separately. Back up anything you need before clearing data or uninstalling the extension.

6. Transmission, third parties, and policy-page hosting

The current extension does not upload notes, tags, or edit history to a developer-operated server or use advertising/analytics trackers, remotely executed code, or its own cloud sync. The developer does not sell or rent this data or use it for behavioral advertising through the extension's normal operation. Sharing a backup yourself or storing it with another service is separate.

Hosting this privacy-policy webpage is separate from using the extension. The privacy notice is served through GitHub Pages at gssg100.github.io/memojang-privacy/. GitHub, as the website host, may process technical information such as visitors' IP addresses and access logs under its own privacy notices and retention practices. This does not mean the extension automatically transfers your notes to GitHub.

7. Contact and updates

For questions about this notice, local data processing, or policy changes: Developer: lemrlog | Email: lemrlog@gmail.com.

The v4.7.2-specific descriptions in this notice apply once that extension update is actually released. Users of v4.6.4 or earlier may have different storage, history, and deletion behavior. Consult the revision date and version information here for policy changes.