Announcement

Collapse
No announcement yet.

Mozilla's Route For Implementing W3C EME (HTML5 DRM)

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #51
    Originally posted by anda_skoa View Post
    The problem most people have with the current for of DRM is that is designed such that it cannot be implemented in FOSS software.
    Which has nothing do to at all with encryption.

    FOSS crypto software is routinely used to protect financial, diplomatic and military data and transmissions, because decades of cryptography research have shown that the protection does not come from the secrecy of the algorithm but from the difficulty of the mathematical problem and the secrecy of the encryption key.

    Yet, for whatever reason, protecting a media stream seems to require secret algorthms.
    DRM cannot rely on anything apart obfuscation. No amount of cryptography research will change this mathematical truth.

    A DRM component must be shipped with the decryption key, there's no way around it, as the content must be decrypted somehow. So how do you prevent the user from reading that key? You obfuscate your program. There is no other way. This requires shipping compiled binaries. If you ship the sources as well, it just makes it much easier for an attacker to locate where the key is stored in the binary, and how it is hidden.

    What you can do, is have a clear API, with the smallest possible surface. That is what Mozilla is doing. But you cannot have an open implementation of the blackbox inside.

    Comment


    • #52
      Awesome post about DRM by the way

      Comment


      • #53
        Originally posted by erendorn View Post
        DRM cannot rely on anything apart obfuscation. No amount of cryptography research will change this mathematical truth.

        A DRM component must be shipped with the decryption key, there's no way around it, as the content must be decrypted somehow. So how do you prevent the user from reading that key? You obfuscate your program. There is no other way. This requires shipping compiled binaries. If you ship the sources as well, it just makes it much easier for an attacker to locate where the key is stored in the binary, and how it is hidden.

        What you can do, is have a clear API, with the smallest possible surface. That is what Mozilla is doing. But you cannot have an open implementation of the blackbox inside.
        See, DRM is quite a special application of cryptography.

        Whereas cryptography is usually used to protect the user's data against attackers, DRM works the exactly opposite way: it protects the content against users. DRM is software whose inherent purpose is to be hostile towards the user and consider every user a potential threat.

        Of course, every DRM scheme will inevitably be broken, and become pointless - which makes DRM in general pointless from the start. But big content marketeers like to annoy users and piss away money, which means the users will suffer in the process.

        No wonder if people will rather torrent their stuff than buy them legitimately... at least when you pirate, you don't have to deal with user-hostile antifeatures like DRM...

        Comment


        • #54
          Originally posted by dee. View Post
          See, DRM is quite a special application of cryptography.

          Whereas cryptography is usually used to protect the user's data against attackers, DRM works the exactly opposite way: it protects the content against users. DRM is software whose inherent purpose is to be hostile towards the user and consider every user a potential threat.

          Of course, every DRM scheme will inevitably be broken, and become pointless - which makes DRM in general pointless from the start. But big content marketeers like to annoy users and piss away money, which means the users will suffer in the process.

          No wonder if people will rather torrent their stuff than buy them legitimately... at least when you pirate, you don't have to deal with user-hostile antifeatures like DRM...
          See my link above for why DRM exist. DRM is not there to prevent bit torrent piracy (there will always be one copy available for torrent), but to prevent sharing among friends, within a family, across your devices, etc... They will never acknowledge that of course, but it's the reason that makes DRM profitable regardless of torrents and pirates.

          As such, it doesn't have to be completely bulletproof, just hard enough for the average buyer.

          Comment


          • #55
            Originally posted by erendorn View Post
            DRM cannot rely on anything apart obfuscation.
            Exactly! Because it is not related to protecting the content at all. That could be handled via cryptography

            Originally posted by erendorn View Post
            No amount of cryptography research will change this mathematical truth.
            And that basically proves that DRM has nothing to do, at all, with protecting the content.
            Because doing that would be possible using crpytography, as widely demonstrated in areas which really require secret and secure data (e.g. finacial transactions, diplomatic or military communication).

            Originally posted by erendorn View Post
            A DRM component must be shipped with the decryption key, there's no way around it, as the content must be decrypted somehow.
            No.
            Decryption, as a use case of cryptography, does not require the key to be part of the software doing the decryption.
            When you do online banking, neither you nor your bank need to run a component created and shipped by the other. Yet each side is able to decrypt the data sent by the other party.

            But we have already established above that DRM has nothing to do with cryptography even if the narrative around it uses phrases that sounds like it does.

            You are of course free to believe in these fairly tales, no matter how much scientific evidence stands against them. Sometimes its just nice to switch of rational thinking and dive into a make-believe world.

            Cheers,
            _

            Comment


            • #56
              Originally posted by anda_skoa View Post
              You are of course free to believe in these fairly tales, no matter how much scientific evidence stands against them. Sometimes its just nice to switch of rational thinking and dive into a make-believe world.

              Cheers,
              _
              I don't really get how you can mostly paraphrase what I'm saying and then conclude with that.

              Anyway, DRM does use encryption. The data streamed by netflix, written on a bluray or passing through HDCP definitely is cyphertext and not just obfuscated data.
              The difference with online banking is that for DRM, the 2 users are "the content provider" and "the media player", while "the consumer" is the attacker. Obfuscation (by using compiled software or hardware parts as in DVD players or HDCP compliant parts) is used to prevent you, the attacker, from gaining access to the decryption key detained by the authorized media player.
              But it's still encryption all the way.

              Comment


              • #57
                EFF: Can This Web Be Saved? Mozilla Accepts DRM, and We All Lose

                It's official: the last holdout for the open web has fallen. Flanked on all sides by Google, Microsoft, Opera, and (it appears) Safari's support and promotion of the EME DRM-in-HTML standard, Mozilla is giving in to pressure from Hollywood, Netflix, et al, and will be implementing its own third-...


                It's official: the last holdout for the open web has fallen. Flanked on all sides by Google, Microsoft, Opera, and (it appears) Safari's support and promotion of the EME DRM-in-HTML standard, Mozilla is giving in to pressure from Hollywood, Netflix, et al, and will be implementing its own third-party version of DRM. It will be rolled out in Desktop Firefox later this year. Mozilla's CTO, Andreas Gal, says that Mozilla "has little choice." Mozilla's Chair, Mitchell Baker adds, "Mozilla cannot change the industry on DRM at this point."

                At EFF, we disagree. We've had over a decade of watching this ratchet at work, and we know where it can lead. Technologists implement DRM with great reticence, because they can see it's not a meaningful solution to anything but rather a font of endless problems. It doesn't prevent infringement, which continues regardless. Instead, it reduces the security of our devices, reduces user trust, makes finding and reporting of bugs legally risky, eliminates fair use rights, undermines competition, promotes secrecy, and circumvents open standards.

                It's clear from the tone of Gal and Baker's comments, and our own discussions with Mozilla, that you'll find no technologist there who is happy with this step. The fact that Mozilla, in opposition to its mission, had to prepare and design this feature in secret without being able to consult the developers and users who make up its community is an indication of how much of a contradiction DRM is in a pro-user open-source browser.

                Unchecked, that contradiction is only going to grow. Mozilla's DRM code, imported from Adobe as a closed-source binary, will sit in a cordoned sandbox, simultaneously Mozilla's responsibility but beyond its control. Mozilla will be responsible for updates to the DRM blackbox, which means users will have to navigate browser updates that will either fix security bugs or strip features from their video watching. Mozillians have already been warned of the danger of talking too much about how DRM works (and doesn't work), lest they trigger the provisions in the Digital Millennium Copyright Act (DMCA) that forbid "trafficking" in circumvention knowledge.

                Baker may think that Mozilla cannot change the industry on its own (despite it having done so many years ago). Sadly, it changes the industry by accepting DRM. It is these repeated compromises to the needs of DRM advocates by tech company after tech company that are changing the nature of personal computing, transforming it into a sector that is dominated by established interests and produces locked-down devices, monitored and managed by everyone but their users.

                Past experience has shown that standing up to DRM and calling it out does have an effect. As we have said to the W3C, and Cory Doctorow spells out to Mozilla in this Guardian article, we can do much more to fight the negative consequences of DRM than simply attempt to mitigate the damage of its adoption.

                We need to work to end the reinforcement of DRM and criminalization of fair use in the DMCA and similar legislation being spread throughout the world. We need to speak out about the failings of DRM, even if we fear that DRM proponents will just make it worse (in the name of "improvement") or take civil or criminal actions under the DMCA. We need to challenge the baseless assertion that users don't mind DRM as long as they can watch House of Cards and demand actual evidence to justify the damage it causes. And, given the amount of compromise we have already suffered, we need to spell out the principles that we won't compromise on.

                Mozilla and the W3C are both organizations with missions intended to defend and promote the open web. Both have now committed to a system of content control that is seen as a violation of those principles by many Internet users. We, and they, can change that story. We need to redirect the ingenuity being wasted on attempts to limit the damage of introducing DRM into the heart of the Web toward a positive campaign against further incursions.
                Mozilla is dying, Servo is not yet ready and Rust is a WIP language.

                Comment


                • #58
                  Originally posted by erendorn View Post
                  I don't really get how you can mostly paraphrase what I'm saying and then conclude with that.
                  You brought up some pieces from the narrative of the DRM fairy tale about it needing secret algorithm and key baked together for "Decryption".
                  So I concluded that you might like that fairy tale. Unless of course you had meant the fariy tale to be an obvious bad example of people not understanding cryptography and its requirements.

                  Originally posted by erendorn View Post
                  Anyway, DRM does use encryption. The data streamed by netflix, written on a bluray or passing through HDCP definitely is cyphertext and not just obfuscated data.
                  Yes, but its target it not to secure the data that is encrypted.
                  If the data, in this case the movie, would need to be protected, it would not be encrypted with a key of a middle man. Much like the channel between you and your bank is end-to-end and not from you to your provider and from the provider to the bank.

                  Originally posted by erendorn View Post
                  The difference with online banking is that for DRM, the 2 users are "the content provider" and "the media player", while "the consumer" is the attacker.
                  No, the recipient is the person watching the movie, on a PC most often the same person as "the consumer". "the media player" is a man in the middle, several steps away from the actual recipient.
                  If DRM were about protecting the content (as opposed to protecting involved corporate entities) then the content would be decrypted as close to the recipient as possible,
                  Currently most likely in the video hardware.

                  But that would counter one of the actual goal of DRM, to ensure that only selected entities can provide platforms for media consumption.
                  It would mean that any player on any operating system on that hardware could be used to provide the content, removing the incentive for all user end-point vendors to participate in the ruse.

                  The alledged need for software blackboxes is only a requirement for making these vendor play ball.
                  It is not, in any way, related to protecting the content from access by unauthorized parties.

                  Cheers,
                  _

                  Comment


                  • #59
                    Originally posted by smitty3268 View Post
                    There are only 4 browser companies that matter.

                    Microsoft, Apple, Google, and Mozilla.

                    Microsoft and Apple both command huge market leads in their markets (desktop and mobile, respectively) and completely control their entire OS.
                    What year is this? 2007? Apple is nowhere except leeching funds off of a few die hard hipsters, their market share is sitting down with RIM and WIMO. Android is 80-something percent.

                    Comment


                    • #60
                      Ok, so here come the important questions;

                      If the drm plugin spits out unencrypted content that you can actually watch (and copy, and upload, etc.), then why bother drm'ing it to begin with? See, what the plugin would become, is a magical library that anyone can use to decrypt drm'd crap into something useful, which contradicts the purpose of drm'ing it to begin with.

                      You need to log in to the "service" that is selling drm crippled data. That identifies you to them and authorizes your use of the content. The encrypted tunnel (ssl) ensures that the content is not intercepted and used by someone between you and the server. If the plugin strips the data of drm, then you end up with drm-free media in your hand. So why add the extra drm in that case? Makes absolutely no sense.

                      Which leads to this;
                      It isn't *going* to spit out unencrypted useful content. It MUST interface with something else that it believes can be trusted.... which obviously means NOT an open source video decoder, like crystalhd, radeon-UVD, or intel-VAAPI. No, what that means, is that this bloody useless plugin is only going to function if it is satisfied that it is talking to AMD/XVBA or NVIDIA/VDPAU binaries.

                      Comment

                      Working...
                      X