Privacy and Security

Privacy-First Design

weNow is built with a privacy-first approach. The app requires no user accounts, collects no analytics, uses no advertising identifiers, sets no cookies, and includes no crash reporting or telemetry. The goal is to provide accurate weather data while collecting the absolute minimum amount of information necessary to operate the service.

Data Collected

Data Purpose Storage
Location (coordinates) Fetch weather data for your area Local device only. Sent per-request to the backend but never stored on the server.
SHA-256 hashed IP address Rate limiting Server-side, automatically deleted after 7 days. The original IP address is unrecoverable from the hash.
Feedback messages User-submitted feedback Server-side, fully anonymous (no identifying information attached).
RevenueCat subscription ID Subscription management Server-side, anonymous identifier not linked to personal information.

Data NOT Collected

Self-Served Ads

Non-premium users see a single ad card at the bottom of the main weather screen. The entire ad system is first-party and built to avoid the privacy pitfalls of traditional mobile advertising:

Concern Traditional ad SDKs (AdMob, Meta) weNow self-served
Third-party native SDKYes (heavy)No
IDFA / GAID accessYes (requires consent)No
Cookies or local storageYesNo
Cross-site trackingYesNo
Consent banner (GDPR / ePrivacy)RequiredNot required
User profilingYesNo
Data sold to third partiesOftenNever

Ads are stored in the ads table in D1 (title, body, image URL, click URL, kind, weight, active, impression/click counters). Serving is a single endpoint: GET /api/ads returns one weighted-random active ad and increments the impression counter. Clicks are reported via POST /api/ads/click with just the ad id — no user identifier, no session, no cookie. Impression and click counters are aggregate-only; the schema has no foreign keys to any user table and no way to reconstruct which user saw a given ad.

See the dedicated Self-Served Ads doc for the full model, inventory management, and comparison to ad networks.

Security Measures

Rate Limiting

To prevent abuse and ensure fair usage, the backend enforces per-IP rate limits using SHA-256 hashed IP addresses (GDPR compliant -- original IPs are never stored):

Endpoint Limit
App weather requests (/api/weather) 5 requests per day (currently elevated for development)
Widget weather requests (/api/weather/widget) 100 requests per day
Geocoding (/api/geocode, /api/geocode/reverse) 200 requests per day (shared)
Ads fetch (/api/ads) 200 requests per day (click endpoint is unrestricted)
Accuracy report (/api/accuracy) 20 requests per day
Feedback (/api/feedback) 5 requests per day
Account creation (/api/auth/register) 10 requests per day
Login (/api/auth/login) 30 requests per day
Device registration (/api/users) 10 requests per day

Rate limit records are automatically cleaned up after 7 days.

GDPR Compliance

weNow satisfies GDPR requirements primarily through minimal data collection by design:

Third-Party Data Sharing

During each weather request, your geographic coordinates are sent to the following third-party weather providers to retrieve forecast data:

For subscription management:

Each provider receives coordinates only for the duration of the API call. No other personal data is shared with third parties.

User Rights

Under GDPR and similar regulations, you have the following rights:

Since weNow collects minimal anonymous data, most of these rights are satisfied by design. There is very little data to access, export, or delete.

Contact

For privacy-related questions or data requests, contact us at: support@wenow.name

For the full legal privacy policy, see the Privacy Policy page.