Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Legitimate Meta Tags #14

Closed
adrianhopebailie opened this issue Oct 14, 2019 · 13 comments

Comments

@adrianhopebailie
Copy link
Member

@adrianhopebailie adrianhopebailie commented Oct 14, 2019

From web-monetization created by LonMcGregor: adrianhopebailie/web-monetization#5

This is a great proposal - I've been meaning to try and write a similar one myself for some time. (I should probably get a move on and write that...) I'm also not sure how best to contribute - can I just flag up as many issues as I want, or would it be better to contain issues in one thread?

Recording Legitimate Meta Tags

One major thing is missing from this draft as I see it: The presence of <meta> tags needs to be legitimate. To fix this I would suggest that this API only operate on sites served over HTTPS. This would preclude bad actors like ISPs injecting their own <meta> tags onto pages.

I also wonder if it would be worth only caring about <meta> tags present on the page from the moment the browser receives bytes. This would be to prevent malicious extensions from injecting tags.

@adrianhopebailie

This comment has been minimized.

Copy link
Member Author

@adrianhopebailie adrianhopebailie commented Oct 14, 2019

I really like the idea of requiring HTTPS.

"only caring about tags present on the page from the moment the browser receives bytes" < is this possible?

@adrianhopebailie

This comment has been minimized.

Copy link
Member Author

@adrianhopebailie adrianhopebailie commented Oct 14, 2019

When we initially were experimenting with the Web Monetization meta tag, we made it so that it can't be changed. We read it once at page load and didn't listen for any changes on it.

We found that to be very limiting on sites that have a mix of monetized and non-monetized content. The same also applies for sites that host content from a variety of authors, each of whom has their own payment pointer. This is most obviously a problem for single-page apps, but it could also apply on any site where you can view multiple different pieces of content without a page reload.

There's always the view that if the user has malicious software/extensions on their device modifying stuff then there's nothing the browser could ever do to fully secure against that.

I think that's a reasonable view. And I can actually think of reasons why someone might want an extension to modify the monetization tags on the pages they view. Maybe their extension adds monetization tags to donate to creators on a currently non-web-monetized platform like youtube, or maybe their extension auto-removes monetization from a community curated blacklist of sites.

@adrianhopebailie

This comment has been minimized.

Copy link
Member Author

@adrianhopebailie adrianhopebailie commented Oct 14, 2019

I also wonder if it would be worth only caring about tags present on the page from the moment the browser receives bytes. This would be to prevent malicious extensions from injecting tags.

Aside from client-side attacks, there is also the possibility of classic injection attacks. Imagine this URL:

https://popular-creator.com/fancy-page?title=</title><meta name="monetization" value="$malicious-hacker.com">

Resulting in HTML like this:

<title></title><meta name="monetization" value="$malicious-hacker.com"></title>

This could be an issue especially if WM Providers decide bandwidth based on origin, so popular-creator.com might be paid at quite a high rate. Or perhaps the user could be tricked into leaving a tip while they are on a part that is compromised in this way.

I think one approach to solving this would be to make Web Monetization part of the Content Security Policy in the future. For instance, my CSP could determine which origins I allow for payment pointers:

Content-Security-Policy: default-src 'none'; monetization-src mywallet.com

Which would allow payment pointers starting with $mywallet.com.

@adrianhopebailie

This comment has been minimized.

Copy link
Member Author

@adrianhopebailie adrianhopebailie commented Oct 14, 2019

"only caring about tags present on the page from the moment the browser receives bytes" < is this possible?

There's always the view that if the user has malicious software/extensions on their device modifying stuff then there's nothing the browser could ever do to fully secure against that. Perhaps my 2nd point is overkill.

@adrianhopebailie

This comment has been minimized.

Copy link
Member Author

@adrianhopebailie adrianhopebailie commented Oct 14, 2019

It’s possible, but it seems quite limiting. That this would only work in secure contexts seems like an unintended oversight or implied, as definitely shouldn’t work over http for the reasons stated.

@adrianhopebailie

This comment has been minimized.

Copy link
Member Author

@adrianhopebailie adrianhopebailie commented Oct 14, 2019

@adrianhopebailie

This comment has been minimized.

Copy link
Member Author

@adrianhopebailie adrianhopebailie commented Oct 14, 2019

For any one else curious what 'feature policy' is
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Feature-Policy

@adrianhopebailie

This comment has been minimized.

Copy link
Member Author

@adrianhopebailie adrianhopebailie commented Oct 14, 2019

@justmoon good idea. Problem with CSP is that it's not on by default... so maybe we should default it to always 'self' for this or none (or whatever it is that would block the xss by default). I wonder if feature policy could play a role also?

@adrianhopebailie

This comment has been minimized.

Copy link
Member Author

@adrianhopebailie adrianhopebailie commented Oct 14, 2019

Is there any way that a browser could only allow monetization tags to be modified by scripts from a certain domain? Is there any precedence for something like that. That would seem to offer a lot of flexibility.

@adrianhopebailie

This comment has been minimized.

Copy link
Member Author

@adrianhopebailie adrianhopebailie commented Oct 14, 2019

It feels natural to have web monetizations be governed by the payment policy-controlled feature (which currently only governs the origins allowed to construct PaymentRequest instances), i.e.:

Feature-Policy: payment 'self' https://secure-wallet.example/alice

But I think it may be safer for web monetization to define its own feature, e.g. payment-stream.

@adrianhopebailie

This comment has been minimized.

Copy link
Member Author

@adrianhopebailie adrianhopebailie commented Oct 14, 2019

@marcoscaceres

Problem with CSP is that it's not on by default

What do you mean? Simply that the header would be required to be configured by a domain owner ?

You're suggesting that without the header set, that it should default to only allow payment pointers from the same origin?

@Malvoz

This comment was marked as outdated.

Copy link

@Malvoz Malvoz commented Oct 14, 2019

whatwg/html#2335 suggests that new <meta> features should be defined as attributes, rather than new values for the name attribute, e.g.:

<meta monetization="...">

instead of:

<meta name="monetization" content="...">
@adrianhopebailie

This comment has been minimized.

Copy link
Member Author

@adrianhopebailie adrianhopebailie commented Oct 15, 2019

@LonMcGregor

This issue seems to be mostly addressed by requiring a Secure Context (added to spec) and defining feature policy for this feature (see #28).

I think the use of CSP is a new issue, so I've opened #29.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants
You can’t perform that action at this time.