Webpass | Hacker News Reader

Webpass

webpass.io

67 pointsfreitasm72 comments

Until services like this make their list of participating sites available, they strike me as amounting to a scam (regardless of how noble their intentions).

If they have no partners, they still collect money, but have no one to give it to at the end of the month, so they'll have to keep it.

I also have no desire for the entire subscription to go to a website I visit one time in a month because they're the only one participating. This is not necessarily a deal breaker, but I can't even make an informed decision without a list of participating sites.

If a subscriber doesn't visit any of our existing partners, then we don't pocket that money which was intended for websites. Instead, it's set aside as a fund for helping new websites to join, with a particular priority on those sites that our subscribers use the most.

It may not be so bad if all of a subscriber's money goes towards a single publisher. We measure rates in terms of RPM. In such a circumstance, that single publisher is receiving an excellent RPM, and that gives us a good argument for convincing new websites to join.

As you can imagine, there are many things on our to-do list -- but a list of participating sites seems to be frequently requested, so that needs to move up in priority.

A list of participating sites should be your absolute number 1 priority. Like, a call away.

It is what I buy on your page.

> If they have no partners, they still collect money, but have no one to give it to at the end of the month, so they'll have to keep it.

IANAL, but my suspicion is that the law of trusts will make this ugly, unless they write "we get to keep it" into their TOS.

My own approach is to levy a fixed percentage and only pay out to participating sites. Readability tried to do the whole accumulate-for-not-participants as a way to try and create dangling carrots for publishers.

It didn't work: it just tied up a bunch of cash, because finding out who to contact for a lot of websites is difficult. Add to that the relatively small amounts of cash held for a given website, spread across many sites, and it would've created a helluva mess.

Disclaimer: I'm working on a competing product.

Would you mind sharing the basic premise of your product. I'm also trying to create some partnerships for a similar product.

Well it's the same general premise everyone stumbles on when they think about the problem for more than a few minutes. I call it "microsubscription".

Pay a service a fixed monthly amount. That service follows you as you visit participating publishers. At the end of the month, the service divvies up your payment amongst publishers based on some kind of formula, typically proportional to visits, clicks, time-on-site etc.

As I said elsewhere, the major technical problem has typically been that it's very easy to attack such schemes at the browser or at the publisher in order to create "visit multiplication". The scheme I designed relies on each of three parties -- a browser, a publisher and an authentication server -- providing independent verification of a particular network transaction occurring. Lashings of crypto, essentially.

My first protocol design, the subject of an honours dissertation, was hilariously broken. My second design was a ground-up redesign and independently reviewed by a fairly decent cryptographer.

I generalised the design so that any application protocol with some kind of control channel could be fit into the model.

I intended to create a scheme where users could avoid ads, pay for sites they like, get an easy pass through paywalls, without cheating and without user trackability.

None of this solves the fact that there are non-technical considerations that will probably be far more influential on the final outcome, barring a dramatic uptick in fraudulent activity souring the pot for my competitors. Google can get around this with their existing talent and technology for sniffing out fraud. The rest of us must make do with better protocols.

> Google can get around this with their existing talent and technology for sniffing out fraud. The rest of us must make do with better protocols.

To defraud webpass etc, you need to be able to sign up as a creator, so if they're not interested in signing up the world (as most adtech players are), they can probably get pretty far just by partnering with reputable sites and forcing them to track and reveal which portions of their traffic is sourced vs organic.

At some point they'll probably want to sign up the entire web too, but by that point they should be large enough to warrant buying the tech from a 3rd party fraud verification provider or build their own in house.

I will say that, knowing what kind of fraud goes on in advertising, I am skeptical that a new protocol would do much besides adding an extra (static) hurdle for fraudsters.

You might have already considered it, but as a potential user I'd like to have the chance of adjusting the percentages at each billing period (month for example) to avoid rewarding sites that use tricks to increase page count or other metrics.

By default, percentages go to each visited site as determined automatically by your service.

I'd also like to veto certain publishers, to avoid giving them money when landing there from obscured redirections or by accident.

Of course, if I veto a site then I would not get privileged access to it. That's fine.

That might be at odds with your three-party verification scheme; this is just a suggestion in case it might be useful.

I hadn't considered adjusting percentages, but I had considered allowing people to complain about and/or exclude websites from payment (veto, in your term).

Otherwise my inclination is to stick to a formula, because you have to balance the interests of users and providers for a network effect to form.

I'm trying to do this too but I have a way in that doesn't involve too much capital... Maybe we should have a chat?

This is scary - you mean I pay you to track every website I visit and you transparently pay them to not show Ads?

It doesn't say who get's what data, which sites are involved and there is no way I'm installing their browser plugin! Oh dear!

Check out our privacy policy at https://webpass.io/privacy for a detailed explanation of what we do with your data. If there are any scenarios that aren't clearly explained that concern you, please let me know and I can have the policy updated.

Does your service block trackers as well as ads? It's not clear at all what exactly gets blocked.

Mind you, since the service acts as a tracker in its own right, people wanting to avoid being tracked are unlikely to use it in the first place...

I am the OP. I run a website that uses webpass.io. I am not posting a link to the site to avoid self-promotion but it should be easy enough to find.

With that said, here is MY implementation. Other publishers may do it differently.

Our site is a discussion forum. People can browse at will but only logged in users can post and reply to topics.

We run advertising with Google DFP. A few years back we started offering a subscription where users pay us a recurring fee and they have the option to turn ads on/off in their profile.

I myself thought of using a micro-payment service but I wanted something easy.

The way webpass works is by their add-on sending a unique token on every page request. If there's a token my code checks with their server if it's a valid token. If yes we then have two options:

- if you are not logged in then we completely remove the ad scripts BEFORE sending the page to the browser client.

- if you are logged in we treat your session as a subscriber session and will send or not the ad scripts based on your profile preferences. This means you can go to your profile page and turn ads on/off.

Using webpass made the experience better for our users because even those people who don't want to create another web profile and pay another subscription can still get to our site ad free.

Does it make sense now?

Uploading the list of installed browser extensions is unnecessary (you say so yourself in your Privacy Policy) and reveals a lot of information about the user.

I'm out.

You are right, this is not necessary, and we stopped recording this information a while ago. Sending this information should be an option that users can turn on or off at their leisure, if it happens at all. Our aim is to provide our users as much privacy, and control over their privacy, as we can, and this old design choice does not fit that aim.

The Firefox addon has never sent that information, and (though not recorded anyway) we'll be removing it from the Chrome extension and updating our privacy policy shortly.

At least here you are aware of what is going on, you're tracked for a reason and you have the possibility to stop it anytime.

The Internet as a whole is scary. Everyone tracks you. You are also tracked and profiled behind your ad-blocker. So no big[ger] deal...

> there is no way I'm installing their browser plugin

Plugins provide a sandbox which hostile publishers can't attack. It also helps that plugins get a much richer API to work with.

Disclaimer: I'm working on a competing product.

Which one? I've seen a few in this space... I thought I was being original :-D

Robojar. As I said elsewhere, I've been entirely too busy focusing on the core protocol design -- it was the subject of an honours dissertation and then a patent application.

Nobody's heard of it because I am still bad at thinking like a product person instead of an engineer.

I like Google Contributor more: you as a visitor participate in the ad bidding and win the ad space if your bid wins. The website gets exactly what he would get from your visit as before.

Too complicated for people to understand and their funds can get depleted very quickly. Also some websites run Google AdSense as an infill, so Google Contributor doesn't really deal with publishers that have a direct sold inventory first, AdSense second policy.

The webpass.io subscription service is a change from the standard consumer - publisher relationship. Instead of having to create and maintain subscriptions with different websites, consumers can subscribe to a single service and affiliated websites can check with the platform to confirm entitlement - thus eliminating friction.

Depending on how websites configure the service customers don't need to create local accounts to get benefits - unless of course sites require accounts for things such as posting comments in topics and articles, or using other non-subscriber's related services.

I am not involved with the service, except as being a publisher using the platform as an alternative to ad-based revenue/subscription model.

What is your website? Did you completely remove ads from it in favor of webpass.io?

I posted this reply to another question, but will repost here for your benefit: