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 #5

Open
LonMcGregor opened this issue Aug 16, 2019 · 11 comments

Comments

@LonMcGregor
Copy link

commented Aug 16, 2019

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.

@brucelawson

This comment has been minimized.

Copy link
Collaborator

commented Aug 16, 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?

@marcoscaceres

This comment has been minimized.

Copy link
Collaborator

commented Aug 16, 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.

@LonMcGregor

This comment has been minimized.

Copy link
Author

commented Aug 16, 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.

@sharafian

This comment has been minimized.

Copy link
Collaborator

commented Aug 18, 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.

@brucelawson

This comment has been minimized.

Copy link
Collaborator

commented Aug 19, 2019

@justmoon

This comment has been minimized.

Copy link

commented Aug 20, 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.

@marcoscaceres

This comment has been minimized.

Copy link
Collaborator

commented Aug 21, 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?

@sublimator

This comment has been minimized.

Copy link
Collaborator

commented Aug 22, 2019

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

@sublimator

This comment has been minimized.

Copy link
Collaborator

commented Aug 22, 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?

@sublimator

This comment has been minimized.

Copy link
Collaborator

commented Aug 22, 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.

@Malvoz

This comment has been minimized.

Copy link

commented Sep 6, 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.

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