3 ms·

> 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

> 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?
    - demo123 9y ago
      What about trusting ip from private address ranges?
andrewla 9y ago
Thinking on this further, the storage one makes sense for secure contexts, because allowing that for insecure contexts would mean that by spoofing the DNS of a site, I could steal its information. I'm not certain how secure the data that you store would be, but if it were, say, camera footage or something, it would be possible for it to be extracted from the user's phone by a malicious website out of your control. I don't know if this problem is soluble -- at least a self-signed certificate would mean that the certificate would have to be exfiltrated in order to do this, assuming the browsers key the indexedDB to the certificate fingerprint, which would indicate a degree of compromise that most likely means that the data could be stolen directly from the device. If you don't mind being more specific, what kind of data would you be storing on the phone? Is it just for caching purposes? It seems like it might be better for the data to be fetched from the device on demand rather than stored on the phone, even if this causes a performance hit, to avoid the possibility of leaking the data to untrusted parties.
- aurelian15 9y ago
  > If you don't mind being more specific, what kind of data would you be storing on the phone? Sure, my particular use-case is a media management/playback application (think web-based audio player; like Plex, Ampache, Spotify) that is intended to be used with a large personal library of audio files (in the order of a hundred thousand files, about 1 TB of data). The application has an offline-mode (via ServiceWorkers, everything being REST, content addressed and infinitely cacheable), where the connected client can request to "pin" a certain playlist/filter. Upon request, all media files with that filter will be transcoded/downloaded onto the client and are available even when having no connection. So it's not really any data that needs to be kept secure (still, all media blobs are encrypted anyhow to allow public caching -- for internet hosted instances -- without having to fear IP issues).

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?
  - demo123 9y ago
    What about trusting ip from private address ranges?

andrewla 9y ago

Thinking on this further, the storage one makes sense for secure contexts, because allowing that for insecure contexts would mean that by spoofing the DNS of a site, I could steal its information. I'm not certain how secure the data that you store would be, but if it were, say, camera footage or something, it would be possible for it to be extracted from the user's phone by a malicious website out of your control. I don't know if this problem is soluble -- at least a self-signed certificate would mean that the certificate would have to be exfiltrated in order to do this, assuming the browsers key the indexedDB to the certificate fingerprint, which would indicate a degree of compromise that most likely means that the data could be stolen directly from the device. If you don't mind being more specific, what kind of data would you be storing on the phone? Is it just for caching purposes? It seems like it might be better for the data to be fetched from the device on demand rather than stored on the phone, even if this causes a performance hit, to avoid the possibility of leaking the data to untrusted parties.

aurelian15 9y ago
> If you don't mind being more specific, what kind of data would you be storing on the phone? Sure, my particular use-case is a media management/playback application (think web-based audio player; like Plex, Ampache, Spotify) that is intended to be used with a large personal library of audio files (in the order of a hundred thousand files, about 1 TB of data). The application has an offline-mode (via ServiceWorkers, everything being REST, content addressed and infinitely cacheable), where the connected client can request to "pin" a certain playlist/filter. Upon request, all media files with that filter will be transcoded/downloaded onto the client and are available even when having no connection. So it's not really any data that needs to be kept secure (still, all media blobs are encrypted anyhow to allow public caching -- for internet hosted instances -- without having to fear IP issues).