[Proposal] A non-modifiable unique id for the client device

I work for a major publisher alliance group. Our members recently been experimenting with a paywall since we are in a transition to completely moving away from Ads. We’re even going to drop support for Google’s AMP in near future because of this, as they control everything on the page.

We were considering making an app that unites all member publishers. The app is the last resort and we want to make make the content open to people with less friction. Some of our members have been doing trials on a web based metered paywall. It turned out to be successful for many of them.

There turns out to be a problem. There are no effective ways to enforce metered paywalls on the web. Users can simply circumvent them by opening the incognito/private browsing mode, clearing cookies/cache etc.

On Android there appears to be access to a standard property called deviceid, which is difficult to change.

This may not be the most appropriate way to address the problem on the web however, because user-extensions are often able to override what the API’s return.

As per my understanding, we need a standard built in DRM module to enforce a metered paywall. What the module would enforce is that we received the correct ID, and to apply adequate resistance to modification of this ID. In the end we know that anything that runs client side cannot be trusted. However as long as it works for >95% of the devices, it is considered to be good enough.

We had considered directly discussing with Google regarding this. However, since we don’t want to lock users on a specific browser, we thought it would be more appropriate to discuss this openly.

I’d like to clarify that we need a DEVICE id not a USER id. We should be able to get the same id irrespective of the account the user is logged in with on the browser profile

I realize the privacy concerns, but as long as there is one permission prompt for the first visit to the domain, that is enough. There should not be a need to click to agree the prompt again once the user has agreed for a particular domain name.

TL;DR: We need a unique device ID, whose integrity could be validated. aka: DRM

PS: Thanks to GDPR and other similar regulations, most of the members intend to move away from advertisement based revenue within the next 1-2 years. Cant be more happy as the Ad’s based model is not sustainable in the age of adblockers.

Edit: I’d like to add that statistically the people circumventing the paywalls were insignificant few months ago, but now we notice that many users are circumventing them to read the content.

Unique IDs have been discussed multiple times before. They are not happening. They allow for major privacy invasion of users of the web. Putting this behind a permission system is very difficult since the wording used needs to be concise yet also convey the serious weight that allowing that permission can allow.

An alternative paywall method could be specifying certain articles that your organization would like to be free. Then the others are paywalled. This way, it isn’t based on the user session/device but instead just their account having paid for access. It has it’s own set of drawbacks, but provides some surface area for people to get a taste of the content without payment and without introducing an API that can easily be used to invade privacy.

See this thread for a previous discussion.

How is conveying information difficult? When Google makes its users download an app, it does not even ask them properly before collecting the unique id. Same goes with Facebook.

If it does not happen, what will happen in the end is that we end up making our own browser with the said features. If 40% of the Alexa1000 make sure that users have to download a proprietary browser to read content from other websites I doubt people will still use Firefox or Chrome.

There is a need and a demand for this to happen.

Android apps are native. That’s a different thing than web applications. Web applications have a fundamentally different model for how users access them and execute their code.

Go ahead. Prove us wrong.

Or people will stop visiting those sits and find alternatives to go to. As stated before, please build your own browser and prove us wrong.

Could you explain which problem exactly you want to be solved and why a client ID is technically the only feasible option? Why not identify users with passwords/other login mechanisms similar to how they are used all over the web e.g. for webmail, social media sites or this website here, plus prevent users from logging in from multiple devices into the same account at the same time?

The problem we want to solve is leaky metered paywalls. i.e you can read only 10 articles a month, before being required to pay. The problem is that you can circumvent it by going to private browsing mode. Or if they make fake accounts, and virtually get unlimited trials. A device id is unique to the device. It does not cost much to make a fake account, but it does cost a lot to buy a new device.

Anyone could popup an extension that automatically generates fake email addresses to counter it. If it is DRM, we know that an extension wont be able to do it, or person wont be able to manually get a disposable email address and fool us. Making this more difficult and expensive is what we want. Make prices reasonable like $20 a month that gives you access for all 2000 websites, and making it more time consuming to circumvent that.

The only other way we have is forcing users to enter credit card details for one centralized account, that controls payments to all of our members. This way they have to enter card details once, and we can do it. They have decided not to use OAuth provided by Google which goes against our interests. The credit card verification way is way more intrusive to privacy. Internal talks are currently underway, we’ll see where it goes. If this gets rejected by the web community, than centralized credit card verification, controlled by the group is that way is where we will be heading for.

We also expect less people to be reading if we require card verification, but that it also means they are more likely to pay.

I just looked into the Android Device ID more. It also is capable of being changed. All a user needs to do is make another user on the device, and that user would gets it’s own ID. Or a factory reset on a device will change it for devices going forward with 8.0+.

So if users are driven to not pay for your content, they still can bypass it on native if the device id is how you do the check for free content access on those devices.

Still, native has different inherit concerns from the web. So while this doesn’t mean we should do it anyways, it does show even the native “device specific ID for life” idea is flawed since it has easily accessible ways of generating a new one.

I realize that. But how many mom and dads do you this will reset devices?

Changing the deviceid is far more annoying. This means only the people who don’t have money and their time is not valuable will circumvent it, and they are not our target audience. Blocking 90% of the people who happen to circumvent just by pressing Ctrl + N or Ctrl + P is what we want and device id serves sufficient resistance to that.

What I meant is that deviceid api is the standard way of doing it on native. There are many other alternate ways on native, but device id is standard and we want a simple solution, which is good enough for our use case.

We have thought of metering by ip addresses too, but they are too prone to change and therefore the paywalls can easily be circumvented.

Our primary use case for this is to make it annoying to circumvent the paywall.

Edit: made some edits for further clarification.

A unique fingerprint to track users isn’t happening. It is too invasive to end users. Privacy on the web is extremely important.

There either needs to be an alternative method that can be provided openly that doesn’t invade privacy or the paywall scheme needs to be modified.

If your goal is to make something annoying then that smells to me like you need to rethink what you’re doing. There are ways to handle paywalls in alternative ways where they can’t be circumvented by clearing a session and don’t require anything new in the web platform. It just primarily means specifically deciding what articles are public vs letting any given X visits be public.

Instead of annoying users by having a weird system in place of X visits open and after that each month you pay. Make it so users know very clearly what is free content and what is behind the paywall. Far more user friendly and more difficult to bypass.

From your sentiment, it feels that the web is not very friendly towards alternate to advertisements as a medium of funding.

Annoying in a sense that it becomes a hassle to pirate or bypass the measures employed. Why would anyone pay for something if they can get it for free. We don’t live in some kind of utopia where everyone volunteers to pay money.

It’s called a trial. There is no way to properly enforce a trialware on the web, and that is a problem. We want to move away from ads since everyone hates them. Giving them access to anything but limiting the access to a number of times is also a business model. Just because you don’t understand it does not mean that it is weird.

We want to move away from ads since everyone hates them.

People hate annoying ads and too many ads and irrelevant ads. But they don’t generally hate ads altogether - the classified section of a newspaper is fine for example, and so are occasional full-page or half- page ads in the same print newspaper.

Ironically, the use of ad blockers and business models where people pay to have an ad-free experience have meant more sites have more and more ads, even though the most effective advertising uses fewer ads rather than more, in most cases.

Giving them access to anything but limiting the access to a number of times is also a business model.

The Web is better at some business models than others. We have a Business Group at W3C for improving Web advertising, looking at alternatives.

The problem isn’t even personalised ads so much as out-of-control tracking and privacy invasions, although the tracked ads can get creepy at times.

There are upcoming ways for people to log in to Web sites that are more secure, and to be able to start a free trial in a more secure way, but you can’t really stop people from copying content and still have the content be accessible. You can use steganography to personalize the content and work out who copied it, of course.

I agree that from a privacy perspective, getting a unique device ID seems… invasive. Maybe you can explore alternatives with some of the work the Web Payments WG is doing, to get user to give you their credentials.

/cc @marcosc

It was not my intent to mean it was misunderstood to me personally. I meant it is weird to multiple users I have met who come across it who aren’t technically minded.

Anyways, another hole in the client id desire is, incognito would still bypass it. So would alternate user profiles in the same browser instance. Browsers, if this were to be added, would make sure that private modes are just that, and they’d get their own generated ID on each instance creation. So the very type of thing that is being requested is still bypassed in the same manner the current session states are.

Seems fine to me. But then we should be able to know if they are in incognito to block them. Our desire is to meter the paywall, effectively. Getting the client id that is different in incognito is not very useful, it is just the equivalent of local storage and cookie, which is as useless for this use case.

This then invades user privacy in another way. The point of incognito is a user has fresh sessions cleared on exit and the places they are visiting don’t have a way of knowing they are in that mode.

You’re also thinking incognito is the only way to do this, that is false. Chrome and Firefox both support multiple profiles which are easy to make and destroy. Not as directly simple as incognito but still fairly seamless to anyone wanting to use the incognito trick to move to doing that.

I think you’re trying to attack symptoms to patch the problem instead of working on the root cause. The root issue is the paywall scheme doesn’t function in a way that works with the web technology while keeping user privacy. Perhaps roll back and look at the paywall foundation (as brought up previously in this thread) and change the mechanics of how it works to protect user privacy, provide a more consistent experience, and work with existing web tech. It’s entirely doable, it is a business decision on working with the flow of the tech and users or against them.

It is not a privacy abusing decision if they get a permission prompt to give it up. The web does realize how detrimental it is to its future, if every legitimate website starts requiring credit card verification. At least with device ID you don’t give up other personal details. Just because Google decided to invade users privacy by targeted ads and using their data for the AI and other business purposes does not mean the rest of the internet is happy with the ecosystem.

A way to properly enforce a trial on the web is now necessary. Otherwise it is only a bit more time consuming for us to get everyone on board and verify by credit cards. Obviously we will be much more happier with the standard device ID.

If this is not very suitable for the web, than other ways that work in incognito mode to enforce a trial are necessary. A web browser designed to offer premium content and trials is probably the need of the day.

Respectfully, there is zero chance browsers are going to give you a device ID (it’s a non-starter, don’t even ask for it).

What you could get, however, is perhaps a negotiated, revokable token. This token would be origin bound, and under the user’s control. With the token, you could use it as a credential to check with the browser if it’s the same user - but only for as long as the user allows you to. Once they clear user data, the token is no longer valid - not much different to a setting a cookie value, really.

The token would be different in private browsing and in different profiles. That’s by design, sorry.

Alternatively, as @Garbee has argued, you could consider a different business model. The tradeoff is shareability of content and putting things behind a paywall. Yes: It’s a hard problem, and a race to the bottom, where people will go to where they can get quality content for the least cost.

Now, with the Payment Request/Payment Handler API, it could be possible to develop an extremely low friction way for users to purchase content on the web. Given a Payment Handler (let’s call it “publisher-pay”), you could show the lede and then have a “Read this for PP#1” (where 1 PP might be, say USD0.10). The click would then send you a token to redeem the funds when the user clicks to read the story.

The “major publisher alliance group” you work for could instead focus on building that system (which could be secure, potentially anonymous, and fraud proof by design), instead of trying to circumvent the web’s privacy assurances.

I think the requirement could be posed in a different way that is not privacy-invasive. You should also build on the previous work on distinctive identifiers in the Encrypted Media Extensions, where we extensively discuss the privacy implications, user consent requirements and restrictions on identifiers (non-permanent, origin-specific etc.)

First, “free trials” of paid services are very popular with users (we have extensive quant and qual data to back this up). A free trial enables a user to obtain a thorough understanding of the product before making a purchase decision. It is very different from a “free sample” model, where the user sees only a selected part of the product and thus has far less information about the product.

Second, if it is very easy to obtain many “free trials”, enough users will abuse the service this way that it is business-impacting. There may also be automated fraud based on reselling of the illegitimately obtained free trials.

In the physical world, it is common that a person must show identification to access certain services (opening a bank account, for example) and thus it is valuable that there exist reliable ways to prove identity (typically government-sponsored). However, it is rare, indeed scandalous, that it is suggested that people be tattooed with permanent identifiers.

What is needed for the free trail model is something less than proof of real-world identity, but some kind of identity should be made available to the user that they can use - should they choose to - to redeem the one-off offer of a free trial from a service provider.

This identity does not need to be the same across different service providers (origins) and so it should not be.

It is a tricky requirement, though, because the action of providing such an identity is in some sense irrevocable (you can never again provide this identity to the same provider ‘for the first time’ - indeed this is the point). This notion is well understood by users in respect of physical world identity, but not online.

A second tricky issue is that we have no reliable way on the web for a user to know that the recipient of the identity will abide by any particular data protection rules, for example time-limited storage of this personal data and the right for the user to view it. Europe’s recent regulations (GDPR) might eventually help us here.

@Mark_Watson is conveying the message in the right manner. The user should be able to give up his or her identity permanently by choice in return for a free trial for the specific origin.

If it is easy to circumvent the means to enforce the trials (i.e: cookies) they impact revenue and the business model.

A permission prompt that says ‘Permanently give up your identity to example.com’ would be enough to let the user realize that they are giving up identity. Should they agree, we can allow them a time trial to the website/app/anything in future to explore the features.

GDPR certainly helps, and we hope it comes to the U.S. very soon.

Right now the only somewhat proper way to enforce trials on the web is credit card verification.If a webbrowser allows this, it will help a lot to trial software on the internet, without giving your credit card number.

Sooner or later, this will be in the web platform due to need. Any website/webapp could tell the user to give the card number or otherwise download a different browser that allows deviceid access to trial the software.

We are going to start working to develop a POC. The community here in the meanwhile could decide if it wants a seamless experience, or make it hard for user to test content before buying on the web.