Privacy notice

Last updated: 14 September 2026.

This notice is available in multiple languages. In the event of any discrepancy between versions, the Hungarian-language version shall prevail.

1. Who controls the data

StreamRadar is currently a service under development and has not yet launched in production.

Contact address for data protection requests: info@streamradar.info.

2. What we store about you, by category

There are fifteen categories. You can download the exact, machine-readable content at any time on the My data page, which lists the same fifteen categories. If a category is empty for you, we say so explicitly, because an empty category is not the same as an omitted one.

2.1 Your account

• Your e-mail address. It identifies you, you sign in with it, and it is where mail goes once we switch that on.
• Your name, if you gave one. It is optional; the account works without it too.
• A one-way hash of your password. The password itself never exists with us in readable form: we do not store it, do not log it, and cannot decrypt it. If you forget it, we cannot tell you what it was, only set a new one.
• When you registered, and when you last signed in.
• Your decision on cookie-based advertising, and the time you made it.
• If you are an administrator, or if we made your account free, that fact and its reason.

2.2 Your household

The subscription is paid by one person, for a household of up to five. For the household we store its name (typically whatever the payer gave it), when it was created, and the subscription status. The trial length counts from when the household was created.

Everyone has their own e-mail address and their own password. There is no shared password and no profile picker: a household is just a grouping, not a shared account. No member of a household sees another member's ratings, keywords, or watched titles individually.

2.3 Invitations

If you invite someone to your household, we store that person's e-mail address, even if they never end up with an account with us. Alongside it we store who sent the invitation, when, how long it is valid, and whether it was accepted or withdrawn.

We do not store the invitation token itself, only its hash. So a database dump is not a pile of usable invitation links.

2.4 Taste data: what you like and what you do not

This is the most sensitive group, which is why we name it separately:

• Watched titles: which releases you flagged.
• Preferences: which platforms and genres you chose, whether you want films or series, and whether you asked for Hungarian-language titles to be ranked first.
• Ratings: how many points you gave each title, on a scale from minus two to plus two.
• Favourites: which titles you marked.
• Keywords: the terms you typed in your own words that we watch for. You write these as free text, so we store exactly what you typed.
• Reminders: the time you set and the note you attached to it.

Together, these six items show what interests you. That is why deletion and download are described in a place reachable even without an account, and why we do not give any of them to a third party.

2.5 Notification settings and sent notifications

We store whether you want mail, which sections you want in it, and how many days before a release we should notify you. We also store what we already told you about: which title, in which section, when. Without the latter, tomorrow's daily mail would say the same thing again.

2.6 Security data

• Password reset: if you request one, we store the time of the request, its expiry, and whether it was used. The token itself is not stored in the table here either, only its hash. This is the one place where we store the requesting IP address in raw form, for tracing purposes only: it plays no part in the reset's validity, so a link opened on mobile still works.
• Failed sign-in attempts: we do not store the entered address or the IP address raw, only their hashes, and only so we can stop password guessing. Hashing the IP address is weak protection, because the space of possible addresses can be brute-forced, so we do not claim it is more than what it is: hygiene, not encryption.

2.7 Outgoing mail

The mail prepared for you is placed in a queue row together with the recipient and its full text before it is sent. This is so because it is not the web page that sends the mail, but a separate process: otherwise response time could reveal whether a given e-mail address exists with us. The mail stays in the queue until it is sent; afterwards its text is deleted, and only the fact and time of sending remain.

3. Why we store it

• So you can sign in: e-mail address and password hash. Without these there is no account.
• So we can show you what interests you: preferences, ratings, favourites, watched titles, keywords. This is the reason the service exists.
• So we can notify you: notification settings, reminders, and what we already told you about.
• So the household works: the household record and the invitations.
• So your account cannot be broken into: the failed-sign-in counter and the password-reset record.

There is no data we collect on the chance that it might be useful someday. If a column does not serve one of the five purposes above, it is not there.

4. How long we keep it

Wherever the code has an expiry, it is stated here too:

Data	How long
Invitation link	7 days, unusable afterwards
Password-reset link	60 minutes, usable once
Failed sign-in attempt	counts for 15 minutes, deleted after 60 minutes at the latest
Consent for cookie-based advertising	1 year, then we ask again
Watching for a later language notification	90 days from the release date
Sign-in cookie	until the browser is closed

Everything else stays until you delete it. There is no automatism that removes your account or your ratings after a year. The row for an expired invitation or a used reset link remains, but invalid: we keep it so that any misuse leaves a trace.

See the deletion details in section 8.

5. Who we pass it on to

Today, outbound requests go to two places, and neither of them receives anything about you personally:

• The source of release data (a streaming-availability service via RapidAPI), once a day, from our server. The request asks about the Hungarian catalogue, not about you: it contains no user ID, e-mail address, IP address, or preference.
• The source of cover images, also from our server, in the same daily run.

Importantly, these two requests are started by our server, not by your browser. We download the cover images and serve them ourselves, precisely so your IP address never reaches the image provider just because you opened the home page. This was not always the case; a single page load used to trigger 99 outside requests.

Until you click something, the page contacts no one. On a title page a single outbound link is visible, the IMDb reference. If you click it, from that point their site sees you, and their rules apply.

What does not exist today

We list these because the groundwork for them already exists, and we do not want you to read a future state as the present one:

• Payment: Stripe. Stripe collects the card details on its own page, and it is Stripe that stores them: the card number never enters our system, so it cannot leak from us. All we keep is an identifier, the card's last four digits, and its expiry, so you can tell which card is which.
• Third-party advertising: not connected. We have no advertising account. The ad slot exists in the interface, and so does the consent gate, but until you consent, the address of the code to load is not even included in the server's response. We do not hide it -- we never create it, so there is nothing to load.
• Invoicing: Szamlify. We issue an invoice for the subscription fee, and for that we pass your billing details (name or company name, address, and tax number if provided) to the invoicing service. We ask you for this data before payment, and you can change it at any time on the My subscription page. A change affects the next invoice, not ones already issued: by law, an issued invoice cannot be rewritten, only cancelled and reissued.
• Sending mail: Amazon SES. We send mail through a mail-relay service, so the recipient's e-mail address and the mail's text pass through it. You only receive mail if you asked for it.

When any of these go live, this notice changes before they do.

6. Cookies

We use two cookies, both our own; no third party sees either of them:

Cookie	What it is for	How long it lives
Sign-in cookie	This keeps you signed in. It cannot be read from JavaScript, only travels over an encrypted channel, and is not sent with a request started from a foreign site.	until the browser is closed
Consent cookie	This stores what you answered about cookie-based advertising. You can decide even without an account, which is why a cookie is needed for it.	1 year

The consent cookie itself does not require consent. This is not a loophole: it is the technical operation without which your decision would not exist. If this too required consent, the "I do not accept" button could not remember itself.

If you decide while signed in, we also attach your decision to your account, so it applies on other devices too. In a conflict, the decision on your account wins, because you made it deliberately, while signed in. You can change the decision at any time on the Account page.

As a subscriber, we show no advertising at all, neither ours nor a third party's.

7. Logs

The server writes logs, because otherwise we could not tell what happened when something goes wrong. What the log may contain:

• The error's class, its message, and which line of code it arose in.
• The fact that an invitation was created, with a masked e-mail address, and the first eight characters of the invitation token. The log never writes the full address.
• The figures from the daily catalogue import. These contain no personal data.

The request body is never written to a log. This matters because the password is in the body of the sign-in and registration requests: no code path writes that out.

8. Your rights, and where to exercise them

Two rights already work today, at the push of a button, and both apply to any registered account, not only a paying one. Without a subscription, and with an expired trial too.

Access to your data

On the My data page you can download everything we store about you. In two formats: a machine-readable JSON file, and a human-readable page you can open in a browser. Both contain the same fifteen categories.

Two things we do not hand out: the hash of your password and the hashes of your tokens. These would give you nothing, but in a leaked file they would be an attack surface.

Closing your account

You can close your account in the same place. The action is irreversible, so confirming it requires typing in your account's e-mail address and your password.

Before starting the deletion, the interface tells you exactly how many rows it will remove, and what stays behind. Today we keep nothing, because there is no invoicing yet, so there is no document accounting rules would require us to retain. Once payment goes live, we will have to keep issued invoices even after deletion, and the interface will state that too, before you delete.

If you are the household's payer, and others are in it too: we do not delete their accounts or their data. The household stays, but without a payer, so until there is a new payer, no one can invite a new member. Before deletion, the interface shows by name who is affected. If you are alone in the household, the household ends together with you.

Correction

9. What we do not do

• We do not sell and do not rent out your data.
• We do not build a profile for advertising purposes. We use your taste data exclusively to show you a better recommendation on our own interface.
• We do not put tracking code on the page. No visitor analytics, no pixel tracker, no fonts loaded from an outside source.
• We do not play content, and we do not store what you watched. We could not even if we wanted to: we have no connection to the platforms through your account.
• We do not send mail without a subscription, and we do not send empty mail. If we have nothing to say on a given day, we do not write that day.

10. If this text changes

The update date always appears at the top of the page. If a change comes that materially modifies any of the above -- for example payment, invoicing, or third-party advertising going live -- we do not do it quietly: the notice changes before the actual operation does.