zzo38computer

I did not mean that you have to introduce an extra dependency; the programming language used to make such a configuration can be the main language of the application. Although whoever needs to configure it can be someone other than whoever wrote it, and they can use whatever they want to use. The output can then be used as the configuration even on a different computer if it is not necessary to change the configuration but only use it on multiple computers. This will be appropriate for some uses but for other uses it will not be appropriate. Note also that different programs will have different requirements for what kind of configurations you will require.

For the reasons you mention (mainly the first one), it can sometimes be useful to use a separate programming language with functions that are used to create the required format, without needing the configuration format itself to do these things.

PostScript is not so bad as a programming language, and it has a binary format as well as a text format, although the limits of numbers and some other things can be too small for many applications. The syntax of TER is based on PostScript (although it is not actually compatible, for many reasons; for example, the syntax "1.0" does not denote a number in TER, but "+1.0" does).

Only if the page is inside of a ZIP archive stored on the local computer and only if the link is to a picture within the same ZIP archive. (However, it would be good to have an option to disable inline display even in that case.)

MAML is an improvement from JSON, but does not improve the data types much (although it does make one improvement, which is that it distinguishes integers from floating point), although the syntax is improved.

Depending on the kind of configuration, different formats might be helpful.

I made up TER, which supports all ASN.1 types (although in some cases there is not a built-in syntax for them and you must write them in terms of other types; however, extensions can be made for your specific application) and is not limited to Unicode, nor does it limit integers to 64-bits (and you can write integers in any base up to thirty-six). You can convert TER to DER (I wrote a program to do this; it is not really intended for an application to use the full specification of TER itself except for using an external program to convert to DER and then use that instead), and you might also make a subset of TER for specific applications.

But, like any other one, it also has advantages and disadvantages (including some that are mentioned in that article; if they look at TER they would probably have criticisms about that too).

There are two kind of criticisms with JSON, having to do with the data types, and having to do with the syntax, and I had mentioned some of these in the past (some of them are commonly mentioned by others too, but some are less commonly mentioned by others).

Another configuration format is the X resource manager format.

I had a different set of criticisms, such as: mandatory TLS, no file size in the response, no range requests, etc. (I made up my own in order to address these and some others.)

I agree that fonts should not be specified by the document, although it would make sense to specify that you want a fixpitch font, or emphasis font. Pictures within the document might make sense (especially if you want to print it out); video/audio would be better as a separate file that you can link to, and display using a separate program.

Yes, what I meant (one way to handle what the author proposed; possibly not exactly what they meant) is that many of these "building blocks" can be made from wasm (although I have some criticism of that too, nevertheless, it will do), and many will be included by default, and others would be set up by the user if desired. Native code extensions (e.g. .so files) would also be possible but is not needed for most things, and if you set up from the app store or from stuff specified by the document or server then only sandboxed VM codes would be possible and native codes would not be allowed in those circumstances.

XHTML does have some advantages compared with ordinary HTML, such as the parsing being more consistent, since the file will specify where literal text is used and which commands are or are not a block that is expected to contain other things.

(It could still try to render in case of an error, but display the error message as well, perhaps.)

> put binary blobs in your browser outside the security sandbox

There are reasons to do this sometimes, but usually it would be better to put them inside of the security sandbox (if the security sandbox can be designed in a good way).

The user (or system administrator) could manually install and configure any native code extensions (without needing to recompile the entire browser), but sandboxed VM codes would also be available and would be used for most stuff, rather than the native code.

XML is not so good for most of the things it was used for, and JSON has some problems too (I prefer DER), but Google is doing many bad things with WWW and not only things relating to XML, whether or not XML is good.

If you really want to improve the simplicity, there are better ways to do so rather than excluding Gopher.

(Also, they could make XSLT (and many other things that are built-in) into an extension instead, therefore making the core system more simpler.)

I like the idea they mentioned of "a browser made up of composable components, protocol handlers separate from primary document renderers separate from attachment handlers", and I had the same idea. (Not all browsers will have to be implemented in this way, and they are not necessarily all the same, but this can be helpful when you want this.)

There can be two kind of extensions, sandboxed VM codes (e.g. WebAssembly) and native codes; the app store will only allow sandboxed VM codes, and any native codes that you might want must be installed and configured manually.

There is also the issue of such things as: identification of file formats (such as MIME), character sets, proxies, etc.

I hade made up Scorpion protocol and file format which is intended to be between Gemini and "WWW as it should be if it was designed better". This uses ULFI rather than MIME (to avoid some of the issues of MIME), and supports TRON character code, and the Scorpion conversion file can be used to specify a way to handle unknown file formats (there are several ways that this can be specified, including by a uxn code).

So, an implementation can be versatile to support things that can be useful beyond only MIME and Unicode etc.

Adding some additional optional specifications to WWW might also help, e.g. a way to specify that certain parts of the document are supposed be overridden by the user specifications in the client when they are available (although in some cases the client could guess, e.g. if a CSS only selects by HTML commands and media queries and not by anything else (or no CSS at all), then it should be considered unnecessary and the user's specifications of CSS can be used instead if they have been specified). Something like the Scorpion conversion file would be another possibility to have, possibly by adding a response header.

The previous "Google is killing the open web" article also mentions some similar things, but also a few others:

> in 2015, the WHATWG introduces the Fetch API, purportedly intended as the modern replacement for the old XMLHttpRequest; prominently missing from the new specification is any mention or methods to manage XML documents, in favor of JSON

Handling XML or JSON should probably better be a separate function than the function for downloading files, though. (Also, DER is better for many things)

> in 2024, Google discontinues the possibility to submit RSS feeds for review to be included in Google News

This is not an issue having to do with web browsers, although it is related to the issues that do have to do with web browsers (not) handling RSS.

> in 2025, Google announces a change in their Chrome Root Program Policy that within 2026 they will stop supporting certificate with an Extended Key Usage that includes any usage other than server [...]; this effectively kills certificates commonly used for mutual authentication

While I think they should not have stopped supporting such certificates (whoever the certificate is issued to probably should better make their own decision), it is usually helpful to use different certificates for client authentication anyways, so this is not quite as bad as they say, although it is still bad.

(X.509 client authentication would also have many other benefits, which I had described several times in the past.)

> in 2021, Google tried to remove [alert(), prompt(), and confirm()], again citing “security” as reason, despite the proposed changes being much more extensive than the purported security threat, and better solutions being proposed

Another issue is blocking events and JavaScript execution (which can sometimes be desirable; in the case of frames it should be better to only block one frame though), and modal dialog boxes potentially blocking other functions in the browser (which is undesirable). For the former case, there other other things that can be done, though, such as a JavaScript object that controls the execution of another JavaScript context which can then be suspended like a generator function (without needing to be a generator function).

I think it might make more sense to use WebAssembly and make them as extensions which are included by default (many other things possibly should also be made as extensions rather than built-in functions). The same can be done for picture formats, etc. This would improve security while also improving the versatility (since you can replace parts of things), if the extension mechanism would have these capabilities.

(However, I also think that generally you should not require too many features, if it can be avoided, whether those features are JavaScripts, TLS, WebAssembly, CSS, and XSLT. However, they can be useful in many circumstances despite that.)

There are separate URLs for "https:" vs "http:" although they are usually the same content when both are available (although I have seen some where it isn't the same), although the compression (and some other stuff) is decided by headers. However, it might make sense to include some of these things optionally within the URL (within the authority section and/or scheme section somehow), for compression, version of the internet, version of the protocol, certificate pinning, etc, in a way that these things are easily delimited so that a program that understands this convention can ignore them. However, that might make a mess.

I had also defined a "hashed:" scheme for specifying the hash of the file that is referenced by the URL, and this is a scheme that includes another URL. (The "jar:" scheme is another one that also includes other URL, and is used for referencing files within a ZIP archive.)

I would guess it would be so that you can read the comments.

Does it work if you disable favicons? (I disabled favicons when I set up the computer, but for a different reason; it is a feature that I don't use.)

If adb is unrestricted and can work with the Linux command shell (something I seem to remember I had read about before; you will need to enable the developer mode to use it), which is aparently a separate system but runs on the same device, although if it has the ability to communicate with the main Android system using adb (which it might be reasonable to require that to be explicitly enabled with another setting, for additional security in case you do not use adb), then this would help since you do not require another computer that would be compatible with adb in order to do it.

However, I think there are other things they should do as well (in addition to the other things) if they want to improve the safety, such as looking at the apps in Google Play to check that they are not malware (since apparently some are; however, it says they do have some safeguards, so hopefully that would help), and to make the permission system to work better (e.g. to make it clear that it can intercept notificatinos; there are legitimate reasons to do this but it should require an explicit permission setting to make this clear).

OK, but I don't know how you would integrate it with an existing file descriptor. (It is why I suggested using a environment variable to manage this.)

I do not understand very well what you mean.

That can be helpful, although JSON is still a bad format for this, especially since now it requires base64 encoding. People think JSON is a good format but it isn't. (MIME is also not a very good format for identifying file formats, since you can only specify one format; although there is a "added on" specification like "+zip" and "+der" this isn't very good.)

Structured output would be helpful in many ways, but JSON is not a good format for this (neither is YAML nor XML nor HTML).

> JSON's not perfect but (non-minified) it's human-readable enough to address the basic issues here without jumping all the way towards binary or (shudder) HTML

It does not address most of the real issues. Programs that deal with pictures, sounds, non-Unicode text, structures of the kinds that JSON does not have, etc, will not do as well; and the input/output will involve converting escaping. (One format that I think is better is DER, although, it is binary format. I did write a program to convert JSON to DER, though.)

There are many downsides.

There are problems with using JSON for this; other formats would be better. JSON needs escaping, cannot effectively transfer binary data (other than encoding as hex or base64), cannot use character sets other than Unicode, etc. People think JSON is good, but it isn't.

Also, you might want to use less or other programs for the text output, which might be the primary output that you might also want to pipe to other programs, redirect to a file (or printer), etc. This text might be separate from the status messages (which would be sent to stderr; these status messages are not necessarily errors, although they might be). If you use --help deliberately then the help message is the primary message, not a status message.

(In a new operating system design it could be improved, but even then, JSON is not the format for this; a binary format would be better (possibly DER, or SDSER, which is a variant of DER that supports streaming, in a (in my opinion) better way than CER and BER does).)

(Another possibility might be to add another file descriptor for structured data, and then use an environment variable to indicate its presence. However, this just adds to the messiness of it a little bit, and requires a bit more work to use it with the standard command shells.)

Collaboration can be excessive, but it can also sometimes be helpful.

For example, if a draft is made available for someone else to review, then someone can comment in case they find something wrong that the original author does not (it is also possible that the original author might find something later that was not originally found).

I think that might work OK.

Passing the process ID and user ID might be helpful to improve security of the terminal emulator, too. If the sidechannel is a UNIX socket then it will do this (with SCM_CREDENTIALS), as well as pass file descriptors (with SCM_RIGHTS).

I think JSON would not be the good format for this; it is too limited and requires escaping. DER or SDSER might be a better format; numbers can be stored efficiently in binary, no escaping is needed, you can use any character set (not only Unicode), binary data can be stored directly (rather than needing to encode as hex or base64), etc.

I had thought of a idea in a operating system design, which has many similarities to this but also many significant differences. The rest of the operating system would also be designed to support this, and the REPL would also be integrated with editors (like they show) and with a zoned spreadsheet. There would also be transactions (not the same as described there, but there is a similarity), and also capabilities (usable for security and many other things), and possibility to move objects between windows (this also allows it to work better with GUI; e.g. you can write a loop and use some combination of keys with mouse to drag a command button from a GUI window into your text in order to execute that command button within the loop; or you can copy data displayed in a table in another program in order to perform calculations on it or write a conversion to other format to then copy into another program, etc). However, tabs and panes would be handled by the window manager. However, it would use a binary format (a kind of TLV format), and it would not use CSS and HTML and Unicode. For rich text and other things there would also be a Reveal Codes function in order to reveal (and modify) the codes.

> I have no problem with enabling smartphone-based payments and passes for people who like them, but companies should not be allowed to block out (or charge extra to) others who prefer not to tether themselves to a phone.

I agree with this. (The same would apply to restaurant menus.)

(In the case of restaurant menus, they could post a single copy near the entrance or somewhere that it can be seen by everyone in case they do not want to make multiple copies (and do not want to waste paper). E-paper displays might be used in case they sometimes change.)

> What happens if your phone is stolen, broken, discharged?

Another comment says that if any of those apply (or if you do not have a (compatible) smart phone) then you can still receive a boarding pass at the airport, although it seems that you will still need check-in online.