nesdev.org

[url=http://forums.nesdev.com/viewtopic.php?p=174830#p174830]Earlier[/url], tepples wrote:Without JavaScript or WebAssembly, OS-independent rich apps would have to run in an x86-64 VM instead.
Sites are broken in Safari because not every web developer can afford a separate computer just for testing on a 2% browser.

Recent discussions about scripting in the browser both here and on another forum have inspired me to flesh out the reasoning behind this.

In [url=http://forums.nesdev.com/viewtopic.php?p=176047#p176047]this post[/url], Hojo_Norem wrote:

koitsu wrote:And stop using Internet Explorer for god's sake -- still the #1 vector for malware and viruses that I know of.

I can't agree more! My choice of poison is Firefox with noscript.

Yeah, it does make using some sites a little bit of a bother when I'm paranoid enough that I rarely whitelist a domain.

But if I have to enable a dozen seemingly unrelated domains to to access one page, do they really deserve my traffic in the first place?

I'm in the middle of a discussion on Slashdot with some members of the vocal minority who are against any use of JavaScript on the web. My understanding of their position is as follows:

Purist: "Whitelist nothing because 'web applications' should never have existed in the first place. Websites should be static, or have HTML forms at the most, and applications should be native. Screw Pirates Love Daisies, screw Cookie Clicker, and screw JSNES and em-fceux."

Me: "This means you'd miss out on ability to use applications whose developer happens to use a different operating system from your own."

Purist: "The developer can instead use cross-platform middleware, such as Qt, Unity 3D, or some classic game console for which Free emulators exist, to build a cross-platform app."

Me: "The developer would still need to buy a Mac to build the Mac version of a native application using a cross-platform library, and not all hobbyists and startups can afford that for launch day."

Purist: "It's no different from a developer having to buy a Mac to test a web application in Safari. There are several things that work in Chrome but break in Safari. And it wouldn't be a cost in the first place had you chosen Macs for your developers in the first place instead of Lenovo or HP."

Me: "But Safari isn't quite as important because a Mac's owner can choose to run Chrome or Firefox instead. Recent stats from caniuse.com show Safari for Mac at about 2 percent of usage share. I imagine that a lot of hobbyists are stuck with the hardware they had before the project began. And had you chosen a Mac, you'd still have to spend $120 for a retail Windows license for each Mac. At least with web applications, Microsoft offers feature-limited virtual machine images with IE 11 and Edge without charge."

Purist: "A user who cannot make use of the provided executable can still make use of 1. the list of features, 2. documentation, 3. the bug tracker, 4. the developer's blog, 5. things made with the application that its users have chosen to share publicly, and 6. complete corresponding source code so that he can port it."

Me: "A fully public bug tracker for a game might enable users to cheat by reading bugs and trying to reproduce them. And not every project's business model is aligned with distribution as free software. Some fear the ability to make a rebranded port, make it available on a separate website, and take all the credit and revenue."

So I suggested distributing an application as a disk image containing a very stripped-down Linux* distribution bundled with your app, which users of other operating systems can run in a virtual machine. But is that such an improvement over JavaScript running in a virtual machine? Do I fundamentally misunderstand something here?


* Size-optimized Linux is often not GNU/Linux, as it uses BusyBox instead of Bash and Coreutils, and Newlib, Bionic, or uClibc instead of glibc.

Assuming that the objection to allowing JavaScript to execute is that it's a compromise to computer security, isn't it a bit ironic that each solution grows closer to running the software on bare metal?

Part of it is frustration with websites pulling in tracking and ad delivery scripts from over a dozen different domains. People can't just set-and-forget a policy to block all scripts from a different domain for a couple reasons. For one thing, sites are intentionally serving static resources from different domains, such as Google's gstatic.com, Stack Exchange's sstatic.net, Yahoo's yimg.com, and the like, so that domain-wide cookies don't get sent with each request. For another, sites are using Google's copy of jQuery or other shared CDN-hosted resources to take advantage of the likelihood that a user has recently visited another site using the same cached copy.

Part of it is a perception that tools to put native apps in an OS-level sandbox are more robust, better understood, or more CPU-efficient than tools to control scripts' privileges in popular web browsers. A power user might have experience with OS-level tools to control activity of a native application, such as chroot or a FreeBSD jail. This includes what parts of the file system it can read and write as well as to what extent it is allowed to connect to the Internet. In theory, a browser could enforce similar policies. But in practice:

Some virtual machines have escape vulnerabilities. Exploiting one of these allows the guest to cause execution of arbitrary native code in the user's context on the host. ZSNES's implementation of the SA-1 coprocessor had an escape vulnerability at one point. Perhaps one argument for native code is that malware would have to trigger two such vulnerabilities: one in the operating system to elevate to the superuser and another in the virtual machine itself to elevate to the host. Chrome, IE, and Edge partially mitigate any unknown escape vulnerabilities they may have by using an additional OS-level sandbox to restrict what calls the browser can make. Firefox doesn't for some reason.

And part of it isn't containment mechanisms as much as the automatic decision of which programs to run. Some people, for example, might want to enforce a policy of running only scripts licensed as free software, for which there is a browser extension called LibreJS. Some people want to run exactly the same code that they ran last time, which isn't possible with web applications (or even with native applications with an automatic update feature, for that matter).

I rather agree with tepples, and what Jason Scott wrote about earlier (last year maybe). The Web should have stayed as a content-delivery system, and any scripts should have stayed running server-side and returned information in a web interface. Actual executable programs (OS/CPU-specific but oh well) should have stayed downloadable on request by the user.

The situation that we are in now is a parody of that ideal, with the user having near-zero control over what runs on their computer over their internet connection, having been blackmailed into allowing apps/trackers full access lest they become unable to view any major, modern site on the web.

Well, Jason put it more eloquently.

There are things you can do in order to work-around inability of some web-pages to work without scripts enabled. Sometimes this just requires client-side user CSS. I use Firefox with userChrome.js and GreaseMonkey and Stylish other extensions in order to disable content scripts in most places, sometimes replacing with my own script. I mainly prefer to work on command-line though.

Of course whoever publishes the program has their own choices of how to do so, although file formats meant for interchange should be openly documented. You can publish as more than one way if you want to (for example, provide a .NES file, but also provide a HTML+JS implementation of the emulator; there are also other VMs, and sometimes you can compile into more than one). And, making program FOSS is even more better because it makes it easier to port to other systems and to modify the program. C programs also often can be ported to other systems. JavaScript also you can have common codes, and then have separate HTML and Node.js versions (and possibly other hosts too such as Synchronet or PhoneGap), and some files are separate for the versions and the other files are common for all versions.

In some cases there are services on internet to access send/receive data; such protocols as SMTP and NNTP and so on are good; even HTTP can do well (it has PUT and DELETE and POST for sending, for example). In some cases it is data which you want to query from a remote server. Data which does not change often can be published as a file in some format (e.g. CSV (comma separated), TSV (tab separated), ARF (ASCII records format), JSON, RDF, SQLite, etc) and optionally also provide a API and/or HTML and/or gopher menu and/or telnet to query it. For data that does change often it would be useful to have direct query access that you can specify (at least part of) the search criteria to the server; again such things as JSON or TSV can be used, or the other idea I had, to make some kind of protocol that a SQLite virtual table module could connect to the server by internet and send the parts of the WHERE and ORDER BY clause (it ought to support LIMIT and OFFSET too, but SQLite virtual tables can't consume those) that it can to the server, and request the result as SQL data so that you can then use your own programs to do backups, queries, combination queries with other data sources, etc.

WWW is really a huge mess.

tepples wrote:So I suggested distributing an application as a disk image containing a very stripped-down Linux* distribution bundled with your app, which users of other operating systems can run in a virtual machine.

Or you could just use Java to the same effect =P

The problem is that:

1) People don't know where to stop and it got to the point that scripts are about as large and complex as native programs (when they were originally supposed to be just the bare minimum needed to do the job). Seriously, disable javascript and watch how the browser becomes fast as heck. It was all javascript overload.

2) Computers these days pretty much contain our whole lives at this point, and now the money is in exploiting that to mine data about everybody. This is not specific to sites, practically every app on mobile suffers from this as well (and way more blatantly, even). Not having javascript wouldn't stop this, they'd have looked for other ways to do it (albeit javascript certainly helps them). Also good luck finding a site that doesn't have Google Analytics in it, even stupid joke pages that are just an image have it these days o_O

3) I did wonder what would happen if scripting never was a thing, would we finally get proper menus that can be opened and closed by definition of its HTML element? (reminder: <details> was never implemented and got deprecated) But probably what would have happened instead is that Flash sites would still be alive today, making the situation even worse ¯\(º_o)/¯


By the way, on the collolary of this whole discussion: every time some web service comes up on internet, it usually means we had failed to create a proper standard protocol to fill said need. Food for thought.

Sik wrote:3) I did wonder what would happen if scripting never was a thing, would we finally get proper menus that can be opened and closed by definition of its HTML element?

We already have something close to that: the CSS3 checkbox hack. Put a hidden checkbox in an element, make the hide/show control a label for that checkbox, and then use "sibling of a checked checkbox" as a selector to change the appearance of other nearby elements.

By the way, on the collolary of this whole discussion: every time some web service comes up on internet, it usually means we had failed to create a proper standard protocol to fill said need.

First, non-programmer end users wouldn't know what to do with "a proper standard protocol" if they had one.

Second, a lot of these services are too specialized for the full IETF standardization process to be useful to them.

Third, these web services tend to require all app developers to register beforehand to obtain OAuth client credentials as a way of disabling apps that spam, cause excessive load, or otherwise break the service's rules. Twitter, for example, is known to revoke credentials that leak to the public, and it reserves the right to ban developers whose credentials leak repeatedly. So how is an app that needs client credentials supposed to be distributed to the public without leaking the credentials to anyone who can run strings? Raffi Krikorian and Chris Steipp seem to think everyone who downloads a desktop app is supposed to register as a developer and then register his individual copy of the app. Is that really practical? It isn't for 13 to 17 year olds, as I mentioned elsewhere.

Sik wrote:By the way, on the collolary of this whole discussion: every time some web service comes up on internet, it usually means we had failed to create a proper standard protocol to fill said need.

You do not necessarily need a separate protocol for each service; there are many protocols: Gopher, Telnet, HTTP, NNTP, SMTP, IRC, etc. But I suggested we should need another protocol for the database access, which would be the SQLite remote virtual table protocol.

Different protocol can be good for different purpose, such as Telnet/SSH for interactive services, Gopher for accessing the files in organization (including queries), HTTP for uploading/downloading (including queries) and can support headers to add additional data (such as timestamps and authentication), IRC is good for live chat, etc.

tepples wrote:...Twitter, for example, is known to revoke credentials that leak to the public, and it reserves the right to ban developers whose credentials leak repeatedly. So how is an app that needs client credentials supposed to be distributed to the public without leaking the credentials to anyone who can run strings? ...

My own idea was to either proxy it, or if an HTML interface is available to screen-scrape it.

Not everything has Google Analytics. Even if it does, you may be able to block it specifically even if you do not want to block all scripts (I block all scripts by default and then use a whitelist, but you can also blacklist if you prefer).

Should web apps have existed in the first place?

<marquee><blink>No.</blink></marquee>

I apologize for having mistakenly asked this question in a manner that admits a yes-or-no answer. Please forgive me for having moved the goalposts.

If not, then what method of deploying one application to users of Windows, Windows Phone, macOS, iOS, X11/Linux, and Android is preferable?

My stance is that they shouldn't be butting into HTML in a way that makes HTML…not HTML. I'm running into increasing numbers of pages that don't even try to have a fallback and just deliver nothing, if the user is unwilling to run their code.

Would you be willing to pay for a fallback? For example, if the in-browser JavaScript version of an Internet app can be used without charge but the downloadable version requires payment, would you pay, or would you instead whine? Even more specifically, if an NES game can be played either in JSNES or by buying a cartridge, would you buy a cartridge?

At least for me, the objection is web apps is not so much "why do I have to use Google Docs instead of Word" but more "why is it that I can no longer read approximately 1/3 of blogspot journals without running arbitrary (if sandboxed) code? why can I no longer read any microsoft knowledgebase articles without running arbitrary (if sandboxed) code?"

Objecting to javascript here is a complaint about people ruining the web's ability to convey hypertext, most often in the pursuit of more advertising revenue.

Without ads, sites would probably put up more paywalls.

How about this one: In-browser NSF player, where JavaScript takes far less server resources because it doesn't have to render to wave and compress it to MP3 or AAC. This takes not only CPU on the server side but also patent royalties for the encoder, as Vorbis is unsupported in Safari and other WebKit wrappers.

It's not like it's an unmitigated evil.

It's just that
• metrics only can show you what you are measuring
• by not gracefully degrading you basically eliminate any possibility of using a web browser other than one of the major engines
• difficulty in reimplementing things causes difficulty in validating things. Difficulty in either leads to everyone using the same undervalidated code (e.g. OpenSSL)
• modern advertising (attention-stealing, privacy-invading) is basically the very definition of a tragedy of the commons

It's an objection to how web browsers now have to include a javascript runtime to access content that could be (and used to be) served without.

The calculus of whether a website can (or should be allowed to) support itself with advertising revenue is a separate argument, even if vaguely entwined.