Questions about design about transfer-size

[jkarlin]

RIght, it's not an enforcer. We leave that up to the site author because there are so many enforcement options you might want.

Agree that PauseDocument is important for this proposal. However you have the alternative of unloading frames that grow too large and are of limited importance to the site.

In terms of ads and logging, don't forget the ad-network is also likely to want to track the creatives they show and which of them exceed limits and by how much.

[jkarlin]

I should note that, in my mind, this explainer is out of date. I'd like to shift to a TransferSizePolicy that automatically enforces limits by gradually throttling the network requests of the frame after the limit is exceeded. There would be no event at all. The primary reason for this change is to limit leakage of x-origin size information.

[addyosmani]

@jkarlin Could you expand on how you see gradual throttling working in practice? e.g origin foo.com exceeds a budget of 500KB and continues to request more resources. Would each subsequent request or set of requests simply be fetched slower? This model is much simpler than the one previously summarized here but I think it's still of high value and makes sense in the context of avoiding x-origin leakage of size data.

I'd love to learn more about the timelines for our plans here (given other types of policies have already started to land for feature policies V1).

[jkarlin]

Yes, the ongoing and subsequent requests would slow down a little bit, ramping down to 2G speeds (or perhaps less) after awhile. I'm afraid I haven't really thought about specifics. I worry about details like, what if you set the budget to 10KB, does it even make sense that it won't throttle down to 2G speeds until the frame is at (say) 1MB or more?

Timeline wise, I think we're more interested in using this as an intervention mechanism in Chrome, seeing how it works, and potentially exposing it via web api if we find it useful. So it'll be a bit down the road.