El argumento principal para una fecha límite fija es probablemente que la historia muestra que muchos proveedores tardarán años en reparar el software si no se establece una fecha límite para la divulgación. Dado que es probable que otros también encuentren el mismo error (o que ya lo hayan encontrado y lo usen), esto significa que los usuarios corren un mayor riesgo sin ser conscientes de ello. Esto también significa que no agregarán defensas adicionales para disuadir el riesgo, como una mayor supervisión, reemplazar el software afectado por uno más seguro, o reducir el riesgo al desconectar temporalmente los sistemas o servicios afectados.
El principal argumento en contra de una fecha límite fija es que algunos errores son más difíciles de solucionar que otros y, por lo tanto, las correcciones llevan más tiempo y tal vez no haya soluciones efectivas para los clientes. Por lo tanto, los clientes tienen un mayor riesgo, mientras que la vulnerabilidad es conocida por el mundo y, por lo tanto, los posibles atacantes, pero no existen soluciones o soluciones alternativas. Pero al menos pueden estar al tanto de este riesgo adicional. El pasado ha demostrado que si este es el caso, a menudo es suficiente si el proveedor colabora estrechamente con los investigadores de seguridad para solucionar el problema lo más rápido posible. Y si las experiencias pasadas con el proveedor fueron positivas, los investigadores a menudo extienden la fecha límite un poco esta vez.
Con respecto al proyecto Google Zero: uno podría quejarse de sus duras fechas límite, pero si observa el trabajo que realizan y la rapidez con que la mayoría de los proveedores reaccionan a los errores, la estrategia de una fecha límite parece ser exitosa: muchos errores se han solucionado dentro de unos días, es decir, mucho más corto que el plazo. Y dudo mucho que este fuera el caso si la presión de la fecha límite no estuviera allí.