Powstały niezliczone ziny, listy mailingowe i grupy w Usenecie omawiające luki w zabezpieczeniach, w tym niesławna lista mailingowa Bugtraq, utworzona w 1993 roku. Wiele z tych ujawnień miało na celu budowanie reputacji hakera. Inne wynikały z frustracji wynikającej z chęci naprawienia sytuacji bez dobrego, formalnego kanału komunikacji. Niektórzy właściciele systemów i dostawcy oprogramowania po prostu nie rozumieli bezpieczeństwa; niektórzy nie mieli prawnego powodu się tym przejmować. Jednak z biegiem lat w społeczności hakerów narastała frustracja, ponieważ dostawcy nie byli postrzegani jako osoby postępujące uczciwie i nietraktujące badaczy poważnie. W 2001 roku konsultant ds. bezpieczeństwa Rain Forest Puppy zajął stanowisko i oświadczył, że da dostawcy tylko tydzień na odpowiedź, zanim w pełni i publicznie opublikuje lukę w zabezpieczeniach. W 2002 roku narodziła się niesławna lista mailingowa Full Disclosure, która przez ponad dekadę służyła jako narzędzie, na którym badacze swobodnie zamieszczali szczegóły dotyczące luk w zabezpieczeniach, z powiadomieniem dostawcy lub bez. Niektórzy znani twórcy tej dziedziny, tacy jak Bruce Schneier, pobłogosławili tę taktykę jako jedyny sposób na osiągnięcie rezultatów, twierdząc, że dostawca oprogramowania najprawdopodobniej naprawi problem, gdy się tego wstydzi. Inni założyciele, jak Marcus Ranum, nie zgodzili się z tym, stwierdzając, że nie jesteśmy lepsi i mniej bezpieczni. Ponownie, nie ma zgody w tej kwestii lub jest ona niewielka; pozwolimy Tobie, czytelniku, sam określić, po której stronie stoisz. Podejście oparte na pełnym ujawnieniu oznacza również, że dostawcy w pośpiechu dotrzymując arbitralnie ustalonych terminów mogą nie naprawić właściwie rzeczywistego problemu. Oczywiście tego typu wybryki są szybko odkrywane przez innych badaczy i proces się powtarza. Inne trudności pojawiają się, gdy dostawca oprogramowania ma do czynienia z luką w zabezpieczeniach biblioteki, której nie opracował. Na przykład, gdy OpenSSL miał problemy z Heartbleed, tysiące witryn internetowych, aplikacji i dystrybucji systemów operacyjnych stało się podatnych na ataki. Każdy z tych twórców oprogramowania musiał szybko przyswoić te informacje i włączyć do swojej aplikacji poprawioną wersję biblioteki. Wymaga to czasu, a niektórzy dostawcy działają szybciej niż inni, w międzyczasie pozostawiając wielu użytkowników mniej bezpiecznych, ponieważ osoby atakujące zaczęły wykorzystywać lukę w ciągu kilku dni od jej udostępnienia. Kolejną zaletą pełnego publicznego ujawnienia jest ostrzeżenie opinii publicznej, aby ludzie mogli podjąć kroki zaradcze przed wydaniem poprawki. Pogląd ten opiera się na założeniu, że czarne kapelusze prawdopodobnie już wiedzą o problemie, więc uzbrojenie społeczeństwa jest dobrą rzeczą i w pewnym stopniu wyrównuje szanse pomiędzy atakującymi i obrońcami. W tym wszystkim pozostaje kwestia szkody publicznej. Czy społeczeństwo jest bezpieczniejsze z pełnym ujawnieniem informacji czy bez? Aby w pełni zrozumieć to pytanie, należy zdać sobie sprawę, że osoby atakujące prowadzą własne badania i mogą wiedzieć o problemie oraz wykorzystywać go do atakowania użytkowników jeszcze przed ujawnieniem luki. Ponownie pozostawimy odpowiedź na to pytanie Tobie.