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).
Re:Chrome 68 will mark all HTTP sites as “not secure”
by aurelian15 on Friday February 09, 2018 @05:28PM
(#16344416)
> If you don't mind being more specific, what kind of data would you be storing on the phone?
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.