1. 14
  1.  

  2. 11

    I fundamentally disagree with much of the history presented here. XHTML/XSLT was an abomination. It deserved to die. XSLT didn’t die because it allowed you to “remove ads”, it died because it fell into the turing tarpit. Have you ever tried to make any kind of non-trivial system using XSLT and XHTML? I have. I was using it to build an intranet site back when the PHBs all thought that those two technologies were the future. It was a nightmare. XSLT has very few mechanisms for encapsulation. Unit testing it is damn near impossible. When we finally switched to Javascript, as terrible as Javascript was, it was still a godsend compared to XSLT.

    Moreover, I think it’s completely wrong to put the blame for the web becoming a privacy-destroying apparatus on the backs of HTML5 and Javascript. HTML5 and Javascript have served to democratize computing. Now, you can make an application and have instant worldwide distribution, without having to deal with publishers, distributors, retailers or the messy business of copying discs and shipping them. If your application has an issue, you can patch it nigh-instantaneously. You don’t need multimillion dollar contracts to sell your application; all you need is a server and a URL. The alternative to a world in which the web exists is not some privacy preserving Utopia. It is a world in which Microsoft reigns supreme. Remember, before the web exploded in popularity, and Apache-on-Linux became the default OS of the web, Windows NT was making significant inroads into the server market. If the web hadn’t happened, we might very well have ended up with a situation where Microsoft ends up with unchallenged and unchallengable control of computing, client and server.

    While we correctly castigate privacy destroying organizations like Facebook and Google, we should also remember that without the world wide web, modern open-source wouldn’t exist. Without the web, Linux would still be an obscure toy operating system kernel created by a Finnish grad student. Without the web, Python would be an esolang created by a Dutch scientist, and Ruby would be Yukihiro Matsumo’s hobby project. It is the web that allowed communities to form around these projects and make them as successful as they are today.

    1. 0

      Have you ever tried to make any kind of non-trivial system using XSLT and XHTML?

      ROTFL! :-D

      Yes, I did. As I said, we had a pretty good infrastructure that chained several transforms from several sources, merging data from a PostgreSQL database and from REST services to generate/update pretty complex websites, in several versions (by language and style).
      Even some dynamic parts were generated that way.

      I have to confess my hope back then was to see XSLT in every browsers.

      The only piece of that stack that I do not really know well is XSL-FO.
      I did several experiments back then, with very nice results, crawling the web we generated and turning into nice (but simple) PDF. But I cannot recall much…

      XSLT has very few mechanisms for encapsulation.

      I think this is the only thing you remember correctly.

      And I happily admit that the whole stack was not perfect. And that it could have been improved.
      Even XSD was not able to represent all constraints I needed back then. And XForms were too limited.

      But it was the right direction to explore.

      HTML5 and Javascript have served to democratize computing. Now, you can make an application and have instant worldwide distribution, without having to deal with publishers, distributors, retailers or the messy business of copying discs and shipping them.

      I do not know who told you this bullshit. We had very nice applications in HTML4 served by our servers and using several technologies.

      Remember, before the web exploded in popularity, and Apache-on-Linux became the default OS of the web, Windows NT was making significant inroads into the server market.

      Lool!

      The web was already “exploded” before 2000. And then imploded. And then exploded again.
      Before HTML5.
      And Apache+Linux was leading the server market since…. gosh… I do not even remember the start…

      JavaScript did not saved Linux, Python, Ruby and so on… but thanks, this is really funny!

      The web existed before JavaScript and HTML5. And it will exist after.

      But right now, JavaScript turns the Web to a very dangerous weapon.

    2. 6

      I understand the points being made here, but I disagree completely.

      I’d rather an open specification being defined for applications than we return to the day of flash, and java applets because customers want x to work easily, and we all know the rep java and flash applications have for how amazing and secure they are…

      A point that seems to keep coming up with webasm is obfuscation. I understand where the sentiment comes from, and yeah, it may not be as easy as just clicking view-source, and scanning through some uglified JS, but vendors can and do make things obfuscated regardless with just javascript alone, this is not webasm specific. Actually there are a few points I have when this argument comes up.

      • Who is looking at the source for each website they visit? General public? Hell no! I’m not going to vet every website’s page to check it’s source either.
      • Users want applications, hell there is a reason why the internet is something so much more than just a Wikipedia. Applications further than just crud need interactivity, something your not getting from basic forms and hyperlinks, and the alternative? Terrible browser extensions that are harder to examine and have holes galore? Or how about download my application packaged with adware!
      • Better than examining source, examine the darn output. Network tab? Excellent! I can see where, and what is being sent out. That’s much better than digging the source. If you want to provide users with more control, provide more functionality around the output/network. WebRTC, Websockets for example. We have a great network tab for HTTP requests, but examining these other two is not trivial.

      I’d much rather run applications run in a sandbox that I can control, than let loose applications on my filesystem.

      Regarding scripts in the browser, if you don’t like ‘em, disable them. Browsers provide these tools, and you can enable per-site. There are many sites that are going to loss partial, even total functionality sure, but that’s the trade-off you make as a user AND a customer.

      There is too much inertia behind the current web, and it’s not going to change radically anytime soon. Sure it’s easy to outline problems with it, nearly anyone can do this. The harder task is finding solutions that keeps everyone happy. Articles like this personally tick me off as it discounts the many problems we HAVE solved. Are there problems? Yup! No doubt, but addressing them like this doesn’t really help at all.

      1. 3

        I’d rather an open specification being defined for applications than we return to the day of flash, and java applets because customers want x to work easily, and we all know the rep java and flash applications have for how amazing and secure they are…

        I don’t think what Shamar is recommending is a return to flash & java applets. (In fact, one of the big complaints about web assembly is that it brings javascript closer to the status of flash and java applets.) Instead, he seems to be recommending that we return the web to the pre-javascript era & move applications entirely off the platform.

        You can have an open specification for a scripting language without embedding that scripting language into a browser & making it emit markup – and, in fact, if you move it out of the browser, then you free it from the never-stable ‘living standards’ that produce browser monopolies, since you end up with fully-versioned specifications. (Think of python, with its several implementations and specs.)

        Who is looking at the source for each website they visit? General public? Hell no! I’m not going to vet every website’s page to check it’s source either.

        As mentioned in the essay, while most people never look at the source, hackers sometimes look at the source, which is a barrier to malicious code that’s consistently served up. If malicious code is only served in response to some server-side process identifying a particular user, then the likelihood that anybody will catch it is much lower. If that code is also minified, then there’s greater friction, so even if it gets served up to a hacker, they are less likely to examine it closely enough to identify malicious code; this applies even moreso to binaries.

        In other words, we have some base probability that malicious code will be eventually identified (say, 1%), and with each of these layers of obfuscation, the probability that it’ll be identified & somebody will make a stink about it sinks lower.

        Users want applications

        Users want applications, but that doesn’t mean that the web is the appropriate way to deliver them. Users want pizza too, but if you serve it to them in a toilet bowl, they need to be pretty hungry to accept it.

        The success of applications managed by real package managers on mobile is an indication that users don’t particularly care whether or not the applications they run are delivered inside a browser. The lack of success of real package managers on consumer desktop OSes is largely a function of the lack of maturity of these package managers. (Nobody goes out of their way to download untrusted binary installers on debian, the way they do on windows, because even though apt-get often produces crusty old versions, it’s more reliable than googling.)

        I’d much rather run applications run in a sandbox that I can control, than let loose applications on my filesystem.

        Sandboxes are a feature of almost all scripting languages. The browser is a poor sandbox with a poor API, and survives as an application platform purely through inertia left over from the mid-90s, when newbie developers falsely believed that javascript in a browser was the only cross-platform sandboxed scripting environment.

        There is too much inertia behind the current web, and it’s not going to change radically anytime soon.

        This is unfortunately very true. Luckily, users don’t have any loyalty to web standards – only web devs do, and many web devs have been around the block enough times to know that it’s worth jumping ship.

        The harder task is finding solutions that keeps everyone happy.

        Keeping everyone happy is straightforward. It’s trivial to do all the tasks the browser does better than the browser does them, so long as you throw out all the web standards.

        The harder task is convincing people who are emotionally married to web technologies they dumped huge amounts of effort into understanding that they ought to switch to something that’s better for both them & users in the long term, even when it means slightly more work in the short term.

        The even harder task is to convince companies – for whom truly long-term planning is necessarily difficult – to force their own devs to make the switch. The most effective tool for this, even as much as we might hate it, is hype: suits won’t really understand technical arguments, but they will understand and respond to peer pressure, and likewise, they will understand and respond to influential bloggers who claim that doing something will save them money.

          1. 3

            I think Mozilla is too closely tied to existing web standards. (I felt more at home in Xanadu, but that doesn’t pay the bills!)

      2. 3

        I agree, but do not see how the genie can be put back into the bottle. Even Apple, who since forming the WHATWG have (failed at building their iAd advertising business and subsequently) decided that privacy is an important marketing differentiator, are limiting the worst excesses of browser tracking but not fundamentally disarming it.

        1. 5

          Well there are several ways actually.

          First we need that more people really understand these issues. That’s why I wrote this.
          These are both huge browsers security issues and geopolitical ones.

          Then we need browser vendors to fix them.
          The DNS issue is something Governements should work out, technically and politically.
          The JavaScript issue is easier to fix, as it’s entirely a software issue.

          As a first step, browsers could mark as UNSAFE all web pages that use JavaScript, as they do with unencrypted HTTP sites these days.
          Then it’s just matter of going back to semantic HyperTexts, with a better markup, better CSS and better typography in the browser. I’d like to see XHTML reconsidered, but with the lesson learned.

          For example I would see well an <ADVERTISEMENT> tag.

          But the main point is to avoid any Turing complete language in the browser.

          1. 6

            The web has gotten to the point where it’s primarily used as a distribution mechanism for scripts. And, as hypertext, static html is not acceptable (having none of the normal guarantees about content stability that hypertext ought to make). So, if we’re going to drop the javascript sandbox, we might as well bite the bullet and also drop DNS and HTTP at the same time.

            In other words, we replace one thing (“the browser”) with two things – a sandbox that downloads and runs scripts, and a proper hypertext browser & editor. Both of these should use a non-host-oriented addressing scheme for identifying chunks of content, and support serving out of its own cache to peers. (The way I’d do it is probably to run an ipfs daemon & then use it for both fetching & publishing, and then manage pinning and unpinning content based on some inter-peer communication protocol.)

            I’ve made this suggestion before. (I’m pretty sure you’ve been privy to some of the discussions I’ve had about it on the fediverse.)

            The point I’d like to underline here is: if the only thing salvagable about the web is the use of internal markup and host-oriented addressing schemes for static semantic hypertext, then nothing about the web is salvagable.

            HTTP+HTML is an unacceptable hypertext system by 1989 standards, and thirty years on we should set our sights higher. Luckily, problems that were hard but not impossible in 1989 (like ensuring that data gets replicated between independent heterogenous nodes) have been made trivial in practice because of the proliferation of both high-speed always-on connections & solid, well-engineered open source packages.

            1. 3

              Honestly, among the few hypertexts I used in the past (with GNU Info being the only one whose I remember the name), the web was the best one from several point of views.

              I think XHTML and the related stack was pretty good, and I used XML Namespaces extensively to enrich web pages with semantic contents while preserving accessibility. But, don’t worry, I don’t dare to argue about hypertexts… with you! :-D

              I welcome any proposal. And any experiment. And any hack.

              I see these as huge security vulnerabilities in the very design of the Internet and the Web.
              Now we need to fix them. I hope in Mozilla as they claim they care about security and privacy, and this actually put lifes at risk. So, we need to go back to the drawing board and design a better Web on top of the lessons we learned.

              In other words, we replace one thing (“the browser”) with two things – a sandbox that downloads and runs scripts, and a proper hypertext browser & editor.

              Agreed for the hypertext browser and editor.

              But the fact you feel the need for a “sandbox that downloads and runs scripts” is just another symptom of the desease that made me create Jehanne. It’s basically a shortcoming of mainstream operating systems!

              Unfortunately, hacking HTML and HTTP to patch this proved to be the wrong approach.

              IMHO, we need a properly designed distributed operating system (and a better network protocol to serve such distributed computation).

              1. 2

                the fact you feel the need for a “sandbox that downloads and runs scripts” is […] basically a shortcoming of mainstream operating systems!

                Absolutely agreed. The web has basically become a package manager for unsafe code. Replacing that function with a dedicated sandbox is only an incremental improvement.

                However – if we stop using URLs that can have their content changed at any time and start using addresses that have their own validation built in, then the problem of scripts being completely swapped out at runtime to target particular people and machines. This is an incremental improvement but a very important one.

                we need a properly designed distributed operating system (and a better network protocol to serve such distributed computation)

                Likewise, completely agreed. A proper distributed OS (as opposed to an ad-hoc layer for swapping sandboxed unsafe code) could be designed data-first instead of host-first (even though almost all distribution protocols, even erlang’s, are still host-oriented). The problems that web tech tries and fails to paper over are solved now by SSB, IPFS, bittorrent, CORD, and other systems – all open source and with documented designs.

                1. 2

                  SSB, IPFS, (and DAT?) all have a pretty severe drawback that’s tied to their biggest strength – immutability/non-deleteability. This gets you a lot of things that the original vision of hypertext wants (byte-range transclusion, external markup, links that never break), and I understand that’s why you feel strongly about it. But not being able to ever delete or edit anything in place (only publish updated versions as a new document) is not a humane basis for the web.

                  If these solutions really took off today, I’m pretty sure that in 10 years, we’d be begging for the horrors of 2018’s web. It would facilitate harassment and hate speech to an extent that would make twitter.com look like kitty.town, and moderation tools would be near impossible to implement.

                  I use and like SSB, but as it’s growing, it’s starting to show some of these problems. Due to founder effect, the community on there is pretty kind, but people are becoming aware of the weaknesses for moderation. No ability to delete or edit posts is a big one; the only fix is to define delete/patch messages that well-behaved clients will respect, but the original will always be available. And the way the protocol works, blocks (the foundation of a humane social media experience) are one-way only: if you block someone you can see them, but they can still see you. (Contrast to Mastodon and mainline Pleroma).

                  On the other hand, for the narrower case of delivering sandboxed code, IPFS or BitTorrent are basically exactly what you want, so my complaints here may not be strictly relevant.

                  1. 2

                    Yeah, undeletability is a can of worms. It’s a huge legal problem, and a potentially large social problem.

                    It’s also fundamental to the basis of functioning hypertext.

                    SSB is mostly being used as a social network – a context where undeletability is a much bigger deal, since the expectation is that posts are being made off-the-cuff. Hypertext (excluding the web, of course) is usually thought of in terms of a publishing context – for distributing essays, criticism, deconstructions, syntheses, historical notes, anthologies, etc. (XanaduSpace even had a public/private distinction, where the full hypertext and versioning facilities were available for documents that were not made available to other users, with an eventual ‘publication’ step broadcasting a copy with previous revision history elided.) The expectations are much different, both around interest in archival by third parties, and around the expectation of privacy or deniability: hypertext is very much in the vein of, say, academic journal publishing[1].

                    In other words: what I’m looking for with regard to new hypertext systems will look less like a deeply-intertwingled Mastodon and more like a deeply-intertwingled Medium. (This probably even comes down to transcopyright. Nobody implements transcopyright, but the closest thing on the web is probably Medium’s open paywall, not token-word’s pseudo-transcopyright system.)

                    [1] The big projected commercial application for XanaduSpace was law offices: we would market it to paralegals, have a dedicated private permapub server for the law office pre-loaded with case law, and replace the current mechanisms they use for searching and discussing case law (which rely heavily on Microsoft Word’s “track changes” feature).

        2. 3

          The article is about two dangerous security issues in the implementation of the Internet and in the design of the Web (specifically the Web 2.0).

          The first bug is mainly a geopolitical issue in technical form and it should concern everyone outside the US as a military threat to their comunications (web, mail, smartphones… everything). Even if we are close friends with USA (and we are!) it’s not nice if your friend fills your home with traps, even if he just want to keep you safe.

          The second is a bug affecting all mainstream browsers: they blindly execute JavaScript programs provided by servers who can “customize” them for specific people or small groups, with perfectly plausible deniability and no way to detect the attack through digital forensics.
          Such kind of attack could be made way worse with WebAssembly, but it’s already possible with JavaScript.

          For example, it could poison people PC with illegal documents or false evidences before a police search.

          1. 4

            I get your main point(s) but I don’t think WebAssembly is a “weapon” that’s deadlier than JavaScript nor is it the worst idea since JavaScript… The problems that exist in the Web world are not in JavaScript or its implementation (there are problems with these but they are irrelevant to the topic). The problems are in its use in browsers which are the weapons themselves. There’s a reason browser heavily limits operations and APIs for developers to use. I think Web assembly doesn’t make the situation worse, it only makes the current situation better for developers as they are not limited to a specific language, and allows for further optimizations and performance in browsers. What makes this statement stronger is the fact that the WebAssembly project is being pushed forward at huge steps by teams at mozilla - on the browser side and on Rust that aims to be one of the first citizens of Web assembly. So I don’t think mozilla will be the first to stop this unpleasing situation.. There are many other security problems that have nothing to do with these. And I think that with time and experience and, of course, huge scandals like Cambridge Analytica things will get more balanced… Until next time. Just like everything in life and everything in software.. Easily and comfortably serving code remotely to be executed on a target machine is a challenge.

            1. 2

              I think Web assembly doesn’t make the situation worse

              I do not agree.
              I’ve had to debug optimized binaries without having the sources in the past (produced by GCC with -O2 and no debug symbols) and I often have to debug minimized and obfusced JavaScript on several browsers.
              I do not like JavaScript, but debugging binaries is way more expensive.

              The problems are in its use in browsers which are the weapons themselves.

              Most web browsers are not weapons. They are HyperText renderers.
              Just mainstream browsers are weapons. Remove all scripting languages from web pages, and you will get pretty decent tools. And secure ones.

              1. 4

                pretty decent tools. And secure ones.

                And almost entirely useless ones.

                Users want applications, not just linked documents.

            2. 3

              I don’t think WebAssembly makes things significantly worse than JavaScript alone. But I think the paradigm of running untrusted code in the browser without user confirmation is fundamentally bad. Opening a web page today (without noscript or umatrix, etc) is basically equivalent to installing an unsigned app on a mobile device. In the latter case, you at least get some indication of what permissions are needed, and a chance to refuse (even if none of that is an adequate protection in practice).

              I think the last 10 years have really told us what JS features a dynamic web page actually needs, and those capabilities could be provided declaratively through additions to HTML and the browser, without requiring client-side scripting.

              1. 3

                you at least get some indication of what permissions are needed, and a chance to refuse

                You get the same on the Web.

                No, you get stronger protection on the Web actually — a permission prompt is required even for push notifications, and arbitrary background activity is not allowed.

              2. 1

                This is a great rant and I’m first in line to hate on the web stack, but I think it’s tilting at the wrong windmill.

                It’s very concerned about code that runs on people’s computers when the thing that throws elections is the text that runs on people’s brains.