Announcement

Collapse
No announcement yet.

Cisco Open-Sources H.264 Codec, Pushes WebRTC

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

  • #46
    NSA backdoor, really?
    In a video codec?

    Get back on earth...
    The codec cannot have access (because you can sandbox it and/or measure what access it is asking for, and compare it to the source) to:
    - network
    - files on your computer
    - user and kernel land programs of your computer

    What do you think it can do without that?
    Even if you put a "video signal acitvator" (lol), what then? the codec can only communicate with your graphic card (or maybe even just a memory buffer). So it can display pre-recorded NSA message to your screen! yay!

    Guys, seriously. Stop that.

    Comment


    • #47
      "pushes WebRTC"?

      Yeah, it pushes it backwards. It was already decided by IETF that it would use VP8. Cisco just wants to make sure a proprietary standard remains the monopoly.

      And make no mistake, just because they released it under BSD, doesn't mean it's "open source". It's a binary blob you can't modify, otherwise you will not be exempt from paying for it.

      I see this as a major step backwards, and Mozilla is selling its soul to the devil, effectively. Because of this "short term" deal to adopt h.264, and reject VP8, they'll have a lot harder time to push Daala in the future.

      Granted, a big part of the blame is Google's too, who said they would stop supporting h.264 like 2 years, ago, and then bailed on Mozilla, and kept supporting it. Google will come to regret that decision, because this could mean now that the future of VP is dead.

      They MIGHT be able get back in the game with Mozilla's Daala, if they demand all Android OEM's to support it as soon as it's available, and only if Daala is like 4x better than h.264, and 2x better than h.265, and arrives early enough (2015). Anything less than that, and codec stakeholders might not give a damn about switching from h.265, when they've just started switching to it a year earlier.

      But now I'm really worried even Daala won't see big adoption anymore, if everyone starts thinking "MPEG-LA won, and the codec war is over".

      Big screwups from both Google and Mozilla here.
      Last edited by Krysto; 10-31-2013, 06:18 AM.

      Comment


      • #48
        Originally posted by phoronix View Post
        Phoronix: Cisco Open-Sources H.264 Codec, Pushes WebRTC
        https://blog.mozilla.org/blog/2013/1...s-h-264-codec/

        We are grateful for Cisco’s contribution, and we will add support for Cisco’s OpenH.264 binary modules to Firefox soon.
        That is misleading journalism, mildly speaking. Cisco will provide their own blob, that would be covered by licensing. They build and distribute that plugin, and other implementations are not covered by it. It might even be opensource, but if it doesn't come from cisco in binary form, it's not protected by license.

        And, if at some point cisco stops renewing their license - poof. I liked it more when firefox relied on external codec frameworks, that was more flexible.
        Last edited by yoshi314; 10-31-2013, 06:57 AM.

        Comment


        • #49
          Originally posted by smitty3268 View Post
          Sigh... I really shouldn't get involved in these conversations because it always devolves into idiocy. All i'm asking for is a little common sense. In a list of applications the NSA could target, a codec would rank about 1 millionth out of about a million apps. It makes zero sense, because there are literally thousands of easier targets. The NSA isn't stupid.
          Not the point. The possibility of exploitation is enough, once the possibility is there and we just sort of accept it because it just seems too unlikely that anyone would ever exploit it (like it seemed unlikely that NSA would be spying the entire rest of the world's online traffic) then it's likely that the vulnerability will be exploited some day.

          So we have to demand up front to get software where such possibilities do not exist.

          LOL. So you won't believe any 0 day exploits exist unless i can prove it by showing them? If i could, then they'd be fixed and wouldn't exist... Anyway, go on any hacker site. There are people out there selling exploits to FOSS software like Firefox just like any of the proprietary browsers. There's no reason why browsers would be fundamentally different in this respect than any other software system. Common sense, people.
          That's not what this was about, don't try to move the goalposts. Of course vulnerabilities exist in any software, and the Linux kernel isn't invulnerable to exploits. The point is, that on Linux, the vulnerabilities are generally fixed as soon as the kernel devs are aware of them, instead of them being reported directly to the NSA, and then some day maybe getting patched, if the NSA says it's ok. And everyone is on a level playing field, everyone can see the code.

          You said, that you "guarantee" the NSA has tons of unknown exploits for Linux. How exactly do you guarantee this? If the exploits are unknown, how do you know about them? Do you have some inside NSA information?

          The point is, that it is possible to harden Linux systems to the point of being very secure against exploits - this is why Linux is used in lots of places where security is important. On proprietary systems, particularly ones, whose exploits and vulnerabilities are voluntarily reported to NSA before getting patched, this is not possible, because those kinds of systems already undermine these kinds of efforts by design.

          DRM literally means digital rights management. If you want to use it to manage the rights of your own data, privacy software is exactly what it becomes. There's no difference. The only thing you mean is that standard DRM is controlled by others instead of you.
          Yes, and NSA literally means "national security agency", so obviously they're just an agency that looks after the security of people who live in nations. No worries!

          I can't believe you'd be that stupid. DRM is a term that has a very specific meaning, and no one has ever included privacy software in the definition of DRM. Terms do not always mean what they seem to mean at face value - kidnappers are not kids who take naps, second hand stores don't actually sell second hands, etc. Particularly, with a term like DRM, which is purposefully designed to be misleading - it's something that happens in business and politics all the time, it's why US politicians create laws with really "nice" sounding names. It's called putting a spin on things, or propaganda. It's why "Patriot Act" isn't called "Taking away your civil liberties Act", and people are much more likely to accept a "Defense of Marriage Act" than a "Damn gays should go to hell Act".

          DRM specifically refers to software that restricts the user's control of their own hardware/software in order to protect the interests of someone other than the user. If you use privacy software, you may be managing your digital rights, but you are not using Digital Rights Management.

          Ok, enough of this. I'm refusing to waste any more time on this stupid topic. You will not draw me into another long flamefest BO$$ style.
          You do as you think best. No one is forcing you to post.

          Comment


          • #50
            This whole thing is nonsense, and just as nonsensical as the gratis fluendo codec. It gives us 'open source' in the literal sense (we can 'see' the code), without the freedom to modify the code. I can't even recompile the code with secure instrumentation, or for another platform, or whatever.

            Mozilla should be using its power to oppose patent traps, not create them.

            Comment


            • #51
              Originally posted by erendorn View Post
              NSA backdoor, really?
              In a video codec?

              Get back on earth...
              The codec cannot have access (because you can sandbox it and/or measure what access it is asking for, and compare it to the source) to:
              - network
              - files on your computer
              - user and kernel land programs of your computer
              Firefox sandboxes nothing. TFA is about Firefox. Therefore the codec does have access to everything you listed, it is a binary running with your user rights.

              Comment


              • #52
                Originally posted by curaga View Post
                Firefox sandboxes nothing. TFA is about Firefox. Therefore the codec does have access to everything you listed, it is a binary running with your user rights.
                But maybe they'll sandbox this, since they're already writing special code just for it? They've already got plugin code running in a separate process, and they will know exactly which rights this code should and shouldn't have, so it'd be really easy.

                The fact is that we don't know what kind of access rights this codec will have, because it hasn't been added yet.

                Comment


                • #53
                  The seccomp sandboxes require cooperation. It's entirely possible FF cannot sandbox the codec without a framework such as SELinux or Smack.

                  You're right that this is speculation. Still, it's such a big hole if it ends up working that way.

                  Comment


                  • #54
                    Originally posted by curaga View Post
                    The seccomp sandboxes require cooperation. It's entirely possible FF cannot sandbox the codec without a framework such as SELinux or Smack.

                    You're right that this is speculation. Still, it's such a big hole if it ends up working that way.
                    Sure, but the you don't need it to be sandboxed everywhere. You need it to be sandboxed/monitored at least once, and see it request at least once a resource that shouldn't be requested based on source, for the backdoor to be detected.
                    This just makes it an unpractical backdoor, and as such, an implausible one.

                    Comment


                    • #55
                      Originally posted by erendorn View Post
                      Sure, but the you don't need it to be sandboxed everywhere. You need it to be sandboxed/monitored at least once, and see it request at least once a resource that shouldn't be requested based on source, for the backdoor to be detected.
                      This just makes it an unpractical backdoor, and as such, an implausible one.
                      You cannot monitor it for suspicious behavior when any backdoor may be activated by an unknown sequence that you do not know of.
                      Any such backdoor will probably be masqueraded as a bug though.

                      Comment


                      • #56
                        Originally posted by uid313 View Post
                        You cannot monitor it for suspicious behavior when any backdoor may be activated by an unknown sequence that you do not know of.
                        Any such backdoor will probably be masqueraded as a bug though.
                        I'm sure this could be used against individual untargeted users provided you can check by some other vector that these users do not have any security measure (SELinux, for example, prevents AND log breaches attempts).

                        It still quite unpractical to only target users that have absolutely zero binary programs on their PC but this codec, that actually use this codec (you won't if you have hardware or OS support), that do not have sandboxing/monitoring capabilities, that can be determined separately that they don't have these capabilities, that use VOIP through the web and using this codec, and that communicate things worth listening to directly (not just for metadata) through it.
                        => implausible.

                        Regarding it being masqueraded as a bug, I completely agree, yet they will still have to deactivate it after being caught.

                        Comment

                        Working...
                        X