Privacy Policy
Effective 2 August 2026 · Last updated 29 September 2026
The short version
- The Snapline app has no analytics, no telemetry, and no account. Nothing you capture is sent anywhere.
- Screenshots, recordings, recognized text, and translations are created and kept on your Mac, in files you control.
- The optional MCP server is off until you turn it on. While it is on, an AI assistant running on your Mac can receive captures and recognized text from Snapline, within the limits you set. What that assistant does with them, including sending them to its own provider, is governed by its policy, not this one.
- The app connects to the internet for two things on its own: checking whether a new version has been published, and confirming this Mac's seat with our activation endpoint: at activation or trial start, at each launch, once a day while it runs, and alongside update checks.
- The activation call carries your key and a salted SHA-256 hash of this Mac's hardware identifier. The raw identifier never leaves your Mac, and after activation the license verifies locally, offline.
- Buying is the one point where you give us personal details: your email address and the license issued to it.
- If you say yes at checkout to hearing about new releases, you join our release newsletter. It keeps your email address and a few details from Paddle, counts opens of each issue without tying them to you, and every issue has an unsubscribe link.
- This website sets no cookies of its own. It counts its readers twice: with our own counter, which never stores your IP address, and with Cloudflare Web Analytics, our host's cookieless page-load beacon. The three pages that show a price also load Paddle's scripts, which can set a Paddle cookie.
1. Who this policy is from
Snapline is a macOS application made by Ziad Ziadeh, an individual developer, who is the data controller for the small amount of personal data described here. This policy covers the Snapline app, the website at snap-line.app, the purchase flow that issues license keys, and the release newsletter.
For anything in this policy, write to support@snap-line.app.
2. The app: what stays on your Mac
Snapline collects nothing about what you capture or how you use it. There is no analytics SDK, no telemetry, no usage reporting, no crash reporting service, and no account to sign in to. Nothing you capture leaves your computer unless you send it somewhere yourself. What the app does send, for updates and licensing, is set out in section 3.
Everything the app produces is produced and kept locally:
- Screenshots, scrolling captures, recordings, and GIFs are ordinary files on your disk, in the location you choose in Settings.
- Recognized text (OCR) is produced on device by Apple's Vision framework and stored alongside your capture history so that searching works. It is never transmitted.
- Capture Text clips are text you read off the screen with Capture Text. By default each is saved as a small plain-text file in the same location as your screenshots and listed in History; with "Keep text clips in History" turned off, the text only goes to your clipboard and nothing is written. Clips are recognized on device and never transmitted.
- Translations are produced on device using macOS language packs. The packs are downloaded and owned by macOS, not by Snapline: the first translation of a language pairing may raise a system download prompt, which is Apple's, and any resulting network activity is between macOS and Apple.
- Annotations, pins, and history are local application data.
- Your license key is stored locally and checked locally.
Snapline asks for the system permission Screen Recording, which macOS requires before any app can read the contents of the screen. It is what capture is. Snapline asks for microphone access only when you turn on Microphone for a screen recording, and camera access only when you turn on Camera (the floating camera bubble) for a screen recording; that audio and video go into the movie file saved on your Mac and are never uploaded, transmitted, or stored anywhere else by Snapline. System Audio (what your Mac is playing) is captured through the same Screen Recording permission Snapline already has and needs no additional permission. Snapline asks for Input Monitoring only when you turn on Show Keystrokes for a screen recording; the keys you press are drawn directly into the recorded frames on your Mac and are never logged, stored, or transmitted separately, and if you decline, the recording simply proceeds without the keystroke overlay. Microphone, System Audio, Camera, and the input overlays (Highlight Clicks and Show Keystrokes) are all off by default. Snapline does not request Accessibility, Full Disk Access, contacts, or location.
The MCP server, if you turn it on
From version 2.40, Snapline includes a local MCP server that lets an AI assistant on your Mac (Claude Code, Cursor, VS Code, Codex, Antigravity) ask Snapline for captures and the text in them. It is off by default, and updating Snapline does not turn it on. It listens only on 127.0.0.1, which is your own Mac; it is not reachable from your network or the internet, it refuses requests that come from a web page, and it runs only while Snapline is running. Every request must carry an access token that Snapline generates and keeps in your login Keychain.
What an assistant may do is three separate switches. With the server on, it can list, search and read the captures already in your History. Taking new captures, including reading text off the screen, is a second switch, and Snapline asks you to Allow or Deny on the schedule you choose. Writing copies of captures to disk is a third, into one folder you choose. An assistant only ever receives the flattened image, so anything you redacted stays redacted; the unredacted original kept for re-editing is never offered.
Snapline itself still sends none of this anywhere: the data goes from Snapline to the program you connected, on your Mac. What that program does next is outside Snapline's control and outside this policy. AI assistants generally send what they receive to their provider's servers to be processed, so a capture you let an assistant take is, in practice, shared with that provider under that provider's terms. The name an assistant shows in Snapline's prompt is the name it gave itself, which Snapline cannot verify. Turn the server off, press Forget, or regenerate the token in Settings → MCP to withdraw access at any time.
3. The app: when it uses the network
Snapline uses the network for updates and licensing, including activation, status refreshes, trial leases, deactivation, and seat resets. Capture contents are not included in these requests.
Update checks
The app uses Sparkle to check for new versions: it fetches an update feed and, if you choose to install an update, downloads the update archive. On versions newer than 2.7.0, both requests go to our own domain, snap-line.app, served by Cloudflare, so Cloudflare receives your IP address and the request headers your system sends (as for the website, section 4), and GitHub, where the release files are stored, is contacted by our server rather than by your Mac. Versions 2.7.0 and earlier instead talk to GitHub directly (the feed from raw.githubusercontent.com and downloads from github.com), so on those versions GitHub receives your IP address and request headers until the install has updated once. Snapline does not attach a system profile, a unique identifier, or your license details to these requests, and receives no report about them itself.
These checks run automatically in the background, and the honest caveat is that the app has no switch to stop them today: a Mac kept offline, or an outbound firewall rule, is currently the only way to prevent them. If that matters to you, say so and it becomes a setting.
Licensing requests and stored records
- Activation and status refreshes. Activation sends the license key, a salted SHA-256 hash identifying this Mac, and a random request nonce. Status refreshes send that hash and nonce with the key or a signed receipt; trial requests do not need a purchased key. The raw hardware identifier is not sent. The hash is a persistent pseudonymous identifier used for seats and trials, not capture analytics.
- When refreshes run. The app attempts a refresh at launch, daily while running, and during update checks. A paid receipt continues to work when the service cannot be reached; an explicit revocation or deactivation can change its status. Trials need connectivity to renew a lease, valid for at most three days and never beyond the trial end.
- A trial record also keeps a country. When a trial starts, we store the two-letter country code Cloudflare had already worked out from the connection before our code ran, so we can count which countries Snapline is being tried in, and nothing finer. Your Mac does not send it and is never told it. The IP address it was derived from is not stored, no region or city is kept, and the code sits beside the trial's start date under the same machine hash, which is not linked to your purchase or to anything you did in the app.
- Trial and seat records keep the day of the last check-in. Each time a trial or a licensed Mac checks in (the requests described above: at launch, once a day while it runs, and alongside update checks), the record for that machine hash stores the date of that check-in, never the time, and how many different days it has checked in. That lets us count how many installs are still in use rather than only how many were ever started. It says that Snapline was running and online on that day, and nothing about what you did with it: nothing new is sent by your Mac, and none of it reaches your receipt.
- Seat records. Each license has records keyed by the machine hash, including activation and revocation state. Deactivation or a seat reset marks a seat revoked rather than deleting its record; later activation can reuse it. These requests carry the key and machine hash.
- No content upload. Captures, recognized text, and translations are never sent anywhere by the app.
Links inside the app (Buy, Renew, the GitHub repository) open in your browser when you click them, at which point that site's own policy applies. The Renew link carries your license's identifier, never the key, so the renewal extends that license.
Crash reports
Snapline embeds no crash reporting service, so a crash sends us nothing. macOS writes crash logs locally, as it does for every app, and Apple's own Share with App Developers setting may pass anonymized diagnostics to developers under Apple's terms. We use no such feed and receive no crash data from it. If you want to send us a crash log, you would have to attach it to an email yourself.
4. The website
The site itself sets no cookies and stores nothing in your browser. Paddle's script, on the three pages that show a price, is the exception, and is described below. The site counts its readers with a small counter we wrote ourselves, running on the site's own domain. Each page view sends an event to the site's /api/metrics endpoint, which records the event name, the page path, the country and region Cloudflare already attaches to every request, the host name of the site you arrived from (only the host, never the page or its query, and nothing at all when you arrived directly or from one of our own pages), your platform family (Mac, iPhone, iPad, Android, Windows, Linux, or other, read from the browser's own description of itself), and a visitor number made by hashing the request's IP address and browser signature together with the current date. The IP address itself is never stored, and the number changes every day; it can say that two page views on the same day were the same person, and nothing more. The hash has no secret key, so the number is pseudonymous rather than anonymous: someone holding one, its date and your browser's exact signature could recover the IPv4 address behind it by trying every possible address. We do not do that, and the numbers are kept only in our own Cloudflare account. The site also counts, as bare totals, how many readers reach the pricing section, scroll to the bottom of the landing page, play the tour video, and click the download and buy buttons. None of it goes to anyone but Cloudflare, which stores it for us; there is no advertising network and no visitor profiling.
Cloudflare Web Analytics. Cloudflare, which hosts the site, measures it too. On every page, this one included, Cloudflare adds its Web Analytics beacon as the page is delivered: a script from static.cloudflareinsights.com that reports how the page loaded to snap-line.app/cdn-cgi/rum. Cloudflare shows us the results as totals: visits and page views by page, country, referring page, browser, operating system and device type, with load-time measurements. Cloudflare says the beacon uses no cookies or local storage and does not fingerprint visitors by IP address or user agent. It is a second measurement, kept by Cloudflare beside our own counter, and the two are never joined.
"Send the link to my Mac." On a phone or tablet the landing page offers to send the download link to your Mac instead. It hands the link to your device's own share sheet (or, where there is none, opens your own mail app with the link in it), and you choose where it goes: AirDrop, Messages, Mail, Notes. It leaves from your device and your accounts, and nothing you choose or type there reaches us. The site counts, as a bare total, how many times the link is shared this way.
Those counts live in Cloudflare's Workers Analytics Engine, in a dataset called snapline_site, and Cloudflare ages them out after 90 days. Requests whose browser identifies itself as a bot or a crawler are dropped before anything is written, so the numbers are readers rather than machines.
The site is hosted on Cloudflare Pages. Like any web host, Cloudflare processes the technical data a request necessarily carries (IP address, user agent, the URL requested, timestamps) to deliver the page and to protect the site from abuse. We keep no log of that raw traffic ourselves. The records of a visit we hold are our own counter and the Cloudflare Web Analytics totals, both described above, and neither shows us your IP address.
The site's fonts, styles, and its own scripts are served from snap-line.app itself; nothing is loaded from Google or any font service. Two outside companies load code into the pages, listed below with every host a page contacts before any checkout opens. Each sees your IP address and user agent, because that is how the web works:
| Loaded from | Pages | What for |
|---|---|---|
| Cloudflare (static.cloudflareinsights.com) | Every page | The Web Analytics beacon described above. It sets no cookies and stores nothing in your browser. |
| Paddle (cdn.paddle.com, api.paddle.com, and its checkout) | Home, Buy, Renew | Displaying the price in your local currency, and running the checkout. Paddle infers your country from your IP address so the price shown is the price you would pay. Its price lookup can set __cf_bm, a bot-protection cookie on paddle.com that Cloudflare, which issues it, describes as expiring after 30 minutes of inactivity and not identifying you. The checkout sets Paddle's own cookies and local storage, for the checkout and for fraud prevention. |
| Paddle Retain (public.profitwell.com, formerly ProfitWell) | Home, Buy, Renew | Paddle's customer-retention tool, which Paddle's script loads wherever it runs. We do not identify you to it, and when we checked on 24 September 2026 it made no requests of its own on these pages. |
On the home page Paddle's script only looks up the localized price, though that still loads Paddle Retain and can set the __cf_bm cookie. The checkout, and the storage that comes with it, exists on the Buy and Renew pages and opens only when you press the button there.
5. Buying a license, and what we keep
Paddle.com Market Ltd is the Merchant of Record for every Snapline purchase. That means Paddle, not us, sells you the license, takes the payment, and handles sales tax. Paddle collects and processes what a payment requires: your name, email address, billing address, country, payment card or wallet details, and the transaction record. Card numbers never reach us and are never stored by us.
Paddle is an independent controller of that payment data and handles it under its own policy, which is at paddle.com/legal/privacy.
What reaches us, after a completed payment, is your email address and the transaction's identifiers. A small Cloudflare Worker uses them to mint your license key, store it so a lost key can be reissued and so a webhook retry never issues you a second one, and then send the key to you by email.
Everything we keep about a purchase lives in Cloudflare Workers KV, and this is all of it:
| Data | Why it exists | Kept |
|---|---|---|
| Your email address | To send the license key, to find your key again if you lose it, and to extend the right update window when you renew. | For as long as the license exists, since a perpetual license has to stay reissuable. |
| The license key issued to you, and its identifier | So that one purchase yields exactly one key, however many times the payment webhook is retried. | Same. |
| Purchase date, update-window end date, number of seats | The terms of the license itself, and what a renewal extends. | Same. |
| Paddle transaction and customer identifiers | To match a support request or a refund to the right license. | Same. |
| The identifiers of the licenses bought under your address, filed under a hash of it | So a renewal that does not name its license can tell whether more than one could be meant. | Same. |
| Support email you send us | To answer you, and to remember the answer if you write again. | Up to 3 years from the last message in the thread. |
That table, the seat and trial records described in section 3, the page counter and Cloudflare Web Analytics totals in section 4, and, if you asked for it, the newsletter record below are the whole of what we hold. There is no profile, no behavioral record, no list of what you captured, and nothing derived from your use of the app, because the app reports nothing. The counter and your purchase are never joined: nothing in the metrics dataset identifies a buyer, and nothing in the license record says anything about a visit.
Ask us to delete your license record and we will. Be aware of the trade-off, which we would rather state than bury: once the record is gone we can no longer prove the license was yours or reissue the key, so keep your own copy of it first. Your existing installation is unaffected either way: the key keeps verifying offline.
The release newsletter, if you ask for it
Snapline sends an email about new releases, about once a week and only when there is a release to report. You are on it only if you said yes when Paddle's checkout asked whether you would like to hear from us. Buying is not saying yes, and nobody is added without it.
The list keeps your email address; your name as Paddle has it (or, where it has none, the part of your address before the @); your Paddle customer identifier; the language Paddle recorded; the date you became a Paddle customer; and a note that you joined at checkout. If an issue to you bounces or is reported as spam, the list also keeps a record of that, and a hard bounce or a spam report blocks the address from further issues. It lives in Listmonk, open-source mailing-list software we run ourselves at lists.snap-line.app, on a DigitalOcean server in Frankfurt, Germany, and each issue goes out through Amazon SES from news@news.snap-line.app, an address kept apart from the one that sends license keys.
Each issue carries a tracking pixel: a tiny image your mail app fetches from our newsletter server, lists.snap-line.app, when it shows images, which tells us the issue was opened. Listmonk keeps opens as a count for each issue, not tied to you or to any other reader. Fetching the image is a request to that server like any other web request, and section 6 lists who handles it. The logo and pictures in an issue load from this website, as the requests section 4 describes. Links are not tracked per reader.
Every issue ends with an unsubscribe link, and the link takes you off the list. Leaving changes nothing about your license. You can also write to support@snap-line.app.
We keep the record while you are subscribed. After you unsubscribe, your address stays on the list marked unsubscribed, because that is what stops a later sync from Paddle adding you back, and the next such sync records your choice in Paddle too. An address blocked after a hard bounce or a spam report stays on the list marked blocked, which is what stops it being mailed again. Ask us and we will delete the record outright, once Paddle records that you said no.
6. Who else handles it
| Service | Role | Sees |
|---|---|---|
| Paddle.com Market Ltd | Merchant of Record, independent controller | Name, email, billing address, payment details, tax location. On the pages that show a price, the requests its scripts make (section 4). |
| Cloudflare, Inc. | Processor: site hosting and Web Analytics, the license-issuing Worker, the KV store, the metrics dataset, and the network in front of the newsletter server at lists.snap-line.app | Site request metadata, the Web Analytics page-load reports and the page counts from section 4, the license records above, and the requests your mail app makes to the newsletter server. |
| Amazon Web Services, Inc. (Amazon SES) | Processor: email delivery | Your email address, the license email itself, and, if you subscribed, each newsletter issue sent to you. |
| DigitalOcean, LLC | Processor: hosting the release newsletter's server (Listmonk), in Frankfurt, Germany | The newsletter records in section 5, and the requests your mail app makes to that server (the tracking pixel, the unsubscribe link, and "View in browser"). |
| GitHub, Inc. (Microsoft) | Storage of the app's release files and update feed, fetched by our server | For installs running 2.7.0 or earlier only: the IP address and headers of update checks and downloads. Nothing from newer installs or website downloads. |
We do not sell personal information, we do not share it for advertising or cross-context behavioral advertising, and there is no other recipient. If that ever changes, this list changes with it before it happens.
7. Why we are allowed to hold it
For readers in the EU, the UK, and anywhere with a comparable law, the legal bases under the GDPR and UK GDPR are:
- Performance of a contract: issuing your license key, emailing it to you, reissuing it, and extending it on renewal. Without your email address there is nowhere to send what you bought.
- Legitimate interests: answering support requests, and keeping the purchase flow from issuing duplicate or fraudulent licenses. The interest is narrow and the data is the minimum the job takes.
- Legal obligation: tax and invoicing records, which are kept by Paddle as the Merchant of Record rather than by us.
- Consent: the release newsletter, and nothing else. You give it at checkout and withdraw it at any time with the unsubscribe link in every issue; withdrawing affects nothing else here.
The newsletter is the only part of this policy that rests on consent. Apart from it, we do not email you unless you bought something or wrote to us.
8. Your rights
Depending on where you live you have some or all of these rights over the data described above: to know what is held, to get a copy, to have it corrected, to have it deleted, to restrict or object to how it is used, and to receive it in a portable form. California residents have the equivalent rights under the CCPA, including the right not to be discriminated against for exercising them.
Exercise any of them by emailing support@snap-line.app from the address you bought with, or telling us the address you bought with. We answer within 30 days, and there is no charge. We may ask you to confirm the request from that address, since it is the only thing tying a person to a record.
For payment data, the faster route is Paddle directly, since Paddle holds it. If you are in the EU or the UK and think we have handled your data badly, you can complain to your national data protection authority.
9. International transfers
Snapline is made and run by one person, and the services it relies on are global. Cloudflare, Amazon Web Services, and GitHub process data in the United States and elsewhere; Amazon SES sends both the license email and the newsletter from the United States. The newsletter server runs on DigitalOcean in Frankfurt, Germany. Paddle operates from the United Kingdom with infrastructure in the EU and the US. Where personal data leaves the EEA or the UK, those providers rely on the European Commission's Standard Contractual Clauses and the UK Addendum, or on an adequacy decision, in their agreements with us.
10. Changes to this policy
If this policy changes, the date at the top changes with it, and the previous versions remain visible in the site's public history. If a change is material (a new recipient of data, a new category collected, a new purpose), we will say so plainly here rather than quietly amending a sentence. Nothing in an update applies retroactively to data already deleted.
24 September 2026. A correction, stated plainly as promised above. Two things the site has loaded since early September 2026 were missing from this policy: Cloudflare Web Analytics on every page, and Paddle Retain with Paddle's __cf_bm cookie on the pages that show a price. Both are now in sections 4 and 6. Google is gone from section 6: it has not served the site's fonts since 3 August 2026. And the visitor number in section 4 is now described as what it is, a pseudonymous hash, rather than one that cannot be reversed.
25 September 2026. A correction, stated plainly as promised above. The release newsletter, set up on 20 September 2026, was missing from this policy, which said there was no marketing list and that nothing here rested on consent. The short version and section 1 now include it; section 5 describes what it keeps, its open tracking, how to leave it and how long it is kept; section 6 adds DigitalOcean, which hosts it, and what Cloudflare and Amazon SES handle for it; section 7 adds its legal basis, consent; and section 9 says where it is hosted and sent from. One more correction: on 20 September 2026 the first release email also reached two buyers who had not agreed to it, because of an import option we have since removed. Their newsletter records were deleted on 25 September 2026.
29 September 2026. A new category collected, stated here as promised above. Trial and seat records in section 3 now keep the date of each machine's most recent check-in and how many days it has checked in, so we can tell how many installs are still in use. The app sends nothing new for it: the check-ins themselves were already described in section 3, and only the date is kept, never the time. Records are dated from 29 September 2026 onward; nothing earlier was reconstructed.
11. Contact
Ziad Ziadeh, developer of Snapline.
Email: support@snap-line.app
A postal address for formal data requests is available on request to that address.