WM Provider's Access to Data

[adrianhopebailie]

@sharafian raised #2 with a number of editorial comments which speak to a fundamental discussion point for WM.

How much data should the WM Provider have access to in order to do a good job of deciding who it pays and how much?

The balance is between:

1. Giving the provider more data and allowing it to do a good job of adjusting the amount it pays different sites based on heuristics it gleans from the user's browsing activity
2. Limiting the data given to the provider to protect the user's privacy

More Data

On the one hand, the WM Provider is chosen by the user so it's possible that the user opts-in to share their browsing data with the provider.

This would mean that whenever the user visits a monetized site the browsers invokes the provider and shares the URL (maybe just origin?) of the site with the provider in doing so.

Less Data

On the other hand, the browser is the user's agent and the WM Provider is just another 3rd party service.

Whenever the user visits a monetized site the browser should invoke the provider and only share the Payment Pointer of the site (i.e. where to send the money).

Alternative 1

The User can classify sites (favourites) and the browser provides signals to the provider whether or now the site is a favourite.

This seems like a nice idea but likely to be VERY difficult to do well and places a lot of the burden on browsers. This also limits what the providers can do severely.

Alternative 2

The browser provides a "sandbox" for the provider to execute custom code that has access to more data but doesn't have network access so this can't be sent to the provider's servers. Instead there would be a "standardized" interface from this sandbox to the provider's code that CAN communicate with its servers. I.e. the sandboxed code could emit a numeric weighting to the non-sandboxed code that indicates how much to pay.

[justmoon]

I think this ticket is misleading because there is a huge difference between the WM Provider and the client-side WM implementation. We don't have a name for the latter, so I'm going to call it WM Agent for now.

To illustrate my point: I'm comfortable using Firefox which knows my entire browsing history. I would not be comfortable sharing my entire browsing history with Mozilla, the company that makes Firefox.

With Web Monetization it's the same thing. I'm fine with sharing browsing history with the WM Agent, so it can make intelligent decisions on how much to pay different sites. I'm not fine with sharing browsing history with the WM Provider.

In order to increase trust in the WM Agent, we could use the same techniques that we use to increase trust in browsers: We could recommend that the WM Agent be open-source and we could make sure that it's communication with the WM Provider appears in the network panel of the browser developer tools so it can be audited.

[adrianhopebailie]

Introducing the idea of a WM Agent is a good idea.

The current proposal, to ultimately leverage the Payment Handler API doesn't consider such a concept but I know a similar idea has been discussed in the past as a way to do a privacy-preserving "canMakePayments" call for on the Payment Request API.

If we extended the Payment Handler API to support this, what would that look like?

I would imagine something like when a service worker registers as a WM Agent per the Payment Handler API (i.e. it adds a listener for a new event we define in the PH API, called onMonetizationRequest for example) the handler is executed in a special context.

In that context we could do a number of things to try increase trust:

1. All network requests are logged to the console, or
2. Block network requests entirely and implement an SPSP/ILP client in the browser with a simple "payment" API exposed to the WM Agent code.
3. Other ideas?

@marcoscaceres, @rsolomakhin, @danyao any ideas from the browser perspective?

[rsolomakhin]

@adrianhopebailie : What do you think about the following:

1. Browser detects WM request on the website and shows the logo of the installed WM Agent somewhere in UI.
   1. The logo may be grayed out.
   2. Hovering over the logo or long-tapping it may bring up status information and a prompt to "Support this website."
2. If the user taps the WM Agent logo, browser hands over the origin of the visited website to WM Agent, which can then initiate payment to this website.

[adrianhopebailie]

@rsolomakhin we're distinctly trying to find a way to make this work without user interaction.

Our goal is to get the level of trust between the user and the WM Agent to a level that this is possible.

This obviously means we may need some extra steps during enrolment/registration?

[rsolomakhin]

@adrianhopebailie : It seems reasonable to me to ask the user the following in a permission prompt:

• Allow the WM Agent to know when you visit an enrolled domain (except in private browsing mode).
• Enabling this setting will show fewer ads on these domains. [ Block ] [ Allow ] _ View a list of enrolled domains.

What do you envision the WM Agent should do if the user clicked [ Block ]?

[adrianhopebailie]

What do you envision the WM Agent should do if the user clicked [ Block ]?

The WM Agent can still send payments to the site but it won't be able to adjust the rate based on what it knows about the site.

e.g. If the WM Agent knows it is sending money to a high profile news site it might increase the rate it sends vs what it would send an unknown blog. If it has no data it will just send at a standardized rate.

[rsolomakhin]

In that case, I guess the second sentence of the prompt should be changed to something that mentions fairness.

• Enabling this setting will enable WM Agent to reward the domain fairly.

[brucelawson]

I'm not sure it's a question of "fariness" - it's differentiation between Payment providers. Provider X might boost charity sites; Provider Y might boost small bloggers, for example.

[sharafian]

@adrianhopebailie @rsolomakhin

I don't think the WM Provider can safely function without the WM Agent's input on what it thinks of the site. For example, Coil won't pay gambling sites, because it's against our (and our payment processor's) Terms of Service. Same goes for adult content.

The ability to not pay certain sites is dependent on the WM Agent's functioning. So without the WM Agent, the WM Provider may be unable to safely pay any sites at all.

[adrianhopebailie]

@sharafian that's an interesting point.

Is the implication then that Web Monetization is basically impossible without the user's browsing data (because of the regulatory oversight that providers fall under)?

[rsolomakhin]

@sharafian : I assume that WM Providers have a whitelist of enrolled origins that they can double-check against a blacklist of gambling and adult content. WM Agent's input is only to help with adjusting the weights on the payouts to the enrolled origins. Is my assumption correct?

[sublimator]

@sharafian mentioned regulation issues aside (which sound important), I was thinking permissions should default to sharing as little info as possible.

Each request could show something like this:

[Always] would have a confirm prompt with information about the implications.

Where it says this request only, the browser would do the SPSP request[s], passing on only the SPSP response details. i.e. ILP account and shared secret details. That default privacy setting does sound like it could be at odds with regulatory compliance though?

You could progressively allow more and more agency to the WM Agent so that things are automated.

I guess something implied in the images above, while not really relevant to the discussion above is use of multiple providers concurrently. Is that something that could/should be supported ?

[adrianhopebailie]

@sublimator that assumes the user will need to be prompted every time they visit a new site unless they explicitly disable that?

When would this prompt appear (when the provider installs itself or when the user first visits a website)?

Assuming this pops up on each new site I'm assuming that users will simply switch to "Until I close the browser" the first few times and then eventually just do "Allow always".

[sublimator]

@sublimator that assumes the user will need to be prompted every time they visit a new site unless they explicitly disable that?

Right. "Opt in" to appease all the privacy zealots ?

[LonMcGregor]

"Opt in" to appease all the privacy zealots ?

That's me. One of the big things I absolutely hate about ads is the privacy implications of targeted advertising (is there any other kind nowadays?). For this to be adopted by people like me, that would almost be a requirement.

It would also be good so you don't accidentally support groups you would rather not should you accidentally visit one of their websites.

[sublimator]

@LonMcGregor Understood

[adrianhopebailie]

We did some early UI mock-ups which we discussed with @rsolomakhin and @danyao a while back.

Getting this balance right (consent vs low-friction) is not an easy task.

Based on what I am hearing so far, the push is for the default behaviour to differ from how Coil's extension works today.

i.e. I would have some icon or similar on my browser that is the Web Monetization indicator.

By default, clicking that icon shows me something like your UI above @sublimator.

If I visit a site that CAN be monetized but isn't the icon will indicate that I need to approve monetization (it will be red or something).

If I visit a site that CAN be monetized and I have approved it then it will be green.

If I visit a site that CAN'T be monetized it will just be grey.

Does that sound right? WDYT? @justmoon , this is quite a departure from goal of zero friction.

Maybe this is a good starting position?

Users can always explicitly allow monetization for all sites for a specific provider.

[sublimator]

this is quite a departure from goal of zero friction.

Not necessarily ?

We did some early UI mock-ups which we discussed with @rsolomakhin and @danyao a while back.

Could you share those here ?

Those mocks I posted are missing a persistent denial option, and indeed are quite obtrusive. Was pondering something similar to what you are talking about for a WM status bar. The point was to make everything opt-in with full privacy by default but with the ability to allow zero-friction.

[sublimator]

@justmoon @sharafian

What's the minimum you could get away with compliance wise? Is an address enough? It's all Coil currently gets now right if I am not mistaken? The SPSP endpoints are retrieved client side, and then the client creates a STREAM connection to coil, using the account and shared secret.

[sharafian]

@sharafian : I assume that WM Providers have a whitelist of enrolled origins that they can double-check against a blacklist of gambling and adult content. WM Agent's input is only to help with adjusting the weights on the payouts to the enrolled origins. Is my assumption correct?

@rsolomakhin We don't have a whitelist, the idea is to monetize any site that includes the Web Monetization meta tag.

If the WM Provider could see by origin that's enough to filter out blacklisted sites and do some basic adjustment of the payment rate (esp. if the WM provider sees payment pointer too). Coil's privacy model aims to be better than that, i.e. never sending out the origins that the user visits over the network and never telling Coil the payment pointer (only the ILP address which is largely anonymized). But that would be enough to basically do some blacklisting on the client side.

@justmoon @sharafian

What's the minimum you could get away with compliance wise? Is an address enough? It's all Coil currently gets now right if I am not mistaken? The SPSP endpoints are retrieved client side, and then the client creates a STREAM connection to coil, using the account and shared secret.

@sublimator In terms of legal compliance we could blacklist ILP address prefixes that allow OFAC users (basically blacklist any ILSP who isn't doing KYC properly).

As for enforcing our ToS we need to at least know site origin or payment pointer. Site URL is better but it's OK if it's not possible to have that. Basically the more we know about the site the more granularly we can blacklist content.

For instance, if you had https://contentsite.example/ and https://contentsite.example/adultcontent we would have to blacklist the whole site if origin is all we see. But if we saw full URL we could allow all the ToS-compliant content on https://contentsite.example/ and only blacklist the adult content portion.

i.e. I would have some icon or similar on my browser that is the Web Monetization indicator.

By default, clicking that icon shows me something like your UI above @sublimator.

If I visit a site that CAN be monetized but isn't the icon will indicate that I need to approve monetization (it will be red or something).

If I visit a site that CAN be monetized and I have approved it then it will be green.

If I visit a site that CAN'T be monetized it will just be grey.

@adrianhopebailie I think that 0 user interactions on the happy path of visiting a new web-monetized site and streaming money to them is extremely high priority.

The ability to turn it off is good, but if users have to opt into web monetization on the sites they visit then it doesn't solve its most basic goal. It would make web monetized sites less pleasant than non-web-monetized sites because they'd have to nag you to enable web monetization.

[LonMcGregor]

I think that 0 user interactions on the happy path of visiting a new web-monetized site and streaming money to them is extremely high priority. The ability to turn it off is good, but if users have to opt into web monetization on the sites they visit then it doesn't solve its most basic goal.

I suppose at the very first stage, where a user signs up to take part in monetization they could be presented with an option asking if they want to just auto enable for everything, or do it manually. Then that gives people a general choice before anything has even started - if it was default "on", that would still give privacy buffs a chance of taking control, and would make things frictionless.

This setting could then be remembered by the WM Agent when they first visit a monetizable site after signing up.

[adrianhopebailie]

I believe the Agent/Sender model addresses this issue nicely.

It is not yet clear what form the agent will take but the interaction with the sender is now such that it has no way of tracking the user's browsing history.

The only remaining question is whether the PaymentRequestEvents that are handled by the sender contain the origin of the website.

See #10 for further discussion