Privacy Policy

The entries EDM Hub keeps in your browser are listed in the section "What We Keep in Your Browser" right below. When you sign up, sign in, stay signed in, sign out, change your account, reset your password or confirm your second factor, the sign-in service records your IP address together with your account in a security log. With your session it stores your IP address and your browser's identification (user agent). When someone invites you to a page on EDM Hub by e-mail, we store your e-mail address with the invitation and, for an invitation to join as a member, the name and role the person who invited you entered for you. When someone asks to remove their name from a page on EDM Hub (no account needed), they give an e-mail address; we send one link to it and do not store the address itself, only a fingerprint of it (a hash), to limit requests. With the request we store the name as it stood, the page, the reason if one was given, and the dates.

In your browser's local storage (localStorage): dnb-language, the language the site was last shown in, so that the site opens in it again; dnb-language-account, the ID of the account signed in here, so that its saved language is applied once in this browser, removed when you sign out; dnb-consent-status, whether you accepted or declined the consent banner; dnb-embed-platforms, the platforms for embedded content (such as YouTube or SoundCloud) you allowed or blocked, in the consent banner, in the settings, in the onboarding or on an embed itself; dnb_theme, the colour theme the site is shown in, the default one until you choose another; sb-…-auth-token, your sign-in session while you are signed in (the middle part comes from the site's address: on www.edm-hub.net the entry is sb-www-auth-token); dnb_last_login_method and dnb_last_login_email, how you last signed in and with which e-mail address, so the sign-in dialog can suggest it, both removed when you sign out; dnb.browserPush.owner, the ID of the account that turned on push in this browser, removed when push is turned off in this browser, when you sign out or your session here ends in another way, and when another account signs in here; dnb.widget-draft.… (one entry per page), the widgets of a page while you edit it, so that the preview window shows your unsaved changes, removed when you end editing, or else the next time you open that page; dnb.booking-offer.asked.… (one entry per profile or event; the name ends in the ID of that entry), that the offer of the advertising package has been shown for that entry in this browser, so that it is offered once only; dnb.booking-offer.snoozed.… (one entry per profile or event; the name ends in the ID of that entry), the time until which you chose "Not now" for the offer on that entry, so that the offer stays hidden for a month, removed at your first visit after that time has passed and when you sign out; neither of these two holds personal data (an entry ID and a time); the first stays until you clear your browser's data. Personal data among these entries: the e-mail address in dnb_last_login_email, the ID of your account in dnb-language-account and dnb.browserPush.owner, and your session in sb-…-auth-token, which holds your sign-in tokens and your account's details as the sign-in service keeps them: e-mail address, ID, what you entered when you signed up and, after a sign-in through Google, Facebook, Apple or Spotify, what that service passes on, such as your name and picture.

In your browser's session storage (sessionStorage), which is emptied when you close the tab: dnb_return_url, the page to return to after signing in with a provider or an e-mail link, removed once used; dnb.invite.token, the invitation you opened, kept while you sign in to accept it, removed once the invitation is used or closed; dnb.reload-after-deploy, the path of the page you were opening (without query or fragment) when a new version of the site had replaced part of the one loaded in your tab, and the time the page in your tab was loaded, so that the page is loaded afresh only once, replaced when another page fails the same way, removed once that page has loaded or when it fails again after its reload; dnb.booking-offer.extending.… (one entry per profile or event; the name ends in the ID of that entry), the end of the featured time of that entry when you go to the payment page to extend it, so that the page you come back to can say what became of the payment, replaced or removed when you next go to the payment page for that entry; it holds no personal data (an entry ID and a date). The invitation token is personal data: it belongs to an invitation sent to your e-mail address.

One cookie: dnb_theme, the same colour theme as the localStorage entry of that name, so that the page opens in it before it has fully loaded; it is renewed at every visit and expires one year after the last one.

In a web browser (not in the native app) the site registers a service worker, push-worker.js. It only receives and shows the notifications you turned on; it keeps no data of its own and no copies of pages. The push subscription itself is described under "Browser push".

The entries in your browser serve only the purposes named with each of them above. The security log and the session data protect accounts against abuse (limiting requests, tracing misuse). The address of an invitation is used to send it and to let only that address accept it. The fingerprint of an address limits how often requests can be made for it. The record of a confirmed removal lets the platform's administrators act if the name is added to the page again unasked; only they can see it, not the page's team.

When you first sign in, we ask for your city, your year of birth and your gender (female, male, diverse or prefer not to say). We store the city as a place from our place search, and the year without a day or month. You can change all three in the settings. Nobody else sees them — not other users, not the owners of pages — and they appear on no public page.

We use the city to suggest a region filter in the onboarding; a filter is created only when you confirm it. We collect the three values for anonymous statistics: the owners of a page see how their followers divide into age groups, genders and federal states with their cities — only as counts, never as a list of people: a city, an age group or a gender is named only when at least five people share it, smaller groups are counted under a neutral heading, and only pages with at least 20 followers who are counted get the statistic at all. For accounts under 16 the values enter no statistic until the account is 16.

The suggestion of a region filter is part of the service you use (Art. 6(1)(b) GDPR). The statistics rest on our legitimate interest, and that of the page owners, in knowing their audience as anonymous numbers (Art. 6(1)(f) GDPR). You can object at any time: the switch "My data may be counted in anonymous statistics" in the settings takes your account out of every statistic; a page's follower count is unaffected. The values stay with your account, are part of your data export and are deleted with your account.

When you follow an artist, a venue, a crew, an event series, an event or a region, we store that your account follows it and since when. The owner of a page, its admins and moderators, and the platform's administrators see on its statistics page how many people follow it now and on which weekday and in which hour (Europe/Berlin time) each of them started following — never who follows; for a region, only the platform's administrators can see this. When you unfollow, we delete the entry and you are no longer counted; it is also deleted together with your account.

The platform's administrators see every account in the admin area: its name, e-mail address and profile picture, its role, whether it is banned, when it was created, how many events it created in the last seven days, and whether its limit on new events is lifted and since when. They find an account by its name or e-mail address. They use this for moderation and to hand a page without an owner to an account.

When you write to an artist, a venue, a crew, an event series or an event, or ask the owner of an event to hand it over to you (a takeover request), we keep the conversation: which page it is with; each decision on your request (accepted or declined, and whether the page blocked further requests from you), who made it and when; every message with its text, who wrote it and when; and for each person in it when they last read it, which only shows them what is unread for them. It is read by you, by the page's owner and, if the page included its team when you first wrote, by its admins and moderators; a takeover request only by you and the event's owner, and an owner who hands the event over to you keeps reading it. Who that is follows the page's current owner and team: a new owner or a new member of the team reads the earlier messages too, and whoever leaves the team no longer does. Notifications about a conversation by e-mail or push never contain a message or a name. A conversation is kept as long as the page exists and is deleted with it; an event that is deleted is only marked as deleted, so its conversations stay and the same people read them. When you delete a message, we delete its text, and the others see it as deleted. When you delete your account, we delete the text of every message you wrote; the other side keeps the conversation: your messages are shown as deleted, and neither they nor the decisions you made show your name.

Anyone in a conversation can report a message someone else wrote in it. The platform's administrators read a conversation only while a report on one of its messages is open: then they see the whole conversation, without being able to write in it — who wrote to which page, every message with who wrote it and when, a message hidden after a report with its text, and a message its author deleted only as deleted. They use this to decide the report; once no report on the conversation's messages is open, they no longer read it. On the report itself they keep seeing, also after their decision, who wrote to which page, who wrote the reported message and its beginning, at most 280 characters: the text until it is deleted, the names until their accounts are deleted. A message hidden after a report is shown to the people in the conversation as removed by moderation; its text is kept: in the app only the administrators read it, as described above, and its author gets it with their data export.

When you report an artist, a venue, a crew, an event series, an event or a message, we keep with the report: your account as the one who sent it, what you reported, the reason you chose, the additional details you wrote, if any, its status (open, reviewed or dismissed), when you sent it and, once the platform's administrators have decided on it, when and which of them. Only the platform's administrators can read reports; they use them to decide whether what was reported is hidden. Neither the page's owner and team nor the author of the message can read them. As soon as 10 different accounts have an open report on the same page or message, it is hidden, and an administrator then decides whether it stays hidden. A report is kept, decided or not, without a time limit, until what it reports is deleted. A report on a page is deleted with the page; an event that is deleted is only marked as deleted, so the reports on it stay. A report on a message is deleted with the message, which happens only with its conversation, and so with the page; when its author deletes the message or their account, the message stays, marked as deleted, and the report stays too. When you delete your account, your reports stay without it: they no longer say who sent them and keep everything else, your additional details included. In the same way, a report no longer says which administrator decided on it once that administrator's account is deleted.

Entries in your browser stay until they are removed as described above or you clear your browser data; those in sessionStorage go when the tab is closed. Entries in the security log and second-factor challenges are deleted after 30 days; the IP address and browser identification of sessions older than 30 days are cleared. Error reports are deleted after 30 days, the summary of an error 37 days after its last report. An invitation that was not accepted is deleted 30 days after it expired, was withdrawn or you opted out through its link, together with your address and any name and role entered for you; an accepted invitation is deleted with your account. When you opt out of invitations, we also keep a fingerprint of your address (a hash), for good, so that nobody can invite you again. A request that was not confirmed is deleted at the latest two days after its link expired (the link is valid for 72 hours). The fingerprint of the address is deleted after 24 hours, at the latest the following night. A confirmed removal is kept for as long as the page exists.

If you turn on push in the notification settings, your browser asks its push service for an address for this browser. The push service belongs to the browser's vendor: Google for Chrome and Opera, Mozilla for Firefox, Microsoft for Edge (Windows Push) and Apple for Safari. We store that address and two keys your browser creates for encryption, once per browser, with the time they were stored and last renewed, and how many times in a row the push service refused a message for that address, with the time of the last refusal. We use them only to deliver the notifications you chose. Each message passes the vendor's push service encrypted from us to your browser; the push service sees only that a message is delivered, its size and its time. The legal basis is your consent (Art. 6(1)(a) GDPR), which you can withdraw at any time by turning push off in that browser. We delete the data when you turn push off in that browser, when you sign out, when your session in that browser ends in any other way (the browser then stops the subscription; our copy goes at the next delivery attempt, when the push service reports the address as invalid), when the push service reports the address as expired, when the push service has refused the address three times in a row while it delivers our messages to other browsers, when you have more than 10 browsers (the least recently renewed goes first), and together with your account. Another account signing in in the same browser does not inherit the subscription.

The maps on EDM Hub — the event map, the map on a page and the map in the address editor — draw their map tiles and fonts from OpenFreeMap (tiles.openfreemap.org), a map service run by Hyperknot Software Kft. in Hungary on OpenStreetMap data. To show a map, your browser fetches them directly from OpenFreeMap, which delivers them through the network of Cloudflare. OpenFreeMap and Cloudflare receive what such a request carries: your IP address, the time, what your browser says about itself (its identification, the user agent, and its language setting), the address of EDM Hub as referrer (only the site, not the page you are on) and, with each map tile, the part of the map that is shown — on the event map, once you let the site use your location, the area around you; in the address editor, the area of the address. No cookies are set or sent, and EDM Hub passes OpenFreeMap no other data. The legal basis is that the request is technically necessary to show the map, a core feature of EDM Hub; without it no map can be shown. OpenFreeMap describes what it logs and for how long in its privacy policy at openfreemap.org/privacy.

Your browser gives the site your position only once you allow it. When you choose "Use my location" in the "Nearby" filter — on the lists of events, venues, artists, crews and event series, and on the event map — the site sends your position to the EDM Hub server with every request for that list or map, as the parameter near, together with the radius. The event map also asks for your position every time it opens and, once you allow it, centres on you, unless the "Nearby" filter is set. Whenever the map shows more than it has loaded, it asks the server for the events in the area it shows plus a margin, as the parameter bbox; while the map is centred on you, the middle of that area is your position. OpenFreeMap learns the area from the map tiles (see "Maps"). The map's location button, once you turn it on, follows your position as precisely as your device can tell it and moves the map along with it until you move the map yourself. When you add a region from your position on the Regions tab of "My Follows", we store that position with your account as the region's centre, named "My location". It is used to find the events in your regions — for the filter "In my regions", the notification about new events there and your calendar subscription — and it is sent as near when you narrow "My Follows" to that region; it is part of your data export and is deleted when you remove the region or delete your account. Otherwise the server uses your position only to answer the request it came with: it does not store it and passes it neither to the place search (Photon) nor to anyone else. Your position does not go into the page address; the server tells your browser not to keep its answers to these requests or the list of your regions, and your browser keeps your position only in the memory of the open page.

The web servers in front of EDM Hub (Caddy) do not record a request that succeeds. Between the EDM Hub server and its database, a gateway (Kong) writes each of the server's database requests into its log, with the time. For the event map that includes the area it asks for (bbox), whose middle is your position while the map is centred on you, and with the filter "Only ones I follow" the ID of your account; it does not include near or your IP address. When a request fails with a server error, the EDM Hub server can record its address with near or bbox, and the database interface behind it the bbox, both without your IP address. When nothing answers behind the web servers, for example during an update, they record the request with its address, and so with near or bbox, together with your IP address and your browser's identification. Each of these logs keeps at most 100 MB, without a time limit, and deletes its oldest entries first.

When something fails — on the site in your browser, while our server renders a page, or in the EDM Hub server — an error report goes to an error tracker that runs on our own server (GlitchTip); it is passed to nobody else. A report from your browser holds what failed and where in the site's code (the error message and its stack), the address of the page without what follows a ? or #, so never your position, the addresses of the pages you opened before it and of the site's requests to its server, also without that part, your browser's identification (user agent), the time and the version of the site. A report from the server holds the error, the method and address of the request without that part, and the time. No report holds your IP address, your account or your position. Reports are deleted after 30 days. The summary that groups the reports of one error — its message, where in the code it occurred, how often and in which version — is deleted 37 days after its last report. The legal basis is our legitimate interest in finding and fixing errors (Art. 6(1)(f) GDPR).

When you book the advertising package for an entry, we store with the booking which entry it is for, with its name, the amount, the language, the email address and the name of your account, and the invoice details you enter in the dialog: the country, whether you book as a business or as a private person, your name or your company’s, the address and the VAT number. If you book as a private person, we also store that and when you requested the immediate start of the advertising package, and in which version of the terms. We also keep your latest complete invoice details with your account; they are deleted with your account. Once the payment has arrived, we create the invoice as a PDF from the details of the booking, store it and send it to you by email; in the settings you find it under “Invoices”.

If you give the VAT number of a business in the EU, we ask the European Commission’s VIES service whether the tax administration of its country confirms it; we send only the country and the number. We store a confirmation with its time with your invoice details and do not ask again for further bookings in the following 3 days. A Swiss UID and a British VAT number are checked for their shape only.

You pay on the page of our payment provider Stripe; our contracting party is Stripe Payments Europe, Limited in Dublin, Ireland. From us, Stripe receives the amount, the name of the advertising package with the name of the entry, the language, the email address of your account and identifiers of the booking and the entry. What you enter on Stripe’s page – card or account details and, depending on the payment method, name and address – goes to Stripe, not to us. For handling the payment Stripe works on our behalf (Art. 28 GDPR); to prevent fraud and to meet its own legal duties, such as against money laundering, Stripe processes the data as a controller of its own. Stripe may transfer data to Stripe, Inc. in the USA, based on the EU-US Data Privacy Framework and on standard contractual clauses. How Stripe handles data, Stripe describes at stripe.com/privacy.

Stripe tells us whether and when a payment has arrived, which fee Stripe keeps and later whether a payment was refunded or disputed at the bank. We store these messages as Stripe sends them. They can contain what you entered at Stripe, such as your name, your email address, your country and your postal code, and of a card its brand, its last four digits, its expiry date and the country that issued it – never the full card number and never the security code.

The booking, the payment through Stripe, the check of the VAT number, the invoice and its delivery serve the contract for the advertising package (Art. 6 (1) (b) GDPR). We keep the invoice and the records of the payment because tax law requires it (Art. 6 (1) (c) GDPR with § 147 AO and § 14b UStG).

We keep an invoice or credit note for eight years, counted from the end of the year in which it was issued (§ 147 (3) AO, § 14b (1) UStG), and then delete it with its PDF. An invoice survives the deletion of your account: tax law requires us to keep it, and the right to erasure gives way to that (Art. 17 (3) (b) GDPR). It carries your invoice details as they were at the booking, but belongs to no account any more; nobody can retrieve it in the app, not even a new account with your email address. The bookings themselves – abandoned and failed ones too, each with the email address and the name of your account and with your invoice details as they were at the booking – and Stripe’s messages remain without your account as well, without a time limit.

You have the right to access, rectify, and delete your data. You can delete the data in your browser at any time through your browser settings.

For privacy questions, contact us at: contact@edm-hub.net