Stories
Slash Boxes
Comments

SoylentNews is people

posted by Fnord666 on Friday June 02, @07:19PM   Printer-friendly
from the virtual-town-hall dept.

http://www.tomshardware.com/news/chrome-deprecates-pnacl-embraces-webassembly,34583.html

Google announced that its Portable Native Client (PNaCl) solution for making native code run inside the browser will be replaced by the new cross-browser web standard called WebAssembly.

Around the same time Google introduced Chrome OS in 2011, it also announced Native Client (NaCl), a sandboxing technology that runs native code inside the browser. This was initially supposed to make Chrome OS a little more useful offline compared to only running web apps that required an internet connection. Two years later, Google also announced PNaCl, which was a more portable version of NaCl that could work on ARM, MIPS, and x86 devices. NaCl, on the other hand, only worked on x86 chips.

Even though Google open sourced PNaCl, as part of the Chromium project, Mozilla ended up creating its own alternative called "asm.js," an optimized subset of JavaScript that could also compile to the assembly language. Mozilla thought that asm.js was far simpler to implement and required no API compatibility, as PNaCl did. As these projects seemed to go nowhere, with everyone promoting their own standard, the major browser vendors seem to have eventually decided on creating WebAssembly.


Original Submission

This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough

Mark All as Read

Mark All as Unread

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
(1)
  • (Score: 4, Insightful) by frojack on Friday June 02, @07:28PM (15 children)

    by frojack (1554) Subscriber Badge on Friday June 02, @07:28PM (#519528) Journal

    And still this crazy idea that code from some random remote site should be free to run un-fettered on everyone's device persists!!

    Tell you what: If that's such a good idea lets reverse the situation and let any random user run any random code on YOUR WEB SERVER, and see how long your site stays on the air.

    I'm starting to think those paranoids that turn off all scripting may actually have stole a march on the rest of us.

    --
    No, you are mistaken. I've always had this sig.
    • (Score: 0) by Anonymous Coward on Friday June 02, @07:34PM (2 children)

      by Anonymous Coward on Friday June 02, @07:34PM (#519533)

      Turns out Stallman has been correct about just about everything. Better late to the train than missing it entirely

      • (Score: 2) by kaszz on Friday June 02, @07:50PM (1 child)

        by kaszz (4211) on Friday June 02, @07:50PM (#519546) Journal

        Any special Stallman quote in mind this time?

        • (Score: 2) by Pino P on Friday June 02, @11:20PM

          by Pino P (4721) on Friday June 02, @11:20PM (#519624) Journal

          "You may be running nonfree programs on your computer every day without realizing it—through your web browser."
          -- Richard Stallman, "The JavaScript Trap" [gnu.org]

          The solution that he and his GNU project offer is to mark up your scripts [gnu.org] with machine-readable license metadata and URLs to untranspiled, unminified source code. This allows the GNU script blocker LibreJS [gnu.org] to identify free scripts for which to create exceptions.

    • (Score: 2) by Arik on Friday June 02, @08:21PM (8 children)

      by Arik (4543) on Friday June 02, @08:21PM (#519558)
      The practice of routinely embedding program code in documents is deeply wrong-headed and poisons every technology it touches.
      --
      "Unix? These savages aren't even circumcised!"
      • (Score: 0) by Anonymous Coward on Friday June 02, @09:08PM (7 children)

        by Anonymous Coward on Friday June 02, @09:08PM (#519576)

        This is true. The only issue is that the web is used for more than just documents. However, the question remains why the web is anything more than a document system to begin with.

        • (Score: 2) by kaszz on Friday June 02, @11:19PM (1 child)

          by kaszz (4211) on Friday June 02, @11:19PM (#519621) Journal

          The main reason is because web monkeys and Microsoft minds. They are everywhere these days, and before that they were too incompetent to get a intellectual foothold in industries that mattered.

          On a more practical side. Producing a normal datasheet requires text and images. Like any html can handle, even HTML v2.0 if so needed. So since 1993 it's been possible to produce "documents". But as soon you get these types that insist on nice formatting all the way to hell. You get to hell standards to handle them because the people deciding on the standards screw it up. Usually the poettering-effect combined with corporate my-special-snowflake-tag.

          The next step comes when there's a need to have a page that can convert say Celsius to Fahrenheit without calling the server every time for such simple things. And that calls for some kind of logic incorporated into the "document". There are some situations where having builtin logic makes sense. Another one is continuously updated data on say a weather station. The problem comes when the way to express that logic is chosen unwisely and the security model is not designed in from the start. And the again the decision makers are not wise on these matters.

          • (Score: 2) by Arik on Saturday June 03, @01:07AM

            by Arik (4543) on Saturday June 03, @01:07AM (#519663)
            "The main reason is because web monkeys and Microsoft minds. They are everywhere these days, and before that they were too incompetent to get a intellectual foothold in industries that mattered."

            Eternal September, the Nakba of my people.

            "On a more practical side. Producing a normal datasheet requires text and images. Like any html can handle, even HTML v2.0 if so needed. So since 1993 it's been possible to produce "documents". But as soon you get these types that insist on nice formatting all the way to hell. You get to hell standards to handle them because the people deciding on the standards screw it up. Usually the poettering-effect combined with corporate my-special-snowflake-tag."

            Yes, the snowflake behaviour must not be normalized, which is why I make it a point to never bow in any way to the idiots that complain about "my" "font." It is and has always been the document authors job to indicate the logical structure of the document accurately in markup, and the browsers job to actually decide how it gets rendered on whatever sort of display device is actually in use. If your browser is doing a bad job talk to your browsers authors, not to me.

            "The next step comes when there's a need to have a page that can convert say Celsius to Fahrenheit without calling the server every time for such simple things. And that calls for some kind of logic incorporated into the "document"."

            Sure. And that can easily be dealt with using a standard dialogue asking for additional permissions. It's no big burden because it's an unusual case. And it *should* be an unusual case.

            Instead it was the thin wedge they used to push the current regime down our throat. More and more websites simply presume that you're running the latest and most horrifically insecure browser known to man, and have the nerve to act like it's your fault if you're not. These fuckers want to be able to feed you 50mbs of encrypted script and see you blindly run it in order to get your temperature conversion, and actually have the nerve to act like YOU are the one with the damn cooties if they don't get their way.

            Fuck em. Fuck em up the arse with a rusty knife, covered in sheep shit.

            --
            "Unix? These savages aren't even circumcised!"
        • (Score: 3, Informative) by tibman on Friday June 02, @11:20PM (4 children)

          by tibman (134) Subscriber Badge on Friday June 02, @11:20PM (#519623)

          the question remains why the web is anything more than a document system

          So that we can collectively comment on a document. So that we can create "living documents" that are updated every second. So that we can interact with each other.

          Document-only protocols exist. It's a horrible way to "be online".

          --
          SN won't survive on lurkers alone. Write comments.
          • (Score: 3, Informative) by Pino P on Saturday June 03, @12:04AM (3 children)

            by Pino P (4721) on Saturday June 03, @12:04AM (#519643) Journal

            So that we can collectively comment on a document.

            The no-script way to do that is to follow the document each comment with a link to a separate document containing a form to reply to that item.

            The article "Please don't use Slack for FOSS projects" by Drew DeVault [drewdevault.com] begins by condemning Slack, HipChat, Skype, Discord, and other real-time chat services for relying on non-free software and service as a software substitute [gnu.org]. Instead, it recommends Internet Relay Chat (IRC), a published protocol with numerous free servers and free clients. The article acknowledges that IRC doesn't archive conversations permanently (unlike the other services), requiring the use of a "bouncer" proxy, nor does it allow attaching a text, image, or other file to a message in a channel, requiring the use of a pastebin or similar. But a private IRC server could offer these features.

            In any case, IRC and proprietary web chat share a few problems.

            IRC requires downloading software
            Mainstream PC and smartphone operating systems ship with a web browser but not an IRC client. IRC-to-web proxies exist, making the experience similar to that of proprietary web chat, particularly if your proxy integrates a bouncer. But use of any web chat tends to be unwieldy unless you allow the proxy to download JavaScript software to your computer to check a WebSocket for incoming messages.
            Real-time communication is discriminatory
            Some users take longer to reply to a particular thought. They might have a different native language or learning disabilities. And not all users are available at the same time. Users in a time zone close to that of the maintainer have an advantage over users in less populated time zones.

            I remember reading another article that condemned chat for discriminating against users in other time zones. Instead, it encourages people to use asynchronous communication systems, such as mailing lists, Usenet, and web-based bulletin boards. Unfortunately, I'm having trouble finding this article again using Google Search.

            • (Score: 2) by tibman on Saturday June 03, @03:57AM (2 children)

              by tibman (134) Subscriber Badge on Saturday June 03, @03:57AM (#519723)

              The no-script way to do that is to follow the document each comment with a link to a separate document containing a form to reply to that item.

              That's not "no-script". That's no client script. There is still a web developer writing code to validate your comment, store it, and render the dynamic document. That's a long way away from the original quote "the question remains why the web is anything more than a document system". You'd have to redefine document to mean anything rendered to the screen.

              I totally agree that the current state of chat really sucks. I remember when people were using libaim and similar libraries to write their own chat client that communicated over open-ish protocols.

              --
              SN won't survive on lurkers alone. Write comments.
              • (Score: 2) by frojack on Saturday June 03, @04:57PM

                by frojack (1554) Subscriber Badge on Saturday June 03, @04:57PM (#519904) Journal

                That's not "no-script". That's no client script.

                Well DUH!.

                The thread started with a condemnation of the practice of foisting all manor processes to run on the client side.

                Client side scripting is, after all, the root of all hacks. Sandboxes have been historically a majestic failure as each successive pwn2own proves over and over again.

                We've been doing this stuff for going on to 30 years now, and it has gotten progressively more risky each year. Not just because the stakes got higher (on line banking, remote control of machinery, etc), but also because the attack vectors are expanding with each new gotta-have feature, and each new browser plugin.

                Serious browser induced exploit announcements use to occur maybe once a year. Now they are revealed once a month.

                Yet we continue to add stupid extensions to browsers. Now my browser can manipulate to my blue tooth. Who ever thought that was a good idea deserves a 38 caliber vasectomy.

                --
                No, you are mistaken. I've always had this sig.
              • (Score: 2) by JNCF on Saturday June 03, @05:24PM

                by JNCF (4317) Subscriber Badge on Saturday June 03, @05:24PM (#519919) Journal

                That's not "no-script". That's no client script.

                In this context, the term "NoScript" [wikipedia.org] is just concerned with the client.

                You'd have to redefine document to mean anything rendered to the screen.

                The distinction being drawn is whether or not there is arbitrary logic happening in the browser. You can have an embedded video and still be "just a document," if your video is embedded using a DOM element. If you roll your own video player, that's "more." You can deliver a document with comment boxes and submit buttons, and as long as they're only making requests which redirect the browser the original page is still "just" a document. If there's a client-side script involved in processing the form data it becomes "more."

    • (Score: 0) by Anonymous Coward on Saturday June 03, @04:18AM

      by Anonymous Coward on Saturday June 03, @04:18AM (#519727)

      this crazy idea that code from some random remote site should be free to run un-fettered on everyone's device persists!!

      That's what JavaScript does, for good or bad.

    • (Score: 3, Informative) by TheRaven on Saturday June 03, @09:32AM (1 child)

      by TheRaven (270) on Saturday June 03, @09:32AM (#519782) Journal

      And still this crazy idea that code from some random remote site should be free to run un-fettered on everyone's device persists!!

      Huh? JavaScript, PNaCl and WebAssembly all run the code in a sandbox. PNaCl and Google's implementation of WebAssembly both use NaCl on the back end and so provide a formally verified sandbox.

      I'm not sure why this is news, the entire PNaCl team was pulled off the project to work on WebAssembly a year or so back (J. F. Bastien is now at Apple, as are a few others, but most of the PNaCl team is still there working on WebAssembly).

      --
      sudo mod me up
      • (Score: 2) by frojack on Saturday June 03, @04:58PM

        by frojack (1554) Subscriber Badge on Saturday June 03, @04:58PM (#519906) Journal

        a formally verified sandbox.

        Chuckle. Famous last words.

        --
        No, you are mistaken. I've always had this sig.
  • (Score: 2) by kaszz on Friday June 02, @07:34PM

    by kaszz (4211) on Friday June 02, @07:34PM (#519534) Journal

    Anyone else getting the feeling of locking and derailing into substandard.. standard modus operandi?

    It's getting more obvious with time that "web people" should not decide on technical standards or procedures.

  • (Score: 5, Funny) by Phoenix666 on Friday June 02, @07:56PM

    by Phoenix666 (552) on Friday June 02, @07:56PM (#519549) Journal

    That's good. "Pee Salt" was a terrible branding mistake.

    --
    Washington DC delenda est.
  • (Score: 0) by Anonymous Coward on Saturday June 03, @11:36AM

    by Anonymous Coward on Saturday June 03, @11:36AM (#519809)

    Your web browser is not a document viewer as originally marketed. It is now a virtual machine, please treat it approriately.

(1)