Privacy Policy

Version v2.0 · Effective 2026-11-13 · Applies to Everymark (Android, package top.tooyang.everymark) and its official site heji.wang.

Language note. This page is an English rendering of the authoritative Chinese policy, which is published at /privacy.html. Where the two differ, the Chinese version governs.

What changed in v2.0 (2026-11-13): the official site heji.wang has completed its ICP filing and is open to the public — filing number 浙ICP备2026096607号 (obtained 2026-11-13). This version replaces the old wording that said the domain “opens after the ICP filing is approved” and that it was “intercepted on the cloud side by an unfiled-domain block” — the site is now publicly reachable (HTTP 200, HTTPS with a valid certificate). The site footer now shows the ICP filing number and links to the MIIT filing system (https://beian.miit.gov.cn/), as the filing rules require. The public security filing and the APP filing have not been obtained yet and are stated as in progress — no number is invented for them. Everything else is unchanged: the data collected, the ten outbound paths, the permissions table, the cross-border notes and your rights all stay exactly as they were; this version changes no personal-information processing behaviour, it only corrects the outdated “not filed yet / not open yet” facts. Existing users will see the consent screen once more, because the policy text changed and the version was incremented.

What changed in v1.9 (2026-11-10): the classification and semantic-model wording now matches the current app. Classification first runs local rules on your device; only when those rules cannot decide, and you configured an external model with a key, is that record sent to your endpoint as a fallback. The local semantic model is not used to decide categories; it is only used for duplicate detection and similar records. After you accept the first-launch privacy notice, app startup may download the semantic model in the background. The download is idempotent: an installed model is skipped, and no record content is included. There are still ten outbound paths and no new vendor. Existing users will see the consent screen once more, because the policy text changed and the version was incremented.

What changed in v1.8 (2026-11-05): one new outbound path — OCR text → external model interpretation (path 10). The text that on-device OCR reads off a photo may now be sent to the endpoint you configured, to be read into a structured interpretation (document type / report date (with the source line it came from) / one-line conclusion / key points). This happens only when all of these hold: you configured an external model and entered a key; the “OCR text interpretation · via cloud model” setting in Settings is on (it is on by default); the record has an image or PDF attachment; and that attachment's OCR text is at least 40 characters. A record sends at most 3 attachments. What is sent is the text (the main part, excluding what was judged background noise) — not the photo itself, not the record text, not any other record. The structured interpretation is stored on your device and is not written into the record text. It is never used for model training. If you use one of the 7 overseas providers, this OCR text crosses the border as well (section 8). The other clauses are unchanged. This version means existing users see the first-launch consent screen once more, because the policy version changed.

1. Who we are

2. In one sentence

Everymark is a local-first record app: your records, attachments, categories and semantic vectors live on your own phone, and under the default settings your records are never uploaded to any server.

We do not require you to register or sign in. No ads, no third-party analytics, no crash reporting, and your content is never used for model training.

Network activity worth stating up front, so “not uploaded by default” is not misread: the shipped app has outbound paths that carry nothing from your records — the automatic update check (at most once an hour, fetching one static version manifest; the server sees your IP address and request time), Google ML Kit's own diagnostic usage telemetry (no record content, no input; no in-app switch), and the semantic-model download after first-launch consent (model files only; an installed model is skipped). Classification runs local rules first; only if those rules cannot decide, and you configured an external model with a key, is that record sent to your endpoint. Two more paths are on by default but easy to turn off: image content recognition (path 8, which can send up to 3 photos) and coordinates-to-place-name reverse geocoding (path 9, which sends coordinates only). One more was added in v1.8: OCR text interpretation (path 10, which sends the text OCR read off a photo — never the photo itself — to the endpoint you entered). Section 6 lists all ten paths.

3. What is recorded, and where it comes from

On first launch Everymark shows one screen: a summary of this policy with an “Agree and start” / “Do not agree” choice. No checkbox is pre-ticked. Until you agree, Everymark makes no application-initiated network request — the main interface is not even created. If the policy version changes, you are asked again.

While you use the app, the following is recorded on your own device:

The “device identifier” is a random string generated on first run. Its only purpose is to tell apart writers when several devices share one sync folder. It is not an IMEI, not the Android ID, not an advertising ID — Everymark reads no system device identifier. Everymark asks for location permission only if you authorise it, and then uses it for exactly two things: taking one coordinate point per record, and resolving that point to a place name.

We do not collect contacts, call logs, SMS, Bluetooth devices, system device identifiers (IMEI / Android ID / advertising ID) or clipboard contents. Location information is not in that list — it is optional collection, and it exists only if you authorise it. But location is not “never leaves the device” either (this is the wording since v1.5): the coordinates may be handed to a geocoding service to resolve a place name (coordinates only, see path 9 in section 6) — and we the operator never receive them, because Everymark has no server, no accounts and no copy of any location data.

We cannot automatically recognise faces or licence plates.

About “place” (the wording changed on 2026-11-02 — the old “we collect no location information” no longer holds): Everymark can have location information, but only after you authorise it. Two layers, extracted first and located second: ① extract first — a readable place is pulled out of the record text and the OCR text of photos by a local regex extractor, which recognises endings such as “XX店 / XX公司 / XX市 / XX区 / XX路 / XX街 / XX广场 / XX中心”. This layer needs no permission at all; it is purely local. ② only if nothing can be extracted — the app takes the most recent coordinate (latitude / longitude, from a fix within the last 5 minutes), which does require you to authorise location. If neither layer succeeds, the record simply carries no location — no place is invented: no IP-based location, and no stale coordinate standing in for the current one. Coordinates → place name (reverse geocoding): once there is a coordinate, it can be handed to a geocoding service to get a place name (“XX mall”, “XX housing estate”), shown next to the time of that record. This step needs the network: coordinates only (no text, no attachments, no record content), sent either to the phone's own geocoder (zero configuration, on by default, needs no account and no key) or to the Amap web service if you entered your own Amap web-service key in Settings (without a key, only the system route exists). It is sent once, at the moment you submit a record — there is no continuous background reporting. The “Turn coordinates into place names” switch in Settings is on by default; turn it off and not a single reverse-geocoding request is ever sent, and the interface then shows only latitude and longitude. If the lookup fails, the coordinates are still shown — no place name is invented. Each record carries one coordinate point — Everymark does not record your movement trail (after you authorise it the app keeps one location listener, only to obtain that point; there is no “where you are” list). Coordinates stay on your device (the SQLite database and the sync folder you chose); but coordinates may be handed to the geocoding service — no text, no continuous reporting; and the Amap key you entered is stored only in the local keystore and never enters the sync folder. The web preview build has no GPS layer at all — browsers only allow location in a secure context (https or localhost), and the preview page is served over a plain LAN address, so the browser refuses it: that layer exists only in the real app (it is not broken).

One honest caveat: offline OCR extracts whatever text is printed in a photo, which may include identity or financial numbers. Everymark does not structure that information, but the raw text enters the record unchanged and stays on your device with it. If you enable cloud transcription or sync, that text leaves the device along with the rest. If you configured an external model and left “OCR text interpretation · via cloud model” on, that OCR text may also be sent to the endpoint you entered, to be interpreted (path 10 — the text only, never the photo).

4. Where it is stored, and for how long

Everymark has no server-side account system, so we hold no copy of your records. Deletion is yours, not ours. Android backup and device-transfer migration are switched off.

Where location information is stored: the coordinate, the readable place and the resolved place name are one field of each record, stored in the same place as that record — the local SQLite database everymark.db, and (if you enabled sync) the sync target you chose. Everymark builds no server for location information, has no third-party location-service account and no caching server (the Amap key is your account, not ours). But note that the reverse-geocoding request does leave a copy on the provider's side: at the moment the coordinates are handed over, that provider handles the request under its own rules (Everymark neither controls nor can see what it keeps) — this is stated in path 9 of section 6 and in section 8.

5. What we use it for

Only to provide recording, categorisation, search, export and sync for you, plus the transcription, external-model categorisation, image content recognition, OCR text interpretation (added in v1.8 — reading the text recognised on a photo into a structured interpretation) and sync that you configure yourself. Not for advertising or profiling, not for model training or redistribution, not for manual review; we do not sell or exchange it.

6. When anything goes out — ten paths, and only ten

Everymark has no background push, no ads, no analytics, no crash reporting. Outside these ten paths the app makes no network request.

Path 9 is not like paths 1 and 5: it contains none of your record text (coordinates only), but it is on by default — the phone's own geocoder needs zero configuration, no account and no key. You can turn “Turn coordinates into place names” off in Settings, and then not a single reverse-geocoding request is sent; the Amap route only exists if you entered a key.

Path 10 sends “the writing on the photo”, not “the photo” — it sends the text that offline OCR read (the main part), not the photo itself (that is path 8); nor the record text, nor any other record. Turn “OCR text interpretation · via cloud model” off in Settings and not a single character is sent; with no external model configured this path does not exist at all. The interpretation that comes back stays on your device (it is not written into the record text) and is never used for model training.

Does the text of my records reach a language model? Only if you configured one and the local rules cannot classify that record. In that case the record text is sent to your endpoint when you submit it, and the result returns to your device. If the local rules can decide, or no external model is configured, no categorisation request is sent. Without an external model, an undecided record is left unclassified; the semantic model does not decide categories. Deduplication and tag suggestions are always on-device. Only path 1 uploads audio, and only path 8 can send photos — and only while the image-recognition setting is on. Path 9 sends coordinates only, never text or attachments. Path 10 sends the text OCR read off a photo — never the photo, never the record text — and only while the OCR-interpretation setting is on and that attachment has at least 40 characters of OCR text. Semantic vectors are never synced. API keys and passwords are never synced.

Do photos reach a language model? That depends on your configuration and your settings as well. With an external model configured, the “Image content recognition” switch on (it is on by default), a record whose text is thin, and a photo that is not a text-heavy image such as a receipt or a screenshot — at submit time up to 3 photos go to the endpoint you entered, and a one-line content description comes back (path 8). If any one of those conditions fails, not a single photo is sent; with no external model configured the feature does not exist at all and not one request is made. The description is only a note attached to the attachment (stored with it on your device, not written into the record text); it does not take part in place extraction (a place comes only from the record text and the OCR text — characters actually written on the image).

7. Third-party components

Google ML Kit Chinese text recognition (bundled, recognition fully on-device — but the same SDK carries the diagnostic telemetry described in path 7), ONNX Runtime (on-device inference), Android system SQLite, flutter_secure_storage (keystore-encrypted preferences, not database encryption), standard system pickers (camera, gallery, files, record, playback, share, folder access), webdav_client (only when you enable WebDAV sync), the Android system geocoder Geocoder (a system API, not a third-party SDK: it turns coordinates into a place name, and it is remote — it needs no account and no key, it is used once at submit time, it is on by default and can be turned off — see path 9), the Amap (Gaode) web service (reverse geocoding, only if you entered your own Amap web-service key; coordinates only, never text), and http (model calls, model download, S3 sync, and the automatic update check).

We integrate no ads SDK, no third-party analytics SDK, no crash reporting SDK, no push SDK, no behaviour analytics service. Everymark provides 18 configurable model provider presets (9 based in China, 7 overseas, 2 local) plus WebDAV and S3-compatible object storage interfaces.

Only 4 of those 18 providers actually offer a transcription interface (OpenAI, SiliconFlow, Zhipu GLM and MiniMax); the other 14 do not — the app says plainly that it does not support it, rather than sending your recording somewhere and hoping. The 2 local presets (Ollama, LM Studio) point at localhost by default and do not leave the network, but their address is editable — change it to a remote address and they do go out (see section 8).

8. Cross-border transfers

If you use OpenAI for transcription — the only one of the 7 overseas providers that has a transcription interface — your recording is transferred to servers outside mainland China, a cross-border transfer of personal information. If the local rules cannot classify a record and you chose an overseas provider for fallback categorisation, the text of that record is transferred too. Choosing an overseas provider for OCR text interpretation does the same thing with the text OCR read off your photos (the photo itself is not sent). We do not make that choice for you and we never forward your data to a provider on your behalf. If you are in mainland China and want to avoid any cross-border transfer altogether, use the 3 China-based providers that support transcription (SiliconFlow, Zhipu GLM, MiniMax) or the 2 local ones.

Five further paths exist whose destination you set or which a default determines: (1) a sync target can point anywhere, including overseas servers — the default S3 endpoint is s3.amazonaws.com, which is overseas, so using the default S3 target unchanged already is a cross-border transfer; (2) the “local model” presets point at localhost by default but their address is editable, and changing it to a remote address sends record text there; (3) the automatic update check resolves through an overseas CDN node, so your IP address and request time travel overseas even though no content does; (4) an overseas provider chosen for categorisation receives that record's text; (5) an overseas provider chosen for OCR text interpretation receives the OCR text of that record's photo attachments — the text only, never the photo, and only while the “OCR text interpretation · via cloud model” setting is on and the attachment has at least 40 characters of OCR text. Turning that setting off, or configuring no external model at all, means path (5) never happens.

Location information: coordinates are not sent to any third-party location service (there is no “where you are” and no trail is recorded), but “coordinates → place name” hands the coordinates to a geocoding service — and whether that step is a cross-border transfer depends on where that service's backend is: the Amap web service you configured yourself is based in mainland China (so no transfer), while the phone's own geocoder is backed by the device and the system (on a machine with Google services it is usually Google, i.e. overseas; on most Chinese machines without GMS there is usually no such backend at all, and the lookup simply fails and falls back to showing coordinates). Which one applies is device-dependent and therefore UNVERIFIED — we have not measured it on your device. If it lands on an overseas backend on your machine, the coordinates are a cross-border transfer of location information and would need separate consent; we do not make that judgement for you — you can turn “Turn coordinates into place names” off in Settings, and then not a single coordinate is sent. If you set your sync target overseas, coordinates also travel with the record along path (1) above.

9. Permissions

Everymark requests no contacts, phone state, Bluetooth or broad storage permissions. Photos and videos are picked through the system picker, per item.

Two further permissions are pulled in transitively by third-party libraries (ACCESS_NETWORK_STATE from the androidx.media3 playback stack, and the self-signed broadcast-protection permission top.tooyang.everymark.DYNAMIC_RECEIVER_NOT_EXPORTED_PERMISSION from androidx.core); Everymark neither uses them actively nor asks for them. The photo-library permissions READ_MEDIA_IMAGES / READ_MEDIA_VIDEO were removed from the package on 2026-10-26 — picking photos or videos goes through the system picker, per item.

10. Your rights

Access and copy: view in the app, or export everything as a zip. Correction: edit text, categories, tags and entities in the detail page. Deletion: delete a record (soft delete with a tombstone; attachments go with it; uninstalling removes all local data). Withdrawal: removing a provider stops transcription and external-model categorisation; removing a sync target stops sync; the first-launch consent can be withdrawn in Settings; the location authorisation can be switched off in the system settings, after which Everymark takes no new coordinates (coordinates already collected stay on your device and follow that record's deletion rules); the “Turn coordinates into place names” switch can be turned off in Settings, after which not a single reverse-geocoding request is sent (the interface shows only latitude and longitude); the “OCR text interpretation · via cloud model” switch can be turned off in Settings, after which the text read off your photos is no longer sent to your model (not a single character); and deleting the Amap key you entered switches off the Amap route. Account closure: Everymark has no accounts — uninstalling is equivalent to closing. Complaints: contact us; we answer within 15 working days.

Location information on deletion and export, stated plainly: deleting a record deletes its location too — the place text, the coordinates and the resolved place name are one field of that record and go with it. Be aware that the deletion is a soft delete: the row is only marked “deleted” with a revision number, it is not wiped, so the marked row still carries its place and coordinates until you clean it out in your own storage or uninstall the app; a record marked as deleted also carries its location when it is synced. “Export all” produces a zip that includes the location (both the place and the coordinate columns are exported), so please keep that zip carefully. Uninstalling clears everything with the app-private directory, leaving no residue on the device. And the one reverse-geocoding request that already happened cannot be taken back: at that moment the coordinates were handed to the geocoding service, and that provider keeps the request under its own rules (Everymark neither controls nor can delete its copy) — to make that step never happen, turn “Turn coordinates into place names” off and delete your Amap key.

When you hand the sync folder to an agent or a third-party tool, your records enter that tool's control. Its retention, training and redistribution behaviour is outside Everymark's responsibility, and we cannot view or withdraw it. Everymark itself never reads those folders; the in-app “copy MCP command” button writes to the clipboard and never reads it. Everymark v1 does not expose a phone-side local-network endpoint and opens no remote interface to any agent.

11. Security

Credentials are stored in Keystore-encrypted preferences and never enter the sync folder — that includes the API keys, the WebDAV password, the S3 secret key and the Amap (Gaode) web-service key. Attachments are content-addressed by SHA-256 and their metadata stores only digest, type and size. Writes are atomic (temp file then rename). Under the default configuration — no external model configured — your record content has no background network behaviour, subject to these stated paths: the automatic update check; ML Kit's own diagnostics; the semantic-model download after consent (model files only, idempotent); external-model categorisation only when local rules cannot decide and you configured the provider; reverse geocoding of coordinates into a place name (on by default; coordinates only, sent once at submit time and not continuously); and interpretation of OCR text through an external model (on by default; the main text read off a photo, only when it is at least 40 characters, sent once at submit time and not continuously; never the photo or the record text; the setting turns it off). We do not claim “never touches the network” and we do not claim AES256 encryption of your database.

12. Minors

Everymark is designed for general users. Users under 14 should use it with a guardian, who performs consent actions on their behalf. We do not actively collect minors' personal information and do not profile or market based on record content.

13. Changes to this policy

When the policy changes, the version number and effective date on this page are updated. Material changes to purposes, data categories or outbound paths are shown prominently in the app and consent is requested again.

14. Contact

Phone 189****8149 · Email yfxd**s@gmail.com · Site: https://heji.wang (ICP filing approved and the site is open to the public; website ICP filing number 浙ICP备2026096607号) · Operator 嘉兴市秀洲区王江泾镇合乐养生馆（个体工商户） · Unified social credit code 92330411MAKCNXUY9B

Website ICP filing: 浙ICP备2026096607号 · Public security filing: in progress · APP filing: in progress.