Sushinet

Ruleproof — Privacy Policy

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

This policy covers Ruleproof, the Shopify app built and operated by Edwin Guo (ABN 20 938 499 163), a sole trader in New South Wales, Australia, trading as Sushinet ("we", "us").

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

Summary — the short version

Which app this policy covers, and where the others are

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 (monitor mode), checkouts in progress (to show a blocking rule is working), and customer tags. See §1. Two things: an order reference plus, where the order had one, a customer id, in the monitor log (§1.2); and Shopify's checkout token, against the rule that matched it and against each checkout we scanned (§1.8). No name, email, phone or address in either.

One app per policy. An earlier version of this document was written to cover every app we publish, adding each as a row in the table above. That is no longer how we do it: each app now has its own policy and its own DPA, scoped to that app alone, because two apps that read different data and keep it for different reasons cannot honestly share one set of clauses — and a merchant should never have to read another product's data flows to find their own.

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 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.

Until September 2026 this section said the monitor log was the only place Ruleproof stored anything tied to an individual customer. That stopped being true when checkout-match records (and later checkout scan records) were added, and it is corrected here rather than quietly left standing: see §1.8, which holds Shopify's identifier for a checkout and no other detail about the shopper. read_orders covers both, and is requested for no other reason.

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 each tag change via the customers/update webhook, and on a periodic backfill sweep that repairs anything the webhook missed. 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 Product tags, collections and SKUs, resolved when a rule is published (no personal data)

For a rule like "hide economy shipping when anything tagged perishable is in the cart", Ruleproof resolves that tag to the set of products carrying it at the moment the merchant publishes, using read_products, and writes that product list into the rule the checkout Function runs. The Function itself never reads tags — it is asked only "is one of these products in the cart", which it can answer without any lookup.

The same happens for a rule that names a SKU: publishing resolves it to the matching product variants and the Function is asked about those instead.

Per shop, this stores: the tag, collection or SKU, the list of matching product or variant ids, and when it was resolved. This is catalog data, not personal data — it describes the merchant's own products and says nothing about any shopper. It is refreshed on each products/update webhook and by a periodic repair sweep, and it is deleted along with everything else when the app is uninstalled (§10).

As in §1.3, this is a point-in-time copy: a product tagged after publishing is not covered until the snapshot refreshes or the merchant republishes. The merchant's admin shows how old the snapshot is, for the same reason — staleness a merchant cannot see is worse than staleness they can.

1.8 Checkout-match and checkout scan records — "every checkout is scanned, and this rule really did stop one" (checkout-linked)

A rule that blocks a checkout prevents the order, so orders/create never fires and the monitor log in §1.2 stays empty however well the rule is working. The merchant reads a zero and reasonably concludes the app is doing nothing. Shopify cannot close that gap — checkout Functions are pure and cannot report anything, and there is no API that returns a validation function's result — so Ruleproof subscribes to checkouts/update and re-evaluates the shop's live blocking rules against the checkout itself. Every checkout is also recorded once as scanned, with a one-word verdict — clean (every live rule looked and none acted), a rule acted, or could not be checked yet — so the merchant can see that checkouts are being scanned even when no rule needed to act. This covers all live rules, including those that only hide a shipping option or a payment method.

What arrives and what is kept are different things, and the difference is the point of this section.

The webhook body is order-shaped, and it can carry the shopper's name, email, phone and their shipping and billing address. To evaluate the rules, Ruleproof reads a fixed set of fields from it into memory: the shipping and billing country, province, postcode, city and street address; the cart total and currency; the line items; the customer's id, email and tags; the shipping methods offered and the payment gateways available.

Two honest notes about that list. It is read for every checkout, not only the fields a merchant's particular rules happen to ask about — the same conversion runs whatever the rules are. And it includes the street address and email even when no rule looks at them. None of it is kept: the rules are evaluated and the values are discarded when the request ends.

What is written to the database is one match row per checkout per rule that matched or could not be evaluated, and one scan row per checkout, holding:

No name, no email, no phone, no address, and no order id are stored.

The checkout token is the honest caveat, and we would rather name it than describe this data as anonymous. On its own it identifies nobody and cannot be turned into a person by us — but it is a handle on one shopper's checkout session on that shop, and Shopify can resolve it. We therefore treat it as personal data.

It is used for one thing: showing "this rule matched 12 checkouts" beside a rule, and "214 checkouts scanned" and the scan log, in the merchant's own admin. Retention is in §7, deletion in §10 — including two limits we would rather name than have you discover: one on customer-level erasure, which follows from storing no customer id, and one on the 30-day window, which depends on the shop still taking checkouts.

1.9 Support conversations (your messages to us)

If you open a request from the app's Support page, the subject and message you write, your shop's name and its contact email are sent to Zoho Desk (Zoho's Australian data centre), the help desk where we answer every support request — the same place an email to support@sushinet.fyi already lands. Each request is its own conversation there. The app keeps one reference per request (the SupportRequest table: its category, and when it was opened, last written to and closed) so you can see your requests and reply to them. It holds no subject and no message text — the subject you write is stored in Zoho Desk, not in the app. Erasing your shop's data (§10) removes those references, so a reinstall starts with an empty list; it does not delete the conversations in Zoho Desk, which are our correspondence with you: we keep them for as long as we need them to support you, and you can ask us to delete them.

Please do not paste your customers' details into a support message. Zoho Desk holds our correspondence with you, not your customers' data, so it is not a sub-processor of it — and it stays that way only if a message carries none.

1.10 What we do not collect

Ruleproof does not read or store 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.

Product and collection data is read only as described in §1.7, and only to build the rules the merchant configured. Ruleproof stores no product field beyond the ids needed to match a cart — no titles, prices, inventory, descriptions or images.

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.

Where we are your processor, a contract governs it — not just this notice. Our Data Processing Agreement sets out the Article 28 terms: that we act only on your instructions, who our sub-processors are and how you are told before one changes, how we help you answer a data-subject request, that we tell you about a breach within 72 hours, and what happens to your data when you uninstall. It is in force automatically for every merchant with an App installed — you do not need to sign anything. If your compliance process needs a countersigned copy, your own template, or the Standard Contractual Clauses as a separate instrument, email support@sushinet.fyi and we will do it.

A privacy policy is a notice; a DPA is a contract. They do different jobs, which is why there are two documents and why Shopify asks for both.

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 Ruleproof — 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 Ruleproof 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, and the object storage holding the daily backups (§7). 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.
Zoho Desk (Australia) Our help desk: support email and the in-app Support page's conversations land here. What you write to us, and your shop's name and contact email (§1.9). Not your customers' data — please keep it out of support messages.
Sentry (USA) Tells us when the app throws an error, so a fault is found by us rather than reported by you. The error itself — message, stack trace, and which shop it happened on. Your customers' data is deliberately kept out: request bodies, headers, cookies and query strings are discarded before anything is sent, and any email address or phone number appearing anywhere in an error is replaced with [email redacted] / [phone redacted] first. That last step matters because a rule can legitimately contain a shopper's email, so a failing rule could otherwise carry one into an error message.

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 Ruleproof's 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
read_products Show the products/collections a merchant picked in a rule by name, power the product picker, and resolve a tag or collection to the products in it when a rule is published (§1.7)
read_shipping Read the store's own shipping option NAMES, so the rule builder can offer them instead of asking the merchant to type from memory

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. read_products and read_shipping read the merchant's catalog and shipping configuration — store data, not personal data; neither touches any information about a shopper.

Protected Customer Data (PCD) access was granted on 15 August 2026. Both webhooks that depend on it are now active:

A third webhook, products/update, keeps the product-tag snapshot in §1.7 current. It is not Protected Customer Data — a product is not a person — and was never gated behind this approval.

The PCD request covers only the specific customer fields the rules, the monitor log and the checkout-match and scan checks actually read (email, phone, address — deliberately not name, which no condition reads) rather than broader access, consistent with the minimum-necessary scope policy above. Adding the checkouts/update topic did not widen that set: it reads the same address and customer fields the approval already names, and unlike the monitor log it stores none of them.

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.