Privacy policy

Two kinds of information are involved, and they are treated differently. Your media — the video you convert — is handled as described in section 02: for file delivery it is fetched from storage you control, processed, written back to storage you control, and not kept afterwards. Section 02 also states the cases where a working file can survive a job anyway, and the retention of hosted output and demonstration uploads; they are real, and they are not buried. Your account data — the address you sign up with, your keys, your jobs and your usage — and any contact request or meeting you submit are stored in silken's database, and nothing removes them on a schedule, as section 06 explains.

silken is operated by Velvet Software Limited, of Dublin, Ireland, company registration number 633270. Every reference to "silken", "we" and "us" in this document is a reference to that company. How to reach it is section 11.

Its role depends on the data. For your account, billing and contact data, and for visitors to the website, silken is the controller: it decides why and how that data is used, and this policy is the notice that explains it. For your media and the job data that comes with it — the video you submit, the converted output, the job record, the URLs you sign and the webhook payloads — silken is a processor, acting on your instructions, which are the API calls you make and the settings you choose. You are the controller of that data, or its processor if you act for your own customer. The data processing agreement governs that processing and forms part of the terms. Section 09 sets out the roles purpose by purpose.

The operational records behind these

The table above is the shape of a customer record. Running the service also writes records that are about the service rather than about you, but which are keyed to your account and are therefore still your data:

• Account security. Hashes of email-verification and password-reset tokens with their creation, expiry and use times, and whether your address is verified.
• Billing state. Your payment-provider customer and subscription identifiers, the history of your entitlement as the provider reported it, the billing destination your usage is reported to and its versions, and one record per usage event we sent — its value, its attempts, its errors and the provider's response identifier.
• AWS Marketplace, if you subscribed there: your AWS account identifier, the licence and product references, a hash of the registration token that was redeemed, and the per-hour usage totals reported for you.
• Accounting. Comparisons between our ledger and the provider's, any corrections applied, and which operator applied one, for what reason, against what figures.
• Operational budgets. Idempotency keys and the stored response for a replayed request; your quota, rate and admission counters; spend reservations; source-inspection reservations and daily inspected-byte totals.
• Onboarding. Hashes of the sample's object and download tokens with their expiry, and the replay keys for the sample request.
• Service events. Operational events, metric rollups and records of alerts sent, which name a job or a customer where the event was about one.

This is not a column-by-column listing of every table, and it should not be read as claiming to be one. What it does claim is that no category of information is being withheld from this document: if silken holds something about you that does not fit one of the descriptions above or in the table, that is an omission worth reporting to us, not a distinction we are drawing.

Presigned URLs, stated precisely

The URLs you submit with a job are stored on the job record. Three things about them are worth stating exactly:

• They are retained. The signature in them expires on whatever schedule you set when you signed it, but the text of the URL stays in our database with the job.
• They are not fields on any API response. The job object silken returns has no source or destination URL in it.
• Error messages have the credentials removed. When a transfer fails, the error recorded on the job is the underlying transport or storage error, which can quote the URL the request was made to and a short excerpt of the response your storage returned. Before that error is logged, stored on the job or sent in a webhook, silken removes the credentials from it: in every URL it quotes, the query string (where a presigned URL carries its signature) is replaced with a marker and any user name and password are dropped, and signature, credential and token parameters elsewhere in the text have their values replaced. The redacted error is what the dashboard shows, the job API returns and the webhook for a failed job includes.

Contact requests and meetings

When you send a contact request, we store your name, work email, company, workflow requirements, optional message, submission time and notification status so our team can respond. When you book a meeting, we also store the selected time, timezones, optional role and team size, booking and cancellation status, notification results, and a hash of the token used to manage the booking. Contact and meeting records are retained until an operator removes them; cancelling a meeting changes its status and does not erase its record. To ask about access, correction or deletion, contact support@silken.io.

What an account does not collect

An account record has no field for a name, a company, a postal address, a phone number, a country, a tax identifier or a marketing preference; the details above are stored only with a contact request or a meeting. There is no analytics, no advertising identifier and no behavioural profiling, and we perform no geolocation of any kind.

Marketing. We do not sell personal data, we do not disclose it to anyone for their own marketing, and we run no third-party advertising or social-media tracker on any silken page.

There is no marketing mail: the messages the service sends are the service email described in section 03 of the terms, which it separates from marketing expressly.

Consent to marketing is never a condition of holding an account or being issued a key, and no such consent is asked for or recorded anywhere.

IP addresses. We do not store one in any column. What is stored is a SHA-256 hash of the address, used as an abuse counter. That cannot be reversed by computation, but it is not anonymous either: the hash is unsalted, so anyone holding it and a candidate address can confirm a match by hashing the candidate. We treat it as personal data rather than as an anonymised value, and this document says so rather than calling it irreversible.

Automated decisions. Some decisions about your account are taken by software with no person involved: whether your subscription entitles you to submit a job, whether a payment failure has run past its grace period, whether a payment dispute suspends the account, and whether you have reached a rate, quota or spend limit. They follow the published rules in the terms and act on your access to the service rather than profiling you. See section 11 for how to put any of them to a person. These checks enforce the contract and the limits you have set; they are not profiling, and they do not decide anything about you beyond whether a job is accepted.

silken does not take card details, and stores none. Payment details are entered on our payment provider's own hosted pages. silken's own forms never ask for a card number, expiry or security code, and there is no column anywhere in the database for a card number, an expiry or the last four digits.

It would be wrong, though, to say no card data ever reaches our machines. When a payment is disputed, silken asks the provider which customer the disputed charge belongs to, and the provider's answer is the whole charge record — which can include the card's brand, its last four digits and its expiry. silken reads the customer identifier out of that answer and keeps nothing else: the rest is discarded with the response and never written down. The distinction between "we never receive it" and "we receive it, read one field, and store none of it" matters, and this document states the second because it is the true one.

We do not sell personal data, and we do not share it for advertising. silken's code contains no analytics provider, no error-reporting service and no third-party log shipper: what it writes, it writes to the machines that run the service.

What those logs contain. Every API request logs its request id, method, path, response status and how long it took — and a path can name a job or a customer. The worker logs job ids and the errors it hits, and a failed conversion can carry up to two thousand characters of the converter's own output with it. These are ordinary server logs on silken's machines rather than a product feature; nothing expires them, and section 06 says so rather than implying a retention period that does not exist.

Where the service runs

The table above lists what silken's code sends out. The service also runs on rented servers, and those hosts see the data the service handles.

• The API and dashboard (the gateway, which holds the account database) run on a server hosted by Hetzner Online GmbH in Falkenstein, Germany.
• The conversion workers, which fetch your source, convert it and deliver the result, run on dedicated servers in the Netherlands, hosted by RedSwitches and by Leaseweb Netherlands B.V.
• Service email is sent through Amazon Simple Email Service in the EU (Ireland) region, operated by Amazon Web Services EMEA SARL.
• Payments are processed by Stripe, which holds card details and invoices; see the table above.

Your media is processed on the workers in the Netherlands. Output you ask silken to host is kept on silken's own storage, in the locations above, all within the European Economic Area. Your own storage stays wherever you put it. The sub-processors page gives the same list with the purpose and location of each provider and says how we tell you before it changes.

• Passwords are stored as Argon2id hashes — 64 MiB of memory, three passes — and compared in constant time. A minimum length of 12 bytes is enforced, with an upper bound of 1,024. That is 12 characters of ordinary Latin text, and fewer where a character encodes to more than one byte.
• API keys are stored as SHA-256 hashes. The secret is displayed once. You can list, revoke and rotate keys from the dashboard, and rotation gives the old key a grace period so a running integration is not cut off mid-deployment.
• Sessions last 24 hours from sign-in by default and cannot be extended. The API lists your active sessions and revokes any one of them, or every one but the current, and these are reached through the API — see section 08 for what is reachable from where. Changing your password signs out every other session and issues the current browser a fresh one; completing a password reset signs out all of them, including the one that requested it.
• Sign-in attempts are limited to five in fifteen minutes, counted against both the address and the connecting network address, which then must wait. Both are stored only as hashes.
• Webhooks are signed with HMAC-SHA256 and are refused rather than sent unsigned if no secret is configured. Delivery destinations are checked against private and reserved address ranges both before connecting and at connection time, so a DNS answer cannot redirect a delivery into an internal network.
• Mail is encrypted where the receiving server offers encryption, and any TLS silken negotiates is TLS 1.2 or better. This is not an absolute guarantee, and we would rather say so: by default silken uses opportunistic STARTTLS, so a configured mail server that offers no encryption is sent the message unencrypted. An operator can require encryption instead — a mail server configured as smtps://, or with STARTTLS marked required — and silken then refuses to deliver rather than fall back. Credentials are never sent to a remote server over an unencrypted connection under any configuration.

Email and password, plus API keys, are the credentials used today. Security reports, questionnaires and requests for our security documentation go to the security address on the contact page.

One thing that section settles rather than leaves open. Section 11 of the terms limits silken's liability to you, and it expressly does not limit compensation under Article 82 of the GDPR for material or non-material damage caused by processing that infringes it. That right is not affected by anything in either document.

Roles and lawful basis

International transfers

Your media and account data are processed in the European Economic Area: Germany for the gateway and the account database, the Netherlands for the conversion workers, and Ireland for service email. Access from a country the European Commission has found to provide adequate protection, which includes Israel, needs no additional safeguard. Where a provider outside the EEA, including Stripe and its affiliates in the United States, receives personal data, the transfer rests on the European Commission's adequacy decision for the EU-US Data Privacy Framework where that framework covers the recipient, and otherwise on the Standard Contractual Clauses the provider has incorporated into its terms. If you need a copy of the clauses, or a transfer assessment, ask at the address in section 11. Where a customer is established in the United Kingdom, the UK addendum to those clauses applies in the same way.

Your rights, breaches and complaints

You have the right to access your personal data, to have it corrected or erased, to restrict or object to its use, and to receive it in a portable form. Write to the address in section 11; we answer within one month, and may ask you to confirm who you are. If we process your media as your processor and a data subject writes to us about it, we pass the request to you and help you answer it, as the data processing agreement sets out.

If personal data we hold is lost, altered or disclosed without authority, we tell the affected controller, and the Data Protection Commission where we are the controller, as the law requires. For data we process on your behalf the data processing agreement commits us to tell you within 72 hours of becoming aware of it.

You may complain to the Irish Data Protection Commission, or to the supervisory authority where you live or work. We do not sell personal data, and we do not use it for automated decisions with legal effect on you other than the entitlement checks described in section 03. Using the service for media that contains other people's personal data is your responsibility as controller, and the terms and the acceptable use policy apply.

Nothing in this section limits any right you already have by law. If you want to exercise one, see section 11.

Questions about this policy and requests concerning your data go to support@silken.io. Reports of a security problem go to support@silken.io.

The company accountable under this policy is Velvet Software Limited, registered in Dublin, Ireland under company registration number 633270. Section 01 identifies it in the same words at the top of this policy.

Its registered office is 29 Earlsfort Terrace, Dublin 2, D02 AY28, Ireland, which is where a written request or a complaint about this policy can be sent if you would rather not email one.

The agreement that company is a party to, and the law governing it, are the terms.

If you email us about support, billing, privacy, security, abuse or copyright, we receive the message, its attachments and the contact details you include to assess and answer your request. A copyright notice or counter-notice may be shared with the affected account holder, as the copyright policy describes. This correspondence is handled by our team and our email providers.