Restrict Storage Access API usage to within secure contexts
Categories
(Core :: Privacy: Anti-Tracking, enhancement, P2)
Tracking
()
Tracking | Status | |
---|---|---|
firefox118 | --- | fixed |
People
(Reporter: chris.p.fredrickson, Assigned: hsohaney)
References
(Blocks 1 open bug)
Details
Attachments
(1 file)
Steps to reproduce:
N/A
Actual results:
N/A
Expected results:
Firefox should expose the document.hasStorageAccess and document.requestStorageAccess APIs in all contexts, but require a secure context as one of the preconditions for a "successful" call (i.e. before yielding true from hasStorageAccess, and before resolving from requestStorageAccess).
This is to get in alignment with https://github.com/privacycg/storage-access/pull/132.
Comment 1•2 years ago
|
||
The Bugbug bot thinks this bug should belong to the 'Core::Privacy: Anti-Tracking' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.
Updated•2 years ago
|
Updated•2 years ago
|
Assignee | ||
Updated•1 years ago
|
Comment 2•1 years ago
|
||
Please don't restrict the javascript engine based on the protocol: No one normal ever desire, even less requested, that.
In the pre-Let'sEncrypt days we would have all screamed against Big(SSL)Corp limiting JS to it's (SSL-validated) contexts.
But LetsEncrypt presence doesn't change the matter: Our Javascript engine must stay consistent and functional across all contexts and under any conditions, including HTTP.
What's next ? Forbidding CSS :visited
on *.cn
or .*ru
tld ??
Comment 3•1 years ago
|
||
Hi Raphaël!
This bug (and project) is tracking compatibility with the Storage Access API specification. Given that the spec requires this behavior, we have to keep this open. You are free to comment on the spec's issue tracker to voice your concern there.
I'm sympathetic to wanting to maintain a consistent Javascript platform, however I think restricting some features to contexts where there is not a possible network attacker is reasonable. Which features meet that bar is reasonable to debate. However, I certainly don't think that this technical constraint leads to the slippery slope of restricting functionality by TLD.
Assignee | ||
Comment 4•1 years ago
|
||
Comment 6•1 year ago
|
||
Backed out for causing bustage on StaticPrefListAll.h
- backout: https://hg.mozilla.org/integration/autoland/rev/3af51b0d6d450cd1eb4a141d3477a3ef111fe2e9
- push: https://treeherder.mozilla.org/jobs?repo=autoland&group_state=expanded&revision=d204d5c43511dcccc5742c7fac407b562658b5d5
- failure log: https://treeherder.mozilla.org/logviewer?job_id=424547750&repo=autoland&lineNumber=2035
[task 2023-08-01T18:07:02.374Z] 18:07:02 INFO - /builds/worker/checkouts/gecko/modules/libpref/init/StaticPrefList.yaml: error:
[task 2023-08-01T18:07:02.374Z] 18:07:02 INFO - missing `mirror` key for pref `dom.storage_access.frame_only`
[task 2023-08-01T18:07:02.374Z] 18:07:02 ERROR - gmake[4]: *** [backend.mk:146: init/.deps/StaticPrefListAll.h.stub] Error 1
[task 2023-08-01T18:07:02.374Z] 18:07:02 INFO - gmake[4]: Leaving directory '/builds/worker/workspace/obj-build/modules/libpref'
[task 2023-08-01T18:07:02.374Z] 18:07:02 INFO - gmake[4]: Target 'export' not remade because of errors.
[task 2023-08-01T18:07:02.374Z] 18:07:02 INFO - gmake[4]: Target 'export' not remade because of errors.
[task 2023-08-01T18:07:02.374Z] 18:07:02 ERROR - gmake[3]: *** [/builds/worker/checkouts/gecko/config/recurse.mk:94: modules/libpref/export] Error 2
Assignee | ||
Comment 7•1 year ago
•
|
||
Thanks for catching that! I'm not sure how that line got deleted but it didn't show up as a diff on my phabricator. I've fixed it now and will double check before submitting to Lando again, sorry about that
Comment 9•1 year ago
|
||
bugherder |
Description
•