If Google did this, there would instantly be a news story about the new privacy-destroying tracking method.

This is what LaTeX was made to do.

Encryption server (or provider) only provides the key for use in decrypting the contents of the email in the browser. It cannot see the contents of the email.

Can either implement your own key service, or use one of the (separate) providers:
https://support.google.com/a/a...

A fair degree of effort & thought seems to have gone into this post, so I would like to reply in kind:

I generally agree that IPv6 support should be baked in to anything (apps, libraries, networks) starting now (actually, starting several years ago). There are certain features implemented differently in v6 that have the benefit of many years of experience with the shortcomings of v4 (multicast & IPSEC come to mind).

That said, this comment presents an argument fueled by an agenda of absolute adoption, and in the process includes a number of statements I find to be exaggerations, speculation, or incorrect. This style has always irked me, and in particular it makes me want to stand up for the other side of the argument (quite the opposite of the intended affect).

I hope the below will be seen as a respectful difference of opinion on some key aspects. I'll try to avoid indulging in sarcasm or wit as an alternative to logic :)

In general, I find fervent proponents of IPv6 (and other things) tend towards exaggeration. This "the sky is falling!" or alarmist approach grabs headline & notice (especially from the uninformed), but can result in skeptical/dismissive responses from those with a stronger grounding in the topic. Summarization necessarily loses information, but when taken to the extreme can result in (often unintentional) bias:

> connecting a modern windows system to a legacy network that lacks ipv6 support can be a security risk
I'm not sure how this rates as a security risk in non-ipv6 networks. It seems to describe the security risk of allowing someone else to enable a rogue ipv6 network within a controlled network.
> MacOS lets you disable ipv4, but you cannot disable ipv6, so it's clear the way os vendors are moving.
Is there a source/support for this? I have disabled ipv6 on MacOS before. Here are several sources:
https://vladtalks.tech/vpn/how...
https://support.nordvpn.com/Co...
https://medium.com/macos/disab...

> you use ipv6 with aws you will get your own block, its easy to keep track of and anything you setup will be in that block.
> If you use ipv4 you get random addresses all over the place, much more difficult to keep track of
> random addresses belonging to aws could be any one of millions of aws customers (including malicious actors), but a single address block registered specifically to zoom is pretty obvious what the traffic is.
This is a good example of a way to make things easier on network operators (by using contiguous blocks of addresses). However, it remains to be seen whether distribution will follow this pattern. Remember, this was intended to be the case with ipv4 initially.

> If your old address is recycled and gets allocated to someone malicious, they can use it for malicious purposes, and this is already happening
Good point here.

> You can no longer practically use ip based blacklists because carrier grade nat is common
I find this section less than convincing. IP-based black/whitelisting has never been completely effective, because of the (many) ways in which a client can mask or alter their true source address (both intentionally & unintentionally).
There are still privacy concerns tied to linking all egress traffic to a single, globally unique address. The privacy extensions to IPv6 are one way to replace the role that NAT/proxy servers handle with IPv4 (among other uses); but that doesn't mean the underlying issues are gone.
Additionally, none of this prevents attackers from globally distributing the sources of their attacks, so blacklisting a small number of IP ranges won't help in those cases.

> The hardware to implement cgn is expensive to both acquire and operate
This is a good point, though I feel inclined to point out that replacing non-ipv6 capable equipment is/was similarly expensive. Still, it is probably a better long term strategy, and most seem to be/have been making ipv6 support a requirement for new acquisitions.

> An increasing number of things are ipv6 only, in some regions it is impossible or impractical to get an ipv4 allocation
Both true statements, but in both cases the actual incidence is still quite rare, and this makes me doubt the current relevance. See:
https://blogs.infoblox.com/ipv...
https://tools.ietf.org/html/rf...
https://tools.ietf.org/html/rf...

> Your firewall rules are easier to manage - source and destination, no need to worry about the extra complexity of the true address being hidden by address translation.
FWIW you still have to worry about these kinds of attacks. Same reasoning as the blacklist/whitelist section above.

> Your logging is easier because the address you see in logs is the real address of the host and not the address of a firewall doing address translation, in the latter case your firewall has to log every connection and you need to correlate 2 separate logs
For non-malicious applications, I tend to agree (provided the network is set up as described).

> sweeping your entire address space is no longer practical so malware won't operate in this way
Agreed, an in particular one approach I have seen here is to "sweep" the ipv4 range for fqdns, then reverse them back to ipv6 for penetration testing. Perhaps this serves as a stronger argument for ipv6-only approach?

I hope this is seen as a constructive response, I certainly don't intend it as a dismissal (or even a counterpoint) to the original comment. Rather, as a slightly different take on the question.

The points above related to scanning and enhanced features are much more convincing to me than the (at best, deceptively worded) "we're running out of ipv4s *now*" or "every toaster gets a globally routable IP" arguments.