{"success":true,"data":{"id":"01a11f24-e051-7509-84f7-c979012ddbba","group":"eauth-terms","locale":"en","slug":"eauth-terms","version":"1.10","title":"EAuth Terms of Service","description":"Terms governing use of the EAuth authentication service, including the data processing agreement and the implemented technical measures.","body_markdown":"# EAuth Terms of Service\n\n**Version:** 1.10\n**In effect from:** 9 October 2026\n**Provider:** Krauss Software, sole proprietorship of Samuel Krauss, Oberägeri ZG, Switzerland, trading as Elchi Studios\n**Contact:** legal@elchi.dev\n**Applies to:** eauth.me, panel.elchi.dev, docs.elchi.dev and the SDKs\npublished under the EAuth name, and auth.elchi.dev, which redirects to eauth.me\nunder clause 2.4\n\n---\n\n## 1. Who these terms are between\n\n1.1 These terms govern your use of EAuth, an authentication service operated by\n**Krauss Software** (\"we\", \"us\"), the sole proprietorship of Samuel Krauss,\nseated in Oberägeri, Canton of Zug, Switzerland, trading under the name Elchi\nStudios. Krauss Software is not entered in the commercial register. Krauss\nSoftware is the counterparty to this agreement and Samuel Krauss, as its owner,\nis personally liable; Elchi Studios is the name under which the service is\npresented.\n\n1.2 \"You\" means the natural or legal person registering an application. If you\nregister on behalf of a company, you confirm you are authorised to bind it.\n\n1.3 \"End user\" means a person who signs in through your application using\nEAuth. End users are your users, not ours. We process their data on your\ninstructions under the Data Processing Agreement in Annex B.\n\n---\n\n## 2. The service\n\n2.1 EAuth provides OAuth 2.1 and OpenID Connect authentication: a hosted\nsign-in page, an authorization server and token issuance at eauth.me, and the\nmanagement console at panel.elchi.dev. The issuer identifier is\n`https://eauth.me`.\n\n2.2 We implement the OpenID Connect Core specification and the OAuth 2.0\nsecurity practices set out in RFC 9700. Where the service deviates from a\nspecification, the documentation at docs.elchi.dev says so.\n\n2.3 We may change, add or remove features. Where a change would break existing\nintegrations, we will give at least 90 days' notice by email to the address on\nyour account and in the changelog, except where a shorter period is necessary\nto address a security problem.\n\n2.4 Until 3 October 2026 the service was provided at auth.elchi.dev, under the\nissuer identifier `https://auth.elchi.dev`. Since that day, every request to\nauth.elchi.dev is answered with a permanent redirect to the same path at\neauth.me. Changing the issuer breaks integrations that name it, which would\ncall for the notice in clause 2.3. None was needed: on that day every\napplication registered with EAuth belonged to Elchi Studios, and no one\noutside Elchi Studios had an account, so no integration of anyone else was\naffected.\n\n---\n\n## 3. Cost, and what \"free\" means\n\n3.1 EAuth is provided free of charge. There is no paid tier, and we do not\nsell your data or your end users' data. We do not serve advertising.\n\n3.2 Free does not mean unconditional. Section 6 sets out usage limits that\nexist to keep the service available for everyone, not to create an upgrade\npath.\n\n3.3 We do not reserve a right to start charging for what is described here.\nThere is no paid tier, no usage threshold that becomes an invoice, and no\nfeature withheld to create one. This is stated as a term rather than as\nmarketing, because a promise made only on a website is worth what a website is\nworth.\n\n3.4 These terms cover the services listed at devs.elchi.dev. Being listed\nthere requires being free permanently, so the commitment in 3.3 and the\nlisting are the same fact stated twice.\n\n3.5 A service with a paid tier is not listed at devs.elchi.dev and is not\ngoverned by this document. It has its own page and its own terms, which you\nwill see before registering for it. It is administered through the same\nconsole, because that is where credentials belong regardless of price, and\nbeing in the console implies nothing about what a service costs.\n\n---\n\n## 4. Availability\n\n4.1 **We give no availability guarantee.** There is no service level\nagreement, no uptime commitment, and no compensation for downtime.\n\n4.2 This is a deliberate consequence of clause 3.1. A free service cannot\nresponsibly promise availability it is not paid to underwrite, and we would\nrather say so plainly than publish a figure we cannot stand behind.\n\n4.3 We publish our actual measured availability at status.elchi.dev, which is\nlive since 3 October 2026, when the service moved to our operation across\nseveral data centres. A figure appears there once a full month has been\nmeasured. It is a record of what happened, not a promise about what will\nhappen.\n\n4.4 If your application cannot tolerate authentication being unavailable, you\nshould run EAuth on your own infrastructure. Section 11 covers this.\n\n### Failures caused by third parties\n\n4.5 We use third parties, including hosting providers, to operate the\nservice. An outage originating with one of them is still an outage of EAuth.\nWe do not disclaim it, because clause 4.1 already means there is no\navailability commitment to disclaim, whatever the cause.\n\n4.6 This exclusion applies to availability only. It does not extend to the\nsecurity of your end users' personal data. Where a third party we engaged\ncauses a personal data breach, we remain liable to you for it under Annex B.8\nand Art. 28(4) GDPR. We chose that provider; you did not. A clause purporting\nto shift that liability to them would be void, and we do not attempt one.\n\n### What actually happens when EAuth is unavailable\n\n4.7 We state this precisely so you can plan, rather than leaving you to\ndiscover it during an incident.\n\n- **Existing sessions continue.** Access tokens are signed, and your\n  application verifies them against a cached copy of our public keys. They keep\n  working until they expire, by default 15 minutes, without contacting us.\n- **Refresh stops.** Once an access token expires, the refresh call fails and\n  the end user is signed out.\n- **New sign-ins fail.** Nobody can start a session.\n\n4.8 Two things follow. First, cache the JWKS response rather than fetching it\nper request; your users then keep working through a short outage. Second, if\nminutes of lockout are unacceptable to you, tell us and we will raise your\naccess token lifetime, or run the service yourself under Section 11.\n\n4.9 We publish a post-incident note for any outage longer than 30 minutes,\nincluding the cause, in our journal at elchi.dev/en/journal and at\nstatus.elchi.dev. We do this whether or not the cause was ours.\n\n---\n\n## 5. Your responsibilities\n\n5.1 You are responsible for the security of your client secrets. A leaked\nsecret can be rotated in the console; we cannot recover one, because we store\nonly a digest.\n\n5.2 You must register redirect URIs exactly. We reject wildcards and matching\nis exact, which prevents a class of account takeover attacks but means a typo\nproduces a rejected sign-in rather than a silent redirect.\n\n5.3 You must validate the `state` parameter and, where you use OpenID Connect,\nthe `nonce` claim. You must verify the `iss` parameter we return on every\nauthorization response. These checks live in your application; we cannot\nperform them for you.\n\n5.4 You must tell your end users, in your own privacy policy, that\nauthentication is handled by Elchi Studios and what data is involved. Annex A\nlists what we process.\n\n5.5 You must not use EAuth as the sole authentication for systems where a\nfailure would cause danger to life, physical harm, or comparable\nirreversible loss.\n\n---\n\n## 6. Acceptable use and limits\n\n6.1 You must not:\n\n- use the service to authenticate access to unlawful material, or to material\n  that sexualises minors, incites violence, or facilitates fraud;\n- attempt to authenticate end users who have not agreed to use your\n  application;\n- present the hosted sign-in page in a way that misrepresents who operates it,\n  or remove the \"Secured by Elchi Studios using EAuth\" mark;\n- resell EAuth as your own authentication product without a separate written\n  agreement;\n- probe, load-test or attempt to circumvent the service's security controls\n  without written permission. Responsible security research is welcome under\n  Section 12.\n\n6.2 Default limits, which the console shows for your application:\n\n| Limit | Default |\n|---|---|\n| Token requests | 120 per minute per application, adjustable in the console up to 600 |\n| Authorization requests | 60 per minute per IP address |\n| Registered applications | 25 per account |\n| Registered redirect URIs | 20 per application |\n\n6.3 These are defaults, not caps on your success. If you outgrow them, ask.\nRaising a limit for a legitimate application costs us a configuration change.\nFor an application without a client secret, token requests are also counted\nper IP address, so requests sent in its name by others do not use up its\nallowance.\n\n6.4 We may suspend an application that materially exceeds its limits, is used\nfor the conduct in 6.1, or is generating traffic that degrades the service for\nothers. Where the situation permits, we contact you first. Where it does not,\nwe suspend and then contact you within one working day.\n\n---\n\n## 7. Your data, and leaving\n\n7.1 You own your data and your end users' data. We claim no rights over it.\n\n7.2 The console provides a full export of your applications, organisations,\nend users and their metadata in JSON, at any time, without asking us.\n\n7.3 Password hashes are included in that export in their original form, so you\ncan migrate to another provider without forcing your end users to reset their\npasswords. We consider being able to leave a feature, not a risk.\n\n7.4 If you delete an application, we delete its data within 30 days, except\nwhere we are legally required to retain records. Audit log entries relating to\nsecurity incidents may be retained for up to 12 months.\n\n7.5 If you stop using the service, we may delete an account that has had no\nsuccessful authentication for 24 months, after two email notices at least 30\ndays apart.\n\n---\n\n## 8. Our obligations regarding end user data\n\n8.1 For end user personal data, you are the controller and we are the\nprocessor. Annex B is our Data Processing Agreement and forms part of these\nterms.\n\n8.2 We process end user data only to provide the service, and on your\ndocumented instructions.\n\n8.3 We notify you of a personal data breach affecting your end users without\nundue delay and in any case within 72 hours of becoming aware of it.\n\n8.4 We do not use end user data to train models, to build profiles, or for any\npurpose other than operating the service.\n\n8.5 Sub-processors are listed at docs.elchi.dev/subprocessors. We give 30\ndays' notice before adding one, and you may terminate if you object.\n\n8.6 The sub-processors that run our operation across several data centres\nwere added on 3 October 2026, the day the service moved there, without the\nnotice in clause 8.5. None was needed: on that day every application\nregistered with EAuth belonged to Elchi Studios, and no one outside Elchi\nStudios had an account, so no one else's end users were affected.\n\n---\n\n## 9. Security\n\n9.1 Measures we implement are described in Annex C. They include: passwords\nhashed with Argon2id, refresh tokens and recovery codes stored only as digests,\nsigning keys encrypted at rest, mandatory PKCE, exact redirect URI matching,\nand TLS for all traffic.\n\n9.2 We have not undergone an independent security audit. We say this plainly\nbecause the alternative is letting you assume otherwise. When an audit is\ncompleted, the result will be published at docs.elchi.dev regardless of\noutcome.\n\n9.3 You must report a suspected compromise of your application to\nsecurity@elchi.dev without undue delay.\n\n---\n\n## 10. Liability\n\n10.1 Nothing in these terms excludes liability for death or personal injury\ncaused by negligence, for fraud, or for anything else that cannot be excluded\nunder Swiss law.\n\n10.2 Subject to 10.1, and because the service is provided free of charge, our\ntotal liability to you for all claims arising from these terms is limited to\nCHF 500.\n\n10.3 We are not liable for indirect or consequential loss, including lost\nprofit, lost business, or the cost of migrating to another provider.\n\n10.4 The service is provided \"as is\". We do not warrant that it will be\nuninterrupted, error-free, or fit for a particular purpose.\n\n10.5 You indemnify us against claims brought by your end users that arise from\nyour use of the service, except where the claim results from our breach of\nthese terms.\n\n---\n\n## 11. Self-hosting\n\n11.1 EAuth can be run on your own infrastructure. Doing so is permitted and\nencouraged for any deployment where availability or data residency matters\nmore than convenience.\n\n11.2 Self-hosted deployments are governed by the licence accompanying the\nsoftware, not by these terms. We provide no support obligation for them.\n\n11.3 You may not present a self-hosted deployment as being operated by Elchi\nStudios.\n\n---\n\n## 12. Security research\n\n12.1 We welcome reports of security problems. Send them to security@elchi.dev.\n\n12.2 We will not pursue legal action against you for research conducted in good\nfaith that: stays within your own account and test data, does not access or\nmodify other users' data, does not degrade the service, and gives us 90 days\nbefore public disclosure.\n\n12.3 We have no bug bounty programme. We will credit you publicly if you want\nthat.\n\n---\n\n## 13. Termination\n\n13.1 You may stop using the service and delete your account at any time. The\naccount is deleted 30 days after you ask, and until then you can sign in,\nexport your data and change your mind. With it goes everything that is only\nthe account's: the applications it owns and their end users, its pictures, its\nsign-in history, every EMX organisation in which you are the only person, with\nits mailboxes, and the enquiries and support messages sent to us from its\naddress. An EMX organisation in which others work stays theirs; your sign-in\nthere ends. How to delete, product by product or all at once, is described at\nlegal.elchi.dev.\n\n13.2 We may terminate your account for a material breach of Section 6, giving\n30 days' notice and an opportunity to correct the problem, except where the\nbreach is serious enough that immediate suspension is necessary.\n\n13.3 On termination you have 30 days to export your data.\n\n---\n\n## 14. Changes to these terms\n\n14.1 We will give 30 days' notice of a material change, by email and in the\nchangelog.\n\n14.2 Continuing to use the service after a change takes effect means you\naccept it. If you do not, you may terminate and export your data.\n\n14.3 Every version of these terms remains published, with its date, so you can\nsee what applied when.\n\n---\n\n## 15. Governing law\n\n15.1 Swiss law applies. The place of jurisdiction is Zug, Switzerland.\n\n15.2 Nothing here removes the protection of mandatory consumer law in your\ncountry of residence, where that applies.\n\n---\n\n## Annex A: What we process\n\n| Data | Why | Retention |\n|---|---|---|\n| Email address | Identifies an end user, delivers sign-in | Until deletion |\n| Password hash | Authentication | Until deletion |\n| Display name | Shown in your application | Until deletion |\n| TOTP secret, recovery code digests | Second factor | Until disabled |\n| Session and refresh token digests | Keeping a user signed in | Until expiry or revocation |\n| Country code (two letters) | Showing a user their own sessions | 12 months |\n| Timestamps of sign-in attempts | Detecting abuse | 12 months |\n\nWe do not process: IP addresses in persisted form, device fingerprints,\nbehavioural data, location beyond country, or anything derived from an end\nuser's activity in your application.\n\n## Annex B: Data Processing Agreement\n\nThis Annex is the agreement required by Art. 28 GDPR and the equivalent\nprovisions of the Swiss Federal Act on Data Protection (revDSG). It forms part\nof the Terms of Service and needs no separate signature.\n\n### B.1 Subject matter and duration\n\nWe process end user personal data solely to operate EAuth for you, for as long\nas your account exists, plus the retention periods in Annex A.\n\n### B.2 Nature and purpose\n\nAuthentication and authorisation: verifying an end user's identity, issuing\ntokens, maintaining sessions, enforcing a second factor, and recording the\nevents needed to detect abuse.\n\n### B.3 Categories of data subjects\n\nNatural persons who sign in to your application through EAuth, and natural\npersons you invite to an organisation.\n\n### B.4 Categories of personal data\n\nAs listed in Annex A. We process no special categories of data under Art. 9\nGDPR, and the service must not be configured to collect any.\n\n### B.5 Controller instructions\n\nWe process personal data only on your documented instructions. These Terms,\ntogether with your configuration in the console, constitute those\ninstructions. If we believe an instruction breaches data protection law, we\nwill tell you and may suspend that processing until it is resolved.\n\n### B.6 Confidentiality\n\nEveryone we authorise to process end user data is bound by a written\nconfidentiality obligation that survives the end of their engagement.\n\n### B.7 Security\n\nWe implement the measures in Annex C. We may change a measure, but not in a\nway that lowers the overall level of protection.\n\n### B.8 Sub-processors\n\nYou give general authorisation for the sub-processors listed at\ndocs.elchi.dev/subprocessors. We give 30 days' notice before adding one. If\nyou object on reasonable data protection grounds within that period and we\ncannot accommodate you, you may terminate without penalty and export your data.\n\nEvery sub-processor is bound by obligations no weaker than this Annex. We\nremain fully liable to you for their performance.\n\n### B.9 Assisting you with data subject rights\n\nIf an end user contacts us directly with a request under Art. 15 to 22 GDPR,\nwe will not answer it ourselves. We forward it to you without undue delay,\nbecause you are the controller and only you know the context.\n\nThe console provides the tools to answer such a request yourself: a full\nexport per end user, correction of stored fields, and deletion. Where those\ntools are not sufficient, we assist you at no charge.\n\n### B.10 Assisting you with obligations under Art. 32 to 36\n\nWe assist you, taking into account the nature of processing and the\ninformation available to us, with security of processing, breach notification,\ndata protection impact assessments, and prior consultation.\n\n### B.11 Personal data breach\n\nWe notify you without undue delay and in any case within 72 hours of becoming\naware of a personal data breach affecting your end users. The notice describes\nthe nature of the breach, the categories and approximate number of data\nsubjects and records, the likely consequences, and the measures taken.\n\nWe notify you even where we are not certain the breach affects you, because\nthat determination is yours to make.\n\n### B.12 Deletion or return\n\nOn termination, you have 30 days to export. After that we delete end user\ndata, including from backups within a further 60 days as backup rotation\nallows, except where retention is legally required.\n\n### B.13 Audit\n\nYou may request the information necessary to demonstrate compliance with this\nAnnex once per calendar year, or after a breach affecting your data. Where a\nrecognised certification or audit report exists, providing it satisfies this\nobligation. On-site audits require 30 days' notice, must not disrupt the\nservice, and are at your cost.\n\n### B.14 International transfers\n\nEnd user data is stored and processed on our servers in Switzerland and the\nEuropean Economic Area. Switzerland benefits from a European Commission\nadequacy decision, and the states of the European Economic Area are adequate\nunder Annex 1 of the Swiss Data Protection Ordinance.\n\nOne sub-processor is outside both. The mails EAuth sends (address\nconfirmations, password resets, invitations) go out through Resend, Inc., a\ncompany in the United States. Resend sends them from its European Union\nregion, but stores the recipient's address, the subject and the text of each\nmail in the United States. For data subject to the GDPR, that transfer rests on\nResend's certification under the EU-U.S. Data Privacy Framework (Art. 45 GDPR),\nwith the standard contractual clauses in Resend's data processing agreement in\naddition (Art. 46(2)(c) GDPR). For data from Switzerland, it rests on those\nstandard contractual clauses as adapted for Swiss law (Art. 16(2)(d) revDSG).\n\nWe transfer end user data to no other country outside Switzerland and the\nEuropean Economic Area. If that ever changes, we will give notice under\nSection 14 before it takes effect.\n\n---\n\n## Annex C: Technical and organisational measures\n\nThese are the measures actually implemented, not a generic list. Each is\nverifiable against the source.\n\n### C.1 Pseudonymisation and encryption\n\n- Passwords hashed with Argon2id at 64 MiB memory, 3 iterations, 2 lanes, with\n  a 16-byte random salt per password. Parameters are embedded in each stored\n  hash, so raising the cost later does not invalidate existing accounts.\n- Refresh tokens, authorization codes, API keys, organisation invitations and\n  two-factor recovery codes are stored only as SHA-256 digests. None of them\n  can be recovered from the database, by anyone, including us.\n- Links sent to confirm an email address or to reset a password, and console\n  invitation links, are 256 random bits stored only as SHA-256 digests. Each\n  works once: a reset link for one hour, a confirmation link for a day, an\n  invitation for seven days.\n- Token signing keys and stored third-party credentials are encrypted with\n  AES-256-GCM. The master key is held in the process environment and never in\n  the database, so a database dump yields ciphertext only.\n- All traffic uses TLS 1.3. The entire .dev top-level domain is on the HSTS\n  preload list, so plain HTTP is refused by the browser before a request is\n  made.\n- Raw IP addresses are never written to request logs. Rate limits keep an\n  address, an IPv6 address by its /64, only for the length of their window.\n\n### C.2 Confidentiality\n\n- Role-based access control on every administrative route, with permissions\n  declared as data and checked per project.\n- Two-factor authentication is mandatory for every role that can change\n  content or credentials.\n- Administrative sessions are validated against the database on every request,\n  so revoking access takes effect immediately rather than when a token expires.\n- Administrative session cookies are httpOnly, Secure and SameSite=Strict, so\n  no credential is reachable by script.\n- Cross-site request forgery tokens bound to the session by HMAC on every\n  state-changing form, including the consent screen and the account page, and\n  a check that the form was sent from the same origin.\n- Signing out through the sign-in service requires an ID token issued to the\n  application for the signed-in person, or the person's own confirmation.\n\n### C.3 Integrity\n\n- PKCE with S256 is required on every authorization request. There is no code\n  path that issues a token without it.\n- Redirect URIs match exactly, in constant time. Wildcards, fragments and\n  plain HTTP outside loopback are refused at registration.\n- Authorization codes are valid for 60 seconds, are single use, and are bound\n  to the client, redirect URI and PKCE challenge. A replay revokes every grant\n  issued to that client for that user.\n- Refresh tokens rotate on every use. Presenting a rotated token revokes the\n  entire chain, which is the standard detection for a stolen token.\n- The implicit grant and the password grant are not implemented, so no\n  configuration can enable them.\n- ID token claims are filtered by granted scope.\n- Every authorization response carries the iss parameter (RFC 9207), which lets\n  a client detect a mix-up attack.\n\n### C.4 Availability and resilience\n\n- Automatic database migrations with checksum verification. A modified\n  migration aborts startup rather than running against an unexpected schema.\n- Health endpoints checking each dependency separately.\n- Every database write is committed on three servers, at three providers in\n  two countries, before it is confirmed. Two application servers and two edge\n  proxies, each pair at two providers in two countries, stand in for each\n  other.\n- Each service is checked continuously from the cluster, which alerts us when\n  a check fails.\n- Graceful shutdown that drains in-flight requests.\n- Rate limiting with a sliding window. Authentication endpoints fail closed, so\n  an outage of the limiter cannot remove brute-force protection.\n- Every attempt at a password or a second-factor code is counted per IP\n  address and per account before it is checked. A browser that has completed a\n  sign-in to an account keeps a separate allowance, so repeated failures\n  elsewhere cannot lock the account holder out.\n\n### C.5 Verification and evaluation\n\n- Every credential change is written to an append-only audit log with the\n  operator's identity.\n- Structured request logging that records neither full IP addresses nor query\n  strings.\n- Automated tests covering the security rules, including nine redirect URI\n  variants that have produced account takeovers at other providers.\n\n### C.6 Organisational measures\n\n- Secrets are supplied through the service environment, readable by root only,\n  and never committed to source control.\n- Least privilege: the application runs as an unprivileged user with a\n  restricted system call filter and a read-only file system apart from its\n  data directory.\n- No independent security audit has been performed. When one is, the result\n  will be published regardless of outcome.\n\n---\n\n## Annex D: Version history\n\n| Version | In effect from | Change |\n|---|---|---|\n| 1.10 | 9 October 2026 | This table is corrected: version 1.8 was never published and never applied, and the changes written for it took effect with 1.9. Clause 13.1 says what deleting an account deletes, including EMX organisations in which the account holder is the only person and the enquiries sent from its address. Every version is published at legal.elchi.dev. |\n| 1.9 | 6 October 2026 | Clause 1.4, the age requirement for registering an application, removed. Annex B.14 names the one transfer outside Switzerland and the European Economic Area, which already took place: mails sent through Resend, Inc., which stores them in the United States, and the safeguards that transfer rests on. The provider is named by its business name, Krauss Software, the sole proprietorship of Samuel Krauss (clause 1.1). With this version the changes written for 1.8 took effect: the sub-processors of the operation across several data centres are listed at docs.elchi.dev/subprocessors, added on the day of the move without notice since no one outside Elchi Studios was affected (8.6); the status page at status.elchi.dev is live (4.3, 4.9); Annex C.4 describes the replication and the checks in place, and no longer mentions push-based liveness reporting, which is not in place. |\n| 1.8 | Never in effect | Written on 3 October 2026 and never published, so it never applied: version 1.7 applied until 1.9 replaced it on 6 October 2026. It said that end user data was not transferred to any other jurisdiction, which was not correct, since the mails EAuth sends are stored by Resend, Inc. in the United States. It is published, marked as never in effect, so the history has no gap. |\n| 1.7 | 3 October 2026 | auth.elchi.dev redirects to eauth.me from the day of the move rather than after ninety days, since every application registered with EAuth belonged to Elchi Studios and no one else was affected (clause 2.4). |\n| 1.6 | 3 October 2026 | The service moves to eauth.me with the issuer `https://eauth.me`; auth.elchi.dev stays in service until 1 January 2027 (clause 2.4). Token requests adjustable up to 600 per minute, and counted per IP address for applications without a secret (6.2, 6.3). Annex C describes the email links, the form checks, sign-out and the sign-in limits that are now in place, and no longer mentions analytics, which EAuth does not have. The status page at status.elchi.dev is not live yet; until it is, outage notes appear in the journal (4.3, 4.9). |\n| 1.5 | 4 September 2026 | Clauses 3.4 and 3.5 tie the free commitment to the devs.elchi.dev listing and state that a paid service lives elsewhere with its own terms. |\n| 1.4 | 4 September 2026 | Clause 3.3 replaced. The reservation of a right to introduce paid plans contradicted the public claim that the service is permanently free, so the reservation was dropped rather than the claim. |\n| 1.3 | 3 September 2026 | The provider is stated accurately as an unregistered sole proprietorship. Corrects 1.2, which named a registered business before registration had taken place. |\n| 1.2 | 3 September 2026 | Superseded within a day. Named a registered business prematurely. |\n| 1.1 | 2 September 2026 | Added clauses 4.5 to 4.9: third-party failures, the distinction between availability and data protection liability, and what happens to sessions during an outage. |\n| 1.0 | 2 September 2026 | First published version. |\n\nEvery version remains available at legal.elchi.dev/en/eauth-terms/versions so\nyou can see what applied on any given date.\n\n\n\n\n\n\n","body_html":"\u003ch1 id=\"eauth-terms-of-service\"\u003eEAuth Terms of Service\u003c/h1\u003e\n\u003cp\u003e\u003cstrong\u003eVersion:\u003c/strong\u003e 1.10\u003cbr /\u003e\n\u003cstrong\u003eIn effect from:\u003c/strong\u003e 9 October 2026\u003cbr /\u003e\n\u003cstrong\u003eProvider:\u003c/strong\u003e Krauss Software, sole proprietorship of Samuel Krauss, Oberägeri ZG, Switzerland, trading as Elchi Studios\u003cbr /\u003e\n\u003cstrong\u003eContact:\u003c/strong\u003e \u003ca href=\"mailto:legal@elchi.dev\"\u003elegal@elchi.dev\u003c/a\u003e\u003cbr /\u003e\n\u003cstrong\u003eApplies to:\u003c/strong\u003e eauth.me, panel.elchi.dev, docs.elchi.dev and the SDKs\u003cbr /\u003e\npublished under the EAuth name, and auth.elchi.dev, which redirects to eauth.me\u003cbr /\u003e\nunder clause 2.4\u003c/p\u003e\n\u003chr /\u003e\n\u003ch2 id=\"1-who-these-terms-are-between\"\u003e1. Who these terms are between\u003c/h2\u003e\n\u003cp\u003e1.1 These terms govern your use of EAuth, an authentication service operated by\u003cbr /\u003e\n\u003cstrong\u003eKrauss Software\u003c/strong\u003e (\u0026quot;we\u0026quot;, \u0026quot;us\u0026quot;), the sole proprietorship of Samuel Krauss,\u003cbr /\u003e\nseated in Oberägeri, Canton of Zug, Switzerland, trading under the name Elchi\u003cbr /\u003e\nStudios. Krauss Software is not entered in the commercial register. Krauss\u003cbr /\u003e\nSoftware is the counterparty to this agreement and Samuel Krauss, as its owner,\u003cbr /\u003e\nis personally liable; Elchi Studios is the name under which the service is\u003cbr /\u003e\npresented.\u003c/p\u003e\n\u003cp\u003e1.2 \u0026quot;You\u0026quot; means the natural or legal person registering an application. If you\u003cbr /\u003e\nregister on behalf of a company, you confirm you are authorised to bind it.\u003c/p\u003e\n\u003cp\u003e1.3 \u0026quot;End user\u0026quot; means a person who signs in through your application using\u003cbr /\u003e\nEAuth. End users are your users, not ours. We process their data on your\u003cbr /\u003e\ninstructions under the Data Processing Agreement in Annex B.\u003c/p\u003e\n\u003chr /\u003e\n\u003ch2 id=\"2-the-service\"\u003e2. The service\u003c/h2\u003e\n\u003cp\u003e2.1 EAuth provides OAuth 2.1 and OpenID Connect authentication: a hosted\u003cbr /\u003e\nsign-in page, an authorization server and token issuance at eauth.me, and the\u003cbr /\u003e\nmanagement console at panel.elchi.dev. The issuer identifier is\u003cbr /\u003e\n\u003ccode\u003ehttps://eauth.me\u003c/code\u003e.\u003c/p\u003e\n\u003cp\u003e2.2 We implement the OpenID Connect Core specification and the OAuth 2.0\u003cbr /\u003e\nsecurity practices set out in RFC 9700. Where the service deviates from a\u003cbr /\u003e\nspecification, the documentation at docs.elchi.dev says so.\u003c/p\u003e\n\u003cp\u003e2.3 We may change, add or remove features. Where a change would break existing\u003cbr /\u003e\nintegrations, we will give at least 90 days' notice by email to the address on\u003cbr /\u003e\nyour account and in the changelog, except where a shorter period is necessary\u003cbr /\u003e\nto address a security problem.\u003c/p\u003e\n\u003cp\u003e2.4 Until 3 October 2026 the service was provided at auth.elchi.dev, under the\u003cbr /\u003e\nissuer identifier \u003ccode\u003ehttps://auth.elchi.dev\u003c/code\u003e. Since that day, every request to\u003cbr /\u003e\nauth.elchi.dev is answered with a permanent redirect to the same path at\u003cbr /\u003e\neauth.me. Changing the issuer breaks integrations that name it, which would\u003cbr /\u003e\ncall for the notice in clause 2.3. None was needed: on that day every\u003cbr /\u003e\napplication registered with EAuth belonged to Elchi Studios, and no one\u003cbr /\u003e\noutside Elchi Studios had an account, so no integration of anyone else was\u003cbr /\u003e\naffected.\u003c/p\u003e\n\u003chr /\u003e\n\u003ch2 id=\"3-cost-and-what-free-means\"\u003e3. Cost, and what \u0026quot;free\u0026quot; means\u003c/h2\u003e\n\u003cp\u003e3.1 EAuth is provided free of charge. There is no paid tier, and we do not\u003cbr /\u003e\nsell your data or your end users' data. We do not serve advertising.\u003c/p\u003e\n\u003cp\u003e3.2 Free does not mean unconditional. Section 6 sets out usage limits that\u003cbr /\u003e\nexist to keep the service available for everyone, not to create an upgrade\u003cbr /\u003e\npath.\u003c/p\u003e\n\u003cp\u003e3.3 We do not reserve a right to start charging for what is described here.\u003cbr /\u003e\nThere is no paid tier, no usage threshold that becomes an invoice, and no\u003cbr /\u003e\nfeature withheld to create one. This is stated as a term rather than as\u003cbr /\u003e\nmarketing, because a promise made only on a website is worth what a website is\u003cbr /\u003e\nworth.\u003c/p\u003e\n\u003cp\u003e3.4 These terms cover the services listed at devs.elchi.dev. Being listed\u003cbr /\u003e\nthere requires being free permanently, so the commitment in 3.3 and the\u003cbr /\u003e\nlisting are the same fact stated twice.\u003c/p\u003e\n\u003cp\u003e3.5 A service with a paid tier is not listed at devs.elchi.dev and is not\u003cbr /\u003e\ngoverned by this document. It has its own page and its own terms, which you\u003cbr /\u003e\nwill see before registering for it. It is administered through the same\u003cbr /\u003e\nconsole, because that is where credentials belong regardless of price, and\u003cbr /\u003e\nbeing in the console implies nothing about what a service costs.\u003c/p\u003e\n\u003chr /\u003e\n\u003ch2 id=\"4-availability\"\u003e4. Availability\u003c/h2\u003e\n\u003cp\u003e4.1 \u003cstrong\u003eWe give no availability guarantee.\u003c/strong\u003e There is no service level\u003cbr /\u003e\nagreement, no uptime commitment, and no compensation for downtime.\u003c/p\u003e\n\u003cp\u003e4.2 This is a deliberate consequence of clause 3.1. A free service cannot\u003cbr /\u003e\nresponsibly promise availability it is not paid to underwrite, and we would\u003cbr /\u003e\nrather say so plainly than publish a figure we cannot stand behind.\u003c/p\u003e\n\u003cp\u003e4.3 We publish our actual measured availability at status.elchi.dev, which is\u003cbr /\u003e\nlive since 3 October 2026, when the service moved to our operation across\u003cbr /\u003e\nseveral data centres. A figure appears there once a full month has been\u003cbr /\u003e\nmeasured. It is a record of what happened, not a promise about what will\u003cbr /\u003e\nhappen.\u003c/p\u003e\n\u003cp\u003e4.4 If your application cannot tolerate authentication being unavailable, you\u003cbr /\u003e\nshould run EAuth on your own infrastructure. Section 11 covers this.\u003c/p\u003e\n\u003ch3 id=\"failures-caused-by-third-parties\"\u003eFailures caused by third parties\u003c/h3\u003e\n\u003cp\u003e4.5 We use third parties, including hosting providers, to operate the\u003cbr /\u003e\nservice. An outage originating with one of them is still an outage of EAuth.\u003cbr /\u003e\nWe do not disclaim it, because clause 4.1 already means there is no\u003cbr /\u003e\navailability commitment to disclaim, whatever the cause.\u003c/p\u003e\n\u003cp\u003e4.6 This exclusion applies to availability only. It does not extend to the\u003cbr /\u003e\nsecurity of your end users' personal data. Where a third party we engaged\u003cbr /\u003e\ncauses a personal data breach, we remain liable to you for it under Annex B.8\u003cbr /\u003e\nand Art. 28(4) GDPR. We chose that provider; you did not. A clause purporting\u003cbr /\u003e\nto shift that liability to them would be void, and we do not attempt one.\u003c/p\u003e\n\u003ch3 id=\"what-actually-happens-when-eauth-is-unavailable\"\u003eWhat actually happens when EAuth is unavailable\u003c/h3\u003e\n\u003cp\u003e4.7 We state this precisely so you can plan, rather than leaving you to\u003cbr /\u003e\ndiscover it during an incident.\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cstrong\u003eExisting sessions continue.\u003c/strong\u003e Access tokens are signed, and your\u003cbr /\u003e\napplication verifies them against a cached copy of our public keys. They keep\u003cbr /\u003e\nworking until they expire, by default 15 minutes, without contacting us.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eRefresh stops.\u003c/strong\u003e Once an access token expires, the refresh call fails and\u003cbr /\u003e\nthe end user is signed out.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eNew sign-ins fail.\u003c/strong\u003e Nobody can start a session.\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003e4.8 Two things follow. First, cache the JWKS response rather than fetching it\u003cbr /\u003e\nper request; your users then keep working through a short outage. Second, if\u003cbr /\u003e\nminutes of lockout are unacceptable to you, tell us and we will raise your\u003cbr /\u003e\naccess token lifetime, or run the service yourself under Section 11.\u003c/p\u003e\n\u003cp\u003e4.9 We publish a post-incident note for any outage longer than 30 minutes,\u003cbr /\u003e\nincluding the cause, in our journal at elchi.dev/en/journal and at\u003cbr /\u003e\nstatus.elchi.dev. We do this whether or not the cause was ours.\u003c/p\u003e\n\u003chr /\u003e\n\u003ch2 id=\"5-your-responsibilities\"\u003e5. Your responsibilities\u003c/h2\u003e\n\u003cp\u003e5.1 You are responsible for the security of your client secrets. A leaked\u003cbr /\u003e\nsecret can be rotated in the console; we cannot recover one, because we store\u003cbr /\u003e\nonly a digest.\u003c/p\u003e\n\u003cp\u003e5.2 You must register redirect URIs exactly. We reject wildcards and matching\u003cbr /\u003e\nis exact, which prevents a class of account takeover attacks but means a typo\u003cbr /\u003e\nproduces a rejected sign-in rather than a silent redirect.\u003c/p\u003e\n\u003cp\u003e5.3 You must validate the \u003ccode\u003estate\u003c/code\u003e parameter and, where you use OpenID Connect,\u003cbr /\u003e\nthe \u003ccode\u003enonce\u003c/code\u003e claim. You must verify the \u003ccode\u003eiss\u003c/code\u003e parameter we return on every\u003cbr /\u003e\nauthorization response. These checks live in your application; we cannot\u003cbr /\u003e\nperform them for you.\u003c/p\u003e\n\u003cp\u003e5.4 You must tell your end users, in your own privacy policy, that\u003cbr /\u003e\nauthentication is handled by Elchi Studios and what data is involved. Annex A\u003cbr /\u003e\nlists what we process.\u003c/p\u003e\n\u003cp\u003e5.5 You must not use EAuth as the sole authentication for systems where a\u003cbr /\u003e\nfailure would cause danger to life, physical harm, or comparable\u003cbr /\u003e\nirreversible loss.\u003c/p\u003e\n\u003chr /\u003e\n\u003ch2 id=\"6-acceptable-use-and-limits\"\u003e6. Acceptable use and limits\u003c/h2\u003e\n\u003cp\u003e6.1 You must not:\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003euse the service to authenticate access to unlawful material, or to material\u003cbr /\u003e\nthat sexualises minors, incites violence, or facilitates fraud;\u003c/li\u003e\n\u003cli\u003eattempt to authenticate end users who have not agreed to use your\u003cbr /\u003e\napplication;\u003c/li\u003e\n\u003cli\u003epresent the hosted sign-in page in a way that misrepresents who operates it,\u003cbr /\u003e\nor remove the \u0026quot;Secured by Elchi Studios using EAuth\u0026quot; mark;\u003c/li\u003e\n\u003cli\u003eresell EAuth as your own authentication product without a separate written\u003cbr /\u003e\nagreement;\u003c/li\u003e\n\u003cli\u003eprobe, load-test or attempt to circumvent the service's security controls\u003cbr /\u003e\nwithout written permission. Responsible security research is welcome under\u003cbr /\u003e\nSection 12.\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003e6.2 Default limits, which the console shows for your application:\u003c/p\u003e\n\u003ctable\u003e\n\u003cthead\u003e\n\u003ctr\u003e\n\u003cth\u003eLimit\u003c/th\u003e\n\u003cth\u003eDefault\u003c/th\u003e\n\u003c/tr\u003e\n\u003c/thead\u003e\n\u003ctbody\u003e\n\u003ctr\u003e\n\u003ctd\u003eToken requests\u003c/td\u003e\n\u003ctd\u003e120 per minute per application, adjustable in the console up to 600\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eAuthorization requests\u003c/td\u003e\n\u003ctd\u003e60 per minute per IP address\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eRegistered applications\u003c/td\u003e\n\u003ctd\u003e25 per account\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eRegistered redirect URIs\u003c/td\u003e\n\u003ctd\u003e20 per application\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/tbody\u003e\n\u003c/table\u003e\n\u003cp\u003e6.3 These are defaults, not caps on your success. If you outgrow them, ask.\u003cbr /\u003e\nRaising a limit for a legitimate application costs us a configuration change.\u003cbr /\u003e\nFor an application without a client secret, token requests are also counted\u003cbr /\u003e\nper IP address, so requests sent in its name by others do not use up its\u003cbr /\u003e\nallowance.\u003c/p\u003e\n\u003cp\u003e6.4 We may suspend an application that materially exceeds its limits, is used\u003cbr /\u003e\nfor the conduct in 6.1, or is generating traffic that degrades the service for\u003cbr /\u003e\nothers. Where the situation permits, we contact you first. Where it does not,\u003cbr /\u003e\nwe suspend and then contact you within one working day.\u003c/p\u003e\n\u003chr /\u003e\n\u003ch2 id=\"7-your-data-and-leaving\"\u003e7. Your data, and leaving\u003c/h2\u003e\n\u003cp\u003e7.1 You own your data and your end users' data. We claim no rights over it.\u003c/p\u003e\n\u003cp\u003e7.2 The console provides a full export of your applications, organisations,\u003cbr /\u003e\nend users and their metadata in JSON, at any time, without asking us.\u003c/p\u003e\n\u003cp\u003e7.3 Password hashes are included in that export in their original form, so you\u003cbr /\u003e\ncan migrate to another provider without forcing your end users to reset their\u003cbr /\u003e\npasswords. We consider being able to leave a feature, not a risk.\u003c/p\u003e\n\u003cp\u003e7.4 If you delete an application, we delete its data within 30 days, except\u003cbr /\u003e\nwhere we are legally required to retain records. Audit log entries relating to\u003cbr /\u003e\nsecurity incidents may be retained for up to 12 months.\u003c/p\u003e\n\u003cp\u003e7.5 If you stop using the service, we may delete an account that has had no\u003cbr /\u003e\nsuccessful authentication for 24 months, after two email notices at least 30\u003cbr /\u003e\ndays apart.\u003c/p\u003e\n\u003chr /\u003e\n\u003ch2 id=\"8-our-obligations-regarding-end-user-data\"\u003e8. Our obligations regarding end user data\u003c/h2\u003e\n\u003cp\u003e8.1 For end user personal data, you are the controller and we are the\u003cbr /\u003e\nprocessor. Annex B is our Data Processing Agreement and forms part of these\u003cbr /\u003e\nterms.\u003c/p\u003e\n\u003cp\u003e8.2 We process end user data only to provide the service, and on your\u003cbr /\u003e\ndocumented instructions.\u003c/p\u003e\n\u003cp\u003e8.3 We notify you of a personal data breach affecting your end users without\u003cbr /\u003e\nundue delay and in any case within 72 hours of becoming aware of it.\u003c/p\u003e\n\u003cp\u003e8.4 We do not use end user data to train models, to build profiles, or for any\u003cbr /\u003e\npurpose other than operating the service.\u003c/p\u003e\n\u003cp\u003e8.5 Sub-processors are listed at docs.elchi.dev/subprocessors. We give 30\u003cbr /\u003e\ndays' notice before adding one, and you may terminate if you object.\u003c/p\u003e\n\u003cp\u003e8.6 The sub-processors that run our operation across several data centres\u003cbr /\u003e\nwere added on 3 October 2026, the day the service moved there, without the\u003cbr /\u003e\nnotice in clause 8.5. None was needed: on that day every application\u003cbr /\u003e\nregistered with EAuth belonged to Elchi Studios, and no one outside Elchi\u003cbr /\u003e\nStudios had an account, so no one else's end users were affected.\u003c/p\u003e\n\u003chr /\u003e\n\u003ch2 id=\"9-security\"\u003e9. Security\u003c/h2\u003e\n\u003cp\u003e9.1 Measures we implement are described in Annex C. They include: passwords\u003cbr /\u003e\nhashed with Argon2id, refresh tokens and recovery codes stored only as digests,\u003cbr /\u003e\nsigning keys encrypted at rest, mandatory PKCE, exact redirect URI matching,\u003cbr /\u003e\nand TLS for all traffic.\u003c/p\u003e\n\u003cp\u003e9.2 We have not undergone an independent security audit. We say this plainly\u003cbr /\u003e\nbecause the alternative is letting you assume otherwise. When an audit is\u003cbr /\u003e\ncompleted, the result will be published at docs.elchi.dev regardless of\u003cbr /\u003e\noutcome.\u003c/p\u003e\n\u003cp\u003e9.3 You must report a suspected compromise of your application to\u003cbr /\u003e\n\u003ca href=\"mailto:security@elchi.dev\"\u003esecurity@elchi.dev\u003c/a\u003e without undue delay.\u003c/p\u003e\n\u003chr /\u003e\n\u003ch2 id=\"10-liability\"\u003e10. Liability\u003c/h2\u003e\n\u003cp\u003e10.1 Nothing in these terms excludes liability for death or personal injury\u003cbr /\u003e\ncaused by negligence, for fraud, or for anything else that cannot be excluded\u003cbr /\u003e\nunder Swiss law.\u003c/p\u003e\n\u003cp\u003e10.2 Subject to 10.1, and because the service is provided free of charge, our\u003cbr /\u003e\ntotal liability to you for all claims arising from these terms is limited to\u003cbr /\u003e\nCHF 500.\u003c/p\u003e\n\u003cp\u003e10.3 We are not liable for indirect or consequential loss, including lost\u003cbr /\u003e\nprofit, lost business, or the cost of migrating to another provider.\u003c/p\u003e\n\u003cp\u003e10.4 The service is provided \u0026quot;as is\u0026quot;. We do not warrant that it will be\u003cbr /\u003e\nuninterrupted, error-free, or fit for a particular purpose.\u003c/p\u003e\n\u003cp\u003e10.5 You indemnify us against claims brought by your end users that arise from\u003cbr /\u003e\nyour use of the service, except where the claim results from our breach of\u003cbr /\u003e\nthese terms.\u003c/p\u003e\n\u003chr /\u003e\n\u003ch2 id=\"11-self-hosting\"\u003e11. Self-hosting\u003c/h2\u003e\n\u003cp\u003e11.1 EAuth can be run on your own infrastructure. Doing so is permitted and\u003cbr /\u003e\nencouraged for any deployment where availability or data residency matters\u003cbr /\u003e\nmore than convenience.\u003c/p\u003e\n\u003cp\u003e11.2 Self-hosted deployments are governed by the licence accompanying the\u003cbr /\u003e\nsoftware, not by these terms. We provide no support obligation for them.\u003c/p\u003e\n\u003cp\u003e11.3 You may not present a self-hosted deployment as being operated by Elchi\u003cbr /\u003e\nStudios.\u003c/p\u003e\n\u003chr /\u003e\n\u003ch2 id=\"12-security-research\"\u003e12. Security research\u003c/h2\u003e\n\u003cp\u003e12.1 We welcome reports of security problems. Send them to \u003ca href=\"mailto:security@elchi.dev\"\u003esecurity@elchi.dev\u003c/a\u003e.\u003c/p\u003e\n\u003cp\u003e12.2 We will not pursue legal action against you for research conducted in good\u003cbr /\u003e\nfaith that: stays within your own account and test data, does not access or\u003cbr /\u003e\nmodify other users' data, does not degrade the service, and gives us 90 days\u003cbr /\u003e\nbefore public disclosure.\u003c/p\u003e\n\u003cp\u003e12.3 We have no bug bounty programme. We will credit you publicly if you want\u003cbr /\u003e\nthat.\u003c/p\u003e\n\u003chr /\u003e\n\u003ch2 id=\"13-termination\"\u003e13. Termination\u003c/h2\u003e\n\u003cp\u003e13.1 You may stop using the service and delete your account at any time. The\u003cbr /\u003e\naccount is deleted 30 days after you ask, and until then you can sign in,\u003cbr /\u003e\nexport your data and change your mind. With it goes everything that is only\u003cbr /\u003e\nthe account's: the applications it owns and their end users, its pictures, its\u003cbr /\u003e\nsign-in history, every EMX organisation in which you are the only person, with\u003cbr /\u003e\nits mailboxes, and the enquiries and support messages sent to us from its\u003cbr /\u003e\naddress. An EMX organisation in which others work stays theirs; your sign-in\u003cbr /\u003e\nthere ends. How to delete, product by product or all at once, is described at\u003cbr /\u003e\nlegal.elchi.dev.\u003c/p\u003e\n\u003cp\u003e13.2 We may terminate your account for a material breach of Section 6, giving\u003cbr /\u003e\n30 days' notice and an opportunity to correct the problem, except where the\u003cbr /\u003e\nbreach is serious enough that immediate suspension is necessary.\u003c/p\u003e\n\u003cp\u003e13.3 On termination you have 30 days to export your data.\u003c/p\u003e\n\u003chr /\u003e\n\u003ch2 id=\"14-changes-to-these-terms\"\u003e14. Changes to these terms\u003c/h2\u003e\n\u003cp\u003e14.1 We will give 30 days' notice of a material change, by email and in the\u003cbr /\u003e\nchangelog.\u003c/p\u003e\n\u003cp\u003e14.2 Continuing to use the service after a change takes effect means you\u003cbr /\u003e\naccept it. If you do not, you may terminate and export your data.\u003c/p\u003e\n\u003cp\u003e14.3 Every version of these terms remains published, with its date, so you can\u003cbr /\u003e\nsee what applied when.\u003c/p\u003e\n\u003chr /\u003e\n\u003ch2 id=\"15-governing-law\"\u003e15. Governing law\u003c/h2\u003e\n\u003cp\u003e15.1 Swiss law applies. The place of jurisdiction is Zug, Switzerland.\u003c/p\u003e\n\u003cp\u003e15.2 Nothing here removes the protection of mandatory consumer law in your\u003cbr /\u003e\ncountry of residence, where that applies.\u003c/p\u003e\n\u003chr /\u003e\n\u003ch2 id=\"annex-a-what-we-process\"\u003eAnnex A: What we process\u003c/h2\u003e\n\u003ctable\u003e\n\u003cthead\u003e\n\u003ctr\u003e\n\u003cth\u003eData\u003c/th\u003e\n\u003cth\u003eWhy\u003c/th\u003e\n\u003cth\u003eRetention\u003c/th\u003e\n\u003c/tr\u003e\n\u003c/thead\u003e\n\u003ctbody\u003e\n\u003ctr\u003e\n\u003ctd\u003eEmail address\u003c/td\u003e\n\u003ctd\u003eIdentifies an end user, delivers sign-in\u003c/td\u003e\n\u003ctd\u003eUntil deletion\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003ePassword hash\u003c/td\u003e\n\u003ctd\u003eAuthentication\u003c/td\u003e\n\u003ctd\u003eUntil deletion\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eDisplay name\u003c/td\u003e\n\u003ctd\u003eShown in your application\u003c/td\u003e\n\u003ctd\u003eUntil deletion\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eTOTP secret, recovery code digests\u003c/td\u003e\n\u003ctd\u003eSecond factor\u003c/td\u003e\n\u003ctd\u003eUntil disabled\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eSession and refresh token digests\u003c/td\u003e\n\u003ctd\u003eKeeping a user signed in\u003c/td\u003e\n\u003ctd\u003eUntil expiry or revocation\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eCountry code (two letters)\u003c/td\u003e\n\u003ctd\u003eShowing a user their own sessions\u003c/td\u003e\n\u003ctd\u003e12 months\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eTimestamps of sign-in attempts\u003c/td\u003e\n\u003ctd\u003eDetecting abuse\u003c/td\u003e\n\u003ctd\u003e12 months\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/tbody\u003e\n\u003c/table\u003e\n\u003cp\u003eWe do not process: IP addresses in persisted form, device fingerprints,\u003cbr /\u003e\nbehavioural data, location beyond country, or anything derived from an end\u003cbr /\u003e\nuser's activity in your application.\u003c/p\u003e\n\u003ch2 id=\"annex-b-data-processing-agreement\"\u003eAnnex B: Data Processing Agreement\u003c/h2\u003e\n\u003cp\u003eThis Annex is the agreement required by Art. 28 GDPR and the equivalent\u003cbr /\u003e\nprovisions of the Swiss Federal Act on Data Protection (revDSG). It forms part\u003cbr /\u003e\nof the Terms of Service and needs no separate signature.\u003c/p\u003e\n\u003ch3 id=\"b1-subject-matter-and-duration\"\u003eB.1 Subject matter and duration\u003c/h3\u003e\n\u003cp\u003eWe process end user personal data solely to operate EAuth for you, for as long\u003cbr /\u003e\nas your account exists, plus the retention periods in Annex A.\u003c/p\u003e\n\u003ch3 id=\"b2-nature-and-purpose\"\u003eB.2 Nature and purpose\u003c/h3\u003e\n\u003cp\u003eAuthentication and authorisation: verifying an end user's identity, issuing\u003cbr /\u003e\ntokens, maintaining sessions, enforcing a second factor, and recording the\u003cbr /\u003e\nevents needed to detect abuse.\u003c/p\u003e\n\u003ch3 id=\"b3-categories-of-data-subjects\"\u003eB.3 Categories of data subjects\u003c/h3\u003e\n\u003cp\u003eNatural persons who sign in to your application through EAuth, and natural\u003cbr /\u003e\npersons you invite to an organisation.\u003c/p\u003e\n\u003ch3 id=\"b4-categories-of-personal-data\"\u003eB.4 Categories of personal data\u003c/h3\u003e\n\u003cp\u003eAs listed in Annex A. We process no special categories of data under Art. 9\u003cbr /\u003e\nGDPR, and the service must not be configured to collect any.\u003c/p\u003e\n\u003ch3 id=\"b5-controller-instructions\"\u003eB.5 Controller instructions\u003c/h3\u003e\n\u003cp\u003eWe process personal data only on your documented instructions. These Terms,\u003cbr /\u003e\ntogether with your configuration in the console, constitute those\u003cbr /\u003e\ninstructions. If we believe an instruction breaches data protection law, we\u003cbr /\u003e\nwill tell you and may suspend that processing until it is resolved.\u003c/p\u003e\n\u003ch3 id=\"b6-confidentiality\"\u003eB.6 Confidentiality\u003c/h3\u003e\n\u003cp\u003eEveryone we authorise to process end user data is bound by a written\u003cbr /\u003e\nconfidentiality obligation that survives the end of their engagement.\u003c/p\u003e\n\u003ch3 id=\"b7-security\"\u003eB.7 Security\u003c/h3\u003e\n\u003cp\u003eWe implement the measures in Annex C. We may change a measure, but not in a\u003cbr /\u003e\nway that lowers the overall level of protection.\u003c/p\u003e\n\u003ch3 id=\"b8-sub-processors\"\u003eB.8 Sub-processors\u003c/h3\u003e\n\u003cp\u003eYou give general authorisation for the sub-processors listed at\u003cbr /\u003e\ndocs.elchi.dev/subprocessors. We give 30 days' notice before adding one. If\u003cbr /\u003e\nyou object on reasonable data protection grounds within that period and we\u003cbr /\u003e\ncannot accommodate you, you may terminate without penalty and export your data.\u003c/p\u003e\n\u003cp\u003eEvery sub-processor is bound by obligations no weaker than this Annex. We\u003cbr /\u003e\nremain fully liable to you for their performance.\u003c/p\u003e\n\u003ch3 id=\"b9-assisting-you-with-data-subject-rights\"\u003eB.9 Assisting you with data subject rights\u003c/h3\u003e\n\u003cp\u003eIf an end user contacts us directly with a request under Art. 15 to 22 GDPR,\u003cbr /\u003e\nwe will not answer it ourselves. We forward it to you without undue delay,\u003cbr /\u003e\nbecause you are the controller and only you know the context.\u003c/p\u003e\n\u003cp\u003eThe console provides the tools to answer such a request yourself: a full\u003cbr /\u003e\nexport per end user, correction of stored fields, and deletion. Where those\u003cbr /\u003e\ntools are not sufficient, we assist you at no charge.\u003c/p\u003e\n\u003ch3 id=\"b10-assisting-you-with-obligations-under-art-32-to-36\"\u003eB.10 Assisting you with obligations under Art. 32 to 36\u003c/h3\u003e\n\u003cp\u003eWe assist you, taking into account the nature of processing and the\u003cbr /\u003e\ninformation available to us, with security of processing, breach notification,\u003cbr /\u003e\ndata protection impact assessments, and prior consultation.\u003c/p\u003e\n\u003ch3 id=\"b11-personal-data-breach\"\u003eB.11 Personal data breach\u003c/h3\u003e\n\u003cp\u003eWe notify you without undue delay and in any case within 72 hours of becoming\u003cbr /\u003e\naware of a personal data breach affecting your end users. The notice describes\u003cbr /\u003e\nthe nature of the breach, the categories and approximate number of data\u003cbr /\u003e\nsubjects and records, the likely consequences, and the measures taken.\u003c/p\u003e\n\u003cp\u003eWe notify you even where we are not certain the breach affects you, because\u003cbr /\u003e\nthat determination is yours to make.\u003c/p\u003e\n\u003ch3 id=\"b12-deletion-or-return\"\u003eB.12 Deletion or return\u003c/h3\u003e\n\u003cp\u003eOn termination, you have 30 days to export. After that we delete end user\u003cbr /\u003e\ndata, including from backups within a further 60 days as backup rotation\u003cbr /\u003e\nallows, except where retention is legally required.\u003c/p\u003e\n\u003ch3 id=\"b13-audit\"\u003eB.13 Audit\u003c/h3\u003e\n\u003cp\u003eYou may request the information necessary to demonstrate compliance with this\u003cbr /\u003e\nAnnex once per calendar year, or after a breach affecting your data. Where a\u003cbr /\u003e\nrecognised certification or audit report exists, providing it satisfies this\u003cbr /\u003e\nobligation. On-site audits require 30 days' notice, must not disrupt the\u003cbr /\u003e\nservice, and are at your cost.\u003c/p\u003e\n\u003ch3 id=\"b14-international-transfers\"\u003eB.14 International transfers\u003c/h3\u003e\n\u003cp\u003eEnd user data is stored and processed on our servers in Switzerland and the\u003cbr /\u003e\nEuropean Economic Area. Switzerland benefits from a European Commission\u003cbr /\u003e\nadequacy decision, and the states of the European Economic Area are adequate\u003cbr /\u003e\nunder Annex 1 of the Swiss Data Protection Ordinance.\u003c/p\u003e\n\u003cp\u003eOne sub-processor is outside both. The mails EAuth sends (address\u003cbr /\u003e\nconfirmations, password resets, invitations) go out through Resend, Inc., a\u003cbr /\u003e\ncompany in the United States. Resend sends them from its European Union\u003cbr /\u003e\nregion, but stores the recipient's address, the subject and the text of each\u003cbr /\u003e\nmail in the United States. For data subject to the GDPR, that transfer rests on\u003cbr /\u003e\nResend's certification under the EU-U.S. Data Privacy Framework (Art. 45 GDPR),\u003cbr /\u003e\nwith the standard contractual clauses in Resend's data processing agreement in\u003cbr /\u003e\naddition (Art. 46(2)(c) GDPR). For data from Switzerland, it rests on those\u003cbr /\u003e\nstandard contractual clauses as adapted for Swiss law (Art. 16(2)(d) revDSG).\u003c/p\u003e\n\u003cp\u003eWe transfer end user data to no other country outside Switzerland and the\u003cbr /\u003e\nEuropean Economic Area. If that ever changes, we will give notice under\u003cbr /\u003e\nSection 14 before it takes effect.\u003c/p\u003e\n\u003chr /\u003e\n\u003ch2 id=\"annex-c-technical-and-organisational-measures\"\u003eAnnex C: Technical and organisational measures\u003c/h2\u003e\n\u003cp\u003eThese are the measures actually implemented, not a generic list. Each is\u003cbr /\u003e\nverifiable against the source.\u003c/p\u003e\n\u003ch3 id=\"c1-pseudonymisation-and-encryption\"\u003eC.1 Pseudonymisation and encryption\u003c/h3\u003e\n\u003cul\u003e\n\u003cli\u003ePasswords hashed with Argon2id at 64 MiB memory, 3 iterations, 2 lanes, with\u003cbr /\u003e\na 16-byte random salt per password. Parameters are embedded in each stored\u003cbr /\u003e\nhash, so raising the cost later does not invalidate existing accounts.\u003c/li\u003e\n\u003cli\u003eRefresh tokens, authorization codes, API keys, organisation invitations and\u003cbr /\u003e\ntwo-factor recovery codes are stored only as SHA-256 digests. None of them\u003cbr /\u003e\ncan be recovered from the database, by anyone, including us.\u003c/li\u003e\n\u003cli\u003eLinks sent to confirm an email address or to reset a password, and console\u003cbr /\u003e\ninvitation links, are 256 random bits stored only as SHA-256 digests. Each\u003cbr /\u003e\nworks once: a reset link for one hour, a confirmation link for a day, an\u003cbr /\u003e\ninvitation for seven days.\u003c/li\u003e\n\u003cli\u003eToken signing keys and stored third-party credentials are encrypted with\u003cbr /\u003e\nAES-256-GCM. The master key is held in the process environment and never in\u003cbr /\u003e\nthe database, so a database dump yields ciphertext only.\u003c/li\u003e\n\u003cli\u003eAll traffic uses TLS 1.3. The entire .dev top-level domain is on the HSTS\u003cbr /\u003e\npreload list, so plain HTTP is refused by the browser before a request is\u003cbr /\u003e\nmade.\u003c/li\u003e\n\u003cli\u003eRaw IP addresses are never written to request logs. Rate limits keep an\u003cbr /\u003e\naddress, an IPv6 address by its /64, only for the length of their window.\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch3 id=\"c2-confidentiality\"\u003eC.2 Confidentiality\u003c/h3\u003e\n\u003cul\u003e\n\u003cli\u003eRole-based access control on every administrative route, with permissions\u003cbr /\u003e\ndeclared as data and checked per project.\u003c/li\u003e\n\u003cli\u003eTwo-factor authentication is mandatory for every role that can change\u003cbr /\u003e\ncontent or credentials.\u003c/li\u003e\n\u003cli\u003eAdministrative sessions are validated against the database on every request,\u003cbr /\u003e\nso revoking access takes effect immediately rather than when a token expires.\u003c/li\u003e\n\u003cli\u003eAdministrative session cookies are httpOnly, Secure and SameSite=Strict, so\u003cbr /\u003e\nno credential is reachable by script.\u003c/li\u003e\n\u003cli\u003eCross-site request forgery tokens bound to the session by HMAC on every\u003cbr /\u003e\nstate-changing form, including the consent screen and the account page, and\u003cbr /\u003e\na check that the form was sent from the same origin.\u003c/li\u003e\n\u003cli\u003eSigning out through the sign-in service requires an ID token issued to the\u003cbr /\u003e\napplication for the signed-in person, or the person's own confirmation.\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch3 id=\"c3-integrity\"\u003eC.3 Integrity\u003c/h3\u003e\n\u003cul\u003e\n\u003cli\u003ePKCE with S256 is required on every authorization request. There is no code\u003cbr /\u003e\npath that issues a token without it.\u003c/li\u003e\n\u003cli\u003eRedirect URIs match exactly, in constant time. Wildcards, fragments and\u003cbr /\u003e\nplain HTTP outside loopback are refused at registration.\u003c/li\u003e\n\u003cli\u003eAuthorization codes are valid for 60 seconds, are single use, and are bound\u003cbr /\u003e\nto the client, redirect URI and PKCE challenge. A replay revokes every grant\u003cbr /\u003e\nissued to that client for that user.\u003c/li\u003e\n\u003cli\u003eRefresh tokens rotate on every use. Presenting a rotated token revokes the\u003cbr /\u003e\nentire chain, which is the standard detection for a stolen token.\u003c/li\u003e\n\u003cli\u003eThe implicit grant and the password grant are not implemented, so no\u003cbr /\u003e\nconfiguration can enable them.\u003c/li\u003e\n\u003cli\u003eID token claims are filtered by granted scope.\u003c/li\u003e\n\u003cli\u003eEvery authorization response carries the iss parameter (RFC 9207), which lets\u003cbr /\u003e\na client detect a mix-up attack.\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch3 id=\"c4-availability-and-resilience\"\u003eC.4 Availability and resilience\u003c/h3\u003e\n\u003cul\u003e\n\u003cli\u003eAutomatic database migrations with checksum verification. A modified\u003cbr /\u003e\nmigration aborts startup rather than running against an unexpected schema.\u003c/li\u003e\n\u003cli\u003eHealth endpoints checking each dependency separately.\u003c/li\u003e\n\u003cli\u003eEvery database write is committed on three servers, at three providers in\u003cbr /\u003e\ntwo countries, before it is confirmed. Two application servers and two edge\u003cbr /\u003e\nproxies, each pair at two providers in two countries, stand in for each\u003cbr /\u003e\nother.\u003c/li\u003e\n\u003cli\u003eEach service is checked continuously from the cluster, which alerts us when\u003cbr /\u003e\na check fails.\u003c/li\u003e\n\u003cli\u003eGraceful shutdown that drains in-flight requests.\u003c/li\u003e\n\u003cli\u003eRate limiting with a sliding window. Authentication endpoints fail closed, so\u003cbr /\u003e\nan outage of the limiter cannot remove brute-force protection.\u003c/li\u003e\n\u003cli\u003eEvery attempt at a password or a second-factor code is counted per IP\u003cbr /\u003e\naddress and per account before it is checked. A browser that has completed a\u003cbr /\u003e\nsign-in to an account keeps a separate allowance, so repeated failures\u003cbr /\u003e\nelsewhere cannot lock the account holder out.\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch3 id=\"c5-verification-and-evaluation\"\u003eC.5 Verification and evaluation\u003c/h3\u003e\n\u003cul\u003e\n\u003cli\u003eEvery credential change is written to an append-only audit log with the\u003cbr /\u003e\noperator's identity.\u003c/li\u003e\n\u003cli\u003eStructured request logging that records neither full IP addresses nor query\u003cbr /\u003e\nstrings.\u003c/li\u003e\n\u003cli\u003eAutomated tests covering the security rules, including nine redirect URI\u003cbr /\u003e\nvariants that have produced account takeovers at other providers.\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch3 id=\"c6-organisational-measures\"\u003eC.6 Organisational measures\u003c/h3\u003e\n\u003cul\u003e\n\u003cli\u003eSecrets are supplied through the service environment, readable by root only,\u003cbr /\u003e\nand never committed to source control.\u003c/li\u003e\n\u003cli\u003eLeast privilege: the application runs as an unprivileged user with a\u003cbr /\u003e\nrestricted system call filter and a read-only file system apart from its\u003cbr /\u003e\ndata directory.\u003c/li\u003e\n\u003cli\u003eNo independent security audit has been performed. When one is, the result\u003cbr /\u003e\nwill be published regardless of outcome.\u003c/li\u003e\n\u003c/ul\u003e\n\u003chr /\u003e\n\u003ch2 id=\"annex-d-version-history\"\u003eAnnex D: Version history\u003c/h2\u003e\n\u003ctable\u003e\n\u003cthead\u003e\n\u003ctr\u003e\n\u003cth\u003eVersion\u003c/th\u003e\n\u003cth\u003eIn effect from\u003c/th\u003e\n\u003cth\u003eChange\u003c/th\u003e\n\u003c/tr\u003e\n\u003c/thead\u003e\n\u003ctbody\u003e\n\u003ctr\u003e\n\u003ctd\u003e1.10\u003c/td\u003e\n\u003ctd\u003e9 October 2026\u003c/td\u003e\n\u003ctd\u003eThis table is corrected: version 1.8 was never published and never applied, and the changes written for it took effect with 1.9. Clause 13.1 says what deleting an account deletes, including EMX organisations in which the account holder is the only person and the enquiries sent from its address. Every version is published at legal.elchi.dev.\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003e1.9\u003c/td\u003e\n\u003ctd\u003e6 October 2026\u003c/td\u003e\n\u003ctd\u003eClause 1.4, the age requirement for registering an application, removed. Annex B.14 names the one transfer outside Switzerland and the European Economic Area, which already took place: mails sent through Resend, Inc., which stores them in the United States, and the safeguards that transfer rests on. The provider is named by its business name, Krauss Software, the sole proprietorship of Samuel Krauss (clause 1.1). With this version the changes written for 1.8 took effect: the sub-processors of the operation across several data centres are listed at docs.elchi.dev/subprocessors, added on the day of the move without notice since no one outside Elchi Studios was affected (8.6); the status page at status.elchi.dev is live (4.3, 4.9); Annex C.4 describes the replication and the checks in place, and no longer mentions push-based liveness reporting, which is not in place.\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003e1.8\u003c/td\u003e\n\u003ctd\u003eNever in effect\u003c/td\u003e\n\u003ctd\u003eWritten on 3 October 2026 and never published, so it never applied: version 1.7 applied until 1.9 replaced it on 6 October 2026. It said that end user data was not transferred to any other jurisdiction, which was not correct, since the mails EAuth sends are stored by Resend, Inc. in the United States. It is published, marked as never in effect, so the history has no gap.\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003e1.7\u003c/td\u003e\n\u003ctd\u003e3 October 2026\u003c/td\u003e\n\u003ctd\u003eauth.elchi.dev redirects to eauth.me from the day of the move rather than after ninety days, since every application registered with EAuth belonged to Elchi Studios and no one else was affected (clause 2.4).\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003e1.6\u003c/td\u003e\n\u003ctd\u003e3 October 2026\u003c/td\u003e\n\u003ctd\u003eThe service moves to eauth.me with the issuer \u003ccode\u003ehttps://eauth.me\u003c/code\u003e; auth.elchi.dev stays in service until 1 January 2027 (clause 2.4). Token requests adjustable up to 600 per minute, and counted per IP address for applications without a secret (6.2, 6.3). Annex C describes the email links, the form checks, sign-out and the sign-in limits that are now in place, and no longer mentions analytics, which EAuth does not have. The status page at status.elchi.dev is not live yet; until it is, outage notes appear in the journal (4.3, 4.9).\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003e1.5\u003c/td\u003e\n\u003ctd\u003e4 September 2026\u003c/td\u003e\n\u003ctd\u003eClauses 3.4 and 3.5 tie the free commitment to the devs.elchi.dev listing and state that a paid service lives elsewhere with its own terms.\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003e1.4\u003c/td\u003e\n\u003ctd\u003e4 September 2026\u003c/td\u003e\n\u003ctd\u003eClause 3.3 replaced. The reservation of a right to introduce paid plans contradicted the public claim that the service is permanently free, so the reservation was dropped rather than the claim.\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003e1.3\u003c/td\u003e\n\u003ctd\u003e3 September 2026\u003c/td\u003e\n\u003ctd\u003eThe provider is stated accurately as an unregistered sole proprietorship. Corrects 1.2, which named a registered business before registration had taken place.\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003e1.2\u003c/td\u003e\n\u003ctd\u003e3 September 2026\u003c/td\u003e\n\u003ctd\u003eSuperseded within a day. Named a registered business prematurely.\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003e1.1\u003c/td\u003e\n\u003ctd\u003e2 September 2026\u003c/td\u003e\n\u003ctd\u003eAdded clauses 4.5 to 4.9: third-party failures, the distinction between availability and data protection liability, and what happens to sessions during an outage.\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003e1.0\u003c/td\u003e\n\u003ctd\u003e2 September 2026\u003c/td\u003e\n\u003ctd\u003eFirst published version.\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/tbody\u003e\n\u003c/table\u003e\n\u003cp\u003eEvery version remains available at legal.elchi.dev/en/eauth-terms/versions so\u003cbr /\u003e\nyou can see what applied on any given date.\u003c/p\u003e\n","body_json":{"meta":{"scope":"Services listed at devs.elchi.dev, all of which are free permanently.","venue":"Zug, Switzerland","contact":"legal@elchi.dev","version":"1.10","document":"EAuth Terms of Service","language":"en","provider":"Krauss Software, sole proprietorship of Samuel Krauss (trading as Elchi Studios)","applies_to":["eauth.me","panel.elchi.dev","docs.elchi.dev","EAuth SDKs","auth.elchi.dev (redirects to eauth.me)"],"entity_form":"Einzelunternehmen, not entered in the commercial register","legal_basis":["Art. 28 GDPR (processor obligations)","Swiss revDSG","Art. 100 OR (limitation of liability)"],"jurisdiction":"CH","legal_entity":"Krauss Software, sole proprietorship of Samuel Krauss","governing_law":"Swiss law","effective_from":"2026-10-09"},"summary":{"price":"Free permanently. Being listed at devs.elchi.dev requires it. A service with a paid tier is not listed there and has its own terms.","audit_status":"No independent security audit performed as of version 1.0.","availability":"No service level agreement. Measured availability is published at status.elchi.dev once a full month has been measured; outages over 30 minutes are written up there and in the journal at elchi.dev/en/journal.","legal_entity":"Krauss Software, the sole proprietorship of Samuel Krauss in Oberägeri ZG, trading as Elchi Studios. Not entered in the commercial register.","breach_notice":"Within 72 hours of becoming aware.","data_location":"Servers in Switzerland and the EEA. Mails sent through Resend, Inc., which stores them in the United States, under the EU-U.S. Data Privacy Framework and standard contractual clauses (Annex B.14).","data_ownership":"The customer owns their data. Full export including password hashes, at any time.","processor_role":"Elchi Studios is the processor; the customer is the controller.","outage_behaviour":"Existing sessions survive until the access token expires (15 min default). Refresh and new sign-ins fail.","third_party_failure":"Availability is not guaranteed regardless of cause. Data protection liability for sub-processors is not excluded and cannot be."},"sections":[{"text":"1.1 These terms govern your use of EAuth, an authentication service operated by **Krauss Software** (\"we\", \"us\"), the sole proprietorship of Samuel Krauss, seated in Oberägeri, Canton of Zug, Switzerland, trading under the name Elchi Studios. Krauss Software is not entered in the commercial register. Krauss Software is the counterparty to this agreement and Samuel Krauss, as its owner, is personally liable; Elchi Studios is the name under which the service is presented. 1.2 \"You\" means the natural or legal person registering an application. If you register on behalf of a company, you confirm you are authorised to bind it. 1.3 \"End user\" means a person who signs in through your application using EAuth. End users are your users, not ours. We process their data on your instructions under the Data Processing Agreement in Annex B.","heading":"1. Who these terms are between"},{"text":"2.1 EAuth provides OAuth 2.1 and OpenID Connect authentication: a hosted sign-in page, an authorization server and token issuance at eauth.me, and the management console at panel.elchi.dev. The issuer identifier is `https://eauth.me`. 2.2 We implement the OpenID Connect Core specification and the OAuth 2.0 security practices set out in RFC 9700. Where the service deviates from a specification, the documentation at docs.elchi.dev says so. 2.3 We may change, add or remove features. Where a change would break existing integrations, we will give at least 90 days' notice by email to the address on your account and in the changelog, except where a shorter period is necessary to address a security problem. 2.4 Until 3 October 2026 the service was provided at auth.elchi.dev, under the issuer identifier `https://auth.elchi.dev`. Since that day, every request to auth.elchi.dev is answered with a permanent redirect to the same path at eauth.me. Changing the issuer breaks integrations that name it, which would call for the notice in clause 2.3. None was needed: on that day every application registered with EAuth belonged to Elchi Studios, and no one outside Elchi Studios had an account, so no integration of anyone else was affected.","heading":"2. The service"},{"text":"3.1 EAuth is provided free of charge. There is no paid tier, and we do not sell your data or your end users' data. We do not serve advertising. 3.2 Free does not mean unconditional. Section 6 sets out usage limits that exist to keep the service available for everyone, not to create an upgrade path. 3.3 We do not reserve a right to start charging for what is described here. There is no paid tier, no usage threshold that becomes an invoice, and no feature withheld to create one. This is stated as a term rather than as marketing, because a promise made only on a website is worth what a website is worth. 3.4 These terms cover the services listed at devs.elchi.dev. Being listed there requires being free permanently, so the commitment in 3.3 and the listing are the same fact stated twice. 3.5 A service with a paid tier is not listed at devs.elchi.dev and is not governed by this document. It has its own page and its own terms, which you will see before registering for it. It is administered through the same console, because that is where credentials belong regardless of price, and being in the console implies nothing about what a service costs.","heading":"3. Cost, and what \"free\" means"},{"text":"4.1 **We give no availability guarantee.** There is no service level agreement, no uptime commitment, and no compensation for downtime. 4.2 This is a deliberate consequence of clause 3.1. A free service cannot responsibly promise availability it is not paid to underwrite, and we would rather say so plainly than publish a figure we cannot stand behind. 4.3 We publish our actual measured availability at status.elchi.dev, which is live since 3 October 2026, when the service moved to our operation across several data centres. A figure appears there once a full month has been measured. It is a record of what happened, not a promise about what will happen. 4.4 If your application cannot tolerate authentication being unavailable, you should run EAuth on your own infrastructure. Section 11 covers this. ### Failures caused by third parties 4.5 We use third parties, including hosting providers, to operate the service. An outage originating with one of them is still an outage of EAuth. We do not disclaim it, because clause 4.1 already means there is no availability commitment to disclaim, whatever the cause. 4.6 This exclusion applies to availability only. It does not extend to the security of your end users' personal data. Where a third party we engaged causes a personal data breach, we remain liable to you for it under Annex B.8 and Art. 28(4) GDPR. We chose that provider; you did not. A clause purporting to shift that liability to them would be void, and we do not attempt one. ### What actually happens when EAuth is unavailable 4.7 We state this precisely so you can plan, rather than leaving you to discover it during an incident. - **Existing sessions continue.** Access tokens are signed, and your application verifies them against a cached copy of our public keys. They keep working until they expire, by default 15 minutes, without contacting us. - **Refresh stops.** Once an access token expires, the refresh call fails and the end user is signed out. - **New sign-ins fail.** Nobody can start a session. 4.8 Two things follow. First, cache the JWKS response rather than fetching it per request; your users then keep working through a short outage. Second, if minutes of lockout are unacceptable to you, tell us and we will raise your access token lifetime, or run the service yourself under Section 11. 4.9 We publish a post-incident note for any outage longer than 30 minutes, including the cause, in our journal at elchi.dev/en/journal and at status.elchi.dev. We do this whether or not the cause was ours.","heading":"4. Availability"},{"text":"5.1 You are responsible for the security of your client secrets. A leaked secret can be rotated in the console; we cannot recover one, because we store only a digest. 5.2 You must register redirect URIs exactly. We reject wildcards and matching is exact, which prevents a class of account takeover attacks but means a typo produces a rejected sign-in rather than a silent redirect. 5.3 You must validate the `state` parameter and, where you use OpenID Connect, the `nonce` claim. You must verify the `iss` parameter we return on every authorization response. These checks live in your application; we cannot perform them for you. 5.4 You must tell your end users, in your own privacy policy, that authentication is handled by Elchi Studios and what data is involved. Annex A lists what we process. 5.5 You must not use EAuth as the sole authentication for systems where a failure would cause danger to life, physical harm, or comparable irreversible loss.","heading":"5. Your responsibilities"},{"text":"6.1 You must not: - use the service to authenticate access to unlawful material, or to material that sexualises minors, incites violence, or facilitates fraud; - attempt to authenticate end users who have not agreed to use your application; - present the hosted sign-in page in a way that misrepresents who operates it, or remove the \"Secured by Elchi Studios using EAuth\" mark; - resell EAuth as your own authentication product without a separate written agreement; - probe, load-test or attempt to circumvent the service's security controls without written permission. Responsible security research is welcome under Section 12. 6.2 Default limits, which the console shows for your application: | Limit | Default | |---|---| | Token requests | 120 per minute per application, adjustable in the console up to 600 | | Authorization requests | 60 per minute per IP address | | Registered applications | 25 per account | | Registered redirect URIs | 20 per application | 6.3 These are defaults, not caps on your success. If you outgrow them, ask. Raising a limit for a legitimate application costs us a configuration change. For an application without a client secret, token requests are also counted per IP address, so requests sent in its name by others do not use up its allowance. 6.4 We may suspend an application that materially exceeds its limits, is used for the conduct in 6.1, or is generating traffic that degrades the service for others. Where the situation permits, we contact you first. Where it does not, we suspend and then contact you within one working day.","heading":"6. Acceptable use and limits"},{"text":"7.1 You own your data and your end users' data. We claim no rights over it. 7.2 The console provides a full export of your applications, organisations, end users and their metadata in JSON, at any time, without asking us. 7.3 Password hashes are included in that export in their original form, so you can migrate to another provider without forcing your end users to reset their passwords. We consider being able to leave a feature, not a risk. 7.4 If you delete an application, we delete its data within 30 days, except where we are legally required to retain records. Audit log entries relating to security incidents may be retained for up to 12 months. 7.5 If you stop using the service, we may delete an account that has had no successful authentication for 24 months, after two email notices at least 30 days apart.","heading":"7. Your data, and leaving"},{"text":"8.1 For end user personal data, you are the controller and we are the processor. Annex B is our Data Processing Agreement and forms part of these terms. 8.2 We process end user data only to provide the service, and on your documented instructions. 8.3 We notify you of a personal data breach affecting your end users without undue delay and in any case within 72 hours of becoming aware of it. 8.4 We do not use end user data to train models, to build profiles, or for any purpose other than operating the service. 8.5 Sub-processors are listed at docs.elchi.dev/subprocessors. We give 30 days' notice before adding one, and you may terminate if you object. 8.6 The sub-processors that run our operation across several data centres were added on 3 October 2026, the day the service moved there, without the notice in clause 8.5. None was needed: on that day every application registered with EAuth belonged to Elchi Studios, and no one outside Elchi Studios had an account, so no one else's end users were affected.","heading":"8. Our obligations regarding end user data"},{"text":"9.1 Measures we implement are described in Annex C. They include: passwords hashed with Argon2id, refresh tokens and recovery codes stored only as digests, signing keys encrypted at rest, mandatory PKCE, exact redirect URI matching, and TLS for all traffic. 9.2 We have not undergone an independent security audit. We say this plainly because the alternative is letting you assume otherwise. When an audit is completed, the result will be published at docs.elchi.dev regardless of outcome. 9.3 You must report a suspected compromise of your application to security@elchi.dev without undue delay.","heading":"9. Security"},{"text":"10.1 Nothing in these terms excludes liability for death or personal injury caused by negligence, for fraud, or for anything else that cannot be excluded under Swiss law. 10.2 Subject to 10.1, and because the service is provided free of charge, our total liability to you for all claims arising from these terms is limited to CHF 500. 10.3 We are not liable for indirect or consequential loss, including lost profit, lost business, or the cost of migrating to another provider. 10.4 The service is provided \"as is\". We do not warrant that it will be uninterrupted, error-free, or fit for a particular purpose. 10.5 You indemnify us against claims brought by your end users that arise from your use of the service, except where the claim results from our breach of these terms.","heading":"10. Liability"},{"text":"11.1 EAuth can be run on your own infrastructure. Doing so is permitted and encouraged for any deployment where availability or data residency matters more than convenience. 11.2 Self-hosted deployments are governed by the licence accompanying the software, not by these terms. We provide no support obligation for them. 11.3 You may not present a self-hosted deployment as being operated by Elchi Studios.","heading":"11. Self-hosting"},{"text":"12.1 We welcome reports of security problems. Send them to security@elchi.dev. 12.2 We will not pursue legal action against you for research conducted in good faith that: stays within your own account and test data, does not access or modify other users' data, does not degrade the service, and gives us 90 days before public disclosure. 12.3 We have no bug bounty programme. We will credit you publicly if you want that.","heading":"12. Security research"},{"text":"13.1 You may stop using the service and delete your account at any time. The account is deleted 30 days after you ask, and until then you can sign in, export your data and change your mind. With it goes everything that is only the account's: the applications it owns and their end users, its pictures, its sign-in history, every EMX organisation in which you are the only person, with its mailboxes, and the enquiries and support messages sent to us from its address. An EMX organisation in which others work stays theirs; your sign-in there ends. How to delete, product by product or all at once, is described at legal.elchi.dev. 13.2 We may terminate your account for a material breach of Section 6, giving 30 days' notice and an opportunity to correct the problem, except where the breach is serious enough that immediate suspension is necessary. 13.3 On termination you have 30 days to export your data.","heading":"13. Termination"},{"text":"14.1 We will give 30 days' notice of a material change, by email and in the changelog. 14.2 Continuing to use the service after a change takes effect means you accept it. If you do not, you may terminate and export your data. 14.3 Every version of these terms remains published, with its date, so you can see what applied when.","heading":"14. Changes to these terms"},{"text":"15.1 Swiss law applies. The place of jurisdiction is Zug, Switzerland. 15.2 Nothing here removes the protection of mandatory consumer law in your country of residence, where that applies.","heading":"15. Governing law"},{"text":"| Data | Why | Retention | |---|---|---| | Email address | Identifies an end user, delivers sign-in | Until deletion | | Password hash | Authentication | Until deletion | | Display name | Shown in your application | Until deletion | | TOTP secret, recovery code digests | Second factor | Until disabled | | Session and refresh token digests | Keeping a user signed in | Until expiry or revocation | | Country code (two letters) | Showing a user their own sessions | 12 months | | Timestamps of sign-in attempts | Detecting abuse | 12 months | We do not process: IP addresses in persisted form, device fingerprints, behavioural data, location beyond country, or anything derived from an end user's activity in your application.","heading":"Annex A: What we process"},{"text":"This Annex is the agreement required by Art. 28 GDPR and the equivalent provisions of the Swiss Federal Act on Data Protection (revDSG). It forms part of the Terms of Service and needs no separate signature. ### B.1 Subject matter and duration We process end user personal data solely to operate EAuth for you, for as long as your account exists, plus the retention periods in Annex A. ### B.2 Nature and purpose Authentication and authorisation: verifying an end user's identity, issuing tokens, maintaining sessions, enforcing a second factor, and recording the events needed to detect abuse. ### B.3 Categories of data subjects Natural persons who sign in to your application through EAuth, and natural persons you invite to an organisation. ### B.4 Categories of personal data As listed in Annex A. We process no special categories of data under Art. 9 GDPR, and the service must not be configured to collect any. ### B.5 Controller instructions We process personal data only on your documented instructions. These Terms, together with your configuration in the console, constitute those instructions. If we believe an instruction breaches data protection law, we will tell you and may suspend that processing until it is resolved. ### B.6 Confidentiality Everyone we authorise to process end user data is bound by a written confidentiality obligation that survives the end of their engagement. ### B.7 Security We implement the measures in Annex C. We may change a measure, but not in a way that lowers the overall level of protection. ### B.8 Sub-processors You give general authorisation for the sub-processors listed at docs.elchi.dev/subprocessors. We give 30 days' notice before adding one. If you object on reasonable data protection grounds within that period and we cannot accommodate you, you may terminate without penalty and export your data. Every sub-processor is bound by obligations no weaker than this Annex. We remain fully liable to you for their performance. ### B.9 Assisting you with data subject rights If an end user contacts us directly with a request under Art. 15 to 22 GDPR, we will not answer it ourselves. We forward it to you without undue delay, because you are the controller and only you know the context. The console provides the tools to answer such a request yourself: a full export per end user, correction of stored fields, and deletion. Where those tools are not sufficient, we assist you at no charge. ### B.10 Assisting you with obligations under Art. 32 to 36 We assist you, taking into account the nature of processing and the information available to us, with security of processing, breach notification, data protection impact assessments, and prior consultation. ### B.11 Personal data breach We notify you without undue delay and in any case within 72 hours of becoming aware of a personal data breach affecting your end users. The notice describes the nature of the breach, the categories and approximate number of data subjects and records, the likely consequences, and the measures taken. We notify you even where we are not certain the breach affects you, because that determination is yours to make. ### B.12 Deletion or return On termination, you have 30 days to export. After that we delete end user data, including from backups within a further 60 days as backup rotation allows, except where retention is legally required. ### B.13 Audit You may request the information necessary to demonstrate compliance with this Annex once per calendar year, or after a breach affecting your data. Where a recognised certification or audit report exists, providing it satisfies this obligation. On-site audits require 30 days' notice, must not disrupt the service, and are at your cost. ### B.14 International transfers End user data is stored and processed on our servers in Switzerland and the European Economic Area. Switzerland benefits from a European Commission adequacy decision, and the states of the European Economic Area are adequate under Annex 1 of the Swiss Data Protection Ordinance. One sub-processor is outside both. The mails EAuth sends (address confirmations, password resets, invitations) go out through Resend, Inc., a company in the United States. Resend sends them from its European Union region, but stores the recipient's address, the subject and the text of each mail in the United States. For data subject to the GDPR, that transfer rests on Resend's certification under the EU-U.S. Data Privacy Framework (Art. 45 GDPR), with the standard contractual clauses in Resend's data processing agreement in addition (Art. 46(2)(c) GDPR). For data from Switzerland, it rests on those standard contractual clauses as adapted for Swiss law (Art. 16(2)(d) revDSG). We transfer end user data to no other country outside Switzerland and the European Economic Area. If that ever changes, we will give notice under Section 14 before it takes effect.","heading":"Annex B: Data Processing Agreement"},{"text":"These are the measures actually implemented, not a generic list. Each is verifiable against the source. ### C.1 Pseudonymisation and encryption - Passwords hashed with Argon2id at 64 MiB memory, 3 iterations, 2 lanes, with a 16-byte random salt per password. Parameters are embedded in each stored hash, so raising the cost later does not invalidate existing accounts. - Refresh tokens, authorization codes, API keys, organisation invitations and two-factor recovery codes are stored only as SHA-256 digests. None of them can be recovered from the database, by anyone, including us. - Links sent to confirm an email address or to reset a password, and console invitation links, are 256 random bits stored only as SHA-256 digests. Each works once: a reset link for one hour, a confirmation link for a day, an invitation for seven days. - Token signing keys and stored third-party credentials are encrypted with AES-256-GCM. The master key is held in the process environment and never in the database, so a database dump yields ciphertext only. - All traffic uses TLS 1.3. The entire .dev top-level domain is on the HSTS preload list, so plain HTTP is refused by the browser before a request is made. - Raw IP addresses are never written to request logs. Rate limits keep an address, an IPv6 address by its /64, only for the length of their window. ### C.2 Confidentiality - Role-based access control on every administrative route, with permissions declared as data and checked per project. - Two-factor authentication is mandatory for every role that can change content or credentials. - Administrative sessions are validated against the database on every request, so revoking access takes effect immediately rather than when a token expires. - Administrative session cookies are httpOnly, Secure and SameSite=Strict, so no credential is reachable by script. - Cross-site request forgery tokens bound to the session by HMAC on every state-changing form, including the consent screen and the account page, and a check that the form was sent from the same origin. - Signing out through the sign-in service requires an ID token issued to the application for the signed-in person, or the person's own confirmation. ### C.3 Integrity - PKCE with S256 is required on every authorization request. There is no code path that issues a token without it. - Redirect URIs match exactly, in constant time. Wildcards, fragments and plain HTTP outside loopback are refused at registration. - Authorization codes are valid for 60 seconds, are single use, and are bound to the client, redirect URI and PKCE challenge. A replay revokes every grant issued to that client for that user. - Refresh tokens rotate on every use. Presenting a rotated token revokes the entire chain, which is the standard detection for a stolen token. - The implicit grant and the password grant are not implemented, so no configuration can enable them. - ID token claims are filtered by granted scope. - Every authorization response carries the iss parameter (RFC 9207), which lets a client detect a mix-up attack. ### C.4 Availability and resilience - Automatic database migrations with checksum verification. A modified migration aborts startup rather than running against an unexpected schema. - Health endpoints checking each dependency separately. - Every database write is committed on three servers, at three providers in two countries, before it is confirmed. Two application servers and two edge proxies, each pair at two providers in two countries, stand in for each other. - Each service is checked continuously from the cluster, which alerts us when a check fails. - Graceful shutdown that drains in-flight requests. - Rate limiting with a sliding window. Authentication endpoints fail closed, so an outage of the limiter cannot remove brute-force protection. - Every attempt at a password or a second-factor code is counted per IP address and per account before it is checked. A browser that has completed a sign-in to an account keeps a separate allowance, so repeated failures elsewhere cannot lock the account holder out. ### C.5 Verification and evaluation - Every credential change is written to an append-only audit log with the operator's identity. - Structured request logging that records neither full IP addresses nor query strings. - Automated tests covering the security rules, including nine redirect URI variants that have produced account takeovers at other providers. ### C.6 Organisational measures - Secrets are supplied through the service environment, readable by root only, and never committed to source control. - Least privilege: the application runs as an unprivileged user with a restricted system call filter and a read-only file system apart from its data directory. - No independent security audit has been performed. When one is, the result will be published regardless of outcome.","heading":"Annex C: Technical and organisational measures"},{"text":"| Version | In effect from | Change | |---|---|---| | 1.10 | 9 October 2026 | This table is corrected: version 1.8 was never published and never applied, and the changes written for it took effect with 1.9. Clause 13.1 says what deleting an account deletes, including EMX organisations in which the account holder is the only person and the enquiries sent from its address. Every version is published at legal.elchi.dev. | | 1.9 | 6 October 2026 | Clause 1.4, the age requirement for registering an application, removed. Annex B.14 names the one transfer outside Switzerland and the European Economic Area, which already took place: mails sent through Resend, Inc., which stores them in the United States, and the safeguards that transfer rests on. The provider is named by its business name, Krauss Software, the sole proprietorship of Samuel Krauss (clause 1.1). With this version the changes written for 1.8 took effect: the sub-processors of the operation across several data centres are listed at docs.elchi.dev/subprocessors, added on the day of the move without notice since no one outside Elchi Studios was affected (8.6); the status page at status.elchi.dev is live (4.3, 4.9); Annex C.4 describes the replication and the checks in place, and no longer mentions push-based liveness reporting, which is not in place. | | 1.8 | Never in effect | Written on 3 October 2026 and never published, so it never applied: version 1.7 applied until 1.9 replaced it on 6 October 2026. It said that end user data was not transferred to any other jurisdiction, which was not correct, since the mails EAuth sends are stored by Resend, Inc. in the United States. It is published, marked as never in effect, so the history has no gap. | | 1.7 | 3 October 2026 | auth.elchi.dev redirects to eauth.me from the day of the move rather than after ninety days, since every application registered with EAuth belonged to Elchi Studios and no one else was affected (clause 2.4). | | 1.6 | 3 October 2026 | The service moves to eauth.me with the issuer `https://eauth.me`; auth.elchi.dev stays in service until 1 January 2027 (clause 2.4). Token requests adjustable up to 600 per minute, and counted per IP address for applications without a secret (6.2, 6.3). Annex C describes the email links, the form checks, sign-out and the sign-in limits that are now in place, and no longer mentions analytics, which EAuth does not have. The status page at status.elchi.dev is not live yet; until it is, outage notes appear in the journal (4.3, 4.9). | | 1.5 | 4 September 2026 | Clauses 3.4 and 3.5 tie the free commitment to the devs.elchi.dev listing and state that a paid service lives elsewhere with its own terms. | | 1.4 | 4 September 2026 | Clause 3.3 replaced. The reservation of a right to introduce paid plans contradicted the public claim that the service is permanently free, so the reservation was dropped rather than the claim. | | 1.3 | 3 September 2026 | The provider is stated accurately as an unregistered sole proprietorship. Corrects 1.2, which named a registered business before registration had taken place. | | 1.2 | 3 September 2026 | Superseded within a day. Named a registered business prematurely. | | 1.1 | 2 September 2026 | Added clauses 4.5 to 4.9: third-party failures, the distinction between availability and data protection liability, and what happens to sessions during an outage. | | 1.0 | 2 September 2026 | First published version. | Every version remains available at legal.elchi.dev/en/eauth-terms/versions so you can see what applied on any given date.","heading":"Annex D: Version history"}]},"legal_basis":["Art. 28 GDPR (processor obligations)","Swiss revDSG","Art. 100 OR (limitation of liability)"],"effective_from":"2026-10-09T00:00:00Z","published":true,"source_sha256":"af567bc02dbf2a717c8fc7a489e7c0750b9140a0d41e89d6d60052d75be7bed2","created_at":"2026-10-09T05:31:13.264341Z","updated_at":"2026-10-09T05:31:13.264341Z","toc":[{"level":1,"title":"EAuth Terms of Service","anchor":"eauth-terms-of-service"},{"level":2,"title":"1. Who these terms are between","anchor":"1-who-these-terms-are-between"},{"level":2,"title":"2. The service","anchor":"2-the-service"},{"level":2,"title":"3. Cost, and what \"free\" means","anchor":"3-cost-and-what-free-means"},{"level":2,"title":"4. Availability","anchor":"4-availability"},{"level":3,"title":"Failures caused by third parties","anchor":"failures-caused-by-third-parties"},{"level":3,"title":"What actually happens when EAuth is unavailable","anchor":"what-actually-happens-when-eauth-is-unavailable"},{"level":2,"title":"5. Your responsibilities","anchor":"5-your-responsibilities"},{"level":2,"title":"6. Acceptable use and limits","anchor":"6-acceptable-use-and-limits"},{"level":2,"title":"7. Your data, and leaving","anchor":"7-your-data-and-leaving"},{"level":2,"title":"8. Our obligations regarding end user data","anchor":"8-our-obligations-regarding-end-user-data"},{"level":2,"title":"9. Security","anchor":"9-security"},{"level":2,"title":"10. Liability","anchor":"10-liability"},{"level":2,"title":"11. Self-hosting","anchor":"11-self-hosting"},{"level":2,"title":"12. Security research","anchor":"12-security-research"},{"level":2,"title":"13. Termination","anchor":"13-termination"},{"level":2,"title":"14. Changes to these terms","anchor":"14-changes-to-these-terms"},{"level":2,"title":"15. Governing law","anchor":"15-governing-law"},{"level":2,"title":"Annex A: What we process","anchor":"annex-a-what-we-process"},{"level":2,"title":"Annex B: Data Processing Agreement","anchor":"annex-b-data-processing-agreement"},{"level":3,"title":"B.1 Subject matter and duration","anchor":"b1-subject-matter-and-duration"},{"level":3,"title":"B.2 Nature and purpose","anchor":"b2-nature-and-purpose"},{"level":3,"title":"B.3 Categories of data subjects","anchor":"b3-categories-of-data-subjects"},{"level":3,"title":"B.4 Categories of personal data","anchor":"b4-categories-of-personal-data"},{"level":3,"title":"B.5 Controller instructions","anchor":"b5-controller-instructions"},{"level":3,"title":"B.6 Confidentiality","anchor":"b6-confidentiality"},{"level":3,"title":"B.7 Security","anchor":"b7-security"},{"level":3,"title":"B.8 Sub-processors","anchor":"b8-sub-processors"},{"level":3,"title":"B.9 Assisting you with data subject rights","anchor":"b9-assisting-you-with-data-subject-rights"},{"level":3,"title":"B.10 Assisting you with obligations under Art. 32 to 36","anchor":"b10-assisting-you-with-obligations-under-art-32-to-36"},{"level":3,"title":"B.11 Personal data breach","anchor":"b11-personal-data-breach"},{"level":3,"title":"B.12 Deletion or return","anchor":"b12-deletion-or-return"},{"level":3,"title":"B.13 Audit","anchor":"b13-audit"},{"level":3,"title":"B.14 International transfers","anchor":"b14-international-transfers"},{"level":2,"title":"Annex C: Technical and organisational measures","anchor":"annex-c-technical-and-organisational-measures"},{"level":3,"title":"C.1 Pseudonymisation and encryption","anchor":"c1-pseudonymisation-and-encryption"},{"level":3,"title":"C.2 Confidentiality","anchor":"c2-confidentiality"},{"level":3,"title":"C.3 Integrity","anchor":"c3-integrity"},{"level":3,"title":"C.4 Availability and resilience","anchor":"c4-availability-and-resilience"},{"level":3,"title":"C.5 Verification and evaluation","anchor":"c5-verification-and-evaluation"},{"level":3,"title":"C.6 Organisational measures","anchor":"c6-organisational-measures"},{"level":2,"title":"Annex D: Version history","anchor":"annex-d-version-history"}]}}