https://software.opensuse.org does not (quite) work without JavaScript any more. Why?

English Open Chat
21

Ah, a Richard Stallman reference!
Absolutely a most entertaining advocate/activist for freely distributed everything…
I wouldn’t miss any of his talks.

But, you have to consider what he says with a critical mind…
People like Richard Stallman are absolutely essential to describe and advocate for utopian concepts make us think critically about what exists and what could.
But, utopians often are on shaky ground (as in this case).

For starters,
I see after his article title (Trap? Who wants to fall into a trap?) and original statement (What? Running bad things unwittingly?) a tremendous waffling and more critically, an introduction of a tangential concept (triviality). The end result is that his original premise is fatally flawed.

If anything,
I’d say instead “Don’t fall into the Javascript Trap Article.”

There are a number of bogeymen stood up in the article,

  • Script source identification. This is perhaps the only item in the article I fully endorse. This used to be done all the time, but not always today. But, even without explicitly stating in the page source, I usually find identification in the script source which has to exist or the script authors might not have any claim. Nowadays, packages of scripts are generally distributed and even read from the page as a single file, and not piecemeal.
  • Free vs non-free code. First, javascript will generally always run whether it’s FOSS or has a proprietary license. It’s the webmaster’s responsibility to ensure license compliance. And, of course just because it’s javascript does not imply the script is non-free. Stallman’s article does not claim the script is likely non-free, only the <possibility> without saying that it’s not likely.
    -** Obfuscated code.** I do not see any obfuscated code in software.opensuse.org. For that matter, Stallman doesn’t even describe obfuscated javascript code correctly and confuses with minimizing. I guess Stallman may not know about de-minimizing applications which can make minimized code readable again. Too bad. And, this is of course possible because that’s the weakness of obfuscation vs alternatives like encryption(but that’s not an option for web page code).
  • AJAX. This is one of the most revolutionary methods used in web programming today, the ability to update only a part of a web page with raw data rather than having to re-draw the entire page. Well, too bad. And, at least within a discussion of possible malevolent or unknown code running in your web browser, this is a complete non-sequitur.
  • Code that calls other code. Hmmm. That’s a pretty powerful method to be avoided. If you’re writing object-oriented code defining functions, this is a basic building block. Surely Stallman can’t be advocating for no OOP!

IMO a big problem with Richard’s article is that I doubt the depth and exposure he has in web page development and javascript, he would do well to join a community that specializes in those technologies to better understand strengths and weaknesses of those technologies.

Additional comment about your reference to Spectre…
I’ve posted in another thread that some current patches only address a javascript attack vector, the actual vulnerability is left unaddressed. That’s fine for the short term because PoC have been written using javascript but it should be noted that IMO Spectre should be exploitable in many different ways so blocking the javascript vector is not a real fix.

And, I’d recommend simply running “Inspect Element” on any object in any of the most common web browsers… You’ll find that even server-side javascript is displayed, so there really isn’t much that you can’t see. Of course, you’ll still need to know javascript to know what you’re looking at.

TSU

22

I’ve already mentioned in a prior post that I find no obfuscated code in software.opensuse.org, for that matter anywhere in any opensuse property.

But,
If you’re actually interested in building an HTML-only page (or site), I’ve done that before, too…
And, the key to doing it is to actually start with what you see in your web browser already.

Simply copy the page and then methodically identify anything that

  • Uses client-side script
  • Uses server-side script

Substitute anything that uses script with whatever you want using straight HTML.
Any client-side script can usually be stripped out easily, particularly if it’s merely decorative and not AJAX.
Any server-side script might be a bit more difficult to replace and will depend on the situation but be inventive.

And then you’re done.

TSU

23

Hear, hear. I’m no javascript expert, but I use the ‘Inspect Element’ option a lot. Nice post, Tony.

24

[QUOTE=Knurpht;2859749]To add a bit: javascript has nothing to do with FOSS. Like HTML doesn’t. They’re standardized protocols.
[/quote]
JavaScript and HTML are not protocols but programming languages. HTML requires nothing but rendering done by the browser. JavaScript programs though are external code which the browser downloads and executes. JavaScript can be and and usually is non-FOSS. For reason like this people created LibreJS.

BTW: As a Board member I can guarantee you that our entire infrastructure, so including software.o.o is nothing but FOSS … with one exception: these forums. :D.

These guarantees are futile. I could argue that as long as your machines run Intel ME or proprietary microcode the “nothing but FOSS” statement is meaningless as well as any attempt for security at ring 0-3. But all that is off-topic.

It is not an opinion but a fact that software.opensuse.org uses Piwik and these forums use Google Analytics.

Of course, I have. As I said - I am not an FSF fanatic. Personally I don’t like any attempts for establishment of utopias. Here I am rather discussing technical facts than ideologies (trust is also a form of ideology). So the link was just a shortcut to illustrate a principle without typing too much. The principle being: browser JavaScript as a way to download and execute externally hosted code which one cannot possibly verify on each and every web page load opening the door to various mischief. That is the only thing I am interested in.

IMO a big problem with Richard’s article is that I doubt the depth and exposure he has in web page development and javascript, he would do well to join a community that specializes in those technologies to better understand strengths and weaknesses of those technologies.

Quite right.

Additional comment about your reference to Spectre…
I’ve posted in another thread that some current patches only address a javascript attack vector, the actual vulnerability is left unaddressed. That’s fine for the short term because PoC have been written using javascript but it should be noted that IMO Spectre should be exploitable in many different ways so blocking the javascript vector is not a real fix.

There is no real fix for Spectre or Meltdown. There are only mitigations. Top experts confirm that the only real fix is to have new CPUs without the existing hardware issue. Still reducing the possibility for attacks by not running unverified code (such as JavaScript programs from web pages) is a valid, healthy and sane measure. Personally I use uMatrix and uBO in quite tightened mode. I enable JS only individually and temporarily for particular sites which I open in “private browsing mode” without any other program windows or browser tabs opened and with clipboard contents cleared before all that. That is my “simulation of single tasking”. Although that may sound ridiculous and it is not an absolute guarantee of anything, I think it can still reduce the exposure. There isn’t anything more one can do nowadays.

And, I’d recommend simply running “Inspect Element” on any object in any of the most common web browsers… You’ll find that even server-side javascript is displayed, so there really isn’t much that you can’t see. Of course, you’ll still need to know javascript to know what you’re looking at.

I do some web programming, so I am aware of all that. Note that “Inspect Element” shows the current DOM, not the html source, i.e. if JS is running (or some extension modifies the HTML) you may be looking at something different from the original HTML.

[QUOTE=tsu2;2859764]I’ve already mentioned in a prior post that I find no obfuscated code in software.opensuse.org, for that matter anywhere in any opensuse property.
[/quote]

  1. Open https://software.opensuse.org/
  2. View source (usually Ctrl+U)
  3. In the <head> section you will see a tag like:

<script src="/assets/application-f138ca00f631a013675d9ea487a7e5afc06839913e263c9992e1341aa8a1549a.js"></script>

Open that URL and you will see the obfuscated code.

But,
If you’re actually interested in building an HTML-only page (or site), I’ve done that before, too…
And, the key to doing it is to actually start with what you see in your web browser already.

Simply copy the page and then methodically identify anything that

  • Uses client-side script
  • Uses server-side script

Substitute anything that uses script with whatever you want using straight HTML.
Any client-side script can usually be stripped out easily, particularly if it’s merely decorative and not AJAX.
Any server-side script might be a bit more difficult to replace and will depend on the situation but be inventive.

And then you’re done.

TSU

That is oversimplified. Example: I want to see the additional community version of claws-mail which I have installed from server:mail repo. So I go to:

https://software.opensuse.org/package/claws-mail

Previously I could click and see that additional version without JS. Now I cannot. I cannot even use the “Download” buttons which the page provides without enabling JS. And no, right clicking on “Show community packages” and then inspecting the element does not reveal a link. It reveals:


<button class="btn btn-sm btn-danger" type="button" data-toggle="collapse" data-target="#opensuse-leap-423-community-packages">Show community packages</button>

How exactly this data should be used in order to access an actual list of community packages remains a mistery until one either enables JS or reverse engineers how this JS interacts with the info from that button element. That is completely unnecessary, it does not improve user experience, it does not add security or privacy. FWIW: It is not even search engine friendly.

25

HTML is a protocol in the most general definition of protocol, eg

And, HTML is not a programming language (I dare anyone to post an example of such). HTML as a <markup> language only defines the way content is displayed, and has no way to provide functionality although tags can call functionality, that is why Javascript is often chosen to provide that functionality (and is lesser known but CSS3 can also do so).

Although there are a great many things that can be done from a default web environment, javascript in general has been sandboxed to disallow web code from acting on a system’s normal operations today (was much looser years ago). That said, I personally have issues with the read-only information that can be gathered by HTML5. And, it should be recognized that <with explicit User agreement> extensions can be installed that allow the web code to reach into a system’s otherwise forbidden parts. That agreement can often not be totally obvious, it might be part of the initial installation of the special web application, and not show up again later when that functionality is actually used.

Analytics code that reaches into the client system can be blocked (I use Ghostery). Although it can be an intrusion, I do understand the practical need for webmasters and business decision-makers so that intelligent decisions can be made. This is just one of those opt-out decsions to be made, and it’s not like those who don’t want to be analyzed have a difficult time doing something about it.

No. Completely wrong. Javascript is "not a way to download and execute externally hosted code.’ Rather, downloading remote objects is a feature of the DOM that allows remote packages of <anything> to be downloaded and added to the DOM. You’ll often find much more than javascript, you’ll also find schema definitions, configurations and much more besides desired functionality. And, as for specifically downloading something specific, as long as downloading is defined in the DOM it’s typically called by an HTML statement.

Not entirely true. Latest Intel CPUs have the ability to accept a firmware update with the necessary micro-code fixes so those don’t need to be replaced. And, IMO current patches do an OK job blocking current known PoC vectors like using javascript. It’s your own decision if you feel you need to do more and it should be noted that even patched machines will likely be vulnerable to other attack vectors(eg Trojan attacking by system sockets or pipes instead of network sockets).

Your link does not point to obfuscated code. Rather, the code is very but unformatted so that the lines of code run together, which is one thing that “minification” does (another is removal of white space). Like Stallman, you should understand what ubfuscation is… The following is an example of obfuscating a URL (You can plug into your web browser). Javascript obfuscation uses the same algorithm, so if your javascript was obfuscated it would look something like the example obfuscated urls

software.opensuse.org

https://%73%6f%66%74%77%61%72%65.%6f%70%65%6e%73%75%73%65.%6f%72%67

and
software.opensuse.org/search

https://%73%6f%66%74%77%61%72%65.%6f%70%65%6e%73%75%73%65.%6f%72%67/%73%65%61%72%63%68

As I described, you have to have some way of executing the button, and in a text-only browser like Lynx, that’s done for you.
I also suggested that if you’re running a graphical browser without javascript support, then point your web browser directly at the repos (http://download.opensuse.org/repositories). Use something like Google search if you don’t want to manually thumb through the repos.

TSU

26

Small add to my criticism about obfuscation…
I won’t budge from what obfuscation actually is,

But, Stallman could have been referring to doing certain transformations to javascript so that it’s distributable in a smaller file, faster and yes… maybe someone might find it harder to read and understand. One of the most well known I’m aware of is UglifyJS (https://github.com/mishoo/UglifyJS).

Some techniques used include what can often be found in code obfuscators like variable name substitution, but the resulting code is generally not obfuscated so that the code is completely unreadable as in my URL obfuscation examples. In fact, if you “beautify” (ie reverse the uglification), you’ll likely find that nearly all the text characters are the same pre- and post-.

As for how this relates to software.opensuse.org, I repeat that I do not find any obfuscated code only few examples of minified library code and the actual code written by the webcoders is not obfuscated or minified at all.

TSU

27

[QUOTE=tsu2;2859839]HTML is a protocol in the most general definition of protocol, eg

And, HTML is not a programming language (I dare anyone to post an example of such). HTML as a <markup> language only defines the way content is displayed, and has no way to provide functionality although tags can call functionality, that is why Javascript is often chosen to provide that functionality (and is lesser known but CSS3 can also do so).
[/quote]
You are confusing HTTP (a protocol) with HTML. The two are different things. HTTP can be used without HTML and vice versa. Yes, generally HTML is not considered programming language but a markup one, still that is just wording. In any case its nature makes it safer than JS which can do much more. It is up to the browser how HTML is handled. Whether you trust your browser is a whole other story.

Although there are a great many things that can be done from a default web environment, javascript in general has been sandboxed to disallow web code from acting on a system’s normal operations today (was much looser years ago).

That “in general” is nothing more than a generalization. There are PoC demonstrating Spectre attacks through JS. A false assumption of security is worse than knowing a system is insecure.

That said, I personally have issues with the read-only information that can be gathered by HTML5. And, it should be recognized that <with explicit User agreement> extensions can be installed that allow the web code to reach into a system’s otherwise forbidden parts. That agreement can often not be totally obvious, it might be part of the initial installation of the special web application, and not show up again later when that functionality is actually used.

I don’t know of any way through which pure HTML can gather information without user consent. What are you talking about? And what have extensions to do with what we are discussing here? And how does your posting about that relate at all to the excerpt you quote before it? Makes no sense.

No. Completely wrong. …]

What I said is a well know technical fact. You are arguing with facts and floating off into something else. I don’t know why.

Latest Intel CPUs have the ability to accept a firmware update with the necessary micro-code fixes so those don’t need to be replaced. And, IMO current patches do an OK job blocking current known PoC vectors like using javascript.

The microcode cannot fix the CPU design and the side channel execution is part of that. Also the microcode is not even open source, i.e. you don’t know what the hardware vendors may put into it. So it is questionable whether through those “fixes” new back doors are not introduced. Perhaps that is off-topic too.

Your link does not point to obfuscated code. Rather, the code is very <clear> but unformatted so that the lines of code run together, which is one thing that “minification” does (another is removal of white space).

“In software development, obfuscation is the deliberate act of creating source or machine code that is difficult for humans to understand.”

Obfuscation does not necessarily mean using weird characters. It often means making function names and variables deliberately meaningless by shortening them.

Unminified that code is more than 10200 lines and full of things like:


function u(t, e, i, n) {
        if (Mt(t)) {
...

If you think that is easy for humans to read and understand, or to do it on each page load - I don’t.

As I described, you have to have some way of executing the button, and in a text-only browser like Lynx, that’s done for you.
I also suggested that if you’re running a graphical browser without javascript support, then point your web browser directly at the repos (http://download.opensuse.org/repositories). Use something like Google search if you don’t want to manually thumb through the repos.

I know there are workarounds. Still that doesn’t justify deliberately creating the need for them. Using JS is ok if it does not block totally site functions. Even better - if it is FOSS. None of those are the case.

28

My mistake about HTML as a protocol.
But does not change what I described about what HTML does and doesn’t.

You can try to argue shutting off javascript altogether beyond simply patching for side channel attacks, but for most people, patching already blocks known PoC. A proper fix is more complicated.

Regarding whether the CPU needs to be replaced or not,
The following Intel guide is authoritative, and the last few paragraphs at the bottom are the facts…
A list of affected Intel CPU indicates everything up to i7 is affected, and i8 is <not listed>.
With some additional reading, you will find that Intel has distributed firmware updates to OEMs and I assume those same patches are available for i8 machines already sold. No need to replace the CPU.

https://www.intel.com/content/www/us/en/architecture-and-technology/facts-about-side-channel-analysis-and-intel-products.html

I grant that there are exceptions to the rule, but in general most un-minified JS libraries are easy to read (It’s why like everyone else I know I never destroy the original source before minified or obfuscated so that nothing is lost). The vast majority of beautified js code is easy to read, and exceptions should not be held up as typical. Even your example is impossible only because it’s a code fragment. If the entire JS were displayed and the purpose discerned, maybe even without descriptive variable names the entire statement can be read and understood.

In any case,
We probably are in agreement on one thing…
It’s one of my personal axioms regarding GUI design that flashiness should never get in the way of functionality, and in this particular case I see no functional reason to hide links… In fact, if anyone were to look up a recent Forum thread which involved re-installing the most recent version of PostgreSQL, that person also did not realize that he had to click on something to display what he wanted.

So, I’d consider this one instance a graphical design flaw where not only is necessary information hidden, it’s hidden in a way that might be considered unintuitive. Additionally, at the very least I also know JS code exists that hides and displays content in a different way that allows a web browser without javascript to see the hidden content automatically which should address your complaint.

TSlU

29

TL;DR.

  • They’re not going to change it because one person has paranoid delusions.
  • It’s fine as it is.

On with the show.

30

Well, they are not mutually exclusive. As I said - where it is absolutely necessary I do enable JS - for a short time and under special conditions. Unfortunately security though patching does not lead to security by design. So it is nothing more than what it is - patching. Today I tested this Spectre PoC on my patched Leap installation and the exploit worked.

As long as the basic mechanism on which computer security is based on (isolation) is broken at hardware level we can patch to infinity the system but it will never be secure. So far it may not have been a problem but now that it is known to the world there will be more and more exploits, beyond what we can currently imagine. From what I read even top experts are still not sure of the full spectrum of problems this reveals. So I am not arguing, I simply refuse to ignore facts for the sake of comforting beliefs.

The following Intel guide is authoritative, and the last few paragraphs at the bottom are the facts…

I don’t know if you have read this: a few months before the side channel vulnerabilities were announced (but were known to Intel) Intel’s CEO sold his shares for many millions. Recently Intel announced that they are working on new CPUs without those vulnerabilities. So they 1) made money from flawed CPUs during the last 20 years 2) made money through that share sell 3) plan to make even more money as a result of all that. Meanwhile they also made Intel ME, closed microcode and who knows what else. So I have my reserves about Intel’s authoritative info.

I grant that there are exceptions to the rule, but in general most un-minified JS libraries are easy to read (It’s why like everyone else I know I never destroy the original source before minified or obfuscated so that nothing is lost). The vast majority of beautified js code is easy to read, and exceptions should not be held up as typical. Even your example is impossible only because it’s a code fragment. If the entire JS were displayed and the purpose discerned, maybe even without descriptive variable names the entire statement can be read and understood.

We cannot possibly discuss each and every case. The example I gave is directly related to the topic of this thread. I hope you would agree that instead of trying to read and understand 10200+ lines of such code, it is easier not to run that code at all.

We probably are in agreement on one thing…
It’s one of my personal axioms regarding GUI design that flashiness should never get in the way of functionality, and in this particular case I see no functional reason to hide links…

Yes, I agree to that. It is a basic UI design principle to show and make available the most important information, not to obstruct it.