Coercive misuse by advertisers?

[hadleybeeman]

Hi all! We the TAG reviewed this at our face-to-face meeting in Seattle, as per the issue you left in our repo.

Overall, we see a lot of good uses for this feature -- especially for something like a photo gallery, where you want to see the main photo first but may have to wait for thumbnails for all the other photos to load first.

But we are particularly concerned about the possibility that advertisers will say "In order to work with us and serve our ads, you must mark our ads as high priority" -- which really isn't in the interest of the user who was primarily asking to see the content of the page.

Have you thought about this?

We wondered if dropping iframe from your spec would solve that; but the same bad behaviour would be likely to persist with ads as images.

We also thought about dropping the high priority (leaving only the low and auto) -- which would only let the site mark certain resources as low. But it would still be possible for a coercive ad network to say, "To contract with us, you must mark all other content on the page as low-- except our ads." (Is that likely? Would a large content publisher actually be willing to do that? It feels less likely to me... but then, it probably depends on how much money is at stake.)

We did discuss the fact that the user agent could ignore the hints altogether, by setting or by an extension; though that would require users to know what's going on and to understand how to change it.

What do you think about this? Have you considered it, and if so, what is a good way to minimise the chances of this degrading the web experience for our users?

[slightlyoff]

@hadleybeeman: priority info is already passed to the HTTP layer in H/2, right?

[addyosmani]

Thank you for this valuable feedback from the TAG, @hadleybeeman and apologies for our delayed replies. We have yet to fully flesh out the parent/child impact of Priority Hints on iframe and will aim to discuss asap whether dropping support for it in favor of a focus on <img>, <link> etc is sufficient to meet most of the use-cases we had originally planned.

When we initially discussed the impact third parties could have on page load performance by enforcing or encouraging high values for their resources, the take we had was that as PR is a hint, the browser is free to apply its own heuristics to decide what to do with third-party use of this feature.

@domfarolino @yoavweiss and I will aim to work through a few scenarios based on your feedback and circle back here shortly.

[yoavweiss]

I don't think that ad networks can abuse the high priority more than they can abuse other mechanisms (e.g. have we seen ad networks that force publishers to include a blocking scripts?).
On top of that, at least at the moment they don't have mechanisms to monitor the priority in which publishers hint for their resources, as priority is not directly web exposed. (even if it can be deduced at the H2 layer)

[tomByrer]

Good to bring up the point @hadleybeeman!
There is another early spec to limit transfer in iframes.

[slightlyoff]

Per today's TAG call (which I'm no longer a member of, FWIW), wanted to reflect a few points about the potential for abuse:

• The proposed system exposes no new priority levels. Any party that is being composed into a tab already have access to all of the priority levels expressed in this system. Browsers already have to be resilient in the face of gamed priorities. E.g., if an advertisers decides to inline all of their content into a top-level document (which is implicitly highest-priority) or entirely via <script src="...">elements, they would be able to do exactly what is possible via this extension, only without having to bend themselves backwards to abuse a media type.
• Browsers (and perhaps extensions) have the ability to re-set these priorities regardless of what is hinted by this API. E.g., if an advertisers wants to try to starve the pipe, browsers can detect this and decide to intervene. The API doesn't provide any guarantees.

All of that makes me think there's no new surface for abuse (but I could always be wrong!)

[yoavweiss]

I believe this was addressed by #38, so closing. Feel free to re-open if you think the language there is insufficient.