cleverjake

You are younger than NaN% of your 0 friends who agreed to share their birthdays with us.

It would be great to hear the problems you had building it

How is that comment relevant to this article?

http://www.youtube.com/watch?v=TEBMlXRjhZY for the lazy

Wouldn't that hash change if the title is changed by a mod?

This is hacker news. People hack to hack. I don't understand your question.

I still don't really understand what you are trying to say

>> There is an effort from various direction to kill off content viewer plugins like them, and the APIs that allow them to exist, and it appears it's going to succeed.

While I agree that there are people trying to kill off the need for plugins, I don't think anyone is killing off the APIs that allow for plugins - can you provide any example of this happening? (Outside of phones)

>>You're right that EME is meaningless one way or another so long as plugins exist

I never said that. Nor do I think that. My point is that EME is doing the same thing as other - long ago implemented - plugins, but with a lot less of a surface area of attack and more likely to be made up of better code.

>> it's essentially a new plugin architecture

agreed.

>>that solves none of the problems of the previous ones.

I don't believe that most people would list DRM-ablility as an issue with previous plugins. Could you elaborate what issues you are referring to?

>>It's a bad idea for the same reason plugins are.

I think that those plugins are bad because it gives flash/silverlight/java/anythingElse access to a lot of native APIs that most users are completely oblivious to. If anything, it removes most of the security issues shown in those plugin systems.

See https://news.ycombinator.com/item?id=5610833

Once someone supports EME, they would support anything written for EME. I don't believe there will be a way to 'grandfather' any old systems. That would require either a complete rewrite of the plugin in the browser, or a rewrite in an EME compatible code, in which case it will run anywhere EME exists.

secondly, isn't the situation you describe exactly the situation we have now with flash/silverlight? I can't play WMAs on my Mac, Flash on my Droid, or any other number of combinations.

ah! thanks for the clarification.

Their code won't have all of the power of flash and silverlight (ie my full user account on the computer). The worst case scenario is their algo's suck and I can decrypt their videos easier.

>>It isn't, that's why plugins are being killed off too. Could you explain? Also, what is the 'too' referring to? What is the original thing being killed off?

The gun rack that is EME is absolutely falling under category 2. There is no native encryption, but there will be soon. The W3C doesn't want to create an encryption scheme, but it wants to allow other people to supply it.

In my mind, having a way to stream hulu/netflix (sorry, I'm not sure if there is an aussie version of either service...) that doesn't require a plugin that gives the computer access to my harddrive is a pretty good thing. Not as good as plain old mp4/ogvs, but better than a plugin player.

>>The ability to download audio/video already exists in computers.

Thank you for clarifying. I wasn't sure what you meant.

>> It's a convenient way for EME supporters to ignore the real issues, but it's valid to talk about a technology's real world uses when discussing its validity.

To be clear, I am not a supporter. I don't want it in the browser either. However, I don't understand how it is a red herring. Everything that is being proposed in EME is already possible in Flash and Silverlight, and those features only exist in those plugins for the same reason. Neither of them need file encryption in order to work as a platform - it is a feature so that people that want to have encrypted/licensed material on the internet can do so. You can write applications without them. But yet no one seems to care about it. I am wondering why that is

>>A DRM API in HTML5 harms users by legitimizing and enabling restrictive technology under the banner of the free and open web, with all the practical harm (lack of control, reduced bargaining power, security issues) that loss of freedom entails.

In whose eyes does it legitimize it? Are you saying someone will be convinced that DRM is ok because it is in a web browser?

>>If the framework is no different from existing frameworks, why do we need it?

Because it is different. Native solutions are more likely to be faster and more secure than external plugins.

A guy in my office was logged in before it went live, but when it came back up the session had been cleared. So my guess would be no.

>>Focusing on minor issue (native plugin) while ignoring the major one (DRM) sounds strange.

I don't think it is a minor issue at all. My biggest complaint with flash has been the security vulnerabilities, and I trust Google/Mozilla with web encryption WAY more than I do Adobe. Can you explain why you consider it to be such a minor issue?

>>And in reality this whole EME thing won't even remove native DRM code. It just will hook it into JavaScript.

I'm not sure what you mean by 'in reality'. Thats it's entire purpose.

>>The risk caused by DRM won't get any less than it is already. I know? Who is arguing the opposite?

>> For one it's not a plugin framework, it's a DRM plugin framework;

A DRM plugin framework is by definition a plugin framework. I relly don't want DRM in html either, but I have a hard time finding logical arguments against it, and I don't see how this is a good one. If you could further your point, I would love to hear it.

>> Secondly its expressed intent is to take away functionality

Take away what functionality? The ability to download audio/video? Again, playing the devil's advocate, I would imagine a vast majority of the content that would be streamed using the DRM encodes would not be streamed using the video element currently - it would be streamed over flash/silverlight, etc (think netflix, hulu). If that is the case, what is it we are losing?

>> I'm not aware of any other instance where a web API is created to disable features of a user's computer

To be fair, this isn't. EME is just a way for people to create addons that leverage native encryption. The same is true of the current plugin system.

>>I'm sure we can rattle off more ways that it is different, but I'm not sure what you're looking for here. I am looking for logical reasons to say why adding EME hurts the open web so when I get into arguments I have better reasons other than 'I hate it'

To play to devils advocate - because that other unethical junk requires additional downloads and poses multiple security vulnerabilities. Right? Why wouldn't a sort of 'native plugin' be better in every sense of the word for the end user?

Honest question - why is having a framework that allows for others to provide some form of DRM different from any other plugin system that exists currently?

Former Costco employee here - nope. A lot of the point of the store is reselling large items to small companies. Not many families need gallon jugs of butter or 100lbs bags of rice, but tons of restaurants do.

That being said, the reselling is normally for people who do something with it (ie cook the food, print with the ink, etc), not turn around and sell the exact same product.

see https://news.ycombinator.com/item?id=5589206

On a recent Shop Talk Show episode, Chris Coyier mentions that he had a conversation with Jason Scott that archive.org has notes around saying that when person X passes away, they post file Y, because they are the only person that cares about the copyright of said file.

It seems that they are willing to skirt copyright information if no one is likely to challenge it.

And society is better for it.

Hey Eoin, Could you explain what benefit this may have over livereload itself?

no it doesn't? it is a common colloquialism.

No, by bytecode, I mean bytecode.

http://en.wikipedia.org/wiki/Bytecode

just because there is an html page being served doesn't mean you can access the control systems.

you're also assuming no one has done it - I have no idea wether or not someone has used shodan for malicious purposes, but that certainly doesn't mean it hasn't happened.

posting content is not the same as supplying content. cards are just meta tags that are used when twitter crawls the link that is posted.

its a card. its their own apis. the apis twitter have been killing are 3rd party access to content, not 3rd party supply of content.

Why would someone clone a repo if you can't push?