Files incident

Google Safe Browsing is falsely reporting the Files.com login page as a "Dangerous Site" if it is navigated to directly

Minor Resolved View vendor source →

Files experienced a minor incident on August 4, 2025 affecting Web Interface, lasting 8h 41m. The incident has been resolved; the full update timeline is below.

Started
Aug 04, 2025, 12:28 PM UTC
Resolved
Aug 04, 2025, 09:09 PM UTC
Duration
8h 41m
Detected by Pingoru
Aug 04, 2025, 12:28 PM UTC

Affected components

Web Interface

Update timeline

  1. investigating Aug 04, 2025, 12:28 PM UTC

    We’ve received reports from customers that users accessing their site through Google Chrome, Mozilla Firefox, Safari, or other browsers that rely on Google’s Safe Browsing are erroneously seeing a "Dangerous Site" warning. This issue specifically affects the Files.com login page when it is accessed directly, at a URL formatted like domain.files.com/login. This usually only occurs when the login page is bookmarked. Users can navigate directly to their domain (for example, by accessing domain.files.com instead of domain.files.com/login) without receiving this warning. We believe that this may have been caused by one of our customers falsely reporting to Google that their Files.com site was unsanctioned. We are attempting to work with Google to have them review the report. There is no security concern with the Files.com application, and you should disregard this error. Please help us by submitting a report to Google that this page is safe: https://safebrowsing.google.com/safebrowsing/report_error/?url=https:%2F%2Ffiles.com%2Flogin&hl=en-US When writing your report, please fill in your custom subdomain in the URL box. We will provide additional details as they become available. Customers with urgent questions are encouraged to contact our Customer Support team by email. Thank you for your patience.

  2. investigating Aug 04, 2025, 02:22 PM UTC

    This issue specifically affects the Files.com login page when it is accessed directly, at a URL formatted like domain.files.com/login. This usually only occurs when the login page is bookmarked. Users can navigate directly to their domain (for example, by accessing domain.files.com instead of domain.files.com/login) without receiving this warning. We will update this page again only when new information becomes available.

  3. investigating Aug 04, 2025, 06:48 PM UTC

    We are continuing to investigate this issue.

  4. resolved Aug 04, 2025, 09:09 PM UTC

    Google has reviewed our appeal of this issue and acknowledged that this was a false positive. There was never any danger to any users connecting to any Files.com site. This issue is now resolved. Starting this morning, we began to receive reports from customers that users accessing Files.com through Google Chrome, Mozilla Firefox, Safari, or other browsers that rely on Google’s Safe Browsing were erroneously seeing a "Dangerous Site" warning. Google has removed Files.com from its list of "Dangerous Sites" and our testing indicates that browsers are no longer displaying this erroneous warning. If you or your users are still seeing a warning when navigating to your Files.com site, you likely need to wait a little longer for your browsers to receive an update from Google.

  5. postmortem Aug 18, 2025, 02:49 PM UTC

    From 10:03 UTC to 19:02 UTC on August 4, 2025, some users attempting to sign in to [Files.com](http://Files.com) via URLs ending in /login \(e.g., [acme.files.com/login](http://acme.files.com/login)\) encountered a red warning stating “Deceptive site ahead.” This warning appeared in Chrome, Safari, Firefox, and other browsers that rely on Google Safe Browsing. Affected access paths included: * Bookmarked links to /login * Direct navigation to /login * The "Sign In" button on our marketing website All other product surfaces—including APIs, desktop and CLI apps, agents, mobile apps, custom domains, and already-loaded web app sessions—remained fully functional and unaffected. **Root Cause** The Chrome, Safari, and Firefox browsers all use a service from Google called Google Safe Browsing to identify potentially dangerous sites and apply a full page warning when a user tries to visit any site that has been flagged by Google Safe Browsing. The [Files.com](http://Files.com) subdomain for a [Files.com](http://Files.com) customer was incorrectly reported to Google Safe Browsing as a phishing site by a third-party security vendor affiliated with that customer. Google accepted the report without independent validation and—unexpectedly— applied a warning to any login page on the entire [files.com](http://files.com) domain, not just that specific customer subdomain. To be clear: * No malware was present. * No compromise occurred. * No policy violation took place on the [Files.com](http://Files.com) platform. We have identified both the customer and the third-party vendor responsible for the report and have taken action to prevent any recurrence. **Response Timeline** At 10:09 UTC, our team convened an incident bridge within six minutes of detection and posted a status page update. Shortly after: * We disabled the affected customer’s subdomain. * We submitted a formal appeal to Google via Search Console, providing logs and proof that the report was a false positive. * We pushed a change to reroute new login sessions from /login to /newsession, restoring access for all customers except those with bookmarks to the previous URL. * We requested “This site is safe” confirmations from affected customers to help expedite Google’s manual review. At 19:02 UTC Google completed its review and removed the incorrect classification. Browser warnings began disappearing shortly thereafter as Safe Browsing lists refreshed \(typically within 30–60 minutes\). **Our Perspective** We understand the critical nature of [Files.com](http://Files.com) in your workflows, and we consider this incident wholly unacceptable—not because of any fault in our systems, but because access to our login page was unfairly blocked, creating real-world disruption for our customers and reputational damage for both you and us. We are deeply frustrated by how this situation was handled by Google: * An erroneous third-party report—submitted via a poorly governed “security” company system—was accepted by Google without any review. * Worse, the impact of that report was applied far beyond its scope, extending the warning to our entire domain, rather than the single customer subdomain in question. * Despite escalating through multiple internal and public channels, it took Google over 9 hours to act, during which time countless users encountered misleading and damaging warnings when trying to access [Files.com](http://Files.com). This incident reveals a deeply troubling reality: Google Safe Browsing wields extraordinary power over the web, but operates with little transparency, no meaningful appeals process, and effectively zero accountability. There’s no SLA, no phone number, and no obligation to fix their own errors promptly—if at all. We believe this system is broken. A single bad report—no matter how inaccurate— can cause cascading damage to legitimate businesses without recourse. That’s not just frustrating. It’s dangerous. We’re currently working to establish a more reliable escalation path within Google Safe Browsing, but the truth is: no business should have to navigate this kind of opaque and unilateral system to protect its integrity. We sincerely apologize for the disruption and appreciate your patience and trust. If you have any further questions or concerns, please reach out to our Support team.