SoylentNews is people
SoylentNews
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.
This discussion has been archived.
No new comments can be posted.
Flash Used on 5% of All Websites, Down From 28.5% Seven Years Ago
|
Log In/Create an Account
| Top
| 58 comments
| Search Discussion
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Fascinating is a word I use for the unexpected.
-- Spock, "The Squire of Gothos", stardate 2124.5
(Score: 2) by Justin Case on Sunday April 22 2018, @01:48PM (12 children)
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)
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?
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?
(Score: 2) by Arik on Sunday April 22 2018, @05:50PM (6 children)
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)
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)
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)
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)
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
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.
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
I acknowledge having misread one of the words in your prior post. Please allow me to try again.
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)
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)
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)
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
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?
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?
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?
What steps should a publisher of an application take to work around this "lost cause"?