Privacy

This is the English version of Aviso de privacidad, which is the authoritative text.

There are no accounts

Reading this site does not require registering, and there is no way to sign in as a reader. No data is asked of you: not your name, not your email, and there is no newsletter, no comments and no advertising. Reading asks nothing of you, and voting for a favourite, below, asks you for no data either.

A view counter

Every story shows how many times it has been viewed. To count one view per browser rather than one per reload, the site stores a first-party cookie in your browser, observatorium_view_receipt, that lasts one year. It holds only a random identifier: it carries no name and no other data of yours, and no third party reads it.

The first time you open a story, the site creates that cookie and, once your browser has stored it, counts the view: the site’s server sends the story and the identifier to Observatorium’s platform. The platform does not keep the identifier: it keeps an encrypted fingerprint of it (an HMAC with a secret key), alongside the story, for 24 hours, and then deletes it. That way, the same browser counts only one view per story every 24 hours. The counter keeps no IP address and no location.

Voting for a favourite

In the directory’s electoral contests you can name your favourite candidacy. Voting is optional and asks for no data: no name, no email, no account. If you never vote, none of what follows reaches your browser.

The voting token. The first time you vote, the site stores a first-party cookie in your browser, observatorium_vote_token, that lasts one year. It holds only a random identifier, created for voting and nothing else: it is not the view-counter cookie, it is not derived from it, and it is never stored beside anything about what you read. Your browser sends it only to the voting address (/api/interactions/votes), never when it asks for a page. If your browser does not keep it, you cannot vote: without it the site cannot count your vote once, and it tells you so.

The verification task. So that a vote costs a person one tap and a program voting in bulk real work, every vote carries the answer to a computational task your browser solves before sending it. The site itself issues and checks the task; no third party takes part.

What a vote processes. A vote request carries only the contest, the candidacy, the token and the task’s answer and, if earlier votes of yours could not be recorded, how many. The site’s server reads neither your IP address nor any trait of your device, and passes neither to Observatorium’s platform.

What a vote keeps. The platform keeps, for each vote, the contest, the candidacy, an encrypted fingerprint of the token and the time, and nothing else. The fingerprint is an HMAC with a secret key of the vote’s own, different from the view counter’s, so no vote can be matched to what you read; and it is computed per election, so deleting an election’s votes leaves nothing that ties that election to your token. With it, a second vote from the same browser replaces the first, and you can withdraw it. To bound how many times a choice changes in one day, the platform also keeps, for that day only, the count of changes that fingerprint made in that contest; it deletes it when the day ends.

For how long. An election’s votes, and every association between a fingerprint and them, are deleted on the date the newsroom sets for that election before it accepts the first vote. That date is shown beside the vote. Only the counts remain.

Who else sees it. No third party sees your vote or its task. The one exception is the handling every request to the site receives from the services that host it: Cloudflare, whose network carries every request to this site, the vote included, with your connection’s network address, like any request on the internet; and Hetzner, which hosts the platform’s server where the vote is stored. Observatorium neither reads nor keeps that address.

Apart from the view counter and the vote for a favourite, there is no other measurement: no other cookie, no third-party tag, no audience analytics.

What is stored in your browser

• The view-counter cookie, above.
• If you vote, the voting-token cookie, above, and your own choice in each contest (which candidacy, and when), under the key observatorium_favoritos_v1 in your browser’s local storage. It exists only to show you your choice when you come back: it is sent nowhere.
• If a vote could not be recorded because voting was unavailable, how many, up to 20, under the key observatorium_favoritos_sin_registrar_v1. That number is sent with your next vote, so the newsroom knows how many votes failed, and goes back to zero.
• The theme you pick at the foot of the page, if you pick one different from your device’s, under the key tema. If you choose no theme, none is stored.

What is in local storage never leaves your machine except as stated, and you can remove all of it by clearing the site’s data.

Third-party requests

Clip thumbnails load from YouTube’s image servers, so opening an entry that has clips makes a request to that domain. The video player does not load until you press a clip: until then there is no embedded player on the page at all. When you press one it opens in YouTube’s no-cookie mode.

The original videos

Every clip links to the exact second of the original broadcast. Following that link takes you off this site, and the terms of the platform hosting the video apply.

The publishing client

The software that uploads clips to YouTube, TikTok and the Facebook Page is a scheduled task on a single desktop machine. It has no user interface, no login screen and no hosted service. It has no third-party users and never has had: it authenticates as the operator, and uploads only to accounts the project owns.

It holds OAuth refresh tokens for the authorized delivery paths, granted in a browser by the operator and stored in an environment variable on that one machine. Tokens are sent only to the relevant platform, appear in no log and are in no repository. Each can be revoked by the operator at any time from that platform’s own account settings, which stops the uploads immediately.

What it stores is the material it works on: source broadcast URLs, transcripts, the rendered clip files, and the video or post identifier each platform returns. None of it is personal data about a reader, because the client never touches a reader.

The editorial desk and TikTok

The editorial desk is an internal Observatorium tool, separate from the reader site. An authorized operator may connect an account they manage through TikTok. Draft delivery uses video.upload; Direct Post requires a separate grant with video.publish. Connecting an account neither publishes a video nor establishes TikTok approval.

Direct Post preparation reads the account identity, available privacy choices, interaction restrictions and duration limit. Authorization credentials stay on the host. The video process retains the account, selected file, exact caption and consented options, consenting operator and time, and the remote posting identifier and status. These records remain while the process is retained; closing the browser does not delete them. The integration does not request private messages or contacts.

Credentials are used only to communicate with TikTok and are never given to readers. For server-held media, TikTok can read the selected file through a signed link that expires after one hour. Disconnecting in the desk removes its local Direct Post authorization. Access can also be revoked in TikTok account settings. Neither action deletes existing posts or the process records. To request deletion of retained data, use the contact page. TikTok describes its own processing in its privacy policy.

YouTube API Services

The publishing client uploads through YouTube API Services. By using it — which in practice means me, the operator, since it has no other users — you agree to be bound by the YouTube Terms of Service. Google’s handling of any data it receives is governed by the Google Privacy Policy.

What the client accesses and stores. It holds one OAuth refresh token for the channel it uploads to, in an environment variable on one machine. From the API it receives, and keeps, the video identifier of each clip it uploads. It requests only the upload scope, so it cannot read the channel’s videos, subscribers, comments, watch history or analytics, and it collects no information about any viewer or any other YouTube user.

How to revoke it. Access can be withdrawn at any time from Google’s security settings page. Revoking stops all uploads immediately, and any data held under that authorisation is deleted within 30 days.

Retention and deletion. Authorised data obtained from the API is deleted or refreshed within 30 days, except the identifier of a video the client itself uploaded, which is kept for as long as that video is embedded on this site — it is the address the page loads the video from, and discarding it would break the link between a published page and the clip it shows. A request to delete stored data is honoured within 7 days.

Contact

Questions or complaints about any of this, and requests to delete stored data, go to the contact page.