You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
"body": "### WebKittens\n\n_No response_\n\n### Title of the proposal\n\ncan streams be transferred via postMessage()?\n\n### URL to the spec\n\nhttps://streams.spec.whatwg.org\n\n### URL to the spec's repository\n\nhttps://github.com/whatwg/streams\n\n### Issue Tracker URL\n\n_No response_\n\n### Explainer URL\n\nhttps://github.com/whatwg/streams/blob/master/transferable-streams-explainer.md\n\n### TAG Design Review URL\n\nhttps://github.com/w3ctag/design-reviews/issues/551\n\n### Mozilla standards-positions issue URL\n\nhttps://github.com/mozilla/standards-positions/issues/430\n\n### WebKit Bugzilla URL\n\n_No response_\n\n### Radar URL\n\n_No response_\n\n### Description\n\nThe specific subsections of the spec are:\n- https://streams.spec.whatwg.org/#rs-transfer\n- https://streams.spec.whatwg.org/#ws-transfer\n- https://streams.spec.whatwg.org/#ts-transfer\n- https://streams.spec.whatwg.org/#transferrable-streams\n\nAccording to [caniuse](https://caniuse.com/wf-transferable-streams) the other major browsers added support between 2020-2022. I didn't see a tracking issue for it here and it seems like a notable omission, apologies if I missed it while searching.",
"body": "### WebKittens\n\n@annekv\n\n### Title of the proposal\n\nCompression Dictionary support for cross-origin no-cors requests\n\n### URL to the spec\n\nhttps://fetch.spec.whatwg.org/\n\n### URL to the spec's repository\n\nhttps://github.com/whatwg/fetch\n\n### Issue Tracker URL\n\n_No response_\n\n### Explainer URL\n\n_No response_\n\n### TAG Design Review URL\n\nhttps://github.com/w3ctag/design-reviews/issues/1203\n\n### Mozilla standards-positions issue URL\n\nhttps://github.com/mozilla/standards-positions/issues/1381\n\n### WebKit Bugzilla URL\n\n_No response_\n\n### Radar URL\n\n_No response_\n\n### Description\n\nThis is a change to [Compression Dictionary Transport](https://github.com/WebKit/standards-positions/issues/160) that we talked about during the [fetch spec integration](https://github.com/whatwg/fetch/pull/1854) for the browser-specific CORS readability issues that are not covered by the [RFC](https://datatracker.ietf.org/doc/rfc9842/).\n\nCurrent WPT's and Chrome's implementation do not allow dictionary compression for cross-origin no-cors requests to prevent oracle attacks (and clients don't send the Accept-Encoding or dictionary headers for those requests).\n\nAt TPAC 2025 in the TAG general discussion, we came up with a solution of leveraging the existing `Cross-Origin-Resource-Policy: cross-origin` response header to flag responses that don't need protection from oracle attacks (the current use for this header) since they contain only public data.\n\nThe current PR for the Compression Dictionary Transport spec integration into fetch includes the change but it was not part of the original WPT's or implementations so I wanted to get buy-in on the change (and provide notice for the in-flight implementation work).\n\nIf we ever want to enable dictionary compression for some no-cors requests, now is the time to do it before there are widespread deployments. \n\nThe only risk is if there are resources that are used in both same-origin and cross-origin no-cors contexts and the origin currently supports compression dictionary transport but does not have the CORP response header on the responses, it will start to fail if they are not limiting dictionary support to same-origin responses (required by the RFC but unlikely someone would notice since they don't get the headers currently if it's not supported).\n\nGoing forward it wouldn't be a problem because the issue would be discovered at the time of deployment rather that with a browser change to existing production traffic.\n\nThere aren't any deployments that I'm aware of that have that problem but the risk of it happening increases over time with more dictionary deployments, limiting the chances of making the change in the future.\n\nThe alternative would be to not allow dictionary compression for any cross-origin no-cors requests independent of the content which would be cleaner for sites since they'd never get the dictionary request headers but it also limits the ability for third-party script embeds to use dictionary compression.",
"body": "### WebKittens\n\n@rniwa @othermaciej\n\n### Title of the proposal\n\nDevice Memory\n\n### URL to the spec\n\nhttps://www.w3.org/TR/device-memory/\n\n### URL to the spec's repository\n\nhttps://github.com/w3c/device-memory/\n\n### Issue Tracker URL\n\n_No response_\n\n### Explainer URL\n\n_No response_\n\n### TAG Design Review URL\n\nhttps://github.com/w3ctag/design-reviews/issues/190\n\n### Mozilla standards-positions issue URL\n\nhttps://groups.google.com/g/mozilla.dev.platform/c/cfydu35XdnY/m/3IqYn0oJAQAJ\n\n### WebKit Bugzilla URL\n\nhttps://bugs.webkit.org/show_bug.cgi?id=199084\n\n### Radar URL\n\n_No response_\n\n### Description\n\nMoving this over from this issue on the repo: https://github.com/w3c/device-memory/issues/24 as doing some housekeeping over there.\n\n@rniwa previously opened that issue with:\n\n> We don't support this API because:\n>\n> - RAM is not a direct estimate of whether the device can run a website with good performance - Some generations of iPads, for example, has an old generation CPU with more RAM.\n> - Amount of RAM device has is no indicative of how much RAM a website can use - the amount of memory WebContent process can use is > limited by a number of variables beyond just the amount that's physically available on a given device.\n> - It adds a new reliable fingerprinting surface - 100% reliability to disambiguate one device from another based on RAM size is a new fingerprinting surface we don't want to add.\n\nLet me know if this opinion has changed, but even if not, it's better to have the position listed in this repo IMHO. In which case feel free to close this issue with the appropriate labels.\n\nFrom the Chrome point of view, I'd reply to above comments with:\n\n> - RAM is not a direct estimate of whether the device can run a website with good performance - Some generations of iPads, for example, has an old generation CPU with more RAM.\n\nAgreed, but it is one of the more important signals. In my own experience [there is a clear correlation with Device Memory and web performance](https://www.smashingmagazine.com/2022/03/signals-customizing-website-user-experience/#device-capability-signals). \n\nDiscussions with multiple RUM providers, when I recently worked on updating the limits in Chrome, have shown the same correlations.\n\n> - Amount of RAM device has is no indicative of how much RAM a website can use - the amount of memory WebContent process can use is > limited by a number of variables beyond just the amount that's physically available on a given device.\n\nI also agree to a point. Again, this is one signal.\n\nWe see two use cases for this API\u2014both of which we hear successful use of in the wild:\n- To adapt website capabilities for lower end, or higher end. Often sites choose a cut off (e.g. below 2GB gets a lite version), rather than fine tune to every value. But different sites may choose different \"cut offs\" so a low/high signal is less useful here.\n- To explain performance metrics for analytics (e.g. there is an decrease in performance despite no changes, but this correlates with an increase in users with lower RAM \u2014 the reason for the degradation can therefore be explained).\n\n> - It adds a new reliable fingerprinting surface - 100% reliability to disambiguate one device from another based on RAM size is a new fingerprinting surface we don't want to add.\n\nThe values are coarsened and capped to reduce the risk of finger printing. Recent updates to the spec give the user-agent control over how to cap the values exposed. In the [Webkit bug](https://bugs.webkit.org/show_bug.cgi?id=199084) @othermaciej suggested:\n\n> Maybe we could expose 2GB as a fixed value for macOS, iOS and iPadOS devices, since all currently supported models would likely meet the true \"high end\" criteria.\n\nThat would now be permitted by the updated spec. An extreme interpretation of the capping, but permitted none-the-less. Though in these days you may wish to choose a higher value than 2GB and review that over time.\n\nThanks for your consideration.\n",
0 commit comments