El año pasado, concretamente durante el mes de Julio, se anunció el nacimiento de Google Project Zero, una iniciativa de seguridad de Google para auditar en busca de vulnerabilidades en aplicaciones de otros fabricantes, incluyendo en esta lista software libre y software de código cerrado. El año pasado fue especialmente vertiginoso en términos de seguridad informática, todavía convulso por las revelaciones de todos los hackeos provenientes de la NSA, la aparición de fallos como Heartbleed, ShellShock, Poodle o el resto de bugs en software criptográfico, hicieron que las inversiones en seguridad empezaran a crecer.
Google montó su equipo en busca de fallos en el software que ellos utilizan que, dicho sea de paso, pensando en una compañía del tamaño de Google es algo así como decir casi todo el software importante del planeta. En sus filas hay hackers de gran nivel y reconocimiento internacional, con varios Pwnie Awards entre ellos, e incluso GeoHot ha pasado a formar parte de este equipo que se dedica a buscar vulnerabilidades.
 |
| Figura 1: Es Google Project Zero (i)rresponsable publicando 0days y exploits? |
La polémica viene con este grupo ha venido por otro lado, no con la búsqueda de los bugs, sino con la "medida de responsabilidad" que han añadido a la publicación de sus descubrimientos, en 0days de Windows y de OS X recientemente.
Un resumen de la publicación de bugs
Recordemos que hace años atrás, los hackers eran acusados con el dedo por la publicación de sus descubrimientos en Full Disclosure, es decir, se encuentra un fallo de seguridad y se publica. Los fabricantes de software se quejaban de que no estaban ayudando a la seguridad de sus clientes con esta forma de publicar, sino que los estaban poniendo en riego porque cualquier atacante podría con ese conocimiento publicado hacer daño a sus usuarios.
La posición de los investigadores era que los que estaban poniendo en riesgo a sus clientes eran ellos no auditando correctamente el software, además de que no tenían ninguna garantía de que antes de que se hiciera público este fallo no estuviera siendo utilizado por ningún malo de verdad. Ahora que se conoce el fallo, todo el mundo deberá trabajar en pro de solucionarlo. El gran investigador argentino Juliano Rizzo, en la presentación que hizo en Ekoparty del bug BEAST en SSL lo explicó con una de las frases que quedará para la historia:
 |
| Figura 2: Juliano Rizzo sobre la publicación del bug BEAST en SSL |
En aquel entonces el mundo de Internet estaba preocupado por las consecuencias en el e-commerce que pudiera tener la publicación de un bug en la capa de cifrado, y lo que consiguieron los investigadores publicando el bug es que todo el mundo se preocupara por el fallo y lo subsanara.
Los fabricantes de software siempre reclaman el Responsible Disclosure, es decir, que los investigadores les comuniquen a ellos el fallo y les dejen tiempo para arreglarlo antes de hacerlo público. Esto tiene dos preguntas a responder por parte de los fabricantes de software:
1) ¿Por que una investigación que ha llevado tiempo y dinero te la voy a tener que dar a ti y no a otros?
Los hackers comenzaron una campaña llamada "No more free bugs" en la que exigían que se reconociera su esfuerzo de investigación y el valor que tenía para todos el descubrimiento de los bugs. En Internet había empresas de todo tipo de reputaciones dispuestas a pagar a los investigadores por ese conocimiento, así que los grandes software vendors deberían ponerse las pilas.
 |
| Figura 3: Alex Sotirov y Dino Dai Zovi apoyando al campaña No More Free Bugs |
Esto llevó a la aparición de brokers (empresas que compran bugs y luego negocian su venta con los fabricantes de software) y a las famosas Bug Bountys que algunas empresas pagan por los bugs reportados, como hace Google, Facebook y en algunos productos puntuales Microsoft. Por supuesto, para sacar una Bug Bounty, primero las empresas deberían auditar mucho más el software de su compañía con equipos de auditoría mucho más formados lo que llevó a que las grandes empresas se "pelearan" por conseguir tener en sus filas a los mejores hackers del panorama internacional trabajando para ellos.
2) ¿Cuál es exactamente la medida de responsabilidad?
Cuando un investigador encuentra un bug se hace un time-stamp. Ese día el hacker toma constancia de que hay un bug en un producto que pone en riesgo muchas cosas. Tal vez incluso cosas críticas que afectan a nuestra seguridad como ciudadanos si hablamos de un bug en un software que se usa en instalaciones críticas. Ese día, por desgracia, no es el tiempo que tiene ese bug. Ese bug es mucho más viejo y existe desde el día que alguien lo introdujo por error o conscientemente. Ese sería el tiempo de verdad que tiene el bug.
Entre el tiempo que va desde que el bug se introdujo hasta el tiempo en el que el hacker lo descubrió hay por medio a veces mucho tiempo, lo que aumenta las posibilidades de que otro hacker lo haya encontrado antes y lo haya usado para vendérselo a los malos o para explotarlo en su provecho.
 |
| Figura 4: Tiempos, riesgo y responsabilidades |
En el momento en que el hacker lo comunica al fabricante de software empieza a correr otro cronómetro hasta que se arregla, lo que obligará al fabricante a meter personas y trabajo en pro de solucionar este fallo. A veces esto puede costar mucho, por lo que los fabricantes prefieren acumular"varios parches en cada actualización para ahorrar esfuerzos y dinero.
Sin embargo, mientras sucede este parcheo masivo del fallo, el tiempo sigue creciendo. Crece el tiempo desde que se introdujo, crece el tiempo desde que el hacker lo descubrió y crece el tiempo desde que el fabricante es consciente de él. Pero lo más importante, también puede crecer el tiempo en el que otro lo esté utilizando - por ejemplo una agencia de inteligencia internacional o un grupo de cibermalos que lo quiere usar para cibermalas cosas -. Y esto debe tener un límite.
La medida de responsabilidad para Google Zero Project
¿Cuándo debe parchearse algo? La respuesta es cuanto antes, y es el fabricante del software el que lo debe hacer. ¿Cuál es el límite de tiempo que el investigador debe darle al fabricante antes de decir basta? Pues el equipo de Google Project Zero ha determinado que 90 días.
A partir de ese momento, para forzar a la actualización se hace público, aumentando masivamente el riesgo de los clientes, pero al mismo tiempo dándoles la oportunidad de poner workarounds, es decir, medidas de mitigación del bug en WAF, Firewalls, configuraciones de software, políticas de seguridad e el Active Directory o directamente deshabilitando componentes en piezas del sistema como los navegadores. Es decir, transfiere a los clientes la responsabilidad, y al mismo tiempo la oportunidad, de hacer algo para protegerse contra un fallo que puede que esté siendo explotado actualmente.
 |
| Figura 5: Exploit publicado por Google Project Zero para atacar OS X |
¿Es necesario que publique también exploits? ¿Es 90 días el tiempo adecuado para publicar? Cada cuál tendrá sus opiniones. ¿Cuál es la tuya?
Saludos Malignos!
Pregunta de n00b. Yo que soy un usuario digamos "doméstico", ¿cómo puedo informarme sobre el descubrimiento de estos bugs?
ResponderEliminarEl full disclosure no es irresponsable, lo irresponsable es vender al público un software que no está revisado y que tardan demasiado en parchear.
ResponderEliminarEs como si BMW se pusiera a vender coches con cerraduras defectuosas.
el riesgo cero no existe. partiendo de esa premisa, que dudo mucho que alguien se atreva a discutir, todos deberiamos aceptar que siempre saldrá software con fallos y que no forzosamente quiere decir que tengamos que imputar toda la culpa al vendor. todos somos humanos.
ResponderEliminarque deben mejorar su seguridad todas las empresas? indudablemente.
que aun asi, tendremos que afrontar los mismos problemas, aunque surjan en menores cantidades? tambien.
por tanto, el margen de accion para las empresas parece razonable. hay que entender que un bug descubierto por la elite y utilizado por su beneficio propio, siempre será menos riesgo que un bug masivamente conocido y aún no parcheado, pues permite a ciberdelincuentes de niveles mas bajos empezar a producir grandes cantidades de malware, phishing, etc.
Mi opinion es ir Full Disclosure, el Responsible Disclosure no ha hecho más que fomentar la pereza entre los desarrolladores de Software, resultado? Hearbleed, Shellshock. Tambien permite que el afán de que ya se conozca el bug haga que las empresas trabajen más rapido.
ResponderEliminarLo que pasó con este tema del Full Disclosure nos ayudó a entender que ni a Apple ni a M$FT les interesa la seguridad de sus usuarios, sencillamente esconden las cosas para no trabajar en ellas o para que la NSA tenga sus backdoors.
Inclusive, en SSLlabs podeis ver como aún despues de descubierto y parcheado determinado Bug (POODLE, por ejemplo) hay empresas que no se han actualizado y no les interesa, entonces da igual el tema del Full Disclosure, porque al final depende si el usuario quiere o puede colocar el parche
Si descubro un bug en TU programa, te jodes. Así de fácil. Si es habitual encontrar fallos de seguridad en el software que vendes no tardará tenerse en cuenta en la calidad de tus productos.
ResponderEliminar¿Alguna duda más?
creo que ciertas actitudes, generadas en el mas profundo aislamiento y cero empatia, no son nada edificantes.
ResponderEliminarlo primero es separar las consecuencias del tratamiento de la seguridad, que se desglosan en el impacto sobre el usuario y en el imapcto sobre la empresa.
impacto para la empresa: si esta es una empresa con ciertos valores, intentará mantener una relacion esuerzo beneficio riesgo en sus procesos de desarrollo de software y servicios. hacer una aplicacion auditada y revisada hasta el absurdo, con triple check, con miles de sistemas y procesos, y por la cual tenemos que duplicar su precio, no seria inteligente, y muchos de esos conspiranoicos que meten a todas las empresas en el mismmo saco y las tachan de despreoccupadas por la seguridad, son los mismos que luego juzgan los productos o servicios X e Y porque son "muy caros".
para hacer una cura de humildad, llevar una pyme de desarrollo de software durante unos añitos, con la realidad áspera de los números y de la hostilidad/hipocresia del mercado, es una experiencia que creo que todo el mundo deberia vivir o por lo menos pararse a imaginar antes de juzgar a todo el tejido empresarial argumentando los mismos mantras paranoicos de siempre contra las "big four", que para mas inri no tienen por qué se representativas.
impacto para el usuario: el full disclosure potencia la delincencia en masa en algunos casos, minimizando la seguridad en lugar de fomentarla. ¿tenemos todos claro el objetivo? o queremos correr a ponernos medallas y decir "aqui estoy yo y soy el mejor porque he descubierto esto?"
el tiempo límite debe existir para las empresas, y es necesario "obligarlas" con una politica de disclosure estricta, pero esta debe ser acorde al tamaño de la empresa, a su cultura, y a sus recursos, cosa que por norma general no le importa a nadie del sector; resolver un bug urgente en un software de una pyme puede partirla en dos y eso no quiere decir que sean unos incompetentes ni que deban irse todos a la calle, solo quiere decir que son humanos y que su margen de operativa es estrecho.
trabajo para la seguridad de la banca y he comprobado que ni siquera aqui, con todos los recursos que tenemos, somos perfectos. y si hubiera un problema todos nos pediriais por favor que el descubridor se callara la boca en publico porque en los tres o cuatro dias que se tardara en resolver en el peor de los casos, una cuenta bancaria que podria ser la tuya acabaria a cero, y por supuesto el banco no asumiria todo ese desperfecto causado por la gestión irresponsable de un tercero (sí en parte, pero no todo, porque no puedes castigar a la gente por ser humana)
luego, hay cierta hipocresia en los discursos habituales. a veces decimos que los bugs de heartbleed y shellshock fueron posibles porque el codigo abierto es una mierd*, porque no hay empresas privadas detrás que inviertan recursos "de los buenos" en hacer las cosas, y bla bla bla.
luego se puede leer el ataque contra las grandes compañias de software diciendo que no les preocupa la seguridad.
y luego te acabas encontrando con gente que dice que bugs como el de openssl es la prueba fehaciente de la "pereza" de los desarrolladores.
el codigo abierto muchas veces se entrega "as is" asi que a los desasrrolladores, que son humanos y que trabajan de forma altruista, sinceramente, si la gente los empieza a criticar porque han cometido errores en el codigo, te van a responer un muy merecido:
"háztelo tú mejor".
El Responsive Disclosure sólo es una forma de "cuidado al negocio del software".
ResponderEliminarSi el software propietario tarda más que el abierto en actualizarse, dejándolo en el banquillo, no es ninguna irresponsabilidad, sino humanidad.
La propiedad intelectual no existe, porque la humanidad es un intelecto colectivo.
Leyendo algunos comentarios pienso que los escriben adolescentes, o por lo menos, con poca experiencia laboral y desde luego un alto ego. Suerte que no todos son así.
ResponderEliminarLos programadores cometen errores porque son personas, y las personas fallan mucho. Partiendo de que un programa de suficiente complejidad contendrá numerosos errores (esto se explica el primer día de un curso básico de programación) debemos pensar cómo trataremos los errores.
90 días parece razonable para que a las empresas les de tiempo a solucionar los problemas, aunque debemos saber que no todos los problemas son iguales y podrían no ser suficiente 90 días. Con una comunicación fluída entre el descubridor del error y el responsable de solucionarlo se podría aumentar esa ventana de tiempo: no es lo mismo un simple error de inyección SQL que un problema en el Kernel de un SO que afecte a numerosos subsitemas críticos.
Lo del full disclousure, o como dice uno aquí uno "si encuentro un error te jodes" no me parece más que uno excusa para desprestigiar a una empresa, o para "fastidiar" a alguien, ya que todo programa va a contener un número grande de errores, no importa de qué empresa sea. No me parece moral no ético, aunque está en su derecho.
Lo que me parece censurable es poner la excusa de la seguriidad de los usuarios para para poder publicar un error sin haber avisado a los desarrolladores. El full disclousures deja a los usuarios indefensos a cualquiera y desde a un número mayor de potenciales explotadores del fallo que si no se hubiera publicado.
El problema de los errores, en general no es un problema de que una empresa sea mejor que otra haciendo tal o cual programa, hablando en términos generales.
Cuando hay un concurso para detectar errores en algún programa, como los que se convocan para los navegadores SIEMPRE se encuentra muchos en TODOS los navegadores de todas las plataformas. ¿Qué hacemos ahí? ¿Tiramamos a la basura todos los navegadores? ¿Tiramos todos el software? Todo programa tiene errores.
Yo creo que las empresas deberían invertir más en su seguridad, al hacer público un bug, es posible que se se haga presión social hacia la empresa porque ahora sus clientes "saben" que su información o el producto que compraron puede estar comprometido y luego entonces la empresa puede perder clientes o perder(o invertir) dinero porque se ve obligada de alguna manera a parchar su software.
ResponderEliminarDe alguna forma se ven obligada porque el gigante de la Internet pareciera que tiene un juicio inapelable acerca de lo que dice o hace (aunque, un bug es un bug).
Estoy de acuerdo con que se hagan público los bugs, porque esto obliga a la empresa que tuvo el fallo a darle más importancia a la seguridad de sus productos y también porque eso hace al consumidor del productor a estar atento y exigir un producto "más o menos" de calidad con respecto a la seguridad de su información.
Aunque, al hacerlo público, también comprometa la seguridad del software.
geohot hace tiempo que dejo google
ResponderEliminarComo bien dice el artículo que se comunique un bug no quiere decir que nadie lo haya descubierto y lo esté usando ya para sus propios fines. Si Google dice que lo comunica y a los 90 días lo hace público tiene que hacerlo porque sino cae su credibilidad. Si dijera "hoy te lo digo y mañana lo publico" pues hombre, ahí no hay tiempo de hacer un parche en condiciones ni nada, pero si 90 días para una empresa gigante como es Microsoft no son suficientes pues queda demostrado que son unos vagos o unos incompetentes o unos tacaños (puede que varias opciones de esas a la vez).
ResponderEliminarPara terminar creo que 90 días es un tiempo excesivo. Creo que se debería dar mucho menos tiempo o incluso que se comunicara abiertamente (casi me inclino más a esta última posibilidad). Además cabe destacar que cuando se comunica el bug bajo divulgación responsable somos humanos que se comunican con otros humanos y puede que haya empleados poco éticos que decidan aprovecharlo con lo cual el riesgo es muy muy grande.
Saludos!
Puesto que las empresas de software privativo VENDE software y vive de ello ¿por qué iban los hackers a descubrir el bug e informar a los desarrolladores?
ResponderEliminarCasi nunca dan ni las gracias, convirtiendo el Responsive Disclosure en el Pardillo Disclosure.
Si esto se convierte en una encuesta mi respuesta es: Que se jodan.
Yo estoy en contra de revelarlo. Si se detecta un fallo debe notificarse exclusivamente al desarrollador, puesto que hacerlo publico pone en riesgo a todos los usuarios de ese software, y desde luego no me parece etico.
ResponderEliminar¿Que ocurre si el desarrollador no se da por aludido? Pues se notifica a las empresas de seguridad (fabricantes de antivirus, de firewalls...) para que hagan presión o se encarguen de proteger a los usuarios (aunque el desarrollador no lo haga). La etica obliga a proteger al usuario, no a atacar a la empresa.
Aunque no se puede confiar en la seguridad por ocultación, el revelar los fallos no hace un software mas seguro.
Lo que hace google creo que es lo correcto, 90 días son suficientes y no pones en peligro los usuarios.
ResponderEliminarPero yo no soy google ni tengo tanto dinero, y teniendo en cuenta quién es el comete el error (no es lo mismo Google o Microsoft que una pequeña empresa) no comunicaría el error al desarrolador en el caso de una gran empresa. Intentaría sacarle algún partido, dinero mejor.
NO MORE FREE BUGS.
@acerswap entonces tu manera de tener seguro al usuario es no diciéndole que está usando sistemas inseguros? Pues yo como usuario prefiero que se me comunique, que afortunadamente en el mundo de la informática hay varias opciones para casi todo. Si me dicen que un navegador tiene un bug que lo hace inseguro pues me puedo instalar otro mientras actualizan o si no les da la gana de sacar otro. Lo mismo con un Sistema Operativo como es el caso. Si nadie me dice los bugs yo sigo tan tranquilo pensando que todo está bien hasta que algún día me lleve el susto.
ResponderEliminarPara mi gusto lo mejor sería que se comunicara a los desarrolladores y se les diera un pequeño plazo variable según el nivel de riesgo y la complejidad para solucionarlo, a la vez avisar públicamente que ese software tiene un fallo pero sin especificar y finalmente, una vez cumplido el plazo, notificarlo.
Pd.: si un software fuera perfectamente seguro no interesaría a las empresas de antivirus o firewall porque no venderían, por lo que no esperes presión por su parte.
@Langos1989
ResponderEliminarUn usuario siempre debe ser consciente de que existen fallos. Si como usuario no consideras esa afirmación te la van a colar de la misma manera que si no cuentas el cambio al comprar. Eso si, ¿te beneficia que TODOS sepan el fallo que existe y como atacarlo?
A mi me da mas confianza pensar que el desarrollador esta informado de lo que se encuentra y que los atacantes puede que sean conscientes del fallo o que no lo sean que el pensar que todo dios conoce la existencia del fallo y como explotarlo.
En el momento en el que se descubre un bug debe revelarse para que los usuarios puedan reaccionar a la amenaza.
ResponderEliminarQue el desarrollador tarde demasiado en solucionarlo es problema suyo, mientras la gente migra a software más seguro.
Es una evolución de lo más natural. ¿A qué viene tanto escándalo?
hay mucha inmadurez profesional en el sector de la seguridad. parece nos que miramos mucho el ombligo y que todo está justificado para hacer nuestro "trabajo".
ResponderEliminarla seguridad y la estabilidad de los productos y servicios pasa por sopesar todas las opciones y tratarlas adecuadamente de forma profesional y tratando de defender el ecosistema, no tratando de atacar al desarrollador y ningunearlo como si estuvieramos por encima de él, porque si no has desarrollado ni servicios ni productos ni negocios, es my facil criticar desde fuera.
veréis, os guste o no, no podemos forzar a ninguna a empresa a que nos pague por un servicio que no te ha pedido. si quereis ganaros la vida profesionalmente buscando problemas de seguridad, buscaros una empresa que os pague por buscar esos problemas en sus programas y sistemas. yo lo hago para una entidad bancaria y eso es lo que justifica mi sueldo, y tanto contento, oye!
eso lo hago por obligacion profesional pero me permite hacer lo que quiero hacer para ganarme bien la vida.
pero si ademas soy usuario de otros programas que me gustan, mi manera de darles soporte, (sean software libre o privativo, me da igual siempre que no me traten a patadas por reportar), es aportando los bugs que descubro, sabiendo que con eso estoy contribuyendo a una buena causa porque por muy bien pagados que puedan llegar a estar algunos equipos de desarrollo, los productos tienen errores (gran ejemplo, los navegadores).
eso es lo que en mi opinion diferencia a una persona realmente concienciada y profesionalizada dentro de la causa de la seguridad, de una persona que quiere ir corriendo a ponerse la medalla y a destruir un ecosistema que tiene un equilibrio complejo en un marco y un ecosistema que en realidad pocos comprenden en su totalidad.
y si os poneis peseteros, dad gracias de que existen los bug bountys para muchos de esos casos, en los que os pagan dinero y por tanto estan abiertos oficialmente a recompensaros por ello.
tan dificil es de entender?
si estuviésemos hablando de las cerraduras de vuestras casas y cada tres meses algun "profesional" os la abriera gratuitamente mientras estais de vacaciones para "ilustraros y haceros el favor" de descubriros un problema en ellas, seguramente estariais poniendo el grito en el cielo.
menos hipocresia y mas pensar como grupo, como especia, y como profesionales dentro de un ecosistema que no es el ombligo del mundo.
No es tan simple. ¿Cuanto te crees que se tarda (y cuanto cuesta) en desplegar un nuevo software? Y si es un sistema operativo, es un infierno aun mayor. Y solo hablo del despliegue, piensa en el coste de las licencias. Ahora le sumas las incompatibilidades con el hardware, con el software existente y rezas para que no se te salga de la capacidad de la calculadora.
ResponderEliminarah! y otra cosa...
ResponderEliminardejad de habar como si TODOs los usuarios fueran avanzados y pudieran hacerse un self service de administracion de sistemas y de su seguridad, cambiando de software, reconfigurandolo, etc etc.
no hay mayor error para partir de un discurso, que ese.
la gente tiene una vida y hace otras cosas con el software y los sistemas, y le pese a quien le pese nuestras estrategias (si somos profesionales de verdad) deben ir orientadas a protegerlos a todos aun cuando sean usuarios no experimentados.
Tres opiniones sobre este debate:
ResponderEliminar1) La no revelación de vulnerabilidades no es una opción, especialmente cuando gracias a Snowden sabemos que hay agencias de espionaje que utilizan estas vulnerabilidades para realizar espionaje masivo. El silencio equivale a complicidad.
2) El período de tiempo que elige Google para sus revelaciones, 90 días, me parece una cantidad deliberadamente grande como para que nadie se queje. Recuerdo haber visto este mismo mes una noticia en que la administración estadounidense definía un período de 30 días para revelar vulnerabilidades.
3) Y dicho todo esto... no me cabe duda de que el Project Zero es una tocada de pelotas por parte de Google y sólo se entiende como parte de la guerra entre empresas que mantiene.
Yo entiendo que las empresas exigen que no se hagan públicas las cagadas que vendieron al público. ¿Es así? Si es así que se pongan las pilas.
ResponderEliminarEspero que este post no hubiera tenido nada que ver con que Microsoft se enfada con google porque le han sonrojado la cara:
ResponderEliminarhttp://barrapunto.com/articles/15/01/26/1343201.shtml
Entre mas publico sean los 0day mejor, asi ques emrpesas empiezan a preocuparse en serio por la seguridad, y los malos podemos aprovecharnos de paso.
ResponderEliminar¿Que beneficio trae que Google publique después de 90 días, una POC de la vulnerabilidad?
ResponderEliminarA los delincuentes que crean malware y exploits kits seguro que les ahorra trabajo y los pone al tanto de vulnerabilidades para explotar, ellos contentos.
Pero ¿A quien más beneficia GPZ?
A mi modo de ver es una irresponsabilidad y facilita un daño más grande, el que genera Google Project Zero.
El tema de notificar y divulgar vulnerabilidades no es sencillo, pero este definitivamente es, para mi, el camino equivocado.
@Raúl, como dice el artículo, auditan software de uso propio, así que el beneficio es que el fabricante parchee el software que están utilizando, y deje de tener errores. El problema con el software privado es que aunque hayas encontrado un fallo, no puedes arreglarlo, y tienes que esperar a que lo arregle el fabricante.
ResponderEliminarPor otro lado, me parece bastante correcto esperar 90 días (creo que entre 60 y 90 puede ser un intervalo adecuado. Si el fabricante no va a solucionarlo, los usuarios deberían conocer a lo que se exponen, porque es muy probable que "los chicos malos" ya conozcan el bug o lo vayan a descubrir en un futuro cercano.
google no esta utilizando estas medidas para mejorar la internet lo hace para ponerle obstaculos a sus competidores.
ResponderEliminares bien conocido qu elos hackers utilizan la informacion que google provee atravez de su buscador para obtener las claves e incluso los mismos servidores para de ser necesario descifrarla.
pero google conciente de que no posee un SO de escritorio fuerte y no tiene un movil lider en ventas hostiga a sus competidores competidores apesar que hay tantas fallas de seguridad en android -y quizas mas- como en IOS, windows o linux siendo que estos ultimos son mas complejos.
si de pronto un policia detiene a delincuentes eso esta bien pero no esta bien cuando el policia hace asu vez juez.
no hay problema en encontrar fallos o errores el problema es cuando se usan de forma oscura y para esa oscuridad contratas ladrones de informacion.
El último anónimo tiene una serie de creencias muy divertidas y mas que cuestionables sobre las consecuencias reales de someter software a procesos de busqueda de bugs. yo opino todo lo ccontrario, google fortalece la calidad de esos productos.
ResponderEliminarMenos mal que no todo el mundo piensa siempre en negativo
creo que la verdadera culpa la tiene el fabricante por sacar un producto con fallos pero siendo sinceros ningún software ha sido perfecto hasta el momento y dudo que lo sean en breves. Pero 90 días me parecen algo excesivos porque solo con que tardes un par de días en saber la noticia puede que cualquiera que ya estuviera informado haya entrado en tu software.
ResponderEliminar