search

adrianhopebailie / web-monetization

Web Monetization Explainer and Specification for submission to the WICG
Other
18 stars 3 forks source link

Legitimate Meta Tags #5

Closed LonMcGregor closed 4 years ago

LonMcGregor commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

"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 commented 4 years ago

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 commented 4 years ago

I've added some wording regarding HTTPS to https://github.com/adrianhopebailie/web-monetization/blob/master/explainer.md#add-meta-tag-to-website-header

justmoon commented 4 years ago

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 commented 4 years ago

@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 commented 4 years ago

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

sublimator commented 4 years ago

@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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

Kamino closed and cloned this issue to interledger/webmonetization.org