Privacy notice · Prototype

Privacy should be as visible as consent.

This notice describes what the current repository does and the controls a production Cloudfunding service must publish before launch.

Effective: 14 July 2026Version 0.1Prototype scope

1. Scope and status

This notice covers the static Cloudfunding website in this repository, the local Electron desktop prototype, the project-application preview, and the intended Cloudfunding funding service described across this site and repository.

No production controller identified

This repository does not identify a deployed legal entity, production data controller, operational privacy contact, or public Cloudfunding service. Those details, lawful bases, vendor list, transfer safeguards, and jurisdiction-specific rights process must be published before production collection begins.

Statements about future controls are design requirements, not claims that those systems are currently deployed or independently audited.

2. Website data

Static pages

The local website files do not include analytics, advertising pixels, session replay, account cookies, or a custom tracking script. The pages request fonts from Google Fonts when loaded with network access; the request may disclose ordinary connection information such as an IP address and browser headers to Google under its own terms.

External links

Following a link to GitHub, Google Fonts or another external service moves you into that service’s privacy environment. Cloudfunding does not control those services.

3. Desktop app data

The desktop prototype stores a small JSON preference file in the Electron user-data directory. It contains the selected project identifier and whether sharing should resume after launch. The app also relies on local storage used by the bandwidth-sharing service for consent status, node identity, and request counts.

The renderer receives only the Cloudfunding state needed for the interface: sharing state, consent state, selected project, status message, and aggregate request counts. It does not receive arbitrary filesystem or operating-system access.

Project preferences

In the current prototype, the selected project is stored locally. It is not transmitted to a Cloudfunding allocation backend because that backend is not implemented here.

4. Sharing provider

When a user affirmatively starts sharing, the bandwidth-sharing service initializes a session using the configured integration key. The service operates the sharing network and may process network, node, request, consent, and operational information required to provide that service.

A production release must link the applicable provider privacy information directly in the consent flow, document the controller or processor roles, list relevant data categories and retention, and explain any international processing.

Stopping sharing calls the SDK opt-out operation and updates the local Cloudfunding preference. Quitting the process also ends the running local application.

5. Project applications

The application page asks for organization name, project title and area, location, website, project summary, expected impact, funding target, timeline, funding use, contact name, email, and referral source.

In this local repository, submitting the form does not transmit the fields; it displays a message explaining that the local page is a visual preview. A separate Lovable deployment may connect to Supabase, but its production URL, controller, hosting region, access policy, and retention are not defined by this local page.

Before a live application form is used, applicants must receive the operational controller identity, purposes and lawful bases, required versus optional fields, reviewers and processors, retention periods, transfer information, rights route, and consequences of not providing required information.

6. Disclosure, security, and retention

Disclosure

The prototype does not contain a Cloudfunding server that sells personal information or publishes device-level records. Production disclosures should be limited to service providers, authorized reviewers, legal obligations, incident response, and project-payment operations as documented in a vendor register.

Security

The desktop uses context isolation, disables Node integration in the renderer, exposes a narrow IPC bridge, and applies a content security policy. These controls reduce risk but do not amount to a security warranty. See the security page.

Retention

Local preferences persist until removed through application data cleanup or operating-system controls. Production retention schedules for applications, accounting, consent evidence, security logs, and project records are not yet established and must be defined before launch.

7. Rights, choices, and launch requirements

Current desktop choices include not starting sharing, stopping sharing, changing the local project preference, reviewing sharing consent settings, quitting the app, and removing local application data using operating-system mechanisms.

A production service must provide a private contact route for access, correction, deletion, restriction, objection, portability where applicable, consent withdrawal, and complaints. It must also identify the relevant supervisory authority or dispute route for the operator’s jurisdiction.

Required before production

Controller identity and address; privacy contact; lawful bases; vendor and subprocessor list; provider role analysis; international-transfer safeguards; retention schedule; rights workflow; incident notification process; child-safety position; application-data notice; and versioned change history.