Privacy Policy

Key Points

tl;dr It’s your data, not ours. We follow the GDPR.

Breef was designed to be an offline app.
- It can be used without ever uploading data to our servers (except, ironically, to approve the T&Cs and this Privacy Policy for compliance).
We’re fully GDPR compliant.
Breef doesn’t ask permission to - and cannot - read your Gmail.
If you opt in to upload data (e.g. to sync settings), Breef only uploads the bare minimum needed to do the job you requested.
You can see your data, and delete it at any time. (For now, please email)

tl;dr Breef only asks for what it needs

Breef escalates consent as and when you need additional functionality.

You can revoke consent at any time.

Breef’s team only can only access your personal data defined in the Data Record if you expressly request it’s investigated during a customer support issue.

3rd Party Services

tl;dr Breef keeps your data mainly inside Google’s ecosystem

Firebase (Google’s server platform)
- Purpose: Authenticates your identity, and stores your data.
- Data Location: US
Gmail (by Google)
- Purpose: Sales and support conversations
- Data Location: US
Google Worksuite (aka Docs and Sheets)
- Purpose: Recording customer interviews, feature discussions, project planning.
- Data Location: US

Data Record and Impact Assessment

Breef’s use and transfer of information received from Google Accounts will adhere to Google API Services User Data Policy, including the Limited Use requirements.

Email Address / Name
- Basis: Consent + Legitimate Interest
- Purpose: Breef works for Gmail accounts, so it is the main identifier to store data for.
- Source: User submitted when they opt in to sync data.
- Retention: Up to 12 months after the last use of Breef (or deletion upon request).
- Risk: Minor. If breached, liable to spam.
IP Address
- Basis: Legitimate Interest
- Purpose: Used to protect our server from abuse
- Source: User submitted when they accept Breef’s Terms
- Retention: Up to 2 weeks
- Risk: Minor. If breached, could identify that a person uses Breef, opening them to social engineering.
Consent
- Basis: Consent + Legal Obligation
- Purpose: Retain a legal record that the user accepted specific policies for a window of time.
- Source: User submitted.
- Retention: Indefinite.
- Risk: Minor. If breached, could identify that a person uses Breef, opening them to social engineering.
Topics (aka Categories)
- Basis: Consent + Legitimate Interest
- Purpose: Breef can sort emails into Topics. Uploading topics allows them to be synced between devices.
- Source: User submitted when they create them in-app
- Retention: Up to 12 months after the last use of Breef (or deletion upon request, either in-app per contact or by submitting an account termination).
- Illustration: {topic_id: string, name: string}
- Risk: Significant. If breached, indicates the interests a person has.
User’s Contact’s Email Address
- Basis: Consent + Legitimate Interest
- Purpose: When Breef sorts emails into topics, it does so by associating their Sender’s email address with a Topic. Uploading allows them to be synced between devices.
- Source: User submitted when they specify them in-app (by giving the email address a Topic)
- Minimization: Breef doesn’t record every contact, only the ones to whom the user explicitly gives a Topic. However this data cannot be pseudo-anonyimized without key features failing due to insufficient data (e.g. cannot search for all emails in a Topic without knowing the email address of the senders.)
- Retention: Up to 12 months after the last use of Breef (or deletion upon request, either in-app per contact or by submitting an account termination).
- Illustration: {emailaddress:string, topic_id: string}
- Risk: Major. If breached, indicates who a person associates with.
Product Usage Analytics
- Basis: Consent + Legitimate Interest
- Purpose: Identifying which features are used, to prioritize product improvements
- Source: Observing user interaction
- Minimization: Breef captures no personal data (e.g. only that a feature was invoked, not any data contained in the feature).
- Retention: Up to 12 months after the last use of Breef (or deletion upon request).
- Illustration: {feature_X_invocation_count: number}
- Risk: Minor. If breached, reveals that a person uses Breef, opening them to social engineering.

Security

tl;dr Breef only uses reputable platforms and best practices

Server Infrastructure
- Our entire server system is hosted on Google’s platform (Firebase)
  - Firebase is a fully managed service, handling authentication, perimeter defence, encryption at rest, infrastructure personnel security, infrastructure software security patching, and providing inbuilt mechanisms for common data handling (reducing the opportunity for bespoke code vulnerabilities).
- All data transfer is via SSL (https)
- All administrative access requires Multi Factor Authentication
- CORS limits cross-site requests only to Breef’s browser extension
Authentication and Authorization
- Breef authenticates with OAuth (whereby the provider - Google - grants a revocable token with permissions you agree to. It’s like a temporary key that you control. Breef never uses nor stores your Google password).
  - Your OAuth tokens are kept locally within your computer. They never touch our server (except the ID Token, which only verfies who you are, but has no permission to read or modify any of your data).
  - Users can revoke tokens given to Breef at any time. The Breef team can also remotely revoke these tokens within 1 business-day hour, should a system wide compromise be discovered.
Browser Extension
- As a Chrome extension, distributed via the Chrome Web Store, Breef must adhere to Google’s minimum acceptable standards and only uses Chrome’s inbuilt mechanisms for safe data storage. (For the knowledgeable, all data storage and transfer occurs in the most secure part of extension’s architecture: the Background)
- It defines a Content Security Policy that defaults to total lockdown, and whitelists permissions only if needed. This policy is enforced by Chrome.
- The code is written in TypeScript, with Yup schemas to validate uploads and downloads, maximizing the confidence that only the data permitted in this Privacy Policy is being transferred.
- Only Breef’s founder has permission to distribute a new version of Breef, minimizing the opportunity to distribute malware.

Bug Bounty Programme

Please submit any bugs you find.
The rewards are ranked by the Risk in the Impact Assessment above.
- Negligible: $5
- Minor: $20
- Significant: $200
- Major: $1,000
Restrictions
- Payouts are only for proof of concept reports. No whole data must be exfiltrated.
- It must have a direct business impact, by exposing another user’s private data covered in the Data Record above.
- It must be reproducible, with steps provided.
- Payments are only made to the first person to submit it.
- It does not cover any marketing websites (e.g. www.getbreef.com), as they’re disconnected from the user data system in this Privacy Policy.

Data Storage Architectural Policy

tl;dr Cloud data is architected to reveal the bare minimum if a breach happens

All development adheres to the following rules.

Unless there is a reason (agreed in this Privacy Policy), all Personally Identifiable Information identifiers must be at least pseudo-anonymized.
New classes of data must
- Be entered into the Data Record, triggering a Privacy Policy update
- Be released with code to automatically remove it according to the Retention criteria
- Be locked down by default, requiring a specific decision about who to white list access
Data stores should be logically minimal silos, to contain a breach.
Keys and tokens should always be Least Privilege, e.g.
- Only the founder should write code that uses long-lived OAuth tokens, everything else is short-lived.
- Data access keys should be set up for automatic rotation.
- Where possible, whitelist incoming access.
Data access logs must
- be kept to identify attackers and breach impact
- never store PII or credentials.
Where possible, taint data stores with fake data and track as a fingerprint.