Storage partitioning allowances for custom protocol frames

[csuwildcat]

For a site the user has added as a registered protocol handler for a safelisted scheme or web+ custom protocol, Storage partitioning, if it separates the handler site from its main storage (e.g. IndexedDB) will break the use case of loading a registered protocol as an iframe's src to establish a protocol-based app-to-app API channel.

To understand the use case, consider an example, web+wallet, wherein a user has added a site as their web+wallet handler. The web+wallet community ships a small lib to create a frame that loads the web+wallet protocol in an iframe's src, allowing top-level site to interact with whatever site a user has installed as their web+wallet handler, via the postMessage API conduit. It is important we not break this functionality for frames loaded with custom protocol handler pages, as this is the only means installed handlers have to provide a background process/API channel to sites that integrate support for them.

Recommendation: because registering a protocol handler already requires an explicit top-level visit to the domain of the registered site + the direct, overt, explicit user choice to install a site as a handler, custom protocol frames should be exempt from partitioning.

[csuwildcat]

Adding @erik-anderson, for Edge coordination and tracking

[erik-anderson]

@csuwildcat do we have clarity on what the current interop story looks like here? Per MDN, Safari doesn't support navigator.registerProtocolHandler. Does Firefox support loading a protocol handler in an iframe?

My general understanding is that under the covers this is mapping the protocol to an URL, so by default I believe any partitioning work would apply here by default.

There's a real risk if this is left open as a generic primitive that sites will be motivated to excessively prompt the user to register their pages as a protocol handler.

Perhaps the discussion here should be about if/how Storage Access API should impact it and/or if there should be a separate consent from the user where they opt into non-partitioned storage for the protocol handler and where it might have some text informing them that it would allow them to be tracked across the web?

I'd also be interested to understand if there are existing protocol handlers that are known to be broken when Storage Partitioning is in effect.

[csuwildcat]

do we have clarity on what the current interop story looks like here?

It is correct that Safari does not implement this useful, long-standard API. They should do that.

Does Firefox support loading a protocol handler in an iframe?

Yes, Firefox correctly loads the registered handler for a protocol when the protocol is the src value for an iframe, just as we and Chrome do.

My general understanding is that under the covers this is mapping the protocol to an URL, so by default I believe any partitioning work would apply here by default.

This is basically the paradigm, and the statement is that because registration of protocol handlers is an overt, explicit, and intentional authorization to enable protocol-based communication for advanced application purposes, storage partitioning that deadens the features such an API enables should not be in place.

There's a real risk if this is left open as a generic primitive that sites will be motivated to excessively prompt the user to register their pages as a protocol handler.

I would be happy to design other mechanisms that provide active background processes for registered apps that sites can communicated with over messaging channels, but 1) this is already possible with an existing API, and 2) we, as a browser community, could just fully implement the APIs that already exist and tie this capability/allowance to PWA installation,

separate consent from the user where they opt into non-partitioned storage for the protocol handler and where it might have some text informing them that it would allow them to be tracked across the web?

If we wrapped this up in a PWA install flow, I think we could do this more elegantly than creating a one-off consent/prompt flow.

I'd also be interested to understand if there are existing protocol handlers that are known to be broken when Storage Partitioning is in effect.

Great question - I suppose we would need to research this, as I cannot provide any offhand data on usage.