Sanción de 15.000 a comunidad de propietarios

Sanción de 15.000 a comunidad de propietarios

La AEPD ha sancionado con 15.000 euros a una Comunidad de Propietarios por publicar en el ascensor de la Comunidad el acta de una reunión. (Ver sanción AEPD)

Las actas se deben enviar individualmente a cada propietario, y la ley sólo contempla su exposición en el tablón de anuncios en caso de que la comunicación a un propietario haya sido imposible (siempre que esté acreditado de forma fehaciente).

Aún así, esa exposición pública está sometida a una serie de criterios, respetando unos plazos para hacer compatible la Ley de Propiedad Horizontal con la Legislación en materia de protección de datos.

Como además, la Comunidad no tiene entidad jurídica, ahora todos los propietarios son responsables solidariamente del pago de la sanción, por lo que deberán realizar una derrama extraordinaria para el pago de la misma.

Además, como menciona alguna fuente, si la finca tiene Administrador, que determina los objetivos y medios del tratamiento de los datos personales, es posible que sea corresponsable de la infracción según el artículo 26 del RGPD.

En Adelopd ayudamos a Administradores y a Comunidades de Propietarios a cumplir la legislación de protección de datos, previniendo este tipo de incumplimientos que pueden derivar en sanciones muy elevadas.

Para ampliar información de nuestro servicio: https://www.adelopd.com/proteccion-de-datos-administradores-de-fincas/

Imagen: Gabriel Ruiz Araoz, CC BY-SA 4.0 https://creativecommons.org/licenses/by-sa/4.0, via Wikimedia Commons

Filtrado DMARC en servidor de correo

Activando DMARC en tu dominio te aseguras que ningún hacker engañe a tus clientes y proveedores, enviando mensajes en tu nombre.

El filtrado DMARC de servidor es la otra cara de la moneda. Tu servidor de correo electrónico debe tener activado ese filtrado para que los hackers no te engañen a ti (y a los usuarios de tu dominio).

Esta medida la debe implementar el administrador del servidor con el que tengas contratado el servicio de hosting.

Si utilizas un servidor con panel Plesk, es bastante fácil y directo, basta con ir a «Herramientas y Opciones», «Configuración del Servidor de Correo» y activar la casilla «Activar DMARC para comprobar el correo entrante» que por defecto viene desactivada en algunos servidores.

Google Analytics sin Cookies

Google Analytics fue una bendición para los webmasters y para el personal de marketing porque nos ofrece una herramienta gratuita genial para medir el tráfico y la optimización de nuestra web. Es tan buena, que nos cuesta vivir sin ella

EL PROBLEMA: «SIn Cookies no hay medición»

El RGPD y su estricta regulación del uso de cookies ha supuesto un trilema a los administradores de sitios web que quieren seguir utilizando las herramientas analíticas de Google.

1) Fastidiar la usabilidad: Pongo un banner gigantesco, bloqueo el contenido de detrás hasta que el usuario acepte o configure las cookies. (Como hacen las webs de importantes periódicos nacionales). Cumplo la ley, me aseguro que las mediciones son correctas pero estropeo la usabilidad de la web.

2) Falsear las mediciones: Pongo un banner más discreto y permito navegar sin que el usuario acepte o configure las cookies. Pero como molesto poco a los usuarios, no hacen click en «aceptar las cookies» y  como las cookies de medición de tráfico no saltan hasta que el usuario acepta. Cumplo la ley, pero los informes de tráfico se falsean, porque sólo reflejan un pequeño % del tráfico real.

3) Incumplir el RGPD: Paso de todo y dejo que la web cargue las cookies analíticas antes de que el usuario acepte y dé su consentimiento. Mido perfectamente el tráfico y puedo optimizar la web como siempre, pero me arriesgo a una sanción.

 

LA SOLUCIÓN: «Utiliza la Analítica sin cookies»

Shhhh. Google no quiere que lo sepas, (porque buena parte de su negocio se basa en estudiar nuestro comportamiento para proponernos la publicidad que más nos puede tentar), pero sí que es posible utilizar Google Analytics sin cookies. El desarrollador Helge Klein nos lo explica en este post (en inglés)

Básicamente se trata de modificar el comportamiento «por defecto» de Google Analytics., En vez de utilizar cookies con identificadores proporcionados por Google, generamos un identificador a partir de la IP, el agente del navegador, idioma y un intervalo de tiempo y utilizaremos ese identificador (no vinculado a datos personales) para el registro analítico de las acciones del usuario en el sistema de Google Analytics.

Haciéndolo así dejamos de utilizar cookies, Google perderá la capacidad de rastreo entre sitios, y gracias a ello respetamos los principios de privacidad recogidos en el RGPD, sin perder nuestra querida analítica.

Te explico cómo hacerlo:

En la web que quieras controlar, has de seguir utilizando el antiguo identificador de Google Analytics ( el que empieza por UA-) El sistema de medición de la última versión de Analytics (el que empieza por G-). Si no sabes cómo hacerlo aquí tienes un tutorial (en inglés): How to install google analytics 2020.

Si estás utilizando wordpress como gestor de contenidos de tu web, lo tienes fácil, Instala el plugin de Google Analytics sin cookies. Le pegas el código de seguimiento UA-*** y a funcionar.

Si estás utilizando otro sistema de gestión de sitios web, le has de añadir un script a la sección de cabecera <head> de tu web. El script que te indico funciona si el servidor tiene instalado php, de no ser así, busca cómo insertar dentro del código la dirección IP (linea 15 del código)

Este es el fragmento que has de insertar (Sustituyendo UA-******* por el código de tu propiedad)

Problemas al activar DMARC

La decisión de activar DMARC en un dominio, puede presentar básicamente dos tipos de problemas para los correos salientes desde el dominio:

1) Redirecciones habilitadas por nuestros clientes / proveedores

Algunos clientes / proveedores que tienen un correo del tipo hola@clienteuno.com pero que tienen contratado un servicio de hosting lowcost, que no tiene buzón físico, sino una redirección a un correo gratuito del tipo clienteuno@gmail.com o clienteuno@hotmail.com 

Si activamos DMARC esos clientes/ proveedores dejarán de recibir nuestros correos. ¿Por qué?
Porque por funcionamiento de estas redirecciones, lo que hace el servidor de nuestro cliente es reenviar a clienteuno@gmail.com el correo que enviamos nosotros, como si fuésemos nosotros. Técnicamente está falsificando la identidad de nuestro dominio para escribir a clienteuno@gmail.com Por ello cuando el correo llega a gmail y el sistema de Google verifica el origen del correo, se da cuenta que NO se ha originado en un servidor autorizado y lo rechaza.

¿Esto supone un problema grave en 2020? En Adelopd activamos DMARC hace más de 6 meses y tuvimos este problema en menos del 0,2% de los correos que enviamos. Pero es bueno tenerlo en cuenta.

 

2) Envío de correos desde plataformas externas.

Cuando una empresa utiliza servicios de plataformas externas para enviar correos electrónicos en nombre de su dominio. Ejemplo: Plataformas de envío de correos electrónicos masivos, como Mailchimp, SendinBlue, Acumbamail, etc

En ese caso ANTES de activar DMARC, hemos de modificar la política SPF para que incluya el servicio externo que va a enviar en nombre de nuestro dominio. De no hacerlo así, los correos electrónicos enviados desde esa plataforma se irían a spam o serían directamente rechazados por los servidores de los destinatarios.

Si una empresa no utiliza plataformas externas, y se limita a enviar correos electrónicos desde su programa de escritorio (Outlook, Thunderbird…) o desde su gestor de webmail, la activación del DMARC no tiene por qué suponer ningún problema en la entrega de sus correos electrónicos.

 

 

 

SPF No es suficiente

Hoy hemos recibido un correo del Ministerio del Interior, relativo a una multa impagada.

La primera impresión es que se trataba de un correo fraudulento, pero al mirar el remitente, me ha parecido legítimo. Lo envía:

Ministerio del Interior<multas@interior.gob.es>

He revisado las cabeceras del mensaje, y me ha mosqueado bastante que el Ministerio del Interior utilice un servidor ruso para enviarme una notificación de una multa:

Received: from 194-58-108-196.ovz.vps.regruhosting.ru 
(194-58-108-196.ovz.vps.regruhosting.ru [194.58.108.196])

He consultado el registro SPF del subdominio interior.gob.es, y me he encontrado esto:

El Ministerio del Interior, sí tiene publicado un registro SPF en el que informa que los correos legítimos los envía desde los servidores autorizados para recibir correos (MX).

He revisado cuáles son estos servidores:

Y resulta que no tienen publicado ningún servidor de correo entrante para este subdominio (interior.gob.es). O sea, que aunque contestes a multas@interior.gob.es, ese correo será devuelto porque no hay dado de alta ningún servidor de correo para ese subdominio.

Por tanto, tal y como suponía, el servidor ruso que me ha enviado el correo con la multa, NO está autorizado por la política SPF del subdominio interior.gob.es

Y sin embargo, extrañamente, mi servidor de correo entrante no ha rechazado el correo.

Intrigado, he analizado todas las cabeceras del mensaje con la ayuda del servicio de MXToolbox

He ahí mi sorpresa: Puesto que el subdominio interior.gob.es no tiene activado DMARC, el SPF que consulta no es el del dominio interior.gob.es, sino el del servidor ruso que ha enviado el mensaje.

Esto me ha confirmado que tener publicado el registro SPF, si no tienes activado DMARC no sirve de nada. Cualquier hacker de medio pelo puede enviar correos haciéndose pasar por un usuario de ese dominio, y los servidores de correo no lo filtrarán.