disabling HSTS

Does it? Life is short. Even those of us who can code, probably want to
spend what (little) time remains outside work and (other?) social obligations
for personal fulfillment and gratification. Even when driven by larger concerns
(e.g. helping produce a healthy body of free software), one's time is arguably
better spent on what they enjoy doing, as that normally leads to more work, of
higher quality. Unless there's a critical mass of developers who would maintain
a minimal fork, carrying local modifications and eternally playing catch-up
with upstream is a losing game. That is without taking into account
considerations about ease of deployment and the implausibility of always having
time and motivation to spend on merging with upstream, rebuilding, etc
when some vital fix comes along (time which would normally be spent by your
friendly package maintainer).

For people who are more removed from programming as a daily practice, that is
even less of an option. Paying someone to maintain local changes forever and
learning what I'm sure seems like a very technical procedure for having your
own copy of a popular program is something few people would be prepared to do
(perhaps rightly so).

To a large degree this is unavoidable. Those who do the work get to decide on
the direction and even the minor implementation choices. Let's not pretend
there's an option though. This 'option' is only a theoretical possibility for
professional developers. Consider: every developer probably has 100-odd things
they'd like to be different in the programs they regularly use, yet they have
investigated, coded up and pushed for the inclusion of a patch for, like, five
of those? Closer to two?

Which brings me to the actual point.

> That's the contract the community has, nothing more.

Programs are large and complicated. The legal possibility of maintaining your
own fork is meaningless as a solution. What can and does work is listening to
people and taking their needs into consideration. Yes, the weighing of
conflicting needs is usually done by the developers or their employers, which
tends to bias the process in various ways[0]. This is inescapable. There
is a fundamental assymetry between the role of user and developer. It is
hardly news that the legal status of a piece of free software primarily
empowers developers and entities (or people) with large financial resources.
When it comes to users though, their agency is only preserved in their
interaction with the developers of the software they use. That is, in the
structure and decision-making processes we build around our projects. The
license is not enough.

This then is my point. The choice to not allow the user of the browser to
bypass the certificate check in the presence of HSTS is one that throws user
agency out the window. It is a choice some of us would have made too, and
could easily justify it in terms of second-order effects that are beneficial
for the users. This does not change the fact that the software is working
against the will of the user and is rubbing this in the user's face (that is in
contrast with most UIs which direct the user by omission).

It is in one word, disempowering. And this matters because putting
machinery under the control of its users is what free software is about. It is
about control. That control is rightly limited to make for a more useful system
(e.g. access checks, proper implementation of a network protocol etc). Yet
those serve to *enable* the user to communicate. Whereas examples such as
obeying CRDA and refusing to accept a certificate work in the opposite
direction. There is a good argument to be made that this is justified because
of the second order effects. All well and good.

But the argument (IIUIC) that "you have the source and the right to modify it
and distribute modifications, so user agency is preserved" does not, in
general, hold water. One can easily think of instances where
user-disempowering choices have been less than justified. If users do not
feel in control of their own system when using free software, then its value
compared to proprietary software is diminished. And that, i.e. less user
adoption and investment, has its own second-order effects too.

Geez this came out long.

[0] E.g. daunting and chaotic configurability or indifference to user issues,
to take two cliched cases.