Stories
Slash Boxes
Comments

SoylentNews is people

posted by chromas on Saturday April 21 2018, @02:34AM   Printer-friendly
from the made-with-macromedia dept.

Submitted via IRC for TheMightyBuzzard

Only 4.9 percent of today's websites utilize Flash code, a number that has plummeted from a 28.5 percent market share recorded at the start of 2011.

The number, courtesy of web technology survey site W3Techs, confirms Flash's decline, and a reason why Adobe has decided to retire the technology at the end of 2020.

[...] On the client side, browser makers are expected to remove Flash support from their products altogether by the end of 2020 —Flash's end-of-life date.

2020 can't come soon enough.

Source: https://www.bleepingcomputer.com/news/software/flash-used-on-5-percent-of-all-websites-down-from-285-percent-seven-years-ago/


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.
  • (Score: 4, Insightful) by The Mighty Buzzard on Saturday April 21 2018, @03:35AM (29 children)

    by The Mighty Buzzard (18) Subscriber Badge <themightybuzzard@proton.me> on Saturday April 21 2018, @03:35AM (#669930) Homepage Journal

    As much as it pains me to say it, there's nothing wrong with extremely minor uses of javascript as a crutch to overcome some HTML shortcomings. The main problems with it are the kind of idiots who think it's a good idea to write an entire office suite in it and the language developers who don't understand they bloody well need to be considering security before functionality.

    --
    My rights don't end where your fear begins.
    Starting Score:    1  point
    Moderation   +2  
       Insightful=2, Total=2
    Extra 'Insightful' Modifier   0  
    Karma-Bonus Modifier   +1  

    Total Score:   4  
  • (Score: 3, Funny) by Anonymous Coward on Saturday April 21 2018, @04:07AM (19 children)

    by Anonymous Coward on Saturday April 21 2018, @04:07AM (#669938)

    As much as it pains her to say it, there's nothing wrong with sex, if you only get the tip in. The main problem with sex is when he shoves the whole damned thing in there, then ejaculates.

    Javascript is javascript. You can get just as pregnant with a little of it, as with a lot of it.

    • (Score: 2, Touché) by takyon on Saturday April 21 2018, @04:23AM (18 children)

      by takyon (881) <takyonNO@SPAMsoylentnews.org> on Saturday April 21 2018, @04:23AM (#669945) Journal

      Javascript is javascript. You can get just as pregnant with a little of it, as with a lot of it.

      Hack this code:

      <!DOCTYPE html>
      <html><head>
      <script>
      var pi = 3;
      </script>
      </head><body>Tau = 300.</body></html>

      Make compooter pragnent.

      --
      [SIG] 10/28/2017: Soylent Upgrade v14 [soylentnews.org]
      • (Score: 5, Interesting) by Arik on Saturday April 21 2018, @04:40AM (4 children)

        by Arik (4543) on Saturday April 21 2018, @04:40AM (#669956) Journal
        That's fine, because a sane browser will simply ignore your scripting and render the HTML, no harm done.

        That's also a horrible example, exactly because your script does nothing.

        But you can add all the scripting you want and as long as the browser is sane and your html is correct, you're just wasting bandwidth.

        But no one does that. They use javascript for useful things, like embedding a calculator, or for things they mistakenly think are useful (like implementing a search field in jscript, which just results in sane browsers skipping it,) or for things that no one with half a clue would think was in any way useful (like encoding the entire document in script, so that there isn't even any <body> text for the sane browser to render.

        None of these things are directly malicious, but each of them creates more reasons for the PC user to abandon sane browsing and throw open the scripting door.

        And once that step is taken it only takes a click on a malicious link.

        The whole idea with the web, the whole genius of it, was that you didn't have to be careful what you clicked. By design, every link was safe. The worst that could happen was the goatse.cx guy. You might see something that you didn't want to see, but it could be guaranteed to be an inert document, not some sort of malware.

        Now, you have to enable the malware creators favorite infrastructure just to access supposedly "public" documents.

        --
        If laughter is the best medicine, who are the best doctors?
        • (Score: 2) by Pino P on Sunday April 22 2018, @05:20PM (3 children)

          by Pino P (4721) on Sunday April 22 2018, @05:20PM (#670405) Journal

          "Using a sane web browser? Download our native application instead!"

          And the native application turns out to be either A. exclusive to an operating system other than the one you regularly use (good luck compiling Swift+Cocoa source code on and for a non-Mac), or B. written in Electron, which bundles a separate tens-of-megabytes copy of Chromium with each application you install.

          • (Score: 2) by Arik on Sunday April 22 2018, @05:46PM (2 children)

            by Arik (4543) on Sunday April 22 2018, @05:46PM (#670411) Journal
            Complex problems have to be solved one level at a time, like an onion.

            You have to have a clear distinction between downloading a program and simply viewing a page before it makes sense to argue about what sorts of programs one will or will not accept to download. Right now the typical web user simply downloads and runs whatever any random server it sees a reference to feels like sending it.

            Right now, there isn't even any incentive for the "web developer" to even try to avoid it, because the end user doesn't see it, isn't even aware of it, and has no opportunity to reject it.

            --
            If laughter is the best medicine, who are the best doctors?
            • (Score: 2) by Pino P on Sunday April 22 2018, @06:12PM (1 child)

              by Pino P (4721) on Sunday April 22 2018, @06:12PM (#670419) Journal

              Let's say there were a Firefox extension that lets the user turn script execution on or off for a particular domain. How many layers would such an extension [mozilla.org] solve?

              Or let's say there were a Firefox extension to block execution of any script without a machine-readable free software license. How many layers would such an extension [gnu.org] solve?

              • (Score: 2) by Arik on Sunday April 22 2018, @06:29PM

                by Arik (4543) on Sunday April 22 2018, @06:29PM (#670423) Journal
                Without being widely adopted, none.

                With wide adoption, it would be a big help, not a solution necessarily, but a big move in the right direction at the web layer. Because web devs would be forced to again think about scripting rather than simply piling it on by default whether it serves any purpose or not.

                --
                If laughter is the best medicine, who are the best doctors?
      • (Score: 2) by Justin Case on Sunday April 22 2018, @01:48PM (12 children)

        by Justin Case (4239) on Sunday April 22 2018, @01:48PM (#670335) Journal

        You neglected to specify if the script is delivered over https. Since you overlooked this critical detail, I'm going to assume you overlooked its implementation as well.

        Now, on any big network there's going to be at least one hacked zombie plugged in somewhere. It listens for ARP requests and replies faster than the corporate fabric. Now the zombie is handling your DNS lookups for you.

        Next time you visit http://anything.com the zombie returns its own IP address for anything.com. The request goes to zombie which proxies a web page containing your expected content PLUS malicious script to monitor and exfiltrate everything in the DOM of every site you visit. So your script that says "pi = 3" gets altered to also say "send all cookies to evil.org".

        This Really Happened.

        Your only defense is not to accept scripts over http. Or, for good measure, don't accept scripts at all.

        • (Score: 2) by Pino P on Sunday April 22 2018, @05:28PM (11 children)

          by Pino P (4721) on Sunday April 22 2018, @05:28PM (#670406) Journal

          You neglected to specify if the script is delivered over https.

          Of course a script delivered over the Internet would be through HTTPS. But not all IP traffic is over the Internet; some is over private networks using address space reserved pursuant to RFC 1918, such as 192.168/16 or 10/8. How would an appliance on a home LAN, such as a router, printer, or NAS, obtain a fully qualified domain name with which to obtain a browser-trusted certificate with which to serve its configuration interface over HTTPS? Would each owner of such an appliance have to pay $15 per year to register a domain and zone hosting and keep it renewed?

          Your only defense is not to accept scripts over http.

          What's better: a script delivered over HTTP or a native application delivered over HTTP?

          Or, for good measure, don't accept scripts at all.

          What's better: a script that you can't run because you have disabled script in the browser or a native application that you can't run because it is compiled for a different operating system?

          • (Score: 2) by Arik on Sunday April 22 2018, @05:50PM (6 children)

            by Arik (4543) on Sunday April 22 2018, @05:50PM (#670413) Journal
            "What's better: a script delivered over HTTP or a native application delivered over HTTP?"

            They're both doing it wrong.

            If it's not a source tarball that could be your sign.
            --
            If laughter is the best medicine, who are the best doctors?
            • (Score: 2) by Pino P on Sunday April 22 2018, @06:01PM (5 children)

              by Pino P (4721) on Sunday April 22 2018, @06:01PM (#670416) Journal

              Delivery in source code or object code form is orthogonal to the point I was making.

              What's better: a script delivered over HTTP or a source tarball delivered over HTTP?

              What's better: a script that you can't run because you have disabled script in the browser or a source tarball for a native application that you n't compile, link, and execute because it uses the system libraries of a different operating system?

              • (Score: 2) by Arik on Sunday April 22 2018, @06:24PM (4 children)

                by Arik (4543) on Sunday April 22 2018, @06:24PM (#670421) Journal
                I suppose from a niche point of view you might prefer one to the other, but in general they're equally useless. If you have a point go ahead and spit it out.
                --
                If laughter is the best medicine, who are the best doctors?
                • (Score: 2) by Pino P on Monday April 23 2018, @12:25AM (3 children)

                  by Pino P (4721) on Monday April 23 2018, @12:25AM (#670541) Journal

                  I agree with you that HTTPS is safer than cleartext HTTP. My point is that if you deliver source code for a native application delivered through HTTPS instead of a web application delivered through HTTPS, you shut out users of native operating systems other than the one to which you target the application.

                  In addition, a far larger fraction of non-technical end users know how to execute a web application than how to build a native application from source code.

                  • (Score: 2) by Arik on Monday April 23 2018, @12:34AM (2 children)

                    by Arik (4543) on Monday April 23 2018, @12:34AM (#670545) Journal
                    "My point is that if you deliver source code for a native application delivered through HTTPS instead of a web application delivered through HTTPS, you shut out users of native operating systems other than the one to which you target the application."

                    What you keep calling a 'native application' is a blob, yes?

                    Lack of support for blobs is a feature, not a flaw.

                    If the code does something important and does it properly then it's unlikely to be difficulty to port.

                    --
                    If laughter is the best medicine, who are the best doctors?
                    • (Score: 2) by Pino P on Monday April 23 2018, @12:41AM

                      by Pino P (4721) on Monday April 23 2018, @12:41AM (#670550) Journal

                      What you keep calling a 'native application' is a blob, yes?

                      Or a source tarball that the end user can build into a blob, provided that the end user is the user of an operating system that makes it practical to build an application from a source tarball into a blob.

                      If the code does something important and does it properly then it's unlikely to be difficulty to port.

                      Assume for the purpose of argument, a user wants to run five applications, each of which "does something important and does it properly", but each of which is made for a different operating system. The first application is made for macOS, the second for Windows, the third for X11/Linux, the fourth for iOS, and the fifth for Android. Did you mean to imply that it is more practical for such a user to buy and carry a separate computing device on which to run each application?

                    • (Score: 2) by Pino P on Monday April 23 2018, @12:45AM

                      by Pino P (4721) on Monday April 23 2018, @12:45AM (#670552) Journal

                      I acknowledge having misread one of the words in your prior post. Please allow me to try again.

                      If the code does something important and does it properly then it's unlikely to be difficulty to port.

                      Who bears responsibility for spending the time=money to port each application's graphical front-end to each operating system's own graphical user interface toolkit, particularly for the benefit of non-technical users who have no interest in learning how to (say) write a makefile?

          • (Score: 2) by Justin Case on Sunday April 22 2018, @08:54PM (3 children)

            by Justin Case (4239) on Sunday April 22 2018, @08:54PM (#670477) Journal

            What's better: a script delivered over HTTP or a native application delivered over HTTP?
            What's better: a script that you can't run because you have disabled script in the browser or a native application that you can't run because it is compiled for a different operating system?

            What's better: being shot in the head with a rifle or a pistol?
            I'll take neither for $1000, Alex.

            Try to remember that HTML is a document specification language with optional formatting suggestions that users are free to ignore if, for example, they are blind.

            Trying to shovel shit into a soda straw is probably a fundamentally broken plan.

            • (Score: 2) by Pino P on Monday April 23 2018, @12:35AM (2 children)

              by Pino P (4721) on Monday April 23 2018, @12:35AM (#670546) Journal

              For the purpose of argument, let us assume that HTML is a document specification language. Thus if a work is a computer program, not just a document, the program ought not to be delivered in a form contained by HTML. Given the preceding, in what not-HTML form should the program instead be delivered so that less-technical users of Windows, macOS, X11/Linux, iOS, Android, and Chrome OS can execute it?

              • (Score: 2) by Justin Case on Monday April 23 2018, @02:18AM (1 child)

                by Justin Case (4239) on Monday April 23 2018, @02:18AM (#670576) Journal

                First of all, accepting executable code from strangers is dangerous. It should be done rarely, and it should not be easy.

                Now, then, the appropriate place to get executable code, on the rare occasions when that is necessary, is from repositories you trust. Various linux distros have things like "apt-get" or "yum update". These cryptographically verify the publisher using previously accepted identities. MacOS has something similar. Windows is a lost cause.

                • (Score: 2) by Pino P on Tuesday April 24 2018, @12:41AM

                  by Pino P (4721) on Tuesday April 24 2018, @12:41AM (#670957) Journal

                  Now, then, the appropriate place to get executable code, on the rare occasions when that is necessary

                  I disagree with your claim that desire to use applications not shipped with an operating system is (with emphasis) rare. Say someone wants to use a whiteboard application to draw-chat with other people over the Internet. What is the standard protocol for an Internet whiteboard that allows users of different native whiteboard clients to send strokes to one another for draw-chat, much as people use different native IRC clients to send lines of text to one another for text-chat?

                  [Package managers on GNU/Linux] cryptographically verify the publisher using previously accepted identities.

                  One might consider relying on the publisher of the distribution to also publish the application. But in general, distributions' policies allow this only for applications distributed as free software, and for some fields of use, a business model based on free software licensing has not yet been demonstrated. Such fields of use include at least nontrivial video games, playback of rented movies, and tax return preparation [pineight.com]. In such a situation, what should the publisher of a computer program do to make his identity worthy of acceptance?

                  MacOS has something similar.

                  Which requires the publisher to have the time and money to port the application to macOS. Even if the application is distributed as free software in source code form, source code relying on Win32 or X11 headers for compilation and Win32 or X11 libraries for linking will not build and run in a stock installation of macOS. Would you find it fair to make a web application available without charge but put the corresponding native application behind a paywall to cover the cost of porting it to macOS and distributing it through Mac App Store?

                  Windows is a lost cause.

                  What steps should a publisher of an application take to work around this "lost cause"?

  • (Score: 2) by Arik on Saturday April 21 2018, @04:27AM

    by Arik (4543) on Saturday April 21 2018, @04:27AM (#669946) Journal
    Yes, yes there is. Once you allow just a little bit of it, you have to have an interpreter built into the browser, and once you do that, they won't stop with just a little bit.

    But on the topic of Flash, there's nothing wrong with it, it just should never have been put into the browser. And Adobe not only insisted on putting it in the browser, they did their darndest to force it to ONLY run there, even going so far as yanking the standalone interpreter and ONLY offering it for download as a browser plugin.

    So Flash is gone but Adobe is sticking around, I know people are celebrating the first and I can understand why, but I'd much rather see Flash free and sticking around, while Adobe could die horribly and that would be just fine.
    --
    If laughter is the best medicine, who are the best doctors?
  • (Score: 4, Interesting) by FatPhil on Saturday April 21 2018, @08:28AM (4 children)

    by FatPhil (863) <reversethis-{if.fdsa} {ta} {tnelyos-cp}> on Saturday April 21 2018, @08:28AM (#670010) Homepage
    Absolutely - *enhancing*. Anyone who does in JS what can be done in raw HTML such that it's not being done in the HTML any more should just die.

    I had an argument last night with someone about a website we both use. I was claiming that it was very broken because when I say "GET uniquely/identified/resource" to the webserver, I expect information on that uniquely identified resource. The website instead sends a blank page with JS that then performs about 20 different GETs of utterly irrelevant data, and one highly obuscated GET that returns even more obfuscated data pertaining to that uniquely identified resource, and then using JS it smooshes it around to present it to me in the browser window. How anyone could think that is superior to just getting the fucking data I asked for in the first place, I don't know. Unfortunately raw data isn't swipey enough, or something.

    Get orf moi lorn!
    --
    Great minds discuss ideas; average minds discuss events; small minds discuss people; the smallest discuss themselves
    • (Score: 4, Funny) by The Mighty Buzzard on Saturday April 21 2018, @12:48PM (2 children)

      by The Mighty Buzzard (18) Subscriber Badge <themightybuzzard@proton.me> on Saturday April 21 2018, @12:48PM (#670034) Homepage Journal

      Hey now, there's nothing wrong with swiping. Like swiping the phone batteries of people who think like that.

      --
      My rights don't end where your fear begins.
      • (Score: 3, Interesting) by MichaelDavidCrawford on Saturday April 21 2018, @03:25PM (1 child)

        by MichaelDavidCrawford (2339) Subscriber Badge <mdcrawford@gmail.com> on Saturday April 21 2018, @03:25PM (#670074) Homepage Journal

        Back in 1990 someone swiped all the memory from all the macs in my building.

        The security guards were convinced the culprit was an Apple employee but their company instructed them to search only us contractors when we left the building

        --
        Yes I Have No Bananas. [gofundme.com]
        • (Score: 2) by toddestan on Sunday April 22 2018, @03:32AM

          by toddestan (4982) on Sunday April 22 2018, @03:32AM (#670233)

          Considering how difficult it was to service those early Macs, removing the ram from all from a bunch of them without getting caught I'm sure was no easy task.

          Probably was an Apple employee now that I think about it.

    • (Score: 0) by Anonymous Coward on Saturday April 21 2018, @07:42PM

      by Anonymous Coward on Saturday April 21 2018, @07:42PM (#670146)

      so uh hey

      you never said what the someone said that made you argue. I expect information on that uniquely identified resource, but you talked about 20 different things of mostly irrelevant data to make him look bad and then never actually presented that info.

      you been reading too much javascript code or something?

  • (Score: 2) by MichaelDavidCrawford on Saturday April 21 2018, @03:31PM (2 children)

    by MichaelDavidCrawford (2339) Subscriber Badge <mdcrawford@gmail.com> on Saturday April 21 2018, @03:31PM (#670076) Homepage Journal

    Example:

    http://soggy.jobs/computer/united-states/washington/king/seattle/ [soggy.jobs]

    This would be easy to do in HTML with a web application but I've been building the site by hand

    http://soggy.jobs/js/tiger-stripe.js [soggy.jobs]

    And yes "tiger stripe" is the correct term for this

    --
    Yes I Have No Bananas. [gofundme.com]
    • (Score: 4, Interesting) by JNCF on Saturday April 21 2018, @04:24PM

      by JNCF (4317) on Saturday April 21 2018, @04:24PM (#670097) Journal

      CSS selectors can handle that now. [w3schools.com] Another option would be making your site in some programming language and writing the html to a text file that you host, so that your code doesn't have to execute before rendering properly. I do sometimes argue for JavaScript, but I'm not convinced by this use case.

    • (Score: 3, Informative) by The Mighty Buzzard on Saturday April 21 2018, @04:25PM

      by The Mighty Buzzard (18) Subscriber Badge <themightybuzzard@proton.me> on Saturday April 21 2018, @04:25PM (#670098) Homepage Journal

      Dude... That's not any more difficult to do server side in whatever source language you're using to generate the pages. And it effectively makes that algorithm that would have more or less been run O(1) times per page (memory or web caching) into one that's run O(N) times, though not on your server. That wastes power and makes your page unfriendly to users with javascript turned off.

      --
      My rights don't end where your fear begins.