[Proposal] HTML5 App DRM

Why?

1. Web applications that do processing client side can easily get ripped, and the barrier to piracy is very low.
2. No web standard exist to protect applications from piracy, or even attempt to resist it.
3. PWA’s that are expensive to build, maintain and cannot resist theft.
4. Encourage more people to build full fledged apps for HTML5, as chances of piracy are reduced.
5. Authors want to release HTML5 games on the web but cannot because no measures exist to resist piracy.
6. Reduce cheating in HTML5 games.
7. To move the web forward! More companies making software that can be used in the browser.
8. Since user agents compatible with WebGL and WASM are in excess of 73%, to effectively benefit from the fact that we can run code at near native speeds, more people need to develop for the web, which happens as DRM for HTML5 App helps them to resist piracy
9. Improved accessibility as solutions that exist currently to fulfil the gap are not standard.
10. Apps are OS/Browser neutral, and more cross platform support!
11. Easily distributing paid PWA’s, software and games on the web.

How?

• HTML5 App licensing API -> This API allows the user to be uniquely identified by the website to determine if he has paid for the app.
• Other API’s as needed.

High level overview of how it works:

1. Client loads the app.
2. App licensing API sends a non-modifiable unique device identifier to website’s license server.
3. Server checks to see if license is valid.
4. Encrypted app is downloaded.
5. CDM decrypts the app.
6. Page runs in a protected environment in which browser extensions, external software cannot modify or access, and its source code cannot be inspected.

We agree that the web should be open, but in some cases an open web is not possible. A closed source thing does not mean it should not be on the web. Where a high investment is required to make a product, we cannot safeguard the apps, or at-least try to resist piracy on the web. HTML5 App DRM allows us to release cross platform Apps that are operating system agnostic. This means the same app can run on Android, iOS, Windows, ChromeOS, OS X, and other operating system which support it.

We realize that DRM is something that will always have its flaws, but currently the web does not even attempt to resist piracy.

I don’t think this should be a device identifier, both to limit tracking and to enable cross-device use. Obviously, we shouldn’t have to rely on the identifier being “non-modifiable” anyhow by the user. Instead, it should be a cryptographic secret received upon payment.

I don’t think this should be a device identifier, both to limit tracking and to enable cross-device use.

In the case that license is only awarded per device and not per user, it will not work. Maybe different API’s for cross device recognition could exist?

What keeps a user from sending the same identifier from multiple devices?

Also, what if users move to a new device, is the license necessarily lost? They should at least be able to request migration, maybe blacklisting the old device…

Also, what if users move to a new device, is the license necessarily lost? They should at least be able to request migration, maybe blacklisting the old device…

Yes, there could be a standard for this, like the user could forget the old device, and move to new. But than he should not be able to change devices too often. 2 max device change per week or something to avoid device sharing abuse, as determined by the DRM system.

Another option without unique recognition could also exist, for people who want to distribute free games or apps, but avoid source code inspection to resist client side cheating.

In case DRM uniquely identifies the user, a request popup might be suitable to be shown. In case where is just runs in a protected manner without unique identification, no request popup needs to be shown to maintain UX.

Can we design a robust system for streaming web apps?

Can we design a robust system for streaming web apps?

No. The code runs client side, not server side. If it were streaming web app, it would already be possible. Latency would also be intolerable. We’re talking about completely client side code.

Edit: Since you modified your comment, I’m not sure if I understand what you mean. Please elaborate further.

Why doesn’t the current Encrypted Media Extension cover this use-case?

Let’s also not conflate HTML5 with the web as a whole. Nothing prevents HTML viewing. The DOM is always visible to the user, it’s literally what is displayed on their screens. So what you really want to protect is the scripting?

This is a very fuzzy area. What exactly should have privileged access on a client system? It’s my opinion that, within reason, what is sent down and executed I should be able to see and validate. If “HTML5 DRM” is added, what prevents a normal e-commerce site from using it to try and “increase their security” when in reality all it does is hide the client-side code?

Because it is not designed for this scenario.

This is a very fuzzy area. What exactly should have privileged access on a client system?

The browser’s DRM system has privileged access. The PWA runs in protected area, with same privileges that are provided by default by a browser of a regular web page. Just that extensions cannot interfere with the page and extensions cannot restrict access to any API’s, and running the app in a protected environment where source code is not visible and cannot be inspected.

what is sent down and executed I should be able to see and validate.

Or you can chose not to use PWA’s whose source you cannot inspect? This is already the case with apps, I cant see a reason why it should not be on the web.

what prevents a normal e-commerce site from using it to try and “increase their security”

Would that not be a good thing? With extensions having access to all webpages, any malicious activity can happen from their side. Banking and other critical things could take benefit because of the fact that there are lower risks of client side snooping. In the end it depends on how they implement it, but a standard guideline could be given.

This is very bad to me. First, it removes user control over what runs on their web. Some people have legitimate reasons for blocking some access. You’re now saying they no longer should have that choice because developers always know best? No. This isn’t right.

Second, what about the DOM should be privileged? It’s a document structure. There is nothing special there. If you feel your DOM is somehow special I think you’re overreaching on protecting your IP. Not to mention, there is going to be a way to bypass this client side focused protection. So in the end you aren’t stopping piracy from anyone who really wants to do it. Just like any DRM system known today.

On the note of normal sites and security… It would not be a good thing at all. Today any security minded person can open devtools and look at what is going on easily. That allows them to find and report problems. You’re now asking for them to specifically circumvent DRM to do the same thing. Which, breaches DMCA law. Adding yet another problem for them to worry about.

They openness of the web is one of the core attributes to it’s growth. You’re asking a system be added to closer things down. No, no, no. This is not a good idea. If you have IP you need to protect so heavily, perhaps software development at all isn’t for your company. Can you show any DRM that hasn’t been broken yet? Everything gets out in time. This is a huge disservice to the web and end users.

They openness of the web is one of the core attributes to it’s growth. You’re asking a system be added to closer things down. No, no, no. This is not a good idea. If you have IP you need to protect so heavily, perhaps software development at all isn’t for your company. Can you show any DRM that hasn’t been broken yet? Everything gets out in time. This is a huge disservice to the web and end users.

Not every thing can be open. This fact needs to be realized. If you want, you can decide not to use the closed source product. No one forces you to use a closed source product.

If you feel your DOM is somehow special I think you’re overreaching on protecting your IP. Not to mention, there is going to be a way to bypass this client side focused protection.

We realize that every DRM has its flaws. Using DRM helps at-least create a higher barrier to piracy. As important as the open web is, the open web is not supposed to dictate the means and terms on using the closed source software.

IF people are happy using walled garden apps, why not allow the browsers to do the same thing? Distributing closed source software on the open web means that it has to compete with open source. When every good app moves to the walled garden stores, and than the open web wont be able to compete.

On the note of normal sites and security… It would not be a good thing at all. Today any security minded person can open devtools and look at what is going on easily. That allows them to find and report problems.

When a software manufacturer specifically says that you should not be finding problems in their product, it means you should not. THEY dont need your help. They will fix it themselves, and if they dont, they go out of business.

If piracy is as convenient as using a product legitimately, most people are going to pirate.

We have come to this conclusion after thinking about this for long. If in the end the open web fails to provide the capabilities of native apps, higher investment will go towards native apps. The web is no longer on desktop anymore, and we are no longer in the 90’s. Why do apps like snapchat, instagram are in their app store, and not the open web? It is because the open web at the moment FAILS to provide the capabilities of native apps. As long as the open web fails to provide proper mechanism to protect the client side integrity of apps, it will not be able to compete with native apps. Before we start porting our product to the web, we have to make sure that we can remain competitive.

Yea, I’m positive Equifax was on top of fixing their security issues without any outside force acting upon them. That’s why they allowed over a hundred million people’s personally identifiable information out the door before going “oh crap, what have we done?” The fact is, companies can become “to big to fail”. We shouldn’t build systems that allow them to further hide away what they’re doing on the web.

Where does this come from? What data can you provide to support this claim? Pirating movies is super easy, yet the movie industry still has constant “record-breaking” releases. So clearly, this mis-information on piracy is still believed. I’d love to know where it is coming from and who conducted the research in what way.

The W3C specs put end users needs first, always. End users have the last say on what APIs sites are allowed to access and use when it comes to things that affect their privacy and security. Also what network requests are allowed to be made, and even if need be how things get styled. You’re now pushing for an addition that goes directly against that.

Native apps can’t have that kind of allowance, it simply isn’t in how things are built there. But the web is a far different beast. Native and Web are two different models, what works in ones best interest doesn’t necessarily work for the other. You’re going to need one very good case for why vendors should tell end-users they no longer have the API control they always have enjoyed. You can’t say “only good companies can use this DRM”, so where is the line drawn? What helps prevent an Equifax from using this kind of thing just to keep their front-ends hidden away while letting over a hundred million people’s info out?

Have either of these companies stated exactly why they don’t have full web versions? If so could you please link to the resources the companies have provided as to why?

The open web won’t succeed by becoming the half closed web.

I am curious who “we” is, but I’m also fine with pseudonymity, if that’s what you prefer.

I don’t see a benefit for users in this proposal. What I understand is that I, as a user, shall be restricted and have less control over my device. I also understood that you find it acceptable that this introduces new security and privacy risks for me. As a user, I don’t want this in my browser.

The fact that many people are willing to use walled garden apps besides the web does not imply that they welcome the open web to become like that as well.

The point is that this ability is already available in native apps. Would it not be more comfortable as a user to just open a page and load the web app rather than going back and forth between apps?

Also would it not be better if we do this? Less network affect of native apps means more power for the user of the web. Sure some apps may be closed source, but that is how they generate their revenue. There could be a permission prompt when DRM requires to uniquely identify you, and when it just requires secure operating environment, then there would not be a prompt.

Thanks for respecting that. We’ll open up when this gains traction by the vendors.

This entirely depends on your personal viewpoint and definition of “better” in this context. Is it better that we close the web off from security analysis? That same analysis which currently tends to find massive vulnerabilities which then get fixed so people’s data is more secure going forward.

Your’e asking that we:

• Make the web less secure for end-users
• Remove user-choice of what is allowed to execute when they visit a site/app. (The choice of “just don’t go there” isn’t applicable. The web functions differently then needing to knowingly install an app on your device.)
• Remove the ability for ideas to be shared to create a better web all around. Since people can’t just look at how a site does something if they wrap it in DRM.
• Violate one of the most fundamental principles of the web since it was created. That is that the web is open to all.

DRM like this only hurts the web as a whole. It only benefits organizations that believe hiding away what they do is the only way they can keep alive. When there has been no actual data to support that kind of claim in the first place.

Why should it be a priority for support to be added to destroy the web as we know it to support something that has yet to be proven? It has been repeatedly proven, if your price something competitively and make your product easy to access and pay for then people will pay for it. Regardless of DRM protections. In fact, DRM protections make some people not pay for anything just to spite those companies.

I think that the right approach here would be for the vendor to:

• create their own web browser or fork of an existing web browser
• add whatever proprietary extensions the company wants to add
• code their web app to use those extensions
• OR instead: create a browser extension / plugin implementing the DRM for the browsers desired so that users can install that into existing browsers if they want to do something so dumb.

If their users are willing to tolerate this, so be it.

But please, please, pretty please, leave this crap out of the web standards! It sounds absolutely terrifying.

You are basically allow web sites to run random code that you can’t inspect or have any visibility into the execution thereof on your computer. Every shady website out there would be running this DRMed crapware to obfuscate their shadiness.

Hey there!

I think this proposal is incredible, I myself create an open source app and closed source. So, I thinks the idea of having a drm is a “good idea”.

An interesting option to solve the drm problem, distribute your app only to customers. For example, when creating a marketplace store - you usually configure all the infrastructure part of an app, this is a good partial solution to avoid piracy since you are the one who deals with the infrastructure aspect and not the web itself - (this of course solves part of the piracy problem and not all of the piracy)

• and of course, that… there can always be a person who will charge cheap or free for a service or
• may do something similar already done or better
• or it may even do something similar open source too.

Not true. Paid subscriptions are part of many apps. Requirement to sign in as well. The private business logic which you do not want to expose has to run in truly guarder area which is under vendor( not a client code ) control. Once you have a code pushed to client it is by definition open. Does not matter on what phase during delivery it was encrypted. Whether it is a TLS on HTTPS or password in compressed archive.

Concluding, the JS/app code in browser can not be trusted and protected from exploiting by the environment owner. Standard is working around the app guarding against external threads.

This proposal is antithetical to the web. It would also make any site that uses it completely inaccessible, as voice control and screen reader tech relies on having access to the DOM.

Hey there

There are other options like having your own browser with proprietary extensions, or there is still the option of you just supporting the app. For example, if the web-app is open source, you can offer maintenance of features and plugins and extensions and then you receive donations to maintain the app. - (this of course solves part of the piracy problem and not all of the piracy too)