1

I have a trusted html file containing a script that handles sensitive information. When I open it in Chrome 108 on Android, it says:

enter image description here

What is this about?

The above warning seems to appear independently of the method that file.html uses for communication. In fact, it appears even if file.html does not communicate at all! Clicking the "Details" link reveals the following:

enter image description here

This message seems to raise suspicion about the integrity of file.html itself. This is a file that I securely installed on my filesystem myself. Is Chrome saying that an attacker may have modified this file? How does Chrome let attackers modify local files in My Documents?

Or perhaps the message is in error? When I click on the "What do these mean?" link, Chrome seems to think I'm using plain http:// and not file://: enter image description here

I am well aware that Chrome has issues with plain http:// (even on secure ports). But file:// is a different matter, as securing users' files is fundamental to system administration (assuming any software can be trusted at all). Local file access should be no less secure than any other method of obtaining a file from someone whom I am entrusting with my sensitive information. (In fact, local file access typically seems to be a necessary step in preparing delivery via other methods).

Of course, in some browsers, I also have to trust a script running under file:// not to read my local files. But then my files would already be stolen by the time I see this warning. Maybe Chrome is warning me not to enter local filenames? But that's not "passwords or credit cards", so Chrome's warning still doesn't seem to make sense.

Is there a logic to Chrome's warning about entering sensitive information into a page running as file://?

1 Answer 1

3

TLDR

This message is a design flaw in Chrome. Chrome does not explicitly address the "file:" scheme. Simply put, if the resource has no valid certificate, it is considered as not secure.

Details

This message makes only sense for resources that you access via network. In case of a local file system there is nobody between your browser and your file system, and the browser loads exactly the contents stored in the file system. We assume that the system is not compromised, because in the compromised system everything can happen and any discussion makes no sense.

There might be objections that file system can mount some remote resources insecurely. But the same is true also when you access any web site via https. Despite your connection to their server is secure, their server can access the resources in an insecure way. We don't consider such cases.

Source code

See the source code. The message "Connection is not secure" is defined in page_info_strings.grdp in the constant IDS_PAGE_INFO_NOT_SECURE_SUMMARY_SHORT. This message is generated in case the page source has no valid certificate. See page_info_ui.cc:

    case PageInfo::SITE_IDENTITY_STATUS_NO_CERT:
    default:
      return CreateSecurityDescription(SecuritySummaryColor::RED,
                                       IDS_PAGE_INFO_NOT_SECURE_SUMMARY_SHORT,
                                       IDS_PAGE_INFO_NOT_SECURE_DETAILS,
                                       SecurityDescriptionType::CONNECTION);

Decision about SITE_IDENTITY_STATUS_NO_CERT is done in page_info.cc

    // HTTP or HTTPS with errors (not warnings).
    if (!security_state::IsSchemeCryptographic(visible_security_state.url) ||
        !visible_security_state.certificate) {
      site_identity_status_ = SITE_IDENTITY_STATUS_NO_CERT;
    } else {

There is no separate handling of "file:" scheme here. Since there is no certificate, it is reported as not secure.

3
  • Thanks for digging up the source code to confirm that this is a flaw in Chrome. Re: "There might be objections that file system can mount some remote resources insecurely. But the same is true also when you access any web site via https." Spot on. I was wondering the same thing, and came to the same conclusion. And now you've confirmed the true technical reason for the warning: Google's code is (incorrectly) using certificate existence as a proxy for file integrity. (The next question is, how could Google not notice such an obnoxious warning?) Dec 25, 2022 at 20:37
  • 1
    1) There can be many reasons. We can only guess. People do mistakes. People can have different opinions. The issue may have been identified, but prioritized low and closed.
    – mentallurg
    Dec 25, 2022 at 22:04
  • 2) The Google's part of the code is closed source. The open part of the code is not Google's code. It is a code of Chromium community. Some committers work at Google. But the most of them don't.
    – mentallurg
    Dec 25, 2022 at 22:04

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .