# Around 10 Percent Of The Internet Is Encrypted Via Lava Lamps

We don't want to sound completely unhinged, like someone yelling
"sharks have been around the galaxy twice" (they have [1]) or
"McFlurries look the way they do because of hedgehogs" (they do [2]),
but around 10 percent of the Internet is encrypted via lava lamps.

Encryption, in its most basic form, is scrambling data (be that text,
image, or video) so that only the sender and recipient with their
encryption keys can read it. Though now associated with computing,
encryption has been around for centuries, with the first recorded
cipher dating back to around 400 BCE, used by Spartan military
officers to secretly communicate.

Encryption varies in complexity. By using simple substitution ciphers
(e.g. a = b, b = c, and so on) you are taking plain text and
converting it into encrypted ciphertext, which someone else can
convert back to readable text if they have (or guess) your very
simple key. Meanwhile, in computer encryption, 56-bit encryption
keys, with 72,057,594,037,927,936 possibilities, proved themselves to
be too easy to crack when they were solved by security experts on
refurbished computer equipment within 56 hours by brute force.

As well as using 128-bit or higher keys, security experts try to make
them harder to break by making them as random as possible. Computers,
with their ordered logical "if this then that" way of working, are
not great at introducing randomness, but fortunately for your
encrypted top-secret WhatsApp meme group, we have other ways of doing
that, including lava lamps.

YouTuber Tom Scott visits the encryption lamps. [3]

"To produce the unpredictable, chaotic data necessary for strong
encryption, a computer must have a source of random data. The 'real
world' turns out to be a great source for randomness, because events
in the physical world are unpredictable," CloudFare , which encrypts
up to 10 percent of the Internet using the lava lamp method, explains
on their website. [4]

"As one might expect, lava lamps are consistently random. The 'lava'
in a lava lamp never takes the same shape twice, and as a result,
observing a group of lava lamps is a great source for random data."

At CloudFare, there is a wall of around 100 lava lamps, which are
running and doing their gloopy thing. At intervals, a camera pointed
at the lamps takes a photo. The random colors of the pixels are then
used to create an encryption key.

"All digital images are really stored by computers as a series of
numbers, with each pixel having its own numerical value," CloudFare
explained, "and so each image becomes a string of totally random
numbers that the Cloudflare servers can then use as a starting point
for creating secure encryption keys."

The unpredictable nature of this key, with no obvious patterns to the
long number string that can be discerned and used to crack the code,
makes it very effective as an encryption method, whilst also giving
your data a nice, retro-70s vibe as a side product.

[H/T: Atlas Obscura] [5]

[1]
<https://www.iflscience.com/
sharks-are-so-old-theyve-been-around-the-galaxy-twice-so-far-71164>

[2]
<https://www.iflscience.com/
mcflurries-look-the-way-they-do-because-of-hedgehogs-62202>

[3]
<https://www.youtube.com/watch?v=1cUUfMeOijg>

[4]
<https://www.cloudflare.com/en-gb/learning/ssl/lava-lamp-encryption/>

[5]
<https://www.atlasobscura.com/videos/
these-lava-lamps-help-encrypt-the-internet>

Ben Collver wrote:

> YouTuber Tom Scott visits the encryption lamps. [3]

The video in question is half a decade old.

--

Ben Collver <bencollver@tilde.pink> wrote:
>
> "As one might expect, lava lamps are consistently random. The 'lava'
> in a lava lamp never takes the same shape twice, and as a result,
> observing a group of lava lamps is a great source for random data."
>
> At CloudFare, there is a wall of around 100 lava lamps, which are
> running and doing their gloopy thing. At intervals, a camera pointed
> at the lamps takes a photo. The random colors of the pixels are then
> used to create an encryption key.

That's neat, although I can't help but think of how inefficient it
is compared to most other random data sources, given all the power
that would be required by 100 lava lamps. Various other common
enthropy sources would use less power than the camera filming them.
Clearly a gimmick. Still I'll admit that if someone else was
paying the power bill, I'd love nothing more than to have a job
building something like that. :)

The Cloudflare page also goes on to describe other novel methods
that they use at other offices, which are less audaciously
power-hungry:

"The other two main Cloudflare offices are in London and Singapore,
and each office has its own method for generating random data from
real-world inputs. London takes photos of a double-pendulum system
mounted in the office (a pendulum connected to a pendulum, the
movements of which are mathematically unpredictable). The Singapore
office measures the radioactive decay of a pellet of uranium (a
small enough amount to be harmless)."

> [4]
> <https://www.cloudflare.com/en-gb/learning/ssl/lava-lamp-encryption/>

I wish Cloudflare would learn that no amount of cute enthropy
sourcing can compensate for the frustration of that link going to
an almost blank page that tells me:

"Enable JavaScript and cookies to continue"

Alternative:
http://web.archive.org/web/20230531034708/https://www.cloudflare.com/en-gb/learning/ssl/lava-lamp-encryption/

--
__ __
#_ < |\| |< _# | Note: I won't see posts made from Google Groups |

On 10/26/23 16:47, Computer Nerd Kev wrote:
> Ben Collver <bencollver@tilde.pink> wrote:
>>
>> "As one might expect, lava lamps are consistently random. The 'lava'
>> in a lava lamp never takes the same shape twice, and as a result,
>> observing a group of lava lamps is a great source for random data."
>>
>> At CloudFare, there is a wall of around 100 lava lamps, which are
>> running and doing their gloopy thing. At intervals, a camera pointed
>> at the lamps takes a photo. The random colors of the pixels are then
>> used to create an encryption key.
>
> That's neat, although I can't help but think of how inefficient it
> is compared to most other random data sources, given all the power
> that would be required by 100 lava lamps. Various other common
> enthropy sources would use less power than the camera filming them.
> Clearly a gimmick. Still I'll admit that if someone else was
> paying the power bill, I'd love nothing more than to have a job
> building something like that. :)
>
> The Cloudflare page also goes on to describe other novel methods
> that they use at other offices, which are less audaciously
> power-hungry:
>
> "The other two main Cloudflare offices are in London and Singapore,
> and each office has its own method for generating random data from
> real-world inputs. London takes photos of a double-pendulum system
> mounted in the office (a pendulum connected to a pendulum, the
> movements of which are mathematically unpredictable). The Singapore
> office measures the radioactive decay of a pellet of uranium (a
> small enough amount to be harmless)."

I think random.org uses atmospheric noise, which is basically free.
--
user <candycane> is generated from /dev/urandom

On 2023-10-26, Computer Nerd Kev <not@telling.you.invalid> wrote:
> I wish Cloudflare would learn that no amount of cute enthropy
> sourcing can compensate for the frustration of that link going to
> an almost blank page that tells me:
>
> "Enable JavaScript and cookies to continue"

Hear hear! It is a major source of frustration for users of a
certain Linux forum that i read, where the admins have chosen to
use Clownflare for DDoS protection.

not@telling.you.invalid (Computer Nerd Kev) writes:

> Ben Collver <bencollver@tilde.pink> wrote:
>>
>> "As one might expect, lava lamps are consistently random. The 'lava'
>> in a lava lamp never takes the same shape twice, and as a result,
>> observing a group of lava lamps is a great source for random data."
>>
>> At CloudFare, there is a wall of around 100 lava lamps, which are
>> running and doing their gloopy thing. At intervals, a camera pointed
>> at the lamps takes a photo. The random colors of the pixels are then
>> used to create an encryption key.
>
> That's neat, although I can't help but think of how inefficient it
> is compared to most other random data sources, given all the power
> that would be required by 100 lava lamps. Various other common
> enthropy sources would use less power than the camera filming them.
> Clearly a gimmick. Still I'll admit that if someone else was
> paying the power bill, I'd love nothing more than to have a job
> building something like that. :)

I had a go at extracting random numbers from a lightening globe -- yew
kno, glass globe that generates a lightening-like electrical display
wandering randomly around the inside surface. Put the globe in front
of a web cam, played with the image data. Never managed to figure out
how to get reliably random numbers from it. Maybe I needed a whole
wall of them? :-o

> I wish Cloudflare would learn that no amount of cute enthropy
> sourcing can compensate for the frustration of that link going to
> an almost blank page that tells me:
>
> "Enable JavaScript and cookies to continue"

For which read:

"You appear to be part of a geeky, cranky and insignificant segment
of the market that we don't care about but we're politly inviting
you to revert to normalcy, joint the herd and do things our way."

--
Mike Spencer Nova Scotia, Canada

2023-10-27, Mike Spencer <mds@bogus.nodomain.nowhere> schrieb:
>
> not@telling.you.invalid (Computer Nerd Kev) writes:
>
>> Ben Collver <bencollver@tilde.pink> wrote:
>>>
>>> "As one might expect, lava lamps are consistently random. The 'lava'
>>> in a lava lamp never takes the same shape twice, and as a result,
>>> observing a group of lava lamps is a great source for random data."
>>>
>>> At CloudFare, there is a wall of around 100 lava lamps, which are
>>> running and doing their gloopy thing. At intervals, a camera pointed
>>> at the lamps takes a photo. The random colors of the pixels are then
>>> used to create an encryption key.
>>
>> That's neat, although I can't help but think of how inefficient it
>> is compared to most other random data sources, given all the power
>> that would be required by 100 lava lamps. Various other common
>> enthropy sources would use less power than the camera filming them.
>> Clearly a gimmick. Still I'll admit that if someone else was
>> paying the power bill, I'd love nothing more than to have a job
>> building something like that. :)
>
> I had a go at extracting random numbers from a lightening globe -- yew
> kno, glass globe that generates a lightening-like electrical display
> wandering randomly around the inside surface. Put the globe in front
> of a web cam, played with the image data. Never managed to figure out
> how to get reliably random numbers from it. Maybe I needed a whole
> wall of them? :-o

I have a very cheap webcam, I take a picture and use a hash of that.

--
Jan v/d Broek balglaas@dds.nl

"Ich kenne das Leben, ich bin im Kino gewesen."

Jan van den Broek <balglaas@dds.nl> writes:

> 2023-10-27, Mike Spencer <mds@bogus.nodomain.nowhere> schrieb:
>
>> I had a go at extracting random numbers from a lightening globe -- yew
>> kno, glass globe that generates a lightening-like electrical display
>> wandering randomly around the inside surface. Put the globe in front
>> of a web cam, played with the image data. Never managed to figure out
>> how to get reliably random numbers from it. Maybe I needed a whole
>> wall of them? :-o
>
> I have a very cheap webcam, I take a picture and use a hash of that.

I didn't think of that. I've done some reading but don't know enough
about the math to understand clearly that the/a/whatever hashing
algorithm that is (more or less) guaranteed to produce a unique
irreversible hash of its input will also produce a bit stream meeting
crypto standards for "random".

Along the same line, I don't understand why you can't (or can?)
produce a random bit stream by running a hash algorithm on whatever
files chosen by personal whim from your HD (or any arbitrary source)
and stringing the output bits together. I infer that such a technique
must have weaknesses or I would have heard about getting crypto random
numbers that way.

--
Mike Spencer Nova Scotia, Canada

Keen on math but weak on actually doing it.

Mike Spencer <mds@bogus.nodomain.nowhere> wrote:
> Jan van den Broek <balglaas@dds.nl> writes:
>> 2023-10-27, Mike Spencer <mds@bogus.nodomain.nowhere> schrieb:
>>> I had a go at extracting random numbers from a lightening globe -- yew
>>> kno, glass globe that generates a lightening-like electrical display
>>> wandering randomly around the inside surface. Put the globe in front
>>> of a web cam, played with the image data. Never managed to figure out
>>> how to get reliably random numbers from it. Maybe I needed a whole
>>> wall of them? :-o
>>
>> I have a very cheap webcam, I take a picture and use a hash of that.
>
> I didn't think of that. I've done some reading but don't know enough
> about the math to understand clearly that the/a/whatever hashing
> algorithm that is (more or less) guaranteed to produce a unique
> irreversible hash of its input will also produce a bit stream meeting
> crypto standards for "random".

Presumably it's not ideal if there's a pattern to hashes, because
that could only make them easier to predict/brute-force. But are
common hashes ideal or not? The whole idea of hashes is that they
produce completely different output from similar inputs, so I
expect the worst you could get is an added bias in the data stream,
not a recurring pattern due to the similarity of the different
images.

If the hashing just creates a bias, then debiasing is an easy and
normal process in harvesting data from a random source. Simply
discard every input pair of bits in a row that are the same
(reading the hash as a sequence of binary number values).

> Along the same line, I don't understand why you can't (or can?)
> produce a random bit stream by running a hash algorithm on whatever
> files chosen by personal whim from your HD (or any arbitrary source)
> and stringing the output bits together. I infer that such a technique
> must have weaknesses or I would have heard about getting crypto random
> numbers that way.

It could, but it would be a pseudo-random generator rather than a
true random generator if you don't touch files on the system
between runs of the program generating the random data. Then
the program will follow the exact same pattern and generate the
exact same data on the second run. The random data source is the
person using the computer and changing files, and data like
keyboard/mouse input timing data is already used by Linux to feed
/dev/random, and feeds on the random nature of its human master
in a more direct way than by checking what files they've saved.

--
__ __
#_ < |\| |< _# | Note: I won't see posts made from Google Groups |

Mike Spencer <mds@bogus.nodomain.nowhere> writes:
> Jan van den Broek <balglaas@dds.nl> writes:
>> 2023-10-27, Mike Spencer <mds@bogus.nodomain.nowhere> schrieb:
>>> I had a go at extracting random numbers from a lightening globe --
>>> yew kno, glass globe that generates a lightening-like electrical
>>> display wandering randomly around the inside surface. Put the globe
>>> in front of a web cam, played with the image data. Never managed to
>>> figure out how to get reliably random numbers from it. Maybe I
>>> needed a whole wall of them? :-o
>>
>> I have a very cheap webcam, I take a picture and use a hash of that.
>
> I didn't think of that. I've done some reading but don't know enough
> about the math to understand clearly that the/a/whatever hashing
> algorithm that is (more or less) guaranteed to produce a unique
> irreversible hash of its input will also produce a bit stream meeting
> crypto standards for "random".

No hashing algorithm is guaranteed to produce unique outputs. That would
be impossible since there are overwhelmingly more possible inputs than
outputs.

> Along the same line, I don't understand why you can't (or can?)
> produce a random bit stream by running a hash algorithm on whatever
> files chosen by personal whim from your HD (or any arbitrary source)
> and stringing the output bits together. I infer that such a technique
> must have weaknesses or I would have heard about getting crypto random
> numbers that way.

Cryptographic RNGs don’t keep their past internal state around - if they
did then an attacker who somehow got hold of it could re-run the RNG to
find its subsequent output. In this case the past state would be your
hard disk.

In concrete terms an attacker who could recover the contents of your
hard disk (in a later data breach, or with a warrant, etc) would only
have to calculate the hash of each file on your disk in order to predict
the possible outputs from your RNG - unlikely to be more than a few
billion operations.

In contrast with a proper RNG the attacker has no better option than
exhaustive search.

--
https://www.greenend.org.uk/rjk/

In article <slrnujnohk.2j9.bencollver@svadhyaya.localdomain>,
Ben Collver <bencollver@tilde.pink> wrote:
>On 2023-10-26, Computer Nerd Kev <not@telling.you.invalid> wrote:
>> I wish Cloudflare would learn that no amount of cute enthropy
>> sourcing can compensate for the frustration of that link going to
>> an almost blank page that tells me:
>>
>> "Enable JavaScript and cookies to continue"
>
>Hear hear! It is a major source of frustration for users of a
>certain Linux forum that i read, where the admins have chosen to
>use Clownflare for DDoS protection.

I have never encountered this or found it to be a problem with a browser,
seeing that most sites today seem to require javascript and cookies for any
function at all anyway. But of course cloudflare often breaks wget which
is an issue.

Oracle Linux 8 uses cloudflare caching for distros rather than maintaining
multiple mirrors, which means you can forget getting yum through a
corporate firewall where the number of outgoing addresses is restricted.

But for what it's intended for, it seems to do okay.
--scott
--
"C'est un Nagra. C'est suisse, et tres, tres precis."

Scott Dorsey <kludge@panix.com> wrote:
> In article <slrnujnohk.2j9.bencollver@svadhyaya.localdomain>,
> Ben Collver <bencollver@tilde.pink> wrote:
>>On 2023-10-26, Computer Nerd Kev <not@telling.you.invalid> wrote:
>>> I wish Cloudflare would learn that no amount of cute enthropy
>>> sourcing can compensate for the frustration of that link going to
>>> an almost blank page that tells me:
>>>
>>> "Enable JavaScript and cookies to continue"
>>
>>Hear hear! It is a major source of frustration for users of a
>>certain Linux forum that i read, where the admins have chosen to
>>use Clownflare for DDoS protection.
>
> I have never encountered this or found it to be a problem with a browser,
> seeing that most sites today seem to require javascript and cookies for any
> function at all anyway.

Most don't require it for simply viewing information. If I'm
looking for information on a subject, when I'll usually be using
a browser without JS support, then if a web search brings up a
page that does that, I'll most likely try another result rather
than switch over to another browser.

Where a search function requires JS, using "site:" in a DuckDuckGo
search can be a good (sometimes better) alternative. For anything
requiring some sort of log-in it is pretty much a lost cause now
though, especially with (mostly Google) captchas everywhere.

--
__ __
#_ < |\| |< _#

On 28 Oct 2023 22:33:36 -0000
kludge@panix.com (Scott Dorsey) wrote:
> In article <slrnujnohk.2j9.bencollver@svadhyaya.localdomain>,
> Ben Collver <bencollver@tilde.pink> wrote:
> >On 2023-10-26, Computer Nerd Kev <not@telling.you.invalid> wrote:
> >> "Enable JavaScript and cookies to continue"
> >
> >Hear hear! It is a major source of frustration for users of a
> >certain Linux forum that i read, where the admins have chosen to
> >use Clownflare for DDoS protection.
>
> I have never encountered this or found it to be a problem with a browser,
> seeing that most sites today seem to require javascript and cookies for any
> function at all anyway.

I can search Google , amazon , read IMDB and many other sites just using w3m
(and with no cookies) .If I expect that a website has mostly text based
content but requires javascript to read it , I assume that it's poorly
designed and I need not bother. The only real annoyance is not being able to
read comments under youtube videos without javascript. On the vast majority
of occasions I choose not to read the comments.

> But of course cloudflare often breaks wget which is an issue.

It also prevents access from w3m and you don't even get an informative
message. But if I'm really interested in the content , it often is available
through Google cache.

--
Action fans will love it because of the zombies, girls will love it because
of the heart warming story of love, zombies will love it because of zombies,
in fact, this movie is probably the key to world peace.
https://www.imdb.com/review/rw1029480/

On Sat, 28 Oct 2023 22:26:26 +0100
Richard Kettlewell <invalid@invalid.invalid> wrote:
> Mike Spencer <mds@bogus.nodomain.nowhere> writes:
> > I didn't think of that. I've done some reading but don't know enough
> > about the math to understand clearly that the/a/whatever hashing
> > algorithm that is (more or less) guaranteed to produce a unique
> > irreversible hash of its input will also produce a bit stream meeting
> > crypto standards for "random".
>
> No hashing algorithm is guaranteed to produce unique outputs. That would
> be impossible since there are overwhelmingly more possible inputs than
> outputs.

Depends what "unique" means. If it means a 1-1 function from inputs to
outputs then it would be impossible for the reason you mention. If it means
an output never encountered before in the history of mankind and extremely
unlikely to ever be encountered again then we are in fact hoping that
cryptographic hashing algorithms achieve this.

> > Along the same line, I don't understand why you can't (or can?)
> > produce a random bit stream by running a hash algorithm on whatever
> > files chosen by personal whim from your HD (or any arbitrary source)
> > and stringing the output bits together. I infer that such a technique
> > must have weaknesses or I would have heard about getting crypto random
> > numbers that way.

[...]

> In concrete terms an attacker who could recover the contents of your
> hard disk (in a later data breach, or with a warrant, etc) would only
> have to calculate the hash of each file on your disk in order to predict
> the possible outputs from your RNG - unlikely to be more than a few
> billion operations.
>
> In contrast with a proper RNG the attacker has no better option than
> exhaustive search.

I think the technique proposed is to randomly ("whim") choose a subset
of your files and then combine the output bits in some order. So the
final output would depend on both which subset of your files you chose
and in which order you combined them. If you have say 1000 files then
there are 2**1000 possible subsets and , if you chose N files , there
are N! different orders you can put them in. It's not possible to do
an exhaustive search on that.

I don't know if the technique proposed would be secure. One objection
is that humans are not random enough even if they feel like they are
doing things randomly and that's why it is not considered a good technique
to generate passwords by "randomly" banging keys on your keyboard.

Another concern is not to leave traces in your command line history or
whatever. If you can avoid that , perhaps it would be a secure technique
but likely inconvenient.

[I note that there exists sci.crypt]

--
vlaho.ninja/menu

Spiros Bousbouras <spibou@gmail.com> writes:
> Richard Kettlewell <invalid@invalid.invalid> wrote:
>> Mike Spencer <mds@bogus.nodomain.nowhere> writes:
>>> I didn't think of that. I've done some reading but don't know
>>> enough about the math to understand clearly that the/a/whatever
>>> hashing algorithm that is (more or less) guaranteed to produce a
>>> unique irreversible hash of its input will also produce a bit stream
>>> meeting crypto standards for "random".
>>
>> No hashing algorithm is guaranteed to produce unique outputs. That would
>> be impossible since there are overwhelmingly more possible inputs than
>> outputs.
>
> Depends what "unique" means. If it means a 1-1 function from inputs to
> outputs then it would be impossible for the reason you mention. If it means
> an output never encountered before in the history of mankind and extremely
> unlikely to ever be encountered again then we are in fact hoping that
> cryptographic hashing algorithms achieve this.

That’s not what unique means, though. The property you’re talking about
is collision resistance and we don’t just look for it to be unlikely, we
look for it to be hard to find collisions even deliberately.

> I think the technique proposed is to randomly ("whim") choose a subset
> of your files and then combine the output bits in some order. So the
> final output would depend on both which subset of your files you chose
> and in which order you combined them. If you have say 1000 files then
> there are 2**1000 possible subsets and , if you chose N files , there
> are N! different orders you can put them in. It's not possible to do
> an exhaustive search on that.

Nobody with any sense will do anything like this. There are much better
sources of entropy and much better PRNGs readily available.

--
https://www.greenend.org.uk/rjk/

>>>>> On 2023-10-29, Spiros Bousbouras wrote:
>>>>> On 28 Oct 2023 22:33:36 -0000 (Scott Dorsey) wrote:

[Cross-posting to news:comp.infosystems.www.misc .]

>> I have never encountered this or found it to be a problem with a
>> browser, seeing that most sites today seem to require javascript
>> and cookies for any function at all anyway.

> I can search Google, amazon, read IMDB and many other sites just
> using w3m (and with no cookies).

I'm using Lynx as my primary web user agent for two decades
now, and I don't have any trouble finding readable websites.

When uMatrix was in Debian, I've used it whenever I needed to
use Chromium. Aside of things like eshops or my bank's web
interface, I don't recall it's been /necessary/ to enable
Javascript for most of the websites I read to function.

For eshops et al. that use Javascript to show their catalog,
the workaround I'm using is to: a. use in-browser debugging
facilities to figure out which URI they query (typically with
XMLHttpRequest) for data; b. query that URI with curl(1)
instead. The results can then be made presentable with Sed
/ Awk / Perl / whatever.

Consider, e. g. (a somewhat artifical example: this data is
accessible with Lynx as it is):

$ curl -skim23 -- https://commons.wikimedia.org/w/api.php\
"?format=xml&action=query&prop=coordinates|info|linkshere|revisions\
&rvprop=ids|timestamp|comment|user|sha1&list=usercontribs&uclimit=max&"\
ucuser=Ivan_Shmakov >| "$(mktemp -- /tmp/mycontribs.XXXXX)"
$ sh -Ceuc 'for f ; do printf \\n%s\\n\\n "*** ${f##*/}" ;
< "$f" sed -e "s/><\\</>\\n</g;" ; done ; ' dummy.sh /tmp/mycontribs.YP3Mu

*** mycontribs.YP3Mu

HTTP/1.1 200 OK^M
date: Sun, 05 Nov 2023 08:27:55 GMT^M
....
<usercontribs>
<item userid="504787" user="Ivan Shmakov" pageid="136088160" revid="794224162"
parentid="793976029" ns="6" title="File:Chebyshev type I order 3 bandstop
filter 2023 228 1.gif" timestamp="2023-08-18T18:07:18Z" comment="Fixed markup,
as well as the {{CC0}} licensing template invocation." size="7529" />
<item userid="504787" user="Ivan Shmakov" pageid="136088475" revid="794220990"
parentid="793910161" ns="6" title="File:Chebyshev type I order 3 bandstop
filter 2023 228 2.gif" timestamp="2023-08-18T17:55:41Z" top="" comment="Fixed
markup." size="9295" />
....

> If I expect that a website has mostly text based content but
> requires javascript to read it, I assume that it's poorly designed
> and I need not bother.

+1. If a website requires Javascript (or flash, DRM, etc.),
I'm likely not its target audience anyway.

> The only real annoyance is not being able to read comments under
> youtube videos without javascript. On the vast majority of occasions
> I choose not to read the comments.

Invidious instances offer an option to read Youtube comments
without Javascript. Consider, e. g.:

http://yewtu.be/watch?v=fs0N2f9VHjI
http://yewtu.be/watch?v=fs0N2f9VHjI&nojs=1

Then again, while I have no doubt there's a wealth of useful
information in Youtube comments, I know of no easy procedure
for actually /finding/ it among all the noise; so most of the
time, I don't bother, either.

>> But of course cloudflare often breaks wget which is an issue.

> It also prevents access from w3m and you don't even get an
> informative message. But if I'm really interested in the content,
> it often is available through Google cache.

I'm using the Wayback Machine for that purpose. E. g.:

http://rfc-editor.org/rfc/rfc7489.txt -> cloudfailure,
http://web.archive.org/web/2023/http://rfc-editor.org/rfc/rfc7489.txt
-> readable version.

(Though in this specific case I actually prefer
rsync://ftp.rfc-editor.org/rfcs/ anyway.)

--
FSF associate member #7257 np. Somewhere Somehow by Broken Poets