jon128
Someone speaks my language <3
_
This could really take off if the leadership can demonstrate remote-native work patterns. The on-site requirement is low oxygen.
In some advanced settings where tolerances for potential impacts resulting from exploited software vulnerabilities are intensely low, Kubernetes (userspace software) on HardenedBSD is choice for mission.
Like with the other two systems, those running Kubernetes userspace on them are self-sufficient and are not among the audience of external more general Kubernetes distro support channels.
If you happen to like RKE, check out https://Talos.dev which is the best Kubernetes on Linux distro (for most Kubernetes on Linux use cases).
_
@nijave
Nomad and Kubernetes schedule containers, which are rarely not Linux containers, yeah.
Both can schedule processes in FreeBSD's BSD Jails.
If someone wants to start an open Kubernetes on FreeBSD/HardenedBSD project I would encourage that. Personally I would like to see an open Kubernetes on illumos project.
As far as I know where Kubernetes on HardenedBSD runs is not interested in open projects.
Separate from any of those, a good chunk of America's more sensitive production database clusters, other workloads, and some network applications are scheduled by Nomad or Kubernetes running directly on a kernel that is not Linux.
The most popular kernel is not necessarily appropriate for all use cases or types of environments where high-value targets reside.
Directly downstream of FreeBSD, HardenedBSD achieved its long history of invulnerability to what were exploitable vulnerabilities in upstream through its advancements in the operating system layer.
https://hardenedbsd.org/content/easy-feature-comparison
> but security thru obscurity
Arrogance is stupidity.
I am hoping to see an indication that https://grsecurity.net/ patches preemptively mitigated CVE-2026-98432 but I'm feeling less optimistic.
This vulnerability has been a stark reminder to why in some places things are running on HardenedBSD instead of Linux.
https://rescript-lang.org/A SQL query would defeat the purported anonymity in many cases. An ai model would look at the other cases where IPs of VPNs or Tor are used, uncover much, and yawn.
Now another set of servers are operated by Flux. That helps. But you know how BFFs are with each other, inter-team access to data sinks.
These posts on Reddit and this orange reddit over here by maqp are high quality. They should be read thoroughly.
On the other side of this, the ability to change the receiving server with zero-interaction by remote contacts does lay a cornerstone for effectively anonymizing users. The option to add additional servers used by a SimpleX profile is another cornerstone.
But the mainline user interface hasn't been updated to use these effectively.
What I do like about SimpleX is it is, with a massive asterisk, distributed. SimpleX in practice lives somewhere between decentralized and distributed right now. SimpleX as used by the unwashed masses and disregarding everyone else, is decentralized, or quasi-decentralized.
SimpleX is not confined to a centralized permissioned namespace like Signal 501c3's service which is total vendor lock-in, for fools (yes if you are using that service, you have been had).
SimpleX has shirked the manual processes that XMPP+OMEMO users need to proactively do for a distributed experience.
The audited core Haskell code is hard to argue with. Looking forward to a successor in Lean.
But today, both SimpleX and the better XMPP clients are best enjoyed with community-managed container compose files.
I have read in places apparently originated from more than two minds some zero knowledge approaches that do functionally mitigate any usable identifiers, sans where users are of a small crowd and rarely ever change source IPs, so as much as may ever be practicable with current generations of IP (Reticulum with no source addresses looking better and better). Will be cool to see these implemented.
There may also be a way to do multiple redundant server paths that may be more efficient.
Much waiting to be done, things simply throwing an LLM at won't achieve.
I am convinced by the behavior of some degenerates that one of among those things is not a polished iOS app. iOS is a total cancer. iOS, for which no source code is available outside of Apple and its puppeteers, is for slaves. Voluntarily use of iOS, is an explicit admission cybersecurity-illiteracy.
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.
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:4233USB 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-governmentThe 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.