Sushinet

Sushinet — Privacy Policy

Last updated: 2026-07-30 · Effective: 2026-07-30

This policy covers the Shopify apps built and operated by Edwin Guo (ABN 20 938 499 163), a sole trader in New South Wales, Australia, trading as Sushinet ("we", "us"). We refer to them together as "the Apps".

Published at https://sushinet.fyi/ruleproof/privacy. It is hosted separately from the Apps themselves, deliberately: you should be able to read what we do with your data even at a moment when an app is down.

Summary — the short version

Which apps this policy covers

App What it does What it can read What it stores about shoppers
Ruleproof Checkout rules — hide, rename or reorder shipping options, hide payment methods, and block checkout on conditions such as postcode, cart total, weight or customer tag. Orders (for monitor mode) and customer tags. See §1. An order reference and, where the order had one, a customer id — in the monitor log only.

When we release another app, it is added to this table with its own row, and any handling that differs from the rest of this policy is stated in its row rather than in a separate document.

1. What data we collect, and why

1.1 Rule definitions (no personal data)

When a merchant builds a rule ("hide standard shipping if the cart is under $50"), the rule's JSON definition, name, and enabled/paused state are stored against the merchant's shop domain. This is merchant-authored configuration, not personal data about anyone — it never contains a customer's name, email, address, or order details.

1.2 Monitor log — "what a rule would have done" (order- and customer-linked)

Shopify checkout Functions cannot make network calls or read a clock, so they cannot log anything themselves. To show a merchant "this rule would have blocked 12 checkouts last week" before a rule goes live, Ruleproof re-evaluates the merchant's rules against each completed order via the orders/create webhook, and records only the outcomes that say something (a rule matched, or a rule's condition couldn't be evaluated from the order data — e.g. a product-tag condition, since order webhooks don't carry product tags or collection membership). Plain non-matches are not recorded.

Each stored entry holds: the shop, which rule matched, the order id and order name/number, the rule's state at the time, the match outcome, whether the rule's action would have blocked the checkout, a one-sentence human-readable summary of what happened, the customer id (if the order had one), and a timestamp.

This is the only place Ruleproof stores anything tied to an individual customer, and the only reason read_orders is requested. It is used solely to render the "activity"/monitor view inside the merchant's own admin — it is not used for any other purpose, and Ruleproof does not build customer profiles from it.

This monitor-mode webhook subscription requires Shopify's Protected Customer Data approval (it touches order fields that can include customer name, email, phone, and address) and is currently gated on that approval — see §14.

1.3 Customer tags, copied into an app-owned metafield (for "block checkout unless tagged X" rules)

A checkout Function can check a customer's tags (hasTags), but only against a list baked into its static configuration at deploy time — it cannot query Shopify's API live during checkout. To support a rule like "block checkout except for customers tagged wholesale", Ruleproof reads a customer's tags from Shopify (read_customers) and copies them into a metafield in its own private namespace ($app:ruleproof, key flags) on that customer record (write_customers). The Function then reads that metafield at checkout time. Nothing else is read from or written to a customer record — no name, email, address, or order history is copied anywhere by this sync.

This is a point-in-time copy, not a live read: it is refreshed on a backfill sweep and (once customers/update webhook access is approved — see §14) on each tag change. Because of this, there is a bounded window where a customer's live tags and the copy Ruleproof's Function reads can briefly disagree; the merchant's admin surfaces when each shop was last synced so this is visible rather than hidden.

1.4 Shop-level settings

Per shop, Ruleproof stores: the emergency kill-switch state, the store's cached currency code (so money-based conditions compare in the right currency) and when it was last checked, the Shopify customization/validation Function ids Ruleproof created (so it can find and update them rather than create duplicates), the last publish failure message (if any), and the customer-sync status described in §1.3 (timestamp, count, last error). None of this is customer-identifying.

1.5 OAuth session data

Standard Shopify app session data required to authenticate API calls to the merchant's store: access token, granted scope, session/user id, and (for online sessions) the authenticating staff user's first name, last name, email, locale, and account-owner/collaborator flags, as supplied by Shopify during OAuth. This is store-operator data, not storefront-customer data, and is used only to make authorized Admin API calls back to that same store.

1.6 Order-volume counters and auto-pause records

Ruleproof stores one row per shop per day counting how many orders it saw, used only as the denominator for anomaly detection (comparing a rule's match rate against normal order volume). If a rule's match/block rate spikes abnormally, Ruleproof can automatically pause it and records that decision (which rule, when, the observed versus expected rate, and the merchant-facing explanation shown at the time) so a merchant can see it was the app, not a person, that paused it. Neither table contains customer-identifying data.

1.7 What we do not collect

Ruleproof does not read or store product data, collections, discount codes, marketing consent, payment card details, or any storefront analytics/tracking data. It does not use cookies or pixels on the merchant's storefront — all data handling happens server-side, via Shopify's Admin API and webhooks, and inside the merchant's own admin.

2. Who is in charge of what — our role

In short: for your shoppers' data you are in charge and we act on your instructions. For your own account and settings, we are.

Under the GDPR and equivalent laws, two different roles apply depending on whose data it is:

Practically, this means: if one of your shoppers asks to see or delete their data, the request belongs to you and we will help you answer it (§11). If you ask us about your own account data, we answer it directly.

3. Why we are allowed to process it

In short: mostly because we need it to give you the app you installed.

Where the GDPR or UK GDPR applies, we rely on:

What Legal basis
Running the Apps you installed — storing rules, evaluating them, syncing tags, keeping you signed in Performance of a contract (Art 6(1)(b))
The monitor log, anomaly detection and auto-pause, security logging, diagnosing a fault you report Legitimate interests (Art 6(1)(f)) — keeping the service correct and safe, balanced against the very limited data involved and its short retention
Keeping billing and tax records Legal obligation (Art 6(1)(c))
Any optional email we might send you about the Apps Consent (Art 6(1)(a)), which you can withdraw at any time

Where we act as your processor (§2), our basis is your instruction; the legal basis toward the shopper is yours to hold as the controller.

4. Where data lives

Ruleproof's data is held in a single database on a dedicated virtual server we operate in Sydney, Australia, isolated from any other system we run. Access to that server is restricted to the operator using key-based authentication only, and data is encrypted in transit (HTTPS) between Shopify, the app, and a merchant's browser.

If you are in the EEA or the UK: your store's data is stored in Australia. Australia is not covered by a European Commission adequacy decision, so where the GDPR applies, transfers rely on the appropriate safeguards in Article 46 or the derogations in Article 49. Ask us and we will tell you exactly what we hold for your store.

5. Who we share data with, and who we rely on

We do not sell merchant or customer data, we do not share it for anyone else's purposes, and there is no advertising network, data broker, marketing tool, ad pixel or third-party analytics SDK anywhere in the app. No store data passes through any such service.

We do rely on a small number of providers to run the app at all. Under the GDPR these are sub-processors — they hold or transmit data on our instructions and for no other purpose — and naming them is more useful to a merchant than a blanket claim that nobody else is involved:

Provider What it does for us What it can hold
Shopify The platform the app runs on. Rules are stored in Shopify metafields and enforced by Shopify's own checkout Functions. Everything in §1 — Shopify is the source of the data and the place rules actually run.
Oracle Cloud (Sydney, Australia) The virtual server running the app's admin interface and database. The rules, the monitor log, shop settings and the OAuth session described in §1.
Vercel (USA) Hosts our public website sushinet.fyi, including the page you are reading. Ordinary web-server request data for visits to that website. No store, merchant or customer data reaches Vercel — the app does not run there.

Our website also uses Vercel Web Analytics and Speed Insights to count visits and measure page speed. Both are cookieless, collect no personal information, and apply only to sushinet.fyi — never to a merchant's storefront and never to the app's admin pages.

We will update this list before adding any provider that would hold store data. If a legal request such as a court order ever compelled disclosure, we would tell the affected merchant unless the law prohibited us from doing so.

6. Sending data overseas

In short: your data sits in Australia, and we tell you plainly what that means.

We are an Australian business and the Apps' database is in Australia. The providers in §5 mean personal information is also likely to be disclosed to recipients in the United States (Vercel; Shopify) and Canada (Shopify). Under Australian Privacy Principle 8 we remain accountable for what those recipients do with it.

If you or your customers are in the EEA or the UK, be aware that Australia is not the subject of a European Commission adequacy decision. Transfers to us therefore rely on the appropriate safeguards in Article 46 — in practice the European Commission's Standard Contractual Clauses, which we will enter into with any merchant who asks — or, where relevant, the derogations in Article 49. We would rather state this plainly than let "your data is stored in Australia" read as if it settled the question, because it is the fact that raises it.

7. How long we keep data

8. Rules that block or restrict a checkout

In short: yes — blocking a checkout is the whole point of some rules. Here is what that means for a shopper, and how a person can review it.

The Apps apply rules a merchant configures and can, as a result, hide a shipping option, hide a payment method, or stop a checkout from completing. Those decisions are made automatically, at checkout, by Shopify running the merchant's rules.

Three things are worth being precise about:

We disclose this because Shopify's protected-customer-data requirements ask apps to be explicit about automated decisions with a significant effect, and because Australian Privacy Principle 1.8 requires it from 10 December 2026 — including where a program refuses to make a decision, which is precisely what a blocking rule does.

9. How we protect it, and what happens if that fails

In short: a small, locked-down setup, and we tell you quickly if it goes wrong.

No system is perfectly secure, and we will not pretend otherwise. If a data breach affects your store, we will tell you without undue delay — and in any event within 72 hours of becoming aware of it — with what happened, what data was involved and what we are doing about it. Where the Australian Notifiable Data Breaches scheme or GDPR Article 33 applies, we will also notify the relevant regulator within the time they require.

10. Deletion — mandatory Shopify compliance webhooks

Ruleproof implements the three webhook topics Shopify requires of every App Store app, regardless of whether it collects personal data:

All three verify the webhook's HMAC signature before acting (Shopify requires this; an invalid signature is rejected with a 401 and no data is touched).

Uninstalling the app also triggers shop/redact deletion as above. A merchant who wants their monitor-log or rule data removed sooner than that, or a merchant relaying a request from a customer, can contact us directly (§7).

11. Your rights, and how to use them

In short: ask us, and we will answer within 30 days, free.

If you are a merchant, you can ask us to give you a copy of what we hold about you, correct it, delete it, restrict or object to how we use it, or provide it in a portable form. Just email support@sushinet.fyi. We will respond within 30 days. There is no charge, unless a request is clearly unfounded, repetitive or excessive — in which case we will tell you why before doing anything.

If you are a shopper who bought (or tried to buy) from a store using one of our Apps: the store is the controller of your data, so please send your request to them. Shopify passes their deletion requests to us automatically (§10), and we act on them. If the store asks us to help identify what we hold, we will.

If you are unhappy with how we handled it, please tell us first — we would rather fix it. If that does not resolve it, you can complain to:

California and other US state residents: you have the right to know what personal information is collected, to have it deleted, to correct it, and not to be discriminated against for asking. We have not sold or shared personal information for any business or commercial purpose, and we have never done so. We do not process sensitive personal information.

12. Children's data

The Apps are business tools sold to merchants, and are not directed at children. We do not knowingly collect personal information from anyone under 16. If we learn that we hold information about a child, we will delete it. If you believe we have, please tell us at support@sushinet.fyi.

13. Cookies

In short: a session cookie inside the app's admin, and nothing on your storefront.

14. Access scopes, and Protected Customer Data status

Ruleproof requests the minimum scopes each feature needs:

Scope Used for
write_validations Activate the checkout-blocking Function
write_delivery_customizations Activate the shipping hide/rename/reorder Function
write_payment_customizations Activate the payment-method hide Function
read_orders Monitor mode: re-evaluate rules against completed orders (§1.2)
read_customers Read a customer's tags, to copy into the metafield in §1.3
write_customers Write that one app-owned metafield (namespace $app:ruleproof) back onto the customer

write_customers reads as broader than what Ruleproof actually does with it: the app writes exactly one metafield, in its own namespace, and touches nothing else on the customer record.

Two features are currently gated behind Shopify's Protected Customer Data (PCD) approval, which has been requested but not yet granted as of this writing:

We requested PCD access only for the specific customer fields the monitor log actually reads (name, email, phone, address) rather than broader access, consistent with the minimum-necessary scope policy above.

15. Changes to this policy

If what Ruleproof collects or how long it's retained changes — for example, when Protected Customer Data approval is granted and the features in §6 become fully active — this document will be updated and the "Last updated" date above will change accordingly.

16. Contact

Questions about this policy, or a request to access or delete data we hold, can be sent to:

support@sushinet.fyi

This policy is published at https://sushinet.fyi/ruleproof/privacy, which is the URL given on the Shopify App Store listing. It is deliberately hosted separately from the app itself: a merchant or a reviewer must be able to read what we do with their data even at a moment when the app is down.