Privacy

StareGlare collects what it needs to deliver bug reports from people who use an app to the developer who makes it, and nothing else. No ads, no trackers on reports or the dashboard, and nothing is sold.

StareGlare is run by Gjorge Karakabakov. Questions or requests: hello@stareglare.com.

Two kinds of people use StareGlare

• Developers sign up, add their apps, and read and answer reports.
• Reporters send a report through a developer's StareGlare page, web widget or app. They don't need an account.

When you send a report, it goes to the developer of that app, and they decide what happens with it (in privacy-law terms they're the controller and StareGlare processes the report on their behalf, under the Data Processing Agreement). To get a copy of your reports, or to have them changed or deleted, ask the developer — replying to their email works — or email me and I'll pass it on. Developers have a tool that finds everything sent from an email address, exports it and deletes it. If the developer had the report posted to another service (see “Tools a developer connects”), that copy is theirs to remove there.

Why StareGlare is allowed to use this data

European and UK law ask for a reason for each use of personal data. These are StareGlare's.

• A developer's email address and workspace, sign-in links, notifications, invites and the plan a workspace is on: needed to provide the service they signed up for (contract).
• A one-way hash of your IP address, and of an email address a sign-in link, confirmation or invite is sent to, kept for up to a day: to stop spam and abuse of report forms and sign-in (a legitimate interest in keeping the service usable and safe).
• Server and error logs, and errors on StareGlare's own pages: to find and fix faults (a legitimate interest in running a reliable service).
• Website addresses a developer asks StareGlare to audit, and the results: needed to provide the service they signed up for (contract).
• Visit counts on three public pages, without cookies: to know whether those pages are read (a legitimate interest; nothing is stored on your device).
• Reports, messages and files from reporters, and errors an app sends on its own: delivered to the developer of that app, who decides why they're collected and is responsible for the reason. StareGlare acts on the developer's instructions.

Where the reason is a legitimate interest you can object, and I'll stop unless there's a compelling reason to continue.

What a report contains

• What you type: the summary and details, and your name and email if you give them.
• Files you attach, such as screenshots.
• Technical details, listed under “What we'll include” before you send: app version, operating system, device model, browser, screen and window size, language and time zone, and the address of the page you came from, without its query string. The web widget also adds the page's title and address (without its query string, unless the site chose to send it in full) and recent console errors from that page, with query strings and anything that looks like a token removed. In console errors and in the logs our Mac and Godot reporters attach, your home folder is replaced with “~”, so file paths don't carry your account name.
• From a Mac app using StareGlare's helper: the end of the app's log files and a snapshot of the app window. These are listed on the form and you can untick them; if you do, they're deleted.
• Messages you send later, by email or on your report's tracking page.

Your IP address is used to limit how many reports, uploads and sign-in emails can be sent in a short time. Only a one-way hash of it is stored, in a counter that's deleted within a day.

Errors an app sends on its own

A developer can switch on automatic error capture for their website or app. It is off unless they do. When it's on and the app hits an error, the app tells StareGlare without anyone filling in a form, and the developer sees it in their dashboard and may get an email about it.

• What is sent: the error message, the technical trace that shows where in the code it happened, the app version, the page address without its query string, and your browser's name and version. A developer's app can add its operating system and a few short labels of its own; what those labels say is up to the developer.
• Query strings, email addresses and anything that looks like a token are removed before the web widget sends an error, and again when StareGlare receives one from any app. The widget sends at most 10 different errors per page load.
• No name, email address or account is attached, and your IP address isn't stored (only the short-lived hash used for rate limits, as above).
• StareGlare keeps one record per distinct error: how often it happened, when it was first and last seen, in which versions, and the details of the most recent time. It doesn't keep a record of each time.

Because these records carry no email address, the tool that finds everything sent from an address doesn't cover them. The developer can delete any error from their dashboard.

Errors on StareGlare's own pages

StareGlare uses the same feature on itself. If a page on stareglare.com hits an error in your browser, the page sends the error message, the trace, the page's path and your browser's name and version to StareGlare, so the fault can be fixed. This covers every page, including report pages, tracking pages and the dashboard. Query strings, the secret part of invite and tracking links, sign-in tokens and email addresses are removed first. The page doesn't read form fields or report content for this, no cookie is set, and the record isn't linked to you or your account. Errors on the server are recorded the same way.

Releases and changelogs

A developer can publish a release: a version number and notes they write, shown on a public changelog page for their app. The reports a release fixes are not shown there. If the developer chooses to tell reporters, everyone who sent one of those reports, or a report marked as a duplicate of one, with an email address gets a message in that report's conversation saying which version fixed it. A developer can also show the changelog on their own website. That page then loads the list of releases from StareGlare: no cookie is set and nothing is stored, and the request appears in the host's standard logs like any other.

Testimonials

A developer can ask a reporter whether a few words from their report may be shown on the app's website. The reporter gets one email with a link (and, if they don't answer, at most one more after three days). Nothing is shown unless the reporter says yes on that page; they choose the name, the title or company and the photo shown with it, and the same link withdraws their yes at any time, which takes the words down at once. Someone who leaves praise in an app's feedback form can tick a box to say yes right away. A photo they add is public, because it is shown next to their words, and is deleted when they remove it or the testimonial is deleted. Testimonials are included when a developer exports or erases a reporter's data.

Website audits

A developer can ask StareGlare to audit a website for search engines and AI answers, once or on a weekly or monthly schedule. A separate audit service, run by StareGlare on Fly.io in Frankfurt, then visits that site's public pages the way a search engine does, and may visit a few public pages of competing sites it finds by searching DuckDuckGo or Bing for the site's topics. It asks Google's PageSpeed Insights for speed measurements of the site's address. It is given the address, an internal reference, and on some plans the workspace's name to print on the report. It never receives reports, messages, files or captured errors.

An audit's results quote short pieces of the public pages it read, such as titles and headings. The results and the finished report (a web page and a PDF) are kept until the developer deletes the audit; deleting it removes them from StareGlare's database and from the audit service. The audit's site address and date stay, so the month's allowance is counted correctly. When a whole workspace is deleted, its audit reports are removed from the audit service too; if that service is asleep at that moment, StareGlare keeps asking until it confirms.

What StareGlare keeps about developers

• Your email address, used to sign in with a one-time link or with Google. Signing in with Google shares your name and email address with StareGlare; only the email is used.
• Your workspace: apps and their settings, reports, replies, internal notes, labels, saved replies, captured errors, releases, website audits and their schedules.
• API tokens, stored only as a one-way hash.
• An activity log for the workspace's owners: who invited or removed a member, changed a role, created or revoked a token, connected a tracker or an integration, created or deleted an app, deleted reports, published a release, or exported or erased a reporter's data, and when the plan changed, with the email address of whoever did it. No report content, and not the reporter's address. It is kept for a year; when someone deletes their account their address is taken out of it.

Email

StareGlare sends sign-in links, report confirmations, replies and notifications, including notices to a workspace about a new error or a website audit whose score dropped. Reply-to addresses contain a random code so your answer lands in the right conversation. Email that reaches StareGlare without matching a report is forwarded to my own inbox, hosted by Google (Gmail), so it isn't lost. Alerts about server errors go to the same inbox; they contain the address of the page that failed and a technical trace. Email you send to hello@stareglare.com is passed to that inbox by ImprovMX, a forwarding service.

AI assistants

Developers can connect an AI assistant, such as Claude, to their workspace through StareGlare's MCP server, for example to help fix a bug. Report content the assistant reads is then sent to that AI provider under the developer's own account and the provider's terms. StareGlare itself doesn't send reports to AI providers.

Tools a developer connects

Developers on some plans can have new reports and replies posted to their own Discord or Slack channel or to a web address they run, and can turn a report into a GitHub or Linear issue. What is sent is the report: its summary, details and technical details, and the reporter's name and email if the developer chose to include them. It goes to the developer's own account at that service, under that service's terms.

Posting to TikTok

A developer can connect their own TikTok account to schedule videos and have StareGlare publish them at the chosen time. They approve this on tiktok.com, and StareGlare never sees their TikTok password. It asks TikTok for two permissions: user.info.basic, to show which account is connected, and video.publish, to publish the videos the developer scheduled. Nothing is published unless the developer scheduled it, or asked an AI assistant they connected to schedule it.

• What StareGlare gets from TikTok: the account's ID, username, display name and profile picture, who the account may post to, the longest video it may post, and the status of each post.
• What StareGlare keeps: that information, the access tokens (encrypted), and for each video the file, caption, audience, comment, duet and stitch settings, content disclosure settings and schedule.
• What goes to TikTok: the video and those settings, when it is time to publish, to the developer's own account and under TikTok's terms and privacy policy.
• How it is used: only to show the developer their account and to publish and track their videos. It isn't sold, used for advertising, or shared with anyone else, apart from the hosting providers listed below.
• Removing it: disconnecting in the dashboard deletes the tokens and asks TikTok to revoke them; access can also be removed in TikTok's own settings. The video history stays until the developer deletes it. Deleting a video in StareGlare removes StareGlare's copy only; a video already published stays on TikTok until it is deleted there. Deleting the workspace or account removes everything StareGlare holds.

Posting to Instagram

A developer can connect their own Instagram professional account (Business or Creator) to post the same videos as Reels, at the same time or on their own. They approve this on Instagram's own login page, and StareGlare never sees their Instagram password. StareGlare asks for two permissions, instagram_business_basic and instagram_business_content_publish, which it uses to show which account is connected and to publish the videos the developer scheduled. It reads no comments, messages or insights. Nothing is published unless the developer scheduled it, or asked an AI assistant they connected to schedule it.

• What StareGlare gets from Meta: an access token for the shared account, the account's ID, username, name, profile picture and account type, and for each post its status, its ID and its link on Instagram.
• What StareGlare keeps: that information, the access token (encrypted), and for each video the file, caption, whether it also shows in the profile grid, and schedule.
• What goes to Meta: the caption and a private link to the video that expires within hours, which Instagram uses to fetch the video when it is time to publish, to the developer's own account and under Meta's terms and privacy policy.
• How it is used: only to show the developer their account and to publish and track their videos. It isn't sold, used for advertising, or shared with anyone else, apart from the hosting providers listed below.
• Removing it: disconnecting in the dashboard deletes the token; access can also be removed in Instagram's settings (Apps and websites). The video history stays until the developer deletes it. Deleting a video in StareGlare removes StareGlare's copy only; a Reel already published stays on Instagram until it is deleted there. Deleting the workspace or account removes everything StareGlare holds. To ask for deletion by email, write to hello@stareglare.com.

Posting to YouTube

A developer can connect their own YouTube channel to upload the same videos as Shorts, at the same time or on their own. StareGlare uses the YouTube API Services for this; by connecting, the developer agrees to the YouTube Terms of Service, and Google's Privacy Policy applies. They approve this on Google's own sign-in page, and StareGlare never sees their Google password. StareGlare asks for two permissions, youtube.upload and youtube.readonly, which it uses to upload the videos the developer scheduled and to show which channel is connected. It reads no comments, analytics or other videos. Nothing is uploaded unless the developer scheduled it, or asked an AI assistant they connected to schedule it.

• What StareGlare gets from Google: a refresh token for the channel, the channel's ID, handle, name and picture, and for each upload its video ID.
• What StareGlare keeps: that information, the refresh token (encrypted), and for each video the file, title, caption, who can see it, and schedule.
• What goes to Google: the video file, its title, the caption as its description, and who can see it, to the developer's own channel when it is time to upload.
• How it is used: only to show the developer their channel and to upload and track their videos. See “Google user data” for who it is shared with and “How data is protected” for how it is kept safe.
• Removing it: disconnecting in the dashboard deletes the token; access can also be removed on the Google security settings page. The video history stays until the developer deletes it. Deleting a video in StareGlare removes StareGlare's copy only; a Short already uploaded stays on YouTube until it is deleted there. Deleting the workspace or account removes everything StareGlare holds.

Google user data

“Google user data” here means what StareGlare receives from a developer's Google account when they choose to connect it: their name and email address when they sign in with Google, their Search Console and Google Analytics reports, and their YouTube channel's profile, refresh token and video IDs. StareGlare's use and transfer of information received from Google APIs adheres to the Google API Services User Data Policy, including the Limited Use requirements.

• What it is used for: only to show the developer their own data in their workspace and, for YouTube, to upload the videos they scheduled. It isn't sold, used for advertising, used to train AI models, or used to build profiles of anyone.
• Who can see it: the members of the workspace it was connected to, and an AI assistant only if a member connects one to that workspace and asks it to read the data on their behalf. Nobody else.
• Who it is shared with: no one, except the service providers that store and run StareGlare for me, only as far as they need to do that, under their data processing terms: Fly.io (the database, in Frankfurt), Netlify (the server code, in Frankfurt) and Cloudflare (stored files, such as a video waiting to be uploaded, in the United States). YouTube videos go to Google itself, to the developer's own channel. Google user data is never transferred to anyone else, unless the law requires it, it is needed to protect someone's safety or to investigate abuse, or StareGlare is merged or sold, in which case this policy keeps applying to it and developers are told first.
• People: I don't read it, except with the developer's permission (for example to help with a problem they report), for security, or when the law requires it.
• Deleting it: disconnecting a Google service in the dashboard deletes its token, and deleting the workspace or account deletes all of it. You can also revoke StareGlare on the Google security settings page, or email me to have it deleted.

How data is protected

• In transit: every connection to StareGlare, and from StareGlare to its providers and to Google, TikTok and Meta, is encrypted with HTTPS (TLS).
• Tokens and keys: the access and refresh tokens for Google, TikTok and Instagram, and the keys and webhook addresses of other connected tools, are encrypted in the database with AES-256-GCM. The encryption key is kept apart from the database, so a copy of the database alone doesn't reveal them.
• At rest: the database and stored files sit on encrypted disks at the providers above.
• Access: each workspace's data can only be read by its own members, which StareGlare checks on every request. Files are private and only shown through links that expire. Only I can administer the servers and the database.
• Keeping it small: StareGlare asks Google for the narrowest permissions that do the job (read-only for Search Console and Analytics; uploading and reading the channel's profile for YouTube) and keeps only what is listed above.

Where data is stored

• Fly.io: runs the database and sign-in (PocketBase) in Frankfurt, Germany, and the website audit service, which holds audit reports.
• Cloudflare (R2): stores files, such as report attachments and scheduled videos, in the United States.
• Supabase: held the database until October 2026, in Frankfurt. A read-only copy is kept there until the move is complete, then deleted.
• Netlify: hosts the website and runs the server code in Frankfurt. Like any host it keeps standard request logs for a limited time.
• Resend: sends and receives email, in the United States.
• Google (PageSpeed Insights): receives the address of a website being audited and returns speed measurements.
• Google (Search Console, Analytics): if you connect them, StareGlare reads your site's search data (searches, pages, impressions, clicks, positions) and your Google Analytics reports (visitors, pages, sources, countries, devices) with read-only access. Analytics reports are kept for up to 7 days and refreshed every 10 minutes while you look at them. You can disconnect at any time, which revokes that access.
• Microsoft (Bing Webmaster Tools): if you connect it, StareGlare reads your site's Bing search data (searches, impressions, clicks, positions) with your API key. You can disconnect at any time, and delete the key in Bing Webmaster Tools.
• TikTok: if you connect it, receives the videos you schedule and their settings, and returns your basic profile and each post's status. See “Posting to TikTok”.
• Meta (Instagram): if you connect it, receives the captions and videos you schedule as Reels, and returns your Instagram account's basic profile and each post's status. See “Posting to Instagram”.
• Google (YouTube): if you connect it, receives the videos you schedule as Shorts with their titles and captions, and returns your channel's basic profile and each upload's ID. See “Posting to YouTube”.
• Keywords Everywhere (Open PageRank): receives the domain names of audited websites, of apps' websites and of the competitors you list, and returns how strongly other sites link to each. Nothing else is sent.
• ImprovMX: forwards email sent to hello@stareglare.com to my inbox.
• Google (Gmail): hosts that inbox.
• Polar: handles payments for paid plans as the merchant of record. Card details go to Polar and its payment processor, never to StareGlare; StareGlare only learns the plan, its status and your billing email.
• Google Analytics: counts visits to the public pages. Google processes that data on its own servers, including in the United States. See below.

See “How data is protected” for how this data is kept safe.

Data leaving Europe. The database stays in Frankfurt; stored files are kept with Cloudflare in the United States. Email passes through Resend in the United States, Google processes visit counts and the forwarded mail above there too, and StareGlare itself is run from outside the European Union. Supabase, Netlify, Resend, Fly.io, Cloudflare, Polar, Google, Microsoft and Meta are companies based in the United States, so their staff there may be able to reach data they hold in Europe, and a request to the site passes through whichever of Netlify's network locations is nearest to you on its way to Frankfurt. Those transfers rely on the safeguards in each provider's data processing terms, such as the European Commission's Standard Contractual Clauses. You can ask me for details.

Cookies

The dashboard sets a sign-in cookie so you stay signed in. Asking for a sign-in link sets one for an hour, so the link opens straight away in the browser that asked for it, and signing in with Google sets one for a few minutes to remember which page to return to. If you dismiss the getting-started checklist, a cookie remembers that for a year, picking a light or dark theme sets one that remembers it for a year, and the dashboard keeps a few of your own choices (a dismissed hint, the widget settings you last tried) in your browser's storage. Nothing else sets cookies: not the public pages, report pages, tracking pages or the widget. Google Analytics runs without cookies (see below), and so does error reporting. There's no advertising on any page.

Visitor counts

The home page, this page and the terms count visits with Google Analytics: which of those pages were opened and where visitors came from. It runs with storage switched off, so it sets no cookies, keeps nothing in your browser and can't tell that two visits came from the same person. Google receives your IP address to estimate a rough location and, by its own account, doesn't store it. Advertising features and Google Signals are switched off, and there's no session recording. Page addresses are sent without query strings and invite links are redacted, so sign-in and invite tokens never reach Google. The sign-in page, invite pages, report pages, tracking pages, the widget and the dashboard don't load it at all, and it's switched off as soon as you navigate into them, so nothing in a report ever reaches Google.

How long data is kept

• Reports, messages and files stay until the developer deletes them, the app, or their account.
• Captured errors stay until the developer deletes them, the app, or their account. The count of how often an error happened each day goes back 14 days.
• Website audits and their reports stay until the developer deletes them or their account.
• Scheduled and posted videos (TikTok, Instagram and YouTube) stay until the developer deletes them or their account. A video added but never saved on a post is deleted within about a day.
• A workspace that has had no plan for 90 days, after its trial or subscription ended, has its apps, reports, files, captured errors, releases and website audits deleted. Its members are emailed at least 14 days before.
• A workspace's activity log is kept for a year.
• Files that were uploaded but never sent with a report are deleted within about a day.
• Files a reporter unticked on the form are deleted when the report is sent.
• The hashed IP and email addresses used for rate limits are deleted within a day.
• Developers can delete their account and everything in it under Account in the dashboard. It happens immediately, and also removes their email address from anything left in a workspace they shared. You can also email me.
• Backups and email logs kept by the hosting and email providers expire on those providers' schedules after that.

If something goes wrong

If there's a security incident that affects your data, developers are emailed without undue delay with what happened and what's being done. Developers are responsible for telling their own reporters; I'll give them what they need to do that.

Children

StareGlare isn't meant for children, and developers must be old enough to enter a contract. Apps and games that use StareGlare may be used by younger people; the developer decides whether to collect reports from them and is responsible for doing that lawfully.

Your rights

You can ask for a copy of your data (in a form you can take elsewhere), a correction, or deletion. StareGlare makes no decisions about you by automated means. If you're in the EU or UK you also have the right to object, to restrict processing and to complain to your data protection authority. Email hello@stareglare.com; I answer within 30 days.

Changes

If this page changes in a way that matters, the date at the top changes and developers get an email.