Contact emails
icle...@chromium.org, loon...@chomium.org
Spec
https://github.com/w3c/webappsec-feature-policy/blob/master/policies/optimized-images.md
Summary
We want to experiment with policies which allows developers to selectively enable and disable the use of large and/or unoptimized images on their sites, through feature policy.
The 'unoptimized-images' policy will restrict the use of images with a high byte-per-pixel ratio. (Exact value can be set by the developer)
The 'oversized-images' policy will restrict the ability of images to be rendered inside of containers which are much smaller than the actual intrinsic image dimensions. (Again, the cutoff value can be set by the developer)
Goals for experimentation
We would like to use this experiment to get developer feedback in three areas.
First, we want to know if the feature is useful at all to developers: Can they actually run their websites, either in staging or (hopefully) production, with the trial enabled, or is it too disruptive to expose actual end users to its restrictions. Second, if it is usable, we would like to ask developers to experiment with different threshold values, to find out (a) what values were usable with essentially no change to existing resources, and (b) what values could they achieve by making changes to their site (resizing or reexporting images as necessary; switching from PNG to JPEG if appropriate, etc.)
Third, are the policies intuitive? Do the names and value ranges make sense? Experimentation is a good time to get feedback from developers on ergonomic issues like that.
Experimental timeline
M74 - M76
Any risks when the experiment finishes?
No risks when the experiment ends; sites using the trial should (hopefully) have optimized their images by then anyway, so there should be no observable change if the feature became unavailable. Certainly future regressions would not be caught without the policy enforcement, but sites will continue to function correctly.
Ongoing technical constraints
None
Will this feature be supported on all five Blink platforms supported by Origin Trials (Windows, Mac, Linux, Chrome OS, and Android)?
Yes.
Link to entry on the feature dashboard
Unoptimized-images: https://www.chromestatus.com/features/6390897969201152
Oversized-images: https://www.chromestatus.com/features/5953669526716416
Notes on Privacy
There is a potential information leak regarding cross-origin images with this feature; the content-length of such an image in a first-party frame can be estimated with multiple uses of the 'unoptimized-images' policy. We are working with privacy teams to determine how best to mitigate this risk, and expect to have that resolved before shipping.
--
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 blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAK_TSX%2BpWAB6tLvA1JJ7CWZiRt5Pzjjd0YyOnxDEDqmx3%3DQxEg%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/op.zx6s2obxrbppqq%40cicero2.linkoping.osa.
> Notes on Privacy
> ...> expect to have that resolved before shipping.Before shipping the experiment (origin trial), or before shipping the feature (enabled by default)? I hope it is the former, otherwise websites that register for the origin trials could use this for its leakage benefits alone.☆PhistucKOn Tue, Mar 5, 2019 at 6:21 PM Daniel Bratell <bra...@opera.com> wrote:Good catch. It is now. Unfortunately the script that makes the list is not very intelligent./DanielOn Tue, 05 Mar 2019 16:23:26 +0100, Ian Clelland <icle...@chromium.org> wrote:I just realized that, while this is an intent to experiment, the subject line may not have made that clear (it's not marked as such in the bit.ly spreadsheet of Blink intents)On Thu, Feb 28, 2019 at 2:04 PM Ian Clelland <icle...@chromium.org> wrote:
Summary
We want to experiment with policies which allows developers to selectively enable and disable the use of large and/or unoptimized images on their sites, through feature policy.
The 'unoptimized-images' policy will restrict the use of images with a high byte-per-pixel ratio. (Exact value can be set by the developer)
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABc02_%2B_FFSD%3DYqWzrcu_Y1YQpND%3DQmt%2B%2BAddTBJr9v6LqHagA%40mail.gmail.com.
LGTM to experimentOn Tue, Mar 5, 2019 at 5:36 PM PhistucK <phis...@gmail.com> wrote:> Notes on Privacy
> ...> expect to have that resolved before shipping.Before shipping the experiment (origin trial), or before shipping the feature (enabled by default)? I hope it is the former, otherwise websites that register for the origin trials could use this for its leakage benefits alone.☆PhistucKOn Tue, Mar 5, 2019 at 6:21 PM Daniel Bratell <bra...@opera.com> wrote:Good catch. It is now. Unfortunately the script that makes the list is not very intelligent./DanielOn Tue, 05 Mar 2019 16:23:26 +0100, Ian Clelland <icle...@chromium.org> wrote:I just realized that, while this is an intent to experiment, the subject line may not have made that clear (it's not marked as such in the bit.ly spreadsheet of Blink intents)On Thu, Feb 28, 2019 at 2:04 PM Ian Clelland <icle...@chromium.org> wrote:Have you filed for a TAG review? If not, now would be a good time to kick it off.
Summary
We want to experiment with policies which allows developers to selectively enable and disable the use of large and/or unoptimized images on their sites, through feature policy.
The 'unoptimized-images' policy will restrict the use of images with a high byte-per-pixel ratio. (Exact value can be set by the developer)
(with my API owner hat off)Am I understanding correctly that this policy also enforces modern image formats, e.g. WebP?If so, I'm not sure it makes sense to enforce that, beyond a restrictive bits-per-pixel ratio.While modern formats are typically better, there are cases where one would prefer more traditional ones:* they can be smaller at times although that's rare* they support features webP doesn't, e.g. progressive rendering and multiple chroma subsampling modesI'd think that as long as folks keep their bpp ratios small, we shouldn't care much about how they got there.