yea, for malicious site trying to learn all of the user’s language
preference, we probably will start rate limit language changes or distinct
language lists from a site.
It could be practical when taking advantage of the existing storage service
(Prefs) in Chromium.
I will double check the
1. We will start limit navigator.languages to return only a single
language. we know it might cause impacts in some cases. Also, will keep
tracking how it works in the ecosystem.
2. Users can only know one language, in this case, which makes service
confused. We will monitor how the
The unified origin trial for the Privacy Sandbox Ads APIs is now at 50% of
Chrome Beta population for FLEDGE and Attribution Reporting. A stability
issue was identified and fixed in Topics code, and we expect the API to be
available to 50% of Chrome Canary and Chrome Dev by the end of today,
The fact that the server can still actively probe to discover all of the
users' languages makes this feel like a questionable Privacy/UX tradeoff;
do we think the mitigations listed in the explainer are practical?
It would also be helpful if this proposal included learnings from the
rollout of
Hi all. The Topics API experiment is back up and running. 50% of canary &
dev users are now in the experiment group. We'll add 50% of beta within the
next couple of days. While I have your attention I'd like to also point you
to our new chrome://topics-internals page (available on canary and dev
(Note: The feature no longer works on preloads, compared to the original
I2P. See explainer for details.)
Contact emailsxiaoche...@chromium.org
Explainer
https://gist.github.com/xiaochengh/9404abbecdc3b45c0e9f3d5e99fbc65d#file-proposal-v3-md
Specificationhttps://github.com/whatwg/html/pull/7474
Sure! Hopefully this explanation helps clarify that relationship:
1) Fullscreen companion window allows a frame with window-placement
permission to request fullscreen on one screen, and open a popup window on
another screen, from a single transient user activation.
This enables a single click to
So, I've been using HTTP2 push for almost 2 years now and as I continue to
write more SPA with more native code (now that IE11 is dead-dead), not
having Push will keep us stuck in the single file bundling mess of CSS and
JS, and all it's bundlers and debugging complexity.
With Javascript, ESM
Since Chromium removed the TLS1.0 and TLS1.1 protocols,the cipher suite
which using HMAC-SHA1 is unnecessary,because TLS1.2 add the SHA2 to ths
cipher suite
I suggest remove these cipher :
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
TLS_RSA_WITH_AES_128_CBC_SHA
Hi Mike, can you help me understand the relationship of this work to
Fullscreen capability delegation? Is the difference just 1 vs many screens?
https://github.com/WICG/capability-delegation#allowing-fullscreen-from-opener-window-click
On 5/9/22 8:35 PM, Mike Wasserman wrote:
1. What about pure client side i18n?
If `navigator.languages` limits to an array which has only one language,
client can't select the best language if the first doesn't match.
2. Could it send two languages in Accept-Language header by default (not
one)?
I guest a lot of people can understand
Yea, we definitely will collect metrics on those performance. thanks for
your comments.
On Sunday, May 22, 2022 at 2:08:02 PM UTC-4 Harald Alvestrand wrote:
> I hope you will be recording the percentage of extra round trips, split on
> main language preference. This may be a disproportionate
On Mon, May 2, 2022 at 8:38 PM Jerilyn D. wrote:
> Are there any future plans on eventually not honoring the
> Origin-Agent-Cluster:
> ?0 to allow setting document.domain ? Or will this header always be honored
> ?
>
There is no plan for dropping the Origin-Agent-Cluster header, or the
Thanks all for the feedback. Update(s):
- The warnings are live, for about two weeks now. Usage is trending down,
but slowly.
- I'd like to postpone flipping the default to M109, as requested (here,
and offline). The existing caveats - particularly a new intent, as
requested by Yoav upthread -
14 matches
Mail list logo