Privacy Policies

SayCopyPaste, PrintScreen.ly, ASAPDF, Diskaroo, Markd.ly, Terminal Tags, Sticki.ly, Scry, Todoing.ly and all112 can send us two kinds of technical report, which you control from Help & Diagnostics in each app's Settings, with exceptions, described below: Scry for Mac has no switch for automatic diagnostic reports, and in SayCopyPaste for Linux, Diskaroo for Linux and Markd.ly for Linux before version 0.7.5-beta.2, the switch for automatic error reports does not yet turn them off. Automatic error reports do not carry your Bravely Account identifier or your email address. Diagnostic reports carry your Bravely Account identifier. We use both only to find and fix problems, and we do not sell them or use them for advertising. Bellwether and MonitorMonitor describe their own diagnostic reports in their own policies. Automatic error reports When an app records an error or a warning, it can send us a short report about it. It collects these on your device and sends them in small batches, about once a minute while problems are happening. A report names the app, the platform, the app version and your operating system version. For each problem it gives: • its category and type, and a short description of it with details removed • how many times it happened, and when it was first and last seen • whether you were signed in, whether you had an active plan, and whether the device was online Some apps also add how long the app had been running, the names of up to three functions in the app's code where the problem happened, and up to ten of the app's own log entries from just before it, with details removed. Before a report leaves your device, the app removes details such as email addresses, account identifiers and file paths from its text. Our server removes those details again before the report is stored, and also removes network addresses, long strings of hexadecimal characters and sign-in tokens in the common JWT format. Error reports do not contain your Bravely Account identifier or your email address, and our server does not record your IP address with them. Our apps are built to keep the contents of your documents, files, notes, tasks, time entries, screenshots, dictations, terminal output or remote sessions out of error reports. Instead of a device identifier, each report carries a code that the app works out from a random identifier it keeps for its installation and from the date, so the code changes every day. We use the code to count how many devices ran into a problem on a given day and to limit how many reports one device can send. When you first use an app, it asks our server which country your connection comes from, and the server answers without storing the answer. If the country is in the European Economic Area or the United Kingdom, automatic error reports are off until you turn them on. Everywhere else, they are on until you turn them off. Our web and Android apps keep reports off until the answer arrives, and if no answer comes, they go by the region in your browser's or device's language settings. Our other apps keep reports on until the answer arrives, and some of them leave reports on if no answer comes. Our Linux apps other than ASAPDF and Markd.ly 0.7.5-beta.2 or later, and Todoing.ly for Windows and Linux, do not ask yet, so in those apps automatic error reports start on wherever you are. In SayCopyPaste for Linux, Diskaroo for Linux and Markd.ly for Linux before version 0.7.5-beta.2, the switch does not yet turn automatic error reports off. In our other apps, you can turn automatic error reports on or off at any time under Help & Diagnostics. We delete each report after 30 days, and the hourly counts we make from reports after 7 days. We keep a summary of each kind of problem with no set end date: its category, type and description with details removed, the app versions it happened in, how many times it happened, on how many devices it happened each day, when it was first and last seen, and a recent example of the log entries that led up to it. Diagnostic reports A diagnostic report is a fuller report about one problem. An app sends one when you press Send Diagnostic Report. Unless you turn automatic diagnostic reports off under Help & Diagnostics, it also sends one when something fails in a way you might not notice, such as a sync that keeps failing or a remote session that ends unexpectedly, and at most once an hour for the same kind of problem. Apps that send our newer diagnostic reports, described below, can also send one, except on the web, when the app stops responding for 5 seconds or more, or the next time you open it after it closed unexpectedly. Automatic diagnostic reports are on by default wherever you are. In Scry for Windows, the switch for automatic error reports also turns automatic diagnostic reports on and off. Scry for Mac does not have a switch for them. Diagnostic reports are sent only while you are signed in. A diagnostic report contains the app version, your operating system version, a few counts and settings from the app (for example, how many documents are open, or whether sync is on) and, where the app keeps them, its own recent log entries. A Scry report also describes the remote session, such as its connection statistics and why it ended. In apps that send the newer reports, a report can also contain: • A record of your recent activity in the app: the names its code gives to its screens and to events such as signing in, changing a setting, the network going offline or a key press the app ignored, with details limited to numbers, yes-or-no values and fixed words that the app's code defines, such as a count or which part of the app something started from. Any other word is left out, so the record is built to leave out names, what you typed, which keys you pressed, file names, addresses, identifiers and the contents of your documents, files, notes, tasks, time entries, screenshots, dictations, terminal output or remote sessions. The app keeps this record, up to its latest 200 entries, only in its memory while it runs, and it leaves your device only inside a diagnostic report. • The state of the app when the report was made. For example: the screen, dialog and tool you were using, what kind of control your typing would go to, what kind of item was selected and how many, and which kinds of window were open. It also shows the state of the network, whether you have an active plan or trial, how long the app had been running and, in apps that sync, the state of sync. In some apps, it shows whether the app has the system permissions it uses. In apps with system-wide keyboard shortcuts, it can show up to eight of them, with the keys each is set to and whether it is working, and how long ago the app last noticed any key being pressed. Like the record, it holds only numbers, yes-or-no values and fixed words, never titles, names or text. • Your display and time zone: the size in pixels and the scale of the display the app is on, and the difference between your time zone and UTC; on a computer, how many displays you have; on Windows and Linux, the version of the software framework the app runs on; and on Linux, which desktop you use and whether it runs on X11 or Wayland. • Up to 50 recent warnings and errors, each with a description with details removed and, where it has one, a short code, and how many warnings and errors the app had recorded. • How the app's previous session ended (normally, in a crash, or unexpectedly, for example because it was forced to quit), with its version, how long it ran and the main steps it recorded, such as starting up. To know this, the app keeps a list of those steps in a file on your device, which it starts again each time it opens. • In Scry: how the most recent attempt to connect went (which end this device was, the session's identifier, the kind of device at the other end and its version of Scry, how far the attempt got, how long it took and how it ended, and the kinds of network connection it tried, but not their addresses); whether the device is online for remote sessions and registered to your account; and, on a computer that others connect to, the state and version of Scry's background service. If you have turned off usage analytics in an app, its newer reports leave out the record of your activity and the previous session's list of steps. In their place they carry a note that the record was left out and a few counts: how many entries the app recorded, combined or dropped to stay within its limit, how many event names or details its filter refused or replaced, and how many times the signed-in account changed. The rest of the report, including the state of the app and the previous session's last step, is still sent, because it describes the problem rather than how you use the app. When a different account signs in, the app first discards everything it recorded for the newer reports until the previous account signed out (or, with no sign-out, until the switch), keeping only a count of how many times the account has changed since the app started. What it recorded while no one was signed in, such as the steps of signing in, can appear in the new account's reports. The app removes details such as email addresses, file paths, and keys or tokens from log entries before they go into a report, and our apps are built to keep the contents of your documents, files, notes, tasks, time entries, screenshots, dictations, terminal output or remote sessions out of a report. In the newer reports, the app also removes text in common quotation marks, network (IP) addresses, the names of document and media files it recognizes by their endings, and your user and computer names, though some details, such as a name it does not recognize, can still appear. Reports from apps and versions that do not send the newer reports can still contain some of these: for example, a document's name in a log entry from ASAPDF for Mac, the network addresses a connection used in Scry for Mac's connection statistics, and, from Scry for Windows, the computer's name, the Windows user names and session details of the accounts signed in to it, and the titles of Scry's windows. Some apps have a switch that records more detail in their own log for 24 hours and then turns itself off. That log stays on your device, apart from the entries that go into a report. With each diagnostic report we record your Bravely Account identifier, the user agent of the app or browser that sent it, the country your connection came from and when it arrived. When you send a report yourself, the app shows you a short code, such as DIAG-7K2QM, to give to support so we can find it. A report's log file, which holds its log entries and, in the newer reports, the record of your activity, the recent warnings and errors and any steps from the previous session, is deleted automatically after 90 days. We keep the rest of the report with no set end date, so we can see patterns across reports: its short code if it has one, your account identifier, the app and its versions, why it was sent, the Scry session details, the counts and settings, the user agent and country, when it arrived, and, in the newer reports, the state of the app, the details of Scry's most recent attempt to connect, your display and time zone details, how many warnings and errors the app had recorded and, if it had recorded any, a short label for the most recent error (or, if there was none, the most recent warning), and, where the app records it, how the previous session ended and its last step. Deleting your Bravely Account deletes your diagnostic reports from our live systems. Our data warehouse keeps its copy of what we keep from each report, without the user agent and country, under your account identifier, as the Bravely Account privacy policy describes. To have a report deleted sooner, email privacy@bravely.dev. Where reports are kept Both kinds of report are stored in database and file storage that Cloudflare runs for us, and copied into a data warehouse that we run ourselves. Diagnostic reports, apart from their log files, are also copied each night into our encrypted backups, described under "Backups" in each app's privacy policy. When our team looks into a problem, they can attach a diagnostic report to an issue in our own issue tracker, whose data Google stores for us. The issue keeps the report's short code (or its number), the app and platform, the app and operating system versions, whether the report was sent by hand or automatically, when it arrived and, for a newer report, a one-line summary of what it shows, such as the screen in use and the most recent problem. It stores the sender only as "customer account", not their account identifier or email address (for a member of our team, it stores their name or email address and their account identifier), and it keeps all of this after the report itself is deleted. While the report and the sender's account exist, our team can see the sender's email address when they view the issue.