[blink-dev] Re: Intent to Experiment: Open popups as fullscreen windows

Given the extremely widespread use of Fullscreen in techscams , I'm concerned about making things easier for attackers. Can I use this new API to make it such that every time my victim user clicks in a fullpage attack wi

Re: [blink-dev] Intent to Ship: Cookies Having Independent Partitioned State (CHIPS)

There is not a Chrome Policy to control this feature (and no similar mechanism for an Enterprise to turn off chrome://flags/#partitioned-cookies), is there? I ask because a major enterprise SaaS vendor today reached out to me to say that their product abruptly stopped working properly. Invest

[blink-dev] Re: Intent to Prototype: Reduce fingerprinting in the Accept-Language header and ​​support for HTTP Variants

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

[blink-dev] Re: Features check with new version release

How do you "monitor"? I'm not aware of any cases where a feature made it into a Dev/Beta release without being in Canary first. (That said, it's *possible *to cherry-pick features from Canary *into *Dev/Beta releases after they were forked out of Canary). Things are slightly complicated by the

[blink-dev] RE: Features check with new version release

For some reason, I don't see your reply in the discussion group. Below, it sounds like you're conflating "features as a part of the release" (what's checked into the code) vs. "features that are listed on ChromeStatus as being part of the release" (documentation). Unfortunately, these aren't the

[blink-dev] Proposal: Ignore Strict-Transport-Security headers for Localhost responses

CL: https://chromium-review.googlesource.com/c/chromium/src/+/5923046?tab=comments Today, if a https://localhost:* response sets Strict-Transport-Security, HTTPS upgrades will be applied to all subsequent http://localhost requests, regardless of port. Localhost is inherently a secure context,

[blink-dev] Intent to Ship: Ignore Strict-Transport-Security for localhost

*Following up on an earlier thread here: https://groups.google.com/u/1/a/chromium.org/g/blink-dev/c/gGHOmFGEzQ0* Contact emails: eric...@microsoft.com Explainer: None Specification: HSTS specification is at https://datatracker.ietf.org/doc/html/rfc6797; this feature proposes an improvement.