document-policy

document-policy copied to clipboard

For images policies, it's hard to come up with schemes where we don't download the image (e.g. https://github.com/WICG/feature-policy/issues/195#issuecomment-412069467), so we've been taking the approach of making the page obviously broken so the lowest path to fixing it is to actually fix the problem rather than a complex way of working around it. These are performance policies, so the consequences of bad actors working around the policies are not bad the way security policies are.

That said, it would be nice if browsers could avoid the fetching the whole bytes of the image in cases where we know the image will violate the policy. Maybe instead of inverting color, we should just show a generic broken image icon like the web of the 90s? That way, browsers can have optimizations where they fetch only the minimal bytes necessary.

@loonybear @clelland

Putting performance concerns aside for a minute... error behavior matching what browsers do when they currently download images which they cannot display for whatever reason – maybe adding a console.error with a nice message, too – sounds much less surprising, and no less visible, than inverting the colors.

Broken image icons aren't just a nineties thing 😄 https://codepen.io/eeeps/pen/rrPLOv

I agree with @eeeps, a broken image icon is more consistent with current browser behavior. Paired with a meaningful console message it becomes very useful for quickly debugging.

If I saw inverted colors I'd start by going back to the designer to see if something was wrong with the image itself.

There's no broken image icon there though, that shows the alt attribute's value.

@annevk screenshots of that pen (which references a FLIF resource that no browser can decode) in:

Safari:

Chrome:

Firefox:

From an author (and user?) experience perspective – it would be least confusing, I think, if each browser painted whatever they paint when they otherwise can’t load or decode an image. So in Firefox’s case – just show the alt text. A message in the console would also be nice, to explain what happened.

In Chrome and Safari (and I think some other browsers), the broken image icon is only shown on quirks mode pages.

Regardless, having least surprise is a good principle to follow, but for this set of policies, that conflicts with another principle that I think is more critical for policies, which is that it needs to be very clear to the developer when they've violated a policy so that they fix it. Showing nothing when the policy is violated (as per the Firefox image) makes it easy to have pages that download unnecessary images that never rendered and go unnoticed by developers.

Definitely +1 to policy violation report, and +1 to console warning or error.

+1 to early abortion of image loading to yield better performance with optimized image policies.

The one situation that isn't obviously covered by this is the max-downscaling policy, for viewport-sized images. WIthout srcset, it's possible for an image to begin in the non-violating state (<div><img style="width:100%">) but then be downsampled more and more as the user shrinks the window, or the page shrinks the containing div (or the device is rotated from landscape to portrait)

At some point, an already-downloaded image will transition from non-violating to violating. Should we replace the rendered image with a broken image icon at that point? And restore it when it grows back into the correct size range?

@clelland that sounds right to me!

---

Whether or not an image gets loaded or displayed — it would be really nice for authors to get some kind of hook so that they could extend or overrule the default styling of violating images.

For instance, to implement the original proposal, the UA stylesheet could contain a rule like:

img:violates-feature-policy {
	filter: invert(100%);
}

...which authors could extend or overwrite. If we go the “broken image” route, this CSS hook would also be nice so that authors could clearly differentiate FP-violations from other image problems, in ways that make sense for their particular development flow. e.g:

.development img:violates-feature-policy::before {
	content: "🚨 Feature-Policy violation 🚨 ";
	font-weight: 900;
	color: red;
}

Based on the explainer, it looks like instead of inverting the colors, Chrome will now display a placeholder.

This feels much nicer and more practical.

To make it even more usable, I wonder if that placeholder could be click-to-load? This is a somewhat common pattern among sites that deal with user-generated content (forums, Slack...)

To make it even more usable, I wonder if that placeholder could be click-to-load?

Definitely! That is the plan for those placeholders, I believe. We just haven't done the engineering yet to make that happen.

That will make it at least possible to interact with the page if the disallowed images are critical, if the user chooses to.

Yea we definitely had click-to-load idea but I think we were blocked on more UX studies and then we haven't got any update on this. @clelland since we are going to ship image policies to origin trial soon, maybe we could collect feedback on interests in click-to-load as well?