| Summary: | Make SelectorQueryCache global | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | Antti Koivisto <koivisto> |
| Component: | DOM | Assignee: | Antti Koivisto <koivisto> |
| Status: | RESOLVED FIXED | ||
| Severity: | Normal | CC: | esprehn, webkit-bug-importer |
| Priority: | P2 | Keywords: | InRadar |
| Version: | WebKit Nightly Build | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| See Also: | https://bugs.webkit.org/show_bug.cgi?id=260556 | ||
|
Description
Antti Koivisto
2023-03-30 04:31:30 PDT
Pull request: https://github.com/WebKit/WebKit/pull/12170 Committed 262362@main (bc149c287545): <https://commits.webkit.org/262362@main> Reviewed commits have been landed. Closing PR #12170 and removing active labels. I think this introduces a performance cliff where documents with distinct selectors (ex with ids in them) fight over the cache. It also means there's a timing attack when process isolation is not enabled. You can call querySelector to see if a different origin has parsed a selector, which may also contain user identifiable information (ex. in attribute, id or class names) The cache key contains the security origin, I don't think there is attack like that. Ah you're right, I missed that line:
Key { selectors, context, document.securityOrigin().data() };
that still means the cache is technically smaller in a process with many tabs or iframes, but I don't have data that shows that's an issue. Thanks for explaining!
|