Re: [directory-discuss] s/w that requires a middleman to liberate it -- is it free?

[Anonymous]

Adonay Felipe Nogueira said:

> I'll answer to some argumentations made at:
> [[http://lists.gnu.org/archive/html/directory-discuss/2017-01/msg00066.html]]
> 
> First we must understand what is the goal of free/libre software
> movement, although there is no need to tell each part of the
> definition again. So, briefely, the free/libre software movement is
> concerned with *software freedom* (or to put more specifically,
> functional data freedom), in other words: What does the user
> receives as rights when he receives the functional data in question?
> (be it software, documentation, text fonts, and some other
> things). This can be seen in the Free Software Definition:
> [[http://www.gnu.org/philosophy/free-sw.html]].

FSF-recognized software freedoms indeed have an important role in the
discussion.  But you do not get a trademark on "software freedom", and
you may not hijack the general concept thereof.  It's an injustice to
take one organization's narrow mission and impose its limited scope on
others working in the free software movement.

Despite the FSF being the single most significant contributor to the
free software movement, it is not the only organism in the movement.
The "Ada Initiative", for example, is focused on an aspect of the
software freedom movement that is largely outside the scope of the FSF
agenda.  There are also tens of other software freedom organizations
with mostly aligned but different goals, all of whome compose a part
of the software freedom movement.

I only say that for academic correctness, while my comment above is
only relevent to the extent that yours is.  Which is only relevant in
terms of finding a solution, not exposing a problem (explained below).

> The section "/Freedom denied/" of the message I referenced earlier does
> not correspond to what is defined in the Free Software Definition, not
> even the reference to involuntary servitude, I'll keep the list
> hierarchy while answering to each list item:

Suppose you have a toy gun maker "Smith & Wesson Toys, Inc." whose
product is putting many kids eyes out, because the projectiles are
small enough and leave the barrel with enough force to destroy a human
eye.  A spokesperson for Smith & Wesson Toys, Inc. might try to argue:
"we do not make safety products and safety is not in the mission
statement or the constitution of our company - we therefore take no
responsibility for this".  I don't have to give a rat's ass about that
mission statement for the atrocity to be actionable.  Smith & Wesson
Toys, Inc. would be accountable not for going against a mission
statement, contract, or license, but rather quite simply for
contributing to bodily harm.

The section /Freedom denied/ is a problem statement.  It's a bug
report that *describes a disaster*.  It would be an act of
incompetence to reduce the problem report to just FSF-recognized
matters.  The whole disaster is on the table, and activity of finding
a remedy is separate from the problem description.

There is a perpetrator, an atrocity, and there are victims.  The GNU
Radio Foundation, Inc. is a perpetrator and therefore in that capacity
responsible for the disaster whether they care or not (i.e. whether or
not their particular software freedom goals recognize the problem).

FSF is also potentially responsible, and not just because some
freedoms are attacked that are within the scope of the FSF mission.
That is, if FSF supports (and has control over) the GNU Radio project,
it would then be part of the cause and thus be responsible for all the
freedoms denied, not just the ones in the scope of their mission.  If
FSF has no control over GNU Radio, then it's interesting to talk about
which elements of the disaster FSF can act on based on FSF-recognized
freedoms.  And yes, some of the trampled freedoms derive from "freedom
0", and some are legally actionable due to GFDL violations.

> 1. This item does not relate to free/libre software movement, it
>    relates to privacy advocates, not free/libre software
>    advocates. Although we do agree that privacy is impossible
>    without free/libre software, privacy isn't a requirement.

This is a false dilemma fallacy.  A freedom can be both a software
freedom and a privacy freedom at the same time.  An attack on software
freedom doesn't cease to be an attack on software freedom simply
because there co-exists an attack on privacy.

This fallacy often presents quite similarly in information security
discussions.  Someone brings up the privacy aspect of some infosec
situation, and someone else says "that's a privacy matter, not a
security matter" (when in fact privacy *is* security).  They've
unwittingly used a false dilemma, as you just have.

Another problem with your claim: privacy loss is part of the damage
report, which need not become a cause for a particular action by a
particular organization.

>    Also, I cannot reproduce this, since I'm not affected by the
>    issue, but I have talked with some experts on Tor usage, and it
>    seems that both parties (Tor and CloudFlare) are tied in regards
>    to who is the responsible for the mess. Tor has part on this
>    because every node has to communicate with the target address in
>    order to stablish a connection to the requesting node, and

Your information came from CloudFlare-biased "experts".  It's a poor
use of language (overgeneralization) to say "Tor has part on this", as
if to imply that Tor project has in some way *contributed* to the
attack.  The Tor network is *impacted* by the mess and has "a part on
this" in the same way a rape victim "has a part" in a rape attack.
Victim blame is a really bad idea.  CloudFlare is the perpretrator
conducting a denial of service attack and does not share
responsibility for "the mess" with the Tor project.

>From a problem solution viewpoint, perhaps you would (perversely) tell
a rape victim: dress differently.  It's technologically infeasible for
the Tor network to operate without exit nodes, or to establish a
mechanism that prevents attacks without compromising security.
(Indeed CloudFlare expected Tor to compromise anonymity to protect
CloudFlare's bottom line)

CloudFlare naïvely relies on a clumsy IP reputation-dependant
approach, in the same crude manner that SpamHaus does for email, with
total disregard for collateral damage to legitimate traffic in its
overzealous vigilanti means of profit.

CloudFlare's competitors are more intelligent.  They use finess.  They
deploy sophisticated algorithms that can separate attack traffic from
legit traffic without an unreasonablly high dependency on IP
reputation data.  I say "intelligent", but from a business standpoint
CloudFlare believes (perhaps correctly) that they can profit more by
not investing in smart algorithms and the extra computing power to
execute them, knowing that consumers are mostly push-overs, too
ambivilous to fight the bully or too naïve to be aware.

>    CloudFlare has part on this because their security measures
>    understand that moultiple connections happenning at the same time
>    are possibly denial of service attacks.

Would your "expert" be Ian Kelling by any chance?  It's clear from
this comment that your "expert" has mislead you the same way IK
mislead RMS.  CloudFlare's attack on Tor is unilateral, and this is
evident from the Tor bug reports (one in particular shows a long
discussion between cloudflare and tor devs).  Even if there is only
*1* connection from a Tor exit node, that user is still blocked simply
because the exit node is known to CF as a Tor node.

It's very easy to prove in a couple different ways.  Take two separate
machines on the same LAN, without Tor, and point them to gnuradio.org.
They will not get blocked despite sharing the same IP.  It's also
interesting to point a Tor-connected host to a hole-in-the-wall
CloudFlared site that's unlikely to have any traffic at all, and
notice that the block instantly occurs.  You can also ensure you have
no other traffic if you run the site yourself.

> 2. Now, as a *personal* suggestion, perhaps you can use GNU  to
>    download the page where the CAPTCHA is, and try to find ways to make
>    character recognition work on the CAPTCHA image everytime it changes,
>    or to solve it in some other way. Once you have a minimal testing way
>    to do so, use  with both the  and
>     options to save the cookies
>    for the session when CloudFlare asks for the CAPTCHA challenge, this
>    will provide you with a cookie called "cfduid" which I think holds
>    the session responsible for the CAPTCHA challenge. Then use 
>    with the , now with your
>    testing exampled, to try to bypass it.

There are many problems with your suggestion, both technological and
philosophical.

  * CAPTCHA automation: Don't be rediculous.  CAPTCHAs are designed to
    be impractical for a machine to solve.  Some projects are devoted
    solely to making headway on some CAPTCHAs, but not the variety of
    CAPTCHAs CloudFlare DoS attacks users with.  Apart from the
    irrelevancy of the CAPTCHA you describe, also note that the
    ImageMagick library would be an ideal tool for the CAPTCHA variety
    you describe, but the support team for ImageMagick refuses to
    support this humanitarian effort due to their overly simplistic
    and naïve sense of ethics, thus adding to the impracticality.

  * manual CAPTCHA solving: You're focused on cookies, but that's not
    the problem.  Wget encounters "ERROR 403: Forbidden" w/no
    possibility of an initial HTTPGET.  Even if a different tool is
    used for the initial get (which btw already violates the principle
    of using the tool how I want), wget encounters "ERROR 400: Bad
    Request." when attempting to retrieve the CAPTCHA frame.  Beyond
    that, it's unclear to me if it would even be legal to hack this
    further, but nor would it interest me to bend over backwards to
    help CloudFlare violate my privacy and work contrary to my own
    interests.  Such an effort is perhaps interesting for you, if
    you're actually determined to be able to claim use of wget is
    possible.  So far it's shown to be unworkable.  You're welcome to
    post a script if you intend to prove that wget works.

> "Google Docs shows how complex the evaluation of a single service
> can become. It invites people to edit a document by running a large
> nonfree JavaScript program, clearly wrong. However, it offers an API
> for uploading and downloading documents in standard formats. A free
> software editor can do so through this API.  This usage scenario is
> not SaaSS, because it uses Google Docs as a mere repository.

You're not seeing the forest for the trees.  Dr. Stallman's SaaSS
article is not a license or contract, or some legally-binding text for
which you can hunt for loopholes and technicalities to exploit to win
an argument.  It's a creative philosophical work that predates the
full-blown intensity of CloudFlare's attack on humanity and freedom
with hooks that eventually grew into software projects ultimately
damaging documentation freedom.  The article was in fact written for
software, not documentation.  It's beautiful, and simultaneously
flawed (naturally in part because it could not have predicted todays
abuses in the future w.r.t. composition time).

I don't give a shit about applicability-limiting ideas of that paper.
I'll be the judge of where I find it useful to apply these concepts.
To some extent "software" needs to be mentally replaced with "all
software artifacts including documentation", which I did in my
carefully-worded citation of that article.

The article generally explains why it's a terrible idea to put a layer
of proprietary, controlling, freedom-restricting and freedom-abusing
bullshit between the user and the artifact.  Such an act *takes away
your freedom*.

For you to dig through the philosophy text looking for some academic
clause or definition to sidestep the applicability (and ultimately
responsibility) to circumvent the pursuit of freedom, what's the
point?  You're (hopefully) only fooling yourself.

Consider this bit:

  "we are now offered another tempting way to cede control over our
   computing: Service as a Software Substitute (SaaSS). For our
   freedom's sake, we have to reject that too."

He only means to talk about software and only to the extent that it
gets the SaaSS label.  But try to use your head and think for yourself
instead of making yourself a mindless vessel for indoctrination.  GNU
Radio Foundation, Inc. together with CloudFlare, Inc. forces users to
"cede control" over their computing.  They dictate what tools you can
use, what information you must surrender to them and what manual labor
you must do just to obtain a copy of the documentation.  If you give a
shit about user freedom, you must reject this attack on freedom.

> Showing all your data to a company is bad, but that is a matter of
> privacy, not SaaSS; depending on a service for access to your data
> is bad, but that is a matter of risk, not SaaSS. On the other hand,
> using the service for converting document formats is SaaSS, because
> it's something you could have done by running a suitable program
> (free, one hopes) in your own computer [...]

It doesn't make the slightest difference whether you want to call the
abuse "an SaaSS issue".  That labelling is only relevant for RMS to
prescribe actions generally.  I can think for myself.  GNU Radio
Foundation, Inc. is behind freedom abuses comparable to that of SaaSS
projects, and I don't accept it.  It's philosophy not law.

Since you like to focus on technical nit-picking, I suggest avoiding
the philosophical branch of this discussion and move your focus to the
GFDL non-compliance that I've pointed out.

> Publishing via someone else's repository does not raise privacy
> issues, but publishing through Google Docs has a special problem: it
> is impossible even to view the text of a Google Docs document in a
> browser without running the nonfree JavaScript code. Thus, you
> should not use Google Docs to publish anything—but the reason is not
> a matter of SaaSS."
> 
> With this citation, if we take the first paragraph, we can see that
> it's not a real matter of SaaSS.

This is another false dilemma.  Just because some rule, guideline, or
ideology outside the SaaSS paper was violated doesn't mean a service
doesn't also trounce on SaaSS principles at the same time.

If for example you had to run non-free js to edit or search in the GNU
Radio wiki, and there existed no free-software tools that could
accommodate these use-cases offline, it would simultaneously be an
RMS-defined SaaSS matter and also lack freedoms 0-3.  Not that it
matters, because as I've said I don't have to accept the applicability
limits of the SaaSS paper to find the philosphy useful for exposing
problematic projects.

> However, if we consider the second paragraph, then your concerns
> *are indeed* founded, *but only* based on the argumentation that
> CloudFlare forces people to use non-free software (through
> JavaScript), not in the privacy argumentation (because privacy isn't
> a requirement for the free/libre software movement).

The privacy loss is part of the damages done by GNU Radio Foundation,
Inc., not in itself the cause for FSF actions.  But what's not clear
is why you're focused on freedom attacks you believe don't apply, and
yet you've ignored compeletely the freedom attacks that trace to
freedom 0.

> On putting a web interface between and the deliverable artifacts as a
> recipe for disaster with regards to user freedom: Not every web
> interface is bad,

There's no need to introduce ambiguity in an effort to cloud the
discussion.  We're talking specifically about one particular web
interface, the GNU Radio one, which is notably evil.

> the problem is with non-free software written in JavaScript, but not
> all JavaScript programs are bad, only the non-free ones are.

That's a different problem, not actually relevent to any of my
points.  None of my claims depend on any non-free js being deployed by
GNU Radio.  This is merely a distraction as far as I can tell.

> Also, regarding including the documentation with the software also: As
> was pointed out by Ineieve in
> [[http://lists.gnu.org/archive/html/directory-discuss/2017-01/msg00075.html]],
> the source files do include documentation and when the user receives
> both, he can see that the documentation is free/libre.

You missed my reply (probably because I screwed up the threading):

  http://lists.gnu.org/archive/html/directory-discuss/2017-01/msg00076.html

I've also already pointed out in other posts documentation that is
missing from that file.

--
Please note this was sent anonymously, so my address will be unusable.
List archives will be monitored.