Privacy

This page says what Sunrose collects and why, who can see it, who runs it, and how long we keep it, when you use our website, account, previews, and review tools.

For privacy questions and requests, contact Sunrose at support@sunrose.dev.

What we collect and why

• Your account. Your verified email address, and the name and profile image supplied by a connected sign-in provider. We use your email to find your workspace. You can set a display name, which your team sees on your notes and status changes. Google and GitHub are optional sign-in providers when connected; email sign-in uses a six-digit code. Existing Cloudflare Access sign-ins remain supported.
• Sign-in security. Sign-in codes are stored as hashes and expire after 5 minutes. We keep authentication sessions, connected provider account identifiers, encrypted provider tokens, and IP address and browser information used for session security and request throttling.
• Teams. Each workspace member’s email, display name and role (owner, editor or viewer), and which workspaces they belong to. When you invite someone we keep their email address, the role offered, the time, and a hash of the invitation secret, and we email them. An invitation closes after 7 days. Your active workspace is remembered in a cookie on sunrose.dev.
• API keys and connected apps. For a key: its name, a short prefix, its permission, when it was made, last used and expires, and a hash of the key; the full key is shown once and never stored. For a connected app: its registration, the person and workspace that authorised it, its permission, and hashes of its codes and tokens.
• Billing. If you buy a plan, Stripe takes the payment. Your card details go straight to Stripe and are never seen or stored by Sunrose. We keep your Stripe customer and subscription identifiers, your plan, billing period and payment status, the dates a payment failed or a plan ended, and a record of the billing emails we sent. Stripe keeps your invoices and payment records under its own policy. If you pay in Bitcoin or Ethereum, NOWPayments processes the payment. We keep the order (plan, interval, price, coin, payment reference and status, and the time), how long you have paid for, and the reminder email we sent. We never hold or see a wallet key; the transaction itself is public on the blockchain.
• Projects and files. Project names, and the files of each site you upload with their paths and sizes. We keep them so previews and downloads work. If you upload images or PDFs, a PDF is kept whole and also drawn out as page pictures in your browser before upload, so no PDF is opened on our servers. Both count against your storage.
• Workspace branding. If you use white-label review pages, the name, accent colour and logo you set, and the label, style and corner of the review button, which are shown to your reviewers.
• Free upload safety checks. Sunrose automatically checks a bounded sample of uploaded HTML on the Free plan for signs of credential phishing, including password fields, form destinations, brand names, and sign-in phrases. We record the decision and the signals found in an audit record. A flagged upload may be held for an operator to review, including when its preview is password-protected. A hold is a request for review, not a finding that the page is harmful.
• Review activity. For each comment: the page, the element or shape it points at, the comment text, and the name and optional email the reviewer typed. Email addresses are shown to your workspace, not to other reviewers. If a comment is edited, reshaped or deleted, we keep its earlier text and position: a deleted comment is hidden, not erased. For a status change on a comment, we record who made it and when.
• Live cursors. When people have the same version open, the Sunrose review panel shares each person’s pointer position, and the name they typed or “Guest N”, with the others in real time through a relay that stores nothing. Your team sees everyone; clients see only other clients. Nothing is sent from touch screens, and anyone can switch cursors off, after which nothing is sent or received.
• Approvals. The approver’s full name, an optional title or company, the receipt code, the time, and the address it was recorded on.
• The human check. When a client reviewer passes the check, we record the time against that review. The check is run by Cloudflare Turnstile, and we do not keep the check token.
• Preview passwords. If you put a password on a preview address, Sunrose keeps only a salted hash of it, never the password itself. A visitor who enters it gets a signed cookie that lasts 12 hours. To slow down password guessing, Sunrose counts wrong guesses against a keyed hash of the visitor’s IP address that changes every day. The raw IP address is not stored in these password-attempt records, and those counts are deleted after an hour.
• Requests for a new review link. If a review link has expired or been turned off, the reviewer can ask for a new one from the page that tells them so. We keep the request, with the time and, if they typed them, a name, an email address and a note. It is tied to the review link they held, and shown to your workspace.
• Notification emails. When a client leaves a comment, a client approves a version, or someone asks for a new review link, Sunrose emails the sign-in address of the workspace owner so they can act on it. The email says what happened and links to the project. It does not include the reviewer’s email address. Internal notes never send email.
• Anonymous counts. Sunrose keeps a count per day of how many sites were published, review links made, comments left, approvals recorded and link requests made. Each count is one number for the whole service. No account, project, reviewer, IP address, or device identifier is recorded in these counts. They are stored with our infrastructure provider.
• Abuse reports. The page address, the reason, and any details or contact email the reporter gives. Abuse reports do not store raw IP addresses.
• Report counting. A report keeps a keyed hash of the reporter’s network address that changes each UTC day. An hourly cleanup clears hashes older than 7 days. The raw network address is not stored with reports or report counts. Two distinct hashes in a 24-hour window trigger a hold on a Free project until an operator reviews it; this distinguishes network addresses, not verified people.
• Audit records. What changed in your workspace, such as a project created or a review link turned off, with the time and the IDs involved.
• Operational logs. One line per change request, with a request reference, the method, the path with IDs masked, the status and the time. Opening a review link records the address and the review session ID, never the link secret. Cookies and request bodies are not logged. Our application logging is designed to redact review-link secrets. Infrastructure providers may separately process network and security logs.

Who can see it

• Your workspace. Only the members of your workspace can see your projects, versions, review links, comments and approvals. A viewer can read but not change them.
• Preview visitors. Anyone with a preview address can view the site unless you set a password. A review link bypasses that password. No public directory and noindex headers do not restrict access.
• Reviewers. Someone with a client link sees the site, the project name, the approval once it is recorded, and only the comments made through that link. People who share one link share its comments. They also see the pointers of others on that link, as “Guest N” or a typed name.
• Team links. A team link also shows internal notes and every comment on that version. It acts as the member who made it, and only that member can open it. Share it only with your own staff.
• Sunrose staff. The people who run Sunrose can read the database when they act on a report or a support request. Database snapshots include reviewer names and comments.
• Safety reviews. Operators can read uploaded files, including files behind a preview password, to review an upload or abuse report. Free previews outside a review session carry a “Hosted on Sunrose · Report this page” banner. Its report link includes the page address without its query string or fragment.
• Search engines. There is no public list of projects, workspaces or reviews. Preview addresses send a noindex header, and robots.txt asks crawlers to stay out. An owner on a paid plan can allow search engines for one project; then that project’s public pages are open to them, and a search engine may keep copies of what it lists after the setting is turned off. Review links, password pages and password-protected sites are never opened to search engines.

Service providers

Sunrose runs on Cloudflare. Cloudflare provides:

• Workers, which run the Sunrose console and the preview servers, and Durable Objects, which relay live cursors without storing them.
• D1, the database for accounts, projects, comments, approvals and audit records.
• R2, file storage for uploaded site files.
• Access, retained for the legacy app sign-in. Customer sign-in sessions are stored in Sunrose’s D1 database.
• Turnstile, the human check on the report form and for client reviewers. The visitor’s IP address goes to Cloudflare for that check.
• Email Service, which sends sign-in codes and the notification emails described above.
• Cloudflare for SaaS, which issues the certificate and routing for custom addresses on a client’s domain.

Card payments are handled by Stripe, who process cards and send receipts. Bitcoin and Ethereum payments are handled by NOWPayments, a separate company with its own privacy policy. Stripe is a separate company with its own privacy policy. Stripe operates globally and may transfer payment-related personal data to other countries, including the United States and India. We do not promise that Stripe billing data stays in Australia. Stripe retains information according to its legal obligations and the purposes described in its policy.

We do not add advertising trackers or third-party audience analytics. Our service providers process information needed to deliver and secure their services. Customer emails use sunrose.dev sender addresses; replies to support are forwarded to the operator’s support inbox. Uploaded sites may include their own scripts, forms, cookies, or external services, controlled by the uploader rather than Sunrose.

Where information is processed

Cloudflare operates a global network. Sunrose does not currently guarantee Australian-only storage or processing for its database, uploaded files, email, or operational data. Google and GitHub process information under their own privacy policies when you choose those sign-in options. Stripe’s international processing is described above. We may disclose information where required by law, to investigate misuse, or to protect people and the service.

How long we keep things

• Billing records. Our retention policy is to keep invoices, payment and refund records, and the related billing audit records for at least five years after the later of the transaction or the completion of the records for that transaction. We may keep them longer where a legal obligation or unresolved dispute requires it. Account or project deletion does not remove records we need for these purposes. Stripe applies its own retention obligations to the records it holds. Automatic deletion of Sunrose billing records is not currently implemented; records retained beyond the policy period require manual review.
• Versions. Each upload is kept as its own version and is never changed. Versions stay until you delete the project. The pricing page lists each plan’s version allowance. Automatic removal of older versions is currently disabled; approved versions and versions with comments or active review links are protected from routine cleanup.
• Approved versions. Routine version cleanup protects approved versions and their approvals. You can remove them by deleting the project and confirming that choice. Removal may also be necessary to comply with law or address prohibited content.
• Comments. Kept with their version. Turning off a review link does not delete them. A comment a reviewer deletes is hidden but kept, with its earlier edits, until its project is deleted.
• Unfinished uploads. An hourly job removes them once their upload window has passed and a further hour of grace has gone by.
• Review links. A client link stops working after 30 days without a visit by default (each visit renews it), or when you turn it off. A team link must be opened within 15 minutes, once, and works for 8 hours after that.
• Free preview expiry. Automatic expiry is currently disabled. When enabled, a Free preview stops serving after 30 days without a new version, comment, approval, new review link, or owner reactivation. Visits alone do not extend it. Expiry keeps the files, comments, and approvals. The owner can choose Reactivate preview or publish a new version to resume serving; a separate safety hold still requires operator review.
• Database restore points. Deleted database records may remain in provider restore points until those restore points expire. Restoring a database may require us to reapply a deletion request.
• Accounts, audit records, abuse reports, and link requests. We retain these while needed to provide your account, investigate abuse, resolve disputes, or meet legal obligations. They do not currently have a uniform automatic deletion period. We review their retention when handling a deletion request and retain only what is reasonably needed. Provider logs follow the provider’s retention settings and policies.

Your choices

• Remove a preview password. Open the project’s Settings view, then choose Remove password. Visitors then reach the preview without it.
• Turn off a review link. On the project page, under Review links, choose Turn off. It stops working straight away, for everyone who holds it.
• Download a version. On the project page, under Versions, choose Download ZIP. You get a ZIP of the files as uploaded, without the review overlay. This works even for a suspended project.
• Delete a project. Open the project’s Settings view, then choose Delete this project. This removes its versions, stored files, comments, review links and addresses. If it has an approval, you must also confirm that the approval record is deleted. It is not possible while a project is suspended.
• Reviewers. A reviewer can edit or delete a comment they made through their link; deleting hides it rather than erasing it. To have a reviewer’s name or email removed from a comment altogether, email support.
• Live cursors. Switch them off from the control in the review panel. The choice is kept in that browser.
• Leave a workspace. Any member can leave a workspace, except its last owner. An owner can remove a member, which also turns off their keys, connected apps and team links.
• Your account. Account deletion is not in the product yet. Email support to ask. We will verify your authority, explain what can be deleted, and identify records that must be retained for legal, billing, security, or dispute-resolution purposes. We do not promise to erase records belonging to another person or business without checking their rights.

Cookies and browser storage

Sunrose uses these cookies and browser storage on preview addresses (on glimpse.page, and on any custom address you connect):

• sr_review (stored as __Host-sr_review on secure connections). Keeps a reviewer signed in to their review link. It is HttpOnly and SameSite=Lax, Secure on HTTPS, and tied to that one address. It lasts until the link expires or is turned off.
• sr_unlock (stored as __Host-sr_unlock on secure connections). Set when a visitor enters the password for a protected preview. It is HttpOnly and SameSite=Lax, Secure on HTTPS, tied to that one address, and lasts 12 hours. Changing or removing the password ends it at once.
• Session storage. The review page keeps the name a reviewer typed, a flag for the human check, and display choices such as whether the panel is open, in their browser’s session storage. It is cleared when the tab closes.
• Local storage. The review page remembers whether live cursors are switched off (sr_cursors) and that the first-time tip has been seen (sr_tip), until the visitor clears their browser data.

On sunrose.dev, the HttpOnly, Secure, SameSite=Lax sign-in cookie is restricted to that host and expires after 7 days unless renewed. OAuth sign-in also uses temporary security cookies, and a cookie remembers your active workspace (__Host-sunrose_workspace on secure connections). These cookies are not shared with uploaded previews, which open on separate domains such as glimpse.page. Google, GitHub, legacy Cloudflare Access, and the human check may set cookies on their own services. We do not add analytics or advertising cookies.

Access, correction, and complaints

Email support@sunrose.dev to request access, correction, or deletion of your personal information, or to make a privacy complaint. Include enough information to locate the relevant account, project, or review; do not send passwords or card details. We may verify your identity and authority before acting. We aim to respond within 30 days and will explain any delay or lawful reason for refusing a request. If you are not satisfied, you may contact the Office of the Australian Information Commissioner where it has jurisdiction, or your local privacy regulator.

Security and children

We use access controls, encrypted connections, and other reasonable security measures, but no online service is risk-free. If a breach occurs, we will investigate and notify affected people and regulators where required by law. Sunrose accounts and paid subscriptions are intended for adults. Do not upload children’s personal information unless you have appropriate authority and safeguards.

Changes to this policy

We may update this policy as the service changes. We will publish the current version here and notify account holders by email of material changes to how we handle their personal information.

Contact

Privacy questions and requests: support@sunrose.dev.