Hacker News Reader

Comment by eropple | Hacker News Reader

It's a web API, but it's a web API that requires development work to do, and Goanna (Pale Moon's pre-multiprocess, pre-all-the-things-that-make-modern-Firefox-good Gecko fork) would need to implement those APIs.

View on HN

Just ran checksec on Pale Moon's Linux binary distribution - their binaries are built with no mitigations whatsoever. ASLR disabled, no stack canaries, no fortify.

This whole project appears to be a security disaster and nobody should use it.

They're generally pretty unprofessional.

https://github.com/jasperla/openbsd-wip/issues/86

I feel for the OpenBSD developer who apparently expected the project lead to be a reasonable grown-up, but ended up slapped in the face.

yikes. That's about the most insane exchange I've seen on Github.

That exchange borders on unbelievable for me. How any project could be so tone deaf is beyond comprehension. And the initial message from the PM project is more than enough to set anyone off.

This issue is now officially resolved. There will be no Pale Moon browser, official or not. The port has been removed. Farewell, petulant children.

Beautiful response.

Petulance is independent of age.

This read was amazing, and I would fully recommend it for someone self-isolating with a hot cup of coffee who wants a jolly read about how not to communicate with others.

Then there's this one from privacytools.io where they disregard criticism as "Fake News" https://github.com/privacytoolsIO/privacytools.io/issues/375... and get all upset at people for "shitting on them". (Note mattatobin is also one of their devs).

The real security disaster on the modern web is commercial groups taking over setting standards and turning the web browser into an OS with all the security problems that entails.

The opposite is the case - web applications are one of the best things to happen, security-wise, in a long time.

Web applications are fully isolated and sandboxed, have fine-grained permissions, are easy to inspect, and the runtime is built with a modern threat model.

ChromeOS is probably the most secure desktop OS for this reason.

I want my browser to expose more functionality to web apps, because it means that I have to run less random unsandboxed code on my underlying OS.

I'd like it more if my underlying OS provided these features instead of running an OS on my OS.

We need both - some kinds of applications need direct hardware access. But the kernel attack surface is huge, even with seccomp and friends.

An app on my smartphone or - much worse - an Electron app "sandboxed" in a flatpak on my desktop has access to far wider range of dangerous APIs than a web application. What's wrong with a browser as a high-level OS?

It's mostly the layering that bothers me.

I don't mind Chrome OS and love my chromebook.

Some of this is aesthetic so I don't really expect to change minds, but if we lived in the world of "Life and Death of Javascript" and booted to some kind of Web OS I'd be annoyed at the loss of low level hackibility and get over it.

Booting to Linux, then booting a browser to get to a normal app that doesn't need network connectivity "feels" wrong.

Booting to Linux is just because Google did not want to start from scratch.

If they took a Xerox approach, ChromeOS would have a tiny mikrokernel, hypervisor type 1 style, and jump directly into Chrome.

I agree, I'd like it if all app platforms were portable, secure, and linkable by default. Given that they aren't, my allegiance is with the web.

A reasonable view.

I value discoverability and comprehensibility of the underlying platform a bit more, and have recognized that isn't likely to happen any time soon.

We had Java....

Sandboxes are security features that have to implemented though, and if implemented incorrectly will create vulnerabilities. I’m sure google is on top of these but these random unheard of browsers need more scrutiny

The thing that kills me is that they forked a pretty bad (at the time) browser core to make Goanna, then the parent of the fork got way better and left them in the dust.

I would actively block Pale Moon if I thought I worked with people silly enough to use a slow single-process browser in 2020. (Instead of a moderately slow multi-process browser. But I digress.)

> are easy to inspect

Until they're delivery vehicles for obfuscated wasm to canvas rendering applications. Then nothing of the "web as graph of hypertext documents" will be left.

There's been a lot of ridiculous FUD about "DRM will be used even for text!!1" (wrt. EME especially) and nothing of that sort has materialized.

(also, wasm changes nothing here, you could always obfuscate js just as much)

> wasm changes nothing here, you could always obfuscate js just as much

It is a significant change because it lowers the bar to create a blackbox. wasm offers the performance, canvas provides an opaque, flexible render target. Without either you're limited to obfuscating your JS (which indeed already happens) and obfuscating your DOM (also happening). But the DOM still leaves enough surface for adblockers and other extensions to intervene. Perhaps throw in a websocket/webrtc to channel all your data over a single connection and you basically have created a single intransparent blob which extensions cannot interact with on the behalf of the user.

You turned the user agent into the site's agent.

> "DRM will be used even for text!!1" (wrt. EME especially)

I am not aware of EME offering a data path to bring encrypted text to the screen. Without such a path these claims have no merit, wasm + canvas on the other hand offer a clear path.

Flipboard made react canvas to render directly to canvas instead of the dom. https://github.com/Flipboard/react-canvas

Go to nasa.gov with javascript off. Tell me how much text you can read. It doesn't have to be DRM. It just has to be ever more complex JS standards and engine implementations that only a handful of companies can actually make.

Once it's an application instead of a document the text just isn't there.

Websites are at least supposedly are sandboxed so they are not as much of a risk as running native binaries. But this is getting worse and worse though as browsers expose more and more of their host operating system's functionality. The benefits of using a website instead of a native app are quickly disappearing, while the drawbacks have only been somewhat mitigated. We're getting to the point where browsers are worthy of the decades old criticism Emacs has received. They have eventually become an OS with many fine features - simply lacking a good web browser. For the privacy (and security) conscious user, modern web technologies will undermine you every step of the way, or simply break if you choose to stand your ground.

Just empirically, browser security has improved dramatically over the last decade or so. When did a browser exploit last cause actual real-world damages? I remember network infrastructure compromises, social engineering, fake gmail logins, etc, but the weekly flash or PDF worm is gone, and JS seems to be holding up remarkably well given its size and complexity. Aluminium Centrifuges seem to also be more vulnerable these days than Chromium Browsers.

Somebody seems to be doing something right.

Why was it used at all if it's basically an old fork of Firefox? Just curious as I've never heard of it before.

"Customization." It retains the older, Firefox ~25-ish UI. They've since upgraded the backend to Firefox 52, which is still Really Old. And they've got a lot of culty behavior around their community, if that's your bag.

If you absolutely must have an XUL-based Firefox derivative: 1) you don't, 2) stop, and 3) don't use this one if you don't listen to #1 or #2.

Help. Police. Murder. Stop. Don't. Come back.

https://www.youtube.com/watch?v=W9ZD3_ppcPE

> their binaries are built with no mitigations whatsoever. ASLR disabled, no stack canaries, no fortify.

Provide evidence.

Anyone can easily verify this by downloading the binaries, and running checksec themselves.

Here's the output:

    $ sha256sum palemoon-bin
    0b7f4ad73fc671e20bfb2366aa9d9ad81e82a3c8f63acde7f37063e73fda2141  palemoon-bin

    $ checksec --file=./palemoon-bin --output=json --extended | jq 
    {
      "./palemoon-bin": {
        "relro": "partial",
        "canary": "no",
        "nx": "yes",
        "pie": "no",
        "clangcfi": "no",
        "safestack": "no",
        "rpath": "no",
        "runpath": "no",
        "symbols": "no",
        "fortify_source": "no",
        "fortified": "0",
        "fortify-able": "15"
      }
    }

Notably, the binary has not been compiled with -fPIE and -fstack-protector, which disables two very basic exploit mitigations - ASLR and stack canaries. Any self-respecting Linux distribution enables these compiler flags by default nowadays. -D_FORTIFY_SOURCE is also missing, unlike Chrome or Firefox. A modern browser uses dozens of custom binary exploitation mitigations in addition to this.

Mitigations and sandboxing are the difference between an exploit a CTF player can write on an afternoon, and a multi-month expert-level endeavour.

Which version is the `palemoon-bin` that you have there?

It's 28.8.4 x64, downloaded straight from the website. (I duplicated his efforts; tbf, you could have, too.)

> It's a web API, but it's a web API that requires development work

Care to name one web API that doesn’t require development work?

Web standards evolve, new APIs are introduced. News at 11.

Yeah, that's my point. Pale Moon's developers forked a complex project and are now asking people to not use things that the mainline project now supports just fine.

Checks written, can't cash, etcetera.

Fair enough, should have sensed the sarcasm.

There are too many APIs released at neck-breaking speed, often poorly designed and rushed.

See Google's own Web Api tracking page [1] Chrome adds almost 1000 new APIs per year Only last year they added over 500 APIs that are not present in other browsers, and pretend they are standard and will not remove them even if other browsers are not going to implement them due to multiple explicitly voiced concerns.

So yeah, no. Your news at eleven is misleading at best.

[1] https://web-confluence.appspot.com/#!/confluence

> Definition: API: For the purposes of these metrics, an “API” is an interface name + attribute or operation pair.

So there aren’t 1000 new Web Component specs coming out each year, no. And fewer make it into W3C/WHATWG specs.

No. But there are 1000 new web APIs that you have to implement yearly just to keep up. And Web Component specs are a part of that.

And then despite all the objections from all the other browser vendors Google releases an API in production and will not mark it as experimental. Yes, a Web Components-related API (Adopted Stylesheets).

the same can be said about any new CSS features and other new stuff that goes into the browser. browsers are evolving rapidly, either to make devs work easier or make users' work easier or just to make everything prettier or faster.

Reply on news.ycombinator.com