disabling HSTS [LWN.net]

disabling HSTS

Posted Apr 19, 2017 2:31 UTC (Wed) by linuxrocks123 (subscriber, #34648)
In reply to: disabling HSTS by mjg59
Parent article: Tor exit node operator arrested in Russia (TorServers.net blog)

Yeah, I get that, and I think that's against the spirit of what our community is about. Saying "download the source code and make the change yourself" is fine when the project is trivial to compile, but I know from experience that getting Mozilla-based browsers to compile, while many things, is not a trivial exercise. A web browser that intentionally makes it so users can't visit certain websites effectively cripples their ability to visit those sites unless they have the technical expertise to compile a browser on their own or find someone else willing to step into the developer's shoes, create a custom build, and distribute it themselves. That isn't guaranteed, and Googling turns up several instances of poor souls trying to hack around with about:config and internal Firefox data files just to get their browser to visit the websites they want, mostly unsuccessfully. Those users are just stuck, so intentionally distributing crippled builds as the official builds is going way, way too far.

But, hey, I guess this will lead to more Pale Moon users, which would be a happy result. I'll even help by directing them to it in those help forums.

I still say shame on Firefox, though.

disabling HSTS

Posted Apr 19, 2017 3:29 UTC (Wed) by mjg59 (subscriber, #23239) [Link] (11 responses)

The website owner explicitly requested that browsers impose this policy. Doing so is entirely within the spirit of our community.

disabling HSTS

Posted Apr 19, 2017 6:36 UTC (Wed) by linuxrocks123 (subscriber, #34648) [Link] (10 responses)

I guess we should get some patches to ffmpeg, mplayer, vlc, and friends to abort with error when an input has the broadcast flag or CGMS-A on it then. After all, some random remote party involved in the content's creation or distribution is requesting those programs not to function when that data is present. By your logic, we should listen.

disabling HSTS

Posted Apr 19, 2017 6:48 UTC (Wed) by mjg59 (subscriber, #23239) [Link] (9 responses)

Like the patches to the kernel that cause wireless hardware to listen to the region provided by the access point and disable certain frequencies? Whatever decisions upstream makes, having the source means that you can make your own choices. That's the contract the community has, nothing more.

disabling HSTS

Posted Apr 19, 2017 22:37 UTC (Wed) by linuxrocks123 (subscriber, #34648) [Link] (8 responses)

I have mixed feelings even about cryptographically verifying CRDA uploads, but wireless frequency regulation is a unique situation.

"Directing the hardware to do something blatantly unethical and illegal" != "Directing a browser to visit a website that's misconfigured"

You didn't answer my question about patching media players.

disabling HSTS

Posted Apr 19, 2017 22:51 UTC (Wed) by mjg59 (subscriber, #23239) [Link] (7 responses)

The media player case isn't comparable - HSTS is about the site maintainer making a decision that gives them no benefit but is intended to improve the security of their user, while DRM is intended to benefit the rights holder while harming the user.

disabling HSTS

Posted Apr 20, 2017 2:59 UTC (Thu) by linuxrocks123 (subscriber, #34648) [Link]

Good point. I disagree that being motivated by paternalism rather than selfishness is an important distinction, but it is a distinction.

disabling HSTS

Posted Apr 21, 2017 19:15 UTC (Fri) by aggelos (subscriber, #41752) [Link] (5 responses)

> Whatever decisions upstream makes, having the source means that you can make your own choices.

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.

disabling HSTS

Posted Apr 22, 2017 4:16 UTC (Sat) by pabs (subscriber, #43278) [Link] (3 responses)

I think this topic would make a great LWN article.

disabling HSTS

Posted Apr 22, 2017 8:21 UTC (Sat) by aggelos (subscriber, #41752) [Link] (2 responses)

Can I go a bit meta? I'm not sure articles diverging from the open source orthodoxy are a great idea for LWN (but see below).

One characteristic of LWN is that, AFAIU, people look forward to reading it as part of their Thursday morning routine (or daily routine now), knowing that there's a minimal chance it'll get their pulse rate up. Perhaps I'm mistaken, but the editors seem to have settled (in practice; not saying they actually discussed this) on a "no original controversy" (akin to Wikipedia's "no original research") rule. There's something to be said for this (apparent) rule. While I'm sure position articles which are controversial for the current audience of LWN would drive hits (and links) up, it's not obvious to me that people would want to fund such a publishing venue. Linking to an article that people are not comfortable with is one thing, having LWN endorse it by (possibly paying for its) publication is quite another.

So while some of us would appreciate reading articles which challenge our world view on LWN, would we keep paying for it if it did that regularly and deliberately? Probably not. I have zero data on this (and would very much like to learn more about actual case or aggregate studies), but I suspect a smaller, slowly-growing, ideologically-homogeneous (more or less) reader base is better suited to a subscriber-based site than a larger, polarized (across any number of axes) one.

That said, I do think there's room for experimentation within the current subscription model without succumbing to trollumnism. Say, by considering views which are in opposition to the kernel's groupthink regarding abuse or critical of the LF (or actually, any views which our editors might be mildly uncomfortable with but think are relevant to LWN's audience). The way things are, I doubt outside contributors would feel comfortable approaching LWN with such articles. But every move towards diversity acts as positive feedback.

So while I can't claim it's a Great Idea for LWN to do that, it is for the LWN I want to subscribe to. It might even be a Good Idea when it comes to low-hanging fruit such as the topic of this subthread here :-)

disabling HSTS

Posted Apr 22, 2017 13:10 UTC (Sat) by anarcat (subscriber, #66354) [Link]

Can I go a bit meta? I'm not sure articles diverging from the open source orthodoxy are a great idea for LWN (but see below).

Sure, but then we're deep into off-topic territory, and you're making me want an article about journalism itself, even though I just started here. ;)

As a new contributor here, I understand what you are talking about, but I identify it more with my own nature than LWN itself: I assume certain topics are off the table, and just self censor, so far. I have yet to come across direct editorial interference in my work, in general. The only exception is one case where I have made a broad social statement that was for me a basic axiom ("large corporations are bad", more or less) but that for the general public may not be a given fact. Keeping that argument in place would have required an elaborate rationalization of the argument, which defeated its purpose: it was supposed to be an argument, not an axiom. :) The trick is that controversial topics are, by nature, harder to argue than well-established positions, which is why you are going to have trouble finding journalists argue those correctly.

Nevertheless, I am, generally, confident that I will be able to bring controversial topics here - and I believe I did a few times already. As a journalist, however, your duty is not to take sides but to reflect on a discussion or situation that is already happening between different parties. Sure, there are opinion pieces to be made, but even those, I feel, are stronger when they are backed by strong arguments. In that context, your comment is even more interesting because it brings nice sound bites I can quote in an article while keeping critical distance. ;)

And as pabs said, there's a "Write for us" button on the left column, try it out and be the media.

disabling HSTS

Posted Apr 24, 2017 17:53 UTC (Mon) by Wol (subscriber, #4433) [Link]

> Can I go a bit meta? I'm not sure articles diverging from the open source orthodoxy are a great idea for LWN (but see below).

I miss Groklaw. But that had aggressive moderation. There were some wonderful off-topic conversations there. PJ just had this simple rule - you could argue anything you liked so long as you had the facts/argument to back yourself up, and you weren't offensive.

(This did cause a few problems, when English and American disagreed as to what was offensive ...)

Cheers,
Wol

disabling HSTS

Posted Apr 22, 2017 13:23 UTC (Sat) by anarcat (subscriber, #66354) [Link]

Freedom is being able to make decisions that affect mainly you. Power is being able to make decisions that affect others more than you. If we confuse power with freedom, we will fail to uphold real freedom. -- Richard Stallman

This is an off-topic but interesting debate. As a person that just enables HSTS yet sometimes has trouble visiting sites because of SSL compatibility problems, I certainly understand the frustration. While it is true that developers can fix that issue on their own, by basically forking a major web browser, that is no small feat of engineering. That software is a really complex piece of machinery, probably one of the most complex standalone pieces of software ever built. What is being proposed is to fork this to remove a limitation a site's author wanted to be configured. I believe this is being a little dishonest: there's nothing simple or easy about doing that kind of stuff. Some people *may* be able to do so, most people can't and basically nobody will.

The underlying problem here is that we have two different freedoms in conflict - one is the freedom of the website author to keep its content private to only the people that visit the site, ensuring better security for its users but also protecting itself from the liability of certain attacks. The other is the freedom for some of *those* users to disable those protections. Should users be able to disable such policies on their own? Maybe.

But why? In this case, it was to workaround a configuration problem on the server, which disabled the service. Should web browsers be modified to work around configuration problems on the server? My answer to this is an emphatic: oh please please please no. I would understand if there would be a more reasonable use case here, but there are legitimate technical reasons behind HSTS. If a websites shoots itself in the foot and (say) starts running on port 80 instead of port 443 because of a typo, should a browser start guessing and fallback to do SSL on port 80? No! We have standards for this, and HSTS was establish to say "I know what I'm doing, disable the site if i fuckup my ssl config". That's what torservers.net said, then they fucked up, and the site went down. Don't go blaming the browser for limiting your freedom then. The server admins did that. And now it's fixed.

So maybe now we can move on to free Bogatov already. The point of this news was not to satisfy your pet peeve about some weird technological corner of the internet. A fellow Debian Developer is in jail for enabling journalists and researchers to do anonymous work on the internet. Help him.