Sub-processors and security measures

• Amazon Web Services — receiving, storing and processing telemetry data (the data the SDK built into your application sends: errors, performance measurements, sessions, logs and the like; the same below). Tokyo region (ap-northeast-1).
• Supabase (SUPABASE PTE. LTD., Singapore) — the index used to list and search telemetry data, and account data. Infrastructure in the Tokyo region.
• Vercel (Vercel Inc., United States) — this website and the dashboard. Your telemetry data never passes through it.
• Cloudflare (Cloudflare, Inc., United States) — bot protection at sign-up (Turnstile), from when accounts become available.

Before adding or changing a sub-processor, we announce it on this page and notify your registered email address at least 14 days in advance. If a change is needed urgently for security reasons, we may make it first and notify you without undue delay afterwards.

As set out in the Privacy Policy, we take the cross-border measures for the onward transfer of the index to Supabase ourselves.

Organised by the items of Annex 10 to the Personal Information Protection Commission’s general guidelines. kromise is run as a sole proprietorship with one operator.

The telemetry data you entrust to us is used only to receive, store and display it, to send the notifications you have configured, and for the incident response, abuse detection and usage metering these require. They are not used for statistics, product improvement or machine learning. This is set out in the Terms and the Privacy Policy.

• The procedures for storing, deleting and exporting data are documented.
• The limits on how many events and how many bytes the ingest accepts are set in the program, not in configuration.

• The person responsible is the operator (one person).
• If a breach is found, our first report reaches you within 72 hours of our becoming aware of it.
• At least once a year, we check how our foreign sub-processor carries out its measures and the regime of its country.

Only the operator can access stored data. If staff are ever engaged, they will sign a confidentiality undertaking and be given access only as far as their work requires.

Data is stored in our sub-processors’ (AWS, Supabase) data centres, whose physical security they manage. When we fulfil an export request, the data passes through the operator’s computer; the local copy is deleted once it has been delivered.

• Traffic is encrypted with TLS 1.2 or later; unencrypted connections are redirected to HTTPS.
• Stored telemetry data is encrypted at rest (AES-256), and public access to the storage is blocked.
• Reading stored telemetry data requires a per-project read token. Only a hash of each token is kept, never the token itself.
• The write key in the DSN cannot read stored data.
• The index database uses row-level security so that one project cannot read another's data.
• The body of the telemetry data is deleted automatically after 30 days, access logs after 30 days, and the ingest’s operation logs after 14 days. The index used for listing and searching is likewise deleted after 30 days.

For sub-processors outside Japan, we reviewed the Commission’s published country reports for Singapore and the United States before putting measures in place.

For an annual written report on how these measures are carried out, write to kromise@jugoya.ai.

This English text is provided for convenience. The Japanese version is the authoritative one.