jon128

  August 2023

  To defend against this risk, Chrome contains a pin set for all Google properties, and we only consider an HTTPS input trustworthy if it’s authenticated using a key in this pin set. Chrome contains a pin set for all Google properties, and we only consider an HTTPS input trustworthy if it’s authenticated using a key in this pin set. This protects against malicious certificate issuance by third parties.

  https://security.googleblog.com/2023/08/making-chrome-more-secure-by-bringing.html

  $ grep -n mail src/net/http/transport_security_state_static_pins.json 
  170:       "name": "gmail.com",
  185:       "name": "googlemail.com",
  230:       "name": "www.gmail.com",
  235:       "name": "www.googlemail.com",
  1500:      "name": "gmail.co.ug",

  https://chromium.googlesource.com/chromium/src/+/refs/heads/main/net/http/transport_security_state_static_pins.json

_

If HKP specification had worked out (RIP, lol), that may have over the last decade-ish spared some config lines for CA config behind commands like

  browser_organizationFoo.sh
  browser_organizationBar.sh

It's odd how that, for the unwashed masses' use of browsers with the default CA config, high-value clearnet websites' PKI robustness is, from all I've read over the years, more often than not functionally outperformed by prominent LSD/tryptamine vendors of various DarkNet Markets.

  LoL

A more meaningful answer on the "other organizations" question above, for a project one might get one or more CA and relevant details in a PGP/MIME or S/MIME or by-hand gpg/sq message with the implicit "you already know what to do".

Some commercially operated services, geared more towards high-value customers, have casually offered a first-party CA cert. Perhaps due to being operated by and for relatively higher value demographic (thus, I'll not advertise them here), even at general or low pricing (high trust societies just hit different).

Some "far left" or whatever anarchist-ish communities often not chasing profit casually do first-party CA too, which is no less based than any other subculture doing it.

Any time someone may have ever manually sent you a VPN config file to load, this is in essence sort of what they were doing but without the existing known-pubkey part.

Across the globe, competent IT teams transparently propagate dedicated browser instance profiles with explicitly whitelisted CA that show up in users' toolbar/dock as differently styled icons with appropriate splash images/dialogue when clicked.

The ability to do this correctly and without mistakes, is, as mentioned above, a litmus test for (when asked to do so) if an IT team is legit or not.

This functional pattern of the people who get the real shit done has been in place for more than, as far as I personally for over two decades have happened to know. And, functionally in its substance, no matter what form on the surface, it's not going away, not ever.

At least not until a cosmic event leading to the dissolution of this current run of civilization.

As I imagine, you already probably know. I see your pubkeys on Keybase. Imported.

_

Super lame anecdote: at one hilarious and sad juncture I witnessed a self-titled ""CTO"" at a sham company, self-proclaimed "security guru", expose himself as a total fucking fraud when he announced boldly to a room that all OpenStack APIs functionally (not a directive, but functionally) are unable to use in-house CA, in what was surfaced as a lame attempt to shirk applying a skill he'd hyped everyone up he like totally had fluency in. Then a good chunk his own team on the side derided him as a "fucking LARP" immediately after that before anyone else could have commented.

  "The thing about computers are is they are objective"
  (roughly accurate quote of)
   ~ Jonathan Blow

  04 May 2011
  Starting with Chrome 13, we'll have HTTPS pins for most Google properties. This means that certificate chains for, say, https://www.google.com, must include a whitelisted public key. It's a fatal error otherwise. 

  https://www.imperialviolet.org/2011/05/04/pinning.html

A Tauri app, which is essentially a Chromium browser instance with no address bar and widgets to access browser settings, a Fastmail desktop "app" made with Tauri can potentially even the playing field between Google the Goliath and Fastmail the David on the TLS certificate pinning front. Tauri is like Electron but sucks a lot less.

  https://tauri.app/

> if you've spending tens of thousands of dollars per month

Such as, 8,000 users at $40k/month for Google Mail.

Yubico has great volume discounts for a part of the CapEx side of a sane deployment of this.

The basic WebAuthn/FIDO2-only Yubikeys with a Fastmail logo on them would be, as the kids said a generation ago, "dope".

_

> where they have a Helpdesk

Quality attention to cicd and artifact release may avoid and potentially reduce conventional helpdesk activity.

For individual users of SaaS, provided the .dmg or .msi of the downstream Betterbird/Thunderbird (or other MUA) has sound cicd and decent release attention, no more additional support tickets than reasonable should occur beyond an initial phase.

A downstream MUA distro can eliminate manual configuration and superfluous details, such as the shit experience with Thunderbird on macOS (Thunderbird's fault 100%) with Oath2 I saw in the last few months. Such a distro could be tuned with a slew of relatively small adjustments reducing existing support ticket traffic.

Startups with headcount of 20 to 30, a good chunk of that being developers, where I have historically preferred to dwell, helpdesk is not there nor wanted for. Higher quality customers are here.

_

> and golden image deploys

Chromebooks, which not including K-12 did outnumber macOS in non-personal environments around a half-decade ago during that Event 201 thing. Super low IT overhead with those.

I have been distant from MIS type of IT for a while but have heard echoes or binocular'd in a bit and believe the golden image era has quietly passed us.

Conventional image pattern shouldn't be necessary anywhere now.

Somewhere in 2019, Apple warped native tooling in tandem with device firmware behavior to squeeze out the conventional image pattern ; killed it off.

Apple Business now includes built-in mobile device management which can enroll and set up Apple devices then apply standard settings and apps through "Blueprints" ; the .dmg would be trivial to push out. The successor to Jamf.

With Microsoft Intune, propagation of .msi packages to enrolled devices is a day-to-day task.

Ubuntu, RedHat, SuSE, Qubes, and all related distros, when under IT teams that can code on a rudimentary level, are managed with Ansible or Salt, without the "enterprise tax" part.

What all of these have in common is centralized org-wide device management where the ability to push out a .msi or .dmg or .deb/.rpm/.AppImage is there.

In similar spirit to certificate pinning, the advanced customers have dedicated private cicd consume source code from the OS vendor.

The more advanced are on

  Bootstrappable builds: how and why
  https://lwn.net/Articles/1088279/

_

> what other SaaS consumer products use certificate pinning.

Slack has the low-hanging-fruit opportunity to with their Electron app, but has reportedly dropped the ball. This is great for tech workers who like to divert all Slack contents to a separate local data sink for archiving and discovery and non-shitty data access.

This repo from about seven years ago looks abandoned and inactive, but

  https://github.com/myxious/electron-root-ssl-pinning

_

> let's expand it to banks and government departments in most countries.

With the episodic exposure I had with computer vision -> flow chart startups in the SF Bay Area many years ago, relatively ongoing time sinks with some archetypal MBA twat types, and some perceived legendary tier banks running on one of the two legit clouds (neither of which is that Azure garbage), who then fell on customer-facing downtime by not deploying with rudimentary cloud patterns that startups don't fail to do (as we recently found out), I am left feeling not confident that banks can do IT with self-reliance these days.

They can still push out .msi and group policy objects though, for sure.

From anecdotes I hear of and distant observations of state governments, departments of the big federal government sans some of the cooler TLA, and govs in Europe, I am not optimistic about those.

About a decade and a half ago we used to look at these two types of institutions and go "ah, the big guys, in their big buildings, they broker a thing I need, with their marble floors and reassuring smiles, these egregore have got it all figured out".

As a staff level DevOps / DevSecOps / whatever who has been along for the ride with a share of Silicon Valley culture-OS startups with enterprise customers, closely followed practices and white papers of hyperscalers and elite security firms, thus can see through any IT product/pattern transparently for its base principles...

-- having witnessed various sitcoms, heard of or read over 9,000 of first-hand accounts of such sitcoms, on top of the broadly spread cultural decay we are experiencing in the West upcoming on this Fourth Turning, with the rot of these institutions, and the major cultural shifts on computer illiteracy/obliviousness being normalized among "professionals" observed over the last couple of decades, I think more often than not some scrutiny of IT patterns at these institutions uncovers that they are severely retarded.

I suspect on the mid to lower end of the gov side it's just checkboxes, misdirection, and casual corruption almost all of the way down. Anyone who actually gives a shit about IT security and tries to fix things gets railroaded out.

The subcontractors who pick up the slack and handle real shit, like SpaceX is something NASA is dependent on (macro example), the upper echelon of the private sector, supranational organizations run by elite characters, are where not the progressive-minded IT teams are found but where IT is treated with some seriousness by leadership. But no transparency into IT patterns will be offered by these outside of talks at cool parties like DEF CON and AWS Re:Invent (shitty DJs but still a great party).

  https://nix64.live/hn-fastmail-comment-b9cf004de71eece0f460f3bae3620e3f52a51b627e674877f2b2eb537aa0c935d018e04dcc9a4f7416480abb2bfb4d7a80ebc264d717db9abf325d200592767b.txt.asc

I didn't realize I was replying to the CEO of Fastmail until I had written the entire comment. In retrospect I'm glad I wrote without any filter.

I have generally thought Fastmail is a pretty cool guy, eh serves email without frills and doesn't afraid of anything.

So by association my working assumption is the CEO is too.

edit 2:

okay apparently the open source channel of Cyrus IMAP, which I used relatively tangentially at an ancient time, still doesn't have the same configuration flexibility as Dovecot (thanks ChatGPT..). A whole 'nother config file and K8s/init/whatever service entry becomes necessary for another TLS listener, boo hoo I guess.

edit 3:

embedded sha512 hash of comment in file name so no one can say I mutated the file after the edit window is closed.

Maybe some of Android users who are naive enough to use Google Play to manage a package like Signal could over time consistently inspect what APK they have and share results.

  https://developers.google.com/android/binary_transparency/google_apk/verification_details

Maybe reproducible builds of apps for iOS and macOS will happen some day but the people with the necessary competencies to do reproducible builds are unlikely to believe in others using those systems enough to attempt reproducible builds for them.

Even with reproducible builds, whether packages on iOS can be verified seems to be a grey area at best and with no source code for iOS there is no starting point to believe anything iOS tells us.

SimpleX has been inconsistent with integrity of releases. Some releases have the expected GPG signatures but more do not.

For any release to not have at least one GPG signature on the source tarball is a serious concern.

Evgeny, the head of the SimpleX project, is doing much better with Git commits now than he has in the past. But a cursory look at the Git commit history at the link below shows an RSA4096 key that is over three years old.

    https://github.com/simplex-chat/simplex-chat/commits/stable/

I know there are some have urged Evgeny to use hardware wallets for signing source tarball releases and to be forthcoming that he is using a hardware wallet (something built into a Macbook is not sufficient) but there isn't anything on the SimpleX blog showing this.

  https://simplex.chat/blog/

> users who can't have any freedom unless they compile their own builds

Those who don't have cicd don't have any freedom and have questionable security at best. Whether this is how things should be, I'll let others argue that. It's how it is.

This behavior, or lack of it, and resulting functionality is what differentiates the "follow the best practices consensus" security teams and the upper tiers of security teams.

What the non-low-value users are generally looking for is the option to not opt-in to discard anonymity with any potentially involved third parties such as server operators and network operators, and left at the discretion of the users solely.

Other systems have already solved this. One user can be not anonymous while another can choose to not opt-in to not be anonymous.

The users still know who the user on the other side is.

If you don't know how computers work, yeah it sounds great. But those who do know how computers work see it for what it really is: a bucket of shit.

> I think this is exactly what he wanted

You think, users should be required to carry a cell phone or make use of a debit card or credit card, in order to message another user, is exactly, what Matthew wanted?

A self-described anarchist who described the original cypherpunks as his teenage heroes?

When XMPP+OTR had already been, among competent people, the prevalent norm for over half a decade when he gave that DEF CON 18 talk?

That is just crazy, man.

In that DEF CON 18 talk, Moxie talked about scope of choice and how the scope of choice changed to "do I want to carry a cell phone, or not?". A notion that Matthew's dream was to impose on the world a demand to carry a cell phone or a debit/credit card transaction on others, such a tax, to enjoy what he and his friends and colleagues already on top of pure Internet Protocol, is on its face absurd.

_

> Spam is not a plague because registration remains expensive

The issue of spam is fully mitigated with an invite token, a 16 byte string ; "is", not "can be", because other systems in production have already been doing this.

The way it works is simple. If Alice wants to receive a message from Bob, Alice can share a connection string username+token to Bob. Then Bob can message Alice and for that time not other users of the hosted centralized namespace.

Very simple concept.

Simple enough for a mediocre dev to implement without an LLM.

The spectre of spam does not justify the demand for "checking in" with your local PSTN tower, nor the friction involved with an uninvolved and unwanted third party named Google (love Google overall but this is such a bastardly and disgusting concept), nor does it justify demanding a debit/credit card transaction become involved.

The spectre of spam does not justify any of this horse shit.

"Hey Bob, here is my username to message me, provided you subject yourself to this horse shit", where such horse shit antithetical in a fundamental way to the values espoused founder of Signal.

The new, grossly degenerated Scope of Choice.

Perhaps some who call themselves "hackers" or software developers may have been actually fooled by this false spectre of spam. I was never among them.

Even worse, the phone numbers, Google Play accounts, debit cards and credit cards, these are cheap. Among the scammer underworld these are a plenty and fungible.

An invite token personally sent by Alice or read aloud by Alice to Bob, is not.

But if somebody wants to harass a specific user on Signal, that's relatively cheap to do.

_

> Not to mention that sending ongoing traffic to your own server tells everyone where and when you're posting

Uncle Jeff, AWS, who doesn't tell exactly everyone but a lot of people, not excluding ICE at any given time, knows when you are posting, from where, and to what other users. The last of which is specifically obviated by a separate namespace hosted on a separate server.

On the occasions I have run Signal's server software, I and other users did mitigate these concerns. We do appreciate that others also have these means, or not.

Another messaging system, you may have already read its name actually, has already solved these problems in a way that they are successfully mitigated in a wholly transparent way for casual users.

_

> Alternative servers are not sapping user metrics.

This imperative is not the users' problem and runs counter to the best interests of the users.

_

> Its tradeoffs all the way down.

Right. In Matthew's view, the horse shit is a tradeoff.

I believe there are other tradeoffs available that are ethical, not more ethical, but ethical, and carry much less technical complexity.

The Signal client software is open source and some of the clients have reproducible builds. The Signal server software is open source, though has a history of being over a year out of date at some points. Other deployments of this server software for production use are rare.

Suppose you configured an instance of the Signal server software and others you know ran also a somewhat modified Signal client that could access that instance of the Signal server software.

But the centralized namespace of the hosted Signal service hosted by the incorporated 501c3 named Signal would not be accessible through that server instance now would it.

And, as dictated by the incorporated vendor of the centralized namespace, and other reasons, in practice, this client would have to run as a separate piece of software. "Another app".

This is vendor lock-in.

The service hosted by the 501c3 named Signal seems widely open yet is a permissioned namespace. A physical location tracking number aka phone number or a credit/debit card is required to access the namespace. This is for slaves. The profane.

  Open Signal on your phone to keep your account active

And, I don't think this is what Moxie wanted.

Signal 501c3 is a centralized service. XMPP and Matrix are decentralized/federated. SimpleX is distributed.

100% of the aforementioned US gov domains resolve to IPv6.

More 5G networks than not are using IPv6 and 464xlat. Many ISPs are IPv6 only too so closer to half the time than not there are IPv6 packets to reach to those IPv4 addresses.

  $   for  USCompany  in    apple akamai att berkshire bestbuy boeing bofa burgerking cnn chase chevron citi comcast costco cvs dell disney fedex fidelity gatorade google goldmansachs gopro hellofresh hilton homedepot infowars in-n-out jcpenny johnsonandjohnson kaiser kroger lulumon macys mcdonalds microsoft nike pepsi petco radioshack safeway shell southwest sprouts statefarm tacobell target tesla traderjoes ups usbank uschamber walgreens walmart wellsfargo wholefoods yahoo    aquantuo atlanticseafarms beehivemeals beetlesplumbing dynamicautomotive jamies-farm joeandbella jovyco privacy4cars prosperityehr redroostercoffee resortlifecarts sproutlabs tradedesignbuild 
    do
      echo ${USCompany}
      dig +short aaaa www.${USCompany}.com
      echo  ; done
  apple
  www-apple-com.v.aaplimg.com.
  www.apple.com.edgekey.net.
  e6858.dsce9.akamaiedge.net.
  2600:1406:3a00:493::1aca
  2600:1406:3a00:492::1aca
  2600:1406:3a00:494::1aca
  2600:1406:3a00:486::1aca
  2600:1406:3a00:48a::1aca
  
  akamai
  www.akamai.com.edgekey.net.
  2600:1406:2e00:49::172e:d8cf
  2600:1406:2e00:49::172e:d8c6
  
  att
  prod-www.zr-att.com.akadns.net.
  cac2.m.att.com.edgekey.net.
  e11697.cd.akamaiedge.net.
  
  berkshire
  3tfzq88u2cbx.wpeproxy.com.
  
  bestbuy
  www.bestbuy.com.edgekey.net.
  e5816.x.akamaiedge.net.
  
  boeing
  d1pt7e7bvjlgwo.cloudfront.net.
  2600:9000:24bc:7a00:16:a4e1:f600:93a1
  2600:9000:24bc:3600:16:a4e1:f600:93a1
  2600:9000:24bc:b400:16:a4e1:f600:93a1
  2600:9000:24bc:e000:16:a4e1:f600:93a1
  2600:9000:24bc:6e00:16:a4e1:f600:93a1
  2600:9000:24bc:be00:16:a4e1:f600:93a1
  2600:9000:24bc:fc00:16:a4e1:f600:93a1
  2600:9000:24bc:c000:16:a4e1:f600:93a1
  
  bofa
  redirect.ecglb.bac.com.
  
  burgerking
  prod-bk-us-web.com.rbi.tools.
  
  cnn
  cnn-tls.map.fastly.net.
  2a04:4e42:200::773
  2a04:4e42:400::773
  2a04:4e42:600::773
  2a04:4e42::773
  
  chase
  gtm.www.chase.com.akadns.net.
  www.chase.com.edgekey.net.
  e129412.a.akamaiedge.net.
  
  chevron
  www-afd-b9aycqabggbkcsdt.z01.azurefd.net.
  mr-z01.tm-azurefd.net.
  2603:1061:14:95::1
  
  citi
  san.www.citi.com.edgekey.net.
  e16976.x.akamaiedge.net.
  
  comcast
  www.comcast.com.edgekey.net.
  e523.dscb.akamaiedge.net.
  2600:1406:3a00:482::20b
  2600:1406:3a00:48d::20b
  
  costco
  costco.map.fastly.net.
  
  cvs
  www.cvs.edgekey.net.
  e5769.x.akamaiedge.net.
  
  dell
  www1.dell-cidr.akadns.net.
  cdn-www.dell.com-v2.edgekey.net.
  e13665.x.akamaiedge.net.
  
  disney
  www-cdn.matterhorn.app.
  
  fedex
  www.fedex.com.akadns.net.
  cidr.fedex.com.akadns.net.
  ipv6www.fedex.com.edgekey.net.
  e111296.dsca.akamaiedge.net.
  2600:1406:2e00:49::172e:d8cc
  2600:1406:2e00:49::172e:d8c8
  2600:1406:2e00:49::172e:d8d0
  2600:1406:2e00:49::172e:d8ca
  2600:1406:2e00:49::172e:d8c4
  
  fidelity
  www.fidelity.com.edgekey.net.
  e94446.x.akamaiedge.net.
  
  gatorade
  2606:4700:4409::ac40:9261
  2a06:98c1:3105::6812:299f
  
  google
  2001:4860:482d:7700::
  2001:4860:482a:7700::
  2001:4860:4828:7700::
  2001:4860:4827:7700::
  2001:4860:482c:7700::
  2001:4860:4826:7700::
  2001:4860:4829:7700::
  2001:4860:482b:7700::
  
  goldmansachs
  www.gs.com.
  www.gs.com.edgekey.net.
  e17133.x.akamaiedge.net.
  
  gopro
  d1h7n50c10z72v.cloudfront.net.
  2600:9000:201e:6800:17:765c:a5c0:93a1
  2600:9000:201e:4c00:17:765c:a5c0:93a1
  2600:9000:201e:a200:17:765c:a5c0:93a1
  2600:9000:201e:2400:17:765c:a5c0:93a1
  2600:9000:201e:a800:17:765c:a5c0:93a1
  2600:9000:201e:fe00:17:765c:a5c0:93a1
  2600:9000:201e:ca00:17:765c:a5c0:93a1
  2600:9000:201e:c200:17:765c:a5c0:93a1
  
  hellofresh
  www.hellofresh.com.cdn.cloudflare.net.
  2606:4700:4409::6812:209d
  2a06:98c1:3106::ac40:9b63
  
  hilton
  www.hilton.com.edgekey.net.
  e2904.dscx.akamaiedge.net.
  2600:1406:2e00:49a::b58
  2600:1406:2e00:4a3::b58
  
  homedepot
  www.homedepot.com.edgekey.net.
  e301254.x.akamaiedge.net.
  
  infowars
  2606:4700:10::6814:1a60
  2606:4700:10::ac42:9d27
  
  in-n-out
  sw6cs.x.incapdns.net.
  
  jcpenny
  www.jcpenny.com.edgesuite.net.
  a1441.b.akamai.net.
  
  johnsonandjohnson
  prod.jnj.psdops.com.
  
  kaiser
  kaiser.com.
  2001:1ab0:7e1e:151::58
  
  kroger
  www.kroger.com.edgekey.net.
  e8023.a.akamaiedge.net.
  
  lulumon
  lulumon.com.
  
  macys
  www.macys.com.edgekey.net.
  e5791.a.akamaiedge.net.
  
  mcdonalds
  direct-san.mcdonalds.com.edgekey.net.
  e179224.a.akamaiedge.net.
  
  microsoft
  www.microsoft.com-c-3.edgekey.net.
  e13678.dscb.akamaiedge.net.
  2600:1406:3a00:487::356e
  2600:1406:3a00:486::356e
  2600:1406:3a00:497::356e
  2600:1406:3a00:481::356e
  2600:1406:3a00:482::356e
  
  nike
  www.nike.com-v1.edgekey.net.
  e2785.x.akamaiedge.net.
  
  pepsi
  g2wh497.x.incapdns.net.
  
  petco
  2a06:98c1:3108::6812:20c7
  2a06:98c1:310a::ac40:9b39
  
  radioshack
  prod.magentocloud.map.fastly.net.
  2a04:4e42::380
  2a04:4e42:200::380
  2a04:4e42:400::380
  2a04:4e42:600::380
  
  safeway
  htu5x69.x.incapdns.net.
  
  shell
  www.nic.shell.edgekey.net.
  e200089.dscb.akamaiedge.net.
  2600:1406:3a00:33::170b:cfef
  2600:1406:3a00:33::170b:cfe6
  
  southwest
  www.southwest.com.edgekey.net.
  e7466.a.akamaiedge.net.
  
  sprouts
  2606:4700:10::ac42:9705
  2606:4700:10::6814:2445
  
  statefarm
  statefarm.edgekey.net.
  e124943.a.akamaiedge.net.
  
  tacobell
  www.tacobell-prod.com.edgekey.net.
  e78335.b.akamaiedge.net.
  
  target
  sites.target.map.fastly.net.
  
  tesla
  www.tesla.com.edgekey.net.
  e1792.dscx.akamaiedge.net.
  2600:1406:3a00:291::700
  2600:1406:3a00:280::700
  2600:1406:3a00:293::700
  2600:1406:3a00:290::700
  2600:1406:3a00:296::700
  
  traderjoes
  www.traderjoes.com.edgekey.net.
  e4528.b.akamaiedge.net.
  
  ups
  ev.ups.com.akadns.net.
  ev2b.ups.com.edgekey.net.
  e13626.dsca.akamaiedge.net.
  2600:1406:2e00:986::353a
  2600:1406:2e00:98b::353a
  2600:1406:2e00:983::353a
  2600:1406:2e00:984::353a
  
  usbank
  www.usbank.com.edgekey.net.
  e374753.a.akamaiedge.net.
  
  uschamber
  uschamber.map.fastly.net.
  
  walgreens
  walgreens.com.edgekey.net.
  e36070.dsca.akamaiedge.net.
  2600:1406:2e00:20::45c0:8be8
  2600:1406:2e00:20::45c0:8bda
  
  walmart
  www.walmart.com.cdn-wal.net.
  
  wellsfargo
  www.wellsfargo.com.edgekey.net.
  e82164.b.akamaiedge.net.
  
  wholefoods
  2600:9000:25ef:c800:8:df9e:eb80:93a1
  2600:9000:25ef:e000:8:df9e:eb80:93a1
  2600:9000:25ef:7400:8:df9e:eb80:93a1
  2600:9000:25ef:6400:8:df9e:eb80:93a1
  2600:9000:25ef:ca00:8:df9e:eb80:93a1
  2600:9000:25ef:9e00:8:df9e:eb80:93a1
  2600:9000:25ef:5400:8:df9e:eb80:93a1
  2600:9000:25ef:fa00:8:df9e:eb80:93a1
  
  yahoo
  me-ycpi-cf-www.g06.yahoodns.net.
  2001:4998:18:800::4003
  2001:4998:18:800::4002
  
  aquantuo
  2606:4700:20::681a:2e
  2606:4700:20::681a:12e
  2606:4700:20::ac43:4547
  
  atlanticseafarms
  2606:4700:3033::6815:4581
  2606:4700:3035::ac43:d0b4
  
  beehivemeals
  beehivemeals.myshopify.com.
  shops.myshopify.com.
  2620:127:f00f:e::
  
  beetlesplumbing
  s.multiscreensite.com.
  global.multiscreensite.com.
  a3c02b2530d6f27ca.awsglobalaccelerator.com.
  
  dynamicautomotive
  dynamicautomotive.com.
  
  jamies-farm
  shops.myshopify.com.
  2620:127:f00f:e::
  
  joeandbella
  joebella.myshopify.com.
  shops.myshopify.com.
  2620:127:f00f:e::
  
  jovyco
  jovy-brand.myshopify.com.
  shops.myshopify.com.
  2620:127:f00f:e::
  
  privacy4cars
  2606:4700:20::681a:dca
  2606:4700:20::ac43:4af6
  2606:4700:20::681a:cca
  
  prosperityehr
  2606:4700:10::6814:2f68
  2606:4700:10::ac42:94bd
  
  redroostercoffee
  cname.vercel-dns.com.
  
  resortlifecarts
  sprod-dnn-gce6a8hab5g5bkf6.a03.azurefd.net.
  mr-a03.tm-azurefd.net.
  2603:1061:14:99::1
  
  sproutlabs
  cdn.webflow.com.
  2620:cb:2000::1
  
  tradedesignbuild
  ext-sq.squarespace.com.



  $   for  USent  in    cia congress dhs epa ice fbi fcc nasa nsa whitehouse
    do
      echo ${USent}
      dig +short aaaa www.${USent}.gov
      echo  ; done
  cia
  cia.gov.edgekey.net.
  e10004744.dsca.akamaiedge.net.
  2600:1406:3a00:33::170b:cfeb
  2600:1406:3a00:33::170b:cff2
  
  congress
  2606:4700:4402::ac40:90ce
  2a06:98c1:3109::6812:2b32
  
  dhs
  www.dhs.gov.edgekey.net.
  e6485.dsca.akamaiedge.net.
  2600:1406:2e00:98b::1955
  2600:1406:2e00:983::1955
  
  epa
  d32i4z0dxazdtp.cloudfront.net.
  2600:9000:201e:a600:10:f3db:af40:93a1
  2600:9000:201e:f400:10:f3db:af40:93a1
  2600:9000:201e:6000:10:f3db:af40:93a1
  2600:9000:201e:c400:10:f3db:af40:93a1
  2600:9000:201e:b600:10:f3db:af40:93a1
  2600:9000:201e:d200:10:f3db:af40:93a1
  2600:9000:201e:d600:10:f3db:af40:93a1
  2600:9000:201e:6400:10:f3db:af40:93a1
  
  ice
  www.ice.gov.edgekey.net.
  e6485.dsca.akamaiedge.net.
  2600:1406:2e00:98b::1955
  2600:1406:2e00:983::1955
  
  fbi
  www.fbi.gov.cdn.cloudflare.net.
  2606:4700::6810:94f4
  2606:4700::6810:95f4
  
  fcc
  www.fcc.gov.edgekey.net.
  e4909.dscb.akamaiedge.net.
  2600:1406:3a00:484::132d
  2600:1406:3a00:497::132d
  
  nasa
  nasa-gov.go-vip.net.
  2a04:fa87:fffd::c000:426c
  
  nsa
  nsa.gov.edgekey.net.
  e16248.dscb.akamaiedge.net.
  2600:1406:3a00:487::3f78
  2600:1406:3a00:496::3f78
  
  whitehouse
  wh47.go-vip.net.
  2a04:fa87:fffd::c000:4233

USB hubs, USB SATA adapters and USB Ethernet interfaces for the win.

Sharing cookies along a strata of inter-team bots is one trick.

_

Web scraping is (among the other pieces) also for the more technically inclined among the "little people" to have computers do things that people they don't have the money to hire might do. Making web scraping more difficult, which won't stop the big players who will work around the hurdles one way or another, is "pulling up the ladder".

_

> What alternative web could change this state of things?

A different architecture for trafficking web contents, one that doesn't need the "shield" of something like Cloudflare or "tar pit" of something like Anubis in the first place.

IPFS is or is something like one piece of that picture but there are other essential pieces to complete that picture.

  Federal Cyber Experts Thought Microsoft’s Cloud Was “a Pile of Shit.” They Approved It Anyway.

  https://www.propublica.org/article/microsoft-cloud-fedramp-cybersecurity-government

The prigs are oh so high status .. to other prigs.

The conventional way of doing web isn't efficient. If it were, no one would be complaining about bots. The way we do web is the thing that needs to be updated.

Or, did they?

  "So we had been perfecting these imaging algorithms on synthetic data. We’d fed these algorithms made-up data. So we would take a black hole image that we might be looking at. We’d corrupt it with noise, and we’d send it through these algorithms, and we’d refine these to the point where we were pretty confident in these algorithms."

They're not really explaining this either.

I'm trying to keep an open mind but I'm still not buying the whole black hole thing.

There needs to be something more intellectually compelling than "we know it's a black hole because we know it's a black hole".

Yes, you read that right. I am doubting this religion.

  "That was a moment where there was a lot of crying and screaming."

  user@host:~$ dig +short  aaaa  www.citi.com
  san.www.citi.com.edgekey.net.
  e16976.x.akamaiedge.net.

  user@host:~$ dig +short  aaaa  www.walmart.com
  www.walmart.com.cdn-wal.net.

The list from ChatGPT:

"This 2026 list ranks organizations by LinkedIn employee count, not revenue, and includes public bodies and universities as well as companies. I’ve kept the listed order; entries without a domain in the source are omitted."

  $ for argdo in $(cat arg2) ; do echo $argdo ; dig +short aaaa $argdo  ;  echo ; done
  www.tytconsultores.com.ar
  
  www.mercadolibre.com
  a35f64fceb718ad27.awsglobalaccelerator.com.
  
  www.es.wikipedia.org
  
  www.dyna.wikimedia.org.
  
  www.techintgroup.com
  fdcomm01-egdmdkhuhfbgb9gx.z01.azurefd.net.
  mr-z01.tm-azurefd.net.
  2603:1061:14:90::1
  
  www.cencosud.com
  www.cencosud.com.cdn.cloudflare.net.
  2606:4700::6812:247
  2606:4700::6812:347
  
  www.ypf.com
  ypf.com.
  
  www.gob.ar
  
  www.uba.ar
  aijewx4.ng.impervadns.net.
  
  www.coto.com.ar
  
  www.somosjob.ar
  somosjob.ar.
  
  www.argentina.gob.ar
  2606:4700:20::681a:5b7
  2606:4700:20::ac43:4b23
  2606:4700:20::681a:4b7
  
  www.telecom.com.ar
  
  www.arcor.com
  arcor.P0585910867.fortiwebcloud.net.
  lb-3.us-east-1.aws.waas-online.net.
  
  www.techint.com
  techintcomprd.azurewebsites.net.
  waws-prod-cq1-003.sip.azurewebsites.windows.net.
  waws-prod-cq1-003.brazilsouth.cloudapp.azure.com.
  
  www.abc.gob.ar
  
  www.century21.com.ar
  
  www.uca.edu.ar
  
  www.galicia.ar
  
  www.osde.com.ar
  
  www.elalmacen.tv
  cdn3.wixdns.net.
  cfd.wixdns.net.
  
  www.carrefour.com.ar
  2a06:98c1:3108::ac40:9379
  2a06:98c1:3108::6812:2887
  
  www.unlp.edu.ar
  2800:340:0:64::135
  
  www.somosfarmacity.com
  farmacitybr02-bzf9h8a2fmbbfyeb.z01.azurefd.net.
  mr-z01.tm-azurefd.net.
  2603:1061:14:97::1
  
  www.hospitalitaliano.org.ar
  
  www.andreani.com
  www.andreani.com.cdn.cloudflare.net.
  2606:4700::6812:161a
  2606:4700::6812:171a
  
  www.mostazaweb.com.ar
  
  www.aesa.com.ar
  aesa.com.ar.
  
  www.claroempleos-aup.com
  
  www.swissmedical.com.ar
  swissmedical.com.ar.
  
  www.unc.edu.ar
  2801:120:842::5
  2801:120:842::4
  2801:120:842::6
  
  www.bbva.com.ar
  www.bbva.com.ar.edgekey.net.
  e6251.a.akamaiedge.net.
  
  www.bna.com.ar
  bna.com.ar.
  
  www.argentina.gob.ar
  2606:4700:20::681a:5b7
  2606:4700:20::ac43:4b23
  2606:4700:20::681a:4b7
  
  www.accenture.com
  4229prod2cf.r53cioaccenturecloud.net.
  d13iavm24b37u0.cloudfront.net.
  2600:9000:25f2:0:d:5159:5a00:93a1
  2600:9000:25f2:7e00:d:5159:5a00:93a1
  2600:9000:25f2:bc00:d:5159:5a00:93a1
  2600:9000:25f2:2600:d:5159:5a00:93a1
  2600:9000:25f2:2e00:d:5159:5a00:93a1
  2600:9000:25f2:9000:d:5159:5a00:93a1
  2600:9000:25f2:6a00:d:5159:5a00:93a1
  2600:9000:25f2:ca00:d:5159:5a00:93a1
  
  www.argentina.gob.ar
  2606:4700:20::681a:5b7
  2606:4700:20::ac43:4b23
  2606:4700:20::681a:4b7
  
  www.aerolineas.com.ar
  
  www.bancoprovincia.com.ar
  
  www.ocasa.com
  ocasa.com.
  
  www.macro.com.ar
  
  www.arca.gob.ar
  
  www.laanonima.com.ar
  
  www.argentina.gob.ar
  2606:4700:20::681a:5b7
  2606:4700:20::ac43:4b23
  2606:4700:20::681a:4b7
  
  www.naranjax.com
  2a06:98c1:3105::ac40:95eb
  2606:4700:440b::6812:2615
  
  www.informeg.com.ar
  informeg.com.ar.
  
  www.gruposancorseguros.com
  
  www.argentina.gob.ar
  2606:4700:20::681a:5b7
  2606:4700:20::ac43:4b23
  2606:4700:20::681a:4b7
  
  www.pecomenergia.com
  dam5tpv20rcp8.cloudfront.net.
  
  www.santander.com.ar
  www.santander.com.ar.edgekey.net.
  e90036.dscb.akamaiedge.net.
  2600:1406:2e00:28::17cb:a618
  2600:1406:2e00:28::17cb:a60d
  
  www.argentina.gob.ar
  2606:4700:20::681a:5b7
  2606:4700:20::ac43:4b23
  2606:4700:20::681a:4b7
  
  www.2606:4700:20::681a:4b7
  
  www.2606:4700:20::681a:5b7
  
  www.2606:4700:20::ac43:4b23
  
  www.unr.edu.ar
  
  www.utn.edu.ar
  
  www.cerveceriaymalteriaquilmes.com
  ug2aj8e.x.incapdns.net.
  
  www.argentina.gob.ar
  2606:4700:20::681a:5b7
  2606:4700:20::ac43:4b23
  2606:4700:20::681a:4b7
  
  www.adecoagro.com
  hostweb.adecoagro.com.
  
  www.mendoza.edu.ar
  
  www.veronicapalermo.com.ar
  
  www.uncuyo.edu.ar
  
  www.toyota.com.ar
  d14rtqisu6jdh1.cloudfront.net.
  2600:9000:211f:7800:e:6ac2:3d40:93a1
  2600:9000:211f:c800:e:6ac2:3d40:93a1
  2600:9000:211f:2600:e:6ac2:3d40:93a1
  2600:9000:211f:b200:e:6ac2:3d40:93a1
  2600:9000:211f:3200:e:6ac2:3d40:93a1
  2600:9000:211f:7400:e:6ac2:3d40:93a1
  2600:9000:211f:6800:e:6ac2:3d40:93a1
  2600:9000:211f:a600:e:6ac2:3d40:93a1
  
  www.argentina.gob.ar
  2606:4700:20::681a:5b7
  2606:4700:20::ac43:4b23
  2606:4700:20::681a:4b7
  
  www.uade.edu.ar
  
  www.diaonline.supermercadosdia.com.ar
  
  www.pan-energy.com
  
  www.sancorsalud.com.ar
  
  www.ar.linkedin.com
  
  www.cctld.linkedin.com.
  
  www.cctld.es.lnkdns.net.
  
  www.www.linkedin.com.cdn.cloudflare.net.
  
  www.rosario.gob.ar
  websrv2.rosario.gob.ar.
  
  www.mpf.gob.ar
  
  www.aysa.com.ar
  aysa.com.ar.
  
  www.uai.edu.ar
  alb-virt02-umbraco-503988087.us-east-1.elb.amazonaws.com.
  
  www.hospitalsanjuandedios.org.ar
  
  www.telecentro.com.ar
  
  www.nadro.mx
  d1j9d2nbk27vjw.cloudfront.net.
  2600:9000:21dd:8a00:3:847:5f00:93a1
  2600:9000:21dd:7400:3:847:5f00:93a1
  2600:9000:21dd:4200:3:847:5f00:93a1
  2600:9000:21dd:5a00:3:847:5f00:93a1
  2600:9000:21dd:1000:3:847:5f00:93a1
  2600:9000:21dd:fa00:3:847:5f00:93a1
  2600:9000:21dd:7c00:3:847:5f00:93a1
  2600:9000:21dd:200:3:847:5f00:93a1
  
  www.usal.edu.ar
  
  www.hospitalaleman.org.ar
  22pt6nf.impervadns.net.
  
  www.pluspetrol.net
  environmental-longan-72bw7rzlnwqdk0vjpbrlycnz.herokudns.com.
  
  www.edenor.com
  d14d07xru8rz5.cloudfront.net.
  2600:9000:21dd:f800:10:d7ce:6840:93a1
  2600:9000:21dd:9a00:10:d7ce:6840:93a1
  2600:9000:21dd:9600:10:d7ce:6840:93a1
  2600:9000:21dd:aa00:10:d7ce:6840:93a1
  2600:9000:21dd:8a00:10:d7ce:6840:93a1
  2600:9000:21dd:6600:10:d7ce:6840:93a1
  2600:9000:21dd:4c00:10:d7ce:6840:93a1
  2600:9000:21dd:6400:10:d7ce:6840:93a1
  
  www.cge.entrerios.gov.ar
  
  www.supervielle.com.ar
  
  www.pwc.com.ar
  www.pwc.com.ar.edgekey.net.
  e675.x.akamaiedge.net.
  
  www.mdp.edu.ar
  proxy.mdp.edu.ar.
  
  www.hospitalbritanico.org.ar
  ambitious-field-049c5d310.1.azurestaticapps.net.
  azurestaticapps1.trafficmanager.net.
  msha-slice-1-wus2-0.msha-slice-1-wus2-0-ase.p.azurewebsites.net.
  waws-prod-mwh-a269a7b8.sip.p.azurewebsites.windows.net.
  
  www.edu.ar
  
  www.gov.ar
  
  www.gdmseeds.com
  wp.wpenginepowered.com.
  
  www.iosfa.gob.ar
  2606:4700:3035::6815:25b7
  2606:4700:3037::ac43:d3a2
  
  www.unsam.edu.ar
  2606:4700:20::ac43:4b64
  2606:4700:20::681a:b10
  2606:4700:20::681a:a10
  
  www.newsan.com.ar
  
  www.argentina.gob.ar
  2606:4700:20::681a:5b7
  2606:4700:20::ac43:4b23
  2606:4700:20::681a:4b7
  
  www.argentina.gob.ar
  2606:4700:20::681a:5b7
  2606:4700:20::ac43:4b23
  2606:4700:20::681a:4b7
  
  www.edilizia.com.ar
  www.edilizia.com.ar.cdn.hstgr.net.
  2a02:4780:50:83e3:2d34:afe1:afaf:97bc
  2a02:4780:4e:a704:36c6:c5a7:478e:3a77
  
  www.hospitalaustral.edu.ar
  adc.hospitalaustral.edu.ar.
  
  www.unne.edu.ar
  wwwproxy.unne.edu.ar.
  
  www.bsg.global
  
  www.icbc.com.ar
  
  www.uca.edu.ar
  
  www.uns.edu.ar
  uns.edu.ar.
  
  www.fravega.com
  
  www.grupopetersen.com.ar
  376ee70d1c774050adbdb0e659a74dd5.v1.radwarecloud.net.



  $ echo ;  for  Argentina_Domain  in   tytconsultores.com.ar mercadolibre.com es.wikipedia.org techintgroup.com cencosud.com ypf.com gob.ar uba.ar coto.com.ar somosjob.ar argentina.gob.ar telecom.com.ar arcor.com techint.com abc.gob.ar century21.com.ar uca.edu.ar galicia.ar osde.com.ar elalmacen.tv carrefour.com.ar unlp.edu.ar somosfarmacity.com hospitalitaliano.org.ar andreani.com mostazaweb.com.ar aesa.com.ar claroempleos-aup.com swissmedical.com.ar unc.edu.ar bbva.com.ar bna.com.ar argentina.gob.ar accenture.com argentina.gob.ar aerolineas.com.ar bancoprovincia.com.ar ocasa.com macro.com.ar arca.gob.ar laanonima.com.ar argentina.gob.ar naranjax.com informeg.com.ar mseg.gba.gov.ar gruposancorseguros.com axionenergy.com argentina.gob.ar pecomenergia.com santander.com.ar argentina.gob.ar unr.edu.ar utn.edu.ar cerveceriaymalteriaquilmes.com argentina.gob.ar adecoagro.com mendoza.edu.ar veronicapalermo.com.ar uncuyo.edu.ar toyota.com.ar argentina.gob.ar uade.edu.ar diaonline.supermercadosdia.com.ar pan-energy.com sancorsalud.com.ar ar.linkedin.com rosario.gob.ar mpf.gob.ar aysa.com.ar uai.edu.ar hospitalsanjuandedios.org.ar telecentro.com.ar nadro.mx usal.edu.ar hospitalaleman.org.ar pluspetrol.net edenor.com cge.entrerios.gov.ar supervielle.com.ar pwc.com.ar mdp.edu.ar hospitalbritanico.org.ar edu.ar gov.ar gdmseeds.com iosfa.gob.ar unsam.edu.ar newsan.com.ar argentina.gob.ar argentina.gob.ar edilizia.com.ar hospitalaustral.edu.ar unne.edu.ar bsg.global icbc.com.ar uca.edu.ar uns.edu.ar fravega.com grupopetersen.com.ar   ;    do     echo $Argentina_Domain   ;   dig +short aaaa $Argentina_Domain   ;  echo    ; done
  
  tytconsultores.com.ar
  
  mercadolibre.com
  
  es.wikipedia.org
  dyna.wikimedia.org.
  2620:0:863:ed1a::1
  
  techintgroup.com
  
  cencosud.com
  
  ypf.com
  
  gob.ar
  
  uba.ar
  
  coto.com.ar
  
  somosjob.ar
  
  argentina.gob.ar
  2606:4700:20::681a:4b7
  2606:4700:20::681a:5b7
  2606:4700:20::ac43:4b23
  
  telecom.com.ar
  
  arcor.com
  
  techint.com
  
  abc.gob.ar
  
  century21.com.ar
  
  uca.edu.ar
  
  galicia.ar
  
  osde.com.ar
  
  elalmacen.tv
  
  carrefour.com.ar
  2a06:98c1:3108::ac40:9379
  2a06:98c1:3108::6812:2887
  
  unlp.edu.ar
  2800:340:0:64::135
  
  somosfarmacity.com
  
  hospitalitaliano.org.ar
  
  andreani.com
  
  mostazaweb.com.ar
  
  aesa.com.ar
  
  claroempleos-aup.com
  
  swissmedical.com.ar
  
  unc.edu.ar
  2801:120:842::4
  2801:120:842::5
  2801:120:842::6
  
  bbva.com.ar
  
  bna.com.ar
  
  argentina.gob.ar
  2606:4700:20::681a:4b7
  2606:4700:20::681a:5b7
  2606:4700:20::ac43:4b23
  
  accenture.com
  
  argentina.gob.ar
  2606:4700:20::681a:4b7
  2606:4700:20::681a:5b7
  2606:4700:20::ac43:4b23
  
  aerolineas.com.ar
  
  bancoprovincia.com.ar
  
  ocasa.com
  
  macro.com.ar
  
  arca.gob.ar
  
  laanonima.com.ar
  
  argentina.gob.ar
  2606:4700:20::681a:4b7
  2606:4700:20::681a:5b7
  2606:4700:20::ac43:4b23
  
  naranjax.com
  2a06:98c1:3105::ac40:95eb
  2606:4700:440b::6812:2615
  
  informeg.com.ar
  
  mseg.gba.gov.ar
  
  gruposancorseguros.com
  
  axionenergy.com
  
  argentina.gob.ar
  2606:4700:20::681a:4b7
  2606:4700:20::681a:5b7
  2606:4700:20::ac43:4b23
  
  pecomenergia.com
  
  santander.com.ar
  2600:1406:bc00:6a::172b:330f
  2600:1406:bc00:6a::172b:330d
  
  argentina.gob.ar
  2606:4700:20::681a:4b7
  2606:4700:20::681a:5b7
  2606:4700:20::ac43:4b23
  
  unr.edu.ar
  
  utn.edu.ar
  
  cerveceriaymalteriaquilmes.com
  
  argentina.gob.ar
  2606:4700:20::681a:4b7
  2606:4700:20::681a:5b7
  2606:4700:20::ac43:4b23
  
  adecoagro.com
  
  mendoza.edu.ar
  
  veronicapalermo.com.ar
  
  uncuyo.edu.ar
  
  toyota.com.ar
  
  argentina.gob.ar
  2606:4700:20::681a:4b7
  2606:4700:20::681a:5b7
  2606:4700:20::ac43:4b23
  
  uade.edu.ar
  
  diaonline.supermercadosdia.com.ar
  diaonline.supermercadosdia.com.ar.cdn.vtex.com.
  d3p7gg3f271ro.cloudfront.net.
  2600:9000:204d:5200:9:b144:ad00:93a1
  2600:9000:204d:7200:9:b144:ad00:93a1
  2600:9000:204d:7800:9:b144:ad00:93a1
  2600:9000:204d:9400:9:b144:ad00:93a1
  2600:9000:204d:8000:9:b144:ad00:93a1
  2600:9000:204d:5000:9:b144:ad00:93a1
  2600:9000:204d:6400:9:b144:ad00:93a1
  2600:9000:204d:4a00:9:b144:ad00:93a1
  
  pan-energy.com
  
  sancorsalud.com.ar
  
  ar.linkedin.com
  cctld.linkedin.com.
  cctld.es.lnkdns.net.
  www.linkedin.com.cdn.cloudflare.net.
  2a06:98c1:3109::6812:2929
  2a06:98c1:310b::ac40:92d7
  
  rosario.gob.ar
  
  mpf.gob.ar
  
  aysa.com.ar
  
  uai.edu.ar
  
  hospitalsanjuandedios.org.ar
  
  telecentro.com.ar
  
  nadro.mx
  
  usal.edu.ar
  
  hospitalaleman.org.ar
  
  pluspetrol.net
  
  edenor.com
  2600:9000:21dd:4000:10:d7ce:6840:93a1
  2600:9000:21dd:fc00:10:d7ce:6840:93a1
  2600:9000:21dd:6a00:10:d7ce:6840:93a1
  2600:9000:21dd:7a00:10:d7ce:6840:93a1
  2600:9000:21dd:2000:10:d7ce:6840:93a1
  2600:9000:21dd:5e00:10:d7ce:6840:93a1
  2600:9000:21dd:7000:10:d7ce:6840:93a1
  2600:9000:21dd:e000:10:d7ce:6840:93a1
  
  cge.entrerios.gov.ar
  
  supervielle.com.ar
  
  pwc.com.ar
  
  mdp.edu.ar
  
  hospitalbritanico.org.ar
  
  edu.ar
  
  gov.ar
  
  gdmseeds.com
  
  iosfa.gob.ar
  2606:4700:3035::6815:25b7
  2606:4700:3037::ac43:d3a2
  
  unsam.edu.ar
  2606:4700:20::ac43:4b64
  2606:4700:20::681a:a10
  2606:4700:20::681a:b10
  
  newsan.com.ar
  
  argentina.gob.ar
  2606:4700:20::681a:4b7
  2606:4700:20::681a:5b7
  2606:4700:20::ac43:4b23
  
  argentina.gob.ar
  2606:4700:20::681a:4b7
  2606:4700:20::681a:5b7
  2606:4700:20::ac43:4b23
  
  edilizia.com.ar
  2a02:4780:84:881e:443e:9364:14fd:ed8f
  2a02:4780:84:8c81:c13b:f920:84f2:6f33
  
  hospitalaustral.edu.ar
  
  unne.edu.ar
  
  bsg.global
  
  icbc.com.ar
  
  uca.edu.ar
  
  uns.edu.ar
  
  fravega.com
  
  grupopetersen.com.ar

If your device isn't able to reach 2606:4700:4700::1111, try using the DNS server 1.1.1.1

and run this bash command:

  for  USCompany  in    apple akamai att berkshire bestbuy boeing bofa burgerking cnn chase chevron citi comcast costco cvs dell disney fedex fidelity gatorade google goldmansachs gopro hellofresh hilton homedepot infowars in-n-out jcpenny johnsonandjohnson kaiser kroger lulumon macys mcdonalds microsoft nike pepsi petco radioshack safeway shell southwest sprouts statefarm tacobell target tesla traderjoes ups usbank uschamber walgreens walmart wellsfargo wholefoods yahoo    aquantuo atlanticseafarms beehivemeals beetlesplumbing dynamicautomotive jamies-farm joeandbella jovyco privacy4cars prosperityehr redroostercoffee resortlifecarts sproutlabs tradedesignbuild 
  do
    echo ${USCompany}
    dig +short aaaa www.${USCompany}.com
    echo  ; done

  for  USent  in    cia congress dhs epa ice fbi fcc nasa nsa whitehouse
  do
    echo ${USent}
    dig +short aaaa www.${USent}.gov
    echo  ; done

Argentina deserves better!

In enough cases, I'm sure many of us can think of some, some of the relatively recent "community" stuff has been counter-productive to an open source project, abused as an opportunity to enforce on clueless bystanders whatever fad orthodoxy of the day, or in the worst cases campaign viciously against specific demographics under the banner of doing the opposite.

Talented engineers who just want to do an open source project don't want any of that.

Separate from all that, I'm 100% with no Discord and no GitHub, both of those are total cancer.

What is shared here is a general direction. I am sure some people I know where all they do is networking could tell me harshly some of these ways could be done better, and often these people are right ; but sometimes these same people are actually wrong and don't fully consider the positions of people in IT roles at companies that aren't ISPs.

All suggested below is not necessarily the ultimate way but a general direction.

_

>> can only get IPv4 addresses through the ISP DHCP

ISP-owned IP addresses, either of legacy IP or IPv6, are capricious and can suddenly change, as you experienced recently.

I suggest to adopt a mindset of "our network" and "their network", rather than functionally have your network be a passive extension of their network by using their IP addresses.

The router announcements (IPv6 RA) or DHCP (IPv4) for any IP addresses within your network should always be issued by devices controlled solely by our organization.

NAT64 and tunnels exist, any upstream ISP is not a blocker.

Modern Linux has eBPF and eXpress Data Path. Both Linux and FreeBSD (use HardenedBSD if you can) have DPDK. They can make for surprisingly high performance edge routers on x86_64 server boxes over a decade old, exceeding what most campuses or even datacenter footprints actually need and at low cost. Even without eBPF & XDP or DPDK, these on x86_64 are often "good enough" for router and firewall.

DNS running on these or adjacent boxes internal to the organization is essential.

The addresses at the gateways, either of IPv4 or IPv6, can be made highly available with VRRPv3.

IPv6 has an elegant way to handle multiple upstream ISPs without VRRP or CARP at the gateways, but even Linux is just recently implementing what may only be a piece of them (the BSDs will later), some mention of them here https://news.ycombinator.com/item?id=50143420

_

What I would do, which is opinionated so I'm not necessarily suggesting others do it, assuming tunneling will be involved: if the organizational wherewithal is there to register an AS and do BGP, is pay the AUD 500 fee to register an AS and have a chunk of IPv6 space for to use IPv6 GUA addresses that officially belong to the organization.

If not, which is often enough the case because we know how some organizations can be slow (not making any assumptions about your's), the remaining avenue is to use IPv6 ULA addresses which are the spiritual counterpart to IPv4 RFC1918 addresses.

You can embed MAC addresses in IPv6 ULA addresses, like the MAC 82c6.7943.acb2 put in an IPv6 like

  fc00:5007:6525:2001:3003:82c6:7943:acb2

Then I would use IPv4-only ISP paths for what they're good for: dumb paths to tunnel IPv6 packets to where there is proper internet.

For the option with an AS, BGP announcements on the other side of the tunnel. Personally I would do SCION on the gateways and out the other side of the tunnel, but you don't want to do SCION unless you are also crazy (like a fox).

For the IPv6 ULA option, PAT which is the spiritual counterpart to IPv4's NAT but is also technologically simpler.

With IPv6 ULA and no tunneling, NAT64 and DNS64 can work for outbound.

Site to site tunnels will be tricky no matter what. Tailscale, ZeroTier, Netbird, and similar may be able to do much of the work for you ; these should run in a DMZ on another side of a router/firewall that filters the appropriate IPv6 ULA prefixes.

I would try to see if I could make vanilla Wireguard work with NAT traversal techniques using some cloud-hosted VMs that help with the "hole punching", but not everyone would do that.

There aren't many options that will all work well but almost always more than one option that can work well, all subject to the specific site and inter-organizational resources.

_

>> dropping IPv4 support might mean dropping support for older devices

For as long as it makes organizational sense to continue using these devices, put them behind an OpenBSD box that performs NAT46 and DNS46, with IPv4 addresses statically mapped to IPv6 addresses, maybe ones that contain the MAC addresses of the devices.

With Salt or Ansible, such a scheme with NAT, DNS, DHCP configuration may all be templatized and in perfect alignment, and is scalable.

Authoritative inventory of canonical identifiers/names versioned with Git, what Ansible calls "inventory", is imperative.

Sometimes this looks like a couple of old x86_64 boxes doing CARP (similar to VRRP) on the IPv4 side for a few dozen or couple hundred devices downstream.

Sometimes this looks like, in a handful of distant corners of the larger network, a cheap single-board computer between a single device and the rest of the network ; without a wifi chip or the wifi chip removed by heating (board-repair style), unless downstream of a wifi AP.

_

>> the ISP which is THE biggest ISP in Argentina, they don't offer IPv6 >> The ISP brand is Personal, local corp is Telecom Argentina S.A, Asynchronous System Number AS7303, trades as TEO in NYSE I think, owned by Grupo Clarin which comes is a traditional Media and news company.

I can think of some service provider network engineers that would gladly drop all of Argentina's IPv4 off the entire internet and "IPv6 prefix announcements welcome", if the business sides would let them do it.

Something like this will probably start happening sooner than people think.

I can tell you that in cicd for production Linux systems today, we have

  CONFIG_LEGACY_IP=""

_

What might work well for your organization is ZeroTier which will make you immune to what any ISPs do. The downside is your organization would be dependent on ZeroTier, but ZeroTier is much less likely to screw you over than any ISP.

  https://www.zerotier.com/

I appreciate your speculation on the principles of contract law. Like you, I believe those principles should be upheld and I believe in morality. If you lived under a monarchy and I were of the monarch, I would cross-examine your ISP in public and solve your problem in minutes. I would also on occasion take someone to the side of the road and chop off their head in front of the entire village, and everyone would know on a visceral level they are all much better off with someone taking out the trash now and then.

But, as many technical workers know, the contract stuff takes months or years to resolve, and technical issues involving IP addresses are best worked around with technical approaches.

_

What I would suggest your network team (you and whoever) do in your shoes is:

- set up NAT64 and DNS64 at the edges of subnets that contain devices that don't do IPv6 properly, because if these devices do not have updates to do IPv6 properly then they are broken in a fundamental way, and a workaround is necessary;

- dictate that starting on December 1st, all new devices and VMs have IPv6 addresses with all userspace services listening on IPv6 addresses or some nftables rule to kludge IPv6:$port -> 127.0.0.1:$port if necessary, with firewall configured to block that IPv6 traffic, then at a later date firewalls not blocking those IPv6 addresses, then at a later date prohibit any new IPv4 addresses being assigned anywhere with special exception to devices tagged "legacy" or "end of life" requiring documentation of such;

- use a combination of IPv6 GUA addresses assigned by whatever ISP and IPv6 ULA addresses chosen by your team -- in IPv6, multiple local gateways and multiple addresses on a network interface issued by those local gateways via RA is relatively a norm rather than an exception (requires userspace tooling in IPv4, DHCP doesn't have this functionality), so leverage this advantage;

- use IPv6 AH (authenticated headers) wherever possible;

- because in an ideal world, ISPs would behave consistently and IPv6 GUA addresses would always be stable, but we aren't living in an ideal world, so be ready to update your internal DNS to drop AAAA records containing IPv6 GUA that an upstream ISP fumbled;

- or, if you have the internal resources, register your own AS and command your own official block of IPv6 addresses;

- use a combination of OpenTOFU (Terraform) and Salt or Ansible, all versioned with Git, be very strict with your team about versioning with Git, to manage everything, and use

  terraform plan -detailed-exitcode

- move userspace services to Podman where possible.

Personally I like Salt. I know Ansible is more popular out there with more inertia.

_

>> why are we normalizing the removal of IPv4 addresses?

This was normalized a long time ago actually. "The future is already here, it's just not evenly distributed".

You and I are total strangers on different corners of the globe. You may not like what you're about to read, but it's better that you get a hint where the wind is blowing sooner than not.

If my team were consulting with your organization's execs and we caught a hint that the existing internal resources were not already proactively staying current with internet protocol (which is IPv6), we would point out there is urgency to start right away with emphasis that the existing internal team is over two decades behind staying current.

Or, if a detected hint the internal team were at all resistant to IPv6, we would advise the executive team to start developing a plan to flush out the replacements for the internal team ASAP.

Many network engineers at many ISPs would gladly drop all IPv4 traffic if they thought they could get away with it.

IPv6 only seems more complicated if you still need to unlearn IPv4. IPv6 does have a steeper learning curve, but once that learning curve is overcome, IPv6 is actually much simpler than IPv4. More people than not don't like reading RFCs, but professionals do slowly read RFCs on their own time.

  https://en.wikipedia.org/wiki/End-to-end_principle

Anyone who doesn't by default set up IPv6-only networks by default with NAT64 and DNS64, or who present any notion that IPv4 is somehow "okay", shouldn't have a job anywhere, not even an entry-level desktop support job.

  Our free tunnel broker service enables you to reach the IPv6 Internet by tunneling over existing IPv4 connections from your IPv6 enabled host or router to one of our IPv6 routers.

  https://tunnelbroker.net/