sunwardBack to the little universe
THE PEOPLE BEHIND THE PAPER

Your memories deserve care.

Sunward turns the details you choose to share into a birthday surprise. This page explains what is stored, who can access it, and how you stay in control.

Who makes what

Dinesh created and maintains Sunward. The person uploading photographs and answering the ten questions creates the individual birthday surprise. The recipient does not answer the questionnaire and does not need an account to open a working recipient link.

What we collect, and why

  • Names, photographs, questionnaire answers, and your message make up the personalized birthday story. A sender name is optional. Your message is displayed as plain text. The answers help assemble the story’s language, artwork, and rhythm.
  • Expiry settings determine how long access is available. An optional birthday date is converted to an expiry in your browser; only the resulting expiry is stored. The exact expiry date is shown before publication.
  • Story and upload identifiers, creation and modification times, photo sizes, a generation seed, and a generation version allow the service to save, reopen, edit, and consistently render stories; control storage; and clean up unused files.
  • Security information includes secure verifiers for management credentials and optional passwords, access status, rate-limit records, and necessary authentication data. The application uses a hashed network address for abuse rate limits, rather than putting your address in the creator’s statistics.
  • Operational records include approximate open totals, cleanup state, and a minimal record of administrative actions. Hosting and storage providers may also process network addresses and request metadata to operate and secure their services.

Routine application logs and analytics must exclude uploaded content, complete private URLs, passwords, and management tokens. Avoid putting personal information in support email subject lines or filenames.

A link is a way in

A recipient link contains a random identifier, rather than the person’s name or questionnaire answers. Anyone who has an unprotected recipient link can open the story while it is active. They can forward the link or save what they see. Posting a birthday link to a social story makes it available to that social story’s audience.

You can add a password for another access check. Recipients do not need an account; they enter that password to unlock the story. Send it separately from the link when possible. A password does not prevent an authorized recipient from sharing a password, screenshot, or downloaded copy.

The creator receives a separate secret management credential. It permits editing and deleting the story; the recipient link does not. Keep the management credential private and save it somewhere secure. Sunward stores a verifier, not the original management secret, and cannot show you the original again if you lose it.

Private storage and access

Photos are stored in private object storage. The application checks the story’s access status, expiry, and any required password before serving a photo through an authorized route. Story responses and private photos are not intended for shared public caches. Fresh photo and story requests stop working when access expires or is revoked; a photo already loaded onto a device may remain visible there.

Private pages use generic social previews and indexing restrictions so a preview does not intentionally expose a birthday name, photo, or message. Crawler instructions are advisory, not access controls. A crawler blocked by robots.txt might never see a page’s noindex instruction. Secrecy should depend on the link and optional password, not search-engine behavior.

Who can access the data

The creator and people given valid recipient access can view the story. Hosting, datastore, and private storage providers process the data needed to deliver and secure Sunward. Authorized administration can manage records and investigate a support, safety, or deletion request. Dashboard summaries show operational metadata by default, rather than personal photos and messages. Any authorized content inspection is an explicit administrative action.

Sunward does not sell uploaded data, use it for targeted advertising, or use it to train AI models. Photos, questionnaire answers, and messages are not sent to an external AI service to generate your story: the story is assembled by Sunward’s own code. These commitments apply to how Sunward operates the service; infrastructure providers process data under their applicable service terms and retention arrangements.

Editing, revocation, and deletion

Use the management controls to change the name, message, answers, photos, or expiry without changing the recipient URL. You can revoke access or request deletion. Deletion blocks new access immediately and queues stored content for physical removal. Revocation is permanent and also makes the stored content eligible for removal by the same cleanup process.

Choose seven days, thirty days, or a custom expiry. If you supply a birthday date, you can choose thirty days after that date. Expiry is enforced on access requests even if physical cleanup has not run. The scheduled cleanup process targets a daily run and retries unfinished deletions; outages and provider delays can extend physical removal. See Retention & Deletion for the distinction between access ending and stored copies being removed.

Backups and provider security records may outlast removal from active storage, depending on the configured provider’s retention. Sunward cannot retract screenshots, downloaded cards, previously loaded photographs, or copies shared by other people. Support email remains in the email provider’s systems under its retention settings.

Cookies and minimal monitoring

Sunward does not add advertising trackers or browser fingerprinting. Necessary cookies can remember a successful story password check for up to twenty-four hours or the story’s remaining lifetime, whichever is shorter. A creator-preview cookie can last up to one hour. These cookies allow viewing; neither grants editing or admin access. Separate authentication cookies secure an authenticated admin session, and the admin authentication provider may use additional cookies needed for sign-in. These are functional security cookies, not advertising cookies.

An approximate “story opened” count is recorded after an intentional recipient interaction, rather than every preview request or preload. Creators see a total, not the viewer’s identity, location, or browsing history. Reloads, retries, privacy tools, and interrupted requests can affect its accuracy. Rate limits and admin audit records exist to protect the service, not to identify birthday guests.

Rate-limit keys use a keyed hash of the network address; the application purges expired rate-limit records after their enforcement window. Minimal admin audit records are retained for ninety days. Contentless records of deleted or expired stories are retained for thirty days after physical cleanup. See Retention & Deletion for more detail.

Cookieless counts and crawler exclusions do not, by themselves, establish compliance with any particular privacy law.

Questions or a deletion request

Contact Dinesh at dineshmadaka007@gmail.com for help, privacy questions, and deletion requests. You can also find Sunward’s creator on Instagram at @dineszz.here (opens a new tab). Please send private requests by email, without including passwords or management credentials.

Include the recipient link and enough context to locate the story. Do not send the management secret or password. Dinesh may need to verify your connection to the content before changing or disclosing it. If you are pictured in a story you did not authorize, explain that in your request.