hadcomplained

The other way around (converting double quoted strings to single quoted ones) would be more understandable, as that is what str.__repr__ prefers:

    >>> "string"
    'string'

Would you mind telling me exactly which patchset you are referring to?

I registered several important accounts with @icloud.com email, because I was sure that I would never switch to Android besides the fact that the email looked cool (what a stupid reason in retrospect).

I deeply regret using the @icloud.com address for anything serious, because you would be unable to receive or send emails as soon as your iCloud storage subscription expires, provided that you use a larger quantity of data than is allowed in the free-tier iCloud. This is what actually happened to me a few weeks ago. I forgot updating my credit card number on the Apple account, thereby making it impossible to renew the iCloud storage subscription, resulting in the inbox full of emails "Your iCloud storage is full" -- these are what replaced the emails that have been sent to the @icloud.com address after the subscription expired. In addition, I did not receive these emails even after I renewed the subscription. To this day I do not know what these emails were about.

Today, to encrypt your communication to websites, you use HTTPS which rely on a vast network of certificate authorities.

This fact has been irritating me for a long time. Because no one should believe that every single certificate authority is tolerant to any attempts to steal the private keys. But that is exactly the underlying assumption behind HTTPS being the only way to use HTTP in a more secure manner than exchanging in plaintext.

Let's think about this scenario: Suppose that I built a web service for my personal use and hosted it in public cloud. I don't trust any certificate authorities, so I created my own TLS certificate without using them. I installed my own certificates on the machine from which to connect to my web service. Now the server for my web service is serving in HTTPS using my own certificate. Am I safe? No. Because any entity with access to the private key of any of the certificate authorities trusted by my machine, is capable of intercepting the communication between my machine and my server, simply by MITM.

The problem of being forced to trust certificate authorities can be solved by adding the feature to embed a public key in a url. For example, it would be wonderful to have a url like httpsecure://rsa:PUBLICKEY/example.com/ to make sure example.com always responds using the key PUBLICKEY. IIRC, the Tor onion services is an instance of this -- the .onion domains include public keys.

Although I do not deny the necessity for certificate authorities for convenience, I do not understand why using CAs is the only option. Why does the TLS protocol not allow for using a key pair which is agreed-upon between a server and a client beforehand, like in SSH connections where a public key to be used in a connection is placed in a server prior to the connection?

There are many CAs out there and in the event of China or Russia hacking into one of them, it would enable them to perform man-in-the-middle attacks. I'd like to eliminate such a possibility, but the TLS protocol requires me to trust a certificate authority. I might just be a conspiracy theorist, but I am suspecting why it's impossible to use TLS without trusting a third-party called certifcate authority is exactly because someone needed to leave a way to do MITM attacks.

The following is the code I wrote before reading the example pieces of code.

    void remove(IntList* l, IntListItem* target) {
      if (l->head == target) {
        l->head = l->head->next;
        return;
      }
      IntListItem* prev = l->head;
      while (prev->next != target) prev = prev->next;
      prev->next = prev->next->next;
    }

For any given P2P system which can be used to share a large amount of files, we can prove the system cannot exist with this question: Is there a way to prevent classified documents of the US stolen by China, or child pornography from being shared using the system?

If the answer is yes: I'm afraid to tell you that the system is not peer-to-peer in the sense that there is a central authority to censor what content is to be shared. Therefore projects like youtube-dl can be easily erased.

If the answer is no: Such a system with no possibility of censorship is too dangerous. What if there is literally no way to prevent information that threatens the security of the US from being shared? Fortunately as of now, no such a system exists on the planet. Maybe you now have a vague idea why such a system does not exist.

the code is developed 100% in mainland China

I am under the same impression and have some circumstantial evidence supporting it as someone who's been inspecting the code of the Zoom client (just for fun): their Windows client uses a 3rd party library that is used virtually only in China whose documentation is available only in Mandarin.

On a tangential note, I got surprised to see no traces of attempts to make inspection harder on their client software. Even function names remain intact in some cases, which I assume would not happen if they had a malicious intent like embedding a backdoor.

We need to promote our own opensource and free tools to our friends and family, we will get the last laugh.

Although I agree that there should be viable alternatives to available tools for online communication without the possibility of being eavesdropped, I can see why such things do not exist. It'd be too inconvenient for the law enforcement. And if you take things from the perspective of whether that thing makes the job of the law enforcement harder, you'd notice such things tend not to exist. As a principle, popular software should not have a means to prevent data going through the software from getting inspected by the law enforcement. Does Dropbox offer end-to-end encryption? Of course not. Is there a popular easy-to-use disk encryption software? There was TrueCrypt, which is gone for an obvious reason. Does Gmail implement end-to-end encryption for emails? Of course not...

I sometimes imagine how wonderful it'd be if there were a viable alternative to the Web that is decentralized and infeasible to censor, only to realize that how great it is for the freedom, is the exact reason why it doesn't exist. It's just too inconvenient for those in power. That might be why Tor was funded by the government. Its primary functionality is to strengthen the existing Web, rather than to be some competing force to the Web.

This project seems nice, but there's some detail I have trouble wrapping my head around: why is a template string represented as a lambda containing an f-string, instead of as a plain string? Namely, wouldn't the code below suffice?

    Q("""select 1 from {otherQuery}""")

    Q(lambda: f"""select 1 from {otherQuery}""")

I quite agree. HTML/CSS/JavaScript is really flexible for sure, but it's because humans happen to be capable of parsing, and extracting information from, what would be chaos for machines. Is this flexibility really necessary? In other words: How many people jump to the Reader View button when reading a long article? What is the success rate of that functionality? Hasn't anyone realized this functionality wouldn't have been necessary if there were limited flexibility available to web contents?

Imposing structures on webpages as suggested would incur limitations, but it's a necessitated consequence of having content with machine-readable semantics. Think of how we encode characters -- we don't encode them by vector graphics of each character or two-dimensional array of pixels. But rather, we encode characters by concise code points. Yes, we lost flexibility by that. In plain text files we cannot represent different fonts because characters are simply represented with a sequence of code points. But don't the advantages outweigh the disadvantages by a large margin? We can read them in whatever font we like, we can `diff` text files... the list goes on and on. It's unfortunate that web ended up as a huge mess which machines can never reliably comprehend.

I wonder why there are no email providers that offer an infinite number of aliases that cannot be associated with the primary address. Simply offering any aliases would soon fill out easy-to-remember addresses, but can't email providers offer a feature to add a randomly-generated address such as 098f6bcd4621d373cade4e832627b4f6@email.provider? This way, users can use a different email address on a different web service when registration, which would reveal no information about the user and drastically improve users' privacy. In addition, it is easy to track down which web service is at fault in the event of receiving spams via sold user data.

Instead of providing a temporary password, can't that service just give a user the session information that is sent to the server via cookies?

IMHO what is essential as a language feature for writing interpreters/compilers is algebraic data types and pattern matching on them, because they make things much easier when manipulating ASTs, which is a frequent task in implementing these programs.

Unfortunately besides functional programming languages (Haskell, OCaml, etc) or modern languages (such as Rust), there are few having these features, and JavaScript is no exception. Of course you can use a poor man's substitute such as the Visitor pattern, but it's quite a hassle without a direct language support.

For downvoters - constructive counterarguments are welcome.

I agree with the sentiment. The common argument against rolling out your own encryption just baffles me. Because there are plenty of ways to roll out your own encryption safely and in such a way that drastically eliminates the possibility of getting broken. Following is just a few ideas easily implemented even by a mediocre engineer.

For the easiest, you can just apply multiple encryption algorithms in succession (of course with different keys). Although the algorithm of AES is considered safe, it can be broken through a side-channel such as a backdoor, which secretly stores keys used somewhere. But if you apply another algorithm after AES, be it ChaCha20 or Blowfish, it can only gets reinforced.

Another trivial way to safely roll out your own encryption is to increase the number of rounds in ciphers that are considered safe. The increased number of rounds only strengthen the algorithm. And it's just changing a few magic numbers in the source code - you can get extra security for little expense of time.

Both methods provide esay-to-implement ways to safely 'invent' a new encryption algorithm without a proper knowledge of cryptography. If people start doing any of the above regularly, it would be a headache for those enjoying to exploit vulnerabilities in common crypto implementations.