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


What defines the “identity” here? Depending on what is included here, it could reveal your identity or just the browser instance a user is on.

On @Mark_Watson’s point that an ID could be per-origin. That still doesn’t cover alternate user profiles in a browser or incognito mode. These would still provide alternative IDs to the same origin. Bypassing the “trial mode” you wish to enforce. So, given the context of what you want, even unique-per-origin IDs still fail to give you what you desire.

This is simply false. Trial systems have been around on the web for a very long time. I even described twice now in this thread how one can be built for publishers. But, that seems to be completely ignored as a thought since this publisher group is so dead focused on needing to invade user privacy to handle this case that they aren’t open to considering other options. Yes, it means rethinking how your free-trial is provided. However, with that, you’d work with the web instead of against it while also protecting user privacy.


Why does the web not allow to volunteer to giving up privacy?

I misunderstood it then.

But he also says:

and he also says

because the action of providing such an identity is in some sense irrevocable

If it is irrevocable, it means it should be the same in incognito/private mode. DRM works in incognito, this should work too. If not, than a standard way for websites must be given to block incognito mode users.

The hardware ID’s or the anrdoid device id. This could be generated by hashing the macaddress + android device id. In more secure cases the DRM ensures the integrity, and the OS provides the information directly to the DRM module. Sure they can be spoofed, but it is much more time consuming to spoof them. If you allow the user to click one single button and start over the trial, this is a loophole.

What you are calling a trial is actually free sample model. A time trial or page view limit based trial is the need. Your described twice reply does not cover all the use cases. Stop being so rigid.


In order to be effective for the use-case, the identity would need to be tied to something not easily changed and so would need to be the same across user profiles. Maybe it is disabled altogether in incognito mode as fundamentally incompatible with the objectives of that mode. And I am assuming it is never provided automatically, only on user request and after informing the user about what that means. That last point is possibly the most intractable here.

Please read my post again more carefully. I did not ignore your point. I described the difference between free trial and free sample. They have very different properties and are not interchangeable.


You called it a trial yourself. I did quote the exact part where you said that.

Since we’re talking about trial vs sample though…

Trial systems often are also a restricted portion of the product. Either in features available or the amount you can use it. I get the feeling a distinction is trying to be made but it doesn’t quite pan out.

The difference I’m seeing is, in a “Trial” system the site/software operator determines what the user can see and do. In the “Sample” system the user decides in some way what they see and do. Which, once you put the power in the users hands, they can find ways of abusing it unless you’ve specifically authenticated them individually.

Standards do not decide this. Incognito/Private modes should have full API access as any other browser instance. The only difference is that users expect what happens in that to not stick around once they close it out.

So, here’s a scenario. One household with two individual users. They have one shared machine in the home, let’s say a Chromebook device with multiple user accounts. User 1 visits and views four articles. Then User 2 visits and uses up the rest during their session. In this scenario, User 1 (who is their own individual person) has their “sample” for the time-span reduced because of User 2. Same device, different profiles, but because this “device ID” for authentication is used, they both hinder each others usage of the sample that both should receive individually.

The web works by putting users first, always. If we can find a way to help this business model that doesn’t hinder users privacy, security, or accessibility then it’s worth looking into. These solutions however are anti-user and shouldn’t be done:

  • Some persistent identifier across all profiles and/or origins. With or without permission in advance, this system is too dangerous.
  • Ability to block or detect incognito users outright. (Some sites do try to take advantage of users based on their previous history. This allows them to try and force users into higher prices or detrimental situations.)


That is not how it works. Standards can and should change with time and need. What worked for the web of the past does not mean it’ll work for the web of tomorrow. Web has already failed on mobile because of being behind in many of the thing native apps provide. Walled gardens exist because there is a need and people like the convenience of them. Your ideology seems to be very niche, and only is good for the 2% early adopters on the internet. There needs to be real changes. The open web would not have EME and DRM. But it DID. The EFF cried and failed. Be a realist. Your privacy concerns have a business cost. If we decide to move away, we’ll see how your very niche web survives.

Remember, Quora sends visitors to native app. Reddit sends visitors to native app. Youtube sends visitors to native app or atleast prefers that. Instagram sends visitors to native app. Facebook sends visitors to native app.

Why is this that most of the largest websites in the world prefer native apps instead of the open web where people can move here and there with a single click of a button? The web browser failed to provide sufficient things to enable a profitable business, except for Google. The way you approach things, many businesses would go bankrupt. Just because you like privacy does not mean someone else might not want to leave it in exchange for free high-quality content.

Get out of your bias, Garbee. You should not be deciding who volunteers to gives up privacy and who does not.


I have stayed out of this conversation, as it’s already been thoroughly discussed before. I feel it’s necessary to jump in here with a reminder to stay respectful. Technical arguments are preferred; alleging bias, trashing organizations, and implying privacy is something of the past is simply unacceptable.


And businesses should not come in and expect their every wish to be carried out without question and unopposed. These discussions exist to try and get as much input as possible. The web has a set of core values and privacy is one of them.

I could care less about my personal privacy in general. I’m trying to bring a viewpoint on privacy to these discussions for the many millions of people who don’t understand whats going on. We know users don’t read most permissions, or EULA’s, or Privacy Policies, etc. So, whatever is done in this regard needs to keep that kind of thing in mind. It isn’t about “consent” it is about “informed consent”. A permission provided by a browser, in this context, doesn’t do enough justice to provide informed consent.

Of course they do. If businesses got whatever they wanted then people would have no privacy ever. It is a trade-off. And the web has traditionally always put users first before all else. Users and data on what they want and need drive change here. In recent years we have seen nothing except people being afraid, confused, and denouncing tracking behaviors. Now you’re asking us to accept putting in a method that allows this to an even deeper extent? How does that make any sense for users?


Other way around. By “trial” I mean the user can “try out” the entire product (at least substantially) and therefore choose from all the content available. By “sample” I mean the service provider determines a subset of the product that will be available unpaid.

Yes, as you say, unpaid usage of the entire product needs to be limited somehow. In Netflix’s case, it’s a time limit (one month) and to avoid fraud we need to be able to detect when the same user comes back again.

The granularity of the “free trial” offer is up to the service provider. A “one per person” free trial would indeed be hard to implement rigorously as indeed would a “one per household” or probably any other strictly defined granularity. In practice, you have to rely on approximations and deal with any corner cases through customer service.

As I mentioned, we have strong evidence that users like free trials. Indeed they demonstrate a willingness to give up some privacy to access them (we ask for a method of payment). There is nothing wrong with offering users the choice to exchange some privacy for something of value, but as you say we must appreciate that consent must be informed and this is difficult to achieve with ‘virtual’ things like identifiers. I want to be clear that I’m not minimizing this point.

To be very clear, I am not advocating provision of a permanent identifier to arbitrary websites, even origin-specific ones with user consent.

And I agree about incognito mode. A site can obviously detect whether any provided identifier is present or not, but cannot detect why.

What I am saying is:

  • Free trail models (as distinct from free samples) are a valid use-case and popular with users
  • Such models depend on preventing (or reducing) abuse, implying a need for at least proof-of-posession of something scarce-per-user, not easily renewed
  • It’s common IRL for users to be provided with a way to exchange some privacy for things of value. The web should not force such exchanges on users but it should not prohibit them either.

I’m not offering a solution and have pointed out problems with the original proposal, but restated as above I believe this problem is worthy of study and should not be dismissed.


For what it’s worth, free “samples” do also work pretty well in practice if the “samples” are large enough. (If they try it, use it for a while, and find it’s almost perfect, but that paid version has exactly what they need, they’ll convert. :wink:)

However, I still don’t think you need a special client ID just for this. You just need the user to log in (as necessary) to confirm they’ve paid.

And I agree about incognito mode. A site can obviously detect whether any provided identifier is present or not, but cannot detect why.

For a while, it used to be possible to detect a browser in private/incognito mode, since you had various things leaking like no localStorage, no indexedDB, etc. Here’s a few hacks:

In general, there’s no good reason to try to detect it, but it still remains possible to do so directly (due to browser stupidity).


Since you bring GDPR, European privacy regulations won’t allow you to store any user-related identifier permanently, regardless of how you compute it. Users have the right to revoke them at any time, and you have to clear all traces from your system when that happens. So even if such an ID was trustworthy, when the user tells you to forget about it (exercising their rights), they can start from scratch with a fresh trial.

Even if such an ID was implemented, browsers would have to offer the user the option to reset that ID, or produce a new one when going in privacy mode (incognito) because that’s the whole point of the privacy mode. Even if it is really inconvenient to do that, someone will write a browser extension that does that on a click of the mouse.

Many users use ad blockers not for the ads, but for the privacy. Ad blockers nowadays have much more code to protect privacy (block beacons, pixels, etc) than to block ads, because users are genuinely concerned about privacy. Grandmothers who don’t know what an ID is or how to install an extension to fake it, also don’t know what an ad blocker is. Ad blockers would be the first extensions to fake that ID or make it unreliable.

My naive recommendation: Go with ads for non signed-in users. Go with free trial for signed-in users. Have account creation abuse detection in place, which also benefits other use cases besides free trial abuse.


I’m not sure I see a way where the particular requirement can be implemented that isn’t extremely likely to be privacy invasive. The EME spec’s privacy section is indeed a great resource; User Tracking describes a specific set of privacy threats that would include the proposed functionality, exposing an identifier (either to an origin or across origins) that could not subsequently be cleared at the same time as other data. A Key System that violated some of those requirements (or took advantage of some “should”/“may” requirements) might be able to implement the irrevocable free trial or permanent revelation of identity. The EME spec provides some mitigations that user agents can apply, including clearing stored data, limiting access to the top-level browsing context, user consent and blacklisting of key systems.

There is general skepticism about giving users the opportunity to volunteer for irrevocable actions. Reasons for that skepticism are not limited to but do include: lack of clear understanding of the implications of an action (“permanently reveal your identity to example.com” could be interpreted in many different ways, and users might not realize, for example, that doing so could mean that the permanent identifier is used across multiple websites rather than just example.com); consent without the user realizing it (maybe I just clicked “okay” without noticing, or someone else borrowing my device clicked “okay”, or I bought a used laptop and the previous owner clicked “okay”, or my cat jumped on the keyboard and clicked “okay”, or…); the possibility of user’s changing their mind.