Privacy Policy

1. How the Service works

The Service is an application for sole proprietors and people working a second job. It records your work logs and turns them into invoices and work reports.

All data is stored in the browser on your own device (IndexedDB). We run no database for your work logs or contract information on any server, so there is no route by which they could reach us in the first place (the record of paid-plan issuance, and the purchaser details Link shares with us, are described in section 11).

This policy applies to the SoleKado website and application as served by us. Its canonical address is https://solekado.com; while the same content is also served at other addresses, this policy applies there in exactly the same way.

During the migration the same content is also served at the former address, https://solekado.endots.dev. Data stored on your device is separated by address (origin), so what you recorded at the former address cannot be seen from the new one. To move it, export a backup from the settings screen at the former address and import it at the new one.

The Service is currently offered as a limited beta. The app screens can be opened only by people whose email address we have permitted, and we use Cloudflare Access, from Cloudflare, Inc., to enforce that. We therefore hold the email addresses of the people concerned, and we entrust their handling — deciding whether access is permitted, and sending the one-time passcode used to sign in — to that company (section 14).

The introduction pages and the legal documents, including this page, are not restricted. Your work data (contracts, work logs and generated documents) still never reaches us through this arrangement: it only decides whether access is permitted and never touches what is on your device. If we lift the restriction for general release, we will say so on this page.

No server of ours holds a database of your work logs or contract information. They never reach us.

2. Information we do not obtain

None of the information listed below is ever sent to any server we run. It is handled on your own device, and leaves the device only when you make it do so — for example when you export a backup (section 3), save a generated document, export your work hours to your calendar (section 6), or authorise with Google, which tells Google the email address of the account (section 7). The purchaser details Link shares with us when you subscribe to a paid plan (name, contact details, billing address and so on) are a separate matter, handled as set out in section 11.

• The terms of your contracts and the contents of your contract documents
• Client names, the names of the people you deal with, and their contact details
• Work logs (start time, end time, breaks, description of the work) and the hours calculated from them
• Invoice amounts; the contents of invoices, timesheets (稼働明細), expense reports (経費明細), work reports (業務報告書) and work hours records (従事時間の記録); and the record of what you have submitted
• Your own business details: name, trade name, address, telephone number, your registration number as an issuer of Qualified Invoices (適格請求書 / Japan's qualified invoice system), and bank account
• Contract PDFs you import and the text extracted from them
• Events imported from a calendar, and the record of the calendar integration (the email addresses of the Google accounts you connect, their connection status and whether each is your own account or one issued to you by a client; the names and identifiers of calendars; which calendars you import from and which contract each is linked to; and the record of exports)
• Expense records, and the receipt images you bring in together with the text read from them
• Outside work hours: only the start and end times of work you do not record in the App, such as a main job (no name, description or client is kept)
• Excel templates you register in place of a supported form, and the document files the Service generates

3. Information stored on your device, and who looks after it

The data in section 2 is stored in IndexedDB, which the browser isolates per origin. Files such as Excel templates are kept in the same place.

From "Backup" in Settings you can export all of your data as a single JSON file. That file contains, in plain text, your business details including your bank account number, and the email addresses of the Google accounts recorded by the calendar integration. Please take care where you keep it.

Exporting happens only when you ask for it, and you choose where the file goes. We never receive its contents.

Your current data is saved as an "on-device snapshot" in the browser on the same device (in an IndexedDB area separate from the main one): daily (the first time you open the App each day), right before you restore from a backup, and right before an action that changes many records at once, such as deleting a contract or deleting or importing work logs in bulk. It is there so that, if you restored the wrong file or changed something by mistake, you can export it from "On-device snapshots" in Settings and go back. Daily snapshots can be turned off in Settings. The snapshots, too, exist only on your device and are never sent to us. A file exported from a snapshot contains your business details and those email addresses in plain text, just as a backup does.

We hold no copy of your data. If you clear the site data in your browser, the data cannot be brought back, on-device snapshots included. Exporting regularly is something you need to do yourself.

4. How the data is protected

The strongest safeguard in this Service is its design: your data is never sent to our servers. What is never obtained can neither leak nor be repurposed. On top of that, the concrete measures in place are listed below.

Encryption in transit

Both the delivery of this site and all traffic to the Google APIs use HTTPS (TLS). No unencrypted route is used.

Where data is stored

Events obtained from Google, the email addresses of the Google accounts you connect, and the names and identifiers of your calendars are stored only in this device’s browser (IndexedDB). They are never sent to our servers. We operate no database server for your work logs or contract information.

Access control

Because no copy of your work logs or contract information exists on our side, there is no route by which the operator, any staff member or any subcontractor could read them. It is not that access is narrowly granted; there is no place to look.

Handling of access tokens

Access tokens are held only in the memory of your browser, one for each Google account. They are never written to storage (IndexedDB, cookies or localStorage) and are lost when you close the tab or reload the page. No refresh token is issued to us or held by us, so we cannot reach Google while you are not actively using the Service.

Least privilege

We request two read-only scopes and one that covers only the calendar this app itself created. We do not request permission to change or delete your existing events. The write scope is asked for separately, the first time you use that feature (incremental authorisation). Connecting more accounts adds no permission beyond these three.

Retention and deletion

Imported events stay on your device until you delete them. Deleting one in the app removes it from the lists and from any document produced (the row itself remains on your device). The record of each connected account (its email address and so on) also stays on your device after you disconnect it. The record of a disconnected account can be erased from the device with "Remove from this device" in Settings. On-device snapshots (section 3) stay until you delete them in Settings, except that, for each kind, older ones beyond the number kept (section 15) are deleted the next time a snapshot of the same kind is saved. To erase everything from the device, clear the site data in your browser. The Google grant itself can be revoked from "Disconnect" in Settings, which shows whether the revocation succeeded, or from your Google Account permissions page (https://myaccount.google.com/permissions).

Third parties and outbound traffic

No analytics tag and no advertising tag is installed, and no external web fonts or CDNs are loaded. Information obtained is never provided or sold to third parties, and is never used to develop or train artificial intelligence or machine learning models.

That we hold no copy of your data also means we cannot restore anything from our side. On-device snapshots do not help against a broken device or cleared site data, so export a backup yourself.

5. Permissions requested by the Google Calendar integration

The Google Calendar integration is optional. If you do not use it, no connection to Google takes place at all.

When you connect in order to import events, the two read-only scopes below are the only ones we request. Each is used for the purpose stated beside it and for nothing else.

The one write scope (the third row) is requested separately, and only the first time you use "Export work hours to your calendar" (incremental authorisation). It does not appear on the consent screen of anyone who only imports.

https://www.googleapis.com/auth/calendar.events.readonly

Reading events (events.list). Used to bring calendar events in as candidate work logs and as day records. Event identifiers (such as the iCalUID) are also read, to recognise events already imported and the same event appearing in more than one calendar. Read-only: the Service can neither change nor delete an event.

https://www.googleapis.com/auth/calendar.calendarlist.readonly

Reading the list of calendars (calendarList.list). Used so that you can choose which calendars to import from, to tell which account is connected (the identifier of an account’s primary calendar is its email address), and to leave the dedicated export calendar the Service created unselected by default among the calendars to import. Read-only.

https://www.googleapis.com/auth/calendar.app.created

Requested only if you use "Export work hours to your calendar". Used to create, update and delete events inside the dedicated calendar the Service itself creates ("SoleKado 稼働"), and to check that this calendar still exists and which account it belongs to; nowhere else. It grants no access, read or write, to your existing calendars or events.

The write scope reaches only inside the dedicated calendar the Service created for itself. Events in calendars that already existed cannot be read, changed or deleted with it — they cannot even be listed.

6. How we handle information obtained from Google

Events you import are processed entirely inside your browser and stored in IndexedDB on your device. They are not transmitted to us, to our servers, or to any third party.

By default an event is attached to a date as a day record and is not counted towards your hours worked. Counting a meeting as time worked would double-count the hours you then log properly. Whether to bring an event in as work is a choice you make at each import.

If you use "Export work hours to your calendar", the Service creates, updates and deletes events in the dedicated calendar it created in the one Google account you chose to export to, and only when you explicitly ask it to. It touches events in no other calendar.

The Service's use and transfer of information received from Google APIs adheres to the Google API Services User Data Policy, including the Limited Use requirements.

Google user data obtained through the Service is never used to develop, train or improve artificial intelligence or machine learning models. No human reads it, it is never sold, and it is never provided to third parties.

7. Access tokens, and the traffic a connection generates

An access token is held only in the memory of your browser. It is written neither to IndexedDB nor to a cookie, so it is gone once you close the tab.

No refresh token is issued. When a token expires, a new one is obtained the next time you press the button. The Service never goes to fetch events while you are not using it.

If you connect more than one Google account, each is authorised separately and its access token is held in memory separately. When you load events from, export work hours to, or revoke access for an account already connected, your device sends Google the email address recorded for that account, so that Google knows which account is meant (login_hint).

When you start a connection, the Google Identity Services script is loaded from accounts.google.com and requests are made to the Google Calendar API (www.googleapis.com). By the nature of that traffic, connection information such as your IP address and browser type reaches Google and is handled under Google's privacy policy.

8. How to revoke the Google permissions

Pressing "Disconnect" for a Google account shown in the settings screen discards the access token held on your device for that account. If a valid access token for that account can be obtained, the Service also asks Google to revoke the grant, checks Google’s response, and shows on screen whether it was revoked. Revoking removes every permission that account has given the Service, including the one for exporting, and applies equally where you use the same account at another address (section 1). The Service never revokes the grant of a different account.

The access token lives solely in the memory of your browser (section 7), so none is held for that account after you reload the page, close the tab, or once the token has expired. When none is held, the Service first tries to obtain one again through Google’s sign-in screen, which may open briefly, and then asks for the revocation. If no token can be obtained — for example because you are not signed in to that Google account — or the revocation request fails, pressing "Disconnect" only removes the connection on your device, and the grant in your Google Account stays in place. The Service tells you on screen when this happens and points you to the page in the next paragraph.

To revoke with certainty, remove access for SoleKado under "Third-party apps & services" in your Google Account: https://myaccount.google.com/permissions

Disconnecting or revoking does not remove the events already brought into your device, or the record of the connected account (its email address, whether it is your own account or one issued to you by a client, and the names and identifiers of its calendars); they stay there. Delete events from within the app if you no longer want them. The record of an account can be erased with "Remove from this device" in Settings once it is disconnected (the source shown on events already imported stays). To erase all of this from the device, clear the site data in your browser (section 15).

The one way to revoke the grant on the Google side for certain is https://myaccount.google.com/permissions. "Disconnect" in the app only removes the connection on your device when no valid token for that account can be obtained or the revocation fails; the app tells you when that happens.

9. Reading .ics files

An .ics file exported from Outlook or Apple Calendar is read entirely on your own device. Neither the file nor anything in it is sent anywhere.

10. Handling of contract PDFs

Contract PDFs are read entirely inside your browser. pdf.js and the files it needs to do the work are served from this site, and nothing in the document is sent to an external API or to a large language model (LLM).

The extracted text is only shown on screen; you check it and decide yourself what to carry over onto the contract. The PDF file itself is not stored, and is discarded once reading has finished.

11. Payment (sold through Link)

Paid plans are sold on the website only. The checkout and the collection of payment are handled on our behalf by Link, a service provided by affiliates of Stripe ("Link"; the checkout shows the purchase as "Sold through Link", and the sale is handled by Sold through Link, LLC).

What you enter at checkout (your name, email address, payment details and so on) is collected directly by Link, which handles it on its own responsibility, not as a party we have entrusted with it. Your full card number and security code never reach us.

Link shares the details of your order with us (contact details such as your name and email address, your billing address, part of your payment details, what you ordered, and so on). We look at them in our Stripe account and use them to issue, verify and reissue licences; to write to you individually about your purchase, about a refund for example; to answer your enquiries; to deal with disputed charges; to check for misuse of licences; and for our accounting and tax records. Separately, our licence server receives notifications from Stripe when you purchase and when the subscription is renewed, changed or cancelled; on the basis of those notifications it fetches the subscription details from Stripe (such as its state, period and customer identifier), and in situation (3) below it receives the portal’s address. Where a notification contains your contact details, the server does not store them. Work logs, contract information, client names, amounts and documents never travel through the payment route.

What our licence server keeps is the record of issuance only: the licence identifier; the identifiers Stripe uses for the subscription and for the customer; the checkout-session identifier (used to hand the licence over on the page shown after purchase); the plan; the state of the subscription; the end of the current period; whether the subscription is set to be cancelled at the end of the period, and when; the times used to decide on renewal (the end of the previous period, when we saw the period move on, and when the latest Stripe notification we applied was created); and the identifiers of Stripe notifications already processed (so that none is applied twice). That record contains neither your name nor your email address (the purchaser details are in our Stripe account, as described above).

Your device makes a request to our licence server in the following situations: (1) when you collect a licence on the page shown after purchase, in which case the checkout-session identifier is sent; (2) when the Service checks whether the licence has been renewed and what the renewal schedule is, whether automatically or because you press "Check now", including after the expiry date has passed; and (3) when you open the portal (the page for changing your payment method or cancelling) from Settings. In (2) and (3), what is sent is the licence string registered on your device, which contains the licence identifier, the plan, the date of issue, the expiry date and our signature. In (2), together with the renewed licence, we return whether the subscription is set to be cancelled at the end of the period, and when; your device uses this to show the renewal schedule in Settings. In (3), we pass to Stripe the Stripe customer identifier that corresponds to that licence, and receive the portal’s address in return. In every situation, the server also receives the IP address, the time of the request and the headers your browser sends. No work logs, contract information or documents are sent.

We do not keep a log of those requests. We record neither successes nor failures, so no history of when anyone used the Service is created. Records that may remain on the hosting platform (Cloudflare) are outside our control, and we cannot claim that none exist. Likewise, when you open the portal (situation (3)), a record of our request to Stripe to create it may remain on Stripe’s side.

Licences are checked on your own device. The Service does not contact us each time you produce a document. Automatic renewal requests are sent only while an app screen is open, either from seven days before the expiry date or when you display the subscription status in Settings, and at most once a day in total for each browser and site. Here "site" means the address at which you open the Service (section 1): if you have registered a licence at more than one address, each counts separately. Days are counted by the calendar date in Japan time. These requests continue after the expiry date until the Service learns that the subscription has ended; removing the licence stops them from that browser and site. Separately, each time you press "Check now", one request is sent.

What Link and the Stripe companies do on their own responsibility is governed by Link’s privacy policy (https://link.com/privacy) and Stripe’s privacy policy (https://stripe.com/privacy).

We have not yet begun selling paid plans to the general public, and we will give notice when we do. Every feature, document output included, is free to use at present. What this section describes — payment, and traffic to our licence server — takes place in only two cases: when someone subscribes to a paid plan (including subscribing with a code that makes it free of charge), and on a device where a licence is registered.

12. Cookies, browser storage and analytics

The app itself uses no cookies for authentication, and there are no user accounts. During the limited beta, however, Cloudflare Access sets a cookie in your browser recording that you have signed in (it includes your permitted email address), so that access to the app screens can be restricted (section 1).

We have installed no analytics tools (Google Analytics or any other measurement tag). We neither collect behavioural data nor track anyone for advertising.

If we introduce analytics in future, we will revise this policy and give notice on this page before doing so.

The app itself uses the three kinds of browser storage below. All of them sit on your own device, and we cannot read any of them.

IndexedDB

Holds everything listed in section 2: contracts, work logs, expenses and receipt images, outside work hours, your business details, the record of the calendar integration, document templates and the files the Service generates. If you register a licence, the licence and a record of when renewal was checked, and with what kind of result, are kept here too (the licence is included in backups; the record of checks is not). On-device snapshots (section 3), and the setting for whether to take daily snapshots, are kept in a separate area (solekado-device). On your device, it is the only place the Service puts personal data.

localStorage

Remembers one thing only: whether you have dismissed the notice on the introduction site that tells you the way into the app has moved (key solekado.lp.movedNoticeDismissed, holding the marker "1"). No personal data goes in it.

Cache Storage

The Service Worker caches pages you have already opened (the page cache), so that a screen can still be shown offline. What it caches is the page itself; work logs and other data are not in it, because the data lives in IndexedDB and is loaded after the screen opens.

IndexedDB is the only place the Service itself puts personal data. localStorage holds a single marker for a dismissed notice, and Cache Storage holds the page cache — neither contains work logs or contract information.

13. Traffic that leaves your device

The four kinds of traffic below are the only ones that can leave the Service. No external web fonts, CDNs, advertising or analytics tags are loaded. The typefaces on screen are the ones already installed on the device you are reading with.

The pdf.js worker used to read contract PDFs, the files and Japanese training data used to read receipts, and the built-in document templates (Excel), are all fetched from this site rather than from any external host. They are only fetched; nothing is sent with the request. Receipt images and the text read from them never leave your device.

The Service Worker that lets the app work offline only caches pages you have already opened on your device (the page cache). That cache is never sent anywhere.

• Delivery of this site. It is served as static files from Cloudflare, and by the nature of that platform connection information such as your IP address may be logged when you visit. During the limited beta, opening an app screen may take you to the Cloudflare Access sign-in page (on that company’s domain) so that access can be checked.
• Traffic from your device to Google when you use the Google Calendar integration (sections 5 to 8). Starting a connection loads a script from accounts.google.com, and requests for reading events and the list of calendars, for exporting, and for revoking access are sent to Google.
• Traffic to Stripe and Link when you subscribe to a paid plan, or manage your subscription through the portal or Link (section 11). Unless you subscribe, no such traffic occurs.
• Traffic to our licence server when you collect a licence, when the Service checks whether it has been renewed, and when you open the portal (section 11).

14. Third parties and subcontractors

We do not provide or sell the information we obtain to third parties.

The only parties we entrust with work are Stripe (including its affiliates), for the two tasks below only, and Cloudflare, Inc. We entrust Stripe with keeping the subscription and the purchaser details Link shares with us in our Stripe account, and with creating the portal in situation (3) of section 11. We entrust Cloudflare with delivery of this site, operation of our licence server and storage of the issuance records, and access control for the app screens (Cloudflare Access). During the limited beta, Cloudflare handles email addresses in order to decide whether access is permitted and to send the one-time passcode used to sign in. That handling is entrusted work carried out on our instructions; Cloudflare does not use those addresses for its own purposes. Neither party handles your work logs or contract information. Purchaser details, the issuance records, the connection information from your visits, and the limited-beta allow list are processed outside Japan, including in the United States. Separately, what Link and the Stripe companies do on their own responsibility with the information entered at checkout (section 11) is not work we entrust to them, and may also take place outside Japan, including in the United States and India (as set out in Link’s privacy policy).

The Google Calendar integration is traffic between your own device and Google; it does not pass through us. We neither receive your data from Google nor hand your data to Google.

We will comply with a request for disclosure made under the law. What we hold, however, is limited to our correspondence with you, the record of paid-plan issuance and the purchaser details Link shares with us (section 11), and the limited-beta allow list (email addresses).

15. Retention and deletion

Data stored on your device stays there until you delete it. We set no expiry and delete nothing ourselves, because we cannot reach it.

On-device snapshots (section 3) stay until you delete them in Settings or clear the site data. For each kind, however, older ones beyond the number kept are deleted the next time a snapshot of the same kind is saved (the newest 7 daily snapshots are kept, and the newest 10 each of the snapshots taken right before a restore and right before an action that changes many records at once). They have no expiry. Records you deleted in the app remain inside any snapshot taken before you deleted them. Daily snapshots are taken on each day you open the app, so a record you deleted also remains in the older daily snapshots until seven more daily snapshots have been taken. If you want a deleted record gone from the snapshots right away, delete those snapshots from "On-device snapshots" in Settings.

Clearing the site data (IndexedDB) in your browser erases all of it, on-device snapshots included. It cannot be brought back. Export whatever you need first, from "Backup" in Settings.

Emails you send us are kept as a record of how we dealt with your enquiry, and deleted once they are no longer needed.

The record of paid-plan issuance (section 11) is deleted automatically one year after the subscription has ended; until then it is kept in case of enquiries about refunds or reissuing. It contains neither your name nor your email address. The marks recording which notifications from Stripe have been processed (the notification identifiers) are deleted 30 days after they are received.

The purchaser details Link shares with us (section 11) are kept in our Stripe account and, apart from the identifiers listed in section 11, are never copied to our server. There is no mechanism that deletes them automatically after a set period. You may ask us to disclose, correct or delete them (section 16). Because we also use them for our accounting and tax records (section 11), however, we may be unable to meet a request for deletion during the period for which tax law requires books and records to be kept (according to Japan’s National Tax Agency, seven years as a rule for a sole proprietor’s books and records, or five years for some documents). You may also ask Link directly to delete them; in that case, under Link’s own rules, the details in our Stripe account are deleted too and any subscription bought through Link is cancelled (after which the licence is no longer renewed).

The limited-beta allow list (email addresses) is held only for the duration of the limited beta. We delete it when the restriction is lifted, or when the person concerned asks us to.

16. Contact

For enquiries about this policy or about how personal information is handled, please use the contact details below.

Operator

Endots (sole proprietor), operated by Koryu Kawatani

Service name

SoleKado

Email address

founder@endots.dev

17. Changes to this policy

Whenever we change the contents, we update the "Last updated" date on this page.

Before we make a substantive change to what we obtain or what we use it for, before we add a Google API scope, and before we introduce analytics, we will give notice on this page.

If a Google API scope changes, we will ask those who are already connected to consent again — in practice, by pressing "Disconnect" for each connected account in the settings screen and connecting once more. Section 8 explains how to make sure the old grant is really gone.