#174 No siempre es necesario. Hay muchos escenarios (no éste) donde quieres validar la condición preservando el anonimato pero no te preocupa la suplantación del titular, en cuyo caso obtienes una certificación a priori y la usas cuando quieras con el servicio sin que la FNMT de tu ejemplo se entere del uso (un zkp básico).
Tu ejemplo expone uno de los problemas que tratan de evitarse o mitigarse (sin éxito), que el emisor se involucre en la fase de presentación, o en otras palabras, que el gobierno (agente de en la fase de emisión) sepa qué servicios consumes (fase de presentación). Muchas soluciones lo mitigan, pero en tu ejemplo es que el servicio llama para decirlo directamente.
Por lo demás, legalmente copiar la certificación no sería suplantación de identidad; primero porque no te identifica ante el servicio (solo muestra que cumples una condición) y segundo porque cogerle el dni a tu hermano mayor para comprar una cerveza no es (legalmente) suplantación de identidad.
#171 Como ya te he dichooo... ya me lo leí en su día y ahora le he vuelto a echarun ojo por encima como te he referido en #157.
Lo bueno de un sistema así es que se podría saber tu nombre y apellidos, y podríamos ver tus comentarios aquí señalando a quién los ha hecho. Desde luego si te dedicases a algo de esto y pudiera identificarse no ibas a poder trabajar en la vida!
A mí me encantaría tener tus comentarios con nombre y apellidos para que todo el mundo sepa como eres
#98 Entiendo que hablas de ZKP y similares, el problema es que además de tener la certificación de la condición del proveedor de identidad, necesitas garantizar que esa prueba sea sólo utilizada por el titular, de otra forma un menor podría copiar la certificación de un adulto y hacerse pasar por él. Esto ya cambia todo. Las piezas del puzzle que venden algunos funcionan bien por separado, pero cuando las pones todas juntas cada una tira en direcciones opuestas y tienes que hacer concesiones por algún lado. No puedes tener a la vez clasificación verificable, anonimato, no correlación, no transferibilidad y reutilización.
#162 Da la casualidad de que sí tengo algo de idea pero esto no tiene naaaada que ver con certificados ni firmas, NADA. Lo he mencionado antes en #110, también he hecho un resumen en #157 de los problemás que aparecen con la propuesta de un vistazo.
#145 Son fragmentos y además varios ahora que lo he mirado con más tiempo. Aún peor. Aunque sólo en el 11 se incluye client_id y el request_url que está asociado a return_url, la credencial está bound al RP. El RP conoce qué credenciales acepta y cuándo las ha validado. Sólo este paso introduce pairwise binding, que además está asociado a tu identidad bajo la promesa de sgad de no cruzar datos. Esto es incluso peor porque el servicio al que accedes aunque no sepa quién eres (la administración si quiere sí lo sabra y a qué has accedido) sí sabrá que eres la misma persona que ayer, anteayer... etc (esto es importante para sitios en los que visitas sin cuenta).
Respecto al documento, ya le eché un ojo en su día y leí varios análisis serios, aunque ahora yo no me voy a poner a estudiarlo para ti. Recuerdo que tenía 4 grandes problemas estructurales que, dentro de la imposibilidad de una solución garantista con la privacidad, hacía de esta propuesta especialmente mala y chapucera; requería validadores externos e intermediarios de verificación (muchas veces el propio servicio) que hacía que la verficación fuese suplantable y que las personas fueren perfilables. Tanto el emisor de credenciales (el estado), como el proveedor del waller (app) como el provedor del backend de verificación (sgda) saben quién eres, esto crea un binding event en el que tu identidad civil se asocia a un token digital reutilizable, este binding está registrado, se puede auditar y es correlacionable así que ya tienes trazabilidad desde el origen. Para mitigar (que no evitar) esto dicen que las credenciales caduquen a los 30 días, pero esto solo dificulta la correlación, por que si usas la misma app, con el mismo proveedor, en el mismo dispostivo para múltiples servicios, se puede reconstruir que la walled X ha accedido a los servicios A, B, C, D independientemente del tiempo, pseudonymous linkability de manual.
En fin, lo dejo aquí. Tú créete lo que quieras creerte. Por debajo del diseño y la ingeniería está la matemática, la criptografía y la teoría de la información; que excluyen la posible existencia de un sistema garante con la privacidad y el anonimato que te identifique en una partición de una clasificación arbitraria.
#140 Al menos 1 de todos los puntos de comunicación entre servicio, app y sgad te hace perder el anonimato al 100%. Como he dicho no es un diagrama técnico y ni siquiera está completo como idea general. No vemos el payload de cada comunicación ni lo que incluyen y al menos tiene que incluir identificadores cotejables.
Pero es que además de la imposibilidad de que funcione y de que sea local como decías, es que tienes que confíar ciegamente en que hacen lo que te dicen que hacen. Eso es inaceptable.
#138 No, la aplicación del móvil comunica con un servidor de la Secretaría General de Administración Digital (SGAD). Lo tienes en el diagrama que han puesto arriba.
Imagina que estás en el PC y quieres acceder a un servicio, y tu móvil tiene la APP pero no tienes internet, estás en modo avión. Podría funcionar? Si la respuesta es NO (requiere comunicación exterior con una tercera parte) entonces NO es local. Y no podría funcionar porque el PC no podrá saber nunca lo que has hecho o no con una aplicación incomunicada.
#129 Eso para acceder a Instagram y demás y para usuarios que han subido fotos personales. Para nuevos usuarios requieren documentación. Para usuarios que no dan información personal ni fotos requiren documentación. Para otros servicios en los que no te registrar pero son para adultos, requiren documentación.
El gobierno Australiano no dice qué mecanismo usar, sólo que sancionarán si hay menores. En consecuencia, los servicios identifican, con IA o sin ella, como quieran, pero identifican.
Si tu ya estás identificado en Instagram porque pones tu nombre y tus fotos, enhorabuena, otros no ni quieren ser identificados. Y quizá, en otros foros o webs, como ya he dicho, tú tampoco quieras serlo.
#121 Algunos os merecéis los grilletes y las jaulas que os quieren imponer. El estado sabe quién genera qué, y cuando se consumen pasa por ellos asociados al servicio. Fin.
Vete a UK, a Australia a enseñarles cómo se hace. O publica algo chico, a que todos los doctorados se nos estará escapando algo
#118 Falso. Las IAs que se usan en Australia son de lado del servidor, así que es incluso peor porque pasas de perder tu privacidad y anonimato con el gobierno a perderlo contra la empresa privada, además de ceder tus datos públicos y tu imagen. La IA además se ejecuta en los servidores del servicio, así que con esa medida, cuando quieras ver PROM tendrás que mandarles tu selfie para que el prom provider te tenga bien fichado
#106 El estado, a día de hoy, NO tiene los datos de qué servicios consumo o a dónde accedo, ni tampoco puede identificarme por mis navegación (si hago las cosas bien).
De eso se trata todo esto, de que ni el estado ni nadie pueda registrar tu actividad en Internet, tus comentarios, tus opiniones, tus amistades ni los servicios que consumes.
#105 No son certificados, esto no tiene nada que ver con el certificado digital. Los certificados no tienen información sobre ti, y en el caso del que quizá uses con la administración funciona que, siendo único generado para ti solo, la administración sabe quien eres y puedes tener una comunicación segura además de identificada. Pero esto es una comunicación 1 a 1, en la que tú sabes que la otra parte sabe quien eres. No hay secreto aquí.
La propuesto requiere una comunicación como mínimo a tres: tú, el servicio y un validador de acceso (el gobierno), tú ya no puedes comunicarte con los servicios de forma anónima porque un tercero tiene que validar tu acceso y sabrá que tú, accedes a X.
El problema no es sólo la conexión entre backends, es que hay un servicio del gobierno que sabe quién accede a qué.
#102 Como ya he contestado a la contestación, sí las hay. De nuevo, no se puede diseñar un sistema que respete tu privacidad y anonimato con todas las garantías a la vez que te identifica como parte de un grupo X. No voy a hacer una ponencia ahora, pero no hagáis afirmaciones peligrosas sin conocimiento. Basta con que busquéis papers y estudios sobre el tema y veaís las limitaciones de incluso los sistemas propuestos más garantistas.
#82 Ya se ha explicado mil veces, el diagrama no es un diagrama técnico; en él el Servidor SGAD aparece mágicamente como punto final, cuando obviamente tiene que estar conectado backend to backend con un servicio de proveedores de contenido y aplicaciones de verificación que gestiona el gobierno. En fin. Por no hablar de las partes que no aparecen representadas (y forman parte del proceso) o el hecho de que las aplicaciones y servidores implicados son opacos y tienes que confiar ciegamente en ellos (inaceptable).
#61#63 el estado sabe qué token pertenece a quién, y el servicio de terceros tiene que consultar al estado backend to backend el token para saber si puede autorizar el acceso*, por lo que el estado termina sabiendo quién hace qué y dónde.
* La información personal no puede ir embebida porque entonces sería duplicable y falsificable, la consulta del servicio a la administración es obligatoria. De nuevo, no hay forma posible; nadie la ha encontrado nunca y además es una cuestión matemática, si creéis que vosotros sí podéis hacerlo escribid un paper y romped la matemática.
#27 No existe forma técnica de verificar tu edad sin identificarte personalmente. En el momento en que tienes que pasar esa verificación estás poniendo nombre y apellidos a toda tu actividad y pasando tus documentos de identificación a terceros.
Es así de simple, si hubiera una forma mágica de comprobar la edad sin dar datos personales ni firma toda tu actividad y opiniones para que un gobierno o empresa pueda luego rastrearlo y utilizarlo en tu contra... todo el mundo estaría de acuerdo; pero no es el caso ni es posible, como no es posible viajar el tiempo u obtener un generador de energía infinita.
Son limitaciones físicas y matemáticas, no hay más.
#18 Son más caras y en consecuencia te dan más vacaciones, como he dicho tiene que ser equivalente.
En muchos sitios tiene sentido hacerlo a fin de año porque el convenio fija las horas anuales, así que sólo haces extra cuando pasas el total anual, que obviamente ocurre al final del año.
A los efectos de lo dispuesto en el párrafo anterior, no se computarán las horas extraordinarias que hayan sido compensadas mediante descanso dentro de los cuatro meses siguientes a su realización.
Por otro lado tú puedes tener un convenio que establezca que siempre se dé una de las dos opciones. En cualquier caso la vacaciones o la remuneración por horas extra son equivalentes SIEMPRE por ley. Si tienes vacaciones son días que no trabajas y te están pagando; o dicho de otro modo, más que horas extra es hacer "horas del futuro" y cuando llega esa futuro no las haces y las cobras.
#13 webkit y blink son sólo motores de render, hay muchas diferencias fundamentales entre chromium y safari, como chromium usando v8 como motor de javascript y safari usando nitro. Además el fork de blink y webkit ocurrió en 2013, han pasado 13 años y las diferencias entre ambos son muy notables, sobre todo en todas las especificaciones que han salido en estos 13 años, que no son pocas precisamente.
#5 No he dicho que esté controlado por Google (aunque el 99% del código es o lo gestiona Google), pero los fallos de seguridad y rendimiento son los mismos. La capa de de usuario es lo único que cambia.
Lo de experiencia segura... pues tampoco. Los brechas de seguridad importantes son a nivel de motor, como en la noticia, Google además añade su capa para sus servicios. En los anuncios y rastreos (que no seguridad) no hay diferencia con Chrome con un adblocker.
El consumo de CPU y memoria, de nuevo, es a nivel de motor, Brave tiene una configuración por defecto diferente a Chrome pero nada que no puedas cambiar en settings.
En resumen, menos Firefox y Safari, el resto de navegadores son Chromium con una skin.
Es más, apps de escritorio como Spotify, Slack, Atom... son Chromium también (basadas en electronjs)
pero esto no tiene naaaada que ver con certificados ni firmas, NADA. Lo he mencionado antes en
Tu ejemplo expone uno de los problemas que tratan de evitarse o mitigarse (sin éxito), que el emisor se involucre en la fase de presentación, o en otras palabras, que el gobierno (agente de en la fase de emisión) sepa qué servicios consumes (fase de presentación). Muchas soluciones lo mitigan, pero en tu ejemplo es que el servicio llama para decirlo directamente.
Por lo demás, legalmente copiar la certificación no sería suplantación de identidad; primero porque no te identifica ante el servicio (solo muestra que cumples una condición) y segundo porque cogerle el dni a tu hermano mayor para comprar una cerveza no es (legalmente) suplantación de identidad.