This proposal is being withdrawn and the associated code was removed in Chrome 144.
See our Update on Plans for Privacy Sandbox Technologies <https://privacysandbox.com/news/update-on-plans-for-privacy-sandbox-technologies/> . Privacy Sandbox feature status <https://privacysandbox.google.com/overview/status> provides more information about the status of individual APIs and platform features. On Tue, Nov 12, 2024 at 2:44 AM Ari Chivukula <[email protected]> wrote: > Contact emails > > [email protected], [email protected], [email protected], > [email protected], [email protected] > > Explainer > > https://explainers-by-googlers.github.io/partitioned-popins/ > > Intent to Prototype > > https://groups.google.com/a/chromium.org/g/blink-dev/c/ApU_zUmpQ2g/ > > Demo > > https://partitioned-popin-demo.glitch.me/ > > Feature Flag > > chrome://flags#partitioned-popins in Chrome 132 and later > > Summary > > A new web primitive is needed to cover short-lived popup use cases which > require access to storage partitioned by the popup opener. This primitive > should be private and secure by default, while providing a consistent UI > experience across user agents. > > To solve this need, we propose the “Partitioned Popin”, a type of pop-up > for loading web content with two unique new features: a modal-like UI > relative to its opener tab, and cookies/storage being partitioned to its > opener context. > > > Blink component > > Blink>Storage > <https://issues.chromium.org/u/1/issues?q=customfield1222907:%22Blink%3EStorage%22> > > > Motivation > > Many smaller businesses and applications on the web currently use > third-party vendors to perform or facilitate security sensitive operations > such as authentication. These third-party vendors prefer to be loaded in > top-level contexts so that they are not subject to clickjacking or script > injection attacks by a compromised relying party, but would want access to > the same third-party storage partition an iframe embedded in the opener > would use to verify the login once completed. > > This ‘popin’ could be useful for any sites wanting a consistent way to > prompt the user to interact with a new window in a way that makes it clear > what site initiated the interaction. Making the ‘popin’ partitioned by its > opener ensures the privacy of an iframe (restricting access to first-party > storage) while retaining the security of a top-level navigation (isolating > the process). > > TAG review > > https://github.com/w3ctag/design-reviews/issues/956 > > Compatibility > > This adds a new feature without removing existing ones. > > > Interoperability > > Gecko: https://github.com/mozilla/standards-positions/issues/1023 > (Deferred) > > WebKit: https://github.com/WebKit/standards-positions/issues/349 > > Web developers: Positive interest at TPAC 2024, conducting outreach to > parties with login-related use-cases > > Debuggability > > The ‘popin’ and related permissions/headers will be debuggable via > DevTools. > > Is this feature fully tested by web-platform-tests? > > Yes > <https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/web_tests/external/wpt/partitioned-popins/> > > Tracking bug > > https://issues.chromium.org/issues/340606651 > > Link to entry on the Chrome Platform Status > > https://chromestatus.com/feature/5949561398099968 > > -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGpy5D%2B25d2XUof40FJ6tXk1g6wRVpjzovZFRb9Fhg7Ln6GwfA%40mail.gmail.com.
