Stolly - Consent and Preference Management Specification (EU / Sweden)

Version: 1.0

Date: 2025-11-20

Controller:

Contacts:

Jurisdiction and framework:

1. Purpose, scope and status of this document

1.1. This Consent and Preference Management Specification (“Consent Specification”) defines how Stolly obtains, records, manages and honours user choices relating to consent, objection and opt-out for specific processing purposes within the Stolly mobile application, website and related services (“Service”).

1.2. The document covers in particular:

1.3. This document is an internal legal-technical implementation standard. It does not itself constitute a public contract with users but is intended to be consistent with, and to implement in practice, the Terms of Service, Privacy Policy, Community Guidelines, Payment Terms, Refund Policy and Copyright & DMCA Policy (together, the “User-Facing Policies”).

1.4. In the event of conflict between this Consent Specification and a duly adopted and published User-Facing Policy, the User-Facing Policy prevails for external users. This document then serves as a basis to update the implementation and technical behaviour.

2. Legal basis framework and key principles

2.1. Stolly processes personal data only where one or more lawful bases under Article 6 GDPR apply, in particular:

2.2. Consent is used only where appropriate and necessary, in line with GDPR Articles 4(11), 6(1)(a), 7 and 8 and the ePrivacy rules. Where consent is not the primary legal basis (for example, security logging, core analytics, or certain non-invasive operations based on legitimate interests), consent mechanisms may still be used as a practical way to implement objections and user preferences.

2.3. All consent obtained via the Service must be:

2.4. For children and teens, Stolly applies enhanced protections and, where applicable, parental verification in accordance with Article 8 GDPR and national rules.

2.5. Consent logs and preference states are kept in an auditable, tamper-resistant manner so that Stolly can demonstrate compliance to supervisory authorities and respond to user complaints.

3. Distinction between required information and optional consent

3.1. Certain processing is strictly necessary for the performance of the contract with the user and for legal compliance (for example, maintaining an account, securing login, moderating harmful content, keeping minimal logs for security and fraud prevention, and processing basic payment information). These operations do not rely on consent as a legal basis.

3.2. During onboarding, users are presented with mandatory notices and must confirm that they:

3.3. Separate from these mandatory confirmations, the Service presents granular toggles or checkboxes for optional processing purposes. These are voluntary and default to “off” unless and until the user explicitly enables them. The user can still use the core Service without enabling any optional consent, subject to technical feasibility and legal requirements.

3.4. For purposes where Stolly relies on legitimate interests instead of consent (for example, certain internal analytics, security logging or non-personalised recommendations), the app may expose an opt-out or objection setting. In those cases the toggle is not a “consent” switch in a strict legal sense, but a technical way to honour the user’s right to object under Article 21 GDPR.

4. Catalogue of consent-relevant purposes

For implementation purposes, each consent-relevant purpose is associated with a stable internal “consent key”. The minimum set of keys is:

Additional keys may be defined as new features are introduced, provided they are mapped to clear purposes and reflected in the Privacy Policy.

5. Onboarding: required notices and age confirmation

5.1. At or immediately before account creation, the app must display a consolidated notice explaining that Stolly will process personal data to operate the Service. This notice will be broadly consistent with the wording used in the Privacy Policy and may be formatted as follows (copy may be localised per language):

“To run your account and deliver the Service (hosting your stories, playback, login, security), Stolly processes personal data such as your email, date of birth, user content, IP address and device information. This is necessary to provide the Service to you. For details, see our Privacy Policy.”

5.2. Below the notice, three checkboxes are presented:

5.3. These boxes must be unchecked by default and must be ticked before account creation can proceed. The labels must be hyperlinked to the current versions of the Terms of Service and Privacy Policy.

5.4. The onboarding flow must collect date of birth (DOB) in a format that allows calculation of age and checking against local thresholds (13-16). The app also collects at least the country of residence (via explicit selection and/or IP-based pre-fill) to determine whether parental consent is required.

6. Granular consent items and default settings

6.1. General UX rules

6.1.1. All optional consent items must be presented as separate toggles or checkboxes both:

6.1.2. Each toggle must:

6.1.3. Toggling “on” sends a consent event to the backend and activates the corresponding processing only after the event has been recorded (or, at minimum, queued). Toggling “off” triggers the withdrawal / objection logic set out in Section 8.

6.2. Location (geographical) - geo_location

6.2.1. Purpose: To use approximate or precise device-level location to surface local stories, trends and features.

6.2.2. Data: GPS coordinates (where available), network-based location, associated timestamps and coarse country / region metadata.

6.2.3. Legal basis: Consent (Art. 6(1)(a)) where device-level location is not strictly necessary to provide requested functionality.

6.2.4. Copy (baseline in English):

6.3. Optional analytics - analytics_optional

6.3.1. Purpose: To enable optional analytics SDKs and extended event streams that are not strictly necessary for security, abuse detection or basic performance monitoring.

6.3.2. Data: App events (screen views, feature usage, crash logs, performance metrics), device type, OS version, app version, pseudonymous identifiers or SDK-specific IDs.

6.3.3. Legal basis: Depending on jurisdiction and technical configuration, either consent (Art. 6(1)(a) and relevant ePrivacy rules) or legitimate interests (Art. 6(1)(f)) with appropriate safeguards. Where consent is required, the toggle must be treated as a consent mechanism; where legitimate interests apply, the toggle implements a voluntary opt-out.

6.3.4. Copy:

6.4. Personalisation and profiling - personalization

6.4.1. Purpose: To personalise feeds and recommendations, including the “For You” feed, based on user interactions with content.

6.4.2. Data: Story view events (including duration, completion, skips), likes, favourites, follows, mute/hide signals, basic context such as language, device type and time of day, and derived embeddings or interest vectors.

6.4.3. Legal basis: Consent (Art. 6(1)(a)) where required by national law for certain types of tracking; otherwise legitimate interests (Art. 6(1)(f)) combined with the right to object (Art. 21). The toggle implements either explicit consent or an objection, depending on jurisdiction.

6.4.4. Copy:

6.5. Marketing emails and similar communications - marketing_communications

6.5.1. Purpose: To send marketing communications about new features, promotions and news about Stolly that are not strictly necessary for provision of the Service.

6.5.2. Data: Email address, language and region, engagement metrics (opens, clicks), subscription status.

6.5.3. Legal basis: Consent (Art. 6(1)(a)) or, where permitted, legitimate interests (Art. 6(1)(f)) combined with opt-out. In either case, the toggle must be treated as a robust opt-in / opt-out mechanism.

6.5.4. Copy:

6.6. Push notifications - push_notifications

6.6.1. Purpose: To send push notifications relating to comments, replies, follows, engagement with a user’s content, and important service information.

6.6.2. Data: Device push tokens, notification topics (e.g., “new comment”, “new follower”), language and time zone, and basic interaction metrics.

6.6.3. Legal basis: Legitimate interests (Art. 6(1)(f)) combined with opt-out. OS-level permission is also required.

6.6.4. Copy:

6.7. Cookies and SDKs (web and in-app) - cookies_non_essential and sub-keys

6.7.1. Purpose: To manage consent for non-essential cookies and similar technologies on the website and, where applicable, in-app SDKs.

6.7.2. Categories (each may be represented with its own internal key):

6.7.3. Legal basis: Consent (Art. 6(1)(a) GDPR and ePrivacy rules). Non-essential cookies and similar technologies must be off by default.

6.7.4. First-layer banner text (example):

“We use cookies and similar technologies to run Stolly and, with your permission, to improve and personalise your experience. You can accept all cookies, reject non-essential ones, or manage your settings.”

Buttons: “Accept all” / “Reject non-essential” / “Cookie settings”.

6.8. AI training and research - ai_training

6.8.1. Purpose: To use certain published user content, associated metadata and behaviour signals as part of internal datasets to train, test and evaluate Stolly’s AI models for story generation, TTS and safety systems.

6.8.2. Data: Selected published stories (text and audio), associated captions and tags, language, public profile identifiers, and aggregated engagement signals such as views and likes. No raw direct messages or private content are included.

6.8.3. Legal basis: Consent (Art. 6(1)(a)) where required. Where Stolly relies on legitimate interests for certain limited evaluation activities, consent still acts as a strong preference and opt-out signal.

6.8.4. Copy:

7. Parental and guardian consent flows

7.1. Age assessment

7.1.1. The onboarding flow must use the declared date of birth and country information to determine whether the user is:

7.2. Restricted account pending parental consent

7.2.1. Where local law requires parental consent for children below a certain age (e.g., 16 in some EU Member States), the following logic applies:

7.3. Guardian email and verification

7.3.1. Stolly sends a verification email to the indicated address containing:

7.3.2. The guardian consent page presents:

7.3.3. The secure link must expire after a defined period (e.g., 7 days). If no valid consent is received within that period, the child’s account remains restricted or may be deleted, in line with the Privacy Policy.

7.4. Logging parental consent

7.4.1. If the guardian confirms consent:

7.4.2. Guardians must be able to withdraw consent by contacting privacy@stolly.app. Withdrawal triggers the same logic as for user-initiated withdrawal, with additional safeguards appropriate for minors.

8. Withdrawal of consent, objection and preference changes

8.1. User-initiated changes

8.1.1. Users must be able to view and change their consent and preference status at any time in Settings → Privacy / Consent Center. The interface should list all relevant toggles, show their current state, and provide a “Withdraw all non-essential consents” option.

8.1.2. Any change to a toggle must immediately update the local state and send a corresponding event to the backend, which updates the authoritative record in the consent logs and user profile.

8.2. Effects of withdrawal / objection

8.2.1. For each consent key, withdrawal or objection must have the following minimum effects:

8.3. Timing

8.3.1. Technical changes that are fully under Stolly’s control should take effect as close to real-time as reasonably possible and no later than 24 hours after the change is recorded.

8.3.2. Changes that require updates to external systems (for example, marketing platforms or advertising SDKs) must be implemented without undue delay and, in any event, within 72 hours, subject to technical constraints.

8.4. Confirmation

8.4.1. For significant changes (in particular withdrawal of multiple consents or marketing opt-out), Stolly should provide a short confirmation via in-app notice and/or email, summarising which preferences were changed and when.

9. Consent logging, evidence and technical specification

9.1. General principles

9.1.1. Stolly maintains an auditable, append-only record of consent-related events to demonstrate compliance with GDPR Article 7(1) and to respond to supervisory authority requests.

9.1.2. Consent logs are separate from, but linked to, user profile and settings data. For operational use (e.g., feature flags), Stolly may store the current consent state in profile tables; for evidence, it relies on the dedicated consent logs.

9.2. Minimal data fields

9.2.1. Each consent event must contain, at minimum:

9.2.2. Where relevant, the following additional fields should be recorded:

9.3. Storage and access control

9.3.1. The consent log table must enforce strong access controls, including Row Level Security (RLS) where supported by the platform. Only authorised backend services and limited staff (for example, privacy, security and compliance personnel) may access consent logs.

9.3.2. Direct editing of consent logs in place is prohibited except for narrowly scoped corrections subject to additional audit logging. Implementation should favour append-only operations, with corrections recorded as new entries.

9.4. Example schema (PostgreSQL)

The following schema is illustrative and may be adapted as needed:

CREATE TABLE consent_logs (

consent_id UUID PRIMARY KEY DEFAULT gen_random_uuid(),

user_id TEXT,

consent_key TEXT NOT NULL,

consent_value BOOLEAN NOT NULL,

timestamp_utc TIMESTAMPTZ NOT NULL,

policy_version TEXT,

policy_url TEXT,

app_version TEXT,

method TEXT,

jurisdiction TEXT,

ip_truncated TEXT,

device_hash TEXT,

guardian_id TEXT,

revoked_at TIMESTAMPTZ,

revocation_reason TEXT

);

CREATE INDEX consent_logs_user_idx

ON consent_logs (user_id);

CREATE INDEX consent_logs_key_time_idx

ON consent_logs (consent_key, timestamp_utc);



10. Retention of consent records and related data

10.1. Consent logs

10.1.1. Consent logs are retained for the lifetime of the user account plus five (5) years, or longer where necessary to establish, exercise or defend legal claims, or to comply with statutory retention and limitation periods.

10.1.2. After the retention period expires, consent logs should be irreversibly anonymised or deleted. Anonymisation must ensure that the data can no longer be linked to an identified or identifiable natural person.

10.2. Profiles, content and analytics

10.2.1. Retention rules for user profiles, content, analytics and other personal data are governed by the Privacy Policy. Consent and preference states must be consistent with those rules and taken into account when designing deletion and anonymisation logic.

10.3. Backups

10.3.1. Deletion or anonymisation within live systems must be followed by expiry in backup media according to defined backup retention schedules, typically not exceeding ninety (90) days unless legally required otherwise.

11. DPIAs, LIAs and governance

11.1. Data Protection Impact Assessments (DPIAs)

11.1.1. Before deploying or materially modifying features that involve:

Stolly must assess whether a DPIA is required under Articles 35-36 GDPR. Where required, the DPIA must document the processing, assess risks to rights and freedoms, and set out mitigation measures.

11.2. Legitimate Interest Assessments (LIAs)

11.2.1. For processing operations relying on legitimate interests (for example, certain analytics, security or non-personalised recommendations), Stolly must maintain LIAs that:

11.3. Versioning and review

11.3.1. This Consent Specification must be reviewed at least annually and whenever relevant laws, guidance or Stolly features change. Version numbers and dates must be updated accordingly and cross-referenced in the Privacy Policy and Terms of Service.

11.3.2. Product, engineering and legal / privacy teams are jointly responsible for ensuring that:

12. UI microcopy (reference text)

The following strings are reference English texts for use in the app; they may be adapted for local languages, provided the meaning remains equivalent.

Example Swedish translations (short):

13. Email templates (reference text)

13.1. Parental consent request

Subject: Action required - parental consent for [Child Name] on Stolly

Body (plain text):

Hi [Parent Name],

[Child Name] (date of birth: [DOB]) has registered for Stolly and requested access to our Service.

Please review our Terms of Service and Privacy Policy at:

[Links]

To allow [Child Name] to use Stolly, please confirm your relationship and consent by clicking the link below:

[Guardian Consent Link]

If you did not authorise this or have any questions, contact us at privacy@stolly.app.

13.2. Consent withdrawal confirmation

Subject: You updated your privacy choices on Stolly

Body:

Hi [User],

You recently changed your privacy choices on Stolly on [timestamp]. The following settings have been updated: [list of keys].

We will stop the related processing as soon as possible, and in any case within 24-72 hours where third-party systems are involved.

If you did not make this change or have questions, please contact us at privacy@stolly.app.

13.3. Policy and consent update notification

Subject: Update to Stolly Privacy & consent options

Body:

Hi,

We have updated our Privacy Policy and how we present privacy and consent options in the app. The changes apply from [effective date].

You can review the updated Privacy Policy here: [link] and adjust your preferences at any time in Settings → Privacy.

If you have any questions, please contact privacy@stolly.app.

14. Supervisory authority and complaints

14.1. Users must be informed, via the Privacy Policy and other materials, that they may:

14.2. For users in Sweden, the competent authority is Integritetsskyddsmyndigheten (IMY).

15. Final provisions

15.1. This Consent and Preference Management Specification is intended to ensure that the design and implementation of Stolly’s consent mechanisms align with GDPR, Swedish law and other applicable European rules. It must be read and applied together with the Terms of Service, Privacy Policy, Community Guidelines and other User-Facing Policies.

15.2. Any material deviation from this Specification in the design or operation of the Service should be assessed by legal and privacy stakeholders and, where necessary, documented, mitigated or corrected without undue delay.