Define feature policy for monetization

[adrianhopebailie]

From web-monetization created by jpettitt: adrianhopebailie/web-monetization#26

The spec as drafted has multiple issues related to revenue sharing, fraud, and abuse prevention.

#16 and #23 have some discussion of where the <meta> tag and monetization object should live. The document vs navigator choice has some implications for abuse prevention.

As written the spec disallows meta tags in iframes. This is impossible to enforce as <iframe> contents are not visible to parent frames. Depending on the, as yet unspecified error handling, an iframe could include a monetization meta tag and trigger a denial of service on the parent by virtue of having more than one tag.

Conversely, if meta tags in iframes are ignored a malicious actor could frame content pages and include a monetization tag in the top frame thus hijacking the payment from the child frame content. This become particularly tricky when dealing with embedded videos where there may be multiple, legitimately monetized child frames on a page.

The mechanics of allocating payment between multiple claimants, some legitimate some not are extremely complex. For example a page that collates the best cat videos from YouTube probably deserves some revenue for bringing the audience. While at the same time the embedded videos also deserve revenue to reward the creators. This is currently achieved vi banner and pre roll ads respectively. It's unclear how this can be done within the current spec.

[adrianhopebailie]

This is impossible to enforce as <iframe> contents are not visible to parent frames.

Only one meta tag per document (Document has a roughly 1:1 relationship with Window), at any one time.

The current implementation is a web browser extension which has knowledge of whether the current window is the "top" window. It simply ignores monetization requests in iframes, it doesn't thwart the top level content.

This could be better specified.

In earlier versions of the spec there was support for <iframe allow='monetization'> but it was never completely implemented, nor specified in detail, and given it is, as you say, complex, we removed it from the spec until we have a working proof-of-concept.

Conversely, if meta tags in iframes are ignored a malicious actor could frame content pages and include a monetization tag in the top frame thus hijacking the payment from the child frame content.

I am parsing that as a concern for people putting meta tags on top level pages, then embedding iframes of others content, with the top frame always getting paid.

I think you have brought up some good points to ponder here. In the meantime there is X-Frame-Options for child frames wanting to protect their content: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Frame-Options

[adrianhopebailie]

Regarding scrolling content, browsers knows what's in viewport. So it ought to be possible to credit frames that are in context. It gets quite complex to do once you have to take into account horizontally scrolling elements like carousels.

Video and Audio are a bit easier with the death of flash. It should be possible to identify all video/audio tags and detect which ones are playing. Allowing a monetization http header on the video files would be helpful here.

However if you're defining a standard and want browsers to bake it in (presumably the long term goal) it's best to define it how it should work and then make compromises needed to get it to work in the extension for now rather than limiting the standard to what's possible with an extension. Since extensions are disallowed on mobile if this project has any hope of actually achieving product market fit it needs to be baked into browsers.

Regarding nested frames I don't think x-frame is really helpful here it's too blunt an instrument. A pair of content security policies that let an iframe disallow monetized parents and a complimentary policy to allow a parent to yield to monetized children in viewport might go a long way to solving it. Although it would have to be designed carefully and there are a lot of edge cases.

[adrianhopebailie]

The long scrolling page of collated content is something I've pondered now and then.
Do you think simply distributing the revenue equally amongst all frames is fair? It would certainly pass the KISS test. Could the browser detect the content in focus somehow and give it the lion's share ?

[adrianhopebailie]

Good points!

I don't think x-frame is really helpful

Temporary :)

[Malvoz]

Feature-Policy is probably the way to go here, because with a defined policy-controlled feature (https://github.com/w3c/webappsec-feature-policy/blob/master/integration.md) with a default allowlist of self, monetization would (by default) only be allowed in a top level browsing context, and web authors would explicitly have to allow monetization in frames, e.g. using <iframe allow="payment-stream"> as I suggested in adrianhopebailie/web-monetization#5 (comment).

[sublimator]

Talking to yourself again @adrianhopebailie ?

[adrianhopebailie]

Talking to yourself again @adrianhopebailie ?

It’s the stress! Unf github only supports transferring issues within the same org so I had to use a tool and it recreates the thread all under my name

[sublimator]

It’s the stress!

:) (edit: <--- ugh!, every time with forgetting the newline after > )

This will later be moved again to WICG eh? So it wouldn't really be appropriate to fold in the (currently private, soon open-sourced) WM (extension etc) repo as well eh?

[adrianhopebailie]

This will later be moved again to WICG eh?

No, don’t think so necessarily. @marcoscaceres and I chatted about it briefly and he seemed happy to just use this repo