Know what stays local, and what you choose to send.

Browser-only tools

The acquisition brief stays in your browser until you choose to send an email. Choosing the email button opens a draft in your email application; you review and send it yourself.

Factory-screen paste mode reads the supplier name and business-scope wording in your browser. It does not send those fields to Currawong or an official registry.

The free checker does keep anonymous daily counters. There are four groups of them.

• That the tool was loaded, that the paste reading was run, that a live lookup was started and whether it returned a record.
• When it did not, which of six fixed failure categories applied (no record, unavailable, blocked, error, network, or offline before it was sent). Also whether what you typed took the shape of an 18-character code, a Chinese name or a Latin-script name, three fixed shape counters that never carry the text itself.
• Once a lookup has returned a record or reported none, which one of five fixed next steps you took first (carrying the record on to the report builder, opening another free tool, opening a guide page, running another lookup, or leaving without any of these). Recorded once per lookup, and never with the page address or the link text.
• Only if you choose to answer the optional sourcing question, a product area and an order-value range picked from fixed lists.

They are stored as one count per day per item. There is no timestamp for an individual use, no IP address, not even a hashed one, no free-text field, and no link to your lookup, your order or you. Because of that structure the counts cannot be traced back to a visit, and cannot be used to contact you. The company name you type into the live lookup is sent to our server to run that lookup, and is not written into these counters. The report builder keeps counters of the same kind: that someone began selecting checks, that they moved on to the order review page, and that an order was submitted. Those three carry no supplier name, no email address, no amount and no record of which checks were chosen.

The report menu page has six separate daily counters. They cover a price label coming into view and links to the specimen, sources section and report terms being opened. The other two record the Advanced menu opening and a valid draft being saved before order review. Each counts at most once per page load; reloading can count again. They carry no link address, company name, selected checks, amount or identifier. A link click does not show that you read the page, and a review draft is not a payment. These totals cannot connect your actions into an individual journey.

Arrival sources. We use campaign parameters in a link, or the browser's referrer when available, to pick a fixed channel such as Google search, Reddit or LinkedIn. Direct visits and missing sources stay unknown. We do not keep the external referrer URL or extract search terms. A search referrer is a clue, not proof that a visit was unpaid or made by a person.

The first source, accepted campaign fields and entry path stay in session storage for this tab. They are cleared when the tab closes. We strip the query and fragment from the entry path. If you submit an order, that source record is sent with it and kept as order metadata. It contains no visitor ID.

Separate daily counters group that source and entry into fixed categories. They count arrival, tool use, price view, order review, submit attempt and buying-brief submit attempt. Sources have four groups; entries have eight public-page groups plus other. Each stage counts at most once per page load; reloading can count again. These counters contain no IP address, supplier details, free text, visitor ID or exact event time. They cannot connect one person's actions. Submitting a form does not prove an order was paid or a buying brief was accepted.

Counters of the same shape sit elsewhere on the site, and none of them carries anything you typed. The code checker keeps nine. Three cover the check itself: that the page ran, that a code was checked, and whether it passed. One records whether you typed the code yourself rather than opening a link that already had one in it. Two cover sharing: that you copied the result, and that you arrived through such a link. Two record which of the two links out of the checker you followed. One is for people who do not have a code yet. The other carries a checked code on to the free registry lookup. Without them we cannot tell someone who left from someone who moved on to the right tool. One records that you scrolled as far as the section on what a passing code does not prove. The code itself never leaves your browser: the check is arithmetic done on your own machine, and only the outcome is counted, not the value. The language switcher keeps one: that someone used it. It does not record which language was chosen. The verification request form keeps two: that at least one check was ticked, and that the submit button was pressed. Each is recorded once. Neither carries a supplier name, an email address, or any record of which checks were ticked. The four-party payment check keeps three: that a comparison was run, whether its outcome was a hold, and that the result text was copied. The copied text itself carries only counts and the tool address. It never carries the names you typed. Finally, one counter records that a price block scrolled into view, so we can tell "read the price and left" apart from "never reached it". It does not record which page, or how long you stayed. All of them are daily totals with no IP address and no timestamp for an individual event, exactly like the counters above.

Every comparison or reading tool on this site, the paste reader, the code checker, the certificate matching worksheet and anything like them — follows the same rule: what you paste or type stays in your browser unless the control is explicitly labelled as a live lookup or a submission.

Verification requests

When you press the submit button on the company-check form, the application sends a fixed set of fields to the Currawong verification service. They are the supplier legal name, optional Unified Social Credit Code and optional supplier website. The rest is product, selected public-record checks and, only if you choose to fill it in, an email address.

That email address is a delivery channel, not an account. It is used to send you a receipt, to tell you when the check is finished, and to reach you if you lose the private link. Submitting it does not create an account, does not subscribe you to anything and is not used for marketing. It is stored on that one request record. So it is tied to that request and to no wider profile, and the public status page never returns it. The China-side desk can access it, and the delivery and payment providers described below may receive it for their stated tasks. Leave the field empty and the request stays anonymous, with the private link as the only way back to it. A paid order carries the same optional address on the same terms.

The service stores the request and its later status or result so I can process it and your private link can retrieve it. A salted, short-window hash derived from the request source is used to enforce submission limits. The application does not write the raw source address into its verification tables.

Sourcing briefs (the buying desk). The structured brief at /sourcing/request/ sends exactly the fields shown on that form to Currawong for manual review. Those are company, contact, an optional WhatsApp or LinkedIn handle, destination country and city or postcode, product details and your declarations. It is stored under a random brief reference. Resend handles the receipt to you and the notice to our desk. These emails include the brief reference, company, destination, product and quantity, and any contact handle you supplied. The desk notice also includes your name and email, product link, declared risk flags and budget range. The brief is not added to a lead or marketing system. The step deliberately collects no street address and no payment information. A brief containing a card-like number is rejected rather than stored. Our policy requires briefs that do not proceed to a quote to be deleted or anonymised during manual review. There is no automatic cleanup job for these briefs. The verification workflow and the buying desk keep separate records. Neither populates the other.

Private result links

Your access secret stays after the # character in the private result URL. Browsers do not send that fragment as part of the page request. The application sends the secret only in a status API request after the page loads, and the database stores a one-way hash rather than the raw secret.

Optional live company lookup

Paste mode remains local. If the separately labelled live lookup is configured and you choose to use it, the company keyword is sent to the same-origin Currawong API. That API may query the configured commercial company-data provider. If no provider account is configured, the lookup fails visibly. It does not fabricate or silently substitute a result.

Retention, access and deletion requests

Our retention policy requires deletion of a paid report body 30 days after delivery. The scheduled cleanup attempts to delete the stored object, then clears the report body and its access pointer from the order record. If object deletion fails, the report becomes inaccessible through the order, but the object may remain in storage while a recorded cleanup retry is pending. Loss of access does not by itself prove deletion. Order metadata, including what was ordered and when it was paid and delivered, remains after report cleanup.

Two shorter windows sit inside that period. A private view session lasts 30 minutes and can be reopened with your link, and the link itself works for 7 days after delivery. After that a person reopens it on request. The retention period can never be configured below 8 days, so the deletion job cannot remove a report you are still entitled to read. An invalid setting falls back to the 30-day default rather than deleting early.

An email address you chose to supply, and likewise an optional supplier contact handle (a WhatsApp or WeChat ID), is not on that 30-day timer. Either sits on the request or order record itself, and no scheduled job clears it. The separate 24-month contact-retention policy below applies to it. The handle refers to your supplier, not to you. It cannot be searched against any registry, is used only for the researcher’s cross-check, and the public status page never returns it. Ask and we clear the address while leaving the request readable through your private link, or delete the record outright if you would rather have neither. We would rather say that plainly than let you assume a sweep exists that does not. Two caps now sit over that. Our policy requires a contact address or handle to be deleted 24 months after your last order, or sooner if you ask. The accounting record of a paid order is different, and shorter is not an option we have. Under China’s Measures for the Administration of Accounting Archives (Order No. 79, in force 1 January 2016) the fixed retention classes are 10 and 30 years, counted from the first day after the accounting year ends, and the schedule sets floors, never ceilings. Accounting records follow those legal retention periods. The 24-month contact policy does not promise that every personal detail in a required accounting record is erased at that point.

Requests submitted without an order follow the same principle in the other direction: send only the minimum supplier information the check needs. Do not submit passwords, bank credentials, government IDs or unrelated personal information at any point.

To ask what application data is associated with a request, request correction or deletion where applicable, or report a private-link exposure, email hello@currawongweb.com with the request ID. Do not include the private result secret in ordinary email unless specifically required to verify access.

Contacting the desk on WhatsApp

The WhatsApp link on this site is a redirect. It sends your browser to WhatsApp and stores nothing on our side: no cookie, no identifier, no record that you clicked it.

If you then send a message, that conversation is carried by WhatsApp and processed by Meta Platforms under their terms and privacy policy, not ours. We see the message together with whatever display name and phone number WhatsApp shows us. We do not import those contacts anywhere, and we do not add you to any list.

Email stays available for anything you would rather not route through a third-party messenger. On either channel, do not send passwords, payment credentials or personal data unrelated to the check.

Payment and email providers

When you pay, the payment itself happens on the processor's side. That is PayPal for PayPal and the on-page card fields (when that payment route is enabled), Shopify for Shopify secure checkout, or Stripe when card checkout is enabled. Your card number, account login and bank details go to the processor, never to Currawong. Every processor receives the order ID, amount and currency needed to reconcile the payment. PayPal and Stripe may also receive the supplier name in the payment description and use the billing descriptor CURRAWONGWEB. Shopify receives the report product or generic report line, the internal order ID, the applicable terms version and, only if you supplied one, your email address. The supplier name and private report subject details remain in Currawong's order record. We do not send any processor your browsing activity on this site. Each processor handles the data it receives under its own privacy policy.

If you leave an email on an order, the order confirmation, payment receipt and report-ready notices are delivered through Resend, an email delivery service. Each such email carries your address, the order ID, the supplier name you entered, the amount and your private order link. Resend processes it as our delivery provider. We do not use it to build any marketing list.

Site measurement

This site loads Google Analytics 4 with analytics_storage, ad_storage, ad_user_data and ad_personalization set to denied. The tag still sends page-view measurements to Google. Denied analytics storage prevents the tag from reading or writing first-party analytics cookies; it does not stop all measurement requests.

Google says these cookieless pings can include a timestamp, browser information, referrer, consent state and a random number made for each page load. Page URLs and campaign parameters may also be sent. We use this measurement for page-view and channel totals. We cannot promise that no identifier is sent or that Google can never connect visits. See Google's consent-mode documentation, checked 9 September 2026.

These Google requests are separate from the application daily counters described in section 01. Cloudflare Web Analytics, when enabled at the edge, is also a separate service. The limits stated for our daily counters do not describe either provider's full data processing.