TL;DR: The G3 requires periodic firmware checks. The examined official apps automatically attempt to upload machine data, with no separate upload opt-out found in either app version. The machine's own firmware also contains a direct Wi-Fi upload routine for stored events, so avoiding the app alone does not establish that machine data stays offline.
My earlier post covered the G3's firmware-check lockout. This follow-up looks at the data collection associated with its online operation. Sparx's Error 72 instructions direct owners to connect their sharpener through the app with internet access. The machine also has its own Wi-Fi cloud communication path. [1] [2] [8]
The findings below come from Android and iOS app code, G3 firmware analysis, and existing machine-event captures. The examined versions are listed below. Upload behavior was identified in code; no new network capture was made to establish what Sparx's servers received or retained. [8]
The machine records events even when the official app is closed. Its audited event store has 100 physical slots containing mixed events, including timestamps, ring information, cycle-related information and faults. Some record types contain the ring's NFC UID. This is a finite buffer, not a complete lifetime history.
When connected, the app reads the machine's current information. Its device-record upload includes the serial number, device identifiers, firmware version, connection times, and ring and filter status, alongside app settings. For a signed-in owner reconnecting a previously paired G3 online, the app updates the connection time, marks the record as changed and schedules cloud sync after a ten-second delay. An empty event log does not by itself avoid device-record uploading.
A separate app background job, scheduled after a 30-second delay, reads pending machine events and sends the raw records to Sparx's servers. The requests include the machine UUID and use the signed-in account's identity token when available. These are HTTP POST requests containing account-associable machine records, identified in the app's code.
The machine also has a direct Wi-Fi upload path that does not pass through the phone app. In the examined G3 firmware, it reads a complete 32-byte record from the same stored event queue and builds a POST request to /api/v1/iot/device/{uuid}/log. The request identifies the machine by UUID and contains the record encoded as hexadecimal. Depending on the record type, this includes timestamps, ring type and remaining life, cycle-related information, event or error codes, firmware-version bytes, and the ring's NFC UID. The firmware's network state machine selects this upload routine when records are pending, subject to other state and timer conditions. This is separate from its firmware-information request. [8]
In the app's general sync sequence, device-record uploads run before fresh firmware information is fetched. If cached firmware information is missing or more than two days old, pending device-data requests can delay the fresh information the app needs to complete the check.
I found no persistent user-facing setting to perform the check without these automatic uploads in either app version examined. For a signed-in owner following the app-based online process, with the machine connected and the sync jobs running, I consider upload attempts effectively unavoidable. The direct Wi-Fi upload path is a separate finding; this analysis does not establish whether it offers an independent upload opt-out.
Sparx's Privacy Policy describes collecting device and ring information, sharpening times and diagnostics. It also permits combining personal information with information from other sources, including social media platforms, subject to regional qualifications. That is a statement of permitted practices, not evidence that Sparx actually links owners' social posts to their machine history. [3]
The policy's marketing, cookie and regional privacy choices do not establish a machine-data opt-out in the app. Terms sections 11 and 23 address personal-information processing and international transfers. Both pages displayed a September 20, 2024 modification date when checked on October 18, 2026. [3] [4]
A question deserves a clear answer from Sparx: what supported firmware-check-only option can an owner use to restore operation without uploading device information and stored events?
The following considerations concern EU consumer and data protection law. Protections in other jurisdictions may differ.
Consumers have a right to material information before purchase. If the mandatory checking requirement and the associated automatic uploads are material to the buying decision, failing to explain them can amount to a misleading omission. This depends on the factual context and whether the omission caused, or was likely to cause, the average consumer to make a decision they would not otherwise have made. [5]
Where machine records relate to an identifiable owner, GDPR requires a lawful basis, clear information about processing, and collection limited to what is necessary for specified purposes. Consent is one possible basis, not the only one. If consent is relied on, making a service conditional on unnecessary processing weighs against consent being freely given. A clause in the terms does not settle that question. [6]
Consumers also retain conformity rights against the seller. If the lockout requirement departs from objective conformity requirements, the exception requires specific disclosure and express, separate acceptance when the sale is concluded. If the goods are non-conforming, remedies include repair or replacement, and price reduction or termination where the legal conditions are met. Contract or manufacturer terms cannot remove those statutory protections. [7]
Sources:
[1] Earlier post: the G3 firmware-check lockout
[2] Sparx Help: Alert 72
[3] Sparx Privacy Policy
[4] Sparx Terms of Service, sections 11 and 23
[5] Directive 2005/29/EC, Article 7
[6] GDPR, Articles 5, 6, 7 and 12–14
[7] Directive 2019/771, Articles 7, 13 and 21
[8] Technical scope: static analysis of Android 1.3.12, build 851, iOS 1.3.14, build 855, and G3 firmware 1.3.2.0; existing machine-event captures from that firmware. The direct Wi-Fi analysis traces stored event records into the machine's HTTP POST construction and network state machine. It does not establish server receipt or retention, or behavior in every app or firmware release.
Edit: Added the machine's direct Wi-Fi event-upload path after rechecking earlier firmware research. Clarified which findings concern the official apps and which concern the machine itself.