Política de privacidad

1. En resumen

Todo lo que figura en esta política se ha comprobado con el código fuente de la aplicación. Si necesita alguna aclaración al respecto, diríjase a nosotros mediante los datos de contacto del apartado 2.

BrickDb es un servicio de ThreeB IT GmbH, sin anuncios publicitarios. Esta política describe los datos que realmente se tratan, no lo que suele figurar en textos de este tipo.

• Para la medición de uso con Google Analytics se le pide su consentimiento. Sin él no tiene lugar: no se carga ningún script, no se establece ningún identificador y no se envía nada a Google. Más detalles en el apartado 10.
• Sin su consentimiento, al abrir una página no se establece ninguna conexión con un tercero. También las fuentes tipográficas se encuentran en nuestro propio servidor.
• Las fotos son visibles únicamente para usted y para los miembros a los que usted haya dado acceso a los datos privados en una colección compartida; no aparecen en la página pública de una colección. Más detalles en el apartado 8.2. Los metadatos incrustados — entre ellos las coordenadas GPS — se eliminan durante el tratamiento.
• En el dispositivo no se almacena nada por lo que se le pudiera reconocer antes de que usted haya elegido activamente un ajuste, haya iniciado sesión o haya dado su consentimiento. Lo que el navegador necesita por razones puramente técnicas para la seguridad de los formularios y lo que sustenta su inicio de sesión figura íntegramente en el apartado 6.1; lo que la aplicación guarda en el dispositivo figura en el apartado 6.5. Puede cambiar en cualquier momento su decisión sobre la medición de uso, al pie de cada página.

2. Responsable del tratamiento

El responsable del tratamiento en el sentido del artículo 4, punto 7, del RGPD es:

ThreeB IT GmbH
Bergstrang 105
49479 Ibbenbüren
Alemania
Teléfono: +49 (5451) 893922-0
Correo electrónico: hello@brickdb.net

Representada por sus administradores (Geschäftsführer) Thimo Buchheister y Thorsten Brügge.

No se ha designado un delegado de protección de datos.

3. Visita al sitio web

Al acceder a www.brickdb.de o a una de las demás direcciones en las que BrickDb está disponible (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), el servidor web trata los datos que un navegador debe transmitir por razones técnicas para que pueda entregarse una página: la dirección IP, la fecha y la hora de la solicitud, la dirección solicitada, el volumen de datos transferido y el código de estado, el identificador del navegador y del sistema operativo (User-Agent) y la preferencia de idioma enviada por el navegador (Accept-Language).

Estos datos se generan necesariamente en toda conexión a internet. Se tratan para entregar la página, garantizar el funcionamiento técnico y repeler ataques.

La preferencia de idioma tiene otro uso más, estrictamente limitado: la indicación de región que contiene (por ejemplo DE en de-DE) se lee mientras se responde a la solicitud para preseleccionar un país: en la lista de eventos y para los precios de las páginas de sets y minifiguras, es decir, de qué tiendas se muestran precios, a qué tienda de Amazon se enlaza y en qué moneda se muestran los precios. Si ha iniciado sesión y ha indicado un país en su perfil (apartado 7.2), se utiliza ese país en su lugar. Un país que usted mismo haya elegido y guardado en el sitio (apartado 6.1, bd-country) prevalece sobre ambos. La indicación de región no se almacena, no se combina con otros datos y no se comunica a nadie; el país elegido aparece de forma visible en la página — en la lista de eventos también en la barra de direcciones — y puede anularse allí con un clic.

En las direcciones asignadas a un país (por ejemplo www.brickdb.de o www.brickdb.fr), el país resulta de la propia dirección. En www.brickdb.net y www.brickdb.eu, que no están asignadas a un único país, se añade un dato más: la red de distribución antepuesta al sitio (Azure Front Door, un servicio del encargado del tratamiento Microsoft mencionado en el apartado 4) deduce allí, en el borde de la red, a partir de la dirección IP de la solicitud, un código de país de dos letras (por ejemplo SE) y se lo transmite a la aplicación. Sirve al mismo fin que la indicación de región: preseleccionar un país para los precios y los eventos. La aplicación no recibe nada más que ese código y, en particular, ninguna ubicación más precisa; el código no se almacena, no se registra y no se combina con otros datos. No se utiliza ningún servicio de geolocalización de terceros; la dirección IP no se revela con este fin a nadie que no la trate de todos modos para entregar la página. La base jurídica de ello es el artículo 6, apartado 1, letra f), del RGPD; el interés legítimo consiste en mostrarle precios y eventos de su propio país sin preguntarle antes por él. Puede usted anularlo en cualquier momento eligiendo un país en el propio sitio (apartado 6.1, bd-country).

Base jurídica: artículo 6, apartado 1, letra f), del RGPD. El interés legítimo consiste en el funcionamiento técnicamente correcto y seguro del servicio.

Plazo de conservación: La aplicación en sí no lleva ningún registro de accesos. Los registros que se generan en el nivel de la infraestructura se conservan únicamente mientras sea necesario para la seguridad operativa, y como máximo 30 días, salvo que se necesiten para esclarecer un incidente de seguridad concreto.

4. Alojamiento

El servicio se opera en Microsoft Azure; el proveedor es Microsoft Ireland Operations Limited, One Microsoft Place, South County Business Park, Leopardstown, Dublin 18, Irlanda. Como lugar de tratamiento se ha elegido la región de Azure Germany West Central (Frankfurt am Main); la base de datos y el almacenamiento de archivos se encuentran, por tanto, en Alemania.

En esta medida, Microsoft es encargado del tratamiento conforme al artículo 28 del RGPD sobre la base del Microsoft Products and Services Data Protection Addendum.

Las solicitudes dirigidas a BrickDb pasan por la red de distribución Azure Front Door de Microsoft. Esta recibe la conexión en una ubicación cercana a usted — que puede encontrarse fuera de Alemania y fuera de la UE y del EEE — y la reenvía; la aplicación y todos los datos almacenados permanecen en Germany West Central (Frankfurt am Main). También esto tiene lugar en el marco del encargo del tratamiento sobre la base del Microsoft Products and Services Data Protection Addendum; en la medida en que ello implique una transferencia a un tercer país, se aplica lo que el párrafo siguiente dice de Microsoft bajo «Transferencia a terceros países».

Transferencia a terceros países: No puede excluirse por completo un acceso desde terceros países en el marco de operaciones de soporte y mantenimiento. Microsoft basa tales transferencias en las cláusulas contractuales tipo de la Comisión Europea y, además, está certificada conforme al EU-US Data Privacy Framework.

5. Fuentes tipográficas y contenidos externos

Las fuentes tipográficas utilizadas se entregan desde nuestro propio servidor. No se cargan fuentes desde servidores de terceros — en particular, no desde Google Fonts. No hay mapas, vídeos, complementos de redes sociales ni otros contenidos incrustados de terceros.

Sin su consentimiento, al abrir una página no se establece ninguna conexión con un tercero ni se transmite ninguna dirección IP a un tercero.

La única excepción es la medición de uso del apartado 10, y no es una limitación de esa frase, sino su condición: el script de Google solo se carga después de que usted haya aceptado en el banner de consentimiento. Mientras no haya aceptado o rechazado, no se carga nada de Google — tampoco un aviso previo de los denominados sin cookies.

6. Almacenamiento en el dispositivo

BrickDb no establece ninguna cookie con fines de marketing o de publicidad. Se almacena exclusivamente lo que registra un ajuste elegido de forma consciente, lo que exige la seguridad de los formularios, lo que sustenta su inicio de sesión si inicia sesión — y, si ha aceptado la medición de uso del apartado 10, las cookies de análisis allí descritas. Ninguna de las cookies de análisis se establece antes de que usted acepte.

6.1 Qué se almacena

Las cinco primeras entradas contienen exclusivamente el último valor seleccionado. No contienen ningún identificador ni nada que permita reconocer a una persona o un dispositivo. Las cinco son almacenamiento de origen propio; ningún tercero tiene acceso a ellas. Cada una de ellas vale solo para la dirección en la que se estableció: una elección hecha en www.brickdb.de no se lee en www.brickdb.fr. bd-country se crea cuando usted elige y guarda un país, y bd-market-hint cuando cierra el aviso de que existe una dirección propia para su país — su única función es que ese aviso no vuelva a mostrarse en cada página. bd-analytics-consent se establece además como HttpOnly, porque ningún script del navegador necesita leerla: si la medición de uso se ejecuta lo decide el servidor antes de que exista la página.

La sexta entrada la establece el framework web utilizado en toda página que contenga un formulario — es decir, también en la página en la que está el banner de consentimiento. Protege esos formularios frente a su envío desde un sitio ajeno (cross-site request forgery), no contiene ningún dato sobre usted, es HttpOnly y SameSite=Strict y termina con la sesión. En el banner de consentimiento es la razón por la que nadie desde fuera puede provocar una aceptación en su nombre.

Las dos entradas siguientes solo se crean cuando usted inicia sesión. bd.auth mantiene su sesión iniciada; su contenido está cifrado, es HttpOnly y Secure y solo se envía a este sitio (SameSite=Lax). No se prolonga por sí sola: la sesión termina con la validez del inicio de sesión y no cuando usted deja de hacer clic. Al cerrar sesión se elimina. Las dos cookies de negociación las establece el framework solo mientras dura un único proceso de inicio de sesión; vinculan el regreso desde la pantalla de inicio de sesión precisamente al proceso que usted comenzó, y después se eliminan.

La última entrada son las cookies de análisis del apartado 10. Se establecen exclusivamente después de su consentimiento y contienen un identificador aleatorio con el que se reconocen las visitas repetidas desde el mismo navegador.

6.2 Por qué no se requiere consentimiento para ninguna entrada salvo las cookies de análisis

La disposición determinante es el artículo 25 de la ley alemana de protección de datos en las telecomunicaciones y los servicios digitales (TDDDG). Abarca todo almacenamiento de información en el equipo terminal y todo acceso a ella — es decir, no solo las cookies, sino expresamente también el almacenamiento local. Conforme al artículo 25, apartado 2, número 2, de la TDDDG, el consentimiento no es necesario cuando el almacenamiento es estrictamente necesario para prestar un servicio expresamente solicitado por el usuario.

Ese es el caso aquí, y por razones que pueden comprobarse en el comportamiento de la aplicación:

• Antes de una elección activa no se almacena nada. El mero hecho de abrir la página no escribe ninguna entrada. Una entrada se crea exclusivamente cuando se accionan los selectores de apariencia o de idioma, cuando usted elige y guarda un país o cuando cierra el aviso que remite a la dirección de otro país.
• Volver al valor predeterminado borra de nuevo la entrada. Si se elige "Sistema", la entrada correspondiente se elimina en lugar de sobrescribirse.
• Se almacena exactamente el ajuste que se solicitó de forma expresa, y nada más.
• Para bd-analytics-consent vale lo mismo por una razón propia: registra la decisión que usted acaba de tomar. Sin ella, la pregunta tendría que plantearse de nuevo en cada página — también a quien acaba de rechazar.
• La cookie antifalsificación es el caso más claro de los tres: sin ella, un formulario de este sitio ya no puede protegerse frente al uso indebido desde fuera, y eso afecta también al botón con el que usted acepta o rechaza la medición de uso. No se almacena porque se quiera medir algo, sino para que la entrada que cuente sea la suya propia.
• Para las tres cookies de inicio de sesión es donde resulta más evidente: sin ellas no se puede ni realizar ni mantener un inicio de sesión. Quien inicia sesión solicita exactamente el servicio que prestan, y solo se crean en el momento en que se solicita — quien no inicia sesión no recibe ninguna de ellas.

Un ajuste que se recuerda a petición expresa es, por tanto, estrictamente necesario para prestar el servicio solicitado; para la seguridad de los formularios y para el inicio de sesión eso vale en cualquier caso. Por ello no se recaba consentimiento para estas entradas.

Oposición y eliminación: Las entradas de apariencia e idioma pueden eliminarse en cualquier momento eligiendo de nuevo "Sistema" en el selector o borrando los datos del navegador. El sitio funciona sin ellas sin cambios; se muestra entonces con la apariencia y el idioma que determinen el sistema operativo o el navegador, respectivamente. Las entradas del país y del aviso cerrado las elimina usted borrando los datos del navegador; sin ellas, el país vuelve a preseleccionarse como describe el apartado 3.

6.3 Cookies de análisis — solo después del consentimiento

El artículo 25, apartado 2, número 2, de la TDDDG no se aplica a las cookies de la medición de uso: una medición de uso no es necesaria para el servicio que usted ha solicitado, y el sitio funciona íntegramente sin ella. Quedan, por tanto, comprendidas en el artículo 25, apartado 1, de la TDDDG y solo se establecen después de que usted haya aceptado en el banner de consentimiento. El banner aparece en la primera página que usted abre y ofrece aceptar y rechazar como dos botones del mismo tamaño, uno junto al otro — ambas cosas son un único clic.

6.4 Datos de conexión técnicamente necesarios

La interfaz de usuario se renderiza en el servidor y mantiene, mientras se usa, una conexión WebSocket con el servidor. El estado de sesión correspondiente se encuentra exclusivamente en la memoria del servidor, no se almacena en el dispositivo y termina al cerrar la página.

6.5 En la aplicación

La aplicación BrickDb para dispositivos móviles y ordenadores muestra las mismas páginas, pero no guarda nada en un almacenamiento del navegador. Allí, los ajustes de apariencia e idioma se encuentran en el almacén de ajustes del sistema operativo y contienen, como en el apartado 6.1, solo el último valor elegido.

Si inicia sesión en la aplicación, su sesión se guarda en el almacenamiento protegido del dispositivo — en el llavero (Keychain) en iOS y macOS, en el almacenamiento protegido por Keystore en Android. Se guardan cuatro cosas: el token de acceso, el token de actualización, el momento de caducidad y la indicación de la vía por la que usted inició sesión.

A ello se añade el token de identidad, y es el único de estos elementos que contiene datos sobre su persona. Lo emite Auth0 al iniciar sesión y se guarda allí porque la aplicación lee en él a quién tiene delante. Contiene el identificador de su cuenta en el proveedor de identidad, su nombre y su dirección de correo electrónico, la indicación de si la dirección está confirmada y un valor técnico de un solo uso procedente del proceso de inicio de sesión. Estos datos se encuentran, por tanto, en el dispositivo, aunque conforme al apartado 7.1 no se incorporan a nuestra base de datos. No hay entre ellos ninguna contraseña, porque la aplicación no recibe ninguna (apartado 7.1).

Los cinco elementos se eliminan al cerrar sesión. En el dispositivo no se conserva ninguna copia de su colección, y no se almacenan temporalmente cambios para una transmisión posterior.

7. Cuenta de usuario

7.1 Inicio de sesión

BrickDb puede utilizarse sin cuenta: el catálogo, la búsqueda y el escáner están abiertos sin iniciar sesión. Solo necesita una cuenta para llevar una colección propia.

El inicio de sesión se realiza a través del proveedor de identidad Auth0 (Okta, Inc.), mediante un inquilino situado en la Unión Europea. Se ofrecen tres vías: una cuenta con dirección de correo electrónico y contraseña, el inicio de sesión con una cuenta de Google existente o el inicio de sesión con su cuenta de Apple ("Iniciar sesión con Apple"). Cuál de ellas utiliza lo decide usted. Esto vale por igual para el sitio web y para la aplicación.

El formulario de inicio de sesión es una página de Auth0, no de BrickDb. Una contraseña no se introduce, no se recibe ni se transmite en ninguna página de BrickDb; también el cambio de contraseña tiene lugar en Auth0. Quien inicia sesión con Google o con Apple no tiene ninguna contraseña en Auth0 — las credenciales se encuentran entonces en Google o en Apple, y BrickDb tampoco las ve. Con "Iniciar sesión con Apple" puede elegir además ocultar su dirección de correo electrónico: BrickDb recibe entonces una dirección del servicio de reenvío de Apple (terminada en @privaterelay.appleid.com), a través de la cual Apple le reenvía nuestros correos electrónicos.

Qué recibe BrickDb. Tras un inicio de sesión correcto, Auth0 entrega los datos que se solicitaron: un identificador seudónimo de su cuenta, los datos de perfil guardados con el inicio de sesión y su dirección de correo electrónico. De ello no se almacena nada salvo el identificador seudónimo y el momento en que se creó el registro — ese es el contenido íntegro de nuestro propio registro de cuenta. El nombre, el perfil y la dirección de correo electrónico permanecen en Auth0 y se leen allí cuando se necesitan (apartado 7.2); no se incorporan a nuestra base de datos.

La autenticación en dos pasos se ofrece y nunca se exige. Quien lo desee puede registrar una aplicación de autenticación (TOTP), una clave del dispositivo como Face ID, Touch ID o Windows Hello, una llave de seguridad física y códigos de recuperación. Sin tal registro no se le pide a nadie. Los códigos por SMS o por correo electrónico no se ofrecen, de forma deliberada.

Qué trata Auth0 al hacerlo. Auth0 trata las propias credenciales de inicio de sesión y los datos técnicos de cada inicio de sesión — momento, dirección IP e identificador del navegador y del dispositivo — para realizar el inicio de sesión y detectar intentos de inicio de sesión abusivos. Al crear una cuenta y en cada cambio de contraseña, Auth0 comprueba además si la contraseña elegida ha aparecido en una filtración de datos conocida y, en ese caso, la rechaza. En un inicio de sesión ordinario esta comprobación no tiene lugar.

Base jurídica: artículo 6, apartado 1, letra b), del RGPD — sin cuenta no pueden prestarse las funciones de colección. Para la detección de intentos abusivos y la comprobación frente a contraseñas filtradas conocidas, artículo 6, apartado 1, letra f), del RGPD; el interés legítimo consiste en la seguridad de las cuentas. En esta medida, Auth0 es encargado del tratamiento conforme al artículo 28 del RGPD.

Transferencia a terceros países: el inquilino se encuentra en la Unión Europea, y allí tiene lugar el inicio de sesión. No obstante, la parte contratante es Okta, Inc. (Auth0), con sede en los Estados Unidos, de modo que no puede excluirse un acceso desde allí — por ejemplo, en el marco del soporte y el mantenimiento. Okta basa tales transferencias en las cláusulas contractuales tipo de la Comisión Europea, adjuntas como documentos independientes al contrato de encargo del tratamiento de 15 de diciembre de 2023.

Plazo de conservación: el registro de cuenta existe hasta que usted elimine su cuenta. La eliminación en la página de la cuenta elimina también la cuenta en Auth0 y, con ella, los datos allí guardados (apartado 14).

7.2 Perfil: nombre, texto de presentación, país y dirección opcional

Puede indicar un nombre, unos apellidos, un texto breve sobre usted, su país, uno de nuestros dibujos de avatar y — de forma opcional — una dirección postal completa.

Nada de ello se almacena en BrickDb. Estos datos se encuentran en el proveedor de identidad Auth0, junto a su cuenta de inicio de sesión; BrickDb los lee y los escribe allí en lugar de conservar una copia: nuestro propio registro de cuenta no contiene nada más que un identificador seudónimo y el momento de su creación. Si elimina su cuenta conforme al apartado 14, se elimina la cuenta de Auth0 y, con ella, este perfil.

Todos los datos son voluntarios. Nada de ello es obligatorio, nada es condición para utilizar BrickDb y no se le priva de ninguna función por dejar un campo vacío. Puede modificar o borrar cualquiera de estos datos en cualquier momento.

Por qué se pregunta, en particular, por la dirección. Dos fines, ambos indicados aquí antes de que se ofrezca el campo, y no después:

• Valoración para el seguro. BrickDb ofrecerá una valoración de una colección a efectos de seguro. Tal valoración está vinculada al lugar en el que se guarda la colección; una aseguradora no la acepta sin ese dato.
• Un mercado previsto con BrickDb como fiduciario. BrickDb tiene la intención de ofrecer un mercado en el que BrickDb actúe como fiduciario entre comprador y vendedor. La dirección postal de una parte es lo que hace que tal operación sea atribuible y que un litigio pueda resolverse.

Ninguno de los dos servicios existe todavía. La dirección no se utiliza para nada más: ni para publicidad, ni para la elaboración de perfiles, ni para forma alguna de puntuación (scoring), y no se comunica a terceros.

Su país se utiliza además para preseleccionar un país en la lista de eventos y para los precios de las páginas de sets y minifiguras, con prioridad sobre la preferencia de idioma del navegador descrita en el apartado 3. Para ello se lee en Auth0 al abrir una página de ese tipo, BrickDb no lo almacena ni lo comunica con ese fin, y la elección puede anularse en la página con un clic.

El país y el idioma que usted elige en el sitio. Si, con la sesión iniciada, elige y guarda un país y un idioma para el sitio, ambos se guardan, además de en las entradas del navegador (apartado 6.1), junto a su cuenta de inicio de sesión en Auth0, para que la elección valga también en otro dispositivo y en otra dirección de BrickDb. BrickDb tampoco conserva una copia propia de ello. Si no ha iniciado sesión, la elección permanece únicamente en el navegador.

Base jurídica: para el nombre, los apellidos, el texto de presentación, el país y el idioma elegido, artículo 6, apartado 1, letra b), del RGPD — el tratamiento forma parte del servicio solicitado. Para la dirección, artículo 6, apartado 1, letra a), del RGPD — consentimiento, otorgado al rellenar el campo y revocable en cualquier momento borrándolo. La retirada no afecta en lo demás a su cuenta y no afecta a la licitud del tratamiento efectuado hasta ese momento.

El perfil está incluido en la copia de sus datos conforme al apartado 14 y se elimina con su cuenta conforme al mismo apartado.

7.3 Envío de correo electrónico

BrickDb solo envía correos electrónicos cuando hay un motivo concreto para ello: la confirmación de su dirección de correo electrónico y el restablecimiento de su contraseña, una invitación a una colección cuando alguien le invita a ella (apartado 8.1a), una invitación a elegir su contraseña cuando la administración crea una cuenta para usted (apartado 8.9), nuestra respuesta a una solicitud de soporte y una notificación a nuestro propio buzón cuando alguien presenta una — esta última se dirige a nosotros y no a usted, pero contiene lo que escribió la persona solicitante (el apartado 8.7 trata ambas) —, una notificación a nuestro propio buzón cuando alguien denuncia un contenido, y la motivación que se le envía a usted cuando se estima una denuncia sobre un contenido que usted publicó (ambas, apartado 8.8). No hay ningún boletín ni correos publicitarios.

El proveedor de envío es Twilio Inc. (“SendGrid”), 101 Spear Street, 5th Floor, San Francisco, CA 94105, EE. UU. Para ello, SendGrid recibe la dirección del destinatario, un nombre visible, si existe, el asunto y el contenido íntegro del mensaje, así como los datos técnicos de entrega (momento, estado de entrega, respuesta del servidor de correo receptor). Su dirección de correo electrónico se comunica, por tanto, a un tercero, y es lo primero que ocurre con ella — antes de que suceda cualquier otra cosa. Por eso se indica aquí y no más abajo, en el apartado 12.

Base jurídica: artículo 6, apartado 1, letra b), del RGPD — la confirmación de una dirección, el restablecimiento de una contraseña y la entrega de una invitación forman parte del servicio solicitado. En esta medida, SendGrid es encargado del tratamiento conforme al artículo 28 del RGPD sobre la base del Twilio Data Protection Addendum.

Transferencia a terceros países: el envío se realiza a través de la infraestructura global de SendGrid; el tratamiento tiene lugar, por tanto, en los Estados Unidos y no en Alemania, como el alojamiento del apartado 4. Twilio basa tales transferencias en las cláusulas contractuales tipo de la Comisión Europea y, además, está certificada conforme al EU-US Data Privacy Framework.

Medición de aperturas y de clics: sí en los correos de la cuenta, no en los nuestros propios. A los correos electrónicos relativos a su cuenta — confirmación de la dirección, restablecimiento de la contraseña — SendGrid les añade antes del envío una imagen invisible, y sus enlaces se redirigen a través de SendGrid. Cuando su programa de correo muestra un mensaje de ese tipo, carga esa imagen y, al hacerlo, transmite el momento y la dirección IP a SendGrid; lo mismo ocurre al hacer clic en un enlace. De ello resulta en SendGrid la información de si un mensaje de ese tipo se abrió y cuándo. Base jurídica: artículo 6, apartado 1, letra f), del RGPD — nuestro interés legítimo en que los correos de la cuenta lleguen y no acaben en la carpeta de correo no deseado. Puede oponerse a ello conforme al artículo 21 del RGPD mediante los datos de contacto del apartado 2, y puede desactivar la carga de imágenes en su programa de correo — en ese caso no tiene lugar la medición de aperturas.

Los correos electrónicos que BrickDb envía por sí mismo no contienen ni una imagen de ese tipo ni enlaces redirigidos — hoy son las invitaciones a una colección, los dos correos de soporte del apartado 8.7, nuestra respuesta a una solicitud y la notificación que esta nos envía, y los dos correos sobre denuncias del apartado 8.8. Ninguno de ellos solicita nada a ningún servidor al abrirse; cada envío desactiva expresamente ambas mediciones en SendGrid.

Plazo de conservación: BrickDb no guarda ninguna copia de un mensaje enviado. En el proveedor de envío, los datos de entrega siguen siendo consultables en su registro de actividad durante un periodo breve que depende de su tarifa.

Estado de esta versión: este apartado describe la vía de envío tal como existe actualmente. Hasta que se añadió la notificación sobre una solicitud de soporte antes mencionada, aquí decía “tal como existe desde el 10 de septiembre de 2026”.

8. Datos de la colección y fotos

Las indicaciones siguientes describen el tratamiento que tiene lugar con una cuenta conforme al apartado 7.

8.1 Datos de la colección

Se almacena lo que usted mismo introduce: número de set, denominación, datos sobre el estado, notas, fecha de adquisición, precio pagado, indicaciones sobre el vendedor y los momentos de la creación y de la última modificación. Estos datos están vinculados a un identificador seudónimo.

Del mismo modo se almacena lo que usted introduce en las demás áreas: minifiguras individuales y piezas sueltas con los mismos datos, ejemplares de números de revistas y de libros con su nota de estado, el estado de un polybag que los acompañe, sus observaciones sobre el estado, cómo y cuándo los adquirió, el precio pagado, la indicación sobre el vendedor y sus notas, colecciones con su nombre, su descripción, su visibilidad conforme al apartado 8.1a y sus miembros junto con el rol de cada uno, invitaciones que usted haya emitido, junto con la dirección de correo electrónico indicada para ellas, firmas que registre para un ejemplar, su lista de deseos, sus aportaciones para resolver códigos de sobre y códigos de barras de envases, y los lotes de fotos de cajas que usted envía para su procesamiento.

Los ejemplares de números de revistas y de libros no están en ninguna colección; solo usted los ve.

Lugares de almacenamiento. Puede registrar dónde se guardan sus cosas: habitaciones, ubicaciones dentro de una habitación y compartimentos dentro de una ubicación, cada uno con el nombre que usted le dé, su nivel y su posición en su lista, y para cada ejemplar — sets, minifiguras, piezas sueltas, números de revistas y libros — en qué lugar se encuentra. Sus lugares de almacenamiento le pertenecen a usted, no a una colección: solo usted puede crearlos, modificarlos o asignarlos. Dónde se encuentra un ejemplar de una colección compartida lo ven, solo en modo de lectura, los miembros cuyo rol en esa colección es Propietario o Editor; los miembros con el rol Lector o Seguro no lo ven nunca, y una colección publicada no lo muestra nunca (apartado 8.1a). Si elimina su cuenta (apartado 14), sus lugares de almacenamiento se eliminan, y antes se quita el lugar de cada ejemplar que lo indicaba — también de un ejemplar que permanezca en una colección compartida con otras personas.

Los campos de texto libre no se evalúan. Se ruega no introducir en ellos categorías especiales de datos personales en el sentido del artículo 9 del RGPD.

Base jurídica: artículo 6, apartado 1, letra b), del RGPD — el tratamiento es necesario para prestar el servicio solicitado.

8.1a Quién puede ver una colección

Cada ejemplar que le pertenece está en una colección, y una colección tiene uno de tres ajustes, que usted elige y puede cambiar en cualquier momento: privada (solo la ven sus miembros — el valor predeterminado de una colección nueva), cualquiera con el enlace o cualquiera, incluidos los buscadores.

Una colección que usted ha hecho pública muestra su nombre y su descripción, los números de set, los nombres de los sets, cuántos ejemplares tiene de cada uno y en qué estado se encuentran, y nada más. Ni fotos, ni notas, ni etiquetas, ni apodos, ni lugares de almacenamiento, ni precios pagados, ni valoraciones propias, ni fechas de adquisición, ni nada sobre el vendedor. No le nombra a usted ni a ningún otro miembro, y tampoco dice cuántas personas forman parte de ella. Esos campos no se ocultan en esa página — ni siquiera se transmiten a ella.

Un enlace no es una contraseña. Una colección con el ajuste “cualquiera con el enlace” se entrega a toda persona que abra esa dirección, se la haya dado usted o no. El ajuste “cualquiera con el enlace” pide además a los buscadores que no incluyan la página; por regla general lo respetan, pero no están obligados a ello. Volver a poner una colección como privada pone fin a la entrega de inmediato, pero no recupera una copia que alguien — o un buscador — ya haya tomado.

Una colección compartida con miembros designados por su nombre es algo distinto de una pública: lo que ve un miembro depende del rol que usted le haya asignado. Un Lector ve exactamente lo que muestra también la página pública. Un Editor lo ve todo, incluidos los campos enumerados arriba. Seguro ve los sets, su estado y las cifras de valoración, y nada más.

Una colección pública puede denunciarse. Su página lleva el formulario de denuncia del apartado 8.8, que puede usar cualquier persona que pueda ver la página. Si la administración estima una denuncia al respecto, la colección vuelve a ponerse como privada; no se elimina nada, y usted puede publicarla de nuevo.

Base jurídica: artículo 6, apartado 1, letra a), del RGPD — usted consiente al elegir el ajuste, y retira el consentimiento al restablecerlo.

8.2 Fotos

Las fotos subidas se muestran a usted y a los miembros de la colección cuyo rol incluye los datos privados — son Propietario y Editor conforme al apartado 8.1a. Si el ejemplar está en una colección en la que no hay nadie más, la foto solo la ve quien la subió. En la página pública de una colección no aparecen fotos, y tampoco las ven los miembros con el rol Lector o Seguro. Las fotos no se publican, no se comunican a terceros y no se utilizan para entrenar modelos.

Los metadatos se eliminan. Al subirla, cada imagen se vuelve a codificar: la orientación anotada en la imagen se incorpora de forma fija a los datos de imagen y, a continuación, se elimina todo el perfil de metadatos — EXIF, IPTC y XMP, y con ello, en particular, las coordenadas GPS, el momento de la toma y los identificadores del dispositivo. Solo se almacena la imagen depurada; el archivo transmitido originalmente no se conserva.

El nombre de archivo original no se conserva. Cada archivo recibe un identificador generado aleatoriamente; de la ruta de almacenamiento no puede deducirse nada sobre la persona que subió el archivo ni sobre su procedencia.

Versiones reducidas. Para la visualización se generan, cuando hace falta, versiones reducidas de una foto y se almacenan temporalmente. Contienen los mismos datos de imagen — ya depurados de metadatos —, están sujetas a las mismas restricciones de acceso y se eliminan junto con la foto.

Las imágenes en un formato que no puede volver a codificarse — entre ellos HEIC/HEIF, el formato estándar de los iPhone más recientes — se rechazan en lugar de almacenarse. El mensaje de error indica los formatos aceptados (JPEG, PNG, WebP, GIF). Así pues, no se guarda nada que no se haya depurado antes.

Para cada foto se almacenan: el identificador aleatorio del archivo, un pie de foto que usted mismo asigna, el orden y el momento de la subida.

Base jurídica: artículo 6, apartado 1, letra b), del RGPD.

8.3 Imagen de avatar

Puede subir una imagen propia como avatar o utilizar uno de los dibujos que BrickDb pone a disposición. Los dibujos puestos a disposición son nuestros propios gráficos y no son datos personales; una imagen subida sí lo es.

Un avatar subido pasa por la misma depuración que cualquier otra foto: la orientación se incorpora a los datos de imagen y todo el perfil de metadatos — EXIF, IPTC y XMP, y con ello, en particular, las coordenadas GPS, el momento de la toma y los identificadores del dispositivo — se elimina. A continuación, la imagen se recorta a su cuadrado central, se reduce a 256 × 256 píxeles y se vuelve a codificar como WebP. Solo se almacena esa imagen; el archivo transmitido no se conserva, y una imagen que no puede volver a codificarse se rechaza en lugar de almacenarse.

Quién puede verlo. Un avatar se almacena para que pueda mostrarse junto a su nombre. BrickDb no tiene actualmente ninguna vista en la que una persona vea el perfil de otra — hoy, por tanto, solo usted ve el suyo. En cuanto eso cambie, este apartado lo dirá expresamente: un avatar está pensado para ser visible para otras personas, y precisamente por eso figura aquí separado del 8.2.

Por cuenta se almacena exactamente un avatar; una nueva subida lo sustituye. Está incluido en la copia de sus datos conforme al apartado 14 y se elimina cuando usted elimina su cuenta conforme al apartado 14.

Base jurídica: artículo 6, apartado 1, letra b), del RGPD.

8.4 Propuestas de eventos

Al proponer un evento almacenamos su título, la descripción opcional, el lugar del evento, el país y el calendario. En un evento de día completo, son la fecha de inicio y la fecha de fin no incluida. En un evento con hora, son los momentos de inicio y de fin y la zona horaria del lugar del evento. A ello se añaden la apertura de inscripciones opcional, la URL de origen, el vínculo con la cuenta y el momento de la propuesta. Almacenamos además el estado de moderación, el momento de una decisión de moderación y una orden interna de notificación para la cola de revisión. Esta orden no envía ningún correo electrónico.

La administración revisa las propuestas manualmente. Las propuestas pendientes y las rechazadas no son públicas. Tras la aprobación, los datos del evento y la URL de origen son visibles públicamente; la identidad de la cuenta no se publica. Le rogamos que proponga solo datos de eventos que esté autorizado a publicar, sin datos de contacto personales ni información privada sobre usted o sobre otras personas.

La propuesta y la moderación prestan el servicio solicitado (artículo 6, apartado 1, letra b), del RGPD). El mantenimiento del calendario público aprobado sirve a nuestro interés legítimo y al de los demás visitantes en disponer de información fiable sobre eventos (artículo 6, apartado 1, letra f), del RGPD). Puede oponerse a un tratamiento basado en intereses legítimos mediante los datos de contacto del apartado 2. La exportación de datos conforme al artículo 15 del RGPD en la página de la cuenta contiene sus propias propuestas de eventos en cualquier estado de moderación.

Al eliminar la cuenta se eliminan las propuestas pendientes y las rechazadas, junto con sus órdenes de notificación. Los eventos aprobados siguen siendo públicos; el vínculo con la persona que los propuso se anonimiza: lo sustituye un nuevo valor aleatorio, sin cuenta ni correspondencia que remita a la persona. Los datos aprobados permanecen en el calendario para los demás visitantes; para ese registro anonimizado no existe un plazo fijo de caducidad. A las copias de seguridad se les aplica el apartado 13. Los demás derechos del apartado 14 se mantienen.

8.5 Leer el número de set a partir de una foto

Cuando usted envía expresamente una foto de una caja de venta para leer el número de set, BrickDb transmite como máximo 8 MB desde el navegador a sus propios servidores web y de API. El servidor de API pasa la foto, sin modificarla, a un tercer servidor propio, el servicio de lectura (la aplicación de contenedor “brickdb-ocr”). Se ejecuta en el mismo entorno de Azure y en la misma región (Germany West Central, Frankfurt am Main) que los demás servidores del apartado 4, solo es accesible desde dentro de ese entorno y no tiene acceso a la base de datos ni al almacenamiento de archivos. Al igual que los servidores web y de API, el servicio de lectura mantiene la imagen exclusivamente en memoria; devuelve al servidor de API solo los posibles números de set leídos en ella, y su entrada de registro solo hace constar cómo terminó la solicitud (por ejemplo, leída o rechazada) y cuánto duró, nada sobre la foto. En ninguno de los tres servidores la imagen se almacena, se registra ni se utiliza para entrenar modelos; no se transmite a terceros y se descarta al terminar la solicitud. Los tres servidores los operamos nosotros mismos en Microsoft Azure; Microsoft es a este respecto encargado del tratamiento conforme al apartado 4. Base jurídica: artículo 6, apartado 1, letra b), del RGPD — el tratamiento presta la lectura que usted ha solicitado.

Para que esta función, que requiere mucha capacidad de cálculo, siga disponible, cada proceso de servidor permite seis solicitudes por dirección IP de origen dentro de un minuto móvil. Este límite lo comprueban tanto el servidor web como el servidor de API, porque el servidor de API también es accesible directamente. Cada proceso de servidor cuenta por separado, y de cada servidor pueden ejecutarse varios procesos a la vez; por eso el límite vale por proceso y no como una cifra total para todo BrickDb. Para que, en una solicitud que llega a través del servidor web, el servidor de API cuente la dirección de usted y no la del servidor web, el servidor web le transmite la dirección de usted junto con la solicitud; el servicio de lectura no la recibe. En ambos servidores la dirección — en IPv6 solo su parte de red — se mantiene únicamente como clave en la memoria del proceso de servidor correspondiente; no se registra, no se almacena de forma permanente ni se comunica a terceros. Transcurrido un minuto ya no influye en ninguna decisión y se elimina cuando esa dirección vuelve a hacer una solicitud o cuando la limpieza impulsada por las solicitudes necesita espacio. Cada proceso de servidor mantiene como máximo 1024 claves de dirección; mientras todos los puestos sigan activos, una dirección nueva se rechaza en lugar de desplazar a una de ellas. Base jurídica: artículo 6, apartado 1, letra f), del RGPD. El interés legítimo es la disponibilidad técnicamente segura, fiable y equitativa del servicio.

8.6 Sugerencia sobre el estado de una caja a partir de una foto

Aparte de la lectura del número de set, usted puede solicitar expresamente, para una foto de una caja de venta, una sugerencia sobre el estado visible en que se encuentra la caja. Solo cuando haya solicitado esa evaluación y haya confirmado la solicitud, BrickDb transmite la foto desde su propio servidor de API al servicio Azure OpenAI de Microsoft Ireland Operations Limited, One Microsoft Place, South County Business Park, Leopardstown, Dublin 18, Irlanda, como encargada del tratamiento conforme al artículo 28 del RGPD. Antes, la imagen se vuelve a codificar, se le quitan todos los metadatos y se reduce a un máximo de 1024 píxeles en su lado más largo. La conexión la establece el servidor, no su navegador; abrir una página no la desencadena nunca.

El tratamiento tiene lugar en la EU Data Zone de Azure, es decir, dentro de la UE; el despliegue está situado en la región Germany West Central y el tratamiento puede realizarse en cualquier Estado miembro de la UE. Según indica Microsoft, las entradas y las salidas no se utilizan para entrenar los modelos y no se ponen a disposición de los proveedores de los modelos. Supervisión estándar de usos abusivos: Microsoft examina las entradas de forma automatizada en busca de un uso abusivo. Una entrada que resulte señalada en ese examen puede ser conservada por Microsoft como muestra y revisada por empleados autorizados de Microsoft en el EEE; Microsoft no indica para ello ningún plazo máximo fijo. Más allá de eso, el servicio no conserva la foto.

BrickDb en sí permanece sin estado: en BrickDb, la foto y el resultado no se almacenan, no se registran y no se utilizan para entrenar modelos; ambos se descartan al terminar la solicitud. El resultado es una sugerencia experimental y no calibrada referida únicamente al estado visible de la caja — no existe una tasa de acierto medida, no dice nada sobre el contenido, el precinto o la integridad, no escribe nada en su colección, y usted mismo la acepta o la sustituye expresamente. Le rogamos que fotografíe solo la caja: sin personas, direcciones u otros datos personales, y solo imágenes que esté autorizado a enviar.

Base jurídica: artículo 6, apartado 1, letra a), del RGPD — su consentimiento, que usted otorga con cada solicitud individual. Es voluntario; sin él no se transmite ninguna foto y la cuestión del estado sigue siendo un dato que usted mismo indica. Lo retira con efectos para el futuro no solicitando ninguna otra evaluación. No es un consentimiento para un entrenamiento; una aceptación posterior (opt-in), revocable por separado, sería una declaración propia.

8.7 Solicitudes de soporte

En la página de soporte hay un formulario para solicitudes de soporte, y usted puede utilizarlo sin cuenta y sin iniciar sesión. Pide una dirección de correo electrónico para la respuesta, un asunto y su mensaje; el nombre es voluntario. No pregunta por el idioma — resulta del idioma en el que se mostró la página, para que la respuesta llegue en el idioma en el que usted preguntó. Si en su lugar nos escribe a la dirección del apartado 2, nos llega igual de bien, pero de ello no resulta ningún ticket; ese mensaje es entonces simplemente un correo electrónico en nuestro buzón.

Lo que usted envía lo almacenamos como ticket con un número de ticket: la dirección de correo electrónico para la respuesta, el nombre voluntario, el idioma en el que escribió, el asunto, el texto de su solicitud, su estado de tramitación, la vía por la que llegó y los momentos de entrada y de cierre.

En esta versión ningún ticket está vinculado a una cuenta de usuario — tampoco uno que usted envíe con la sesión iniciada. La ruta que recibe el formulario está abierta a todos y no determina ningún inicio de sesión, de modo que el campo previsto para ese vínculo queda vacío. Lo que de ello se deriva para sus derechos figura más abajo, en el párrafo sobre la eliminación. Un ticket tiene además un campo para una clave de acceso a una página de estado, y tampoco se emite ninguna clave de ese tipo en esta versión, de modo que ese campo también queda vacío. Si se emitiera una, solo se almacenaría su suma de comprobación, nunca la clave misma.

Alguien se entera de inmediato. Un ticket que usted presenta se nos notifica por correo electrónico a nuestro propio buzón, para que no quede sin atender. Esa notificación contiene el número de ticket, la dirección y el nombre que usted indicó, su asunto y el texto íntegro de su mensaje. Se envía a través del proveedor de correo mencionado en el apartado 7.3, de modo que estos datos se tratan en los Estados Unidos sobre la base allí descrita. A diferencia de los correos de la cuenta de ese apartado, no contiene ninguna imagen invisible ni enlaces redirigidos. Lo que usted mismo ve es el número de ticket en la página, una vez enviado el formulario; nuestra respuesta a usted es un correo electrónico aparte, más abajo, en "Cómo respondemos".

Protección frente a envíos masivos. Para que el formulario no pueda utilizarse para inundarnos, BrickDb permite cinco envíos por conexión a internet en un cuarto de hora móvil. Para ello mantiene una forma abreviada de su dirección IP como clave en la memoria de un proceso web — en IPv6 solo la parte de red, en IPv4 la dirección. No se registra, no se escribe en el ticket, no se almacena en la base de datos y no se comunica a nadie, y una vez transcurrido el cuarto de hora ya no influye en ninguna decisión. Se mantienen como máximo 1024 claves de ese tipo; si todos los puestos están ocupados, una nueva se rechaza en lugar de desplazar a una existente. No hay ningún captcha, y para ello no se carga nada de terceros. Base jurídica: artículo 6, apartado 1, letra f), del RGPD. El interés legítimo es la disponibilidad técnicamente correcta, segura y equitativa del servicio.

Base jurídica: tramitación y respuesta de su solicitud (artículo 6, apartado 1, letra b), del RGPD, en la medida en que se refiera a su relación de uso; en los demás casos, artículo 6, apartado 1, letra f), del RGPD — nuestro interés legítimo en poder responder a las consultas sobre este servicio). Puede oponerse a un tratamiento basado en intereses legítimos mediante los datos de contacto del apartado 2.

Plazo de conservación: un ticket cerrado se elimina 24 meses después de su cierre. El plazo corre desde el cierre y no desde la entrada — un ticket por el que usted todavía espera no se elimina, por antiguo que sea. La eliminación se realiza en el marco de una limpieza periódica y, por tanto, puede producirse unos días después de que venza el plazo, nunca antes. A las copias de seguridad se les aplica el apartado 13.

En la eliminación de la cuenta conforme al artículo 17 del RGPD, al eliminar su cuenta en la página de la cuenta se anonimizan todos los tickets vinculados a su cuenta: la dirección de correo electrónico, el nombre y ese vínculo se eliminan y la clave de acceso deja de ser válida, mientras que el ticket en sí se anonimiza en lugar de eliminarse, porque el asunto, el texto y nuestras respuestas son nuestra propia constancia de una conversación en la que también nosotros participamos. Dado que en esta versión ningún ticket lleva un vínculo de ese tipo, ese paso no alcanza nada en la práctica: una solicitud de soporte no está incluida ni en la exportación de datos conforme al artículo 15 del RGPD ni en la eliminación de la cuenta en la página de la cuenta, con independencia de que usted hubiera iniciado sesión al enviarla. La relación de lo que la exportación no contiene menciona las solicitudes de soporte precisamente por ese motivo.

Sus derechos del apartado 14 se mantienen sin cambios, y así es como los ejerce respecto de un ticket: diríjase a nosotros mediante los datos de contacto del apartado 2 e indique el número de ticket o la dirección utilizada. Hay algo que conviene que sepa al hacerlo — quitar campos no anonimiza el texto libre. Si en la propia solicitud escribió su nombre, un número de pedido u otros datos sobre usted, estos siguen figurando en el texto. Avísenos si es así; en ese caso tachamos o eliminamos a mano el ticket en cuestión.

Notas internas: mientras se tramita un ticket, escribimos además notas para nosotros mismos sobre él — qué se intentó, qué encontramos, a qué estado de tramitación pasamos el ticket y quién lo hizo. Esas notas son nuestras y no suyas: van unidas a la persona que las escribió, nunca forman parte de una respuesta a usted y, por ello, ni están en su exportación de datos conforme al artículo 15 del RGPD ni se anonimizan al eliminar su cuenta. Se eliminan junto con el ticket, en el mismo plazo. Si desea saber si una nota le menciona por su nombre, escríbanos mediante los datos de contacto del apartado 2 e indique el número de ticket.

Cómo respondemos: respondemos por correo electrónico a la dirección que usted indicó y en el idioma en el que escribió. Esa respuesta cita de nuevo su asunto y su mensaje para que pueda identificar el ticket, porque al enviar la solicitud no recibe ninguna copia de ella. Nuestra respuesta no contiene ningún enlace ni ningún seguimiento — no se carga nada desde ningún sitio, y no nos enteramos de si usted la abre. Si después queda algo pendiente, responda simplemente a ese correo electrónico y deje el número de ticket en el asunto.

Correos a la dirección de soporte: los correos enviados a support@brickdb.net — también una respuesta a una de nuestras respuestas, que debe dirigirse allí — se convierten en un ticket. Nuestro proveedor de correo (apartado 7.3) los recibe por encargo nuestro para el subdominio support.brickdb.net y los entrega a BrickDb; por ello se tratan en los Estados Unidos sobre la base allí descrita. Si el asunto lleva el número de un ticket abierto, el correo procede de la dirección propia de ese ticket y el dominio del remitente lo ha firmado o autorizado (DKIM o SPF, comprobado en la recepción), se añade a ese ticket; cualquier otro correo abre uno nuevo, y el ticket hace constar si el remitente pudo confirmarse de ese modo. Se almacenan la dirección y el nombre del remitente, el asunto, el idioma que declara el correo y su texto — nunca sus archivos adjuntos: un archivo adjunto no se almacena en ningún sitio, y el ticket solo hace constar cuántos había. Un correo que nuestro filtro antispam clasifica como spam, que procede de una de nuestras propias direcciones o que llega después de que en la última hora ya se hayan aceptado cinco correos del mismo remitente (o sesenta en total) no se convierte en ticket; para que una solicitud real que quede retenida de ese modo pueda aun así encontrarse y responderse, dejamos una breve constancia de cuándo llegó, por qué se rechazó, la dirección del remitente y el asunto — nunca el texto —, y ello durante 30 días. La base jurídica, el plazo de conservación y sus derechos son, por lo demás, los del formulario de arriba.

Estado de esta versión: el formulario para solicitudes de soporte de /support está en funcionamiento, y también la respuesta por correo electrónico descrita arriba. Sigue pudiendo contactar con nosotros también mediante los datos de contacto del apartado 2 y del Impressum (aviso legal) — esa es la vía si el formulario no acepta su solicitud por cualquier motivo.

8.8 Denuncias sobre contenidos

Cada evento de la página de eventos lleva un formulario de denuncia, y también la página de cada colección publicada (apartado 8.1a). Puede utilizarlo sin cuenta y sin iniciar sesión — aquello de lo que trata una denuncia también puede verlo quien no ha iniciado sesión, de modo que una barrera previa excluiría precisamente a la persona para la que existe el formulario. Se pide un motivo de una lista fija, una descripción voluntaria de lo que no está bien y una dirección de correo electrónico voluntaria. Solo en un único motivo — „Otra cosa“ — la descripción es obligatoria, porque una denuncia cuyo contenido íntegro es esa expresión tendría que leerse antes de poder clasificarse. No se pregunta por el idioma — resulta del idioma en el que se mostró la página.

Lo que usted envía lo almacenamos como denuncia con una referencia propia, que tiene el aspecto de BDR-000042: de qué tipo de contenido se trata y la clave propia de ese contenido, el motivo que usted eligió, su descripción, si escribió una, la dirección de correo electrónico, si indicó una, el idioma en el que escribió, el estado de tramitación y los momentos de entrada y de decisión. Una descripción puede tener como máximo 2000 caracteres y una dirección como máximo 254; todo lo que sea más largo se rechaza indicando el campo, en lugar de almacenarse abreviado.

Ninguna denuncia está vinculada a una cuenta de usuario — tampoco una que usted envíe con la sesión iniciada. La ruta que recibe el formulario está abierta a todos y no determina ningún inicio de sesión, y no existe un campo para tal vínculo: BrickDb, de forma deliberada, no sabe qué denuncia era suya. Lo que de ello se deriva para sus derechos figura más abajo, en el párrafo sobre la exportación y la eliminación. Tampoco hay ninguna página de estado de una denuncia ni ninguna clave de acceso a ella, de modo que tampoco se almacena nada de ese tipo.

Alguien se entera de inmediato. Una denuncia que usted envía se nos notifica por correo electrónico a nuestro propio buzón, para que no quede sin atender. Esa notificación contiene la referencia, el tipo de contenido, el motivo, la clave del contenido denunciado y el texto íntegro de su descripción. No contiene ninguna dirección suya: el mensaje va dirigido a nosotros, y su dirección permanece en la cola, donde solo puede verla un administrador. Se envía a través del proveedor de correo mencionado en el apartado 7.3, de modo que estos datos se tratan en los Estados Unidos sobre la base allí descrita; al igual que la notificación de soporte, no contiene ninguna imagen invisible ni enlaces redirigidos. Lo que usted mismo ve es la referencia en la página, una vez enviado el formulario.

Protección frente a envíos masivos. Para que el formulario no pueda utilizarse para inundarnos, BrickDb permite cuatro denuncias por conexión a internet en diez minutos móviles. Para ello mantiene una forma abreviada de su dirección IP como clave en la memoria de un proceso web — en IPv6 solo la parte de red, en IPv4 la dirección. No se registra, no se escribe en la denuncia, no se almacena en la base de datos y no se comunica a nadie, y una vez transcurridos los diez minutos ya no influye en ninguna decisión. Se mantienen como máximo 1024 claves de ese tipo; si todos los puestos están ocupados, una nueva se rechaza en lugar de desplazar a una existente. No hay ningún captcha, y para ello no se carga nada de terceros. Base jurídica: artículo 6, apartado 1, letra f), del RGPD. El interés legítimo es la disponibilidad técnicamente correcta, segura y equitativa del servicio.

Quién lee una denuncia y qué efecto tiene la decisión. Una denuncia llega a una cola en /admin/reports que solo puede abrir un administrador; no existe ninguna página en la que otra persona pueda consultarla, tampoco mediante la referencia. La denuncia se desestima o se estima, y si se estima, el contenido denunciado se retira: un evento contra el que prospera una denuncia desaparece del calendario público. Una colección publicada contra la que prospera una denuncia vuelve a ponerse como privada: a partir de entonces solo la ven sus miembros, no se elimina nada de ella, y quien la posee puede publicarla de nuevo — una colección publicada de nuevo puede volver a denunciarse. Actuamos contra el contenido, no contra la persona que lo publicó.

Una decisión sobre algo que una persona ha publicado se hace constar también respecto de ella. Si la administración estima o desestima una denuncia sobre una colección o sobre un evento propuesto por un miembro, la decisión se hace constar en el registro de auditoría del apartado 8.9, en la cuenta de la persona que publicó el contenido: de qué denuncia se trataba, qué tipo de contenido y su clave, y cómo evolucionó el estado de la denuncia. La persona denunciante no se menciona en esa entrada, y las notas de la moderación tampoco forman parte de ella.

Base jurídica: artículo 6, apartado 1, letra f), del RGPD. El interés legítimo consiste en mantener los contenidos publicados por BrickDb libres de material ilícito y ofensivo, en poder recibir siquiera una objeción — también de alguien sin cuenta — y en poder acreditar después cómo se tramitó una reclamación. Si una denuncia se refiere a contenidos contra los que estamos obligados a actuar, su tramitación sirve al mismo tiempo al cumplimiento de una obligación legal (artículo 6, apartado 1, letra c), del RGPD). Puede oponerse a un tratamiento basado en intereses legítimos mediante los datos de contacto del apartado 2.

Si se estima una denuncia, la persona que publicó el contenido recibe de nosotros una motivación por correo electrónico. Esto vale para una colección publicada y para un evento propuesto por un miembro; en un evento que hemos tomado de un calendario ajeno no hay nadie a quien pudiéramos escribir. El mensaje indica la referencia de la denuncia, de qué contenido se trata (su tipo y su título o nombre), qué hemos hecho y durante cuánto tiempo se aplica, el motivo bajo el que se presentó la denuncia, el apartado de nuestras Condiciones de uso conforme al cual decidimos, la indicación de que no se emplearon medios automatizados, y cómo puede usted oponerse — respondiendo al correo electrónico o mediante el formulario de soporte, indicando la referencia. No figura en él quién envió la denuncia, ni tampoco su descripción ni las notas de la moderación.

Para el envío consultamos a Auth0, en el momento de la decisión, su dirección de correo electrónico y el idioma guardado en su cuenta (apartado 7.1). La dirección solo se utiliza para ello y no la almacenamos; en la denuncia únicamente hacemos constar si la motivación pudo enviarse y cuándo — o por qué no, por ejemplo porque no hay ninguna dirección guardada. Se envía a través del proveedor de correo mencionado en el apartado 7.3, de modo que estos datos se tratan en los Estados Unidos sobre la base allí descrita; no contiene ninguna imagen invisible ni enlaces redirigidos. Si una colección se pone como privada, el ajuste modificado se ve además en la página de colecciones. Base jurídica: artículo 6, apartado 1, letra c), del RGPD en relación con el artículo 17 del Reglamento (UE) 2022/2065 (Reglamento de Servicios Digitales), en la medida en que estemos obligados a tal motivación, y en lo demás artículo 6, apartado 1, letra f), del RGPD — el interés legítimo es decirle qué ha ocurrido con su contenido y por qué, y darle una vía para oponerse a la decisión.

Plazo de conservación: una denuncia decidida se elimina 24 meses después de la decisión. El plazo corre desde la decisión y no desde la entrada — una denuncia sobre la que nadie ha decidido todavía no se elimina, por antigua que sea, porque es una objeción a la que aún se debe una respuesta. La eliminación se realiza en el marco de una limpieza periódica y, por tanto, puede producirse unos días después de que venza el plazo, nunca antes. A las copias de seguridad se les aplica el apartado 13.

Ni la exportación de datos conforme al artículo 15 del RGPD ni la eliminación de la cuenta alcanzan una denuncia, y eso es un límite y no una decisión contra usted. Como ninguna denuncia está asignada a una cuenta, ni siquiera es posible preguntar qué denuncias proceden de una persona determinada — por eso una denuncia no está incluida ni en la exportación de datos conforme al artículo 15 del RGPD ni en la eliminación de la cuenta en la página de la cuenta, con independencia de que usted hubiera iniciado sesión al enviarla, y eliminar su cuenta no la elimina. Lo mismo vale si alguien ha denunciado algo que usted publicó: esa denuncia designa el contenido, nunca su cuenta, y por tanto tampoco está en su exportación — la decisión al respecto sí lo está, una vez que la administración la ha estimado o desestimado, como entrada del registro de auditoría conforme al apartado 8.9. La relación de lo que la exportación no contiene menciona ambos casos precisamente por este motivo. Lo que usted puede hacer realmente: diríjase a nosotros mediante los datos de contacto del apartado 2 e indique la referencia. Con ella encontramos la denuncia a mano, podemos decirle qué contiene, rectificarla o quitar la dirección y el texto que usted escribió.

Quitar campos no anonimiza el texto libre. Si en la descripción escribió su nombre, una dirección u otros datos sobre usted, estos siguen figurando en el texto. Avísenos si es así; en ese caso tachamos o eliminamos a mano la denuncia en cuestión.

Notas internas: mientras se tramita una denuncia, escribimos además notas para nosotros mismos sobre ella — qué encontramos, a qué estado de tramitación pasamos la denuncia y quién lo hizo. Esas notas son nuestras y no suyas: van unidas a la persona que las escribió, no se envían ni a usted ni a la persona cuyo contenido se denunció y, por ello, ni están en su exportación de datos conforme al artículo 15 del RGPD ni son alcanzables mediante una eliminación de la cuenta. Se eliminan junto con la denuncia, en el mismo plazo. Si desea saber si una nota le menciona por su nombre, escríbanos mediante los datos de contacto del apartado 2.

Por nuestra parte no respondemos. De una denuncia no resulta ninguna correspondencia: no hay correo de confirmación, ni página de estado, ni mensaje cuando se ha decidido. La dirección está para que alguien pueda ponerse en contacto con usted si la denuncia no puede tramitarse sin hacerle una consulta, y no se utiliza para nada más. Lo que usted recibe es, de inmediato, la referencia en la página.

Estado de esta versión: el formulario de denuncia de /events y de la página de cada colección publicada está en funcionamiento, y también la cola que hay detrás. Si no acepta su denuncia por cualquier motivo, puede contactar con nosotros igual de bien mediante los datos de contacto del apartado 2 y del Impressum — un mensaje enviado de ese modo es entonces simplemente un correo electrónico en nuestro buzón y no genera ninguna denuncia.

8.9 Administración de cuentas de usuario

Los administradores de BrickDb pueden gestionar las cuentas de usuario en un área situada en /admin/users que solo ellos pueden abrir: ver la lista de cuentas, consultar una cuenta, cambiar su nombre, su dirección de correo electrónico, su perfil o sus roles, enviar un restablecimiento de contraseña, volver a enviar el correo de confirmación, marcar una dirección de correo electrónico como confirmada, bloquearla o desbloquearla, o eliminarla mediante la misma eliminación que se describe en el apartado 14. Los datos de la cuenta que allí se muestran se leen en directo en Auth0 (apartados 7.1 y 7.2) y no se copian en la base de datos de BrickDb. Lo mismo vale para el historial de inicios de sesión de una cuenta: se lee en Auth0 cuando un administrador lo abre y solo se conserva mientras el propio Auth0 lo conserve.

Qué ve la administración sobre una cuenta. La página de una cuenta muestra lo que Auth0 almacena sobre ella — su identificador, la dirección de correo electrónico y si está confirmada, los métodos de inicio de sesión vinculados a ella, cuándo se creó, cuándo se modificó por última vez y cuándo inició sesión por última vez, cuántas veces ha iniciado sesión, si está bloqueada, qué tipos de autenticación multifactor están configurados (solo el tipo, nunca un secreto ni un número de teléfono) y sus roles — así como el perfil que usted rellenó (nombres, país, el texto sobre usted, el avatar elegido y el idioma de sus correos electrónicos, pero no su dirección postal). De la base de datos propia de BrickDb muestra solo recuentos: cuántas colecciones posee usted y a cuántas se ha unido, cuántos ejemplares ha añadido, cuántos códigos de sobre, códigos de barras de sets y eventos ha aportado, cuántas de sus solicitudes de soporte están abiertas y cuántas denuncias de contenido se presentaron con su dirección de correo electrónico — nunca su contenido.

El historial de inicios de sesión muestra, para cada evento que Auth0 ha registrado para la cuenta, cuándo ocurrió, qué fue (un inicio de sesión o uno fallido, un registro, un cierre de sesión, un cambio de contraseña o de dirección de correo electrónico, una confirmación de correo electrónico, un paso de la autenticación multifactor, un intento bloqueado por Auth0 o una contraseña procedente de una filtración de datos), a través de qué método de inicio de sesión y de qué aplicación de BrickDb se realizó, el país y la ciudad que Auth0 dedujo de la dirección IP, y el navegador y el sistema operativo con su versión principal. La dirección IP en sí no se muestra, ni tampoco el texto libre que Auth0 adjunta a un evento. La administración lo consulta para mantener seguras las cuentas — para reconocer inicios de sesión que no eran suyos, o un ataque a su contraseña — y para ayudarle cuando usted nos pregunta por su cuenta.

Nadie de la administración ve, elige ni teclea jamás una contraseña. Una cuenta que se crea allí recibe una contraseña aleatoria que nadie ve, y usted recibe de BrickDb un correo de invitación (enviado como se describe en el apartado 7.3) con un enlace que es válido durante siete días y puede usarse una sola vez, para elegir su propia contraseña. Un restablecimiento de contraseña es el correo propio de Auth0 con el mismo tipo de enlace. Ni la contraseña ni el enlace son almacenados ni registrados por BrickDb.

Toda acción de la administración se hace constar en un registro de auditoría, y ello antes de que se ejecute, para que también conste una que falle: cuándo tuvo lugar, quién la ejecutó, qué fue, a qué cuenta afectó (su identificador de Auth0, y la dirección de correo electrónico y el nombre que tenía en ese momento), qué motivo indicó la persona, qué campos cambiaron y con qué valores antes y después, y si tuvo éxito. Nunca se hace constar una contraseña, un enlace de restablecimiento ni un token. Solo la administración puede leer el registro, en /admin/audit, y este no tiene ninguna función que modifique o elimine una entrada.

Base jurídica: artículo 6, apartado 1, letra f), del RGPD. Nuestro interés legítimo consiste en mantener seguros las cuentas y el servicio, en ayudarle cuando su cuenta necesita ayuda y en poder mostrar después qué ocurrió con una cuenta, por parte de quién y por qué — la responsabilidad proactiva que nos exige el artículo 5, apartado 2, del RGPD. Esto vale para los datos de la administración en el registro igual que para los suyos. Puede oponerse mediante los datos de contacto del apartado 2.

Plazo de conservación: una entrada del registro de auditoría se elimina 24 meses después de la acción, en el marco de la limpieza periódica, es decir, posiblemente unos días más tarde y nunca antes. A las copias de seguridad se les aplica el apartado 13.

Si elimina su cuenta, las entradas sobre ella se conservan, pero ya no le nombran. El identificador de la cuenta se sustituye por un seudónimo aleatorio, y la dirección de correo electrónico, el nombre y todos los valores modificados se eliminan; quién actuó, qué se hizo y cuándo se mantiene, porque precisamente para eso existe la entrada. El motivo que anotó la administración también lo conservamos; puede mencionarle en el texto — avísenos y lo tachamos. Si usted mismo forma parte de la administración y elimina su cuenta, las entradas sobre sus acciones se mantienen sin cambios.

La administración solo elimina una cuenta mediante esa misma eliminación (apartado 14), paso a paso, y solo después de haber tecleado la dirección de correo electrónico de la cuenta y de haber indicado un motivo, que el registro de auditoría conserva. Lo hacemos, por ejemplo, cuando usted nos pide que eliminemos una cuenta en la que ya no puede iniciar sesión. Si antes desea una copia de sus datos, descargue su exportación conforme al artículo 15 del RGPD en la página de la cuenta antes de escribirnos — después ya no queda nada que exportar. La administración no puede eliminar por esta vía su propia cuenta; para ello existe, como para todos, la página de la cuenta.

La administración también puede descargar por usted su exportación conforme al artículo 15 del RGPD — por ejemplo, cuando usted nos pide que se la enviemos porque no puede iniciar sesión. Es el mismo archivo que le da la página de la cuenta, creado del mismo modo, y la administración solo puede descargarlo después de haber indicado un motivo. Toda descarga se hace constar en el registro de auditoría como cualquier otra acción de la administración: quién la descargó, cuándo y por qué. El archivo va directamente al navegador de la administración; BrickDb no conserva ninguna copia de él y no lo escribe en ningún registro.

Su exportación conforme al artículo 15 del RGPD en la página de la cuenta contiene las entradas sobre su cuenta (en „adminAuditEntries“) — cuándo, qué, el motivo y qué cambió —, pero no quién de la administración fue, porque esos son datos de esa persona y no suyos. Escríbanos mediante los datos de contacto del apartado 2 si desea saberlo.

Estado de esta versión: la lista de usuarios con su búsqueda, la página de una cuenta individual, su historial de inicios de sesión, todas las acciones mencionadas arriba y el registro de auditoría están en funcionamiento.

9. Fuentes de datos externas

BrickDb muestra datos de catálogo y de precios procedentes de fuentes ajenas, en particular Rebrickable y BrickLink. Esos datos se obtienen exclusivamente en el servidor y se incorporan a nuestro propio fondo de datos. El navegador no establece en ningún momento una conexión con esos proveedores.

A esos proveedores no se les transmite ningún dato personal — ni la dirección IP ni ningún identificador, ni la información sobre lo que se buscó o sobre lo que alguien posee. Las consultas se realizan según un calendario propio y no como traslado de una solicitud de un usuario.

10. Medición de uso con Google Analytics

BrickDb cuenta con Google Analytics 4 cuántas veces se abren las páginas y qué áreas se utilizan. Esto ocurre exclusivamente con su consentimiento. Mientras usted no haya aceptado, no se carga ningún script de Google, no se establece ningún identificador y no se envía nada a Google — tampoco un aviso previo de los denominados sin cookies. El modo de consentimiento avanzado de Google ("Consent Mode v2 advanced"), en el que el script se carga de inmediato y transmite datos ya antes del consentimiento, no se utiliza, de forma deliberada.

Base jurídica: artículo 6, apartado 1, letra a), del RGPD — su consentimiento — y artículo 25, apartado 1, de la TDDDG para el almacenamiento y la lectura de la información en su dispositivo.

Destinatario y encargado del tratamiento: Google Ireland Limited, Gordon House, Barrow Street, Dublin 4, Irlanda. La base son las condiciones de tratamiento de datos de Google (Google Ads Data Processing Terms), aceptadas para el ordenamiento jurídico de Alemania.

Qué se trata: la página abierta y su título, la fuente de referencia, una ubicación aproximada a nivel de país y de región, el tipo de dispositivo, el navegador, el sistema operativo, el tamaño de pantalla y el idioma, la fecha y la hora, y un identificador aleatorio en las cookies del apartado 6.1 con el que se reconocen las visitas repetidas desde el mismo navegador. Además están activos los eventos automáticos que Google denomina "medición mejorada": profundidad de desplazamiento, la búsqueda en este sitio web, descargas de archivos, interacciones con vídeos y clics en enlaces a otros sitios web — es decir, también en los enlaces de afiliación del apartado 10.1. Google utiliza su dirección IP para deducir la ubicación aproximada y, según indica Google, al hacerlo no la registra ni la almacena.

Qué no tiene lugar: las funciones "Señales de Google" y "publicidad personalizada" están expresamente desactivadas en el código fuente de la página (allow_google_signals y allow_ad_personalization_signals están ambas en false), y la compartición con "productos y servicios de Google" está desactivada en la propiedad. No se crean listas de publicidad ni de audiencias, no se comunican datos a Google con fines publicitarios y no se elaboran perfiles entre dispositivos. No tiene lugar ninguna decisión automatizada, incluida la elaboración de perfiles, en el sentido del artículo 22 del RGPD. En la página no están integrados otros servicios de análisis, ni redes publicitarias, ni complementos sociales, y tampoco ningún script de un servicio de informes de errores: el navegador no carga nada de un servicio de ese tipo y no le envía nada. El diagnóstico de errores que BrickDb utiliza realmente se ejecuta en el servidor y — en la aplicación — en el propio dispositivo; se describe en el apartado 11.

Transferencia a terceros países: la parte contratante es Google Ireland Limited; no puede excluirse una transferencia a Google LLC en los Estados Unidos. Google LLC está certificada conforme al EU-US Data Privacy Framework, para el que la Comisión Europea adoptó una decisión de adecuación el 10 de julio de 2023; de forma complementaria se aplican las cláusulas contractuales tipo de las condiciones de tratamiento de datos de Google.

Plazo de conservación: los datos relativos a eventos y a usuarios se conservan en la propiedad de Google Analytics hasta 14 meses desde su última interacción y después Google los elimina. El plazo corre desde la última visita y no desde la primera, porque en la propiedad está activa la opción "restablecer con nueva actividad": cada nueva visita reinicia los 14 meses. Así pues, los datos de quien vuelve con regularidad no se eliminan mientras siga volviendo. Afecta a los datos asignados a eventos e identificadores individuales. Los informes estándar agregados — por ejemplo, "cuántas páginas vistas tuvo septiembre" — no están comprendidos en ese ajuste y siguen disponibles en Google más allá de él. La cookie de consentimiento de su dispositivo caduca a los 182 días; después se vuelve a plantear la pregunta.

Retirada del consentimiento: al pie de cada página se encuentra el área "medición de uso" con un botón que invierte su decisión — un clic, igual que lo fue aceptar (artículo 7, apartado 3, del RGPD). La retirada surte efecto de inmediato: el script deja de cargarse, y las cookies establecidas por Google (_ga y _ga_…) se borran con la misma solicitud. La licitud del tratamiento efectuado hasta la retirada no se ve afectada. Respecto de los datos ya transmitidos a Google puede ejercer además los derechos mencionados en el apartado 14.

Qué significa esto para las cifras: solo se cuenta a quien ha aceptado. Por ello las cifras son incompletas y quedan por debajo del uso real. Esa es la consecuencia buscada de la decisión de no cargar nada sin consentimiento.

10.1 Enlaces de afiliación

BrickDb participa en programas de afiliación; los enlaces correspondientes se identifican directamente con "Publicidad". Esto no cambia nada de lo dicho arriba: no se integra en la página ninguna red publicitaria, no se carga ningún script ni píxel de recuento de una red de afiliación y no se establece ningún identificador. Con la mera apertura de una página no ocurre nada a este respecto.

Solo cuando una persona hace clic en un enlace de ese tipo, su navegador abre la dirección del comerciante o de la red de afiliación. Es un cambio de página provocado por la propia persona, del que es responsable, en materia de protección de datos, el sitio enlazado. La dirección contiene un identificador por el que el comerciante reconoce que la visita procede de BrickDb; es visible en la barra de direcciones. BrickDb no llega a saber quién ha hecho clic: la red de afiliación facilita exclusivamente datos de liquidación agregados, ningún dato personal sobre clics individuales.

Awin. Los enlaces a comerciantes cuyos precios BrickDb toma de un feed de datos de productos de Awin pasan por la red de afiliación Awin (AWIN AG, Berlín). BrickDb muestra un enlace de ese tipo sin modificarlo, tal como figura en el feed: contiene el identificador de editor (publisher) de BrickDb, el identificador del comerciante y el destino en el comerciante, y nada sobre usted - ningún identificador de cuenta ni ningún identificador de clic o de visitante asignado por BrickDb. Si hace clic en él, su navegador abre primero una dirección de Awin (awin1.com) y desde allí se le redirige al comerciante. Al hacerlo, Awin puede recabar información directamente de usted y establecer o leer cookies en su navegador en su propio dominio, para atribuir una compra posterior a ese clic, conforme a la política de privacidad propia de Awin. BrickDb no establece ninguna cookie para ello, no registra el clic en su propio servidor y no transmite por sí mismo ningún dato sobre usted a Awin.

Rakuten Advertising. Los enlaces a tiendas en línea que opera la propia LEGO y cuyos precios BrickDb toma de un feed de datos de productos de Rakuten Advertising pasan por la red de afiliación Rakuten Advertising, al igual que el enlace a la tarjeta regalo de LEGO en Giftcards.com que una página de set ofrece a los visitantes de los EE. UU. El responsable es Rakuten Marketing LLC dba Rakuten Advertising, 800 Concar Drive, Suite 175, San Mateo, CA 94402, EE. UU., según su propia indicación también para los visitantes del Reino Unido y del Espacio Económico Europeo. A efectos de su política de privacidad, Rakuten Advertising indica como establecimiento en la UE a Rakuten Advertising France S.A.S, 92 rue Réaumur, 75002 Paris, Francia, y en el Reino Unido a Rakuten Marketing Europe Limited, Vintners Place, 68 Upper Thames St., London EC4V 2AF, Reino Unido. También este enlace lo muestra BrickDb sin modificarlo, tal como figura en el feed de datos de productos: contiene el identificador de editor de BrickDb, un identificador de oferta y la dirección de destino en la tienda, y nada sobre usted. El enlace a la tarjeta regalo de LEGO no procede del feed de datos de productos: Rakuten Advertising lo generó una sola vez para BrickDb, y contiene igualmente solo el identificador de editor de BrickDb, el identificador de Giftcards.com y la dirección de destino en Giftcards.com. Si hace clic en él, su navegador abre primero una dirección de Rakuten Advertising (click.linksynergy.com) y desde allí se le redirige a la tienda. Al hacerlo, Rakuten Advertising puede recabar información directamente de usted y establecer o leer cookies en su navegador en su propio dominio, para atribuir una compra posterior a ese clic, conforme a la política de privacidad propia de Rakuten Advertising. Sus derechos frente a Rakuten Advertising los ejerce mediante su formulario de solicitudes de privacidad; las posibilidades de contacto figuran aquí. BrickDb no establece ninguna cookie para ello, no registra el clic en su propio servidor y no transmite por sí mismo ningún dato sobre usted a Rakuten Advertising.

Tradedoubler. Los enlaces a la librería Hugendubel, cuyos precios BrickDb toma de un feed de datos de productos de Tradedoubler, pasan por la red de afiliación Tradedoubler. Según la política de privacidad propia de Tradedoubler, el responsable es Nyorda AB (Suecia), la sociedad matriz del grupo Tradedoubler. También este enlace lo muestra BrickDb sin modificarlo, tal como figura en el feed de datos de productos: contiene el identificador de editor de BrickDb, los identificadores del programa y del producto y la dirección de destino en Hugendubel, y nada sobre usted. Si hace clic en él, su navegador abre primero una dirección de Tradedoubler (pdt.tradedoubler.com) y desde allí se le redirige a Hugendubel. Al hacerlo, Tradedoubler puede recabar información directamente de usted y establecer o leer cookies en su navegador en su propio dominio, para atribuir una compra posterior a ese clic, conforme a la política de privacidad propia de Tradedoubler. Sus derechos frente a Tradedoubler los ejerce en privacy@tradedoubler.com. BrickDb no establece ninguna cookie para ello, no registra el clic en su propio servidor y no transmite por sí mismo ningún dato sobre usted a Tradedoubler.

Amazon. En calidad de Afiliado de Amazon, obtengo ingresos por las compras adscritas que cumplen los requisitos aplicables. BrickDb participa en los programas de afiliados de Amazon para amazon.com (operado por Amazon.com Services LLC) y amazon.de (operado por Amazon Europe Core S.à r.l.). Una página de set enlaza a una búsqueda en la tienda de Amazon correspondiente; en BrickDb no se carga nada de Amazon - ningún script, ninguna imagen, ningún precio y ningún logotipo. Si sigue un enlace de ese tipo, se encuentra en el sitio web propio de Amazon; allí Amazon puede recabar información directamente de usted y establecer o leer cookies en su navegador, conforme a la política de privacidad propia de Amazon. BrickDb recibe de Amazon solo informes agregados, ningún dato sobre visitantes individuales.

Un añadido desde la medición de uso: si usted la ha aceptado conforme al apartado 10, el clic en un enlace de ese tipo se cuenta además como evento en Google Analytics — con la dirección de destino, sin ninguna indicación de quién ha hecho clic, salvo el identificador aleatorio allí descrito. Sin su consentimiento tampoco ocurre eso.

11. Supervisión del funcionamiento y diagnóstico de errores

La aplicación está instrumentada con OpenTelemetry. Esos datos solo se exportan si se ha configurado expresamente un destino; en funcionamiento no hay configurado ningún destino de ese tipo, de modo que estos datos de telemetría no salen del proceso. Las llamadas a los puntos de conexión de estado quedan excluidas del registro.

Para los informes de errores se utiliza además el servicio Sentry. Si la aplicación se cierra por un fallo, o si una solicitud falla de forma inesperada en el servidor, se transmite un informe de error a Sentry para que el fallo pueda encontrarse y corregirse. Esto afecta a cuatro puntos: el servidor de API, el servidor web, el servicio de lectura del apartado 8.5 y — a diferencia de todo lo demás de este apartado — la aplicación de su dispositivo. En los cuatro casos la conexión con Sentry la establece la propia aplicación; en el sitio web no está integrado ningún script de un servicio de informes de errores, de modo que el navegador no envía nada allí por iniciativa propia (apartado 10).

El proveedor es Functional Software, Inc. d/b/a Sentry, 45 Fremont Street, 8th Floor, San Francisco, CA 94105, EE. UU. En esta medida es encargado del tratamiento conforme al artículo 28 del RGPD. Según sus propias indicaciones, Sentry no mantiene en la Unión Europea ningún establecimiento con el que pudiera celebrarse un contrato — la parte contratante es, por tanto, una empresa con sede en los Estados Unidos.

Lugar del tratamiento: cuestión distinta es dónde se encuentran los datos. Los informes van a la región de la UE de Sentry, que el propio Sentry denomina European Union (EU) y que está configurada como región de almacenamiento de nuestra organización. La dirección de recepción de los cuatro puntos está en ingest.de.sentry.io y no en la dirección mundial del servicio. Son dos cosas distintas, y solo la segunda es un nombre de host: la dirección a la que envía el software, frente al ajuste de la cuenta que decide dónde se guarda lo recibido.

Transferencia a terceros países: como la parte contratante tiene su sede en los Estados Unidos, no puede excluirse un acceso desde allí — por ejemplo, en el marco del soporte y el mantenimiento. Sentry basa tales transferencias en las cláusulas contractuales tipo de la Comisión Europea, en las que se fundamenta el contrato de encargo del tratamiento en su versión 5.1.0 de 29 de mayo de 2024.

Qué contiene un informe de error: el tipo de error y su mensaje, la traza técnica de llamadas (archivos, métodos, números de línea), la versión de BrickDb, la dirección solicitada con sus parámetros de consulta, salvo los que se eliminan como se describe más abajo, en el servidor de API y en el servidor web además las cabeceras de la solicitud — por ejemplo, la identificación de su navegador, el idioma preferido y la página desde la que usted llegó — y los datos que el SDK de Sentry recopila por iniciativa propia sobre el entorno — en particular el modelo de dispositivo, el sistema operativo y su versión, el idioma y la zona horaria. En el servidor de API se añade el identificador seudónimo de su cuenta si usted había iniciado sesión; el servidor web y la aplicación no transmiten ningún identificador.

Qué comunica el servicio de lectura: el servicio de lectura del apartado 8.5 envía un informe de error solo cuando la lectura de una foto falla de forma inesperada; que esté saturado o que rechace una foto no lo comunica. Un informe de ese tipo contiene el tipo de error y su mensaje, la traza técnica de llamadas, la versión de BrickDb, la dirección interna en la que lo llamó el servidor de API, las cabeceras de esa llamada interna — no las de su navegador — y los datos del entorno del servidor. El servicio de lectura no transmite ningún identificador de su cuenta. La foto enviada no está contenida nunca en un informe del servicio de lectura, tampoco en parte: el contenido de una solicitud no se recoge, y el servicio de lectura no registra nada sobre la foto.

Qué anota además la aplicación: para que un fallo en su dispositivo pueda reconstruirse, la aplicación adjunta a un informe de error un rastro de actividad. Contiene los nombres de las páginas abiertas más recientemente (no sus direcciones); para cada solicitud a nuestro servidor que no tuvo éxito, el método, la dirección como patrón sin identificadores, el código de estado, la duración y, si se conoce, el tipo de error; los ajustes anotados al arrancar — la dirección del servidor sin ruta, si el inicio de sesión y los informes de errores están activados y el idioma configurado —; y, como el SDK de Sentry lleva su propio rastro de solicitudes, para cada solicitud de la aplicación — a nuestro servidor y al servicio de inicio de sesión — además la dirección completa con el método y el código de estado, incluida la ruta, que puede contener, por ejemplo, un número de set o el identificador de una colección, y los parámetros de consulta, por ejemplo un término de búsqueda. También de esta dirección se eliminan antes del envío los parámetros de consulta antes mencionados cuyo nombre apunta a un secreto, así como las direcciones de correo electrónico. La misma dirección puede figurar además en una traza de rendimiento, que Sentry crea para una proporción elegida al azar del 2 % de las operaciones de la aplicación.

Datos sobre el dispositivo: cada informe que la aplicación envía después de arrancar lleva la plataforma, la versión del sistema operativo, el tipo de dispositivo (por ejemplo, teléfono o tableta) y la versión de la aplicación; una vez ejecutada la comprobación de la presentación al arrancar, además el tipo y la versión principal de la vista web en la que se ejecuta la aplicación. Si la aplicación no carga una imagen, una hoja de estilos, un script o una fuente tipográfica, o bloquea un contenido por razones de seguridad, se anota qué era — en los archivos propios, la ruta sin identificadores; en las direcciones ajenas, solo el nombre del servidor; en una fuente tipográfica, su nombre —, y una vez al arrancar una comprobación de la presentación: qué hojas de estilos se cargaron, cuántas reglas contienen y qué fuente tipográfica se utiliza realmente. Un fallo de carga de ese tipo, un error del servidor o una solicitud que no recibe ninguna respuesta pueden desencadenar un informe propio también sin que la aplicación se cierre — el mismo fallo, en una solicitud, como máximo una vez en diez minutos; en un fallo de carga, como máximo una vez por arranque de la aplicación.

El registro en su dispositivo: la aplicación escribe en un registro situado en el área de almacenamiento propia de la aplicación: cada solicitud a nuestro servidor — también cada una que tiene éxito — con el método, la dirección como patrón sin identificadores, el código de estado, la duración y un número de operación aleatorio; los fallos de carga antes mencionados; el resultado de la comprobación de la presentación al arrancar, incluidos el tipo y la versión de la vista web; los ajustes anotados al arrancar; y los demás mensajes de la aplicación a partir del nivel "Information". Los nombres de las páginas abiertas, el tipo de un error, los datos sobre el dispositivo y las direcciones completas del rastro propio de Sentry no figuran en este registro. Abarca como máximo tres archivos de un megabyte cada uno, las entradas más antiguas se sobrescriben, y cada entrada se depura al escribirse igual que un informe de error. Este registro no sale del dispositivo por sí solo. Solo si usted pulsa "Copiar diagnóstico" en "Acerca de", la aplicación coloca la versión de la aplicación, la plataforma, la versión del sistema operativo, el tipo de dispositivo, los ajustes anotados al arrancar y hasta 200 de las últimas entradas — depuradas una vez más — en el portapapeles; dónde las pega lo decide usted.

Qué se elimina expresamente antes de que un informe salga del dispositivo o del servidor: todas las cookies, el contenido íntegro de una solicitud, todo parámetro de consulta cuyo nombre apunta a un secreto (entre otros code, state, token, password, email, key), todo valor de cabecera cuyo nombre apunta a un secreto, toda cabecera en la que nuestros servidores antepuestos transmiten su dirección IP, así como las direcciones de correo electrónico y las cadenas de caracteres con aspecto de token — también en medio de un mensaje de error. Un nombre de usuario, una dirección de correo electrónico o una dirección IP en la sección de usuario del informe se sobrescribe antes de que se envíe el informe, al igual que el identificador de instalación que el SDK escribe allí por iniciativa propia. Esta depuración está construida de modo que, en caso de fallo, descarta el informe en lugar de enviarlo sin filtrar.

La propia aplicación no transmite ninguna dirección IP: SendDefaultPii está en false en los cuatro puntos, la depuración que se acaba de describir sobrescribe ese campo de todos modos, y elimina también las cabeceras en las que nuestros servidores antepuestos transmiten su dirección IP al servidor web y al servidor de API. No se adjuntan capturas de pantalla, y los textos de la interfaz de usuario no se incorporan a los rastros de actividad; ambas cosas están expresamente desactivadas. Las fotos no pueden llegar a un informe de error, porque el contenido de una solicitud se elimina por completo de todos modos.

Trazas de rendimiento en el servidor: con independencia de que se produzca un error, el servidor web, el servidor de API y el servicio de lectura crean una traza de rendimiento para una proporción elegida al azar de las solicitudes y la transmiten a Sentry, para que puedan encontrarse los puntos lentos; las llamadas a los puntos de conexión de estado y las solicitudes de prueba de nuestros servidores antepuestos quedan excluidas. La proporción es del 5 %. No obstante, si una solicitud procede de la aplicación, del servidor web o del servidor de API y pertenece a una operación para la que allí ya se ha decidido si se mide, el servidor adopta esa decisión, de modo que una operación de ese tipo se mide en todas las etapas o en ninguna. Una traza de ese tipo contiene los mismos datos sobre la solicitud que un informe de error del servidor — el método, la dirección solicitada con sus parámetros de consulta, por ejemplo un término de búsqueda, y las cabeceras de la solicitud —, y además el patrón de la dirección solicitada sin identificadores, el código de estado de la respuesta, el inicio y la duración de la tramitación y los mensajes que la aplicación registra entretanto. A ello se añaden los distintos pasos de trabajo con su duración: las solicitudes que el propio servidor realiza al hacerlo — por ejemplo, el servidor web al servidor de API o el servidor de API al servicio de inicio de sesión —, cada una con el método, la dirección completa y el código de estado, y las consultas a la base de datos con su texto, en el que los valores insertados figuran solo como marcadores de posición y no los valores mismos. En el servidor de API, la traza lleva el identificador seudónimo de su cuenta si usted había iniciado sesión; el servidor web y el servicio de lectura no transmiten ningún identificador. En el servicio de lectura, una traza se refiere solo a la llamada interna realizada por el servidor de API; al hacerlo, no realiza por sí mismo solicitudes a otros servidores ni consultas a la base de datos, y la foto tampoco está contenida nunca en una traza. A cada traza de rendimiento se le aplica la misma depuración que a un informe de error, descrita arriba; en particular, las cookies y las cabeceras con su dirección IP se eliminan antes del envío. La base jurídica es el artículo 6, apartado 1, letra f), del RGPD; el interés legítimo consiste en operar la aplicación de forma rápida y fiable. Sentry conserva una traza de rendimiento completa durante un máximo de 90 días en nuestra tarifa; una muestra reducida de las trazas puede conservarla Sentry hasta 13 meses.

Sentry no conserva la dirección IP de la conexión. Al enviar un informe se establece una conexión a internet; la dirección desde la que se envió es, por tanto, forzosamente conocida por el servidor receptor durante la transmisión. Sentry ofrece un ajuste que descarta esa dirección en lugar de registrarla, y ese ajuste está activado para los cuatro proyectos — los del servidor de API, el servidor web, el servicio de lectura y la aplicación. Por ello, un informe de error no conserva la dirección. Esto vale también para los informes de la aplicación, en los que sería la dirección de su propia conexión a internet; en el servidor de API, el servidor web y el servicio de lectura sería la dirección de nuestros propios servidores.

Para la transmisión se aplica sin cambios todo lo demás de este apartado: el destinatario es Functional Software, Inc. d/b/a Sentry, los informes van a la región de almacenamiento antes mencionada, y la transferencia se basa en las cláusulas contractuales tipo descritas arriba. La depuración propia de Sentry en el lado del servidor está activada en su forma básica para nuestros cuatro proyectos — los del servidor de API, el servidor web, el servicio de lectura y la aplicación; no le hemos añadido reglas propias ni hemos quitado ninguna de las suyas.

Base jurídica: artículo 6, apartado 1, letra f), del RGPD — tanto para el informe de error como para la dirección IP en su transmisión. El interés legítimo consiste en detectar y corregir errores y cierres por fallo de la aplicación. La dirección no se trata para ningún fin propio y no se utiliza para reconocerle. Es la misma base sobre la que el apartado 3 trata la dirección IP que se genera forzosamente en toda conexión con el sitio web. Puede oponerse a ello conforme al artículo 21 del RGPD mediante los datos de contacto del apartado 2.

Plazo de conservación: 90 días. Cuánto tiempo se conserva un informe de error en Sentry resulta de la tarifa en la que se encuentra la organización. La nuestra se encuentra en la tarifa Business, para la que Sentry publica una conservación de 90 días; en la tarifa Developer serían 30. Los archivos adjuntos siguen al evento al que pertenecen. Para un proyecto individual puede fijarse un plazo más corto, que entonces prevalece; ninguno de nuestros cuatro proyectos tiene uno, de modo que los 90 días valen por igual para los cuatro.

12. Destinatarios

Los datos personales no se venden ni se comunican con fines publicitarios. Los destinatarios son actualmente Microsoft Ireland Operations Limited, como encargada del tratamiento para el alojamiento, la base de datos y el almacenamiento de archivos y — únicamente a petición expresa suya conforme al apartado 8.6 — para la evaluación de imágenes mediante Azure OpenAI, y Twilio Inc. (“SendGrid”) como encargada del tratamiento para el envío de correo electrónico conforme al apartado 7.3, incluido el tratamiento en los Estados Unidos allí descrito. Si usted ha aceptado la medición de uso conforme al apartado 10, se añade, mientras dure, Google Ireland Limited como otra encargada del tratamiento; sin su consentimiento no recibe nada. Para el inicio de sesión conforme al apartado 7.1, Auth0 / Okta, Inc. es encargada del tratamiento, y para los informes de errores conforme al apartado 11, Functional Software, Inc. d/b/a Sentry; ambas tienen su sede en los Estados Unidos y basan la transferencia en las cláusulas contractuales tipo de la Comisión Europea, como se describe en los apartados mencionados. Los datos de eventos aprobados son públicos conforme al apartado 8.4; el vínculo con la cuenta no forma parte de ellos. Más allá de eso, solo se comunican datos cuando existe una obligación legal de hacerlo.

13. Plazos de conservación

• Datos de la colección y fotos: hasta su eliminación por el interesado o hasta la eliminación de la cuenta.
• Ajustes en el dispositivo: véase el apartado 6.1.
• Datos de la cuenta en el proveedor de identidad (apartados 7.1 y 7.2): hasta la eliminación de la cuenta, que elimina también la cuenta en Auth0.
• Medición de uso: hasta 14 meses desde la última interacción para los datos relativos a eventos y a usuarios en Google, 182 días para la cookie de consentimiento en su dispositivo — véase el apartado 10.
• Propuestas de eventos: los plazos de conservación, distintos según el estado, del apartado 8.4.
• Solicitudes de soporte: 24 meses después del cierre del ticket — véase el apartado 8.7, también sobre por qué el plazo corre desde el cierre y no desde la entrada.
• Denuncias sobre contenidos: 24 meses después de la decisión — véase el apartado 8.8, también sobre por qué el plazo corre desde la decisión y no desde la entrada, y por qué una denuncia aún no decidida no se elimina.
• Acciones de la administración sobre cuentas de usuario (registro de auditoría): 24 meses después de la acción — véase el apartado 8.9, también sobre lo que permanece cuando se elimina la cuenta. Los datos de la cuenta y el historial de inicios de sesión que se muestran a la administración se leen en directo en Auth0 y BrickDb no los almacena.
• Fotos para la lectura del número de set (apartado 8.5) y para la evaluación del estado (apartado 8.6): no se almacenan en BrickDb y se descartan al terminar la solicitud.
• Correos electrónicos enviados: BrickDb no guarda ninguna copia; sobre los datos de entrega en el proveedor de envío, véase el apartado 7.3.
• Registros en el nivel de la infraestructura: véase el apartado 3.
• Informes de errores en Sentry: 90 días — véase el apartado 11; Sentry no conserva la dirección IP de la conexión por la que se entregaron.
• Trazas de rendimiento en Sentry: completas durante un máximo de 90 días, como muestra reducida hasta 13 meses — véase el apartado 11.

Cuando se elimina una entrada, se eliminan con ella las fotos correspondientes — incluidas las versiones reducidas del apartado 8. Los datos eliminados desaparecen de las copias de seguridad con el vencimiento ordinario de estas, a más tardar a los 35 días.

14. Derechos de los interesados

Existen los derechos siguientes:

• Acceso a los datos tratados (artículo 15 del RGPD),
• Rectificación de los datos inexactos (artículo 16 del RGPD),
• Supresión (artículo 17 del RGPD),
• Limitación del tratamiento (artículo 18 del RGPD),
• Portabilidad de los datos (artículo 20 del RGPD),
• Oposición a los tratamientos basados en el artículo 6, apartado 1, letra f), del RGPD (artículo 21 del RGPD),
• Retirada de un consentimiento otorgado, con efectos para el futuro (artículo 7, apartado 3, del RGPD).

Para ejercerlos basta un mensaje informal a la dirección de correo electrónico indicada en el apartado 2.

El derecho de acceso conforme al artículo 15 del RGPD puede ejercerse además directamente y sin enviar ningún mensaje: la página de la cuenta genera una copia completa y legible por máquina de todos los datos almacenados — la cuenta y el perfil, las colecciones con sus miembros y las invitaciones que usted ha emitido, los ejemplares que contienen con sus notas, etiquetas, estado, precios de compra y notas sobre el vendedor, las minifiguras individuales y las piezas sueltas, sus ejemplares de números de revistas y de libros, sus lugares de almacenamiento y qué ejemplar se encuentra en cuál de ellos, las firmas registradas, la lista de deseos, sus propias aportaciones sobre códigos de sobre y códigos de barras de envases, sus propias propuestas de eventos en cualquier estado de moderación, los lotes de fotos de cajas que usted ha enviado, las entradas del registro de auditoría de la administración sobre su cuenta (apartado 8.9), cada foto subida, y su imagen de avatar, si subió una.

Qué no contiene esa copia, y por qué: los datos de inicio de sesión en el proveedor de identidad (dirección de correo electrónico, contraseña, historial de inicios de sesión, segundos factores registrados) — se encuentran en Auth0, que facilita por sí mismo la información al respecto; las invitaciones que otras personas han dirigido a su dirección, porque son datos de ellas y no suyos; la vista de piezas derivada de sus ejemplares, porque no contiene nada que no figure ya en la copia; las solicitudes de soporte — todas ellas, porque en esta versión ningún ticket está vinculado a una cuenta y no podemos reconocer cuáles son suyas (el apartado 8.7 indica cómo contactar con nosotros al respecto); las notas internas sobre un ticket de soporte, que nos pertenecen a nosotros y no a usted (también apartado 8.7); la breve constancia de un correo a la dirección de soporte que no se convirtió en ticket, porque no está vinculada a ninguna cuenta (apartado 8.7); las denuncias sobre contenidos, que tampoco están vinculadas a ninguna cuenta, y las notas que escribimos al decidir sobre una denuncia relativa a su contenido (apartado 8.8); quién de la administración actuó sobre su cuenta, porque esos son datos de esa persona y no suyos (apartado 8.9); y la notificación en cola relativa a una propuesta de evento enviada por usted, que solo contiene la mecánica de envío y remite a la propuesta ya enumerada arriba.

También el derecho de supresión conforme al artículo 17 del RGPD puede ejercerse allí directamente. La página de la cuenta muestra de antemano qué se va a eliminar exactamente; una vez confirmada, la eliminación se ejecuta de inmediato: la colección, los lugares de almacenamiento, las fotos (los archivos en sí, no solo las entradas) y la cuenta de inicio de sesión en el proveedor de identidad. No puede deshacerse.

Las excepciones están reguladas así de forma deliberada; a los eventos se les aplica el apartado 8.4. Sus propias aportaciones sobre los códigos de sobre se anonimizan en lugar de eliminarse: qué figura hay en un sobre es un hecho sobre un producto de LEGO que otros usuarios han determinado conjuntamente y en el que confían — la aportación se mantiene, y el vínculo con la persona se sustituye por un valor aleatorio recién generado para el que ya no existe ninguna cuenta ni ninguna correspondencia (considerando 26 del RGPD). Un ejemplar que se incorporó a una colección compartida con otras personas se anonimiza en lugar de eliminarse del mismo modo: eliminarlo privaría a los demás participantes de su entrada sobre un set que llevan en común. Por ello, el número de set, la cantidad y el estado permanecen en la colección; todo lo personal que hay en él desaparece — el apodo, las notas, las etiquetas, el lugar de almacenamiento, el precio pagado, la valoración propia y las fotos — junto con el vínculo con la persona, sustituido por un valor aleatorio generado del mismo modo. Un ejemplar de una colección en la que no hay nadie más se elimina por completo — no hay nadie a quien se le quitaría. Y las copias de seguridad siguen rigiéndose por el apartado 13: los datos eliminados desaparecen de ellas con su vencimiento ordinario, a más tardar a los 35 días.

Los distintos pasos, una enumeración de lo que se elimina y de lo que se conserva anonimizado, y la vía para las personas que ya no pueden iniciar sesión figuran resumidos en la página Eliminación de la cuenta y de los datos. Es accesible sin iniciar sesión y solo reproduce lo que figura en este apartado.

Derecho a presentar una reclamación

Con independencia de ello, existe conforme al artículo 77 del RGPD el derecho a presentar una reclamación ante una autoridad de control, en particular en el Estado miembro de la residencia habitual, del lugar de trabajo o del lugar de la supuesta infracción. La autoridad competente para el responsable del tratamiento es:

Landesbeauftragte für Datenschutz und Informationsfreiheit Nordrhein-Westfalen
Postfach 20 04 44
40102 Düsseldorf
Teléfono: +49 211 38424-0
Correo electrónico: poststelle@ldi.nrw.de
www.ldi.nrw.de

15. Obligación de facilitar datos

La comunicación de datos no es un requisito legal ni contractual. Sin datos, no obstante, las funciones de colección no pueden utilizarse de forma útil; las partes de libre acceso del servicio están abiertas sin ningún dato.

16. Modificaciones y versión lingüística que prevalece

Esta política se adaptará si cambia el tratamiento o la situación jurídica. Rige la versión publicada aquí en cada momento, con la fecha de actualización indicada arriba.

Prevalece la versión alemana. Las versiones en inglés, francés, neerlandés, danés, italiano y español son traducciones facilitadas a título informativo y no tienen efectos jurídicos propios.