When I started writing this blog, my intent was to post notices more
frequently and treat it more like a microblogging platform; but that's not
how it ended up. Instead, I use this site to write more detailed posts with
solid references to back up my statements.
[GNU Social](https://gnu.org/software/social/) is a federated social
network---you can host your own instances and they all communicate with
one-another. You can find mine at the top of this page under "Notices", or
at [https://social.mikegerwitz.com/](https://social.mikegerwitz.com/). I
will be using this site to post much more frequent miscellaneous notices.
It seems that Comcast has decided that it is a good idea to [inject
JavaScript into web pages][js] visited by its customers in order to inform
them of Copyright violations.
This is a huge violation of user privacy and trust. Further, it shows that
an ISP (and probably others) feel that they have the authority to dictate
what is served to the user on a free (as in speech) Internet. Why should we
believe that they won't start injecting other types of scripts that spy on
the user or introduce advertising? What if a malicious actor compromises
Comcast's servers and serves exploits to users?
It is no surprise that Comcast is capable of doing this---they know the IP
address of the customer, so they are able to intercept traffic and alter it
in transit. But the fact that they _can_ do this demonstrates something far
more important: _that they have spent the money on the infrastructure to do
so_!
Comcast isn't the only ISP to have betrayed users by injecting data. One
year ago, it was discovered that [Verizon was injecting "perma-cookies" into
requests to track users][verizon]. This is only one example of the
insidious abuses that unchecked ISPs can take.
So what can you do to protect yourself?
What Comcast is doing is called a [man-in-the-middle (MITM) attack][mitm]:
Comcast sits in the middle of you and your connection to the website that
you are visiting, proxying your request. Before relaying the website's
response to you, it modifies it.
In order to do this, Comcast needs to be able to read your communications,
and must be able to modify them: the request must be read in order to
determine how the JavaScript should be injected and what request it should
be injected into; and it must be modified to perform the injection. It
cannot (given a properly configured web server) do so if your connection is
encrypted. In the case of web traffic, `https` URLs with the little lock
icon in your web browser generally indicates that your communications are
encrypted, making MITM attacks
unlikely.
(We're assuming that Comcast won't ask you to install a root CA so that they
can decrypt your traffic! But that would certainly be noticed, if they did
so on a large enough scale.)
Not all websites use SSL. Another method is to use encrypted proxies, VPNs,
or services like like [Tor][tor]. This way, Comcast will not be able to
read or modify the communications.
See also: [HackerNews discussion][hn]; [original Reddit discussion][reddit].
[js]: https://gist.github.com/Jarred-Sumner/90362639f96807b8315b
[verizon]: https://www.eff.org/deeplinks/2014/11/verizon-x-uidh
[mitm]: https://en.wikipedia.org/wiki/Man-in-the-middle_attack
[hn]: https://news.ycombinator.com/item?id=10592775
[reddit]: https://www.reddit.com/r/HuntsvilleAlabama/comments/35v4sn/comcast_is_injecting_bad_javascript_to_your/
[tor]: https://tor.org/
*This article originally appeared as a guest post on the [GitLab
blog][orig-post].*
In early March of this year, it was announced that
[GitLab would acquire Gitorious][0] and shut down `gitorious.org` by 1
June, 2015. [Reactions from the community][1] were mixed, and
understandably so: while GitLab itself is a formidable alternative to wholly
proprietary services, its acquisition of Gitorious strikes a chord with the
free software community that gathered around Gitorious in the name of
[software freedom][2].
<!-- more -->
After hearing that announcement,
[as a free software hacker and activist myself][11], I was naturally
uneasy. Discussions of alternatives to Gitorious and GitLab ensued on the
[`libreplanet-discuss`][12] mailing list. Sytse Sijbrandij (GitLab
B.V. CEO) happened to be present on that list;
[I approached him very sternly][13] with a number of concerns, just as I
would with anyone that I feel does not understand certain aspects of the
[free software philosophy][2]. To my surprise, this was not the case at
all.
Sytse has spent a lot of time accepting and considering community input for
both the Gitorious acquisition and GitLab itself. He has also worked with
me to address some of the issues that I had raised. And while these issues
won't address everyone's concerns, they do strengthen GitLab's commitment to
[software freedom][2], and are commendable.
I wish to share some of these details here; but to do so, I first have to
provide some background to explain what the issues are, and why they are
important.
## Free Software Ideology
[Gitorious][3] was (and still is) one of the most popular Git repository
hosts, and largely dominated until the introduction of GitHub. But even as
users flocked to [GitHub's proprietary services][28], users who value freedom
continued to support Gitorious, both on `gitorious.org` and by installing
their own instances on their own servers. Since Gitorious is
[free software][2], users are free to study, modify, and share it with
others. But [software freedom does not apply to Services as a
Software Substitute (SaaSS)][4] or remote services---you cannot apply the
[four freedoms][2] to something that you do not yourself possess---so why do
users still insist on using `gitorious.org` despite this?
The matter boils down to supporting a philosophy: The
[GNU General Public License (GPL)][6] is a license that turns copyright on
its head: rather than using copyright to restrict what users can do with a
program, the GPL instead [ensures users' freedoms][8] to study, modify, and
share it. But that isn't itself enough: to ensure that the software always
remains free (as in freedom), the GPL ensures that all *derivatives* are
*also* licensed under similar terms. This is known as [copyleft][9], and it
is vital to the free software movement.
Gitorious is licensed under the
[GNU Affero General Public License Version 3 (AGPLv3)][5]---this takes the
[GPL][6] and adds an additional requirement: if a modified version of the
program is run on a sever, users communicating with the program on that
server must have access to the modified program's source code. This ensures
that [modifications to the program are available to all users][7]; they
would otherwise be hidden in private behind the server, with others unable
to incorporate, study, or share them. The AGPLv3 is an ideal license for
Gitorious, since most of its users will only ever interact with it over a
network.
GitLab is also free software: its [Expat license][10] (commonly referred to
ambiguously as the "MIT license") permits all of the same freedoms that
are granted under the the GNU GPL. But it does so in a way that is highly
permissive: it permits relicensing under *any* terms, free or not. In other
words, one can fork GitLab and derive a proprietary version from it, making
changes that deny users [their freedoms][2] and cannot be incorporated back
into the original work.
This is the issue that the free software community surrounding Gitorious has
a problem with: any changes contributed to GitLab could in turn benefit a
proprietary derivative. This situation isn't unique to GitLab: it applies
to all non-copyleft ("permissive") [free software licenses][26]. And this
issue is realized by GitLab itself in the form of its GitLab Enterprise
Edition (GitLab EE): a proprietary derivative that adds additional
features atop of GitLab's free Community Edition (CE). For this reason,
many free software advocates are uncomfortable contributing to GitLab, and
feel that they should instead support other projects; this, in turn, means
not supporting GitLab by using and drawing attention to their hosting
services.
The copyleft vs. permissive licensing debate is one of the free software
movement's most heated. I do not wish to get into such a debate here. One
thing is clear: GitLab Community Edition (GitLab CE) is free
software. Richard Stallman (RMS) [responded directly to the thread on
`libreplanet-discuss`][20], stating plainly:
> We have a simple way of looking at these two versions. The free
> version is free software, so it is ethical. The nonfree version is
> nonfree software, so it is not ethical.
Does GitLab CE deserve attention from the free software community? I
believe so. Importantly, there is another strong consideration: displacing
proprietary services like GitHub and Bitbucket, which host a large number of
projects and users. GitLab has a strong foothold, which is an excellent
place for a free software project to be in.
If we are to work together as a community, we need to respect GitLab's
free licensing choices just as we expect GitLab to respect ours. Providing
respect does not mean that you are conceding: I will never personally use a
non-copyleft license for my software; I'm firmly rooted in my dedication to
the [free software philosophy][2], and I'm sure that many other readers are
too. But using a non-copyleft license, although many of us consider it to
be a weaker alternative, [is not wrong][23].
## Free JavaScript
As I mentioned above,
[software freedom and network services are separate issues][4]---the four
freedoms do not apply to interacting with `gitlab.com` purely over a network
connection, for example, because you are not running its software on your
computer. However, there is an overlap: JavaScript code downloaded to be
executed in your web browser.
[Non-free JavaScript][15] is a particularly nasty concern: it is software
that is downloaded automatically from a server---often without prompting
you---and then immediately executed. Software is now being executed on your
machine, and [your four freedoms][2] are once again at risk. This, then,
[is the primary concern][16] for any users visiting `gitlab.com`: not only
would this affect users that use `gitlab.com` as a host, but it would also
affect *any user that visits* the website. That would be a problem, since
hosting your project there would be inviting users to run proprietary
JavaScript.
As I was considering migrating my projects to GitLab, this was the
[first concern I brought up to Sytse][14]. This problem arises because
`gitlab.com` uses a GitLab EE instance: if it had used only its Community
Edition (GitLab CE)---which is free software---then all served JavaScript
would have been free. But any scripts served by GitLab EE that are not
identical to those served by GitLab CE are proprietary, and therefore
unethical. This same concern applies to GitHub, Bitbucket, and other
proprietary hosts that serve JavaScript.
Sytse surprised me by stating that he would be willing to
[freely license all JavaScript in GitLab EE][17], and by offering to give
anyone access to the GitLab EE source code who wants to help out. I took
him up on that offer. Initially, I had submitted a patch to merge all
GitLab EE JavaScript into GitLab CE, but Sytse came up with another,
superior suggestion, that ultimately provided even greater reach.
**I'm pleased to announce that Sytse and I were able to agree on a license
change (with absolutely no friction or hesitation on his part) that
liberates all JavaScript served to the client from GitLab EE instances.**
There are two concerns that I had wanted to address: JavaScript code
directly written for the client, and any code that produced JavaScript as
output. In the former case, this includes JavaScript derived from other
sources: for example, GitLab uses CoffeeScript, which compiles *into*
JavaScript. The latter case is important: if there is any code that
generates fragments of JavaScript---e.g. dynamically at runtime---then that
code must also be free, or users would not be able to modify and share the
resulting JavaScript that is actually being run on the client. Sytse
accepted my change verbatim, while adding his own sentence after mine to
disambiguate. At the time of writing this post, GitLab EE's source code
isn't yet publicly visible, so here is the relevant snippet from its
`LICENSE` file:
> The above copyright notices applies only to the part of this Software that
> is not distributed as part of GitLab Community Edition (CE), and that is
> not a file that produces client-side JavaScript, in whole or in part. Any
> part of this Software distributed as part of GitLab CE or that is a file
> that produces client-side JavaScript, in whole or in part, is copyrighted
> under the MIT Expat license.
## Further Discussion
My discussions with Sytse did not end there: there are other topics that
have not been able to be addressed before my writing of this post that would
do well to demonstrate commitment toward [software freedom][2].
The license change liberating client-side JavaScript was an excellent
move. To expand upon it, I wish to submit a patch that would make GitLab
[LibreJS compliant][21]; this provides even greater guarantees, since it
would allow for users to continue to block other non-free JavaScript that
may be served by the GitLab instance, but not produced by it. For example:
a website/host that uses GitLab may embed proprietary JavaScript, or modify
it without releasing the source code. Another common issue is the user of
analytics software; `gitlab.com` uses Google Analytics.
If you would like to help with LibreJS compliance, please [contact me][11].
I was brought into another discussion between Sytse and RMS that is
unrelated to the GitLab software itself, but still a positive demonstration
of a commitment to [software freedom][2]---the replacement of Disqus on the
`gitlab.com` blog with a free alternative. Sytse ended up making a
suggestion, saying he'd be "happy to switch to" [Juvia][22] if I'd help with
the migration. I'm looking forward to this, as it is an important
discussion area (that I honestly didn't know existed until Sytse told me
about it, because I don't permit proprietary JavaScript!). He was even kind
enough to compile a PDF of comments for one of our discussions, since he was
cognizant ahead of time that I would not want to use Disqus. (Indeed, I
will be unable to read and participate in the comments to this guest post
unless I take the time to freely read and reply without running Disqus'
proprietary JavaScript.)
Considering the genuine interest and concern expressed by Sytse in working
with myself and the free software community, I can only expect that GitLab
will continue to accept and apply community input.
It is not possible to address the copyleft issue without a change in
license, which GitLab is not interested in doing. So the best way to
re-assure the community is through action. [To quote Sytse][18]:
> I think the only way to prove we're serious about open source is in our
> actions, licenses or statements don't help.
There are fundamental disagreements that will not be able to be
resolved between GitLab and the free software community---like their
["open core" business model][19]. But after working with Sytse and seeing
his interactions with myself, RMS, and many others in the free software
community, I find his actions to be very encouraging.
*Are you interested in helping other websites liberate their JavaScript?
Consider [joining the FSF's campaign][27], and
[please liberate your own][16]!*
*This post is licensed under the
[Creative Commons Attribution-ShareAlike 3.0 Unported License][25].*
[0]: https://about.gitlab.com/2015/03/03/gitlab-acquires-gitorious/
[1]: https://news.ycombinator.com/item?id=9138419
[2]: https://www.gnu.org/philosophy/free-sw.html
[3]: https://gitorious.org/
[4]: https://www.gnu.org/philosophy/who-does-that-server-really-serve.html
[5]: https://www.gnu.org/licenses/agpl.html
[6]: https://www.gnu.org/licenses/gpl.html
[7]: https://www.gnu.org/licenses/why-affero-gpl.html
[8]: https://www.gnu.org/licenses/quick-guide-gplv3.html
[9]: https://www.gnu.org/philosophy/pragmatic.html
[10]: https://www.gnu.org/licenses/license-list.html#Expat
[11]: http://mikegerwitz.com/
[12]: https://lists.gnu.org/mailman/listinfo/libreplanet-discuss
[13]: https://lists.gnu.org/archive/html/libreplanet-discuss/2015-03/msg00075.html
[14]: https://lists.gnu.org/archive/html/libreplanet-discuss/2015-04/msg00019.html
[15]: https://www.gnu.org/philosophy/javascript-trap.html
[16]: https://www.gnu.org/software/easejs/whyfreejs.html
[17]: https://lists.gnu.org/archive/html/libreplanet-discuss/2015-04/msg00020.html
[18]: https://news.ycombinator.com/item?id=9141801
[19]: https://lists.gnu.org/archive/html/libreplanet-discuss/2015-03/msg00076.html
[20]: https://lists.gnu.org/archive/html/libreplanet-discuss/2015-03/msg00095.html
[21]: https://www.gnu.org/software/librejs/free-your-javascript.html
[22]: https://github.com/phusion/juvia
[23]: https://www.fsf.org/blogs/rms/selling-exceptions
[24]: https://gnu.org/software/easejs
[25]: http://creativecommons.org/licenses/by-sa/3.0/
[26]: https://www.gnu.org/licenses/license-list.html
[27]: https://fsf.org/campaigns/freejs
[28]: http://mikegerwitz.com/about/githubbub
[orig-post]: https://about.gitlab.com/2015/05/20/gitlab-gitorious-free-software/
"Begging the question" and "raising the question" mean different things. This patch fixes an instance where it is misused.
See: http://begthequestion.info/
There are many great presentations out there---many that I enjoy
reading, or that I would enjoy to read. Unfortunately, many of them
are hosted on SlideShare, which requires me to download proprietary
JavaScript.
[JavaScript programs require the same freedoms as any other
software][0]. While SlideShare does (sometimes/always?) provide a
transcript in plain text---which is viewable without JavaScript---this
is void of the important and sometimes semantic formatting/images that
presenters put much time into; you know: the actual presentation bits.
(I'm a fan of plain-text presentations, but they each have their own
design elements).
There are ways around this. SlideShare's interactive UI appears to
simply be an image viewer, so it is possible to display all sides
using a fairly simple hack:
```javascript
Array.prototype.slice.call(
document.getElementsByClassName( 'slide' ) )
.forEach( function( slide ) {
slide.classList.add( 'show' );
var img = slide.getElementsByClassName( 'slide_image' )[0];
img.src = img.dataset.full;
} );
```
This will display all slides inline. But there's a clear problem with
this: how is the non-JS-programmer supposed to know that? Even
JavaScript programmers have to research the issue in order to come up
with a solution.
But ideally, I'd like to download the presentation PDF. SlideShare
does offer a download link, but not only does it not work with
JavaScript disabled, but it requires that the user create an account.
This is no good, as it can be used to track users or discover
identities by analyzing viewing habits. This would allow
de-anonymizing users, even if they have [taken measures to remain
anonymous][1].
(By the way: at the time that I wrote this post, the [EFF's
Surveillance Self-Defense Guide][1] is [LibreJS compatible][2] and the
JavaScript code that it runs is mostly free.)
I encourage presenters (and authors in general) to release the slides
in an [unencumbered document format][3], like PDF, HTML, OpenDocument,
or plain text. Those formats should be hosted on their own website,
or websites that allow downloading those files without having to
execute proprietary JavaScript, and without having to log in. If
those authors *must* use SlideShare for whatever reason, then they
should clearly provide a link to that free document format somewhere
that users can access without having to execute SlideShare's
proprietary JavaScript, such as on the first slide. (The description
is iffy, since it is truncated and requires JavaScript to expand.)
[0]: https://www.gnu.org/software/easejs/whyfreejs.html
[1]: https://ssd.eff.org/
[2]: https://www.gnu.org/software/librejs/
[3]: http://www.fsf.org/campaigns/opendocument/reject
Two days ago, the Free Software Foundation published [an announcement
strongly condemning Mozilla's partnership with Adobe][0] to implement the
[controversial W3C Encrypted Media Extensions (EME) API][1]. EME has been
strongly criticized by a number of organizations, including the [EFF][2] and
the [FSF's DefectiveByDesign campaign team][3] (``Hollyweb'').
[Digital Restrictions Management][4] imposes artificial restrictions on
users, telling them what they can and cannot do; it is a system [that does
not make sense][5] and is harmful to society. Now, just about [a week after
the International Day Against DRM][6], Mozilla decides to [cave into the
pressure in an attempt to stay relevant][7] to modern web users, instead of
sticking to their [core philosophy about ``openness, innovation, and
opportunity''][8].
John Sullivan requested in the [FSF's announcement] that the community
contact Mozilla CTO Andreas Gal in opposition of the decision. This is my
message to him:
Date: Wed, 14 May 2014 22:57:02 -0400
From: Mike Gerwitz <mikegerwitz@gnu.org>
To: agal@mozilla.com
Subject: Firefox EME
Andreas,
I am writing to you as a free software hacker, activist, and user; notably,
I have been using Firefox for over ten years. It has been pivotal, as I do
not need to tell you, in creating a free (as in freedom), standard, and
accessible internet for millions of users. Imagine my bewildered
disappointment, then, to learn that Firefox has chosen to cave into the
pressure to [support Digital Restrictions Management through the
implementation of EME][0].
Mitchell Baker made a feeble attempt at [rationalizing this decision][0] as
follows:
[...] Mozilla alone cannot change the industry on DRM at this point. In
the past Firefox has changed the industry, and we intend to do so again.
Today, however, we cannot cause the change we want regarding DRM. The
other major browser vendors =E2=80=94 Google, Microsoft and Apple =E2=80=
=94 have already
implemented the new system. In addition, the old system will be retired
shortly. As a result, the new implementation of DRM will soon become the
only way browsers can provide access to DRM-controlled content.
She goes on to explain how ``video is an important aspect of online life''
and that Firefox would be ``deeply flawed as a consumer product'' if it did
not implement Digital Restrictions Management. This is precisely the FUD
that the ``content owners'' she describes, and corporations like Adobe, have
been pushing: Mozilla understands that the solution is not to implement DRM,
but to fight to encourage content to be published *without* being
DRM-encumbered. Unfortunately, they will now have little motivation to do
so, with every major browser endorsing EME.
She defers to a post by Andreas Gal [for more implementation details][1], in
which he mentions that the proprietary CDM virus (which will be happily
provided by Adobe) will be protected by a sandbox to prevent certain spying
activities like fingerprinting. While this is better than nothing, it's a
clear attempt by Mozilla to help make a terrible situation a little bit
better.
He goes on to say:
There is also a silver lining to the W3C EME specification becoming
ubiquitous. With direct support for DRM we are eliminating a major use
case of plugins on the Web, and in the near future this should allow us to
retire plugins altogether.=20
Let us not try to veil the problem and make things look more rosy than they
actually are: this is not a silver lining; it is not appropriate to have a
standardized way of manipulating and taking advantage of users.
It is true that Firefox was in an unfortunate position: many users would
indeed grow frustrated that they cannot watch their favorite TV shows and
movies using Firefox. But Firefox could have served, when the EME API was
used, static content that provided a brief explanation and a link for more
information on the problem. They could have educated users and encourage an
even stronger outcry.
Instead, we are working with the corrupt W3C to implement a seamlessly
shackled web. Mozilla wants to propose alternative solutions to DRM/EME, but
by implementing it, their position is weakened.
This is a difficult and uncomfortable step for us given our vision of a
completely open Web, but it also gives us the opportunity to actually
shape the DRM space and be an advocate for our users and their rights in
this debate. [1]
Such advocacy has been done and can continue to be done by Mozilla without
the implementation of EME; once implemented, the standard will be virtually
solidified---what is the incentive for W3C et. al. to find alternatives to a
system that is already "better than" the existing Flash and Silverlight
situation?
On behalf of the free software community, I strongly encourage your
reconsideration on the matter. Mozilla is valued by the free software
community for its attention to freedoms. Stand with us and fight. You're in
a powerful position to do so.
[0]: https://blog.mozilla.org/blog/2014/05/14/drm-and-the-challenge-of-serv=
ing-users/
[1]: https://hacks.mozilla.org/2014/05/reconciling-mozillas-mission-and-w3c=
-eme/
The following day, I [submitted the FSF announcement to HackerNews][9]
(surprised that it was not there already) in an attempt to bring further
coverage to the matter and hopefully spur on some discussion. And discuss
they did: it was on the front page for the entire day and, at the time of
writing, boasts 261 comments, many of them confused and angry. I sent the HN
link to Andreas in a follow-up as well.
Mozilla has a vast userbase and is in the position to fight for a DRM-free
web. Please voice your opinion and hope that they reverse their decision.
[0] http://www.fsf.org/news/fsf-condemns-partnership-between-mozilla-and-adobe-to-support-digital-restrictions-management
[1] https://dvcs.w3.org/hg/html-media/raw-file/tip/encrypted-media/encrypted-media.html
[2] https://www.eff.org/deeplinks/2013/03/defend-open-web-keep-drm-out-w3c-standards
[3] [cref:576d89ab953535be8f9cb08aa02a2ad630957811]
[4] http://www.defectivebydesign.org/what_is_drm_digital_restrictions_management
[5] https://plus.google.com/+IanHickson/posts/iPmatxBYuj2
[6] http://www.defectivebydesign.org/dayagainstdrm
[7] https://blog.mozilla.org/blog/2014/05/14/drm-and-the-challenge-of-serving-users/
[8] http://www.mozilla.org/en-US/about/manifesto/
[9] https://news.ycombinator.com/item?id=7749108
Mike Gerwitz
Mike Gerwitz