zzo38computer

I might have misremembered then, or maybe it was someone else.

I do not use the ASN.1 schema format, and have not written a specification for how the new ASN.1X features would be used in the ASN.1 schema format, although someone who is interested to do so might be able to help to write such a thing. (An alternative might be to make up a different schema format for use with ASN.1X.)

ASN.1X is mostly just a list of additional types, although there is also another serialization format called SDER which is between BER and DER (any valid DER is also valid SDER and any valid SDER is also valid BER), and is intended for when you do not quite need a canonical form but still want the simplicity of DER; one of the things that it allows is overlong length encodings (which is useful when the encoder wants to encode items to a file individually but then go back to encode the length afterward).

The additional types include:

- UTF-16 string: Same as BMP string but non-BMP characters are also allowed (as surrogate pairs). The type number is the same as BMP string.

- OBJECT IDENTIFIER RELATIVE TO: Either a absolute or a relative object identifier; what it is relative to might be either fixed or given elsewhere in the data, depending on the schema. This is equivalent to a type given in the appendix of the official specification of ASN.1, except that it is now a standardized type, and the canonical form (even in SDER, so that a reader does not need to check for both cases) is required to use the relative format if possible.

- BCD string (64): A string of 4-bit characters, with the high nybble first in each byte. The characters come from the character set 0 1 2 3 4 5 6 7 8 9 * # + - . space and it should be padded with a space on the end if necessary.

- PC string (65): A string of characters in the PC character set (or a related character set in some cases). Note that control characters can also be used as graphic characters.

- TRON string (66): A string of TRON characters, encoded as TRON-8.

- Key/value list (67): A set of keys (without duplicates) with associated values. The keys and values can be any type allowed by the schema. In canonical form, they must be sorted by keys in the same order that a SET is sorted (but the values are kept with the corresponding keys). (This is the only one of these nonstandard types which is used for representing JSON data; all of the other JSON types correspond to standard ASN.1 types.)

- Out of band (72): The format and usage of this type depends on the communication channel being used, and is intended for including things inside of the ASN.1X data which is separate from the ASN.1X data, such as file descriptors. This type is not intended for storage in files, and some programs that relay messages may need special handling of this type if it is used (for this reason, it should not be IMPLICIT).

- Reference (74): A reference to another node within the same file (schemas may restrict which nodes can be referenced). The encoding is like a relative OID but the first number is how many times to go to the parent node (0 means the reference itself), and then the rest of the numbers are the zero-based index into the node referenced by the previous number.

- Identified data (75): Contains a set, followed by the payload (of any type), followed by an optional key/value list where the keys are OIDs. The set is used to identify the format, and it can contain OIDs, object descriptors (only expected to be used in error messages and stuff like that), and sequences who first element is a OID; and should not have duplicates. This type may be used as the top-level type in a file in order to identify the file format, but can also be used inside of the file in case the existing types are considered to be insufficient for this purpose.

- Rational number (76): Contains two integers, being the numerator and denominator. The denominator must be greater than zero. If it is canonical form, then it must be lowest terms.

- Translation list (77): A key/value list where the keys specify the languages (null means the default), and is expected to be used where it could be replaced by the appropriate value according to the l10n.

- Scientific number (78): Same as a real number except that the number of digits (or bits) is considered to be significant. Decimal numbers must be NR3, and if it is canonical form then there must be exactly one digit before the dot.

There are also additional situations where the standard ASN.1 schema format does not seem to specify (although as I mentioned above, there is currently no standardized schema format for these things), such as: regular expressions for octet strings (and bit strings), constraining types as though it is another type (e.g. limiting a UTF-8 string to a number of bytes instead of (or in addition to) code points), constraints about what control characters are allowed in a General string (I think it is rarely useful to allow all control characters), etc. (Also, I disagree with the standard recommendation to use automatic tags; I think that manual tags are better and make both the schema and the data files clearer and easier to understand.)

I seem to remember reading somewhere that Marilyn vos Savant had said that it is acceptable to use a calculator when learing arithmetic (I do not remember the reason given) but that clocks should not be used to learn time. (I might be mistaken, since I do not remember for sure.)

In my opinion, JSON is not the best format and has some problems. Lack of comments is one of the reasons, as they mention in there. Another is the lack of trailing commas (optional trailing commas would be useful for manually written files). However, these are problems with the syntax, and there are also problems with the data, such as a lack of a proper integer type, lack of Infinity and NaN, lack of support for character sets other than Unicode (and ASCII), lack of proper octet string type, etc.

That is not quite true, because you have to define "numbers" and "strings" more specifically; JSON uses Unicode strings, and how numbers work depends on the implementation (but are generally finite 64-bit IEEE floating point; JSON does not have Infinity and NaN).

ASN.1 is almost a superset, but lacks a key/value list type; I had made some nonstadard extensions called ASN.1X and one of my new types is a key/value list type, so that makes the data types of ASN.1X a superset of JSON (although the format is different, it makes that all JSON data can be represented using DER if the nonstandard key/value list type of ASN.1X is used).

I don't like JSON that much because of its many problems (some are problems with syntax, others are problems with the data), so I use ASN.1X instead (with the DER format), for my own stuff (but I also deal with JSON because it is common enough).

I do not (and never had) a smart phone, either.

I have been at one restaurant that had a QR code to view the menu, although they did provide a iPad to any customer who needed it. (At the time, I was with someone else who had their own iPad.) It was not very good food (and badly managed) so I do not intend to return there in future.

If you do not want to print the menu in multiple paper copies, then you might consider a single epaper display somewhere that the customers can easily see (anyone with a camera or a camera phone can take a picture; someone with pencil and paper might copy it out by hand).

Line Mode Browser has some features that have not been found anywhere else. (In some cases, old version of Firefox can be hacked to support a few of them, such as that URLs entered by the user are treated as relative to the current document; Lynx doesn't do that. But, there are also such things as the ability to pipe the output to another program, directly invoking HTTP methods, display a numbered list of links in the current document (also should be easy to do in most web browsers by adding an extension), direct cache management, etc.) I would rather avoid many of the features that Firefox and Chrome have, including CSS, JavaScripts (although JavaScript codes entered by the end user can be useful for the purpose of querying JSON data returned by the server, because such a situation is common enough to be worth), favicons, HSTS, etc, but include some features such as TLS 1.3. Some features that would be useful, I don't see anywhere, such as displaying a table of contents menu based on the <h1> etc in the HTML, commands to sort tables, saving form data to the local disk and later recalling it, calling external programs to edit text, etc. However, they just put too much stuff and make it more complicated than it should be, and many of the actual useful features are omitted. I don't want inline pictures, videos, etc either. However, some of the web developer tools can be useful, because e.g. you can display a list of the network requests.

I think not quite, although many planets have the names of the gods. They called them planets due to their motion, so it is still called that. The use of the same word in different contexts can have different usages and different (but sometimes related) meanings. "Planet" is used differently in astrology than it is in science (astronomy); this isn't a contradiction (although, like any words, can sometimes result in confusion if you do not make the meaning clearly).

The "system" function (and also "popen" function) are helpful, although they should be used carefully. You should only use it where the entire input (rather than merely a part of it) comes from a trusted source from the local user (and documented in a clear way that it does this), such as being entered interactively or from a user configuration file, or in some cases a entirely hard-coded string (although in such a case, often one of the exec functions works better), and to ensure that the security boundary is correct (e.g. you should probably avoid it if it is setuid). If it is necessary to pass additional data then you might use environment variables, pipes, temporary files, etc.

Strings passed to system or popen should not be constructed by combining other strings; they should be directly unchanged from whatever trusted source it comes from.

The specific use documented in the article is a situation where I should think that you should not call the shell (since the command includes untrusted input, and also because there might be a better way to display the error message).

There are additional possible security issues with such things though, whether you use the shell or execute directly, some of which are due to the use of text rather than binary data for communication (although changing that won't solve everything).

> It is a bad design trade-off to send a bunch of header fields on every request just to tell the server all of the possible variations of preference held by the user, particularly when there is a very small chance that any of those dimensions are applicable to the target resource. It has been a bad design trade-off ever since the very brief period in 1993-94 when folks didn't know which image format would be usable on all UAs and there was no CSS or javascript to allow for client-side adaptation.

Doing this with the Accept header is a bad idea, although I think CSS and JavaScripts (in web pages) is not a good solution to this either (they can often make it worse).

My way is the Scorpion conversion file, which must be downloaded explicitly by the end user and the end user must be allowed to override it with their own, and which tells it what to do when it receives a file that it does not recognize, based on the URL or the file type, such as: rewrite the URL, use a uxn program to convert it (to a format that you can use), use a uxn program to display it, etc. Something similar might be possible to add into WWW, by adding a "Interpreter:" response header into HTTP, perhaps using WebAssembly instead of uxn.

The web page does not load for me (I cannot reach the server), but the idea to serve Markdown according to the Accept header is possible, although it might be better to do that by changing the file name and adding a header (or a <meta> command) to indicate this possibility, so that there is a different file name in each case. Some already do this, allowing to change the file name for JSON or Markdown instead of HTML, and is helpful (there are also other common ways that you can change a URL to access it differently e.g. "blob" to "raw" in a git viewer, and I use these things sometimes). However, the reason should not be mainly for AI agents, even if it can be helpful for that purpose too.

If the feature can sometimes be useful (including this situation, which some other comments mentioned; but also for other things such as hiding actual secure data), then perhaps it should be made as a setting which can be changed in the setting menu (e.g. "Exclude secure data from screenshots"; it should also mention which apps use this feature), so prevent abuse. (This would also make it clear what the feature is, as well as being able to disable it.)

Mirroring is probably the most important consideration to me.

However, if another hosting system is done, there some other ideas of some possible things to do:

- Mirroring tickets/discussions as well as the repository (in both directions)

- Support for X.509 client certificate chains for authentication

- Ability to view without JavaScripts and CSS (having JavaScripts and CSS for enhancement is OK, but do not require it and do not add a message to say it is required)

- Support any character sets, including ones not compatible with Unicode (this will not always be displayable in web pages, but will still be usable with some other stuff, such as API using a format other than JSON (e.g. DER))

- Read-only access to public files should not require TLS but should still allow TLS; write access, and access to private files, should require TLS

- A compatible API with GitHub (and possibly others) so that software that works with those API are usable

I think that archive links should be made to include a cryptographic hash of the file; this can prevent alteration of content (including of the original file that it is copied from) but also can allow alternative sources of the file to be found (or verified to be correct) according to the hash. (If someone is concerned they want their username removed, they could perhaps edit their copy of the file first and then archive it, although they should have someone to trust if it matches the original one or not, if it has been modified in this way (or any other way, e.g. removing some scripts and CSS etc).)

Working with screen readers is not the only possible problem. It is not very good if you disable loading fonts, or if you disable CSS as well, or using a browser that does not load fonts, etc.

I agree that benefits come from fine-grained permissions; however, for the fine permissions of user authentication (and API authentication), I think it would help to use X.509 certificate chains. The certificate can include a extension for specifying the permissions that it grants (a permission will only be granted if all certificates in the chain grant that permission). This avoids needing to login or use 2FA in order to set up new API keys or access tokens, and prevents problems with misauthentication with the wrong server (personal access tokens don't help much compared with passwords, but X.509 does help). Merely using X.509 won't cause it to have fine-grained permissions, but they can be combined in the way that I described. (This use of X.509 can also be used to allow someone else to operate on your behalf with limited permissions; in this case, a client would issue a certificate to a server, and that server would then also be a client to GitHub.)

If there is a broken design of GitHub Actions, that is another issue, and neither TLS nor X.509 is the issue with that. (Also, GitHub Actions could hopefully be made to allow finer permissions if the existing permissions are not fine enough; that is not related to X.509 at all.)

Avoiding too many dependencies, is another thing to do.

And, signed releases is another thing to do, and is helpful for additional reasons (unrelated to authentication with GitHub, but useful for knowing that you published it rather than someone else (without having to trust GitHub with it)). The key used to sign the release might or might not match that in the X.509 certificate used to authenticate with TLS; there are some benefits if it does (such as if you have published your certificates that someone else can check, or your mention of Yubikey), but it doesn't have to (e.g. because you have multiple certificates, because multiple people are publishing releases, because you have some other reason to not use the same certificate for the other purpose, etc).

Possibly, to add the anti-discrimination law, one of the other things that is protected against discrimination would be the computers (including kind of computers and lack of computers). Then, they cannot expect you to have a app to get a discount.

Additionally, in situations where it would be reasonable, to publish the catalogs including prices and to allow them to be distributed. (My idea of a computer payment file, additionally requires that the catalog file have a proof of work field.)

Different countries use different money, and also if they sell in the place then it can still be a price for the different place, which does not necessarily involve surveillance, nor does it necessarily involve hidden fees, etc.

(If they try to prevent someone from buying them and using them elsewhere or buying one for a specific other person who requested it who they do not know, then that is different, but it might lead to different issues (e.g. liability of tampering with medications, different regulations in different countries, etc).)

My only use of GitHub Actions specifies permissions that only allow it to write to the issue tracker, so if the program it executes (which is the "gh" program) is malicious then the only damage it can cause is to the issue tracker and not to the repository itself (unless GitHub Actions itself is compromised). Furthermore, there are no private files (I do not host private files on remote services such as GitHub), so they can't steal my files either.

I think one thing that would help is to support mutual TLS, with X.509 certificate chains for authentication. This is more secure than personal access tokens and allows you to issue them to yourself and others without needing to login first, including to specify whatever permissions you want to set (as a subset of the permissions of the issuer) and to make them expire. (You could also store the private keys of one certificate on a separate computer not connected to the internet, and use that to issue another one to yourself to use that one instead, and can use a passworded private key as well (an alternative of 2FA), so you can recover even if your certificate you are using does become compromised, or something deletes it (intentionally or not), and can revoke the ones that are compromised.)

Mutual TLS (and even ordinary TLS) won't solve everything, but in combination with other things, including ability to restrict access to what is needed, and avoiding needing too many dependencies (since, programs that need too many dependencies is also one thing that can cause many problems), and many other things, it can be an additional step to help with security.

I might su combining Proposal A (but only for contributions (to Debian) that actually involve the output of LLMs/generative-AI or that blindly trust their results) with Proposal C (for everything else).

However, in the case of item 4 of Proposal C, there are multiple kind of "assistance" that is possible; not all of them involve contributing the output of LLMs (e.g. the assistance might be to check for a mistake such as if a paragraph seems to be redundant or is incomplete or something like that; the result from the LLM might be incorrect but you will have to decide by yourself what (if anything) to do about it when writing your message). Even if some kind of assistance should not be banned entirely, it should still be discouraged (like the rest of Proposal C says). (Also, there are other programs that can sometimes be used for the assistance; e.g. sometimes ordinary spelling/grammar checking will do (although that won't find that an incorrect word that is spelled like a correct word in the correct grammar).)

I do not use LLM/generative-AI for any purpose, and would not accept contributions including their output into my projects, and would discourage other uses. (This seems to be similar to Proposal A and Proposal C.)

I have less than one terabyte of disk space, and less than 10% of the full capacity is in use, so it is closer to being empty. (The hard drives they sell have more capacity than I require.) And, there are files that I do not use (some of which come with the operating system, such as PulseAudio).

I agree with most of what you write, and I think it is good that you mention these details. I also do not use LLM/generative-AI and I do not intend to use LLM/generative-AI, and many of my reasons are like what you have.

It still works for me too (I have no account on Reddit and have no intention to have an account, even if they try to insist), and it is also possible to add .json on the end of the URL for JSON data (although, so far, I only use this feature to view pictures at the original size that are too small if I do not do this).

I do not like much of the modern decor either, but there are some additional issues.

I think that they should not need to put all of the lights inside and outside even in the day time; the window should be enough light from the sun light (so, they should ensure to have enough window to do that). (You should turn off the light in the night time too so that it is dark in the night time (especially outside).)

One thing I have been working on is a implementation of X.509.

(I also made my own implementation of DER, which I already use for some things that are unrelated to X.509, such as a game engine, and some other stuff where a structured data format would be helpful. So, it includes some types which are not used in X.509.)

I do not use emoji and I do not have (and do not want) colourful emoji on my computer (emoji as ordinary text characters would be acceptable for the purpose of displaying texts that have emoji, but I don't really need to that much, even if the texts have them, so I can do without that, too). The reason does not have to do with AI; I think that things can rarely be explained better with emoji, and is usually better to explain by text, and sometimes also diagrams will help (for computer programs, having good documentation is very helpful). (I also don't like Unicode.)

Super ZZ Zero is one of my projects, which is a game engine written in C with SDL1 (although it may be possible to port it to something that does not use SDL1, too). It is similar to ZZT and MegaZeux. The git repository is: https://github.com/zzo38/superzz0

Some things that it might be possible to help with including, bug reports, feature requests, making a game with it, improvement of documentation if someone finds a problem with it (I think the tutorial document is probably not good enough), etc.

I also would think that client certificates would help better. Then, you do not need API keys, as well as other benefits, such as the end user can create their own passworded private keys if wanted (without ever sending the password to the server), the server cannot steal authentication, it can be used with multiple protocols (not only HTTP(S)), the end user can issue more constrained certificates to themself and others (which can improve security as well as other benefits), it uses DER which is a better format than JSON (in my opinion), the certificate can be revoked, the client can issue a certificate to the server (with restricted permissions, and possibly short validity time) to operate on the client's behalf if wanted, etc.

I agree with you.

The extensions and plugins should be separated from the rest of the program, like any other extensions, and can be configured and disabled by the end user.

Some of the extensions might come with the distribution, but if so, there should also be another package available which is the same program but without any of the extensions included with it (and should be just as easy to find and use, rather than making it difficult), and also the possibility that if you downloaded it with the extensions it can be disabled, and that if you downloaded it without the extensions then you can still install them like any other extension if wanted.

People who do want the AI features can have them, but not as a core part of the browser (the extension mechanism can be enhanced if it is found to be insufficient, which would help with many other things as well; however, the end users should still be able to control the security features of extensions regardless of who wrote them or where they come from), and possible to get it without those and other potentially unwanted extensions.

Even many official features of WWW may be potentially unwanted; in some cases, these might be made as extensions, and in some cases, they might be made as options which can be configured and disabled. Either way, they should be documented; it is good to have good documentation for any software (and should not require an internet connection to use, even for a web browser).

The list of concerns omits many things (although they do mention many valid concerns), such as concerns about control by the organizations that provide the AI services, power that is better used elsewhere (independently of whether it is "too much"), using too much space, effects on prices of things, excessive scraping, inappropriate use of AI, someone trying to force or insist strongly that you should use it even if you do not want to, etc. It might be potentially possible to mitigate some of these concerns (and in some circumstances, some of them are mitigated), but that still doesn't mean you should be required to use it. Software and services that make the AI features optional is one way to help (and is worth doing, if applicable for that software/service), but it does not solve everything; but, one way will not solve everything.