Privacybeleid

1. In het kort

Alles in deze verklaring is getoetst aan de broncode van de applicatie. Als u daarover inlichtingen nodig hebt, kunt u zich via de contactgegevens in punt 2 tot ons wenden.

BrickDb is een dienst van ThreeB IT GmbH, zonder advertenties. Deze verklaring beschrijft welke gegevens daadwerkelijk worden verwerkt — niet wat gewoonlijk in zulke teksten staat.

• Voor de gebruiksmeting met Google Analytics wordt uw toestemming gevraagd. Zonder die toestemming vindt zij niet plaats: er wordt geen script geladen, geen identificator geplaatst en niets naar Google verzonden. Meer hierover in punt 10.
• Zonder uw toestemming wordt bij het openen van een pagina geen verbinding met een derde partij opgebouwd. Ook lettertypen staan op onze eigen server.
• Foto's zijn alleen zichtbaar voor u en voor de leden aan wie u in een gedeelde collectie de privégegevens hebt toegekend; op de openbare pagina van een collectie verschijnen ze niet. Meer hierover in punt 8.2. Ingesloten metagegevens — waaronder gps-coördinaten — worden bij de verwerking verwijderd.
• Op het eindapparaat wordt niets opgeslagen waaraan u zou kunnen worden herkend voordat u actief een instelling hebt gekozen, hebt ingelogd of toestemming hebt gegeven. Wat de browser louter technisch nodig heeft voor de beveiliging van de formulieren en wat uw aanmelding draagt, staat volledig in punt 6.1; wat de app op het apparaat plaatst, staat in punt 6.5. Uw beslissing over de gebruiksmeting kunt u onderaan elke pagina op elk moment wijzigen.

2. Verwerkingsverantwoordelijke

De verwerkingsverantwoordelijke in de zin van artikel 4, punt 7, AVG is:

ThreeB IT GmbH
Bergstrang 105
49479 Ibbenbüren
Duitsland
Telefoon: +49 (5451) 893922-0
E-mail: hello@brickdb.net

Vertegenwoordigd door de bestuurders (Geschäftsführer) Thimo Buchheister en Thorsten Brügge.

Er is geen functionaris voor gegevensbescherming aangewezen.

3. Bezoek aan de website

Bij het openen van www.brickdb.de of een van de andere adressen waarop BrickDb bereikbaar is (www.brickdb.at, www.brickdb.ch, www.brickdb.dk, www.brickdb.nl, www.brickdb.be, www.brickdb.fr, www.brickdb.it, www.brickdb.lu, www.brickdb.es, www.brickdb.co.uk, www.brickdb.us, www.brickdb.com.mx, www.brickdb.eu, www.brickdb.net), verwerkt de webserver de gegevens die een browser om technische redenen moet doorgeven opdat een pagina kan worden afgeleverd: IP-adres, datum en tijdstip van het verzoek, het opgevraagde adres, de overgedragen hoeveelheid gegevens en de statuscode, de browser- en besturingssysteemaanduiding (user agent) en de door de browser meegezonden taalvoorkeur (Accept-Language).

Deze gegevens ontstaan noodzakelijkerwijs bij elke verbinding op het internet. Ze worden verwerkt om de pagina af te leveren, de technische werking te waarborgen en aanvallen af te weren.

De taalvoorkeur wordt nog voor één ander, nauw begrensd doel gebruikt: de regioaanduiding die erin staat (bijvoorbeeld DE uit de-DE) wordt tijdens het beantwoorden van het verzoek gelezen om een land voor te selecteren: op de evenementenlijst en voor de prijzen op de pagina's van sets en minifiguren, dat wil zeggen van welke winkels prijzen worden getoond, naar welke Amazon-winkel wordt gelinkt en in welke valuta prijzen worden weergegeven. Bent u ingelogd en hebt u in uw profiel een land vastgelegd (punt 7.2), dan wordt in plaats daarvan dat land gebruikt. Een land dat u op de site zelf hebt gekozen en opgeslagen (punt 6.1, bd-country), gaat vóór beide. De regioaanduiding wordt niet opgeslagen, niet met andere gegevens gecombineerd en niet doorgegeven; het gekozen land staat zichtbaar op de pagina — op de evenementenlijst ook in de adresbalk — en kan daar met één klik ongedaan worden gemaakt.

Op de adressen die bij één land horen (bijvoorbeeld www.brickdb.de of www.brickdb.fr), volgt het land uit het adres zelf. Op www.brickdb.net en www.brickdb.eu, die bij geen afzonderlijk land horen, komt er één gegeven bij: het voorgeschakelde distributienetwerk (Azure Front Door, een dienst van de in punt 4 genoemde verwerker Microsoft) leidt daar aan de rand van het netwerk uit het IP-adres van het verzoek een landcode van twee letters af (bijvoorbeeld SE) en geeft die door aan de applicatie. Die code dient hetzelfde doel als de regioaanduiding: een land voorselecteren voor prijzen en evenementen. De applicatie ontvangt daarbij niets anders dan deze code, en in het bijzonder geen nauwkeurigere locatie; de code wordt niet opgeslagen, niet gelogd en niet met andere gegevens gecombineerd. Er wordt geen geolocatiedienst van een derde gebruikt; het IP-adres wordt voor dit doel aan niemand bekendgemaakt die het niet toch al verwerkt om de pagina af te leveren. De rechtsgrond daarvoor is artikel 6, lid 1, onder f), AVG; het gerechtvaardigd belang bestaat erin u prijzen en evenementen voor uw eigen land te tonen zonder u daar vooraf naar te vragen. U kunt dat op elk moment overschrijven door op de pagina zelf een land te kiezen (punt 6.1, bd-country).

Rechtsgrond: artikel 6, lid 1, onder f), AVG. Het gerechtvaardigd belang ligt in de technisch foutloze en veilige werking van de dienst.

Bewaartermijn: de applicatie zelf houdt geen toegangslogboek bij. Logboeken die op infrastructuurniveau ontstaan, worden slechts bewaard zolang dat voor de bedrijfszekerheid nodig is, ten hoogste 30 dagen, tenzij ze nodig zijn om een concreet beveiligingsincident op te helderen.

4. Hosting

De dienst draait op Microsoft Azure; de aanbieder is Microsoft Ireland Operations Limited, One Microsoft Place, South County Business Park, Leopardstown, Dublin 18, Ierland. Als plaats van verwerking is de Azure-regio Germany West Central (Frankfurt am Main) gekozen; de database en de bestandsopslag bevinden zich daarmee in Duitsland.

Microsoft is in zoverre verwerker in de zin van artikel 28 AVG op grond van het Microsoft Products and Services Data Protection Addendum.

Verzoeken aan BrickDb lopen via het distributienetwerk Azure Front Door van Microsoft. Het neemt de verbinding in ontvangst op een locatie bij u in de buurt — die buiten Duitsland en buiten de EU en de EER kan liggen — en stuurt haar door; de applicatie en alle opgeslagen gegevens blijven in Germany West Central (Frankfurt am Main). Ook dat gebeurt in het kader van de verwerking in onze opdracht op grond van het Microsoft Products and Services Data Protection Addendum; voor zover daarmee een doorgifte aan een derde land gepaard gaat, geldt daarvoor wat de volgende alinea onder 'Doorgifte aan derde landen' over Microsoft zegt.

Doorgifte aan derde landen: toegang vanuit derde landen kan in het kader van ondersteunings- en onderhoudswerkzaamheden niet volledig worden uitgesloten. Microsoft baseert zulke doorgiften op de standaardcontractbepalingen van de Europese Commissie en is daarnaast gecertificeerd onder het EU-US Data Privacy Framework.

5. Lettertypen en externe inhoud

De gebruikte lettertypen worden vanaf onze eigen server afgeleverd. Er worden geen lettertypen van servers van derden geladen — in het bijzonder niet van Google Fonts. Er zijn geen kaarten, video's, socialemediaplug-ins of andere ingesloten inhoud van derden aanwezig.

Zonder uw toestemming wordt bij het openen van een pagina geen verbinding met een derde partij opgebouwd en geen IP-adres aan een derde doorgegeven.

De enige uitzondering is de gebruiksmeting volgens punt 10, en zij is geen beperking van die zin maar de voorwaarde ervan: het script van Google wordt pas geladen nadat u in de toestemmingsbanner hebt ingestemd. Zolang u niet hebt ingestemd of geweigerd, wordt niets van Google geladen — ook geen als "cookieloos" aangeduide voorafgaande melding.

6. Opslag op het eindapparaat

BrickDb plaatst geen cookies voor marketing- of reclamedoeleinden. Opgeslagen wordt uitsluitend wat een bewust gekozen instelling vastlegt, wat de beveiliging van de formulieren vereist, wat uw aanmelding draagt wanneer u inlogt — en, als u met de gebruiksmeting volgens punt 10 hebt ingestemd, de daar beschreven analysecookies. Vóór uw instemming wordt geen van de analysecookies geplaatst.

6.1 Wat er wordt opgeslagen

De eerste vijf vermeldingen bevatten uitsluitend de laatst gekozen waarde. Ze bevatten geen identificatienummer en niets waaraan een persoon of een apparaat zou kunnen worden herkend. Alle vijf zijn first-party-opslag; geen derde heeft er toegang toe. Elk ervan geldt alleen voor het adres waarop het is geplaatst: een keuze op www.brickdb.de wordt op www.brickdb.fr niet gelezen. bd-country ontstaat wanneer u een land kiest en opslaat, bd-market-hint wanneer u de verwijzing sluit dat er voor uw land een eigen adres bestaat — het zorgt er alleen voor dat die verwijzing u niet bij elke pagina opnieuw wordt getoond. bd-analytics-consent is bovendien als HttpOnly geplaatst, omdat geen script in de browser het hoeft te lezen: of de gebruiksmeting loopt, beslist de server voordat de pagina ontstaat.

De zesde vermelding wordt door het gebruikte webframework geplaatst op elke pagina die een formulier bevat — dus ook op de pagina waarop de toestemmingsbanner staat. Zij beschermt die formulieren ertegen dat ze vanaf een vreemde site worden verzonden (cross-site request forgery), bevat geen gegevens over u, is HttpOnly en SameSite=Strict en eindigt met de sessie. Bij de toestemmingsbanner is zij de reden waarom niemand van buitenaf in uw naam een instemming kan uitlokken.

De twee volgende vermeldingen ontstaan pas wanneer u inlogt. bd.auth houdt uw aanmeldsessie vast; de inhoud is versleuteld, het is HttpOnly en Secure en wordt alleen naar deze site gestuurd (SameSite=Lax). Het verlengt zichzelf niet: de sessie eindigt met de geldigheid van de aanmelding en niet pas wanneer u ophoudt met klikken. Bij het uitloggen wordt het verwijderd. De twee handshake-cookies plaatst het framework alleen voor de duur van één enkele aanmelding; ze binden de terugkeer van het inlogscherm aan precies de poging die u bent begonnen, en worden daarna weer verwijderd.

De laatste vermelding betreft de analysecookies uit punt 10. Ze worden uitsluitend na uw toestemming geplaatst en bevatten een willekeurige identificator waarmee terugkerende bezoeken van dezelfde browser worden herkend.

6.2 Waarom voor alle vermeldingen behalve de analysecookies geen toestemming nodig is

Bepalend is § 25 van de Duitse wet inzake gegevensbescherming bij telecommunicatie en digitale diensten (TDDDG). Die bepaling omvat elke opslag van informatie op het eindapparaat en elke toegang daartoe — dus niet alleen cookies, maar uitdrukkelijk ook local storage. Volgens § 25, lid 2, nr. 2, TDDDG is toestemming niet vereist wanneer de opslag strikt noodzakelijk is om een door de gebruiker uitdrukkelijk gevraagde dienst te kunnen leveren.

Dat is hier het geval, en wel om redenen die aan het gedrag van de applicatie kunnen worden getoetst:

• Vóór een actieve keuze wordt niets opgeslagen. Het louter openen van de pagina schrijft geen vermelding weg. Een vermelding ontstaat uitsluitend wanneer de schakelaars voor weergave of taal worden bediend, wanneer u een land kiest en opslaat of wanneer u de verwijzing naar een ander landenadres sluit.
• Terugkeren naar de standaardinstelling verwijdert de vermelding weer. Wordt "Systeem" gekozen, dan wordt de bijbehorende vermelding verwijderd in plaats van overschreven.
• Opgeslagen wordt precies de instelling die uitdrukkelijk is gevraagd, en verder niets.
• Voor bd-analytics-consent geldt hetzelfde om een eigen reden: het legt de beslissing vast die u zojuist hebt genomen. Zonder dit cookie zou de vraag op elke pagina opnieuw moeten worden gesteld — ook aan wie zojuist heeft geweigerd.
• Het antiforgery-cookie is het duidelijkste geval van de drie: zonder dit cookie kan een formulier op deze site niet meer tegen misbruik van buitenaf worden beveiligd, en dat geldt ook voor de knop waarmee u met de gebruiksmeting instemt of haar weigert. Het wordt niet opgeslagen omdat er iets moet worden gemeten, maar opdat uw eigen invoer degene is die telt.
• Voor de drie aanmeldcookies geldt het het duidelijkst: zonder deze cookies kan een aanmelding niet worden uitgevoerd en ook niet in stand worden gehouden. Wie inlogt, vraagt precies om de dienst die ze leveren, en ze ontstaan pas op het moment waarop daarom wordt gevraagd — wie niet inlogt, krijgt er geen van.

Een instelling die op uitdrukkelijk verzoek wordt onthouden, is daarmee strikt noodzakelijk voor het leveren van de gevraagde dienst; voor de beveiliging van de formulieren en voor de aanmelding geldt dat hoe dan ook. Voor deze vermeldingen wordt daarom geen toestemming gevraagd.

Bezwaar en verwijdering: de vermeldingen voor weergave en taal kunnen op elk moment worden verwijderd door in de schakelaar opnieuw "Systeem" te kiezen of door de browsergegevens te wissen. De site werkt zonder deze vermeldingen ongewijzigd; zij verschijnt dan in de weergave en de taal die het besturingssysteem respectievelijk de browser aangeeft. De vermeldingen voor het land en voor de gesloten verwijzing verwijdert u door de browsergegevens te wissen; zonder deze vermeldingen wordt het land weer voorgeselecteerd zoals punt 3 beschrijft.

6.3 Analysecookies — alleen na toestemming

Voor de cookies van de gebruiksmeting geldt § 25, lid 2, nr. 2, TDDDG niet: een gebruiksmeting is voor de door u gevraagde dienst niet noodzakelijk; de site werkt zonder haar volledig. Ze vallen daarmee onder § 25, lid 1, TDDDG en worden pas geplaatst nadat u in de toestemmingsbanner hebt ingestemd. De banner verschijnt op de eerste pagina die u opent en biedt instemmen en weigeren aan als twee even grote knoppen naast elkaar — beide zijn één enkele klik.

6.4 Technisch noodzakelijke verbindingsgegevens

De gebruikersinterface wordt op de server gerenderd en houdt tijdens het gebruik een WebSocket-verbinding met de server open. De bijbehorende sessiestatus bevindt zich uitsluitend in het werkgeheugen van de server, wordt niet op het eindapparaat opgeslagen en eindigt met het sluiten van de pagina.

6.5 In de app

De BrickDb-app voor mobiele apparaten en computers toont dezelfde pagina's, maar plaatst niets in een browseropslag. De instellingen voor weergave en taal staan daar in de instellingenopslag van het besturingssysteem en bevatten, net als in punt 6.1, alleen de laatst gekozen waarde.

Logt u in de app in, dan wordt uw sessie in de beveiligde opslag van het apparaat geplaatst — in de sleutelhanger onder iOS en macOS, in de door de Keystore beveiligde opslag onder Android. Er worden vier dingen geplaatst: het toegangstoken, het vernieuwingstoken, het tijdstip van verlopen en de aanduiding langs welke weg u hebt ingelogd.

Daar komt het identiteitstoken bij, en dat is het enige van deze elementen dat gegevens over uw persoon bevat. Het wordt bij het inloggen door Auth0 afgegeven en daar geplaatst omdat de app eruit afleest met wie zij te maken heeft. Het bevat de identificator van uw account bij de identiteitsdienstverlener, uw naam en uw e-mailadres, de aanduiding of dat adres is bevestigd, en een technische eenmalige waarde uit de aanmelding. Deze gegevens staan daarmee op het apparaat, ook al worden ze volgens punt 7.1 niet in onze database overgenomen. Een wachtwoord is er niet bij, omdat de app er geen in ontvangst neemt (punt 7.1).

Alle vijf elementen worden bij het uitloggen verwijderd. Een kopie van uw collectie wordt niet op het apparaat bewaard, en er worden geen wijzigingen voor latere verzending tussentijds opgeslagen.

7. Gebruikersaccount

7.1 Inloggen

BrickDb kan zonder account worden gebruikt: de catalogus, de zoekfunctie en de scanner staan zonder inloggen open. Een account hebt u pas nodig om een eigen collectie bij te houden.

Het inloggen verloopt via de identiteitsdienstverlener Auth0 (Okta, Inc.), via een tenant in de Europese Unie. Er worden drie wegen aangeboden: een account met e-mailadres en wachtwoord, inloggen met een bestaand Google-account of inloggen met uw Apple Account ("Log in met Apple"). Welke daarvan u kiest, beslist u zelf. Dat geldt voor de website en voor de app in gelijke mate.

Het inlogformulier is een pagina van Auth0, niet van BrickDb. Een wachtwoord wordt op geen enkele pagina van BrickDb ingevoerd, in ontvangst genomen of doorgegeven; ook het wijzigen van een wachtwoord gebeurt bij Auth0. Wie met Google of Apple inlogt, heeft bij Auth0 helemaal geen wachtwoord — de inloggegevens berusten dan bij Google respectievelijk Apple, en BrickDb ziet ze evenmin. Bij "Log in met Apple" kunt u er bovendien voor kiezen uw e-mailadres te verbergen: BrickDb ontvangt dan een adres van de doorstuurdienst van Apple (eindigend op @privaterelay.appleid.com), waarlangs Apple onze e-mails aan u doorstuurt.

Wat BrickDb daarbij ontvangt. Na een geslaagde aanmelding draagt Auth0 de gegevens over waarom is gevraagd: een pseudonieme identificator van uw account, de bij de aanmelding vastgelegde profielgegevens en uw e-mailadres. Daarvan wordt niets opgeslagen behalve de pseudonieme identificator en het tijdstip waarop het record is aangemaakt — dat is de volledige inhoud van ons eigen accountrecord. Naam, profiel en e-mailadres blijven bij Auth0 en worden daar gelezen wanneer ze nodig zijn (punt 7.2); in onze database worden ze niet overgenomen.

Tweefactorauthenticatie wordt aangeboden en nooit verlangd. Wie dat wil, kan een authenticator-app (TOTP), een apparaatsleutel zoals Face ID, Touch ID of Windows Hello, een hardwarebeveiligingssleutel en herstelcodes vastleggen. Zonder een dergelijke registratie wordt niemand ernaar gevraagd. Codes per sms of per e-mail worden bewust niet aangeboden.

Wat Auth0 daarbij verwerkt. Auth0 verwerkt de inloggegevens zelf en de technische gegevens van elke aanmelding — tijdstip, IP-adres en browser- en apparaataanduiding — om de aanmelding uit te voeren en misbruikpogingen bij het inloggen te herkennen. Bij het aanmaken van een account en bij elke wachtwoordwijziging controleert Auth0 daarnaast of het gekozen wachtwoord in een bekend geworden datalek is opgedoken, en weigert het in dat geval. Bij een gewone aanmelding vindt die controle niet plaats.

Rechtsgrond: artikel 6, lid 1, onder b), AVG — zonder account kunnen de collectiefuncties niet worden geleverd. Voor het herkennen van misbruikpogingen bij het inloggen en de controle op bekend geworden wachtwoorden: artikel 6, lid 1, onder f), AVG; het gerechtvaardigd belang ligt in de veiligheid van de accounts. Auth0 is in zoverre verwerker in de zin van artikel 28 AVG.

Doorgifte aan een derde land: de tenant bevindt zich in de Europese Unie, en daar vindt het inloggen plaats. De contractpartij is echter Okta, Inc. (Auth0), gevestigd in de Verenigde Staten, zodat toegang van daaruit — bijvoorbeeld in het kader van ondersteuning en onderhoud — niet kan worden uitgesloten. Okta baseert zulke doorgiften op de standaardcontractbepalingen van de Europese Commissie, die als afzonderlijke documenten bij de verwerkersovereenkomst van 15 december 2023 zijn gevoegd.

Bewaartermijn: het accountrecord bestaat totdat u uw account verwijdert. De verwijdering op de accountpagina verwijdert ook het account bij Auth0 en daarmee de daar vastgelegde gegevens (punt 14).

7.2 Profiel: naam, tekst over uzelf, land en optioneel adres

U kunt een voornaam, een achternaam, een korte tekst over uzelf, uw land, een van onze avatartekeningen en — optioneel — een volledig postadres vastleggen.

Niets daarvan wordt bij BrickDb opgeslagen. Deze gegevens berusten bij de identiteitsdienstverlener Auth0 bij uw inlogaccount; BrickDb leest en schrijft ze daar in plaats van een kopie te houden: ons eigen accountrecord bevat niets anders dan een pseudonieme identificator en het tijdstip waarop het is aangemaakt. Wanneer u uw account volgens punt 14 verwijdert, wordt het Auth0-account verwijderd en daarmee dit profiel.

Elk gegeven is vrijwillig. Niets daarvan is vereist, niets is een voorwaarde voor het gebruik van BrickDb, en er wordt u geen functie onthouden wanneer u een veld leeg laat. U kunt elk gegeven op elk moment wijzigen of wissen.

Waarom in het bijzonder naar het adres wordt gevraagd. Twee doelen, beide hier genoemd voordat het veld wordt aangeboden en niet pas daarna:

• Waardebepaling voor verzekeringsdoeleinden. BrickDb zal een waardebepaling van een collectie voor verzekeringsdoeleinden aanbieden. Een dergelijke waardebepaling is gebonden aan de plaats waar de collectie wordt bewaard; een verzekeraar aanvaardt haar niet zonder dat gegeven.
• Een geplande marktplaats met BrickDb als vertrouwde tussenpartij. BrickDb is voornemens een marktplaats aan te bieden waarop BrickDb als vertrouwde tussenpartij (Treuhänder) tussen koper en verkoper optreedt. Het postadres van een partij is wat een dergelijke transactie toerekenbaar en een geschil oplosbaar maakt.

Geen van beide diensten bestaat al. Het adres wordt voor niets anders gebruikt: niet voor reclame, niet voor profilering, niet voor enige vorm van scoring, en het wordt niet aan derden doorgegeven.

Uw land wordt bovendien gebruikt om een land voor te selecteren op de evenementenlijst en voor de prijzen op de pagina's van sets en minifiguren, met voorrang op de in punt 3 beschreven taalvoorkeur van de browser. Het wordt daarvoor bij het openen van een dergelijke pagina bij Auth0 gelezen, wordt daarvoor door BrickDb niet opgeslagen en niet doorgegeven, en de keuze kan op de pagina met één klik ongedaan worden gemaakt.

Het land en de taal die u op de site kiest. Wanneer u ingelogd een land en een taal voor de site kiest en opslaat, worden beide naast de vermeldingen in de browser (punt 6.1) ook bij uw inlogaccount bij Auth0 vastgelegd, zodat de keuze ook op een ander apparaat en op een ander adres van BrickDb geldt. BrickDb houdt ook hiervan geen eigen kopie bij. Bent u niet ingelogd, dan blijft de keuze alleen in de browser.

Rechtsgrond: voor voornaam, achternaam, tekst over uzelf, land en de gekozen taal artikel 6, lid 1, onder b), AVG — de verwerking hoort bij de gevraagde dienst. Voor het adres artikel 6, lid 1, onder a), AVG — toestemming, gegeven door het veld in te vullen en op elk moment in te trekken door het te wissen. De intrekking raakt uw account voor het overige niet en laat de rechtmatigheid van de verwerking tot dat moment onverlet.

Het profiel is opgenomen in de kopie van uw gegevens volgens punt 14 en wordt volgens hetzelfde punt samen met uw account verwijderd.

7.3 Verzending van e-mail

BrickDb verstuurt alleen e-mail wanneer daar een concrete aanleiding voor is: de bevestiging van uw e-mailadres en het opnieuw instellen van uw wachtwoord, een uitnodiging voor een collectie wanneer iemand u daarvoor uitnodigt (punt 8.1a), een uitnodiging om uw wachtwoord te kiezen wanneer de beheerders een account voor u aanmaken (punt 8.9), ons antwoord op een supportverzoek, en een melding aan ons eigen postvak wanneer iemand er een indient — die laatste is aan ons gericht en niet aan u, maar bevat wat de verzoeker heeft geschreven (punt 8.7 behandelt beide) —, een melding aan ons eigen postvak wanneer iemand inhoud meldt, en de motivering aan u wanneer een melding over inhoud die u hebt gepubliceerd gegrond wordt verklaard (beide punt 8.8). Er is geen nieuwsbrief en geen reclame-e-mail.

De verzenddienstverlener is Twilio Inc. (“SendGrid”), 101 Spear Street, 5th Floor, San Francisco, CA 94105, USA. SendGrid ontvangt daarvoor het adres van de ontvanger, een weergavenaam voor zover die bestaat, het onderwerp en de volledige inhoud van het bericht, evenals de technische afleveringsgegevens (tijdstip, afleverstatus, het antwoord van de ontvangende mailserver). Uw e-mailadres wordt daarmee aan een derde doorgegeven, en wel als eerste — nog voordat er iets anders mee gebeurt. Daarom staat dit hier en niet pas onder punt 12.

Rechtsgrond: artikel 6, lid 1, onder b), AVG — het bevestigen van een adres, het opnieuw instellen van een wachtwoord en het afleveren van een uitnodiging horen bij de gevraagde dienst. SendGrid is in zoverre verwerker in de zin van artikel 28 AVG op grond van het Twilio Data Protection Addendum.

Doorgifte aan een derde land: de verzending loopt via de wereldwijde infrastructuur van SendGrid; de verwerking vindt daarmee in de Verenigde Staten plaats en niet, zoals de hosting volgens punt 4, in Duitsland. Twilio baseert zulke doorgiften op de standaardcontractbepalingen van de Europese Commissie en is daarnaast gecertificeerd onder het EU-US Data Privacy Framework.

Meting van openen en klikken: bij account-e-mails wel, bij onze eigen niet. E-mails over uw account — bevestiging van het adres, wachtwoord opnieuw instellen — worden door SendGrid vóór verzending aangevuld met een onzichtbare afbeelding, en de links erin worden via SendGrid omgeleid. Toont uw e-mailprogramma een dergelijk bericht, dan laadt het die afbeelding en geeft daarbij het tijdstip en uw IP-adres door aan SendGrid; hetzelfde gebeurt bij het aanklikken van een link. Bij SendGrid ontstaat daaruit de informatie of en wanneer een dergelijk bericht is geopend. Rechtsgrond: artikel 6, lid 1, onder f), AVG — ons gerechtvaardigd belang dat account-e-mails aankomen en niet in de spammap belanden. U kunt daartegen op grond van artikel 21 AVG bezwaar maken via de contactgegevens in punt 2, en u kunt het laden van afbeeldingen in uw e-mailprogramma uitschakelen — dan vindt de meting van het openen niet plaats.

E-mails die BrickDb zelf verstuurt, bevatten geen dergelijke afbeelding en geen omgeleide links — op dit moment zijn dat de uitnodigingen voor een collectie, de twee supportmails volgens punt 8.7, ons antwoord op een verzoek en de melding die het ons stuurt, en de twee mails over meldingen volgens punt 8.8. Geen ervan vraagt bij het openen iets op bij welke server dan ook; elke verzending schakelt beide metingen bij SendGrid uitdrukkelijk uit.

Bewaartermijn: BrickDb maakt geen kopie van een verzonden bericht. Bij de verzenddienstverlener blijven de afleveringsgegevens gedurende een korte, van diens tarief afhankelijke periode in diens activiteitenlogboek opvraagbaar.

Stand van deze versie: dit punt beschrijft de verzendroute zoals die op dit moment bestaat. Totdat de hierboven genoemde melding over een supportverzoek erbij kwam, stond hier “zoals die sinds 10 september 2026 bestaat”.

8. Collectiegegevens en foto's

De volgende gegevens beschrijven de verwerking die plaatsvindt met een account volgens punt 7.

8.1 Collectiegegevens

Opgeslagen wordt wat u zelf invoert: setnummer, naam, gegevens over de staat, notities, aanschafdatum, betaalde prijs, aantekeningen over de verkoper en de tijdstippen van aanmaak en van de laatste wijziging. Deze gegevens zijn gekoppeld aan een pseudoniem identificatienummer.

Op dezelfde wijze wordt opgeslagen wat u in de overige onderdelen invoert: afzonderlijke minifiguren en losse onderdelen met dezelfde gegevens, exemplaren van tijdschriftnummers en boeken met hun beoordeling van de staat, de staat van een bijgevoegde polybag, uw opmerkingen over de staat, hoe en wanneer u ze hebt verworven, de betaalde prijs, de aantekening over de verkoper en uw notities, collecties met hun naam, hun beschrijving, hun zichtbaarheid volgens punt 8.1a en hun leden met de rol van elk lid, uitnodigingen die u hebt verstuurd, met het daarvoor opgegeven e-mailadres, handtekeningen die u bij een exemplaar vastlegt, uw verlanglijst, uw bijdragen aan het ophelderen van zakjescodes en verpakkingsbarcodes, en de batches van doosfoto's die u ter verwerking indient.

Exemplaren van tijdschriftnummers en boeken zitten in geen enkele collectie; alleen u ziet ze.

Opbergplekken. U kunt vastleggen waar uw spullen worden bewaard: kamers, locaties in een kamer en vakken op een locatie, telkens met de naam die u eraan geeft, het niveau en de positie in uw lijst, en bij elk exemplaar — sets, minifiguren, losse onderdelen, tijdschriftnummers en boeken — op welke plek het ligt. Uw opbergplekken zijn van u, niet van een collectie: alleen u kunt ze aanmaken, wijzigen of toewijzen. Waar een exemplaar in een gedeelde collectie ligt, zien — alleen-lezen — de leden van wie de rol in die collectie Eigenaar of Bewerker is; leden met de rol Lezer of Verzekering zien het nooit, en een gepubliceerde collectie toont het nooit (punt 8.1a). Verwijdert u uw account (punt 14), dan worden uw opbergplekken verwijderd, en eerst wordt de plek verwijderd bij elk exemplaar dat haar noemde — ook bij een exemplaar dat in een met anderen gedeelde collectie blijft.

Vrije tekstvelden worden niet geanalyseerd. U wordt verzocht daar geen bijzondere categorieën van persoonsgegevens in de zin van artikel 9 AVG in te voeren.

Rechtsgrond: artikel 6, lid 1, onder b), AVG — de verwerking is noodzakelijk om de gevraagde dienst te leveren.

8.1a Wie een collectie kan zien

Elk exemplaar dat van u is, zit in een collectie, en een collectie heeft een van drie instellingen, die u kiest en op elk moment kunt wijzigen: privé (alleen de leden zien haar — de standaard voor een nieuwe collectie), iedereen met de link of iedereen, ook zoekmachines.

Een openbaar gemaakte collectie toont haar naam en haar beschrijving, de setnummers, de setnamen, hoeveel exemplaren u van elk hebt en in welke staat ze verkeren — en verder niets. Geen foto's, geen notities, geen tags, geen bijnamen, geen bewaarplaatsen, geen betaalde prijzen, geen waardeschattingen, geen verwervingsdata en niets over de verkoper. Zij noemt u niet en ook geen ander lid, en zegt evenmin hoeveel personen erin zitten. Deze velden worden op die pagina niet verborgen — ze worden er helemaal niet naartoe gestuurd.

Een link is geen wachtwoord. Een collectie met de instelling “iedereen met de link” wordt afgeleverd aan iedereen die dat adres opent — of u het hun hebt gegeven of niet. Die instelling “iedereen met de link” verzoekt zoekmachines bovendien de pagina niet op te nemen; daar houden ze zich in de regel aan, maar verplicht zijn ze het niet. Een collectie weer op privé zetten beëindigt de aflevering onmiddellijk, maar haalt geen kopie terug die iemand — of een zoekmachine — al heeft gemaakt.

Een collectie die met bij naam genoemde leden wordt gedeeld, is iets anders dan een openbare: wat een lid ziet, hangt af van de rol die u hebt toegekend. Een Lezer ziet precies wat ook de openbare pagina toont. Een Bewerker ziet alles, met inbegrip van de hierboven opgesomde velden. Verzekering ziet de sets, hun staat en waarderingscijfers, en verder niets.

Een openbare collectie kan worden gemeld. Haar pagina bevat het meldformulier uit punt 8.8, dat iedereen kan gebruiken die de pagina kan zien. Verklaren de beheerders een melding daarover gegrond, dan wordt de collectie weer op privé gezet; er wordt niets verwijderd, en u kunt haar opnieuw publiceren.

Rechtsgrond: artikel 6, lid 1, onder a), AVG — u geeft toestemming door de instelling te kiezen, en trekt haar in door de instelling terug te zetten.

8.2 Foto's

Geüploade foto's worden getoond aan u en aan de leden van de collectie van wie de rol de privégegevens omvat — dat zijn Eigenaar en Bewerker volgens punt 8.1a. Zit het exemplaar in een collectie waarin verder niemand zit, dan ziet alleen degene die de foto heeft geüpload haar. Op de openbare pagina van een collectie verschijnen foto's niet, en leden met de rol Lezer of Verzekering zien ze evenmin. Foto's worden niet gepubliceerd, niet aan derden doorgegeven en niet gebruikt om modellen te trainen.

Metagegevens worden verwijderd. Bij het uploaden wordt elke afbeelding opnieuw gecodeerd: de in de afbeelding vermelde oriëntatie wordt vast in de beeldgegevens verwerkt en daarna wordt het volledige metagegevensprofiel verwijderd — EXIF, IPTC en XMP, en daarmee in het bijzonder gps-coördinaten, het tijdstip van de opname en apparaataanduidingen. Alleen de opgeschoonde afbeelding wordt opgeslagen; het oorspronkelijk verzonden bestand wordt niet bewaard.

De oorspronkelijke bestandsnaam wordt niet overgenomen. Elk bestand krijgt een willekeurig gegenereerde identificator; uit het opslagpad valt niets af te leiden over degene die het bestand heeft geüpload of over de herkomst ervan.

Verkleinde versies. Voor de weergave worden zo nodig verkleinde versies van een foto gegenereerd en tijdelijk opgeslagen. Ze bevatten dezelfde — reeds van metagegevens ontdane — beeldgegevens, zijn aan dezelfde toegangsbeperkingen onderworpen en worden samen met de foto verwijderd.

Afbeeldingen in een formaat dat niet opnieuw kan worden gecodeerd — daartoe behoort HEIC/HEIF, het standaardformaat van nieuwere iPhones — worden geweigerd in plaats van opgeslagen. De foutmelding noemt de aanvaarde formaten (JPEG, PNG, WebP, GIF). Er wordt dus niets opgeslagen dat niet eerst is opgeschoond.

Bij elke foto worden opgeslagen: de willekeurige bestandsidentificator, een door u zelf gegeven bijschrift, de sorteervolgorde en het tijdstip van het uploaden.

Rechtsgrond: artikel 6, lid 1, onder b), AVG.

8.3 Avatarafbeelding

U kunt een eigen afbeelding als avatar uploaden of een van de door BrickDb beschikbaar gestelde tekeningen gebruiken. De beschikbaar gestelde tekeningen zijn onze eigen illustraties en geen persoonsgegevens; een geüploade afbeelding is dat wel.

Een geüploade avatar doorloopt dezelfde opschoning als elke andere foto: de oriëntatie wordt in de beeldgegevens verwerkt en het volledige metagegevensprofiel — EXIF, IPTC en XMP, en daarmee in het bijzonder gps-coördinaten, het tijdstip van de opname en apparaataanduidingen — wordt verwijderd. Daarna wordt de afbeelding tot het middelste vierkant bijgesneden, tot 256 bij 256 pixels verkleind en als WebP opnieuw gecodeerd. Alleen die afbeelding wordt opgeslagen; het verzonden bestand wordt niet bewaard, en een afbeelding die niet opnieuw kan worden gecodeerd, wordt geweigerd in plaats van opgeslagen.

Wie hem kan zien. Een avatar wordt opgeslagen opdat hij naast uw naam kan worden getoond. BrickDb heeft op dit moment geen scherm waarop een persoon het profiel van een ander ziet — vandaag ziet dus alleen u uw eigen avatar. Zodra dat verandert, zal dit onderdeel dat uitdrukkelijk zeggen: een avatar is bedoeld om voor anderen zichtbaar te zijn, en juist daarom staat hij hier gescheiden van 8.2.

Per account wordt precies één avatar opgeslagen; een volgende upload vervangt hem. Hij is opgenomen in de kopie van uw gegevens volgens punt 14 en wordt verwijderd wanneer u uw account volgens punt 14 verwijdert.

Rechtsgrond: artikel 6, lid 1, onder b), AVG.

8.4 Inzendingen van evenementen

Bij het indienen van een evenement slaan wij de titel, de optionele beschrijving, de locatie, het land en het tijdschema op. Bij een evenement dat de hele dag duurt, zijn dat de begindatum en de niet-inbegrepen einddatum. Bij een evenement met tijdstip zijn dat de begin- en eindtijdstippen en de tijdzone van de locatie. Daar komen bij: de optionele opening van de inschrijving, de bron-URL, de koppeling met het account en het tijdstip van indiening. Wij slaan bovendien de moderatiestatus op, het tijdstip van een moderatiebeslissing en een interne meldingsopdracht voor de beoordelingswachtrij. Die opdracht verstuurt geen e-mail.

De beheerders beoordelen inzendingen handmatig. Inzendingen die in behandeling zijn of zijn afgewezen, zijn niet openbaar. Na goedkeuring zijn de gegevens van het evenement en de bron-URL openbaar zichtbaar; de identiteit van het account wordt niet gepubliceerd. Dien alstublieft alleen gegevens over evenementen in die u mag publiceren, zonder persoonlijke contactgegevens of privé-informatie over uzelf of anderen.

Indiening en moderatie leveren de gevraagde dienst (artikel 6, lid 1, onder b), AVG). Het in stand houden van de goedgekeurde openbare kalender dient ons gerechtvaardigd belang en dat van andere bezoekers bij betrouwbare informatie over evenementen (artikel 6, lid 1, onder f), AVG). Tegen een verwerking op grond van gerechtvaardigde belangen kunt u via de contactgegevens in punt 2 bezwaar maken. De gegevensexport volgens artikel 15 AVG op de accountpagina bevat uw eigen inzendingen van evenementen in elke moderatiestatus.

Bij het verwijderen van het account worden inzendingen die in behandeling zijn of zijn afgewezen, samen met hun meldingsopdrachten verwijderd. Goedgekeurde evenementen blijven openbaar; de koppeling met de indiener wordt geanonimiseerd: een nieuwe willekeurige waarde vervangt haar, zonder account of herleiding naar de persoon. De goedgekeurde gegevens blijven voor andere bezoekers in de kalender; voor dit geanonimiseerde record bestaat geen vaste vervaltermijn. Voor back-ups geldt punt 13. De overige rechten uit punt 14 blijven bestaan.

8.5 Setnummer uit een foto lezen

Wanneer u uitdrukkelijk een foto van een verkoopverpakking indient om het setnummer te laten lezen, verstuurt BrickDb ten hoogste 8 MB van de browser naar de eigen web- en API-servers. De API-server geeft de foto ongewijzigd door aan een derde eigen server, de leesdienst (de container-app “brickdb-ocr”). Die draait in dezelfde Azure-omgeving en dezelfde regio (Germany West Central, Frankfurt am Main) als de overige servers volgens punt 4, is alleen vanuit die omgeving bereikbaar en heeft geen toegang tot de database of de bestandsopslag. Net als de web- en API-server houdt ook de leesdienst de afbeelding uitsluitend in het werkgeheugen; hij geeft de API-server alleen de daarop gelezen mogelijke setnummers terug, en zijn logboekvermelding legt alleen vast hoe het verzoek afliep (bijvoorbeeld gelezen of afgewezen) en hoe lang het duurde, niets over de foto. Op geen van de drie servers wordt de afbeelding opgeslagen, gelogd of gebruikt om modellen te trainen; zij wordt niet aan derden doorgegeven en na afloop van het verzoek weggegooid. Alle drie de servers beheren wij zelf op Microsoft Azure; Microsoft is daarbij verwerker volgens punt 4. Rechtsgrond: artikel 6, lid 1, onder b), AVG — de verwerking levert de door u gevraagde leesdienst.

Opdat deze rekenintensieve functie beschikbaar blijft, staat elk serverproces zes verzoeken per oorspronkelijk IP-adres binnen een glijdende minuut toe. Die grens wordt gecontroleerd door zowel de webserver als de API-server, omdat de API-server ook rechtstreeks bereikbaar is. Elk serverproces telt voor zich, en van elke server kunnen meerdere processen tegelijk draaien; de grens geldt daarom per proces en niet als één totaal voor heel BrickDb. Opdat de API-server bij een verzoek via de webserver uw adres telt en niet dat van de webserver, geeft de webserver hem uw adres samen met het verzoek door; de leesdienst ontvangt het niet. Op beide servers wordt het adres — bij IPv6 alleen het netwerkdeel — alleen als sleutel in het werkgeheugen van het desbetreffende serverproces gehouden; het wordt niet gelogd, niet duurzaam opgeslagen en niet aan derden doorgegeven. Na één minuut beïnvloedt het geen enkele beslissing meer en wordt het verwijderd wanneer dat adres opnieuw een verzoek doet of de door verzoeken aangestuurde opschoning ruimte nodig heeft. Elk serverproces houdt ten hoogste 1.024 adressleutels vast; zolang alle plaatsen nog actief zijn, wordt een nieuw adres afgewezen in plaats van er een te verdringen. Rechtsgrond: artikel 6, lid 1, onder f), AVG. Het gerechtvaardigd belang is de technisch veilige, betrouwbare en eerlijke beschikbaarheid van de dienst.

8.6 Voorstel voor de staat van een verpakking op basis van een foto

Los van het lezen van het setnummer kunt u voor een foto van een verkoopverpakking uitdrukkelijk een voorstel aanvragen over de zichtbare staat waarin de doos verkeert. Alleen wanneer u die beoordeling hebt aangevraagd en de aanvraag hebt bevestigd, verstuurt BrickDb de foto van zijn eigen API-server naar de dienst Azure OpenAI van Microsoft Ireland Operations Limited, One Microsoft Place, South County Business Park, Leopardstown, Dublin 18, Ierland, als verwerker in de zin van artikel 28 AVG. Vooraf wordt de afbeelding opnieuw gecodeerd, van alle metagegevens ontdaan en verkleind tot ten hoogste 1.024 pixels aan de langste zijde. De verbinding wordt door de server opgebouwd, niet door uw browser; het openen van een pagina brengt haar nooit tot stand.

De verwerking vindt plaats in de EU-gegevenszone van Azure, dus binnen de EU; de implementatie is aangemaakt in de regio Germany West Central, en de verwerking kan in elke EU-lidstaat plaatsvinden. Volgens opgave van Microsoft worden invoer en uitvoer niet gebruikt om de modellen te trainen en niet aan de aanbieders van de modellen doorgegeven. Standaard-misbruikbewaking: Microsoft controleert invoer geautomatiseerd op misbruik. Een invoer die daarbij wordt aangemerkt, kan Microsoft als steekproef bewaren en laten beoordelen door geautoriseerde medewerkers van Microsoft in de EER; Microsoft noemt daarvoor geen vaste maximale bewaartermijn. Daarbuiten bewaart de dienst de foto niet.

BrickDb zelf blijft toestandsloos: de foto en het resultaat worden bij BrickDb niet opgeslagen, niet gelogd en niet gebruikt om modellen te trainen; beide worden na afloop van het verzoek weggegooid. Het resultaat is een experimenteel, niet-gekalibreerd voorstel dat uitsluitend de zichtbare staat van de verpakking betreft — er is geen gemeten trefkans, het zegt niets over inhoud, verzegeling of volledigheid, het schrijft niets in uw collectie, en u neemt het uitdrukkelijk zelf over of vervangt het. Fotografeer alstublieft alleen de verpakking: geen personen, adressen of andere persoonsgegevens, en alleen afbeeldingen die u mag indienen.

Rechtsgrond: artikel 6, lid 1, onder a), AVG — uw toestemming, die u met elke afzonderlijke aanvraag geeft. Zij is vrijwillig; zonder toestemming wordt geen foto verstuurd en blijft de vraag naar de staat een gegeven dat u zelf invult. Voor de toekomst trekt u haar in door geen verdere beoordeling aan te vragen. Zij is geen toestemming voor training; een latere, afzonderlijk intrekbare opt-in zou een eigen verklaring zijn.

8.7 Supportverzoeken

Op de supportpagina staat een formulier voor supportverzoeken, en u kunt het zonder account en zonder in te loggen gebruiken. Het vraagt om een e-mailadres voor het antwoord, een onderwerp en uw bericht; een naam is vrijwillig. Naar de taal vraagt het niet — die volgt uit de taal waarin de pagina werd weergegeven, zodat het antwoord komt in de taal waarin u de vraag hebt gesteld. Als u ons in plaats daarvan schrijft op het adres in punt 2, bereikt u ons net zo goed, maar daaruit ontstaat geen ticket; dat bericht is dan gewoon een e-mail in ons postvak.

Wat u verstuurt, slaan wij op als ticket met een ticketnummer: het e-mailadres voor het antwoord, de vrijwillige naam, de taal waarin u hebt geschreven, het onderwerp, de tekst van uw verzoek, de status van de behandeling, de weg waarlangs het is binnengekomen, en de tijdstippen van binnenkomst en afsluiting.

In deze versie is geen enkel ticket aan een gebruikersaccount gekoppeld — ook geen ticket dat u ingelogd verstuurt. De route die het formulier in ontvangst neemt, staat voor iedereen open en stelt helemaal geen aanmelding vast, zodat het daarvoor bestemde veld leeg blijft. Wat daaruit voor uw rechten volgt, staat hieronder in de alinea over verwijdering. Bij een ticket hoort bovendien een veld voor een toegangssleutel tot een statuspagina, en ook een dergelijke sleutel wordt in deze versie niet uitgegeven, zodat ook dat veld leeg blijft. Zou er een worden uitgegeven, dan zou daarvan alleen de controlesom worden opgeslagen, nooit de sleutel zelf.

Iemand krijgt er meteen bericht van. Een ticket dat u indient, wordt ons per e-mail aan ons eigen postvak gemeld, zodat het niet onopgemerkt blijft liggen. Die melding bevat het ticketnummer, het door u opgegeven adres en de naam, uw onderwerp en de volledige tekst van uw bericht. Zij wordt verstuurd via de in punt 7.3 genoemde maildienstverlener, zodat deze gegevens in de Verenigde Staten worden verwerkt op de daar beschreven grondslag. Anders dan de account-e-mails in dat punt bevat zij geen onzichtbare afbeelding en geen omgeleide links. Wat u zelf te zien krijgt, is het ticketnummer op de pagina zodra het formulier is verzonden; ons antwoord aan u is een afzonderlijke e-mail, hieronder onder "Hoe wij antwoorden".

Bescherming tegen massale inzendingen. Opdat het formulier niet kan worden gebruikt om ons te overspoelen, staat BrickDb vijf inzendingen per internetaansluiting in een glijdend kwartier toe. Daarvoor houdt het een verkorte vorm van uw IP-adres als sleutel in het werkgeheugen van één webproces — bij IPv6 alleen het netwerkdeel, bij IPv4 het adres. Het wordt niet gelogd, niet in het ticket geschreven, niet in de database opgeslagen en niet doorgegeven, en na afloop van het kwartier beïnvloedt het geen enkele beslissing meer. Er worden ten hoogste 1.024 van zulke sleutels gehouden; zijn alle plaatsen bezet, dan wordt een nieuwe afgewezen in plaats van een bestaande te verdringen. Er is geen captcha, en hiervoor wordt niets bij derden opgehaald. Rechtsgrond: artikel 6, lid 1, onder f), AVG. Het gerechtvaardigd belang is de technisch onberispelijke, veilige en eerlijke beschikbaarheid van de dienst.

Rechtsgrond: behandeling en beantwoording van uw verzoek (artikel 6, lid 1, onder b), AVG, voor zover het uw gebruiksverhouding betreft, anders artikel 6, lid 1, onder f), AVG — ons gerechtvaardigd belang om vragen over deze dienst te kunnen beantwoorden). Tegen een verwerking op grond van gerechtvaardigde belangen kunt u via de contactgegevens in punt 2 bezwaar maken.

Bewaartermijn: een afgesloten ticket wordt 24 maanden na de afsluiting verwijderd. De termijn loopt vanaf de afsluiting, niet vanaf de binnenkomst — een ticket waarop u nog wacht, wordt niet verwijderd, hoe oud het ook is. De verwijdering gebeurt in het kader van een periodieke opschoning en dus mogelijk enkele dagen na afloop van de termijn, nooit ervoor. Voor back-ups geldt punt 13.

Bij het verwijderen van het account volgens artikel 17 AVG worden door het verwijderen van uw account op de accountpagina alle tickets geanonimiseerd die aan uw account zijn gekoppeld: het e-mailadres, de naam en die koppeling worden verwijderd en de toegangssleutel wordt ongeldig, terwijl het ticket zelf wordt geanonimiseerd in plaats van verwijderd, omdat het onderwerp, de tekst en onze antwoorden ons eigen bewijs zijn van een gesprek waaraan ook wij deelnamen. Aangezien in deze versie geen enkel ticket een dergelijke koppeling draagt, treft die stap in de praktijk niets: een supportverzoek is niet opgenomen in de gegevensexport volgens artikel 15 AVG en evenmin in de accountverwijdering op de accountpagina — ongeacht of u bij het versturen was ingelogd. De opsomming van wat de export niet bevat, noemt supportverzoeken om precies die reden.

Uw rechten uit punt 14 bestaan onverminderd, en zo oefent u ze voor een ticket uit: wend u via de contactgegevens in punt 2 tot ons en noem het ticketnummer of het gebruikte adres. Eén ding moet u daarbij weten — het verwijderen van velden anonimiseert geen vrije tekst. Als u in het verzoek zelf uw naam, een bestelnummer of andere gegevens over uzelf hebt geschreven, staan die nog steeds in de tekst. Laat het ons weten als dat zo is; wij maken het desbetreffende ticket dan met de hand onleesbaar of verwijderen het.

Interne notities: terwijl een ticket wordt behandeld, schrijven wij daarover bovendien notities voor onszelf — wat er is geprobeerd, wat wij hebben gevonden, op welke status wij het ticket hebben gezet en wie dat deed. Die notities zijn van ons en niet van u: ze hangen aan de persoon die ze heeft geschreven, ze worden nooit deel van een antwoord aan u, en ze zitten daarom niet in uw gegevensexport volgens artikel 15 AVG en worden evenmin geanonimiseerd wanneer u uw account verwijdert. Ze worden samen met het ticket verwijderd, op dezelfde termijn. Als u wilt weten of een notitie u bij naam noemt, schrijf ons dan via de contactgegevens in punt 2 en noem het ticketnummer.

Hoe wij antwoorden: wij antwoorden per e-mail op het adres dat u hebt opgegeven, en in de taal waarin u hebt geschreven. Dat antwoord citeert uw onderwerp en uw bericht nogmaals, zodat u het ticket kunt terugvinden — bij het versturen krijgt u er geen kopie van. Ons antwoord bevat geen link en geen tracking: er wordt niets bijgeladen, en of u het opent, komen wij niet te weten. Als er daarna nog iets openstaat, beantwoord dan gewoon die e-mail en laat het ticketnummer in het onderwerp staan.

Mails aan het supportadres: mails aan support@brickdb.net — ook een antwoord op een van onze antwoorden, dat daarheen moet gaan — worden een ticket. Onze maildienstverlener (punt 7.3) neemt ze voor het subdomein support.brickdb.net in onze opdracht in ontvangst en draagt ze over aan BrickDb; ze worden daarom op de daar beschreven grondslag in de Verenigde Staten verwerkt. Draagt het onderwerp het nummer van een openstaand ticket, komt de mail van het eigen adres van dat ticket en heeft het domein van de afzender haar ondertekend of toegestaan (DKIM of SPF, bij ontvangst gecontroleerd), dan wordt zij aan dat ticket toegevoegd; elke andere mail opent een nieuw ticket, en het ticket vermeldt of de afzender zo kon worden bevestigd. Opgeslagen worden het adres en de naam van de afzender, het onderwerp, de taal die de mail aangeeft en de tekst ervan — nooit de bijlagen: een bijlage wordt nergens opgeslagen; het ticket vermeldt alleen hoeveel het er waren. Een mail die onze spamcontrole als spam aanmerkt, die van een van onze eigen adressen komt of die binnenkomt nadat in het afgelopen uur al vijf mails van dezelfde afzender (of zestig in totaal) zijn aangenomen, wordt geen ticket; opdat een echt verzoek dat zo blijft hangen toch kan worden gevonden en beantwoord, leggen wij kort vast wanneer het binnenkwam, waarom het werd geweigerd, het adres van de afzender en het onderwerp — nooit de tekst —, en wel gedurende 30 dagen. Rechtsgrond, bewaartermijn en uw rechten zijn voor het overige die van het formulier hierboven.

Stand van deze versie: het formulier voor supportverzoeken op /support is in gebruik, en het hierboven beschreven antwoord per e-mail eveneens. U bereikt ons ook nog steeds via de contactgegevens in punt 2 en in het Impressum — dat is de weg wanneer het formulier uw verzoek om welke reden dan ook niet aanneemt.

8.8 Meldingen over inhoud

Bij elk evenement op de evenementenpagina hoort een meldformulier, en ook bij de pagina van elke gepubliceerde collectie (punt 8.1a). U kunt het zonder account en zonder in te loggen gebruiken — waar een melding over gaat, kan ook worden gezien door wie niet is ingelogd, zodat een drempel ervoor precies de persoon zou buitensluiten voor wie het formulier bestaat. Er wordt gevraagd naar een reden uit een vaste lijst, een vrijwillige beschrijving van wat er niet klopt, en een vrijwillig e-mailadres. Slechts bij één reden — „Iets anders“ — is de beschrijving verplicht, omdat een melding waarvan de hele inhoud dat woord is, eerst zou moeten worden gelezen voordat zij kan worden ingedeeld. Naar de taal wordt niet gevraagd — die volgt uit de taal waarin de pagina werd weergegeven.

Wat u verstuurt, slaan wij op als melding met een eigen referentie, die eruitziet als BDR-000042: om welke soort inhoud het gaat en de eigen sleutel van die inhoud, de door u gekozen reden, uw beschrijving als u er een hebt geschreven, het e-mailadres als u er een hebt opgegeven, de taal waarin u hebt geschreven, de status van de behandeling en de tijdstippen van binnenkomst en beslissing. Een beschrijving mag ten hoogste 2.000 tekens lang zijn en een adres ten hoogste 254; alles wat langer is, wordt onder vermelding van het veld afgewezen in plaats van ingekort opgeslagen.

Geen enkele melding is aan een gebruikersaccount gekoppeld — ook geen melding die u ingelogd verstuurt. De route die het formulier in ontvangst neemt, staat voor iedereen open en stelt helemaal geen aanmelding vast, en een veld voor een dergelijke koppeling bestaat niet: BrickDb weet bewust niet welke melding van u was. Wat daaruit voor uw rechten volgt, staat hieronder in de alinea over export en verwijdering. Er is bovendien geen statuspagina voor een melding en geen toegangssleutel daarvoor, zodat ook niets van dien aard wordt opgeslagen.

Iemand krijgt er meteen bericht van. Een melding die u verstuurt, wordt ons per e-mail aan ons eigen postvak gemeld, zodat zij niet onopgemerkt blijft liggen. Dat bericht bevat de referentie, de soort inhoud, de reden, de sleutel van de gemelde inhoud en de volledige tekst van uw beschrijving. Het bevat geen adres van u: het bericht gaat naar ons, en uw adres blijft in de wachtrij, waar alleen een beheerder het kan zien. Het wordt verstuurd via de in punt 7.3 genoemde maildienstverlener, zodat deze gegevens in de Verenigde Staten worden verwerkt op de daar beschreven grondslag; net als de supportmelding bevat het geen onzichtbare afbeelding en geen omgeleide links. Wat u zelf te zien krijgt, is de referentie op de pagina zodra het formulier is verzonden.

Bescherming tegen massale inzendingen. Opdat het formulier niet kan worden gebruikt om ons te overspoelen, staat BrickDb vier meldingen per internetaansluiting in glijdende tien minuten toe. Daarvoor houdt het een verkorte vorm van uw IP-adres als sleutel in het werkgeheugen van één webproces — bij IPv6 alleen het netwerkdeel, bij IPv4 het adres. Het wordt niet gelogd, niet in de melding geschreven, niet in de database opgeslagen en niet doorgegeven, en na afloop van de tien minuten beïnvloedt het geen enkele beslissing meer. Er worden ten hoogste 1.024 van zulke sleutels gehouden; zijn alle plaatsen bezet, dan wordt een nieuwe afgewezen in plaats van een bestaande te verdringen. Er is geen captcha, en hiervoor wordt niets bij derden opgehaald. Rechtsgrond: artikel 6, lid 1, onder f), AVG. Het gerechtvaardigd belang is de technisch onberispelijke, veilige en eerlijke beschikbaarheid van de dienst.

Wie een melding leest, en wat de beslissing teweegbrengt. Een melding komt terecht in een wachtrij onder /admin/reports, die alleen een beheerder kan openen; een pagina waarop iemand anders haar zou kunnen opzoeken, bestaat niet — ook niet via de referentie. De melding wordt ofwel afgewezen, ofwel gegrond verklaard, en wordt zij gegrond verklaard, dan wordt de gemelde inhoud verwijderd: een evenement waartegen een melding gegrond wordt verklaard, verdwijnt uit de openbare kalender. Een gepubliceerde collectie waartegen een melding gegrond wordt verklaard, wordt weer op privé gezet: vanaf dat moment zien alleen haar leden haar, er wordt niets van verwijderd, en de eigenaar kan haar opnieuw publiceren — een opnieuw gepubliceerde collectie kan opnieuw worden gemeld. Wij treden op tegen de inhoud, niet tegen de persoon die haar heeft geplaatst.

Een beslissing over iets wat een persoon heeft gepubliceerd, wordt ook bij die persoon vastgelegd. Verklaren de beheerders een melding over een collectie of over een door een lid ingediend evenement gegrond, of wijzen zij haar af, dan wordt de beslissing vastgelegd in het in punt 8.9 beschreven auditlogboek, en wel bij het account van de persoon die de inhoud heeft gepubliceerd: om welke melding het ging, de soort inhoud en de sleutel ervan, en hoe de status van de melding is verschoven. De melder wordt in die vermelding niet genoemd, en de notities van de moderatie maken er evenmin deel van uit.

Rechtsgrond: artikel 6, lid 1, onder f), AVG. Het gerechtvaardigd belang is de door BrickDb gepubliceerde inhoud vrij te houden van onrechtmatig en aanstootgevend materiaal, een bezwaar überhaupt in ontvangst te kunnen nemen — ook van iemand zonder account — en achteraf te kunnen aantonen hoe een klacht is behandeld. Betreft een melding inhoud waartegen wij moeten optreden, dan dient de behandeling ervan tevens de nakoming van een wettelijke verplichting (artikel 6, lid 1, onder c), AVG). Tegen een verwerking op grond van gerechtvaardigde belangen kunt u via de contactgegevens in punt 2 bezwaar maken.

Wordt een melding gegrond verklaard, dan krijgt de persoon die de inhoud heeft gepubliceerd van ons een motivering per e-mail. Dat geldt voor een gepubliceerde collectie en voor een door een lid ingediend evenement; bij een evenement dat wij uit de kalender van een ander hebben overgenomen, is er niemand aan wie wij zouden kunnen schrijven. Het bericht noemt de referentie van de melding, om welke inhoud het gaat (de soort en de titel of naam ervan), wat wij hebben gedaan en hoe lang dat geldt, de reden waaronder de melding is ingediend, het punt van onze Gebruiksvoorwaarden op grond waarvan wij hebben beslist, de mededeling dat geen geautomatiseerde middelen zijn ingezet, en hoe u bezwaar kunt maken — door de e-mail te beantwoorden of via het supportformulier, onder vermelding van de referentie. Wie de melding heeft verstuurd, staat er niet in, en evenmin de beschrijving ervan of de notities van de moderatie.

Voor de verzending vragen wij op het moment van de beslissing bij Auth0 uw e-mailadres en de taal die bij uw account is vastgelegd op (punt 7.1). Het adres wordt alleen daarvoor gebruikt en bij ons niet opgeslagen; bij de melding leggen wij alleen vast of de motivering kon worden verstuurd en wanneer — of waarom niet, bijvoorbeeld omdat er geen adres is vastgelegd. Zij wordt verstuurd via de in punt 7.3 genoemde maildienstverlener, zodat deze gegevens in de Verenigde Staten worden verwerkt op de daar beschreven grondslag; zij bevat geen onzichtbare afbeelding en geen omgeleide links. Wordt een collectie op privé gezet, dan is de gewijzigde instelling bovendien te zien op de collectiepagina. Rechtsgrond: artikel 6, lid 1, onder c), AVG in samenhang met artikel 17 van Verordening (EU) 2022/2065 (de digitaledienstenverordening), voor zover wij tot een dergelijke motivering verplicht zijn, en voor het overige artikel 6, lid 1, onder f), AVG — het gerechtvaardigd belang is u te zeggen wat er met uw inhoud is gebeurd en waarom, en u een weg te bieden om tegen de beslissing bezwaar te maken.

Bewaartermijn: een melding waarover is beslist, wordt 24 maanden na de beslissing verwijderd. De termijn loopt vanaf de beslissing, niet vanaf de binnenkomst — een melding waarover nog niemand heeft beslist, wordt niet verwijderd, hoe oud zij ook is, want zij is een bezwaar waarop nog een antwoord uitstaat. De verwijdering gebeurt in het kader van een periodieke opschoning en dus mogelijk enkele dagen na afloop van de termijn, nooit ervoor. Voor back-ups geldt punt 13.

Noch de gegevensexport volgens artikel 15 AVG, noch de accountverwijdering bereikt een melding, en dat is een grens en geen beslissing tegen u. Omdat geen melding aan een account is toegewezen, valt niet eens te vragen welke meldingen van een bepaalde persoon afkomstig zijn — een melding is daarom niet opgenomen in de gegevensexport volgens artikel 15 AVG en evenmin in de accountverwijdering op de accountpagina, ongeacht of u bij het versturen was ingelogd, en het verwijderen van uw account verwijdert haar niet mee. Hetzelfde geldt wanneer iemand iets heeft gemeld dat u hebt geplaatst: die melding noemt de inhoud, nooit uw account, en zit daarmee ook niet in uw export — de beslissing daarover wel, zodra de beheerders haar gegrond hebben verklaard of hebben afgewezen, als vermelding in het auditlogboek volgens punt 8.9. De opsomming van wat de export niet bevat, noemt beide gevallen om precies die reden. Wat u daadwerkelijk kunt doen: wend u via de contactgegevens in punt 2 tot ons en noem de referentie. Daarmee vinden wij de melding met de hand, kunnen wij u zeggen wat zij bevat, haar rectificeren of het adres en de tekst die u hebt geschreven verwijderen.

Het verwijderen van velden anonimiseert geen vrije tekst. Als u in de beschrijving uw naam, een adres of andere gegevens over uzelf hebt geschreven, staan die nog steeds in de tekst. Laat het ons weten als dat zo is; wij maken de desbetreffende melding dan met de hand onleesbaar of verwijderen haar.

Interne notities: terwijl een melding wordt behandeld, schrijven wij daarover bovendien notities voor onszelf — wat wij hebben gevonden, op welke status wij de melding hebben gezet en wie dat deed. Die notities zijn van ons en niet van u: ze hangen aan de persoon die ze heeft geschreven, ze gaan niet naar u en ook niet naar de persoon van wie de inhoud is gemeld, en ze zijn daarom niet opgenomen in uw gegevensexport volgens artikel 15 AVG en evenmin via een accountverwijdering bereikbaar. Ze worden samen met de melding verwijderd, op dezelfde termijn. Als u wilt weten of een notitie u bij naam noemt, schrijf ons dan via de contactgegevens in punt 2.

Uit onszelf schrijven wij niet terug. Uit een melding ontstaat geen briefwisseling: er is geen bevestigingsmail, geen statuspagina en geen bericht wanneer er is beslist. Het adres is er opdat iemand contact met u kan opnemen als de melding niet zonder een vraag aan u kan worden behandeld, en het wordt voor niets anders gebruikt. Wat u krijgt, is meteen de referentie op de pagina.

Stand van deze versie: het meldformulier op /events en op de pagina van elke gepubliceerde collectie is in gebruik, en de wachtrij erachter eveneens. Neemt het uw melding om welke reden dan ook niet aan, dan bereikt u ons net zo goed via de contactgegevens in punt 2 en in het Impressum — een zo verzonden bericht is dan gewoon een e-mail in ons postvak en doet geen melding ontstaan.

8.9 Beheer van gebruikersaccounts

De beheerders van BrickDb kunnen gebruikersaccounts beheren in een onderdeel onder /admin/users dat alleen zij kunnen openen: de lijst van accounts zien, een account bekijken, de naam, het e-mailadres, het profiel of de rollen ervan wijzigen, een wachtwoordreset sturen, de bevestigingsmail opnieuw sturen, een e-mailadres als bevestigd markeren, het account blokkeren of deblokkeren, of het verwijderen via dezelfde verwijdering die in punt 14 is beschreven. De accountgegevens daar worden live bij Auth0 gelezen (punten 7.1 en 7.2) en niet gekopieerd naar de database van BrickDb. Hetzelfde geldt voor de aanmeldgeschiedenis van een account: die wordt bij Auth0 gelezen wanneer een beheerder haar opent, en wordt slechts zo lang bewaard als Auth0 zelf haar bewaart.

Wat de beheerders over een account zien. De pagina van een account toont wat Auth0 daarover opslaat — de identificator, het e-mailadres en of dat is bevestigd, de eraan gekoppelde aanmeldmethoden, wanneer het is aangemaakt, voor het laatst gewijzigd en voor het laatst ingelogd, hoe vaak ermee is ingelogd, of het is geblokkeerd, welke soorten meerfactorauthenticatie zijn ingesteld (alleen de soort, nooit een geheim of een telefoonnummer) en de rollen — evenals het profiel dat u hebt ingevuld (namen, land, de tekst over uzelf, de gekozen avatar en de taal van uw e-mails, maar niet uw postadres). Uit de eigen database van BrickDb toont zij alleen aantallen: hoeveel collecties u bezit en bij hoeveel u zich hebt aangesloten, hoeveel exemplaren u hebt toegevoegd, hoeveel zakjescodes, setbarcodes en evenementen u hebt bijgedragen, hoeveel van uw supportverzoeken openstaan en hoeveel inhoudsmeldingen met uw e-mailadres zijn ingediend — nooit de inhoud ervan.

De aanmeldgeschiedenis toont bij elke gebeurtenis die Auth0 voor het account heeft vastgelegd, wanneer zij plaatsvond, wat het was (een aanmelding of een mislukte, een registratie, een afmelding, een wijziging van wachtwoord of e-mailadres, een e-mailbevestiging, een stap van de meerfactorauthenticatie, een door Auth0 geblokkeerde poging of een wachtwoord uit een datalek), via welke aanmeldmethode en welke applicatie van BrickDb zij verliep, het land en de stad die Auth0 uit het IP-adres heeft afgeleid, en de browser en het besturingssysteem met hun hoofdversie. Het IP-adres zelf wordt niet getoond, en evenmin de vrije tekst die Auth0 aan een gebeurtenis toevoegt. De beheerders bekijken haar om accounts veilig te houden — om aanmeldingen te herkennen die niet van u waren, of een aanval op uw wachtwoord — en om u te helpen wanneer u ons iets over uw account vraagt.

Geen enkele beheerder ziet, kiest of typt ooit een wachtwoord. Een account dat daar wordt aangemaakt, krijgt een willekeurig wachtwoord dat niemand ziet, en u ontvangt van BrickDb een uitnodigingsmail (verzonden zoals in punt 7.3 beschreven) met een link die zeven dagen geldig is en één keer kan worden gebruikt om uw eigen wachtwoord te kiezen. Een wachtwoordreset is de eigen mail van Auth0 met hetzelfde soort link. Noch het wachtwoord, noch de link wordt door BrickDb opgeslagen of gelogd.

Elke handeling van de beheerders wordt in een auditlogboek vastgelegd, en wel voordat zij wordt uitgevoerd, zodat ook een mislukte handeling is vastgelegd: wanneer zij plaatsvond, wie haar heeft uitgevoerd, wat het was, welk account zij betrof (de Auth0-identificator ervan, en het e-mailadres en de naam die het op dat moment had), welke reden de persoon heeft opgegeven, welke velden met welke waarden vooraf en achteraf zijn gewijzigd, en of zij is geslaagd. Een wachtwoord, een resetlink of een token wordt nooit vastgelegd. Alleen de beheerders kunnen het logboek lezen, onder /admin/audit, en het heeft geen functie die een vermelding wijzigt of verwijdert.

Rechtsgrond: artikel 6, lid 1, onder f), AVG. Ons gerechtvaardigd belang is accounts en de dienst veilig te houden, u te helpen wanneer uw account hulp nodig heeft, en achteraf te kunnen aantonen wat er met een account is gebeurd, door wie en waarom — de verantwoording die artikel 5, lid 2, AVG van ons verlangt. Dat geldt voor de gegevens van de beheerders in het logboek evenzeer als voor de uwe. U kunt via de contactgegevens in punt 2 bezwaar maken.

Bewaartermijn: een vermelding in het auditlogboek wordt 24 maanden na de handeling verwijderd, in het kader van de periodieke opschoning, dus mogelijk een paar dagen later en nooit eerder. Voor back-ups geldt punt 13.

Als u uw account verwijdert, blijven de vermeldingen daarover bewaard, maar ze noemen u niet meer. De accountidentificator wordt vervangen door een willekeurig pseudoniem, en het e-mailadres, de naam en alle gewijzigde waarden worden verwijderd; wie heeft gehandeld, wat er is gedaan en wanneer, blijft staan, want precies daarvoor dient de vermelding. De reden die de beheerders hebben genoteerd, bewaren wij eveneens; die kan u in de tekst vermelden — laat het ons weten, dan maken wij haar onleesbaar. Als u zelf beheerder bent en uw eigen account verwijdert, blijven de vermeldingen over uw handelingen ongewijzigd.

De beheerders verwijderen een account alleen via diezelfde verwijdering (punt 14), stap voor stap, en pas nadat zij het e-mailadres van het account hebben ingetypt en een reden hebben opgegeven, die het auditlogboek bewaart. Dat doen wij bijvoorbeeld wanneer u ons vraagt een account te verwijderen waarop u niet meer kunt inloggen. Als u vooraf een kopie van uw gegevens wilt hebben, download dan uw export volgens artikel 15 AVG op de accountpagina voordat u ons schrijft — daarna valt er niets meer te exporteren. Het eigen account kunnen de beheerders langs deze weg niet verwijderen; daarvoor is er, zoals voor iedereen, de accountpagina.

De beheerders kunnen uw export volgens artikel 15 AVG ook voor u downloaden — bijvoorbeeld wanneer u ons vraagt hem aan u te sturen omdat u niet kunt inloggen. Het is hetzelfde archief dat de accountpagina u geeft, op dezelfde wijze samengesteld, en de beheerders kunnen het pas downloaden nadat zij een reden hebben opgegeven. Elke download wordt in het auditlogboek vastgelegd zoals elke andere handeling van de beheerders: wie hem heeft gedownload, wanneer en waarom. Het archief gaat rechtstreeks naar de browser van de beheerder; BrickDb bewaart er geen kopie van en schrijft het in geen enkel logboek.

Uw export volgens artikel 15 AVG op de accountpagina bevat de vermeldingen over uw account (onder „adminAuditEntries“) — wanneer, wat, de reden en wat er is gewijzigd —, maar niet welke beheerder het was, want dat zijn de gegevens van die persoon en niet de uwe. Schrijf ons via de contactgegevens in punt 2 als u het wilt weten.

Stand van deze versie: de gebruikerslijst met haar zoekfunctie, de pagina van een afzonderlijk account, de aanmeldgeschiedenis ervan, elke hierboven genoemde handeling en het auditlogboek zijn in gebruik.

9. Externe gegevensbronnen

BrickDb toont catalogus- en prijsgegevens uit bronnen van derden, in het bijzonder Rebrickable en BrickLink. Die gegevens worden uitsluitend op de server opgehaald en in het eigen bestand overgenomen. De browser bouwt op geen enkel moment een verbinding met die aanbieders op.

Aan die aanbieders worden geen persoonsgegevens doorgegeven — geen IP-adres en geen identificatienummer, en evenmin de informatie waarnaar is gezocht of wat iemand bezit. Opvragingen gebeuren volgens een eigen tijdschema en niet als het doorgeven van een verzoek van een gebruiker.

10. Gebruiksmeting met Google Analytics

BrickDb telt met Google Analytics 4 hoe vaak pagina's worden geopend en welke onderdelen worden gebruikt. Dat gebeurt uitsluitend met uw toestemming. Zolang u niet hebt ingestemd, wordt geen script van Google geladen, geen identificator geplaatst en niets naar Google verzonden — ook geen als "cookieloos" aangeduide voorafgaande melding. De geavanceerde toestemmingsmodus van Google ("Consent Mode v2 advanced"), waarbij het script onmiddellijk laadt en al vóór de toestemming gegevens verzendt, wordt bewust niet gebruikt.

Rechtsgrond: artikel 6, lid 1, onder a), AVG — uw toestemming — en § 25, lid 1, TDDDG voor het opslaan en uitlezen van de informatie op uw eindapparaat.

Ontvanger en verwerker: Google Ireland Limited, Gordon House, Barrow Street, Dublin 4, Ierland. De grondslag zijn de verwerkingsvoorwaarden van Google (Google Ads Data Processing Terms), waarmee voor het rechtsgebied Duitsland is ingestemd.

Wat er wordt verwerkt: de geopende pagina en de titel ervan, de verwijzende bron, een locatie bij benadering op het niveau van land en regio, het type apparaat, de browser, het besturingssysteem, de schermgrootte en de taal, datum en tijdstip, en een willekeurige identificator in de cookies volgens punt 6.1, waarmee terugkerende bezoeken van dezelfde browser worden herkend. Daarnaast zijn de automatische gebeurtenissen actief die Google "verbeterde meting" noemt: scrolldiepte, het zoeken op deze website, bestandsdownloads, video-interacties en klikken op links naar andere websites — dus ook op de partnerlinks volgens punt 10.1. Uw IP-adres wordt door Google gebruikt om de locatie bij benadering af te leiden en wordt daarbij volgens opgave van Google niet gelogd en niet opgeslagen.

Wat niet plaatsvindt: de functies "Google-signalen" en "gepersonaliseerde advertenties" zijn in de broncode van de pagina uitdrukkelijk uitgeschakeld (allow_google_signals en allow_ad_personalization_signals staan beide op false), en het delen met "Google-producten en -services" is in de property gedeactiveerd. Er worden geen advertentie- of doelgroeplijsten gevormd, geen gegevens voor reclamedoeleinden aan Google doorgegeven en geen apparaatoverschrijdende profielen aangemaakt. Er vindt geen geautomatiseerde besluitvorming, met inbegrip van profilering, in de zin van artikel 22 AVG plaats. In de pagina zijn geen andere analysediensten, geen advertentienetwerken en geen sociale plug-ins opgenomen, en ook geen script van een foutrapportagedienst: de browser laadt van een dergelijke dienst niets en stuurt er niets naartoe. De foutdiagnose die BrickDb daadwerkelijk gebruikt, draait op de server en — in de app — op het apparaat zelf; zij is beschreven in punt 11.

Doorgifte aan derde landen: de contractpartij is Google Ireland Limited; een doorgifte aan Google LLC in de Verenigde Staten kan niet worden uitgesloten. Google LLC is gecertificeerd onder het EU-US Data Privacy Framework, waarvoor de Europese Commissie op 10 juli 2023 een adequaatheidsbesluit heeft vastgesteld; aanvullend gelden de standaardcontractbepalingen uit de verwerkingsvoorwaarden van Google.

Bewaartermijn: gegevens op gebeurtenis- en gebruikersniveau worden in de Google Analytics-property tot 14 maanden na uw laatste interactie bewaard en daarna door Google verwijderd. De termijn loopt vanaf het laatste en niet vanaf het eerste bezoek, omdat in de property de optie "Resetten bij nieuwe activiteit" actief is: elk volgend bezoek laat de 14 maanden opnieuw beginnen. Van wie regelmatig terugkomt, worden de gegevens dus niet verwijderd zolang hij terugkomt. Het gaat om de gegevens die aan afzonderlijke gebeurtenissen en identificatoren zijn gekoppeld. De samengevatte standaardrapporten — bijvoorbeeld "hoeveel paginaweergaven had september" — vallen niet onder die instelling en blijven bij Google daarna beschikbaar. Het toestemmingscookie op uw apparaat verloopt na 182 dagen; daarna wordt de vraag opnieuw gesteld.

Intrekking: onderaan elke pagina staat het onderdeel "Gebruiksmeting" met een knop die uw beslissing omkeert — één klik, precies zoals het instemmen dat was (artikel 7, lid 3, AVG). De intrekking werkt onmiddellijk: het script wordt niet meer geladen, en de door Google geplaatste cookies (_ga en _ga_…) worden met hetzelfde verzoek verwijderd. De rechtmatigheid van de verwerking tot aan de intrekking blijft onverlet. Voor gegevens die al aan Google zijn doorgegeven, kunt u daarnaast de in punt 14 genoemde rechten uitoefenen.

Wat dat voor de cijfers betekent: geteld wordt alleen wie heeft ingestemd. De cijfers zijn daarom onvolledig en liggen onder het werkelijke gebruik. Dat is het beoogde gevolg van de beslissing om niets zonder toestemming te laden.

10.1 Partnerlinks (affiliatelinks)

BrickDb neemt deel aan partnerprogramma's; de desbetreffende links zijn onmiddellijk bij de link gemarkeerd met "Advertentie". Dat verandert niets aan wat hierboven is gezegd: er wordt geen advertentienetwerk in de pagina opgenomen, geen script en geen telpixel van een partnernetwerk geladen en geen identificator geplaatst. Bij het louter openen van een pagina gebeurt in dit opzicht niets.

Pas wanneer een persoon een dergelijke link aanklikt, opent zijn browser het adres van de handelaar respectievelijk van het partnernetwerk. Dat is een zelf gekozen paginawissel, waarvoor de gelinkte partij de verwerkingsverantwoordelijke is. Het adres bevat een identificator waaraan de handelaar herkent dat het bezoek van BrickDb kwam; hij is zichtbaar in de adresbalk. BrickDb komt daarbij niet te weten wie heeft geklikt: het partnernetwerk stelt uitsluitend samengevatte afrekeningsgegevens beschikbaar, geen persoonsgegevens over afzonderlijke klikken.

Awin. De links naar handelaren van wie BrickDb de prijzen uit een productdatafeed van Awin overneemt, lopen via het partnernetwerk Awin (AWIN AG, Berlijn). BrickDb geeft een dergelijke link ongewijzigd weer zoals hij in de feed staat: hij bevat de publisher-identificator van BrickDb, de identificator van de handelaar en de bestemming bij de handelaar, en niets over u - geen accountidentificator en geen door BrickDb toegekende klik- of bezoekersidentificator. Klikt u erop, dan opent uw browser eerst een adres van Awin (awin1.com) en wordt hij van daaruit naar de handelaar doorgestuurd. Daarbij kan Awin informatie rechtstreeks bij u verzamelen en op zijn eigen domein cookies in uw browser plaatsen of uitlezen om een latere aankoop aan die klik toe te rekenen, volgens de eigen privacyverklaring van Awin. BrickDb plaatst daarvoor geen cookie, registreert de klik niet op de eigen server en geeft zelf geen gegevens over u door aan Awin.

Rakuten Advertising. De links naar webwinkels die LEGO zelf exploiteert en waarvan BrickDb de prijzen uit een productdatafeed van Rakuten Advertising overneemt, lopen via het partnernetwerk Rakuten Advertising, evenals de link naar de LEGO-cadeaukaart bij Giftcards.com die een setpagina aan bezoekers in de VS aanbiedt. De verwerkingsverantwoordelijke is Rakuten Marketing LLC dba Rakuten Advertising, 800 Concar Drive, Suite 175, San Mateo, CA 94402, USA, volgens eigen opgave ook voor bezoekers uit het Verenigd Koninkrijk en de Europese Economische Ruimte. Voor de doeleinden van haar privacyverklaring noemt Rakuten Advertising als vestiging in de EU Rakuten Advertising France S.A.S, 92 rue Réaumur, 75002 Paris, Frankrijk, en in het Verenigd Koninkrijk Rakuten Marketing Europe Limited, Vintners Place, 68 Upper Thames St., London EC4V 2AF, Verenigd Koninkrijk. Ook deze link geeft BrickDb ongewijzigd weer zoals hij in de productdatafeed staat: hij bevat de publisher-identificator van BrickDb, een aanbiedingsidentificator en het bestemmingsadres in de winkel, en niets over u. De link naar de LEGO-cadeaukaart komt niet uit de productdatafeed: Rakuten Advertising heeft hem eenmalig voor BrickDb gegenereerd, en hij bevat evenzo alleen de publisher-identificator van BrickDb, de identificator van Giftcards.com en het bestemmingsadres bij Giftcards.com. Klikt u op een link, dan opent uw browser eerst een adres van Rakuten Advertising (click.linksynergy.com) en wordt hij van daaruit naar de winkel doorgestuurd. Daarbij kan Rakuten Advertising informatie rechtstreeks bij u verzamelen en op zijn eigen domein cookies in uw browser plaatsen of uitlezen om een latere aankoop aan die klik toe te rekenen, volgens de eigen privacyverklaring van Rakuten Advertising. Uw rechten tegenover Rakuten Advertising oefent u uit via diens formulier voor privacyverzoeken; de contactmogelijkheden staan hier. BrickDb plaatst daarvoor geen cookie, registreert de klik niet op de eigen server en geeft zelf geen gegevens over u door aan Rakuten Advertising.

Tradedoubler. De links naar de boekhandel Hugendubel, waarvan BrickDb de prijzen uit een productdatafeed van Tradedoubler overneemt, lopen via het partnernetwerk Tradedoubler. Volgens de eigen privacyverklaring van Tradedoubler is de verwerkingsverantwoordelijke Nyorda AB (Zweden), de moedermaatschappij van de Tradedoubler-groep. Ook deze link geeft BrickDb ongewijzigd weer zoals hij in de productdatafeed staat: hij bevat de publisher-identificator van BrickDb, de identificatoren van het programma en van het product en het bestemmingsadres bij Hugendubel, en niets over u. Klikt u erop, dan opent uw browser eerst een adres van Tradedoubler (pdt.tradedoubler.com) en wordt hij van daaruit naar Hugendubel doorgestuurd. Daarbij kan Tradedoubler informatie rechtstreeks bij u verzamelen en op zijn eigen domein cookies in uw browser plaatsen of uitlezen om een latere aankoop aan die klik toe te rekenen, volgens de eigen privacyverklaring van Tradedoubler. Uw rechten tegenover Tradedoubler oefent u uit via privacy@tradedoubler.com. BrickDb plaatst daarvoor geen cookie, registreert de klik niet op de eigen server en geeft zelf geen gegevens over u door aan Tradedoubler.

Amazon. Als Amazon-partner verdien ik aan in aanmerking komende aankopen. BrickDb neemt deel aan de Amazon-partnerprogramma's voor amazon.com (geëxploiteerd door Amazon.com Services LLC) en amazon.de (geëxploiteerd door Amazon Europe Core S.à r.l.). Een setpagina linkt naar een zoekopdracht in de desbetreffende Amazon-winkel; van Amazon wordt op BrickDb niets geladen - geen script, geen afbeelding, geen prijs en geen logo. Volgt u een dergelijke link, dan bent u op de eigen website van Amazon; daar kan Amazon informatie rechtstreeks bij u verzamelen en cookies in uw browser plaatsen of uitlezen, volgens de eigen privacyverklaring van Amazon. BrickDb ontvangt van Amazon alleen samengevatte rapporten, geen gegevens over afzonderlijke bezoekers.

Een aanvulling sinds de gebruiksmeting: hebt u daarmee volgens punt 10 ingestemd, dan wordt de klik op een dergelijke link bovendien als gebeurtenis in Google Analytics geteld — met het bestemmingsadres, zonder gegevens over wie heeft geklikt, behalve de daar beschreven willekeurige identificator. Zonder uw toestemming gebeurt ook dat niet.

11. Bedrijfsbewaking en foutdiagnose

De applicatie is geïnstrumenteerd met OpenTelemetry. Die gegevens worden alleen geëxporteerd wanneer uitdrukkelijk een bestemming is geconfigureerd; in bedrijf is geen dergelijke bestemming geconfigureerd, zodat deze telemetriegegevens het proces niet verlaten. Aanroepen van de statuseindpunten worden van de registratie uitgezonderd.

Voor foutrapporten wordt daarnaast de dienst Sentry gebruikt. Crasht de app of mislukt op de server een verzoek onverwacht, dan wordt een foutrapport aan Sentry doorgegeven, zodat de fout kan worden gevonden en verholpen. Dat betreft vier plaatsen: de API-server, de webserver, de leesdienst volgens punt 8.5 en — anders dan al het andere in dit punt — de app op uw apparaat. De verbinding met Sentry wordt in alle vier de gevallen door de applicatie zelf opgebouwd; in de website is geen script van een foutrapportagedienst opgenomen, de browser stuurt dus uit zichzelf niets daarheen (punt 10).

De aanbieder is Functional Software, Inc. d/b/a Sentry, 45 Fremont Street, 8th Floor, San Francisco, CA 94105, USA. Zij is in zoverre verwerker in de zin van artikel 28 AVG. Een vestiging in de Europese Unie waarmee een overeenkomst zou kunnen worden gesloten, heeft Sentry volgens eigen opgave niet — de contractpartij is daarmee een onderneming gevestigd in de Verenigde Staten.

Plaats van verwerking: daarvan te onderscheiden is waar de gegevens staan. De rapporten gaan naar de EU-regio van Sentry, die Sentry zelf als European Union (EU) aanduidt en die als opslagregio van onze organisatie is ingesteld. Het ontvangstadres van alle vier de plaatsen luidt op ingest.de.sentry.io en niet op het wereldwijde adres van de dienst. Dat zijn twee verschillende dingen, en alleen het tweede is een hostnaam: het adres waarnaar de software verzendt, tegenover de instelling van het account die bepaalt waar het ontvangene staat.

Doorgifte aan een derde land: omdat de contractpartij in de Verenigde Staten is gevestigd, kan toegang van daaruit — bijvoorbeeld in het kader van ondersteuning en onderhoud — niet worden uitgesloten. Sentry baseert zulke doorgiften op de standaardcontractbepalingen van de Europese Commissie, die aan de verwerkersovereenkomst in versie 5.1.0 van 29 mei 2024 ten grondslag liggen.

Wat een foutrapport bevat: de soort fout en de melding ervan, het technische aanroepverloop (bestanden, methoden, regelnummers), de versie van BrickDb, het opgevraagde adres met zijn queryparameters, voor zover die niet zoals hieronder beschreven worden verwijderd, bij de API-server en de webserver bovendien de headers van het verzoek — bijvoorbeeld de aanduiding van uw browser, de voorkeurstaal en de pagina waarvan u bent gekomen — en de gegevens die de Sentry-SDK uit zichzelf over de omgeving verzamelt — in het bijzonder het apparaatmodel, het besturingssysteem en de versie ervan, de taal en de tijdzone. Op de API-server komt de pseudonieme identificator van uw account erbij als u was ingelogd; de webserver en de app geven helemaal geen identificator door.

Wat de leesdienst meldt: de leesdienst volgens punt 8.5 stuurt alleen een foutrapport wanneer het lezen van een foto onverwacht mislukt; dat hij bezet is of een foto afwijst, meldt hij niet. Een dergelijk rapport bevat de soort fout en de melding ervan, het technische aanroepverloop, de versie van BrickDb, het interne adres waarop de API-server hem heeft aangeroepen, de headers van die interne aanroep — niet die van uw browser — en de gegevens over de serveromgeving. Een identificator van uw account geeft de leesdienst niet door. De ingediende foto is nooit opgenomen in een rapport van de leesdienst, ook niet gedeeltelijk: de inhoud van een verzoek wordt niet vastgelegd, en de leesdienst logt niets over de foto.

Wat de app bovendien vastlegt: opdat een fout op uw apparaat kan worden nagegaan, voegt de app aan een foutrapport een verloopspoor toe. Dat bevat de namen van de laatst geopende pagina's (niet hun adressen); voor elk verzoek aan onze server dat niet is geslaagd, de methode, het adres als patroon zonder identificatoren, de statuscode, de duur en, voor zover bekend, de soort fout; de bij het opstarten vastgelegde instellingen — het adres van de server zonder pad, of aanmelding en foutrapporten zijn ingeschakeld en de ingestelde taal —; en, omdat de Sentry-SDK een eigen verloopspoor voor verzoeken bijhoudt, voor elk verzoek van de app — aan onze server en aan de aanmelddienst — ook het volledige adres met methode en statuscode, met inbegrip van het pad, dat bijvoorbeeld een setnummer of de identificator van een collectie kan bevatten, en van de queryparameters, bijvoorbeeld een zoekterm. Ook uit dit adres worden de hierboven genoemde queryparameters waarvan de naam op een geheim wijst, en e-mailadressen vóór het verzenden verwijderd. Hetzelfde adres kan bovendien in een prestatiemeting staan, die Sentry voor een willekeurig gekozen aandeel van 2 % van de verrichtingen in de app aanmaakt.

Gegevens over het apparaat: elk rapport dat de app na het opstarten verstuurt, bevat het platform, de versie van het besturingssysteem, de soort apparaat (bijvoorbeeld telefoon of tablet) en de versie van de app; zodra de opstartcontrole van de weergave is uitgevoerd, bovendien de soort en de hoofdversie van de webweergave waarin de app draait. Laadt de app een afbeelding, een stijlblad, een script of een lettertype niet, of blokkeert zij inhoud om veiligheidsredenen, dan wordt vastgelegd wat dat was — bij eigen bestanden het pad zonder identificatoren, bij adressen van anderen alleen de naam van de server, bij een lettertype de naam ervan —, en eenmaal bij het opstarten een controle van de weergave: welke stijlbladen zijn geladen, hoeveel regels ze bevatten en welk lettertype daadwerkelijk wordt gebruikt. Een dergelijke laadfout, een serverfout of een verzoek dat helemaal geen antwoord krijgt, kan ook zonder crash een eigen rapport teweegbrengen — dezelfde fout bij een verzoek ten hoogste eenmaal in tien minuten, bij een laadfout ten hoogste eenmaal per start van de app.

Het logboek op uw apparaat: de app schrijft in een logboek in het eigen opslaggebied van de app: elk verzoek aan onze server — ook elk geslaagd verzoek — met methode, adres als patroon zonder identificatoren, statuscode, duur en een willekeurig verzoeknummer; de hierboven genoemde laadfouten; het resultaat van de opstartcontrole van de weergave met de soort en de versie van de webweergave; de bij het opstarten vastgelegde instellingen; en de overige meldingen van de app vanaf het niveau "Information". De namen van de geopende pagina's, de soort van een fout, de gegevens over het apparaat en de volledige adressen uit het eigen verloopspoor van Sentry staan niet in dit logboek. Het omvat ten hoogste drie bestanden van elk één megabyte, de oudste vermeldingen worden overschreven, en elke vermelding wordt bij het schrijven op dezelfde wijze opgeschoond als een foutrapport. Dit logboek verlaat het apparaat niet uit zichzelf. Alleen als u onder "Over BrickDb" op "Diagnosegegevens kopiëren" tikt, plaatst de app de versie van de app, het platform, de versie van het besturingssysteem, de soort apparaat, de bij het opstarten vastgelegde instellingen en tot 200 van de laatste vermeldingen — nogmaals opgeschoond — op het klembord; waar u ze plakt, beslist u zelf.

Wat uitdrukkelijk wordt verwijderd voordat een rapport het apparaat of de server verlaat: alle cookies, de volledige inhoud van een verzoek, elke queryparameter waarvan de naam op een geheim wijst (onder meer code, state, token, password, email, key), elke headerwaarde waarvan de naam op een geheim wijst, elke header waarin onze voorgeschakelde servers uw IP-adres doorgeven, en e-mailadressen en tekenreeksen die op een token lijken — ook midden in een foutmelding. Een gebruikersnaam, een e-mailadres of een IP-adres in het gebruikersgedeelte van het rapport wordt overschreven voordat het rapport wordt verzonden, evenals de installatie-identificator die de SDK daar uit zichzelf invult. Die opschoning is zo gebouwd dat zij bij een fout het rapport weggooit in plaats van het ongefilterd te verzenden.

De applicatie zelf geeft geen IP-adres door: SendDefaultPii staat op alle vier de plaatsen op false, de zojuist beschreven opschoning overschrijft dat veld hoe dan ook, en zij verwijdert ook de headers waarin onze voorgeschakelde servers uw IP-adres aan de webserver en de API-server doorgeven. Schermafbeeldingen worden niet bijgevoegd, en de teksten van de gebruikersinterface worden niet in de verloopsporen opgenomen; beide zijn uitdrukkelijk uitgeschakeld. Foto's kunnen een foutrapport niet bereiken, omdat de inhoud van een verzoek hoe dan ook volledig wordt verwijderd.

Prestatiemetingen op de server: ongeacht of er een fout optreedt, maken de webserver, de API-server en de leesdienst voor een willekeurig gekozen aandeel van de verzoeken een prestatiemeting aan en geven die door aan Sentry, zodat trage plekken kunnen worden gevonden; aanroepen van de statuseindpunten en de testverzoeken van onze voorgeschakelde servers zijn daarvan uitgezonderd. Het aandeel bedraagt 5 %. Komt een verzoek echter van de app, van de webserver of van de API-server en hoort het bij een verrichting waarvoor daar al is beslist of zij wordt gemeten, dan neemt de server die beslissing over, zodat een dergelijke verrichting ofwel op alle stations wordt gemeten, ofwel op geen enkel. Een dergelijke meting bevat dezelfde gegevens over het verzoek als een foutrapport van de server — de methode, het opgevraagde adres met zijn queryparameters, bijvoorbeeld een zoekterm, en de headers van het verzoek —, en daarnaast het patroon van het opgevraagde adres zonder identificatoren, de statuscode van het antwoord, het begin en de duur van de verwerking en de meldingen die de applicatie intussen logt. Daar komen de afzonderlijke stappen met hun duur bij: de verzoeken die de server daarbij zelf doet — bijvoorbeeld de webserver aan de API-server of de API-server aan de aanmelddienst —, telkens met methode, volledig adres en statuscode, en de databasequery's met hun tekst, waarin ingevoegde waarden alleen als plaatshouders staan en niet de waarden zelf. Op de API-server draagt de meting de pseudonieme identificator van uw account als u was ingelogd; de webserver en de leesdienst geven geen identificator door. Bij de leesdienst betreft een meting alleen de interne aanroep door de API-server; hij doet daarbij zelf geen verzoeken aan andere servers en geen databasequery's, en de foto is ook in een meting nooit opgenomen. Voor elke prestatiemeting geldt dezelfde opschoning als voor een foutrapport, zoals hierboven beschreven; in het bijzonder worden de cookies en de headers met uw IP-adres vóór het verzenden verwijderd. De rechtsgrond is artikel 6, lid 1, onder f), AVG; het gerechtvaardigd belang ligt in het snel en betrouwbaar exploiteren van de applicatie. Een volledige prestatiemeting bewaart Sentry in ons tarief ten hoogste 90 dagen; een verkleinde steekproef van de metingen kan Sentry tot 13 maanden bewaren.

Het IP-adres van de verbinding bewaart Sentry niet. Bij het verzenden van een rapport wordt een internetverbinding opgebouwd; het adres van waaruit is verzonden, is de ontvangende partij tijdens de overdracht daarmee onvermijdelijk bekend. Sentry biedt een instelling aan die dat adres weggooit in plaats van het te registreren, en die instelling is voor alle vier de projecten ingeschakeld — die van de API-server, de webserver, de leesdienst en de app. Een foutrapport behoudt het adres daarom niet. Dat geldt ook voor de rapporten van de app, waarbij het het adres van uw eigen internetaansluiting zou zijn; bij de API-server, de webserver en de leesdienst zou het het adres van onze eigen servers zijn.

Voor de overdracht geldt al het overige van dit punt ongewijzigd: de ontvanger is Functional Software, Inc. d/b/a Sentry, de rapporten gaan naar de hierboven genoemde opslagregio, en de doorgifte berust op de hierboven beschreven standaardcontractbepalingen. De eigen opschoning van Sentry aan de serverzijde is voor alle vier de projecten — die van de API-server, de webserver, de leesdienst en de app — in haar basisvorm ingeschakeld; wij hebben er geen eigen regels aan toegevoegd en geen van haar regels verwijderd.

Rechtsgrond: artikel 6, lid 1, onder f), AVG — voor het foutrapport en voor het IP-adres bij de overdracht ervan in gelijke mate. Het gerechtvaardigd belang ligt in het herkennen en verhelpen van fouten en crashes. Het adres wordt voor geen enkel eigen doel verwerkt en niet gebruikt om u te herkennen. Het is dezelfde grondslag waarop punt 3 het IP-adres verwerkt dat bij elke verbinding met de website onvermijdelijk ontstaat. U kunt daartegen op grond van artikel 21 AVG bezwaar maken via de contactgegevens in punt 2.

Bewaartermijn: 90 dagen. Hoe lang een foutrapport bij Sentry wordt bewaard, volgt uit het tarief waarin de organisatie valt. De onze valt in het tarief "Business", waarvoor Sentry een bewaring van 90 dagen publiceert; in het tarief "Developer" zouden het er 30 zijn. Bijlagen volgen de gebeurtenis waarbij ze horen. Voor een afzonderlijk project kan een kortere termijn worden ingesteld, die dan voorgaat; geen van onze vier projecten heeft er een, zodat de 90 dagen voor alle vier in gelijke mate gelden.

12. Ontvangers

Persoonsgegevens worden niet verkocht en niet voor reclamedoeleinden doorgegeven. De ontvangers zijn op dit moment Microsoft Ireland Operations Limited, als verwerker voor hosting, database en bestandsopslag en — uitsluitend op uw uitdrukkelijk verzoek volgens punt 8.6 — voor de beeldbeoordeling door Azure OpenAI, en Twilio Inc. (“SendGrid”) als verwerker voor de verzending van e-mail volgens punt 7.3, met inbegrip van de daar beschreven verwerking in de Verenigde Staten. Hebt u met de gebruiksmeting volgens punt 10 ingestemd, dan komt voor de duur daarvan Google Ireland Limited als verdere verwerker erbij; zonder uw toestemming ontvangt zij niets. Voor het inloggen volgens punt 7.1 is Auth0 / Okta, Inc. verwerker, en voor de foutrapporten volgens punt 11 Functional Software, Inc. d/b/a Sentry; beide zijn gevestigd in de Verenigde Staten en baseren de doorgifte op de standaardcontractbepalingen van de Europese Commissie, zoals in de genoemde punten beschreven. Goedgekeurde gegevens van evenementen zijn openbaar zoals in punt 8.4 beschreven; de koppeling met het account hoort daar niet bij. Daarbuiten worden gegevens alleen doorgegeven wanneer daartoe een wettelijke verplichting bestaat.

13. Bewaartermijnen

• Collectiegegevens en foto's: tot verwijdering door de betrokkene of tot verwijdering van het account.
• Instellingen op het eindapparaat: zie punt 6.1.
• Accountgegevens bij de identiteitsdienstverlener (punten 7.1 en 7.2): tot verwijdering van het account, waarbij het account bij Auth0 mee wordt verwijderd.
• Gebruiksmeting: tot 14 maanden na de laatste interactie voor gegevens op gebeurtenis- en gebruikersniveau bij Google, 182 dagen voor het toestemmingscookie op uw apparaat — zie punt 10.
• Inzendingen van evenementen: de naar status onderscheiden bewaartermijnen uit punt 8.4.
• Supportverzoeken: 24 maanden na afsluiting van het ticket — zie punt 8.7, ook voor de reden waarom de termijn vanaf de afsluiting en niet vanaf de binnenkomst loopt.
• Meldingen over inhoud: 24 maanden na de beslissing — zie punt 8.8, ook voor de reden waarom de termijn vanaf de beslissing en niet vanaf de binnenkomst loopt en waarom een melding waarover nog niet is beslist, niet wordt verwijderd.
• Handelingen van de beheerders met betrekking tot gebruikersaccounts (het auditlogboek): 24 maanden na de handeling — zie punt 8.9, ook voor wat er overblijft wanneer het account wordt verwijderd. Accountgegevens en aanmeldgeschiedenis die aan de beheerders worden getoond, worden live bij Auth0 gelezen en door BrickDb niet opgeslagen.
• Foto's voor het lezen van het setnummer (punt 8.5) en voor de beoordeling van de staat (punt 8.6): worden bij BrickDb niet opgeslagen en na afloop van het verzoek weggegooid.
• Verzonden e-mails: bij BrickDb wordt geen kopie gemaakt; voor de afleveringsgegevens bij de verzenddienstverlener zie punt 7.3.
• Logboeken op infrastructuurniveau: zie punt 3.
• Foutrapporten bij Sentry: 90 dagen — zie punt 11; het IP-adres van de verbinding waarlangs ze zijn afgeleverd, bewaart Sentry niet.
• Prestatiemetingen bij Sentry: volledig ten hoogste 90 dagen, als verkleinde steekproef tot 13 maanden — zie punt 11.

Wordt een vermelding verwijderd, dan worden de bijbehorende foto's mee verwijderd — met inbegrip van de verkleinde versies volgens punt 8. Uit back-ups verdwijnen verwijderde gegevens wanneer die back-ups volgens hun gewone verloop vervallen, uiterlijk na 35 dagen.

14. Rechten van de betrokkenen

De volgende rechten bestaan:

• Inzage in de verwerkte gegevens (artikel 15 AVG),
• Rectificatie van onjuiste gegevens (artikel 16 AVG),
• Gegevenswissing (artikel 17 AVG),
• Beperking van de verwerking (artikel 18 AVG),
• Gegevensoverdraagbaarheid (artikel 20 AVG),
• Bezwaar tegen verwerkingen die op artikel 6, lid 1, onder f), AVG zijn gebaseerd (artikel 21 AVG),
• Intrekking van een gegeven toestemming met werking voor de toekomst (artikel 7, lid 3, AVG).

Om ze uit te oefenen volstaat een vormvrij bericht aan het in punt 2 genoemde e-mailadres.

Het recht van inzage volgens artikel 15 AVG kan bovendien rechtstreeks en zonder bericht worden uitgeoefend: de accountpagina maakt een volledige, machineleesbare kopie van alle opgeslagen gegevens — account en profiel, collecties met hun leden en de door u verstuurde uitnodigingen, de exemplaren daarin met notities, tags, staat, aankoopprijzen en aantekeningen over de verkoper, afzonderlijke minifiguren en losse onderdelen, uw exemplaren van tijdschriftnummers en boeken, uw opbergplekken en welk exemplaar op welke daarvan ligt, vastgelegde handtekeningen, de verlanglijst, de eigen bijdragen aan zakjescodes en verpakkingsbarcodes, de eigen inzendingen van evenementen in elke moderatiestatus, ingediende batches van doosfoto's, de vermeldingen van het auditlogboek van de beheerders over uw account (punt 8.9), elke geüploade foto en uw avatarafbeelding als u er een hebt geüpload.

Wat die kopie niet bevat, en waarom: de inloggegevens bij de identiteitsdienstverlener (e-mailadres, wachtwoord, aanmeldgeschiedenis, vastgelegde tweede factoren) — die berusten bij Auth0, dat daarover zelf inzage verleent; uitnodigingen die anderen aan uw adres hebben gericht, omdat het hun gegevens zijn en niet de uwe; de uit uw exemplaren afgeleide onderdelenweergave, omdat zij niets bevat wat niet toch al in de kopie staat; supportverzoeken — en wel allemaal, omdat in deze versie geen ticket aan een account is gekoppeld en wij niet kunnen herkennen welke van u zijn (punt 8.7 zegt hoe u ons daarover bereikt); interne notities bij een supportticket, die van ons zijn en niet van u (eveneens punt 8.7); de korte aantekening van een mail aan het supportadres die geen ticket is geworden, omdat zij aan geen account is gekoppeld (punt 8.7); meldingen over inhoud, die evenmin aan een account zijn gekoppeld, en de notities die wij bij de beslissing over een melding over uw inhoud hebben geschreven (punt 8.8); welke beheerder met betrekking tot uw account heeft gehandeld, omdat dat de gegevens van die persoon zijn en niet de uwe (punt 8.9); en de in de wachtrij geplaatste melding bij een door u ingediend evenement, die alleen verzendmechaniek bevat en verwijst naar de hierboven al genoemde inzending.

Ook het recht op gegevenswissing volgens artikel 17 AVG kan daar rechtstreeks worden uitgeoefend. De accountpagina toont vooraf wat er precies wordt verwijderd; na bevestiging wordt de verwijdering onmiddellijk uitgevoerd: de collectie, de opbergplekken, de foto's (de bestanden zelf, niet alleen de vermeldingen) en het inlogaccount bij de identiteitsdienstverlener. Dat kan niet ongedaan worden gemaakt.

De uitzonderingen zijn bewust zo geregeld; voor evenementen geldt punt 8.4. De eigen bijdragen aan de zakjescodes worden geanonimiseerd in plaats van verwijderd: welke figuur in een zakje zit, is een feit over een LEGO-product dat andere gebruikers samen hebben vastgesteld en waarop zij vertrouwen — de bijdrage blijft bestaan, de koppeling met de persoon wordt vervangen door een nieuw getrokken willekeurige waarde waarvoor geen account en geen herleiding meer bestaat (overweging 26 AVG). Een exemplaar dat in een met andere personen gedeelde collectie is ingebracht, wordt op dezelfde wijze geanonimiseerd in plaats van verwijderd: het verwijderen ervan zou de andere deelnemers hun vermelding van een gezamenlijk bijgehouden set ontnemen. Setnummer, aantal en staat blijven daarom bij de collectie; al het persoonlijke eraan vervalt — de zelf gegeven bijnaam, de notities, de tags, de bewaarplaats, de betaalde prijs, de eigen waardeschatting en de foto's — samen met de koppeling met de persoon, vervangen door een evenzo nieuw getrokken willekeurige waarde. Een exemplaar in een collectie waarin verder niemand zit, wordt volledig verwijderd — er is niemand aan wie het zou worden ontnomen. En back-ups blijven punt 13 volgen: verwijderde gegevens verdwijnen daar bij het gewone verloop ervan, uiterlijk na 35 dagen.

De afzonderlijke stappen, een opsomming van wat wordt verwijderd en wat geanonimiseerd bewaard blijft, en de weg voor personen die niet meer kunnen inloggen, staan samengevat op de pagina Verwijdering van account en gegevens. Die is zonder inloggen bereikbaar en geeft alleen weer wat in dit punt staat.

Recht om een klacht in te dienen

Los daarvan bestaat op grond van artikel 77 AVG het recht om een klacht in te dienen bij een toezichthoudende autoriteit, met name in de lidstaat van de gewone verblijfplaats, van de plaats van het werk of van de plaats van de beweerde inbreuk. De voor de verwerkingsverantwoordelijke bevoegde autoriteit is:

Landesbeauftragte für Datenschutz und Informationsfreiheit Nordrhein-Westfalen
Postfach 20 04 44
40102 Düsseldorf
Telefoon: +49 211 38424-0
E-mail: poststelle@ldi.nrw.de
www.ldi.nrw.de

15. Verplichting om gegevens te verstrekken

Het verstrekken van gegevens is wettelijk noch contractueel voorgeschreven. Zonder gegevens kunnen de collectiefuncties echter niet zinvol worden gebruikt; de vrij toegankelijke delen van de dienst staan zonder enig gegeven open.

16. Wijzigingen en bindende taalversie

Deze verklaring wordt aangepast wanneer de verwerking of de rechtstoestand verandert. Bindend is de telkens hier gepubliceerde versie met de hierboven vermelde datum.

De Duitse versie is bindend. De versies in het Engels, Frans, Nederlands, Deens, Italiaans en Spaans zijn vertalingen ter informatie en hebben geen zelfstandige rechtskracht.