Coyotech Privacy Policy / 隱私權政策
Last updated / 最後更新: 2026-10-24
English
This one policy covers both Coyotech apps: dresspec and Dietosaur. Shared sections apply to both; the app sections describe what each app actually collects and does.
Jump to
Who we are and contact
The controller of both apps is Leo Lin, an independent developer operating as Coyotech. For anything in this policy, contact support@coyotech.app.
dresspec
dresspec ("the app", "we") is an outfit recommendation app. This section describes what data we collect, how we use it, and what choices you have.
What we collect
- Account identity. Email, name, profile picture and your Google
sub, or (iOS) your Apple user ID and the email/name Apple shares (possibly a private relay address).- When: when you sign in with Google or Apple.
- Where it goes: stored in our database (
userstable). - Why: identify your account so your wardrobe follows you across devices.
- Clothing photos and item details. Photos of clothing items you upload, and the details you enter or confirm for each item (category, subcategory, color and the free-text note).
- When: when you add or edit an item.
- Where it goes: photos go to Google Cloud Storage (us-central1, USA); each photo is also sent transiently to Google Gemini API for tagging and outfit visualization. Item details are stored in our database (
clothing_items) and sent to Gemini with your styling requests. - Why: recognize the garment so the AI styling works.
- Optional body photos.
- When: when you upload one or generate an AI full-body photo.
- Where it goes: same as above (storage + Gemini transient).
- Why: used as a visual reference in outfit mockups, AI full-body photos and the hairstyle simulator.
- Hairstyle simulator. The body photo you pick and, optionally, a reference hairstyle photo (both can contain faces).
- When: when you tap generate in the Hairstyle tab.
- Where it goes: sent through our servers to Google Gemini to produce the preview. The generated image is returned to your device and kept only on your device. The reference photo is never stored by us; the source photo is one of your already-stored body photos.
- Why: show a hairstyle preview on you.
- Generated outfit mockup images.
- When: when an outfit mockup is created.
- Where it goes: sent through our servers to Gemini; the result is returned to your device and kept only on your device (not stored on our servers) unless you share the outfit (see Share links below).
- Why: visualize the outfit.
- Body measurements. Gender, height, weight, shoulder/bust/waist/hip, body type.
- When: when you fill out the profile.
- Where it goes: stored in our database.
- Why: personalize outfit recommendations.
- Occasion text you type (e.g. "wedding guest").
- When: when you request a recommendation.
- Where it goes: sent to Google Gemini for processing, and stored in our database with your outfit history (
styling_sessions), your likes/dislikes (outfit_feedback) and any share link you create. - Why: generate appropriate outfits, show your history.
- Approximate location (low-accuracy GPS).
- When: only when you tap "Surprise me" and grant location permission.
- Where it goes: read on your device; the coordinates are sent directly from your device to Open-Meteo (weather) and BigDataCloud (city and country), and the country code to Nager.Date (public holidays). The coordinates are not sent to our servers and we do not store them. "Surprise me" then builds a text from the result (city name, weather, season, holiday) and submits it automatically as your occasion: it is sent to our servers and to Google Gemini, and stored with your outfit history like any occasion text, so the city name (approximate location) is retained until you delete your account.
- Why: suggest an occasion that fits your weather and date.
- Share links. Copies of the piece photos of a shared outfit, the outfit mockup image only if you tick "include the try-on mockup" when sharing (off by default), plus the occasion, outfit title, rationale and piece names/colors.
- When: when you tap share on an outfit.
- Where it goes: copies are stored in your own storage folder and the page is served from a public link. Anyone with the link can view it, with no login, until you delete your account (there is no separate revoke).
- Why: let you show an outfit to other people.
- Outfit likes / dislikes.
- When: when you tap 👍/👎.
- Where it goes: stored in our database; the titles of outfits you liked or disliked are sent to Gemini with later styling requests.
- Why: improve future recommendations for you.
- Purchase and subscription records, and image generation records. What you bought (credit packs, the Plus subscription), its status and renewal dates, and your credit balance; and, for each image generation, the route, model, credits charged and time.
- When: when you buy, restore or manage a purchase, and when you generate an image.
- Where it goes: stored in our database; purchase verification and subscription status are handled by RevenueCat (see Third parties below). Apple or Google processes the payment itself; we never receive your card or other payment details.
- Why: provide the service (credits and subscription), manage your account, and analytics: RevenueCat's purchase analytics. Not used for advertising.
- Reports of AI images. When you report a generated outfit mockup, hairstyle preview or AI full-body photo as offensive: which kind of image it was, which full-body photo (for that kind), the optional reason you type (up to 500 characters) and the time. The reported mockup or preview image itself is not sent to us.
- When: when you tap report on a generated image.
- Where it goes: stored in our database (content_reports) until you delete your account.
- Why: review reports of offensive AI output and improve how images are generated.
- Usage events (e.g.
app_opened,item_added,styling_requestedwith metadata like counts, latency, category), each with a random device ID and, while you are signed in, your account ID.- When: while using the app.
- Where it goes: stored in our database (
telemetry_eventstable). - Why: improve the product. Never includes photo content, item names, body measurements, or occasion text.
What we do not collect
- We don't read your contacts, calendar, or files outside the app's own storage, and we don't collect advertising or hardware identifiers (advertising ID, IMEI, etc.). Location is read only for "Surprise me", as described above. The app does generate a random device ID that is attached to usage events (see Retention & deletion).
- We don't sell or share any of the above with advertisers or data brokers.
Third parties involved
- Google Cloud — hosts our backend and data. The backend runs on a Compute Engine virtual machine in us-central1 (Iowa, USA), shared with other apps operated by the same developer; dresspec's PostgreSQL database runs on that machine, separate from the other apps' databases. Photos are stored in Google Cloud Storage, us-central1.
- Google Gemini API — performs the AI tagging, styling, and mockup generation. Each request sends the relevant images + your body metrics (including gender) + occasion text + your item details (category, color, note) + titles of outfits you liked or disliked to Google. Google's data handling for paid Gemini API requests is governed by their API Terms.
- RevenueCat (USA) — a processor acting for us: verifies purchases and keeps subscription status. It processes our user ID for you, your purchase records, and the device and app version information its SDK sends. It does not collect advertising identifiers. Apple and Google are the payment providers: we never receive your payment details, and they keep purchase records under their own policies.
- Google Sign-In and Sign in with Apple (iOS) — handle the actual sign-in. We receive a verified identity but never your password.
- Open-Meteo, BigDataCloud, Nager.Date — only for "Surprise me": weather, reverse geocoding and public holidays, as described above. Like any web request, these services see your IP address.
Retention & deletion
- Your data stays in our database until you delete your account. You can delete it in the app (Settings → Delete account), which removes your account, wardrobe, body data, outfit history and photos. Photos uploaded within about an hour of deletion may remain in storage until we remove them manually; contact us to confirm removal.
- Deleting your account deletes your credits and purchase records from our live database; any remaining credits, including occasion pack credits, are forfeited. Database snapshots taken before maintenance (we keep the five most recent) and server logs may still contain them until they rotate out. We also ask RevenueCat to delete your purchase records; if that request fails, we delete them manually. Deleting your account does not cancel an App Store or Google Play subscription — cancel it in your store settings.
- Generated outfit mockups and hairstyle previews are kept only in the app's local storage on your device. Our servers do not store them. They are removed when you uninstall the app, but may be restored from your device's own backup (iCloud or Android Auto Backup) if backups are enabled. Share links are the exception: a shared outfit's piece photos are stored as copies and viewable via the link until you delete your account. If you opt in at share time, the outfit mockup (generated from your full-body photo) is stored with the share and is also publicly viewable through the link.
- Usage telemetry rows are retained indefinitely for trend analysis. When you delete your account they are kept but unlinked from it (
user_idis cleared). The app also replaces its device ID at that point, so a new account on the same device can't be linked to them. The old rows still carry the old random device ID, so rows from the same device can be grouped together, but nothing ties them to your account or identity. The device ID is kept in the device's secure storage; on iOS (Keychain) it can survive uninstalling the app until the next account deletion, on Android it is removed with the app.
Your rights, children, security, international transfer and changes to this policy are in the section for both apps.
Dietosaur
Dietosaur is developed and operated by an individual, who is the collector and holder of this data. This section describes what the app actually does, not what it intends to do. If any sentence disagrees with the app's behavior, that is a defect; please tell us.
The three most important things
- Photos have all metadata, including GPS coordinates, stripped the moment they enter the app, so where you ate never leaves your phone.
- There is no analytics, tracking, advertising or crash-reporting SDK. The number is zero, not "few".
- You can delete your whole account in the app, and it is a real delete: cloud photos are deleted first, and only after that succeeds are the database rows deleted. There is no retention period, no soft delete, and no copy kept for analytics.
What we collect and why
- Account. You sign in with Google. From Google we get your Google account identifier (
sub) and your email address. We never have, and cannot have, your Google password. The account exists only so your food log syncs across devices and you can get back in after changing phones. - Your food log. Dish names, portion multipliers, calories and protein/carbs/fat per portion, the time you ate, and the corrections you made to estimates. This is the content of the app itself.
- Meal photos. The original image you took or picked from your gallery. We keep the original rather than a thumbnail so the same photo can be re-estimated later with a better model.
- The photo's metadata is stripped as it enters the app: every EXIF and XMP segment is discarded, including GPS coordinates, camera model and capture time. Only orientation is kept, otherwise sideways photos would show lying down. Stripping happens before the photo is sent for estimation and before it is stored in the cloud, so neither place ever received your location.
- This was not true before 2026-09-13: until then, photos picked from the gallery were sent with their EXIF. That defect is fixed, and we state it here rather than fixing it silently. Before the fix the app had never been publicly released; its only users were the developer and one test account.
- Usage. When each estimate happened, the number of model tokens used, and which model version was called. This is our proof of cost and the only basis for detecting abuse. It is also a record of when you ate, so it is deleted together with everything else when you delete your account, and is not kept as statistics.
- Stored only on your device. A local copy of your full diary and your photo files. Your sign-in credentials are kept in Android Keystore-backed encrypted storage and are excluded from cloud backup and device-to-device transfer. If you use Health Connect, the app writes nutrition records (calories, protein, carbs, fat, meal name, meal type, time span) into Android's Health Connect store; this stays on the device and needs the Health Connect nutrition write permission; other apps you grant Health Connect read access can read those records. Only the install that logged a meal writes it.
What we do not collect
- Location. The app does not request location permission, and photo GPS is removed on entry.
- Weight, height, age, gender, or any body measurement.
- Contacts, SMS, call logs, or data from other apps.
- Advertising identifiers, or any cross-app tracking.
- Payment information. The service is currently free; we have no card number and no way to process payments.
- Analytics, behavioral events, crash reports. There is no such package anywhere in the code.
Where data is sent
Google Gemini (estimation)
- To turn a photo into calorie figures, the photo itself and a fixed prompt are sent to Google's Gemini API. If you corrected dish names, those words are sent too. The photo passes through our server on its way to Gemini.
- Nothing in what is sent points to you: no account identifier, no sign-in token, no device identifier. Gemini receives a photo and a prompt and does not know who ate it.
- Only estimation is sent. The dinosaur's line on the diary page used to be generated by the model (until 2026-09-13), so a meal's name, calories and your day's total calories and meal count were sent. Now that line is composed on your phone and works offline: nothing leaves your phone to make the dinosaur talk.
- What Google does with it is governed by Google's Gemini API Additional Terms. We use a paid tier, under which Google does not use your prompts or responses to improve its products and has no routine human review; Google retains content only for a limited period for abuse detection, service security and legal requirements, and that temporary retention may be in any country.
- This depends on the tier, so the reverse: on the free tier Google does use prompts and responses to improve products, and human reviewers may read them (Google says it first disconnects them from account, key and project). We do not plan to move to the free tier; if we ever do, this page changes first.
Google Cloud Storage (photos)
- Stored photos are not uploaded through our server: the app transfers them directly with Google's storage using temporary links we issue, valid for one file only and for 5 to 15 minutes. The bucket is configured at platform level to be never publicly accessible, so even a mistaken permission would be rejected by Google.
- Our server also uses Google IAM Credentials (to sign those links) and Google Secret Manager (to load our own secrets). Neither carries your food log or photos; the signed links do contain an opaque account ID in the photo path.
Our own server
- Your food log and account data are stored in our own database. Apart from the Google services listed above, and Google Sign-In for signing in, no other third party receives anything.
Retention and deletion
- No automatic deletion and no automatic retention. Your data stays until you delete it. There are no scheduled jobs, no lifecycle rules, no "keep for 90 days".
- Deleting one meal. The meal's photo is deleted from the cloud first, then its record is deleted. There is no recovery window: soft delete is off and versioning is off, so deleted means deleted. One thing remains: a deletion record saying that a meal was deleted at a certain time, with no dish name, no numbers, no photo. It exists because your other devices need it to know the meal is gone, otherwise the next sync would bring it back. It disappears when you delete your whole account. Also, if you ate the same dish at another meal, that dish's name and nutrition numbers are kept, because another meal still uses it.
- Deleting your whole account. Do it on the app's Account page. The order is deliberate: all your cloud photos are deleted first, and only after every one succeeds is the account deleted. If any photo cannot be deleted, the whole action stops, nothing is deleted, and you are told your data is still there, because once the account is gone nothing would point to those photos. After the account is deleted, every server table related to you is emptied: sign-in sessions, usage records, food log, dishes, estimates, deletion records. At the same time the local diary and photo files on that phone, and the nutrition records this app wrote into Health Connect, are deleted. This cannot be undone, and we cannot undo it for you.
- Without the app. You can also request deletion by email, from the Google account you used to sign in to Dietosaur; we complete it within 7 days and reply when done; see dietosaur.coyotech.app/delete-account.
- Sign-in state. Sign-in credentials last at most 30 days, and the short-lived one only 15 minutes. When you sign out, the server-side credential is invalidated immediately instead of waiting to expire.
Where the server-side data is stored
All server-side data (database and photos) is in Google Cloud us-central1 (Iowa, USA), so your food log and photos are transferred outside Taiwan and stored in the United States. This is a cost trade-off, not a preference: the service currently runs on Google's free-tier machine, and that spec only exists in a few US regions. By using the app you consent to this international transfer. If that is not acceptable to you, the app is not for you, and we would rather you know now.
How we protect the data
- All connections use HTTPS, with automatically renewed certificates.
- Sign-in credentials are stored on the server only as hashes (SHA-256), never in plain text, so even a leaked database could not be used to replay a sign-in.
- All secrets are in Google Secret Manager: not in the code, not in the image, not in the machine's metadata.
- Photo storage has object-level ACLs off and public access prevention enforced; every read is a single-file signed link that expires in minutes.
- The server has no private key file: links are signed through Google's IAM service as the machine's own identity.
- SSH to the machine is only through Google's IAP tunnel and is closed to the internet.
- Release builds of the app write nothing to the phone's system log.
- Sign-in credentials on the phone are in Android Keystore-encrypted storage and excluded from cloud backup and device transfer.
What we cannot do. The service runs on a single machine. The database has no backup, and nothing monitors whether it is alive. By design your phone holds the original of your data and the server is a copy, so this does not lose your diary, but if that machine fails, the server's copy may be gone while the one on your phone remains. We would rather write this than a content-free line like "we use industry-standard security".
Dietosaur's own website
Its pages are plain static pages: no cookies, no analytics, no third-party components, and nothing is left in your browser.
Your rights, children, security, international transfer and changes to this policy are in the section for both apps.
Both apps
These sections apply to dresspec and to Dietosaur.
International transfer
- dresspec: its backend, PostgreSQL database and photo storage are in Google Cloud us-central1 (Iowa, USA), so your data is transferred to and stored in the United States; it sends data to Google Gemini API as described in its section, and Gemini calls may be processed in any country. The Supabase project (Mumbai, India) used by older app versions was deleted on 2026-10-07.
- Dietosaur: all server-side data (database and photos) is in Google Cloud us-central1 (Iowa, USA); calls to Google Gemini API may be served from any country. See the Dietosaur section.
Security
Sign-in is handled by Google Sign-In (both apps) and Sign in with Apple (dresspec, iOS); we receive a verified identity but never your password. The specific security measures we have implemented for Dietosaur are listed in its section. For dresspec, your data is held in Google Cloud (a virtual machine and Cloud Storage in us-central1) that we control.
Your rights
You have these rights for both apps. Under Taiwan's Personal Data Protection Act, Article 3, they cannot be waived in advance.
- Access / copy: request a copy of everything we have tied to your account.
- Correction: edit your data directly in the app at any time (dresspec: profile and wardrobe; Dietosaur: each meal's estimate), or ask us.
- Stop processing: request that we stop collecting, processing or using your data. There is no in-app switch; we act on your request, for example by deleting the account.
- Deletion: delete your account and all associated data in the app, or by contacting us. What is kept after deletion, if anything, is stated in each app's retention section (for dresspec, usage telemetry is kept without a link to your account, and snapshots, logs and RevenueCat records may remain as described in its retention section).
To exercise any of these, email support@coyotech.app. We respond to access or copy requests within 15 days (extendable by 15 days with notice to you), and to correction, stop-processing and deletion requests within 30 days. Dietosaur account deletion by email is completed within 7 days.
Children
Neither app is directed at children under 13. If you believe a child has signed up, contact us and we will delete the account.
Changes to this policy
When we make a material change, we post the new version at this same URL and change the "Last updated" date.
This website
coyotech.app and Two Designs' website, fortune.coyotech.app (the free Human Design test and the app's page), are static sites served by Cloudflare. Their pages use Google Analytics 4 (measurement ID G-J64LWY5QSX) so we can understand how the sites are visited. This covers only the websites, not the apps. On fortune.coyotech.app, Google gets a page's address without the part after the "#", which is where a test result's link keeps its chart, and never the birth details you enter; on the full report's page it gets only the page's path, without the payment references Portaly adds when you return from paying; the pair invitation page has no Google Analytics. What the test does with the birth details you enter, and what an order for the full report bought there stores, are in the Two Designs privacy policy; that purchase is governed by the Two Designs terms.
- What it collects: the pages you view and the site that sent you, your approximate location (country and city, derived by Google from your IP address), and your device type, operating system, browser and screen size.
- How: a script from Google sets first-party cookies (
_ga,_ga_*) in your browser to tell visits apart. - Why: to understand how many people visit and which pages they read. It is not linked to your account in any app, and not used for advertising.
- Google: Google processes this data as described in How Google uses information from sites or apps that use its services. You can block it with your browser's tracker or cookie settings, or with the Google Analytics opt-out add-on.
Contact
Leo Lin (Coyotech) · support@coyotech.app · Last updated: 2026-10-24
繁體中文
這份政策同時涵蓋 Coyotech 的兩個 app：dresspec 與 Dietosaur。共通章節適用於兩者；各 app 章節說明該 app 實際收集與做的事。English version
我們是誰與聯絡方式
兩個 app 的負責人是 Leo Lin，一位以 Coyotech 名義營運的獨立開發者。本政策任何問題請聯絡 support@coyotech.app。
dresspec
dresspec（「本 app」、「我們」）是一款穿搭推薦 app。本章節說明我們收集什麼資料、如何使用，以及你有哪些選擇。
我們收集什麼
- 帳號身分。Email、名稱、頭像、Google
sub；或（iOS）Apple 使用者 ID 與 Apple 提供的 email／名稱（可能是私人轉發信箱）。- 何時：你用 Google 或 Apple 登入時。
- 存放在哪：我們的資料庫（
users表）。 - 用途：識別你的帳號讓衣櫃跨機同步。
- 衣物照片與衣物資料。你上傳的衣物照片，以及你為每件衣物輸入或確認的資料（類別、子類別、顏色與自由文字備註）。
- 何時：新增或編輯衣物時。
- 存放在哪：照片存在 Google Cloud Storage（us-central1，美國），每張照片同時暫時傳給 Google Gemini API 做識別和搭配示意圖；衣物資料存在我們的資料庫（
clothing_items），並隨搭配請求傳給 Gemini。 - 用途：讓 AI 能辨識衣物。
- 全身照（選填）。
- 何時：你上傳或用 AI 生成全身照時。
- 存放在哪：同上。
- 用途：作為搭配示意圖、AI 全身照與髮型模擬器的人物參考。
- 髮型模擬器。你選的全身照，以及（選填）參考髮型照片（都可能含臉部）。
- 何時：你在「髮型」分頁按生成時。
- 存放在哪：經我們的伺服器傳給 Google Gemini 產生預覽。生成的圖片只回傳並保存在你的裝置上；參考照片我們不會儲存；來源照片是你已儲存的全身照之一。
- 用途：顯示套用髮型後的預覽。
- 生成的搭配示意圖。
- 何時：建立搭配示意圖時。
- 存放在哪：經我們的伺服器傳給 Gemini；結果只回傳並保存在你的裝置上，伺服器不儲存（除非你分享該搭配，見下方「分享連結」）。
- 用途：讓你看到搭配效果。
- 身材數據。性別、身高、體重、肩寬／胸／腰／臀、體型。
- 何時：你填寫時。
- 存放在哪：我們的資料庫。
- 用途：個人化搭配推薦。
- 你輸入的場合文字（例如「婚禮 guest」）。
- 何時：你請求搭配時。
- 存放在哪：傳給 Google Gemini 處理，並與你的搭配紀錄（
styling_sessions）、喜歡／不喜歡（outfit_feedback）及你建立的分享連結一起存在我們的資料庫。 - 用途：產生對應場合的搭配、顯示你的歷史紀錄。
- 大概位置（低精度 GPS）。
- 何時：只有在你按「幫我搭」並允許定位權限時。
- 存放在哪：在你的裝置上讀取；座標直接從你的裝置傳給 Open-Meteo（天氣）與 BigDataCloud（城市與國家），國家代碼傳給 Nager.Date（國定假日）。座標不會傳到我們的伺服器，我們也不儲存。「幫我搭」接著會用結果（城市名稱、天氣、季節、節日）組成一段文字，並自動當成場合送出：它會傳到我們的伺服器與 Google Gemini，並和一般場合文字一樣存在搭配紀錄中，因此城市名稱（大概位置）會保留到你刪除帳號為止。
- 用途：建議符合當下天氣與日期的場合。
- 分享連結。被分享搭配中單品照片的複本、搭配示意圖（只有在分享時勾選「包含換裝示意圖」才會包含，預設不含），以及場合、搭配標題、說明、單品名稱／顏色。
- 何時：你按分享時。
- 存放在哪：複本存在你自己的儲存資料夾，頁面以公開連結提供。任何拿到連結的人都能不用登入檢視，直到你刪除帳號（沒有另外的撤銷功能）。
- 用途：讓你把搭配給別人看。
- 搭配的喜歡／不喜歡。
- 何時：你點 👍/👎 時。
- 存放在哪：我們的資料庫；你喜歡或不喜歡的搭配標題會隨之後的搭配請求傳給 Gemini。
- 用途：改進你未來的推薦。
- 購買與訂閱紀錄，以及生圖紀錄。你購買的項目（場合包、Plus 訂閱）、狀態與續訂日期、點數餘額；以及每次生圖的路徑、model、扣除的點數與時間。
- 何時：你購買、恢復或管理購買，以及生圖時。
- 存放在哪：我們的資料庫；購買驗證與訂閱狀態由 RevenueCat 處理（見下方第三方）。付款本身由 Apple 或 Google 處理，我們不會收到你的信用卡或其他付款資料。
- 用途：提供服務（點數與訂閱）、帳號管理與分析（RevenueCat 的購買分析），不用於廣告。
- AI 圖片檢舉。你把 AI 搭配圖、髮型預覽或 AI 全身照檢舉為不當內容時：是哪一種圖、哪一張全身照（檢舉全身照時）、你選填的原因（最多 500 字）與時間。被檢舉的搭配圖或髮型預覽本身不會傳給我們。
- 何時：你在生成的圖片上按檢舉時。
- 存放在哪：我們的資料庫（content_reports），直到你刪除帳號。
- 用途：審查不當 AI 內容的檢舉，並改善圖片的生成方式。
- 使用事件（例如
app_opened、item_added、styling_requested含計數、延遲、類別等 metadata），每筆附隨機裝置 ID，登入期間另附你的帳號 ID。- 何時：你使用 app 過程中。
- 存放在哪：我們的資料庫（
telemetry_events表）。 - 用途：改進產品。不會包含照片內容、衣物名稱、身材數值或場合文字。
我們不收集
- 不讀通訊錄、行事曆、app 自己儲存範圍以外的檔案，也不收集廣告 ID、IMEI 等廣告或硬體識別碼。位置只在「幫我搭」時讀取，如上所述。app 會產生一組隨機的裝置 ID，附在使用事件上（見「保留與刪除」）。
- 不會把上述資料賣給或分享給廣告商或資料中介。
涉及的第三方
- Google Cloud — 託管我們的後端與資料。後端跑在 us-central1（美國愛荷華州）的 Compute Engine 虛擬機上，與同一位開發者營運的其他 app 共用機器；dresspec 的 PostgreSQL 資料庫跑在這台機器上，與其他 app 的資料庫分開。照片存在 Google Cloud Storage（us-central1）。
- Google Gemini API — 執行 AI 標籤、搭配、示意圖生成。每次請求會把相關照片 + 身材數據（含性別）+ 場合文字 + 你的衣物資料（類別、顏色、備註）+ 你喜歡或不喜歡的搭配標題傳給 Google。Google 對付費 Gemini API 的資料處理依其 API 條款。
- RevenueCat（美國）— 代我們處理資料的 processor：負責購買驗證與訂閱狀態。它會處理我們的使用者 ID、你的購買紀錄，以及它的 SDK 傳送的裝置與 app 版本資訊，不收集廣告識別碼。Apple 與 Google 是付款方：我們不會接觸你的付款資料，它們會依各自的政策保留購買紀錄。
- Google Sign-In 與 Sign in with Apple（iOS）— 處理登入流程。我們拿到已驗證的身分資訊，但拿不到你的密碼。
- Open-Meteo、BigDataCloud、Nager.Date — 只用於「幫我搭」：天氣、反向地理編碼與國定假日，如上所述。如同一般網路請求，這些服務看得到你的 IP 位址。
保留與刪除
- 你的資料留在我們資料庫直到你刪除帳號。你可以在 app 內刪除（設定 → 刪除帳號），會移除帳號、衣櫃、身材資料、搭配紀錄與照片。刪除前後大約一小時內上傳的照片，可能會留在儲存空間，直到我們手動移除；如需確認移除，請聯絡我們。
- 刪除帳號會從我們的正式資料庫刪除你的點數與購買紀錄；剩餘的點數（包含場合包點數）一併作廢。維護前所做的資料庫快照（我們保留最近五份）與伺服器 log，在輪替掉之前仍可能包含這些資料。我們也會請 RevenueCat 刪除你的購買紀錄；若該請求失敗，我們會手動刪除。刪除帳號不會取消 App Store 或 Google Play 的訂閱，請到商店的設定自行取消。
- 生成的搭配示意圖與髮型預覽只保存在你裝置上的 app 本機儲存，我們的伺服器不儲存。解除安裝 app 就會清掉，但若啟用裝置備份（iCloud 或 Android 自動備份），可能會從備份還原。分享連結是例外：被分享搭配的單品照片會以複本儲存，並可透過連結檢視，直到你刪除帳號。若你在分享時選擇包含，搭配示意圖（由你的全身照生成）也會隨該分享儲存，並可透過連結公開檢視。
- 使用 telemetry 紀錄會無限期保留做趨勢分析。你刪除帳號後這些紀錄會保留，但與帳號的連結會被清除（
user_id清空）。app 也會在此時更換裝置 ID，讓同一支裝置上的新帳號無法連到這些紀錄。舊紀錄仍帶有舊的隨機裝置 ID，因此同一支裝置的紀錄可被歸在一起，但無法連回你的帳號或身分。裝置 ID 存在裝置的安全儲存區；在 iOS（Keychain）上，解除安裝 app 後它可能保留到下次刪除帳號，在 Android 則隨 app 移除。
你的權利、兒童、資訊安全、國際傳輸與政策變更見兩個 app 共通章節。
Dietosaur
Dietosaur 由個人開發與營運，是這些資料的蒐集者與保有者。本章節描述 app 實際上做了什麼，不是描述它打算做什麼。如果哪一句跟實際行為不符，那是缺陷，請告訴我們。
先講三件最重要的
- 照片在進入 app 的那一刻就被拿掉所有中繼資料，包括 GPS 座標。所以「你在哪裡吃的」這件事從來沒有離開過你的手機。
- 沒有任何分析、追蹤、廣告或當機回報 SDK。數量是零，不是「很少」。
- 你可以在 app 裡刪掉整個帳號，而且是真的刪：雲端的照片先被刪光，成功之後才刪資料列，沒有保留期、沒有「軟刪除」、沒有留一份做分析。
我們蒐集什麼，為什麼
- 帳號。你用 Google 登入。我們從 Google 拿到的是你的 Google 帳號識別碼（
sub），以及你的電子郵件地址。我們從來沒有、也不可能有你的 Google 密碼。帳號存在的唯一理由，是讓你的飲食紀錄能跨裝置同步、以及在你換手機之後回得來。 - 你的飲食紀錄。菜名、份量倍數、每份的熱量與蛋白質／碳水／脂肪、你吃的時間、以及你對估算做的修正。這些就是這個 app 的內容本身。
- 餐點照片。你拍的或從相簿選的原圖。保留原圖而不是縮圖，是為了日後能用更好的模型重新估算同一張照片。
- 照片的中繼資料在進入 app 的當下就被剝掉——EXIF 與 XMP 的每一個區段都被丟棄，包含 GPS 座標、相機型號、拍攝時間。唯一留下來的是「方向」，不然側拍的照片會顯示成躺著的。剝除發生在照片送去估算之前、也在存進雲端之前，所以那兩個地方從來沒有收過你的位置。
- 這件事在 2026 年 9 月 13 日之前並不成立：在那之前，從相簿選的照片會帶著 EXIF 一起送出。這個缺陷已經修好，而我們把它寫在這裡而不是安靜地改掉。修正之前這個 app 從未公開發行，使用者只有開發者本人與一個測試帳號。
- 使用量。每一次估算的發生時間、用掉的模型 token 數、以及呼叫了哪個模型版本。這是我們付錢的憑據，也是判斷服務有沒有被濫用的唯一依據。它同時也是「你在什麼時候吃東西」的紀錄，所以刪帳號的時候它跟其他東西一起刪，不會被留下來當統計。
- 只留在你裝置上的東西。完整日記的本機副本與照片檔案。登入憑證放在 Android Keystore 加密的儲存區，且排除在雲端備份與換機轉移之外。如果你使用健康連結（Health Connect），app 會把營養紀錄（熱量、蛋白質、碳水、脂肪、餐點名稱、餐別、時間區間）寫進 Android 的 Health Connect；這只在裝置上，且需要 Health Connect 的營養寫入權限；你授予 Health Connect 讀取權限的其他 app 可以讀到這些紀錄。只有記錄那一餐的安裝才會寫入。
我們沒有蒐集什麼
- 位置。app 沒有要求位置權限，照片的 GPS 也在進入時就被移除。
- 體重、身高、年齡、性別，或任何身體測量值。
- 通訊錄、簡訊、通話紀錄、其他 app 的資料。
- 廣告識別碼，或任何形式的跨 app 追蹤。
- 付款資訊。這個服務目前不收費，我們沒有你的卡號，也沒有處理付款的管道。
- 分析、行為事件、當機回報。整個程式碼裡沒有任何一個這類套件。
資料會送到哪裡
Google Gemini（估算）
- 要把一張照片變成熱量數字，照片本身與一段固定的提示文字會送到 Google 的 Gemini API。如果你修正過菜名，那些字也會一起送去。照片在送往 Gemini 的途中會經過我們的伺服器。
- 送出去的內容裡沒有任何指向你的東西：沒有帳號識別碼、沒有登入 token、沒有裝置識別碼。Gemini 收到的是一張照片跟一段提示，不知道是誰吃的。
- 而且只有估算會送。恐龍在日記頁說的那句話，在 2026 年 9 月 13 日之前也是模型生成的，所以那一餐的名稱、熱量、你當天的總熱量與餐數都會送去 Google。現在那句話是在你手機上組出來的，不連網也會說話——為了讓恐龍講話，已經沒有任何東西離開你的手機。
- Google 收到之後怎麼處理，適用 Google 的 Gemini API 附加條款。我們用的是付費方案，依該條款，Google 不會用你的提示或回應來改進它的產品，也沒有例行的人工審閱；Google 只會為了偵測濫用、維護服務安全以及法規要求的目的短期留存這些內容，而那份暫存可能位於任何國家。
- 這一段跟方案綁在一起，所以把反面也講清楚：免費方案的 Gemini API，Google 會用提示與回應來改進產品，而且人工審閱者可能讀到（Google 說會先切斷與帳號、金鑰、專案的關聯）。我們不打算換到免費方案；如果哪天換了，這一頁會先改。
Google Cloud Storage（照片）
- 儲存的照片不經過我們的伺服器上傳：app 跟 Google 的儲存空間直接傳，用的是我們簽發、只對單一檔案有效、且只活 5 到 15 分鐘的臨時網址。那個儲存空間在平台層級被設定成永遠不可能公開——就算有人設錯權限，Google 也會拒絕。
- 我們的伺服器另外使用 Google IAM Credentials（簽發上述網址）與 Google Secret Manager（讀取我們自己的密鑰）。兩者都不帶你的飲食紀錄或照片；簽發的網址路徑中含有不透明的帳號 ID。
我們自己的伺服器
- 飲食紀錄與帳號資料存在我們自己的資料庫。除了上面列出的 Google 服務，以及用於登入的 Google Sign-In，沒有其他第三方會收到任何東西。
存多久與刪除
- 沒有任何自動刪除，也沒有任何自動保留。你的資料存在，直到你把它刪掉。沒有排程工作、沒有生命週期規則、沒有「保留 90 天」這種東西。
- 刪掉一餐。那一餐的照片會先從雲端刪除，接著它的紀錄列被刪掉。照片沒有復原期——「軟刪除」已經關閉，版本控制也沒有開，所以刪掉就是刪掉。有一件事會留下來：一筆刪除紀錄，內容是「某一餐在某個時間被刪除了」——沒有菜名、沒有數字、沒有照片。它存在的理由是你的其他裝置要靠它才知道那一餐已經不在了，否則下次同步又會把它長回來。這筆紀錄會在你刪除整個帳號時一起消失。另外，如果同一道菜你在別餐也吃過，那道菜的名稱與營養數字會留著，因為還有一餐正在用它。
- 刪掉整個帳號。在 app 的「帳號」頁面就可以做。順序是刻意的：先把你在雲端的照片全部刪光，全部成功之後才刪帳號。如果有任何一張刪不掉，整個動作就停下來、什麼都不刪，並且告訴你資料都還在。因為一旦帳號沒了，那些照片就再也沒有任何東西指得到它們。帳號刪掉之後，伺服器上跟你有關的每一張表都會跟著清空：登入工作階段、使用量紀錄、飲食紀錄、菜色、估算、刪除紀錄。同一時間，這支手機上的本機日記、照片檔案，以及這個 app 寫進健康連結（Health Connect）的營養紀錄也會被刪掉。這個動作無法復原，而且我們也沒有能力幫你復原。
- 沒有 app 時。你也可以用你登入 Dietosaur 的那個 Google 帳號寄信請求刪除，我們會在 7 天內完成並回信告知，見 dietosaur.coyotech.app/delete-account。
- 登入狀態。登入憑證最多 30 天，其中短期憑證只有 15 分鐘。按下登出的當下，伺服器端的憑證就立刻失效，不是等它自己過期。
伺服器端資料存放在哪裡
所有伺服器端資料（資料庫與照片）都位於 Google Cloud 的 us-central1（美國愛荷華州）。也就是說，你的飲食紀錄與照片會傳輸到台灣以外並儲存在美國。這是成本上的取捨而不是偏好：這個服務目前跑在 Google 的免費額度機器上，而那個規格只存在於美國的幾個區域。使用這個 app 即表示你同意這項國際傳輸。如果這對你不可接受，這個 app 不適合你，我們寧可你現在就知道。
我們怎麼保護這些資料
- 所有連線都是 HTTPS，憑證自動更新。
- 登入憑證在伺服器上只存雜湊值（SHA-256），不存原文——就算整個資料庫外流，也無法拿去重放登入。
- 所有密鑰存在 Google Secret Manager，不在程式碼裡、不在映像檔裡、不在機器的中繼資料裡。
- 照片儲存空間關閉物件層級 ACL、強制禁止公開存取，每一次讀取都是一個只對單一檔案有效、幾分鐘就失效的簽章網址。
- 伺服器沒有任何私鑰檔案：簽發網址是透過 Google 的 IAM 服務以機器自己的身分簽的。
- 機器的 SSH 只能透過 Google 的 IAP 通道進入，對網際網路完全關閉。
- 正式版 app 不會把任何東西寫進手機的系統日誌。
- 手機上的登入憑證放在 Android Keystore 加密的儲存區，且排除在雲端備份與換機轉移之外。
我們做不到的事，一起寫在這裡。這個服務跑在一台機器上，資料庫沒有備份，也沒有任何東西在監看它是否活著。設計上你的手機才是資料的正本、伺服器只是副本，所以這不會讓你失去日記——但如果那台機器壞掉，伺服器上的那一份可能就沒了，而你手機上的那一份還在。我們寧可把這件事寫出來，也不想寫「我們採用業界標準的安全措施」這種沒有內容的句子。
Dietosaur 網站本身
它的頁面是純靜態網頁：沒有 cookie、沒有分析、沒有第三方元件，也不會在你的瀏覽器裡留下任何東西。
你的權利、兒童、資訊安全、國際傳輸與政策變更見兩個 app 共通章節。
兩個 app 共通
以下章節同時適用於 dresspec 與 Dietosaur。
國際傳輸
- dresspec：其後端、PostgreSQL 資料庫與照片儲存都在 Google Cloud us-central1（美國愛荷華州），因此你的資料會傳輸到美國並存放在美國；並如其章節所述把資料傳給 Google Gemini API，Gemini 的呼叫可能由任何國家處理。舊版 app 使用的 Supabase 專案（印度孟買）已於 2026-10-07 刪除。
- Dietosaur：所有伺服器端資料（資料庫與照片）存在 Google Cloud us-central1（美國愛荷華州）；對 Google Gemini API 的呼叫可能由任何國家處理。見 Dietosaur 章節。
資訊安全
登入由 Google Sign-In（兩個 app）與 Sign in with Apple（dresspec，iOS）處理；我們拿到已驗證的身分資訊，但拿不到你的密碼。我們為 Dietosaur 實際採取的具體安全措施列在其章節。dresspec 的資料存放在我們控管的 Google Cloud（us-central1 的虛擬機與 Cloud Storage）。
你的權利
兩個 app 你都享有以下權利；依中華民國《個人資料保護法》第 3 條，這些權利不得預先拋棄。
- 查詢／取得複製：要求我們提供與你帳號相關的所有資料副本。
- 更正：隨時在 app 內直接編輯你的資料（dresspec：個人資料／衣櫃；Dietosaur：每一餐的估算），或請我們處理。
- 請求停止處理：請求停止蒐集、處理或利用你的資料。app 內沒有對應的開關；我們會依你的請求處理，例如刪除帳號。
- 刪除：在 app 內或聯絡我們刪除你的帳號與所有相關資料。刪除後若有任何保留，會寫在各 app 的保留章節（dresspec 的使用 telemetry 會在不連結你帳號的情況下保留，快照、log 與 RevenueCat 的紀錄可能依其保留章節所述而殘留）。
行使以上權利請寄信到 support@coyotech.app。查詢或複製請求我們會在 15 日內回應（必要時可延長 15 日並通知你）；更正、停止處理與刪除請求會在 30 日內回應。Dietosaur 以 email 請求刪除帳號會在 7 天內完成。
兒童
兩個 app 都不針對 13 歲以下兒童設計。若發現有兒童註冊，請聯絡我們，我們會刪除該帳號。
政策變更
有重大變更時，我們會在同一個網址貼出新版本，並更新「最後更新」日期。
本網站
coyotech.app 與 Two Designs 的網站 fortune.coyotech.app（免費人類圖測驗與 app 介紹）是由 Cloudflare 提供的靜態網站。網頁使用 Google Analytics 4（評估 ID G-J64LWY5QSX），讓我們了解網站的造訪情況。這只涵蓋網站，不涵蓋各 app。在 fortune.coyotech.app 上，Google 收到的網址不含「#」之後的部分（測驗結果的連結把圖放在那裡），也從不包含你輸入的出生資料；在完整報告頁只收到頁面路徑，不含付款完成返回時 Portaly 附加的付款資訊；配對邀請頁沒有 Google Analytics。你在測驗輸入的出生資料如何處理，以及在該網站購買完整報告時訂單保存哪些資料，見 Two Designs 隱私權政策；該購買適用 Two Designs 服務條款。
- 收集什麼：你瀏覽的頁面與從哪個網站連過來、大略位置（國家與城市，由 Google 依你的 IP 位址推算），以及裝置類型、作業系統、瀏覽器與螢幕大小。
- 怎麼收集：Google 的 script 會在你的瀏覽器設定第一方 cookie（
_ga、_ga_*），用來區分不同次造訪。 - 為什麼：了解有多少人造訪、看了哪些頁面。不會連結到你在任何 app 的帳號，也不用於廣告。
- Google：Google 如何處理這些資料見Google 如何使用採用 Google 服務的網站或應用程式所提供的資訊。你可以用瀏覽器的追蹤或 cookie 設定封鎖，或安裝 Google Analytics 不透露資訊瀏覽器外掛程式。
聯絡
Leo Lin（Coyotech）· support@coyotech.app · 最後更新：2026-10-24