On Wed, Oct 7, 2026 at 4:14 PM Vladimir Levin <[email protected]> wrote: > > > > On Wednesday, October 7, 2026 at 10:56:20 AM UTC-4 Chromestatus wrote: > > Contact emails > [email protected] > > Specification > https://w3c.github.io/resource-timing > > Summary > For cross-origin resources, require that a resources is fetched with CORS for > it to show its encoded/decoded body sizes as well as transferSize. For > encodedBodySize/decodedBodySize this would replace the Timing-Allow-Origin > gate, while transferSize would require both. > > Blink component > Blink>PerformanceAPIs>ResourceTiming > > Web Feature ID > resource-timing > > Motivation > It was realized a while ago that when a resource opts-in to > "Timing-Allow-Origin" it should only opt-in to information that is clearly > related to *timing*. Body sizes, as well as the existing CORS-protected > attributes like responseStatus, contentType and contentEncoding, tell more > about the content of the resource than about the process of fetching it. > > Initial public proposal > No information provided > > TAG review > No information provided > > TAG review status > Not applicable > > Goals for experimentation > None > > Risks > > > Interoperability and Compatibility > No information provided > > Gecko: Shipped/Shipping > > WebKit: Shipped/Shipping WebKit only exposes body sizes for same-origin > resources, so they are more strict than this. > > Web developers: No signals > > Other signals: > > WebView application risks > > Does this intent deprecate or change behavior of existing APIs, such that it > has potentially high risk for Android WebView-based applications? > > No information provided > > > Debuggability > No information provided > > Will this feature be supported on all six Blink platforms (Windows, Mac, > Linux, ChromeOS, Android, and Android WebView)? > No > > > I assume this is available on all six Blink platforms? Could you check that > box > Done
> > > Is this feature fully tested by web-platform-tests? > No > > > Why not? I think there should be WPTs to ensure we can get to interop. Is > that possible to add? > Oh sorry, of course there are WPTs. See https://github.com/web-platform-tests/wpt/blob/123e9cf261ab3119dfbf9b6fac4cd9ca799dbf03/resource-timing/body-size-cross-origin.https.html (added to the chromestatus). > > > Flag name on about://flags > No information provided > > Finch feature name > ResourceTimingUseCORSForBodySizes > > Rollout plan > Will ship enabled for all users > > Requires code in //chrome? > False > > Tracking bug > https://issues.chromium.org/issues/40251936 > > Estimated milestones > Shipping on desktop158 Shipping on Android158 Shipping on WebView158 > > Anticipated spec changes > > Open questions about a feature may be a source of future web compat or > interop issues. Please list open issues (e.g. links to known github issues in > the project for the feature specification) whose resolution may introduce web > compat/interop risk (e.g., changing to naming or structure of the API in a > non-backward-compatible way). > > No information provided > > Link to entry on the Chrome Platform Status > https://chromestatus.com/feature/5195340595724288?gate=6079863659298816 > > This intent message was generated by Chrome Platform Status. -- 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/CAJn%3DMYbNvAR238OQyJhG6LNRdN9Z5jHbi0McB706EPpez05DOQ%40mail.gmail.com.
