Purism, GitLab, and Malicious Web Design

General
1

Most people here are probably aware that it is a good idea to have javascripts disabled in the browser by default, selectively allowing javascripts by trusted entities on trusted web sites when necessary. Similar to cookies, javascripts are usually only necessary when signing into an account on a web site. By disabling javascripts, web sites load much quicker and are generally more enjoyable in their static state. Disabling javascripts also has the benefit of protecting privacy by blocking ads, trackers, and most fingerprinting.

Most of us have likely encountered at least one web site that attempts to block access if javascripts are disabled. Many of these web sites have a blank page that overlays the actual web page, usually with a loading indicator of some sort and a message demanding that you enable javascripts in order to access the web site. With the uBlock Origin browser extension installed, one can simply right-click the web page and select the uBlock Origin menu item to block the element, revealing the actual web page underneath the blank overlay. This can also be done to block loading indicators and any other elements of a web site that hide content or are otherwise undesired by the user. Some web sites use more sophisticated methods to block users. When I encounter such a web site, I usually close the tab, as these web sites are not worth my time.

I was surprised to discover that Purism’s public GitLab page (https://source.puri.sm/public) uses Cascading Style Sheets (CSS) to block access if javascripts are disabled. In order to unblock the web page, the user needs to block CSS on the page. This can be done by selecting View in the menu toolbar, then selecting Page Style, and finally selecting No Style. This process has to be done every time source.puri.sm is loaded in a new tab or window.

Ironically, this is difficult to do on a Librem 5 if the menu toolbar is hidden by default, as pressing the Alt key on the Librem 5 keyboard does not make the menu toolbar appear, and having the menu toolbar unhidden by default leaves less space for web content on an already small display. Another method to block CSS on a web page involves using the uMatrix browser extension which has recently been discontinued. One can also use a terminal web browser like w3m which does not have the ability to load CSS, but this solution is also rather inconvenient.

Frustratingly, blocking CSS does not unblock the entire web page, so there is still plenty of content that remains hidden and inaccessible. In contrast, GitHub, now owned by the untrustworthy Microsoft company, does not appear to block users if javascripts are disabled.

I realize that this malicious web design is a product of GitLab rather than Purism, but I wonder what Purism could do to allow their public resources to be easily accessible by the public.

Thoughts?

7 Likes
2

As with most technology, it can be used or it can be abused. It can be: helpful … annoying but harmless … outright harmful. There are definitely legitimate uses of Javascript.

I would have thought that

you would do this. If you don’t trust Purism, that’s your choice, but in that case using their software may not make sense.

This (https://source.puri.sm/public) isn’t exactly general public. It is only if you wish to make changes to these resources - and even then you may not be able to commit your changes. If you just want to access the underlying content, there are likely to be alternatives e.g. maybe you can use the git command and not use the web interface at all. I didn’t try this however.

3

Most modern websites are not usable anymore without JavaScript even though they COULD offer the same functionality (at least for read only things) without it. I think its a bit out of scope for Purism to see that it’s infrastructure works without JS. Gitlab itself is Open Source, so is its JavaScript part. I guess even with the LibreJS browser addon which blocks unfree JavaScript and thus minimizing attacksurface you could enjoy the source code on source.puri.sm.

4

I agree.

I did not suggest that I do not trust Purism. Enabling javascripts in order to read plain text on a web page is unnecessary. That is what I am saying.

I have javascripts disabled on all of my devices by default and only enable javascripts when necessary, like signing into this forum account to give my observations and opinions. Enabling javascripts only on Purism’s GitLab page while leaving it disabled on other web sites requires the use of extensions like uBlock Origin, which can be difficult to use on devices running Phosh. Librem 14 does not struggle to enable javascripts, but on devices like PinePhone, attempting to enable javascripts is cumbersome and can sometimes cause the browser to crash. It is not just annoying. It is needlessly annoying, since javascripts are not needed in order to display text on a web page.

I have seen the following links posted in the forums, and they appear to be for the general public:

I also could not find the information from the above links on the https://docs.puri.sm site, which does not require the use of javascripts. If Purism moved or duplicated all general-public information from the source.puri.sm site to the docs.puri.sm site, then that would be reasonable. I think that Purism should want information they release to be as easily accessible as reasonably possible, so as to build a relationship of trust with their current and potential customers. Trust is something that is generally earned, and encountering barriers to accessing information can cause some to feel uneasy and err on the side of distrust.

Another thing about trust in this context is that the user is asked not only to trust Purism as a company, but also to trust the web site itself. I realize that this is not at all something to expect, but a compromised web site would be less of an issue if javascripts are disabled.

I think a reasonable approach to web browsing is to trust-but-verify, and when possible, eliminate the need to trust.

5 Likes
5

I do not disagree with you, but as I said in my other reply, I think that customer-facing sites meant for the general public should be accessible without javascripts. Obviously the checkout page will require javascripts, but informational pages should be more freely available, in my opinion.

2 Likes
6

Maybe. Without analyzing the page in detail, I don’t know whether the use of Javascript is legitimate.

As an extreme example, all this content is created using markup languages that are not HTML. So conversion into HTML has to happen somewhere. Imagine if the decision is that conversion is client-side (e.g. because certain conversion is client-dependent e.g. locale-dependent). In that case Javascript will be unavoidable and hence legitimate.

As you said originally, I think this Javascript pollution comes ‘for free’ because Purism has used existing tools. For the outcome of those two Wiki pages, yes, they are basic in layout and pure HTML would do the trick. (I agree with you. I would love Purism to publish simple, fast, pure HTML versions of these pages.)

For the avoidance of confusion: those Wiki pages are of a completely different nature and purpose, as compared with the original link that you posted (relating to GitLab repos and developers).

What actually happens if you access the Wiki pages with Javascript turned off?

Yes, that is intentional.

docs.puri.sm is written and authorized by Purism. The two Wiki pages (and everything else in that area) are written by the community and not authorized by Purism.

The community adds what the community finds useful. I doubt Purism has the time right now to trawl through all the community content in order to add into the official documentation what it considers appropriate.

However in order to edit in either area, you need a GitLab account and I guess that that would unavoidably take you down a Javascript rabbit hole.

7

I was originally going to use https://source.puri.sm in my post, but that address redirects to https://source.puri.sm/public so I used that.

The same thing that happens for all of the other source.puri.sm pages happens for the Wiki pages. There is a a menubar at the top of the page with some buttons and a search bar, there is a menubar on the left with some buttons, and there is a blank void where the actual content should be. The page cannot be scrolled left/right or up/down to reveal anything else, and the blank void is not an overlay that uBlock Origin can hide. The only way to see any of the content at all is to either enable javascripts or disable CSS.

I can certainly understand that. I had thought that Purism themselves created and/or put most of the work into creating the FAQ and Tips & Tricks pages, especially with the information about buying and shipping. That is a seriously dedicated fanbase to create such detailed and useful pages of information. I only wish that it can become more accessible in the future, hopefully being added to Purism’s own site eventually.

Thank you for the information.

2 Likes
8

There’s always the nuclear option:

9

In theory, Javascript can add to the textual content of a page. So disabling Javascript and using a text-based browser can lead to different (or erroneous) results.

1 Like
10

The World’s First Website, as it appeared in 1992:

http://info.cern.ch/hypertext/WWW/TheProject.html

http://info.cern.ch/

Wonderfully readable! (Imagine that!)

2 Likes