[conspire] (forw) Re: [skeptic] A butterfly flapped its wings and:

[Michael Paoli]

> From: "Rick Moen" <rick at linuxmafia.com>
> Subject: [conspire] (forw) Re: [skeptic] A butterfly flapped its wings and:
> Date: Wed, 9 Jun 2021 16:19:13 -0700

> Quoting Laurie Forbes (laforbes at telus.net):
>
>> *A major internet blackout that hit many high-profile websites on
>> Tuesday has been blamed on a software bug.*

And there has been clamoring and gnashing of teeth and noises ...
I think I saw some (poor) headlines along the lines of:
Oh my gosh, The Internet is fragile, we must do something about that!

Uhm, no, The Internet is mostly pretty dang robust and mostly works,
thank-you-very-much - and please don't screw that up.

Now, on the other hand, putting most or all of one's eggs in one basket,
oh ... like Fastly ... might sometimes get bitten or have a problem
or glitch.  "Oops".  Oh well.  But The Internet remained fine throughout.
Just a whole lot 'o sites/services that depended upon Fastly had problems
for a while.  But folks and services with no such dependencies - no such
problems - they were fine.

Likewise doing dumb/stupid/insecure things on The Internet - might cause
problems for oneself or one's organization.  Always has been the case,
always will be.  Just like wandering inattentively through most any major
bustling international city and paying next to no attention to anything,
can also be rather hazardous.  So, yeah, don't do that - don't be stupid
and insecure and failing to pay reasonable attention to the environments
within which one is operating, do be suitably prepared and as relevant
defended.  It's not The Internet that needs fixin'.  It's folks paying
more attention and setting themselves up properly to operate in such
environments - and it's not a set it and forget it. Threats change and
evolve.  Just like if you were going to go to some exotic foreign country for
an extended visit ... what are the current immunizations and safety protocols
and things one should avoid?  Yeah, what was current 20 years ago may not be
the best advice for what's relevant and appropriate and reasonably safe now.

And yes where there are rather persistent bad actors out there, sure, more
could be done to thwart/stop them.  But it will never be fully safe out
there.  So, again, it's not The Internet that needs fixin'.

How you do things on The Internet, set yourself / your organization,
services, etc. up - it matters.  What services you outsource to what
vendor(s), what software you trust and depend upon, etc.

>> Fastly, the cloud-computing company responsible for the issues, said
>> the bug had been triggered when one of its customers had changed
>> their settings.
>
> As the old saying here in the open source world goes, 'There is no
> "the cloud"; there's just someone else's computer.'
>
>> https://www.bbc.com/news/technology-57413224
>
> "Fastly" is a Content Delivery Network (CDN) company, essentially a
> place you pay to handle incoming requests for your Web traffic and serve
> them cached copies, because otherwise you expect to be overwhelmed,
> either because some parties hate you and are trying to take you down
> with Denial of Service (DoS) attacks or because you've just become
> insanely popular with legitimate traffic and need help handling the
> load.  Typically, CDNs have data centres widely distributed around the
> world so that they can use GeoIP techniques to serve up cached content
> from a network-wise close location to the customer, hence with good
> responsiveness.
>
> Major CDNs (that may sound familiar) include Cloudfare and Akamai.
>
> Here is a story about Fastly's embarrassing problem of yesterday, that
> is less uselessly vague than was Auntie Beeb's:
> https://gizmodo.com/how-one-fastly-customer-broke-the-internet-1847061755
> And a VP's blog post:
> https://www.fastly.com/blog/summary-of-june-8-outage
>
> In order for a CDN's services to be usable by paying customers, they
> must be able to communicate over the Web to inform the CDN network about
> what to cache, under what circumstances to refresh the content from the
> customer's own Web server,
>
> The description of the specific error cascade is vague.  Some customer
> changed his/her local IP address or DNS configuration, and through
> triggering an unspecified bug in the software connection to Fastly's CDN
> software, which in turn cause massive software failure within Fastly's
> CDN management software, taking out 85% of their capacity for an hour.
>
> As should be obvious, this isn't supposed to be possible, and indirectly
> points to one hell of a serious bug.