Intent to implement and experiment: Unoptimized images policies

142 views
Skip to first unread message

Ian Clelland

unread,
Feb 28, 2019, 2:04:27 PM2/28/19
to blink-dev

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.

Ian Clelland

unread,
Mar 5, 2019, 10:23:42 AM3/5/19
to blink-dev
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)


Daniel Bratell

unread,
Mar 5, 2019, 11:21:59 AM3/5/19
to Ian Clelland, blink-dev
Good catch. It is now. Unfortunately the script that makes the list is not very intelligent.

/Daniel
--
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.



--
/* Opera Software, Linköping, Sweden: CET (UTC+1) */

PhistucK

unread,
Mar 5, 2019, 11:36:07 AM3/5/19
to Daniel Bratell, Ian Clelland, blink-dev
> 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.

PhistucK


Yoav Weiss

unread,
Mar 7, 2019, 4:26:33 PM3/7/19
to PhistucK, Daniel Bratell, Ian Clelland, blink-dev
LGTM to experiment

On 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.

PhistucK


On 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.

/Daniel

On 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)




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 modes

I'd think that as long as folks keep their bpp ratios small, we shouldn't care much about how they got there.
 

Ian Clelland

unread,
Mar 7, 2019, 5:03:58 PM3/7/19
to Yoav Weiss, PhistucK, Daniel Bratell, blink-dev
On Thu, Mar 7, 2019 at 4:26 PM Yoav Weiss <yo...@yoav.ws> wrote:
LGTM to experiment

On 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.

PhistucK


On 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.

/Daniel

On 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)




Have you filed for a TAG review? If not, now would be a good time to kick it off.

I have not yet, but I'll do that.
 
 



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 modes

I'd think that as long as folks keep their bpp ratios small, we shouldn't care much about how they got there.

Agreed on all counts, and we've actually dropped a proposed feature, 'legacy-image-formats', for exactly those reasons. If you can manage to get a TGA or BMP image into the size constraints that we apply for more modern formats, then we'll render it. We're just not going to take those formats into account at all when coming up with suggested ratios.

Yoav Weiss

unread,
Mar 7, 2019, 5:11:17 PM3/7/19
to Ian Clelland, PhistucK, Daniel Bratell, blink-dev
Got it! That's great to hear. You may want to update the explainer though, as it gives the impression that it's still part of that policy.
Reply all
Reply to author
Forward
0 new messages