L'argomento principale per una scadenza prefissata è probabilmente che la cronologia indica che molti produttori impiegheranno anni a sistemare il software se non viene fissata una scadenza rigida per la divulgazione. Poiché è probabile che anche altri trovino lo stesso bug (o che lo abbiano già trovato e utilizzato), ciò significa che gli utenti sono a maggior rischio senza esserne consapevoli. Ciò significa anche che non aggiungeranno ulteriori difese per dissuadere il rischio, come un maggiore monitoraggio, sostituire il software interessato con uno più sicuro o ridurre il rischio portando offline i sistemi oi servizi interessati.
L'argomento principale contro una scadenza fissa è che alcuni bug sono più difficili da correggere rispetto ad altri e quindi le correzioni richiedono più tempo e che forse non ci sono soluzioni alternative efficaci per i clienti. In questo modo i clienti hanno un rischio maggiore mentre la vulnerabilità è nota al mondo e quindi potenziali aggressori, ma non esistono soluzioni o soluzioni alternative. Ma almeno possono essere consapevoli di questo rischio aggiuntivo. Il passato ha dimostrato che, se questo è il caso, è spesso sufficiente che il venditore lavori a stretto contatto con i ricercatori di sicurezza per risolvere il problema il più velocemente possibile. E se le esperienze passate con il venditore sono positive, i ricercatori spesso prolungano la scadenza un po 'questa volta.
Per quanto riguarda il Progetto Google Zero: si potrebbe lamentarsi delle loro scadenze rigide ma se si guarda al lavoro che fanno e alla velocità con cui la maggior parte dei fornitori reagisce ai bug, la strategia di una scadenza difficile sembra avere successo: molti bug sono corretti entro pochi giorni, cioè molto più breve della scadenza. E dubito strongmente che questo sarebbe il caso se la pressione della scadenza non fosse lì.