Re: A suggest to LibreJS

[bill-auger]

AFAICT, wikipedia works perfectly with librejs; so i dont fully
understand the concern raised in this thread - i will do my best
to explain things as i understand them though

as best as i understand this proposal, it seems like it would be
a matter of "feature-creep" for librejs - the purpose of librejs
is to inhibit dynamic behaviors, which are normally beyond the
control of, and practically invisible to, the user - that is,
conditions such that the user has no opportunity to inspect or
replace the code, before running it, or to so much as witness
it's effects while running it blindly - librejs does not allow
the user to do any of those things either - librejs can only
inhibit code from running without prior consent; and nonetheless,
that consent is _always_ given blindly - that is because, every
time some web page is visited, the server may (and often does)
send different scripts than those previously inspected/approved
by the user

in contrast, "clickable" URLs on web pages are generally, static
properties of the HTML document (read: inert, harmless) - these
are a very different case; because although URLs also may be
different each time the page is visited, the user, before
deciding to click the link (intentionally), always has the
opportunity to inspect the URL which would be resolved - more
substantially though, is that unless the URL is a literal IP
address (most are not), the actual web-server to which any
domain name resolves, is fundamentally governed by a DNS
mechanism, as chosen by each user - that mechanism is entirely
orthogonal to librejs and the web browser - there are better
ways to manage that concern, such as the good ol' 'hosts' file

there may be some confusion regarding "direct" vs "re-direct"
URLs - the reason why youtube can be accessed generally by other
tools, is because youtube exposes a programmer's API; which are a
set of stable entry-points (essentially URLs) for heterogeneous
clients to access network resources, generically (ie: with or
without a web browser) - clients such as invidious use the
youtube API in a way, such that youtube can be accessed by web
browser clients, via a proxy web service; but that is only one
possible design choice - it is the least imaginative one
actually, and the least effective for the goal of achieving
software freedom - it is merely "passing the buck" as they say,
to another website, which itself serves javascript for librejs
to filter, in exactly the same way - it entails the same
degradation/preclusion of software freedom which is inherent in
any remote network service - such proxy web services offer no
more or less software freedom than the original web service does
- _unless_ one hosts one's _own_ instance, proxy services have
zero relevance to software freedom - that is true, irrespective
of the software license; because the user has zero software
freedom, while using it, and can never inspect _any_ of the
software which is _actually_ running on the remote server

an alternate design option, is direct clients such as totem and
minitube, which use the same API to access youtube from local
desktop applications - this is another important distinction to
make - those tools perform exactly the same tasks as a proxy
service does, except that nothing like librejs is needed;
because total transparency and control over the software is
inherent in them, by nature of the user having their own local
copy, necessarily

wikipedia's underlying software, mediawiki also exposes a
programmer's API - i believe that it is enabled on the
wikipedia,org instance; so the same variety of third-party
clients, which could be written for youtube, could be written
for wikipedia as well - i am not aware of any website software
which uses the mediawiki API to proxy access to wikipedia.org
data - presumably none exists, and presumably because there is
no demand for one - if the suggestion is to re-write URLs
"inline", to forcibly re-direct all matching URLs to some other
website, then in the case of wikipedia.org, there is no
alternative website serving the same data, toward which to
redirect as a "drop-in" replacement - that is why i am confused
by the wikipedia example, as justification for librejs to
blacklist entire domains, and forcefully redirect to another; but
again, perhaps i have mis-understood the proposal

network API are essentially URLs, which are designed to never
change - in general, there is no distinction from the user's
perspective - they are both nothing more than addresses of some
network resource - the main difference is that the API can
search/locate resources, without firstly fetching some other
resource (such as an HTML index page or external search engine) -
the distinction is irrelevant though, WRT web proxies such as
invidous; because the back-end service uses the API to locate
the resource, but the user still accesses the data, by firstly
downloading an HTML page - the only difference is from which
server the HTML page is downloaded

in either case of API vs directly-clickable URLs, neither are
executable software, and so do not themselves impose any
impedance to software freedom (the primary concern of librejs) -
librejs only needs to serve as a guard or warning, when one's
software freedom would otherwise have been restricted without it