Notes ·
A Security Breach Is Bad. Ignoring the Person Who Reports It Is Worse.
Security researcher BobDaHacker says he discovered a remarkably simple authorization failure in tl;dv, an AI meeting-recording service used by more than two million people.
According to his disclosure, any authenticated tl;dv user could query a Firestore collection containing 181,874 meeting records from 84,312 users across 35,003 domains. The exposed metadata included email addresses, meeting IDs, providers and recording status. Active meeting IDs could potentially be used to attempt to join calls.
The researcher also tested 27,334 meeting IDs and found more than 1,000 recordings configured as public, including government, university and corporate meetings. The recordings themselves were not universally exposed, which is an important distinction.
But the technical mistake may not be the most disturbing part.
He says he reported the problem on January 28 and repeatedly followed up through July without hearing from tl;dv's CTO. tl;dv's own security page promises that its security team will respond to vulnerability reports within 24 hours and says production code changes undergo security review and extensive testing.
I have seen this pattern personally.
Years ago, during my first week at a company, I discovered a superadministrator username and password committed to source control. The credential provided extraordinary access to sensitive customer information and had apparently been sitting there for roughly two years.
Reporting it immediately turned into an exercise in blame.
People looked for ways the problem could somehow belong to the person who discovered it. Eventually the commit history made the situation fairly difficult to dispute.
The vulnerability was serious.
The organizational reaction bothered me more.
Security failures happen. Engineers make mistakes. The dangerous part is when protecting someone's reputation becomes more important than understanding the failure and protecting the people whose information is exposed.
That is why the tl;dv disclosure deserves more attention than it appears to be receiving.
As of this writing, I could not find a public incident response from tl;dv addressing the researcher's claims or significant independent reporting investigating them.
For a product whose entire purpose is storing conversations people considered important enough to record, silence is not a reassuring security response.
Security culture is not SOC 2 badges, encryption claims or a vulnerability-reporting email address.
It is what the organization does when someone sends that address a message saying:
You have a serious problem.
Read “tl;dv (Too Lazy; Didn't Validate): 181,874 Meetings Left Wide Open.”