Privacy Policy
1. Controller and contact
This policy describes how personal data is processed in the SlipperySign Mail application (the “Service”).
The Service is operated by Yusuf Murad Disli, sole proprietor, trading as SlipperySign:
Rucholzstrasse 64103 Bottmingen
Switzerland
For privacy enquiries, including requests to exercise the rights set out in section 13, contact [email protected].
SlipperySign is established in Switzerland and subject to the Swiss Federal Act on Data Protection. The European Commission has determined that Switzerland provides an adequate level of protection for personal data, most recently in January 2024. Personal data may therefore be transferred from the EU and EEA to SlipperySign without Standard Contractual Clauses or other additional safeguards.
Where the Service is used by an organisation, that organisation is the controller in respect of the campaign content and recipient data it processes, and SlipperySign acts as its processor. SlipperySign is the controller in respect of the account identifiers and service operation data described in section 3(a).
2. Scope
This policy covers the Service at app.slipperysign.com and its
associated interfaces. It does not cover your email provider (Google Workspace),
whose own terms and privacy notices govern the mailbox from which your messages
are sent.
3. Categories of personal data
(a) Account and operation data. Your email address, as supplied by your identity provider on sign-in; your organisation’s domain; your role within the Service; and records of administrative actions, for example the addition of an administrator or use of the “view as user” function.
(b) Campaign content. The subject, body, images and configuration of the campaigns you compose, including any personal data you choose to place in them.
(c) Aggregate measurement data. Counts of opens and link clicks per campaign and per calendar day. See section 7.
(d) Technical data. Request metadata processed transiently to deliver and secure the Service, including IP address and user-agent string.
The Service does not request, and has no function in which to store, special categories of personal data within the meaning of Article 9 GDPR.
4. Purposes and legal bases
| Purpose | Data | Legal basis |
|---|---|---|
| Providing the Service to you | 3(a), 3(b) | Contract, Art. 6(1)(b) |
| Authenticating you, maintaining your session | 3(a) | Contract, Art. 6(1)(b) |
| Reporting campaign reach in aggregate | 3(c) | Legitimate interests, Art. 6(1)(f) |
| Securing the Service, preventing abuse | 3(d) | Legitimate interests, Art. 6(1)(f) |
| Meeting audit and governance obligations | 3(a) | Legitimate interests, Art. 6(1)(f) |
5. Authentication and credentials
The Service does not operate a password system. It has no field in which a password can be entered and no store in which one could be kept.
Sign-in is federated. Google authenticates you and returns a signed assertion of your identity. The Service verifies that assertion against the provider’s published signing keys, takes your email address from it, and issues its own session token. The provider’s assertion is not retained after verification.
6. How messages are sent
Messages are sent by your own mailbox, not by SlipperySign. When you send a campaign,
your browser requests a limited, revocable permission from your provider, gmail.send, and transmits the message directly to that
provider’s API.
The resulting access token is held in your browser for the duration of the operation and is never transmitted to, or stored by, SlipperySign’s servers. SlipperySign operates no mail transfer agent and cannot send email on your behalf.
You may withdraw the permission at any time, at myaccount.google.com/permissions.
7. Measurement and tracking
Measurement is aggregate only. When a recipient opens a campaign or follows a tracked link, the Service increments a counter against the campaign and a counter against the calendar day. It does not record which recipient produced the event.
This is a property of the data model rather than a configuration setting: there is no recipient identifier in the tracking tables, and therefore no per-person open or click report that could be produced on request, by us, or by your employer.
Consequently the Service cannot support features that depend on individual-level measurement, such as per-recipient engagement scoring or resending to non-openers. This is a deliberate trade-off.
8. Recipient data
The Service holds no contact database. Campaigns are addressed to distribution lists, group aliases and addresses that exist in your own directory, and those addresses are resolved by your mail provider at the moment of sending.
Addresses you type into a campaign’s settings are stored as part of that campaign’s configuration, under category 3(b), and are deleted with it.
9. Sub-processors
| Sub-processor | Function | Region |
|---|---|---|
| Cloudflare, Inc. | Application hosting, database, object storage, network security | European Union, or United States where elected |
| Google LLC | Identity verification and message sending, through your organisation’s own Google Workspace account | Per your Workspace agreement |
Google appears here because it authenticates you and because your own mailbox sends the mail. It is not an infrastructure provider to SlipperySign: the Service’s application, database and stored images run on Cloudflare.
10. Storage location and transfers
Campaign content, account data and uploaded images are stored in the European Union by default, in object storage subject to an EU jurisdiction restriction. Organisations may elect United States storage instead; the election is recorded against the organisation’s record and applies only to that organisation’s data.
Where an election results in a transfer outside the EEA, that transfer is made on the basis of the European Commission’s Standard Contractual Clauses.
11. Retention
- Account data is retained while your account is active.
- Campaign content is retained until you delete it, or until the retention period configured by your organisation elapses after sending.
- Aggregate measurement data is retained for the period configured by your organisation. Daily detail is removed first; campaign totals may be kept longer as a record of reach.
- Uploaded images that no campaign references may be removed after thirty days, where the organisation has enabled that sweep. Brand assets are exempt.
- Administrative audit records are retained for the life of the account, since they exist in order to be auditable.
Sent campaigns are immutable. A sent campaign can be deleted but not edited, so that the stored record continues to reflect what was actually distributed.
12. Security measures
- All connections are encrypted in transit using TLS.
- Data is segregated by organisation, and that segregation is enforced on the server for every request rather than in the browser.
- Session tokens are signed, expire, and carry no permission to send mail.
- Administrative access is role-based. Use of the “view as user” function is recorded in an audit log, and a session obtained that way cannot send email.
- Published campaign pages are served under a restrictive Content Security Policy.
13. Your rights
Subject to the conditions set out in the GDPR, you have the right to request access to your personal data (Art. 15), its rectification (Art. 16), its erasure (Art. 17), restriction of processing (Art. 18), portability (Art. 20), and to object to processing based on legitimate interests (Art. 21).
Write to [email protected]. We respond within one month. Where you use the Service through your employer, we may need to refer your request to them as controller, and will tell you if we do.
You may also lodge a complaint with a supervisory authority: in Switzerland the Federal Data Protection and Information Commissioner, or in the EEA the authority for your place of residence or work.
14. Automated decision-making
The Service performs no automated decision-making or profiling within the meaning of Article 22 GDPR. It does not score, segment or rank individuals.
15. Changes to this policy
Material changes will be notified in the application before they take effect. Each version carries a version number and effective date, and names the version it supersedes at the top of this page.