The proposed service separates operational job IDs from account records, while recognising that ordinary GPU processing does not keep plaintext secret from the hardware owner.
Random job and device IDs can limit identity sharing between customers and providers. IdleGPU still needs account mappings, operational records and payout identity.
Inputs can identify their subject even without a name field. Only authorised public, non-sensitive data belongs in the initial pilot.
The intended service keeps customer and provider identities out of each other’s operational view. That means pseudonymous job and device IDs—not a promise that people, machines or data are completely anonymous.
These are proposed controls for the future pilot. The current website does not submit workloads, and the local backend uses test accounts and fixtures. Encryption, identity separation and production isolation have not been deployed or independently assessed.
Planned: workers receive a random job ID and only the approved processing payload. Customer names, emails, payment details and billing records stay in the control plane.
Text itself can reveal identity. Customers must remove personal and confidential information; random IDs do not anonymise its contents.
Planned: customer views use an opaque worker ID and relevant capability information, without a provider’s name, home address or direct endpoint.
IdleGPU still needs private device/account records and verified payout details. Hosting and network services may observe connection metadata.
Planned: scoped, short-lived access to one job’s inputs and outputs; encrypted transport; protected platform storage; no payment data in a worker payload.
During ordinary GPU processing, the host may access plaintext in memory or storage. Transport encryption cannot prevent this.
The pilot will accept fixed, reviewed models and bounded data—not arbitrary code, interactive remote access or unrestricted rentals. Worker enrolment, signed software/model manifests, least-privilege execution, timeouts and resource limits are planned prerequisites.
Outbound polling avoids opening a public inbound worker service. Containers help limit execution but do not eliminate hardware-owner or software-supply-chain risk.
The local scheduler already rejects expired attempts and protects simulated accounting against duplicate completion. Production AI validation still needs measured tolerances, malformed-output rejection and sampled trusted recomputation.
Agreement between workers alone is insufficient: workers can collude, and legitimate outputs can vary numerically.
| Participant | Intended access |
|---|---|
| Customer | Own job inputs, outputs, status and billing; provider alias and capability summary. |
| Provider worker / host | Assigned processing payload, output and opaque job ID. Host may inspect execution data. |
| IdleGPU authorised operators | Account/device mappings and necessary operational records, subject to reviewed access controls. |
| Payment provider | Required payment or payout identity. No payment integration is currently active. |
Proposed pilot policy: delete platform workload inputs and outputs within seven days, or sooner under the pilot agreement. Limit operational logging and omit payloads from logs. Financial-record retention must be confirmed professionally. A host’s deletion cannot be guaranteed once it has received plaintext.
Before launch, define incident ownership, token revocation, assignment suspension, evidence handling and notification procedures. These are readiness requirements, not claims of current certification.
Initial scope: authorised public data only. No end-to-end secrecy from GPU owners, complete anonymity, confidential-computing certification or enterprise compliance claim.