QuotaManager already has a notion of "internal" origins[1] that
explicitly white-lists devtools' synthetic "indexeddb" fake scheme.
It's this check that avoids the prompt when persistent storage is requested.
It might make sense to expand the existing logic that acts like all
system-principaled origins are asking for persistent storage[2] to use
the check as well, or at least for the IndexedDB protocol until we get
to the next steps for changing how QuotaManager handles persistent
data. We could do this in the same commit that removes devtools' use of
the storage property.
Andrew
1:
https://searchfox.org/mozilla-central/rev/bffd3e0225b65943364be721881470590b9377c1/dom/quota/ActorsParent.cpp#5524
2:
https://searchfox.org/mozilla-central/rev/bffd3e0225b65943364be721881470590b9377c1/dom/indexedDB/IDBFactory.cpp#681
On 03/06/2018 01:18 PM, J. Ryan Stinnett wrote:
DevTools is one chrome caller that might be impacted. We craft a custom
principal and pass `storage: persistent`[1] when using IndexedDB in the
tools.
DevTools uses this storage for developer settings that should be retained
over time. It sounds like with the proposed change here, DevTools storage
might lose the persistent status. If that's true, what's the right approach
to maintain the status quo? I don't think it makes sense to show a
permission prompt when DevTools access its storage, since it is a browser
feature.
Should we add an exception for the DevTools iDB principal? Should DevTools
use the system principal and migrate existing data?
[1]:
https://searchfox.org/mozilla-central/rev/bffd3e0225b65943364be721881470590b9377c1/devtools/shared/indexed-db.js#34
- Ryan
On Tue, Mar 6, 2018 at 9:58 AM, Johann Hofmann <jhofm...@mozilla.com> wrote:
I would like to unship the proprietary "storage" attribute in
indexedDB.open()[0]. It allows developers to prevent their indexedDB
storage from being evicted as part of quota management[1]. However,
there is a web standard which specifies a better persistent storage
mechanism and has broader vendor support[2].
There are several issues with the old proprietary version:
- It's only supported by Firefox.
- It can be used over insecure HTTP, which is against the persistent
storage spec.
- Its internal mechanism is only concerned with indexedDB and does not
integrate with other quota managed storage.
- We actually need to maintain two separate permissions that do more or
less the same thing ("indexedDB" and "persistent-storage"). The UI for
managing these looks almost exactly the same and it's impossible to
clarify the difference. It's a pretty annoying security/privacy UX issue
and difficult to justify to users.
The plan is to ignore the "storage" attribute and label all databases
opened from iDB.open as default (i.e. dependent on the persistent
storage mechanism).
Before doing this, we will issue a deprecation warning in the browser
console and write a blog post on Mozilla Hacks. Affected websites could
lose their indexedDB data (equivalent to the user clearing their
cookies), unless they migrate to the new storage model.
We are tracking this work in bug 1354500
(https://bugzilla.mozilla.org/show_bug.cgi?id=1354500).
We have seen very low usage on beta[3], with the exception of a spike in
November which we attribute to about:home usage from a/b testing. After
we stopped counting usage from about: pages on Nightly, the telemetry
probe stopped signaling completely[4].
I personally consider these numbers (prior to any evangelism or console
warnings) low enough to unship within the Firefox 62 timeframe, without
migration.
Chrome callers should not be affected by this, since we upgrade the
system principal to persistent storage automatically.
Please let me know what you think.
Thanks,
Johann
[0] https://developer.mozilla.org/en-US/docs/Web/API/IDBFactory/
open#Syntax
[1]
https://developer.mozilla.org/en-US/docs/Web/API/IndexedDB_
API/Browser_storage_limits_and_eviction_criteria
[2] https://storage.spec.whatwg.org/
[3] https://mzl.la/2GVyQ7g
[4] https://mzl.la/2FqW0FH
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
