Google fue demandado por engañar a los usuarios en su modo «incógnito»

Hace pocos días, se dio a conocer información sobre una demanda colectiva con la cual está lidiando Google y en la cual Google ha anunciado importantes cambios en la advertencia asociada al modo incógnito en su popular navegador web, Chrome.

Y es que ante la reciente demanda, Google ha llegado a un acuerdo para resolver litigios relacionados con violaciones de privacidad y realizar modificaciones que tienen como objetivo proporcionar a los usuarios una comprensión más clara de las limitaciones de privacidad en este modo «semiprivado».

Google fue acusado de violar las leyes federales de escuchas telefónicas de Estados Unidos y las leyes de privacidad de California. La demanda alega que Google podría utilizar datos analíticos de sus diferentes servicios, cookies del navegador y sus aplicaciones para rastrear la actividad del usuario cuando Chrome está habilitado en modo incógnito, así como cuando utiliza el modo de navegación privada en otros navegadores. Este tipo de seguimiento proporcionaba acceso incontrolado a información sobre amigos, pasatiempos, comidas favoritas, hábitos de compra y cosas vergonzosas que los usuarios no querían revelar y creían que estaban usando el modo incógnito para proteger su privacidad.

También se menciona que Google ha elegido el nombre engañoso «incógnito», que da la impresión de que el usuario recibe anonimato y protección contra la actividad de navegación, en lugar de simplemente no almacenar el historial de navegación y borrar datos relacionados con el sitio, como las cookies. La controversia destaca la importancia de la transparencia por parte de las grandes empresas tecnológicas en cuanto a las prácticas de privacidad, así como la necesidad de que los usuarios estén informados sobre las limitaciones reales del modo incógnito.

La demanda alega que Google rastrea a los usuarios de Chrome en sitios web propios y de terceros, incluso cuando se activa el modo incógnito, del cual Google sostiene que este modo está diseñado para evitar el almacenamiento local de datos, no para evitar el seguimiento en línea, la nueva advertencia busca aclarar aún más estas distinciones.

Google reconoce que, aunque otros usuarios en el mismo dispositivo no verán la actividad en modo incógnito, los sitios web y servicios, incluidos los de Google, aún pueden recopilar datos. La actividad, como descargas, favoritos y elementos de la lista de reproducción, se almacenará.

Este cambio en la advertencia destaca la importancia de educar a los usuarios sobre la privacidad en línea. Aunque el modo incógnito puede ofrecer cierta protección, no es suficiente para garantizar la privacidad completa en la web.

El acuerdo, aún pendiente de aprobación judicial, incluye cambios en la advertencia del modo incógnito, y Google deberá proporcionar información adicional en su sitio web y campañas publicitarias. Como parte de esta iniciativa, se ha implementado una advertencia en Chrome Canary, la versión nocturna para desarrolladores.

El resultado de esta demanda podría tener un impacto significativo en las regulaciones de privacidad en línea y en cómo las empresas abordan la comunicación de sus funciones de privacidad.

Los términos del acuerdo no fueron revelados, pero la demanda original se presentó en el 2020, y de manera inicial la demanda pretendida cubrir a “millones” de usuarios de Google desde el 1 de junio de 2016 y pedía al menos 5.000 dólares en daños y perjuicios por usuario por violaciones de las leyes federales de escuchas telefónicas y de privacidad de California.

Hasta el momento, solo se han resuelto algunos cambios que han sido acordados por las partes en conflicto, además de que aún deben ser aprobados por un juez federal en una audiencia programada para el 24 de febrero, ya que la audiencia fue aplazada en diciembre de 2023, para poner fin a la disputa.

Finalmente, cabe mencionar que ningún navegador ofrece el 100% de privacidad ni anonimato al usuario, lo que si, es que entre los diferentes navegadores existentes, podremos encontrar navegador web (como por ejemplo brave) que ofrecen capas adicionales de protección de los datos del usuario, pero esto no los vuelve 100%  eficientes en ello, pues incluso navegadores como Tor (para la dark web) tiene sus fallos.

Fuente: https://www.reuters.com/

from Linux Adictos https://ift.tt/w9rkm5a
via IFTTT

logo de ntpsec

NTPsec es un proyecto de código abierto que se centra en el desarrollo de una implementación segura y mejorada del Protocolo de Tiempo de Red (NTP), el cual es ampliamente utilizado para sincronizar los relojes de los sistemas informáticos en una red, asegurando una medición precisa y consistente del tiempo.

Este tipo de componentes, suelen ser los que la mayoría de los usuarios ignoramos (y me incluyo porque hasta hace algunos meses no había comprendido la importancia de este pequeño protocolo), ya que al ser algo que está detrás de nuestro día a día, es algo que pasa desapercibido.

En mi caso descubrí la importancia de NTP al querer realizar una «simple actualización» de mi sistema (Arco Linux) que deje durante varios meses sin abrir. Para no hacer el cuento largo, después de que se descargaron todas las actualizaciones y en teoría se debían instalar, simplemente no se instalaron, pues me aparecían un problema con las claves OpenPGP de los paquetes y por obvias razones de haber dejado el sistema durante meses, esto hiba a generar un grave problema.

Después de haber hecho 101 y una cosas e intentar de todo e incluso exorcizar a mi equipo, simplemente no podía resolver mi problema y la solución más próxima era volver a instalar el sistema desde cero, algo que no era de mi agrado.

Algo que note durante todo el proceso de intentar solucionar el problema, es que la hora de mi sistema era diferente a la de mi localidad e investigando un poco ese pequeño cambio horario generaba un problema al intentar importar las claves nuevas (tal y como lo menciona la bendita wiki de arch). Al leer esto, una palmada en mi frente fue lo primero que genero y procedí a intentar cambiar la hora e inmediatamente procedí a reiniciar para verificar si la fecha y hora del BIOS eran correctos, lo cual asi era. Posterior a ello volví a iniciar el sistema a disponerme a realizar el cambio como si de un proceso común en Windows o Android se tratara, y lo cual fue grave error de tener las costumbres antes de analizar.

Por más que intente resolver el problema de una forma u otra, lo que generaba el problema en mi sistema era el paquete ntp de mi instalación, por alguna razón que nunca pude resolver el paquete simplemente me estaba causando problemas. Aquí es donde encontré NTPsec la cual fue mi solución después de varias ahora de intentar solucionar mi problemática.

NTPsec es una implementación mejorada de NTP que cuenta con muchas mejoras de seguridad, pues cuenta con la implementación del estándar Network Time Security de IETF para una autenticación criptográfica sólida del servicio horario. En total, más del 74% del código base de NTP Classic se ha eliminado por completo, y se ha agregado menos del 5% de código nuevo al núcleo crítico para la seguridad y también hay un uso más consistente de la precisión de nanosegundos.

Entre las mejoras de seguridad, se eliminaron modos y funciones obsoletas, se adoptó el estándar RFC de Minimización de datos del cliente NTP y se incorporó la seguridad de tiempo de red. Además, se realizaron cambios en la sincronización horaria y mejoras en las herramientas del cliente, con nuevas utilidades como ntpmon y ntpviz para monitoreo en tiempo real y visualización de datos, respectivamente.

Explicando un poco esto, podemos entender un poco más la importancia de este «pequeño» componente que, para un usuario normal le dio varios dolores de cabeza y en entornos críticos no quiero imaginar el desastre que puede generar.

Dada una «no tan extensa» explicación de la importancia de NTP, la razón de contar mi pequeña “aventura” es porque hace poco fue lanzada la nueva versión de NTPsec 1.2.3 :

Entre las mejoras en la nueva versión se incluyen:

• Alineación modificada de los paquetes del protocolo de control Mode 6, lo que podría afectar la compatibilidad con NTP clásico. El Mode 6 se utiliza para transmitir información sobre el estado del servidor y cambiar el comportamiento en tiempo real.
• Se ha implementado el algoritmo de cifrado AES de forma predeterminada en ntpq.
• Utilización del mecanismo Seccomp para bloquear nombres de llamadas al sistema incorrectas.
• Se ha habilitado la recopilación de estadísticas con reinicio cada hora, con registros adicionales para NTS, NTS-KE y ms-sntp.
• Inclusión de la opción «update» en buildprep.
• Mejoras en la presentación de datos de retardo de paquetes en la salida JSON de ntpdig.
• Se añadio soporte para la lista ecdhcurves.
• Se corrigió la compilación en plataformas que -fstack-protector dependen de libssp, como musl.
• Se corrigió el fallo de ntpdig al utilizar 2.ntp.pool.org con un host sin soporte IPv6.

Finalmente si estás interesado en poder conocer más al respecto, puedes consultar los detalles en el siguiente enlace.

from Linux Adictos https://ift.tt/YZzurAt
via IFTTT

Aunque mi compañero Diego los defiende, le gustan y recomienda, por lo menos algunos de ellos y como mínimo no ataca al tipo de paquete, creo que no me equivoco si afirmo que está muy poco acompañado en su postura. Canonical hizo oficial la disponibilidad de los paquetes snap en 2016 con Ubuntu 16.04 Xenial Xerus, nos prometió el cielo y yo sólo leo comentarios negativos de la comunidad Linux. En mi caso concreto, y me consta que no soy el único, he llegado a deshacerme de ellos completamente.

Lo que sí triunfa son los flatpak, y en Flathub, el repositorio más popular, encontramos prácticamente todo. Por poner algunos ejemplos, el navegador Vivaldi, Bottles o casi la totalidad de las aplicaciones del círculo de GNOME. Gustan más, y también parece ser que presentan menos problemas. En muchas ocasiones son los desarrolladores de los diferentes programas los que los suben, a diferencia de lo que pasa en Snapcraft que mucho lo reempaqueta Canonical. Esto mismo pasa con el paquete snap de Steam, y Valve desaconseja su uso tras los muchos reportes de bugs que está recibiendo.

Valve desaconseja el uso de los paquetes snap, por lo menos el de Steam

Hace mucho tiempo, para ser honesto no recuerdo cuándo ni dónde leí cierta información, pudo ser incluso aquí en LXA pero no lo encuentro en el archivo, se hablaba del buen trabajo que estaba haciendo Canonical con el paquete snap de Steam, hasta el punto de que se echaban ciertas pullitas a otras opciones. Ahora, algunos meses o años después, Valve está recibiendo cada vez más quejas de usuarios que reportan bugs con este paquete, por lo que recomiendan usar la versión .deb que ellos mismos empaquetan o por lo menos usar el paquete flatpak.

Ha sido Timothee Besset quien lo ha publicado en Mastodon (vía GamingOnLinux):

«Valve está recibiendo un número creciente de informes de errores por problemas causados por el reempaquetado de Canonical del cliente de Steam a través de snap.

La mejor manera de instalar Steam en Debian y sistemas operativos derivados es seguir las instrucciones en http://repo.steampowered.com/steam y utilizar el .deb oficial.

No estamos involucrados en el reempaquetado snap. Tiene muchos problemas.

Si no quieres el .deb, por favor considera al menos la versión flatpak».

La versión flatpak no está verificada, pero eso no significa que un proyecto no esté involucrado. Tampoco lo está Vivaldi Browser, y quien lo sube forma parte del equipo oficial. Lo que sí es seguro es que no tienen nada que ver con el reempaquetado del snap, y que éste está presentando muchos problemas que escapan a su control.

No es un ataque, pero…

Lo comentado por Timothee Besset no es un ataque directo y gratuito a los paquetes snap. Es sencillamente contar un hecho que está ocurriendo. Si los usuarios de Steam se quejan del mal funcionamiento del programa y el programa lo están editando de alguna manera terceros desarrolladores, poco o nada pueden hacer para identificar el problema y encontrar una solución.

Lo mejor para los usuarios de Debian/Ubuntu es usar el paquete .deb, que es lo nativo y sale directamente del horno de Valve. Después, el paquete flatpak. Para el resto de distribuciones, pues dependerá. Si no tienen problemas con el paquete snap, no deja de ser una opción, pero debería tomarse en consideración después del flatpak.

Y para los que no quieran ni lo uno ni lo otro, la opción que les que da es ver si su distribución Linux lo ofrece en sus repositorios oficiales. Yo desde aquí lo único que puedo hacer es recomendar lo mismo que Valve, y el paquete snap debería ser lo último por probar.

Los usuarios de una distribución basada en Debain/Ubuntu pueden descargar la última versión de Steam en formato .deb desde la página web oficial de Steam. En este otro enlace hay información para hacerlo manualmente. Los usuarios de otras distribuciones Linux pueden encontrar el tarball aquí.

from Linux Adictos https://ift.tt/SPFfj8H
via IFTTT