What this service knows about you.

Document version

Version of this document: 2026-09-20; the Terms of Use are a separate document and currently sit at version 2026-09-18.

2. Scope of this policy

This policy covers the Rolls & Rocks web application, including the parts that work without an account: uploading a recording, analyzing it, browsing the public catalog and the cookie information page. It does not cover services run by other providers that you reach from here — opening a playlist in Spotify, downloading a preview from Apple, or the donation button leading to PayPal — each of those has its own privacy policy.

3. What is stored, and why

Account — the login you choose, a hash of your password, the date the account was created, information about the last sign-in, and, if you provide it, an e-mail address. The e-mail address is optional and is not required to use the service.

Your session — a session identifier in a cookie, plus the identifiers of the uploads and URL downloads made in that browser before signing in. They are attached to your account when you sign in, which is how an anonymous upload becomes yours.

Record of each submission — the SHA-256 hash of the recording, its size, the original filename, the analysis profile you chose, the timestamps, the status and progress of the analysis, the recognition provider used, the internal identifier of the background task, and an error description if the analysis failed. For a URL submission the application also stores the address you gave it, the download status and the number of bytes transferred. The content of the recording is stored only until the analysis ends (point 4).

Playlists and recognized tracks — the playlist name, who created it, when, its export status, and the recognized tracks: title, artist, album, the identifier returned by the recognition provider, and links to cover art and previews hosted by other providers. Private display names you set for a playlist you imported are stored separately and are visible only to you.

Google sign-in — if you choose this option, we store the provider name, its stable user identifier, the email address supplied by the provider, the first and last name it returns, and the dates the identity was created and last used. The name fills the greeting, and a local username is derived from it. We record your acceptance of the Terms of Use together with the version and the date. We do not automatically link accounts by matching email addresses. Sign-in access and refresh tokens are used only during authentication and are not retained in the database or in the pending signup session. This is separate from connecting Spotify for playlist export.

Spotify connection — only if you connect a Spotify account: your Spotify user identifier, an encrypted access token and refresh token, the permissions you granted, when the token expires, and, if you configured your own Spotify application, its client id and encrypted client secret.

Donations — the donation prototype stores a reference number, a nominal amount and currency, its status, the date, and — when given — the donor name, e-mail address and message. Payment card and bank details are handled by PayPal on its own page.

Contact messages — the name, e-mail address, subject and message you send through the contact form. The form is delivered as an e-mail to the operator, and the application keeps no copy of it: the message lives in the operator's mailbox, which is not part of this service.

Technical logs — the web server and the analysis workers write logs for diagnostics and security, which normally contain the time, the address that was requested, the result status and technical error details. Depending on the configuration of the operator's server, an IP address can be part of such a log line.

Cookies — three cookies, all technically necessary. Their names, purpose and lifetimes are listed on the Cookie information page.

4. The recording itself

Your recording is stored in the storage used by the application, decoded, split into short fragments and sent fragment by fragment to the recognition provider. The resulting metadata becomes the playlist described above.

As soon as the analysis reaches a final state — succeeded or failed, including a failure caused by an unexpected error — the content of the recording is deleted from that storage. The record of the submission described in point 3 stays, including its hash, its size and its original filename. Keep your own copy: the recording cannot be downloaded back from the service. This deletion covers the application storage; it does not reach into backups or versioning that the operator of that storage might keep.

5. On what basis the data is processed

• To perform the service you asked for (Article 6(1)(b) GDPR) — the account, the submission and its analysis, the playlists, the library, the Spotify export you trigger and the donation prototype you click. Without this data the service cannot run at all.
• Legitimate interests of the operator (Article 6(1)(f) GDPR) — keeping the service secure and working: technical logs, protection against abuse and attacks, deduplication of submissions so the same content is not analyzed twice, answering the messages sent through the contact form, and defending claims.
• Legal obligations (Article 6(1)(c) GDPR) — only where such an obligation really applies to the operator.

The service relies on the legal bases listed above rather than on consent, because everything it stores is needed to deliver the service you asked for. Accepting the Terms of Use is not a consent to processing, and it is not a consent to receive messages.

6. Who can see your data

• The public — everything published in the public catalog is visible to everyone without signing in: the playlist name, the masked filename of the recording, the first characters of its hash, its type and size, the creation date, and the list of recognized tracks with cover art and preview links. Your login is not shown there.
• You — your library shows the playlists you created or imported, including the private names you gave to imported playlists.
• The recognition provider — the service configured by the operator. It receives short audio fragments of your recording and returns the music metadata.
• Apple — the public iTunes Search API receives the title and artist of a recognized track to look for a thirty-second preview.
• Google as an identity provider — only when you press Continue with Google. Your browser visits Google, which authenticates you and returns identity data to this application: the stable account identifier, the e-mail address and the name. Sign-in asks for the OpenID, e-mail and profile scopes — the profile scope is what supplies that name — and it never grants playlist export permissions or access to Gmail, Drive or contacts.
• Spotify — when you connect an account, the OAuth flow exchanges the tokens described in point 3, and an export creates a playlist in your Spotify account under the permissions you granted. When you open a playlist's Embed page, your browser loads Spotify's own embedded players directly from open.spotify.com, so Spotify sees that request — your IP address and browser details, as with any embedded content.
• PayPal — only when you press the donation button and only if the operator configured a donation link.
• The mail provider — a message sent through the contact form is handed to the SMTP provider configured for this deployment, which delivers it to the operator's mailbox.
• Facebook, X and WhatsApp — only when you press one of the Share icons on a playlist page. The button opens that service's own sharing interface in a new tab with the address of the page you chose to share, so that service sees the request you started yourself.
• Cover and preview hosts — Spotify's and Apple's image and audio delivery networks serve artwork and previews to your browser when you open a playlist page, so those requests come from your device.
• The operator and its technical staff — the Django admin lets staff read accounts, playlists and submissions for support and moderation. Passwords stay hashed, Spotify tokens stay encrypted, and the acceptance history is read-only.
• Hosting and infrastructure — the operator of the server and of the storage keeps the service running and processes data on the operator's behalf. To be completed before a public launch: the name and location of the hosting provider, and where the database and the storage really live.

7. Data leaving the European Economic Area

Some recipients in point 6 are based outside the EEA, and the recognition provider, Apple and Spotify may process a request on servers located in other countries. Where a transfer needs a legal safeguard, it has to rest on an adequacy decision of the European Commission or on the standard contractual clauses of the provider in question.

To be completed before a public launch: which recipients process data outside the EEA, on what legal basis the transfer rests, and where the operator's own data is hosted.

8. How long the data stays

• Content of the source recording — until the analysis of that submission reaches a final state, and then it is deleted (point 4).
• Submission record — kept so that the same content is not analyzed twice and so that playlists stay consistent: the hash, the size, the filename, the status and the error description. Removed together with the playlist or the upload when the operator deletes it, or when you ask for it.
• URL download order — the URL and the download metadata are deleted seven days after the order reaches a final state; only the hash of the address remains, which is what makes a repeated submission return the existing result instead of downloading it again.
• Account, playlists, library and subscriptions — as long as the account exists, and removed or detached as described in point 11.
• External sign-in identities — kept while your local account exists and deleted with that account.
• Spotify tokens — until you disconnect the Spotify account or delete the account here.
• Acceptance of the Terms of Use — kept while the account exists, because it is the record of what was accepted; removed with the account.
• Contact messages — not stored in the application at all. The message lives in the operator's mailbox, and how long it stays there follows the rules of that mailbox.
• Session cookie — 30 minutes without a request; every request moves the window. The CSRF cookie lasts one year, the message cookie until the browser window is closed.
• Technical logs — To be completed before a public launch: the retention period of the server and worker logs, which the operator sets outside this application.
• Backups — To be completed before a public launch: whether backups exist, how long they are kept and how a deletion request is honoured inside them.

9. Cookies and similar technologies

The service sets only technically necessary cookies. Names, purposes, lifetimes and the requests your browser may make to other domains are listed on the Cookie information page.

10. The optional e-mail address and notices

An e-mail address is optional and is stored as contact data for your account. If a future feature sends account notices — for instance a message that helps recover an account, or a notice about the service — this policy will name it and the address will be used for those notices.

11. Your rights

Under the GDPR you can ask for access to your data and a copy of it, for correction of anything inaccurate, for deletion, for restriction of processing, and you can object to processing based on legitimate interests. You can also ask for data you provided in a portable form. Write to the operator and describe what you need; the operator answers within the time the GDPR allows.

To delete everything, ask for the account to be deleted. Deletion is done by the operator; say at the same time whether the playlists and the submission records created through the account should go as well, because they are detached from the account rather than deleted automatically. The account page lets you add, change or clear the optional e-mail address yourself at any time.

If you believe your data is processed unlawfully, you can complain to a supervisory authority — the one in your country of residence, place of work or where the issue occurred. To be completed before a public launch: the authority competent for the operator, once the operator is named.

12. Security

Passwords are stored as a password hash. Spotify tokens and a client secret configured by a user are stored encrypted with a key taken from the deployment environment. Access to the admin is limited to staff accounts, and the terms acceptance history is read-only. Sessions are removed from the browser after 30 minutes without a request.

If you find a security problem, report it to the operator instead of publishing it. A public production deployment must use HTTPS and its own secret key, and the operator should keep the dependencies up to date.

13. Changes to this policy

This policy changes together with the service: a new integration, a new field, a different retention period. The current identifier is shown at the top of this page. A version that changes what is done with your data is published here before that change reaches a public deployment.

14. Contact, and what still has to be completed

Questions about this policy, requests about your data and security reports all go to the operator of the service.

Points marked To be completed before a public launch are deliberately visible instead of being filled with guesses: the hosting location, the international transfers, the log retention and the backup regime. Until they are filled in, this document describes the application faithfully but is not ready to be published as a final privacy policy.