Privacy Policy

Last updated: 2026-08-31 / Effective: 2026-08-13

Aifuda is an iOS app that surfaces reservations buried in your mailbox at the moment you need them.

The design principle in one sentence: mail bodies are not sent to Aifuda’s servers. The details follow.

1. Summary

2. What is stored on your device only

2-1. Reservations (SwiftData, app-private container)

The structured reservation extracted from the mail is stored. Outlook and the sample also keep the body of the mail it came from, linked to that reservation (see 2-6). Bodies from Gmail are not stored.

Stored fields:

• Route (departure and arrival stations), train name, departure and arrival times
• Car number, seat number, number of seats
• Confirmation number
• Fare amounts (face value / charged / refunded)
• The "as of" timestamp of the information
• An internal identifier for the mail template the data came from

Not stored — "not stored" here means not extracted into a structured field. If a value below appears verbatim in the mail body, Outlook and the sample keep that body per 2-6 whenever the mail is recognized as a reservation. Gmail does not keep the body, so those values do not remain as part of a stored email either:

• The body or subject of mail that is not recognized as a reservation (discarded on the spot; Outlook and the sample keep a recognized body per 2-6; Gmail bodies are not stored)
• The HTML version of a mail, and ordinary attachments (PDF, ICS, images, etc.). Only the plain-text body is stored. The exception is .pkpass — when a recognized email carries an issuer-signed Apple Wallet pass, it is stored on device so it can be added to Wallet later (up to 8, deleted automatically at most 7 days after the reservation starts, excluded from iCloud backup)
• The membership ID is not extracted into a structured field. It is only hashed with SHA-256 to build a unique key; only the first 16 hex digits are kept
• IC card numbers are not extracted into a structured field (discarded during parsing)
• Names or contacts are not extracted into a structured field. The intro card you fill in yourself is separate; see 2-5
• Email addresses are not extracted into a structured field. The only address kept in the Keychain is the one for the account you connect (see 2-2); the sender address of each mail is stored as metadata under 2-6

If a membership ID, IC card number, name, or contact detail appears verbatim in an Outlook or sample email that was recognized as a reservation, it remains in the stored body as part of that email (see 2-6). Gmail does not keep the body, so those values do not remain that way.

This data lives in the app's private container and is covered by iOS Data Protection. The developer cannot access it.

2-2. Access tokens (iOS Keychain)

If you connect Gmail or Outlook, the access and refresh tokens are stored only in the iOS Keychain. They are never written to preferences, logs, or any server.

The email address of the account you connect is stored in the same Keychain. It is used only to show which account is connected on the Accounts screen, it is not sent to Aifuda’s servers or written to logs, and it is deleted when you disconnect.

2-3. App settings (UserDefaults)

Only non-secret values: OAuth client IDs, the Wallet signing server URL, Pass Type ID, and Team ID. The signing server's auth token is the one exception and is stored in the Keychain.

2-4. Widget snapshot (App Group container)

To render the home screen / lock screen widget and the Live Activity, the app writes a JSON file containing only what is displayed: train name, departure and arrival stations, departure and arrival times, the first seat, and the seat count.

It deliberately excludes the confirmation number, fare amounts, and the membership ID hash, because that data would otherwise appear on the lock screen.

2-5. Your intro card (what you type in yourself)

Aifuda lets you build an intro card you can hand over like a business card. This is the one place where the app stores information you typed, rather than anything read from mail.

Stored: display name, the fields you arranged (a title and its content — how many, and what they are called, is up to you), the images you set on the card (the band and the icon), and — only if you set the QR code to “contact” — an email address and a phone number.

• It lives in the same app-private container on your device as the reservations. The developer has no access to it
• It is never sent to the developer’s server. Adding the card to Apple Wallet still sends only manifest.json, a dictionary of file names and checksums (§3-2)
• Put a URL in a field and the app shows the mark and handle of that service (GitHub, X, and so on). That is decided on the device by reading the URL; the service itself is never contacted
• The email address and phone number appear only inside the card’s QR code, never printed on the face of the card. You choose who gets to scan it
• The images you set are embedded in the pass. A card is made to be handed over, so sharing it from Wallet hands the images over too (the opposite of how reservation passes are treated — see §6). That happens directly from Wallet, never through the developer’s server
• Sharing by “Wallet link” (§3-4) covers reservation passes only. An intro card never becomes a share link
• It does not appear in widgets, Live Activities, or Next fuda
• Deleting the card removes it — images included — from the device. A pass you already added is removed from within Wallet

2-6. The original mail

For Outlook and the sample, when mail is recognized as a reservation, the body is stored on your device and can be read again from the reservation’s detail screen. Values in the body that match the current reservation may be highlighted in yellow; wording differences can keep a value from being highlighted.

Bodies from Gmail are not stored. Only the structured reservation or package Aifuda read remains. Any Gmail body left by an earlier build is deleted on each sync.

• What is stored is the plain-text body, plus metadata used to display it, deduplicate it, and open the original mail (subject, sender address, received time, mail identifiers, and the source account). The HTML version and ordinary attachments are not stored (the .pkpass exception is described in 2-1)
• Up to 256K characters are stored per email; any remainder is not stored
• It lives in the same app-private container as the reservations. It is never sent to the developer’s servers
• Aifuda never automatically sends it to a Wallet pass, the Lock Screen, a Live Activity, a widget, or shared text. You can select and copy it from the detail screen inside the app. Depending on your iOS backup settings, it may be included in your device backup
• A reservation may have multiple source emails (booking, seat assignment, reminders). Up to 16 are kept per reservation; beyond that the oldest are dropped
• Mail that is not recognized as a reservation has neither its body nor its subject stored. Outlook and the sample keep only mail from which a reservation was extracted. Gmail bodies are not kept
• Deleting a reservation deletes the bodies linked to it
• Choosing “Disconnect” in the app deletes every body taken from that account (the reservations themselves remain). If you only revoke access from Google’s or Microsoft’s own settings, the locally stored copies are not deleted automatically (see sections 4 and 5)
• Reservations imported before this feature existed have no body attached. For those, the “Original mail” section does not appear at all

3. Network traffic that leaves your device

These are the only destinations the app contacts:

There are no analytics beacons, ad networks, or crash-reporting SDKs. The only third-party SDK is RevenueCat (Purchases).

3-0. Aifuda Pro (subscriptions)

• Payment and the subscription contract are with Apple. Price, trials, and cancellation follow the App Store / iOS Settings
• The app uses the RevenueCat SDK with an anonymous ID to check the pro entitlement. Aifuda does not create an account with your name or email
• In App Store Connect App Privacy, we declare Purchases (Purchase History) (as RevenueCat documents; App Functionality / Analytics), Other User Content (the .pkpass shared through a Wallet link; App Functionality), Device ID (App Attest and Live Activities; App Functionality), and Search History (the short query used during image import; App Functionality). Purchases and Search History are not linked to identity. Other User Content may contain reservation details, and Device ID persistently distinguishes the same device, so both are declared as linked under Apple’s definition. None is used for tracking.

3-1. Mail bodies

Requests to the Gmail API and Microsoft Graph are made directly from your device. They do not pass through the developer's servers. Retrieved mail bodies are not sent to Aifuda’s servers. Outlook and the sample store the body of a recognized reservation in the on-device database so you can read it again in the app (see 2-6). Gmail bodies are not stored. Mail that is not recognized as a reservation is discarded on the spot.

The app uses two types of search filters: (1) sender filters for the reservation services Aifuda supports, and (2) subject filters such as subject:reservation, applied whatever the sender. The number of candidate messages retrieved through subject filters is limited per sync. Messages matching either filter are retrieved to your device and evaluated there.

A message retrieved from an unsupported sender through a subject filter is saved only when its body contains reservation structured data in a schema.org format Aifuda supports and Aifuda recognizes it as a reservation. Once Aifuda determines that a message is not a reservation, its body and subject are discarded immediately and never stored.

Only if you explicitly turn on the Aifuda Pro setting (off by default) does the on-device model also read the bodies of these messages; in that case a message without schema.org data can still be saved when the model reads a reservation out of it. A reservation read by the model is marked “On-device” so you can compare it with the original mail inside the app.

3-2. Apple Wallet pass signing

An Apple Wallet pass (.pkpass) must be signed with a certificate issued by Apple. Bundling that signing key inside the app is prohibited by Apple's terms and unsafe in any case, so the signing step alone is delegated to the developer's server.

Only manifest.json is sent. It is a dictionary mapping file names to SHA-1 hashes; it contains none of the reservation's content (stations, seats, times, confirmation number). The pass body (pass.json) and the images are not sent for signing.

This describes adding a pass to your own Wallet. There is one case where the pass file itself does leave the device: when you create a “Wallet link” to hand the pass to someone else. Please read 3-4 below.

The server does not log the contents of manifest.json. It logs only byte counts, file counts, and error reason codes, and it retains nothing after returning the signature.

A precise note: the SHA-1 hashes explain what is not sent; they are not a cryptographic guarantee of secrecy. Someone who knows the pass template and the candidate values could in principle recover them by brute force. Our claim is that reservation content is not sent to the server — not that it would be unrecoverable from what is sent.

3-3. Factual web lookup during image import

For image import, OCR and structuring run with the on-device language model. The image itself and the full OCR text never leave the device.

When the model needs help interpreting an airport code or flight number, it may send only a short search query to DuckDuckGo (for example NGS airport Japan). Prompts and length limits keep passenger names, seats, confirmation numbers, and full OCR out of the query. This path is used only for image import, not for on-device extraction of mail bodies (to stay aligned with Google Limited Use). DuckDuckGo handles the query under its Privacy Policy.

3-4. Handing a pass to someone else with a “Wallet link”

When you share a reservation and pick “Wallet link” in the share sheet — and only then — the app uploads the assembled .pkpass file to Aifuda's server and creates a short URL the other person can open. This is the only way to put a copy of your reservation into someone else's Wallet, because Wallet fetches the file from a URL.

So this action, and only this action, places the contents of the pass on the server. Those contents are what you intend the other person to see: route or venue, date and time, train or flight number, seat, reservation number, address, and phone number — the values printed on the front and back of the pass. Sharing as plain text does not use this path.

• It is kept for at most 48 hours, then deleted automatically and the URL stops working. There is no way to revoke it earlier from your device
• The URL carries an unguessable random token. Anyone who has the URL can fetch the file — choose who you send it to
• The server treats the file as opaque bytes. It does not parse the contents and does not log them (it logs byte counts and result codes only)
• A photo you put on your own pass is not included in the shared copy — it is baked only into the pass added to your own Wallet
• Once the recipient adds the pass, it lives on their device. Aifuda cannot remove it

3-4a. Handing a reservation to another Aifuda user with an “Aifuda link”

The share sheet also offers an “Aifuda link”. If the recipient has Aifuda, they can import the reservation as their own fuda.

This link never passes through the developer’s server. A compressed reservation summary is carried after the # in the link. That fragment is not sent to a web server, so the developer does not know that the link was created or shared. The 48-hour server retention in 3-4 applies only to a Wallet link.

• The link carries only values already shown on the pass and share text: kind, route or venue, date and time, seat, reservation number, address, and phone number
• It has no fields for the mail body, membership ID or its derived value, IC card number, names of companions or hotel guests, payment method, amounts, or notes
• The recipient sees a summary first and nothing is saved until they choose Import
• The link can be forwarded, and anyone who obtains it can read its contents. Choose where you send it. It cannot be revoked because it is not stored on a server
• The imported reservation is marked as received through a shared link. It has no original mail and does not update if the source reservation changes

3-5. Device check (App Attest) and automatic Live Activities

The signing and sharing server verifies with Apple's App Attest that a request comes from a genuine copy of Aifuda on a genuine iPhone, so that the server cannot be abused by third parties. To do that it stores a per-device key ID, its public key, a signature counter, and timestamps. They are not tied to your name, e-mail address, or Apple ID, but they do persistently distinguish the same device; this is why Device ID is declared as linked in the App Store privacy label. The source IP address is also used for anti-abuse rate limits.

If you use automatic Live Activities (Aifuda Pro), the server additionally keeps an APNs push token and a schedule of when to start a Live Activity. The schedule holds only the fire time and a keyed hash of the reservation identifier computed with a secret held on your device; station names, seats, train numbers, and confirmation numbers are not included (and never appear in the payload that passes through Apple's APNs either). Each entry is deleted as soon as it fires. If you do not use the feature, an empty schedule is sent and the server-side record is cleared.

4. Google user data (Limited Use)

The Gmail integration is not available in the currently shipping build. It is intentionally disabled while Google's OAuth review (restricted scope verification) is in progress. This section describes the handling that will apply once it is enabled.

When you use the Gmail integration, Aifuda requests only the https://www.googleapis.com/auth/gmail.readonly scope. It never sends, modifies, or deletes mail.

Aifuda's use and transfer to any other app of information received from Google APIs is intended to adhere to the Google API Services User Data Policy, including the Limited Use requirements.

Specifically, Aifuda's intent is not to:

• Use or transfer Google user data for advertising, including retargeting, personalized advertising, or interest-based advertising
• Allow humans to read the data, except for security purposes, to comply with applicable law, or with your explicit consent (no such mechanism exists today)
• Use the data to train or improve AI/ML models
• Sell or transfer the data to third parties
• Retain persistent copies beyond what is required to provide the feature. Bodies from Gmail are not stored (see 2-6). Structured reservations and packages stay on the device until they are deleted, all items are deleted, or the 16-per-reservation cap is reached

Mail bodies retrieved from Gmail are handled entirely on device and are never transmitted to the developer's servers. The body is not stored; only the extracted reservation or package remains on the device. Any Gmail body left by an earlier build is deleted on each sync.

Revoking access: choosing "Disconnect" on the Accounts screen in the app deletes the stored token, the connected address, and the bodies stored for that account (reservations remain). If you revoke access only from your Google Account permissions page, the locally stored token and bodies are not deleted automatically — use "Disconnect" in the app as well to remove them.

5. Microsoft Graph (Outlook)

When you use the Outlook integration, Aifuda requests only Mail.Read, User.Read, offline_access, and openid. User.Read is used once, to read the address of the account you connected so the Accounts screen can show it (see 2-2). It never sends, modifies, or deletes mail.

Requests to Microsoft Graph go directly from your device. Mail bodies are not sent to Aifuda’s servers. The body of an email from which a reservation was extracted is kept on the device as described in 2-6 (this is the difference from Gmail). The data is never used for advertising, transferred to third parties, or used to train models.

Revoking access: choosing "Disconnect" on the Accounts screen in the app deletes the stored token, the connected address, and the bodies stored for that account (reservations remain). If you revoke access only from Microsoft account apps and services (or My Apps for work or school accounts), the locally stored token and bodies are not deleted automatically — use "Disconnect" in the app as well to remove them.

6. Location, photos, contacts, calendar

Your location is never read. The app does not use the framework that reads the device’s position (CLLocationManager) and never prompts for location permission. Contacts are not touched either.

Your calendar is read only after you ask for it. Two places do it, and both request calendar permission at that moment: the “Import from calendar” screen, where you pick the events, and the “Auto-import events with a place” setting, which is off by default and explained in full before it can be turned on. With that setting on, Aifuda looks at events from yesterday through the next six months while the app is open or coming back to the foreground, and imports only those that have a place, a title, and a start time — never all-day events, invitations you declined, birthdays, or subscribed calendars such as holidays. It never reads your calendar in the background. Only the fields shown on a fuda are stored (title, place, times); event notes and attendees are not. Deleting a fuda keeps that event from being imported again.

Drawing a map does send the places written in your reservation to Apple, in exactly two situations:

• When a Wallet pass is given a “show this when you get there” condition, the address text from the reservation goes to Apple’s geocoder (CLGeocoder) to be turned into coordinates
• When the map thumbnail on a pass, or the map image in a share, is drawn, the coordinates of the origin and destination go to Apple’s map service (MKMapSnapshotter)

Both go to Apple, not to the developer’s server. What is sent is the place written in the reservation — never where you are now. Apple’s own handling is covered by the Apple Privacy Policy.

The app never asks for photo library access either. Importing a screenshot, and choosing the picture for a Wallet pass, both go through the iOS photo picker: only the single image you pick is handed to the app, which cannot see the rest of your library. That image is processed entirely on the device, and the cropped version is stored only on the device (and excluded from iCloud backup). It is never uploaded — signing a Wallet pass sends only manifest.json, a dictionary of file names and checksums; not one byte of the image leaves the phone. Share links you send to other people do not carry the picture either.

The camera is used only when you tap “Take a photo” and open it. Aifuda asks for permission at that moment, so you can read reservation details straight off a paper ticket or another device’s screen. Declining changes nothing else — importing an image you pick still works. The captured photo is not added to your photo library, and it is handled exactly like an image you pick: text recognition and reservation extraction run on the device, and the photo itself is never uploaded. Aifuda does not open the camera in the background, and does not record video or audio.

Images on an intro card are the one exception, by design. A card is made to be handed over, so the images you set are embedded in the pass and travel with it when you share the card from Wallet (§2-5). That hand-off is Wallet’s own; it does not pass through the developer’s server.

7. Tracking and advertising

No tracking. The app does not read the advertising identifier (IDFA), does not present an App Tracking Transparency prompt, and shows no ads. No third-party tracking SDKs are embedded.

8. Children's privacy

Aifuda is not directed at children. Mail bodies are never transmitted to the developer, and the developer does not knowingly collect children's personal data.

9. Deleting your data

Aifuda requires no sign-up, so there is no account to delete.

10. Sharing with third parties

Personal data is never sold or shared for advertising purposes. What is shared is limited to what you explicitly choose to share (a "Wallet link") and the destinations described in section 3. In response to a lawful request, the developer can only disclose the data described in 3-4 and 3-5.

11. Storage location and retention

Your reservations live on your iPhone. There is no permanent reservation database on the developer's side. Reservations are kept until you delete them individually, use "Delete all reservations," or delete the app. Original mail bodies are also deleted when the 16-per-reservation cap is reached or when you disconnect the account.

The developer’s server (Cloudflare) holds the following. There is no permanent reservation database:

• A pass you shared as a “Wallet link” — deleted automatically within 48 hours (3-4 above)
• Values needed for the device check and Live Activities — a per-device key ID, public key, signature counter, last-seen time, push token, and pending start times (3-5 above). Schedule entries are deleted when they fire. Attestation keys and valid push tokens currently have no fixed retention period and are kept while needed for the feature and abuse prevention
• Anti-abuse rate-limit state — request counts and last-updated time keyed by source IP address. It currently has no fixed retention period and is kept while needed for rate limiting
• Short search queries during image import — not stored on the developer’s server; sent directly to DuckDuckGo (3-3)

12. Changes to this policy

If this policy changes, the "Last updated" date above is revised. Significant changes are also noted in the app's release notes.

13. Contact

• Email: biwashi.dev@gmail.com
• Developer: Shota Iwami