MozillaZine

Custom Build Plan for Freedom Fox

Discussion of third-party/unofficial Firefox/Thunderbird/SeaMonkey builds.
TCaudillLG
 
Posts: 35
Joined: March 2nd, 2005, 4:27 pm
Location: Middletown, OH

Post Posted February 1st, 2014, 2:29 am

I'm starting a new build project, "Freedom Fox". This project will implement a number of changes that I think will make Firefox better software. Some of these changes may seem counter-intuitive, but my reading of the facts at hand suggests they will achieve the aims of the Mozilla project better than the current proposals.

1) eliminate XPCOM and other such cross-platform abstraction layers.
2) create the ability for web pages to access the local file system (with user permission). This functionality was available in Firefox builds up until release 17 last year.
3) remove a lot of the "pro-business" features and technologies that bloat the browser unnecessarily. If you need that stuff, that's what Javascript/addons are for.

Eliminating XPCOM might seem counter-productive as far as platform universality goes. However, Chrome cited abstraction-level issues as a key reason for forking Webkit into Blink. Abstraction can introduce lots of hard to identify bugs. XPCOM is created by IBM... I don't have a lot of faith in things made by IBM. Better to rely on platform specific calls... it is after all the spirit, not the method, that matters most when pursuing platform breadth.

I've heard Firefox is a tougher build than in the past. I'm thinking to start with earlier builds and swap in parts of later builds.

As far as building Firefox goes, I can handle the compilation process myself, although I would appreciate the advice of an experienced hand in the matter.

My chief motivation for doing this project is that I'm sick of the disrespect I and others receives from Mozilla as users, and am very tired of jumping through hoops to do simple things like opening files on the user's file system (I've spent more hours stringing together event chains for addon code than any man should). I would that the browser became a replacement for native apps (it's very close already), but it's at the point where established interests are feeling they have turf to defend, and Mozilla is all over the place as to which interests to respect and which not to (they have rallied under a banner of over-protectiveness at any rate). Suffice to say that I disagree with their development philosophy, even as I agree with their basic values. I agree with Mozilla project in principle, but just can't abide by their design.

tcaud
 
Posts: 19
Joined: February 1st, 2014, 3:49 pm

Post Posted February 1st, 2014, 5:26 pm

Eliminating XPCOM will be difficult. I won't be doing that right away. Gonna remove the junk first. Is there some place you custom builder peeps meet over IRC, where I can get some help understanding what does what and how?

xunxun1982
 
Posts: 311
Joined: June 20th, 2011, 10:37 am

Post Posted February 2nd, 2014, 12:49 am

I don't know whether you started as a normal slim build or a xulrunner app.

If you started as a normal slim build, I am developing a pcxFirefox 28.0 Mini edition.

This is my completed features:
1) Remove WebGL, autoconfig, SPS profiler, pdfjs, healthreport, skia, gamepad ( Very easy )
2) Remove DOM API: pay, activities, battery, bluetooth, contacts, fmradio, mobilemessage, phonenumberutil, telephony, push, identity, promise, datastore, settings, camera
3) Remove toolkit modules: diskspacewatcher, social, parental control

And I can remove more features but I am not a Web programmer, I don't know what effect some modules have.

I want to know your progress.

Thanks.

bisketti
 
Posts: 16
Joined: February 2nd, 2014, 1:04 am

Post Posted February 2nd, 2014, 3:01 am

create the ability for web pages to access the local file system (with user permission)
Respectfully, as a user, I absolutely cannot abide the prospect of browser intrusion into my filesystem.
Did we, collectively, not learn a hard lesson from the past decade of ActiveX vulnerabilities?!?

Regardless whether the functionality is called "native client", whether dev(s) promise "user permission" will be required... no!
Flat out, no!

A gecko-based desktop rootmenu (or entire desktop environment, routed via websockets and node.js)
would be acceptable, perhaps even appealing, but a full-blown "browser" would represent an ever-suspect (privacy leak and) malware vector.

along the same vein (nerve)
WebRTC.
Thanks, but no thanks. It has to go -- by that, I mean it "needs to be ripped out by the roots" removed from the codebase.
If I wanted a videochat app, I would have installed a video chat app.
"just switch it off. We won't re-enable it behind yer back. Honest Injun!"

Smells like: "we have the utmost respect for our users' privacy and HealthReporting will be opt in"
Nope. Fool me once, burn me twice... I've become pretty darned disillusioned toward Mozilla.
Somewhere, I did read a devblog explaining the "rationale" for changing to default=enabled, must opt out
(fewer than 3% of users had elected to opt-in)(so, basically... screw 'em)

By the by, current events -- check out the news story regarding the Sept2013 reported/verified webRTC vulnerability in Chrome.
Reported 120 days ago; still not fixed. Why? The behavior arguably, technically, "meets the API specification".
Spec, as in "inbuilt spyware capability, by design" ?!?

I understand the argument that HealthReporting does not transmit any "personally identifying" info.
(I both understand it, and call bullshit ~~ installTime + various other correlated details creates a damn solid fingerprint.)
Here's the deal:
Evident in the removal/crippling of prior features and functionality, introduction of multiple privacy-unfriendly behaviors...
...Mozilla is pursuing an agenda which seemingly is NOT aligned with users' (best) interests.

This is my completed features:
1) Remove WebGL, autoconfig, SPS profiler, pdfjs, healthreport, skia, gamepad ( Very easy )
2) Remove DOM API: pay, activities, battery, bluetooth, contacts, fmradio, mobilemessage, phonenumberutil, telephony, push, identity, promise, datastore, settings, camera
3) Remove toolkit modules: diskspacewatcher, social, parental control

And I can remove more features but I am not a Web programmer, I don't know what effect some modules have.
Removed? Really?
If you have simply provided a few "custom" mozconfig --disable-thisthing directives... I'm convinced that amounts to chasing your tail.

As it stands (ff v23+ codebase) at each startup, Mozilla and/or a well-endowed MITM can silently push an "update" which temporarily enables "sync service" and slurps EVERY bit of detail (history, bookmarks, stored logins) known to the browser... uninstalling itself afterward and leaving no user-detectable trace.
---
No, I won't entertain demands to provide a working POC. The code is self-evident.
This backdoor vector is inbuilt by design, replete with inline comments indicating various methods which MUST not be obviated (via proposed patches, nor via user prefs).

Until / unless the XPCOM "services" mechanism becomes an optional, separately-installable, component (ain't gonna happen)
Mozilla firefox users will continue to "benefit from" whatever "services" may Mozilla care to provide.
Silently.
"because Our extensive research (cough, cough) indicates that users don't like popups. Oh, and by the way, they LIKE Australis too."

tcaud
 
Posts: 19
Joined: February 1st, 2014, 3:49 pm

Post Posted February 2nd, 2014, 3:57 pm

The capability for local file access was there for years without incident. Server admins depended on it. There was similar functionality in Opera until it went over to Webkit. If you don't like the idea of random websites accessing your files (I don't), that's what whitelists are for. Personally I wouldn't allow local file access except by sites whose admins I know on a first name basis. Running offline apps from trusted sources as file:/// URIs is a whole 'nother story. I don't like that HTML pages can't access web pages, except through an addon system whose spec is unstable and a constant distraction from writing purposeful code.

Bisketti you may have your opinion. I don't share it.

There is a lot that can be done to customize Mozilla without bothering to create a custom build. You can add files to the install directory and even expose custom methods and chrome code. I've noticed that the Web Audio API is entering implementation... that means the "anti-MS revolution" which started with the development of HTML 5 is now reaching its crescendo, and browsers have access to all major hardware functions. This means the beginning of the end of the native code era... file access obtuseness at the browser is the last thing going in favor of native code technologies as far as software developers are concerned. Even Javascript now enjoys dynamic recompilation, so that it runs as fast as compiled code.

The safest way to neuter a Firefox build is to cut off its components at the XPCOM level by going into the Omni jars and slashing script. It's also the fastest by far, because script restoration is a matter of a single file replacement.

What I'm trying to understand now is how to actually make a module script "stick"; that is, have its operations accessible to content script. For example I'd like to create a child property of window at the chrome level and access that in page scripts. I figure the ability does exist, but finding the documentation is difficult since MDN's redesign... much of the information on how Firefox is structured has either been lost, or else unlinked to in the accessible docs.

The scariest thing I've seen in Mozilla's new system, is the web-app blacklist. That grabs a list of prohibited apps from Mozilla's website and bars the browser from running them. I can't imagine it being abused. >_>

As far as HTML page security vs native app security goes, it is far more intelligent to run a script whose operations are clearly readable than to run a perfectly opaque binary file that serves the same purpose.

xunxun1982
 
Posts: 311
Joined: June 20th, 2011, 10:37 am

Post Posted February 2nd, 2014, 4:54 pm

In fact, I provide the --disable-... option in my patches.

And I want to know what function you will eliminate from xpcom?

tcaud
 
Posts: 19
Joined: February 1st, 2014, 3:49 pm

Post Posted February 2nd, 2014, 5:50 pm

Well I tried to add a "foo" variable to browser.js (in browser/content/browser folder of the omni.ja in the browser folder), and it corrupted my install. I tried taking it back out, but the corruption remained. I'm not sure if it's a security precaution, or if WinRAR didn't zip the jar file back right. Regardless, this thing is harder to hack than it looks...

tcaud
 
Posts: 19
Joined: February 1st, 2014, 3:49 pm

Post Posted February 2nd, 2014, 11:31 pm

xunxun1982 wrote:In fact, I provide the --disable-... option in my patches.

And I want to know what function you will eliminate from xpcom?


Took this list from Light Fox's thread.

crashreporter skia webm opus ogg wave webrtc jsd gamepad intl-api accessibility webapp sync healthreport safebrowsing pdfjs identity spellcheck tabview social devtools printing webspeech webgl directshow

I'd eliminate everything in this list I struck out, and make everything in bold a plug-in type deal or replace it with an alternative. Learning Skia was a Google project surprised me... just shows how much Google has infiltrated. I'd leave in the game relevant stuff though, 'cause I like HTML 5 for games.

What I'd like to do is start with an earlier version (one that enabled chrome access to webpages) and replace the components with later versions. Security would not be a priority, but I'm pretty sure users could get used to using one browser for apps and another for buying stuff off eBay, if it meant the apps were superior.

Honestly though what's needed is a whole new browser, preferably done in free BASIC (QB64 or FreeBASIC) for readability and ease of maintenance. XPCOM is impossible to deal with... who knows what god awful exploits are lurking within it? A lot of Firefox's weakness is from doing stuff it shouldn't even be trying to do. This project might seem intimidating, BUT it could be accomplished by integrating the Spider Monkey JS engine from old Firefox. Wouldn't be as fast at first, but eh. Could probably pull in Amaya's parts for the rendering.

Oh, and that 8 megs for webapprt... yeah I'd shaft that, too, and the webapp spec in general. Those AMO guys are so anal... giving them that kind of power over software distribution networks is bad juju.

xunxun1982
 
Posts: 311
Joined: June 20th, 2011, 10:37 am

Post Posted February 3rd, 2014, 5:06 am

tcaud wrote:
xunxun1982 wrote:In fact, I provide the --disable-... option in my patches.

And I want to know what function you will eliminate from xpcom?


Took this list from Light Fox's thread.

crashreporter skia webm opus ogg wave webrtc jsd gamepad intl-api accessibility webapp sync healthreport safebrowsing pdfjs identity spellcheck tabview social devtools printing webspeech webgl directshow

I'd eliminate everything in this list I struck out, and make everything in bold a plug-in type deal or replace it with an alternative. Learning Skia was a Google project surprised me... just shows how much Google has infiltrated. I'd leave in the game relevant stuff though, 'cause I like HTML 5 for games.

What I'd like to do is start with an earlier version (one that enabled chrome access to webpages) and replace the components with later versions. Security would not be a priority, but I'm pretty sure users could get used to using one browser for apps and another for buying stuff off eBay, if it meant the apps were superior.

Honestly though what's needed is a whole new browser, preferably done in free BASIC (QB64 or FreeBASIC) for readability and ease of maintenance. XPCOM is impossible to deal with... who knows what god awful exploits are lurking within it? A lot of Firefox's weakness is from doing stuff it shouldn't even be trying to do. This project might seem intimidating, BUT it could be accomplished by integrating the Spider Monkey JS engine from old Firefox. Wouldn't be as fast at first, but eh. Could probably pull in Amaya's parts for the rendering.

Oh, and that 8 megs for webapprt... yeah I'd shaft that, too, and the webapp spec in general. Those AMO guys are so anal... giving them that kind of power over software distribution networks is bad juju.

I think even though slimming the skia, there is another backend to replace it (cairo?)
Mozilla take WebRTC as an importand position, and they want to integrate some decoders and encoders into WebRTC, and other modules can directly call WebRTC.
Integrating the newer JS engine into old Firefox may be a good idea, but it wont follow Mozilla's newest features.
In fact, I don't know what Mozilla's webapprt can do.

tcaud
 
Posts: 19
Joined: February 1st, 2014, 3:49 pm

Post Posted February 3rd, 2014, 1:52 pm

xunxun1982: It's basically a clone of Chrome's Apps runtime. WebRTC can be used to create servers... really, that's what it is. A chat server backend. Turn your comp into a game server, or a hangout... all you need is the bandwidth and the script.

While it's true newer versions of Javascript have more features, the only such features I've found occasionally useful are the "for ..." variants. "Let" I could do without.

xunxun1982
 
Posts: 311
Joined: June 20th, 2011, 10:37 am

Post Posted February 3rd, 2014, 5:59 pm

And at the same time, I don't think gamepad is very important for Desktop Firefox.

tcaud
 
Posts: 19
Joined: February 1st, 2014, 3:49 pm

Post Posted February 3rd, 2014, 7:57 pm

There is software called Joy2Key which you can use to intercept gamepad presses and map them to the keyboard. I kinda like having the gamepad there though, because tbh playing games is something a lot of people do nowadays, and the keyboard is cumbersome and kinda unhealthy to use.

tcaud
 
Posts: 19
Joined: February 1st, 2014, 3:49 pm

Post Posted February 3rd, 2014, 8:27 pm

I remember that Firefox started going downhill about version 3.5. Does anyone know why?

xunxun1982
 
Posts: 311
Joined: June 20th, 2011, 10:37 am

Post Posted February 3rd, 2014, 8:41 pm

tcaud wrote:I remember that Firefox started going downhill about version 3.5. Does anyone know why?

Which aspect?

bisketti
 
Posts: 16
Joined: February 2nd, 2014, 1:04 am

Post Posted February 3rd, 2014, 10:11 pm

tcaud wrote: trying to understand now is how to actually make a module script "stick"; that is, have its operations accessible to content script. For example I'd like to create a child property of window at the chrome level and access that in page scripts.

Are any of these helpful?
http://stackoverflow.com/questions/5146 ... a-web-page
http://blog.mozilla.org/addons/2012/08/ ... nt-safely/
http://stackoverflow.com/questions/1569 ... to-jsvalue
viewtopic.php?f=19&t=2105087

Return to Third Party/Unofficial Builds


Who is online

Users browsing this forum: No registered users and 3 guests