4 ms·

I don't think there's a way to do what you want in a secure manner. I think fundamentally your issue here is with secure contexts, not with the site labeling.

I don't think there's a way to do what you want in a secure manner. I think fundamentally your issue here is with secure contexts, not with the site labeling. In the end, you can have a site like you describe, but you have to avoid using APIs that require secure contexts. Any sort of avoidance of this, as by the method you describe ("please ignore the ugly warning you are about to see") is a mistake, because you're helping to train the users to ignore these messages. > Still, the app will forever be marked as insecure. Although it isn't. It is trivial for the user to verify that the connection is secure by comparing the certificate fingerprint with that displayed by the server program she just started. Is it, though? Assuming your server hasn't been compromised (nobody is monitoring it to make sure!), and assuming that the self-signed cert cannot be easily exfiltrated, and assuming that they don't do the same thing the next time they get an ugly warning from chase-bank.ru because they're sure that it's spurious -- then maybe?

aurelian15 9y ago
> In the end, you can have a site like you describe, but you have to avoid using APIs that require secure contexts. While that might be an option now, it's not going to be viable. Browser vendors have agreed to make all new JS APIs -- mostly independent of their security implications -- available to secure contexts only [1]. Even now, you cannot use the Crypto API -- which is entirely implementable in plain JS, albeit slower and with higher energy consumption -- without secure contexts. Or you cannot raise the IndexedDB storage limit for your application above a certain threshold without a secure context (which is exactly my problem, I want users to be able to temporarily store a few hundred MB on their mobile device). > Any sort of avoidance of this, as by the method you describe ("please ignore the ugly warning you are about to see") is a mistake, because you're helping to train the users to ignore these messages. I completely agree. I understand the implications of me doing this and I honestly don't want to. I guess what I'm complaining about mostly boils down to an UX issue. It would be near-trivial for browser vendors to add the following to the error page if they detect a self-signed cert on a local connection: "This site seems to be served from the local network. If you are trying to access your own network infrastructure, please make sure the following fingerprint matches the one displayed by the application you are trying to access <fingerprint>, <autogenerated fingerprint art>. If you are unsure, please click 'Cancel'.". That would solve the problem, no landing page from my application required. > Is it, though? You're right, there are a lot of assumptions I'm making here. However, I see no reason why my local HTTPS site should be displayed as less secure (red cross, red text in the URL bar) than a local HTTP site. [1] https://blog.mozilla.org/security/2018/01/15/secure-contexts-everywhere/ https://blog.mozilla.org/security/2018/01/15/secure-contexts...
- andrewla 9y ago
  Wow -- you're right, the overreach in "secure contexts" is astonishing. It looks like [1] is the main thread discussing this policy. The notion of "internal/isolated network services" is mentioned in one comment but never address, other than pointing out the difficulty of getting a cert for such a service. I think it's probably worth jumping into that discussion before the policy is set in stone. [1] https://github.com/w3ctag/design-principles/pull/75 https://github.com/w3ctag/design-principles/pull/75
- collinmanderson 9y ago
  > I see no reason why my local HTTPS site should be displayed as less secure (red cross, red text in the URL bar) than a local HTTP site. Exactly, that's why browsers are trying to move in the direction of making HTTP sites appear as less secure. > I guess what I'm complaining about mostly boils down to an UX issue. It would be near-trivial for browser vendors to add the following to the error page if they detect a self-signed cert on a local connection: "This site seems to be served from the local network. If you are trying to access your own network infrastructure, please make sure the following fingerprint matches the one displayed by the application you are trying to access <fingerprint>, <autogenerated fingerprint art>. If you are unsure, please click 'Cancel'.". I totally agree it's a UX issue, but I don't see a good solution. Unfortunately your browser doesn't know if you're on "your own network infrastructure" and not at a coffee shop. It needs to be on the safe side and assume it's not a trusted network. Maybe the browser should require you to type in the fingerprint of the key.
  - dcow 9y ago
    In IPv6 it does know. This is because IPv6 addresses have scoped prefixes. So much of this discussion is hinged on old IPv4 assumptions.
    - collinmanderson 9y ago
      So how does your browser know that a certain range of ip addresses should be trusted?

aurelian15 9y ago

> In the end, you can have a site like you describe, but you have to avoid using APIs that require secure contexts. While that might be an option now, it's not going to be viable. Browser vendors have agreed to make all new JS APIs -- mostly independent of their security implications -- available to secure contexts only [1]. Even now, you cannot use the Crypto API -- which is entirely implementable in plain JS, albeit slower and with higher energy consumption -- without secure contexts. Or you cannot raise the IndexedDB storage limit for your application above a certain threshold without a secure context (which is exactly my problem, I want users to be able to temporarily store a few hundred MB on their mobile device). > Any sort of avoidance of this, as by the method you describe ("please ignore the ugly warning you are about to see") is a mistake, because you're helping to train the users to ignore these messages. I completely agree. I understand the implications of me doing this and I honestly don't want to. I guess what I'm complaining about mostly boils down to an UX issue. It would be near-trivial for browser vendors to add the following to the error page if they detect a self-signed cert on a local connection: "This site seems to be served from the local network. If you are trying to access your own network infrastructure, please make sure the following fingerprint matches the one displayed by the application you are trying to access <fingerprint>, <autogenerated fingerprint art>. If you are unsure, please click 'Cancel'.". That would solve the problem, no landing page from my application required. > Is it, though? You're right, there are a lot of assumptions I'm making here. However, I see no reason why my local HTTPS site should be displayed as less secure (red cross, red text in the URL bar) than a local HTTP site. [1] https://blog.mozilla.org/security/2018/01/15/secure-contexts-everywhere/ https://blog.mozilla.org/security/2018/01/15/secure-contexts...

andrewla 9y ago
Wow -- you're right, the overreach in "secure contexts" is astonishing. It looks like [1] is the main thread discussing this policy. The notion of "internal/isolated network services" is mentioned in one comment but never address, other than pointing out the difficulty of getting a cert for such a service. I think it's probably worth jumping into that discussion before the policy is set in stone. [1] https://github.com/w3ctag/design-principles/pull/75 https://github.com/w3ctag/design-principles/pull/75
collinmanderson 9y ago
> I see no reason why my local HTTPS site should be displayed as less secure (red cross, red text in the URL bar) than a local HTTP site. Exactly, that's why browsers are trying to move in the direction of making HTTP sites appear as less secure. > I guess what I'm complaining about mostly boils down to an UX issue. It would be near-trivial for browser vendors to add the following to the error page if they detect a self-signed cert on a local connection: "This site seems to be served from the local network. If you are trying to access your own network infrastructure, please make sure the following fingerprint matches the one displayed by the application you are trying to access <fingerprint>, <autogenerated fingerprint art>. If you are unsure, please click 'Cancel'.". I totally agree it's a UX issue, but I don't see a good solution. Unfortunately your browser doesn't know if you're on "your own network infrastructure" and not at a coffee shop. It needs to be on the safe side and assume it's not a trusted network. Maybe the browser should require you to type in the fingerprint of the key.
- dcow 9y ago
  In IPv6 it does know. This is because IPv6 addresses have scoped prefixes. So much of this discussion is hinged on old IPv4 assumptions.
  - collinmanderson 9y ago
    So how does your browser know that a certain range of ip addresses should be trusted?