If the interface is documented and can also be used without AI, and you can write your own software instead if wanted, then that will be more helpful, I think. (Someone who does want to use it with the AI can still do so, without forcing everyone else to also do.)
You shouldn't need LLM and AI to do such things. Even if such things might be useful to some people, I might want to use the API without LLM/AI and just to read the API documentation and then to make my own, and some other people might want to do similarly. In the specific case of e-commerce, I had been making my own specification of a file format for e-commerce (which is independent of the protocol), which is not intended to use with LLM/AI, but instead is intended to avoid many kind of dishonest business while also being flexible and that you could make and use your own software or some other implementaiton instead of being forced to use their UI/UX.
> namely both "private" and "public" key are the same thing; the labeling "public" vs. "private" reflects your arbitrary choice of which of one you give away, and which one you keep for yourself.
It is not quite arbitrary. With RSA, you could potentially store only the modulus and the exponents, publishing one exponent and keeping the other one private (or making each privately known to different people, with both having the modulus). However, the way it is commonly stored is with the private key file includes both exponents and several other numbers, and the public exponent is usually 65537 which makes it easy to guess so you cannot effectively keep it secret. With some other kinds of cryptography (other than RSA), you can figure out the public key from the private key even without doing things like this.
In some programming languages with RPN you can avoid this problem, because it makes sense to put it in the stack as the initial value, and then you can as easily have multiple initial values; and then the callback function can read that from the stack that you had put there, like anything else you will push into the stack to read it back later. For example, in PostScript you can write something like:
0 exch {add} forall
However, this is not as good if you want to use the first element as the initial value instead, but still it can be done but it is then not as simple (unlike in programming languages that do not use RPN but instead with function call with arguments, in which case it might be simpler).
I guess names as SELECT and WHERE are like SQL (although SQL works differently than other programming langauges).
Something that bothers me (even though I do not drive a car and do not intend to, but sometimes am a passenger) is windows that require electric controls to operate and cannot be operated manually.
It doesn't load for me, but I have read the other comments.
There is the problem of TLS and X.509 being used with centralized authorities like this, even though it is not inherent to TLS nor to X.509 (although they were designed to be used in this way). In some circumstances, you can get a copy of the certificate (which might be self-signed) from somewhere else and then check that it matches in this circumstances. In other circumstances there are other things that can be done (e.g. TOFU, which has a different set of problems, but also has advantages in a different set of circumstances). What the security requirements are will depend on the circumstances, which can also depend on the user's intentions; they should not have to depend on a centralized authority.
(There is the issue that a single X.509 certificate cannot have multiple issuers, though. There is also the issue that X.509 certificates cannot contain unsigned extensions (they could be added after the signature, but an implementation might check for additional fields after the signature and reject a certificate that has any). Although an alternative schema can be made (I have done so), it would not work with the existing protocols.)
I think it would be a good idea. TLS and X.509 would work better that way. Actually, both sides should have a certificate (the bank might issue a certificate to the customer).
It won't do for all circumstances (as some other comments mention), but when it is possible, it would be a good idea.
One possible alternative might be to add the ability for user configuration to substitute one certificate for another one (both will need the same public key and subject name, but the substitute will not be self-signed (since you do not have the private key)), and to use the data in the substitute certificate instead of the original. If the name constraints extension is implemented, then it would make this and other things possible. Since the substitute certificate will be considered trusted, it is not necessary for the substitute certificate to have a signature (if it does (e.g. because you got it from somewhere else instead of making it yourself), then the signature can be ignored), nor is it necessary for the substitute certificate to be issued by anyone (this applies even if it is the end certificate being substituted).
I think some servers do not send a copy of the root certificate to the client. In this case, what I described above might already be possible even if that feature has not already been added to existing implementations, as long as it does not require the installed certificate to be self-signed.
I also don't like the idea of putting cameras all over my house and having ad companies surveil my intimate space, and I also don't like to add further things that require electrical power, and/or that make noise, etc. This is in addition to the security ramifications that you describe and that you don't describe, and other issues.
If you disable JavaScripts then you will get a non-interactive version (with a note that says you can enable JavaScripts for the interactive version), so you might try that.
reply