Requirements for DRM in HTML5 are a secret

Oooooh, that would be splendid…

My two favorite anagrams of Epinards Caramel are Sara Dream Pencil and Spaniard La Creme. Also DRM in HTML as a standard is a really stupid and unworkable idea doomed to fail. It will be implemented, but it will fail.

THat was beautiful.

This is amazing :slight_smile:

I chose that name somewhat at random, for my blog. There are recipes with spinach and caramel, even though I haven’t tried them.

I knew that ultimately, this is where BB would go.

Also, as manufacturing becomes increasingly localised, you get a $US 74.99 TV for sale in Manila, with no licensing or anything attached, no HDMI HDCP, no ETC, that simply plays locally broadcast stuff that isn’t protected, is entertaining, is relevant to the locale, and draws people to watch it simultaneously on live broadcast.

Like sports events have this effect - no-one loves seeing it after the fact.

I suspect and hope that Big Content is digging its own Big Grave.

It’ll come down to the money, and the entertainment value, and the ease of getting that entertainment.

1 Like

Yeah absolutely, to my mind it’s a forced solution, in other words it’s been made an issue in search of a solution that isn’t really necessary.

Studios, publishers interpret fair use incorrectly and they make assumptions based on their initial flawed implementations on an incorrect world view. So they assume everyone is a thief, they support this by pointing at the current system that is itself a warped bi-product of their thinking. By not making content available and at a fair price you are going to have more piracy. For consumers to be honest producers / distributers need to be so first:

1 Like

I think that I didn’t articulate my (intended) point terribly well: thanks to a combination of legal techniques(mostly ‘hook IP’, and DMCA-like legislation) and strong cryptography, it is now largely possible to separate secrecy from control in DRM systems.

With old-style pure obfuscation schemes, like @EpinardsCaramel mentioned, the secrecy is the (poor, but tedious to crack) defense. With the advent of cryptographic approaches, the only thing that needs to remain secret are the trusted signing keys of the relevant authority. As long as those remain a secret, the entire rest of the system can be publicly documented, even OSS, but if you don’t kiss the pinkie ring, and show that your implementation conforms to whatever restrictions (no-copy flags, image constraint tokens, etc.) are demanded, your build doesn’t get signed and you go nowhere. Even something like a TPM (while it isn’t OSS, because it’s hardware, is a fully documented widget, just one with signed keys baked into it. You are free to build your own; but good luck getting your self-signed TPM treated as valid by much of anybody).

This is the issue that really divides GPL2 (written before this approach hit the scene) from GPL3 (written largely as a reaction to ‘tivoization’ in all its various forms). GPL2 relied on the partly implicit, partly explicit, assumption that denying somebody the code was how you denied them the control. Tivoization gave us the ‘Oh, have your precious code, and best of luck finding something that will execute your binaries…’

It is true (whether explicitly by use of tamper-resistant hardware design, or just because modern consumer electronics are brutally tightly integrated and really small) that the hardware in closed systems tends to be resistant to modification; but, even given a perfectly tamper-proof set-top-box or the like, you could still re-implement the system on an open computer except that your implementation would lack the necessary cryptographic blessing.

‘OSS’ as in GPL3 is incompatible with DRM, because that’s the major change between GPL2 and GPL3; but ‘OSS’ as in basically anything aside from GPL3 is no impediment to DRM systems, so long as they are cryptographic rather than merely obfuscated.

Funny, I was thinking that too. :slight_smile:

I’m almost certain that web technology will include in the near future some sort of “user tracking API” via webcam. No one would want that, of course, until

No more passwords to remember ! The page remembers that it’s you !

.

For your convenience, this presentation/movie/game will pause when you are not in front of the screen !

Then of course, websites could make it mandatory. HTML5 already has the “PageVisibility API”, that allows a script to know if you have minimized the browser (or changed tabs). Officially, it’s to allow developers to put their app on hold while you don’t use them, but I’ve already seen a page which said “the advertisement before this video will not play if you hide the tab”.

Of course, this is an advertiser’s wet dream, to be able to force people to watch their ads (see also : “Black Mirror” episode “Fifteen Million Merits”).

… But of course, browsers can be modified to do whatever, the server can only ask for stuff.

The security of the commercial crypto systems that are worth using only relies on the secrecy of the cryptographic keys.

This is not the case with military systems which use secret algorithms and protocols. But the cost of doing that well is huge and you don’t add security unless you do it perfectly.

This is the debate that led to the slogan ‘security through obscurity’ being used. Unfortunately security does not reduce to slogans and a lot of bad security has resulted. I had a flame war with Dennis Richie about 25 years ago over the practice in UNIX of leaving the password file world readable, relying only on the one way encryption. Which was never a good plan but became a terrible one when CRACK appeared and people could brute force the password space. The fact that Robert Morris who had come up with the scheme was by then working for the NSA… The UNIX guys switched but the ideology lived on and stopped us fixing the problem on the Web.

So all the protocols and security standards for the Web and email are open and have been from the start. But the reason that it is practical to provide security to allow you to shop and bank online but not enforce copyright is rather different.

For online banking the customer has as much of an interest in protecting their security as their bank (well close). For copyright enforcement the customer is the potential attacker.

For online banking and such, breaking one account does not allow me to break all the rest. For copyright enforcement the attacker only needs to compromise one machine and they can extract every copyrighted item. Copyright enforcement is break once, run anywhere. I think Brian LaMacchia came up with that phrase, it was the first time I heard it at any rate.

1 Like

I don’t think it’s right to equate ‘HTML5’ with this dumb unworkable attempt to force dumb unworkable DRM into a standard of which most important implementations are open source. I don’t think it’s possible for anyone to have a ‘hammerlock on HTML5’ and the fact that Big Content don’t understand this or are in terrified denial of it is actually funny.

I just seriously doubt Google will be on board with locking down the source code of Chrome at the whim of the same bunch of arseholes who keep trying to sue YouTube.

Sure, but that’s when I make a hollowed out silicone mould of my head with a video camera replacing one of my eyes.

I like this game.

2 Likes

I see. I’m not an IT guy, just an observer, but it sounds like the Big They might get their way. If so, wouldn’t they two be more or less equal - or at least one of those Venn diagrams with the little amoeba inside the big amoeba? (Yea I suck at drawing circles too.)

In any event, my point was that they just might succeed in breaking HTML5. But the result wouldn’t be a billion broken computers; it would be everybody ditching HTML5. (Then again, we do keep on using Windows.)

Edit to note: Just explaining why there is a huge middle ground between “ditching HTML5” and not doing stupid things that are in the HTML5 standard. I essentially agree with what you are saying.

HTML doesn’t quite work that way. It’s a standard that individual browsers implement. Everyone agrees that they want <b> to make things bold, so MicroSoft and Mozilla and Google all design software that interprets that tag and makes the text inside bold.

If I wrote my own browser, I could decide I don’t like <b> and choose not to implement that portion of the standard. You would be right to say that my browser was non-compliant, but if I implemented every other HTML5 standard I would be more compliant than any other browser I know of right now.

Because each piece of software can take or leave any part of the standard, HTML can keep going even if parts of it don’t get widespread use. In fact, Mozilla has already promised never to implement the HTML5 DRM - the fact that this won’t work with Firefox is going to be a bug that just doesn’t get fixed.

This will then be countered, first, by a google glass type device, then a subcutaneous device, then a computer implanted directly into your brain.

:confounded:

Detection and defeat of hostile optical sensors is actually (in what should definitely not be taken as a bad sign, no sir) a problem that the DoD became interested in before Hollywood picked up the thread to try to defeat in-theater cammers.

During the first Gulf War, we deployed a couple of demo units of the AN/VLQ-7 Stingray, which is designed to detect lenses and then dazzle or destroy the sensors behind them with a laser pulse. There were…some concerns… about how well this approach agreed with Protocol IV (Blinding Laser Weapons) of the Convention on Certain Conventional Weapons, so the project has been largely on the back burner.

The ‘PirateEye’ system used in theaters skips the laser destructor; but uses similar techniques for lens detection, in order to swiftly locate cammers so that they can be removed or arrested.

1 Like

This topic was automatically closed after 5 days. New replies are no longer allowed.