Jump to content

My Browser Builds (Part 1)


Recommended Posts

I am currently using 'uBlock Orgin firefox-legacy-1.16.4.8 - gorhill Jan 26, 2019' ... with New Moon and Basilisk. If a newer legacy version is released ... I just run it with the older version in place and it updates to the newer version.

I don't quite understand why a person would need this updater - Ublock origin legacy updater 1.6.7 ( Basilisk ). Is this another actual 'legacy version' different from the gorhill versions?

My latest updated uBlock Orgin firefox-legacy-1.16.4.8 seems to be working OK.

...

Link to comment
Share on other sites


1 hour ago, roytam1 said:

Why are they so determined to take that out? Why not just let it be and not maintain it? Don't see how that would affect performance but thanks for keeping it in, at this point we need both because legacy addons are  no longer in development.

Link to comment
Share on other sites

On 2/13/2019 at 9:33 AM, Monroe said:

I am currently using 'uBlock Orgin firefox-legacy-1.16.4.8 - gorhill Jan 26, 2019' ... with New Moon and Basilisk. If a newer legacy version is released ... I just run it with the older version in place and it updates to the newer version.

I don't quite understand why a person would need this updater - Ublock origin legacy updater 1.6.7 ( Basilisk ). Is this another actual 'legacy version' different from the gorhill versions?

My latest updated uBlock Orgin firefox-legacy-1.16.4.8 seems to be working OK.

...

I think the idea is, it's supposed to update you to the next legacy version whenever gorhill releases one. If you just use Basilisk Serpent's own auto-update it will keep updating you to 1.17.4 (Baslisk Serpent 52) or the current WE version (Basilisk Serpent 55), so you just have to turn auto-update off.

It may not be needed in PM/NM/Basilisk because those browsers only support legacy add-on versions anyhow, but it's useful in FF 52 ESR or Serpent, where some WE add-ons are also supported.

Edited by Mathwiz
Clarify branding since Basilisk only supports legacy add-ons now like PM/NM
Link to comment
Share on other sites

18 minutes ago, DanR20 said:

Why are they so determined to take that out? Why not just let it be and not maintain it? Don't see how that would affect performance but thanks for keeping it in, at this point we need both because legacy addons are  no longer in development.

 

Moonchild believes that webextensions both directly and indirectly introduce security bugs.

Link to comment
Share on other sites

4 minutes ago, DanR20 said:

Why are they so determined to take that out? Why not just let it be and not maintain it? Don't see how that would affect performance but thanks for keeping it in, at this point we need both because legacy addons are no longer in development.

The most charitable explanation I can think of is that they're trying everything they can to, uh, "encourage" add-on developers to maintain legacy add-ons, since PM/NM doesn't support WE at all, and the Basilisk support they keep trying to remove is limited.

If that's the explanation, though, I think it's a losing battle. Add-on developers aren't going to start maintaining their legacy code again just because of Basilisk, so this would just make Basilisk a less useful FF 52 fork. @roytam1 is correct to revert these changes.

It seems unlikely, given how "ideological" MC et al. can be, but maybe they'll figure that out one day, and put the limited WE code from FF 52 back in to not only Basilisk but also PM.

Link to comment
Share on other sites

2 hours ago, Sampei.Nihira said:

Moonchild believes that web extensions both directly and indirectly introduce security bugs.

That sort of sounds like what Google is saying about the API that uBO uses. Of course, restricting that API happens to benefit Google financially, so there's reason to distrust Google on that.

But I can't see how removing WE APIs would benefit the PM team. So I have to take MC at his word that he at least believes that. Which makes me wonder: does he have a point? Could a malicious WE add-on do more damage than a malicious legacy add-on? Seems unlikely, but I don't know enough to say for sure.

Edit: Even if MC is right, I'd still prefer to take my chances. Just make WE a Boolean in about:config and let users decide for themselves; I wouldn't force my own paranoia on everyone else. (BTW, looks like Schmaif made the same point on PM's forum.)

Edit 2: MC's post on the question is quite vague:

Quote
  1. Increasing disparity with the "gecko" target: our platform support for WebExtensions in Basilisk is basic, mostly limited to cross-browser content manipulation, and won't be extended with Mozilla-specific APIs, mainly because we already have existing APIs that can be fully used from XUL extensions. This makes our WebExtension support increasingly at odds with what "gecko" targeting WebExtensions expect.
  2. The large security attack surface WEs pose. Some taste of that became public knowledge recently with web content being able to steal browser data through WEs.
  3. Aside from that though, there is constant upkeep in security bugs (undisclosed) dealing with WEs.
  4. The non-native nature of WE interface elements in a XUL-based application. A whole bunch of hacks are needed to integrate web content widgets in the XUL UIs.
  5. XUL extensions already offer anything WEs can do, and then some, without the need for writing new WE APIs for specific extensions, each with their own maintenance and risks.

Point 1 seems to be "we don't intend to expand WEs because we think doing so is unnecessary;" that's fine, but it hardly seems like a reason to remove them. Just leave them as they are.

Point 2 is, you can "steal browser data through WEs." But is there data you can steal through WEs that you can't steal through legacy APIs? And my previous comment still stands, in any case: let end-users decide. Default it to off but if folks are willing to take their chances, let them turn it on. The benefits, although limited, still seem to outweigh the risks to me.

Point 3 does make a bit of sense to me: even if they never expand WE functionality, it would be irresponsible not to address and fix security bugs in the existing APIs as they are identified. But I can't imagine that implementing security patches to the limited WE APIs in FF 52.9 and Basilisk has been a significant burden to the PM team.

Points 4 and 5 seem merely to expand on point 1: it's not practical to expand WEs given the XUL code base, and it's not necessary anyway because the legacy APIs provide all the same functionality.

To be blunt, these don't seem like compelling reasons to remove the existing WE functionality, even when taken all together.

Edited by Mathwiz
Link to comment
Share on other sites

10 minutes ago, Mathwiz said:

That sort of sounds like what Google is saying about the API that uBO uses. Of course, restricting that API happens to benefit Google financially, so there's reason to distrust Google on that.

But I can't see how removing WE APIs would benefit the PM team. So I have to take MC at his word that he at least believes that. Which makes me wonder: does he have a point? Could a malicious WE add-on do more damage than a malicious legacy add-on? Seems unlikely, but I don't know enough to say for sure.

https://forum.palemoon.org/viewtopic.php?f=61&t=21298

Link to comment
Share on other sites

@Sampei.Nihira, and Mozilla said the opposite: they had to remove legacy because of security. I would imagine they both have issues but I've yet to hear many stories of where firefox has been compromised from addons, legacy or we. If it were a widespread problem then the argument can be made for changes otherwise it becomes unnecessary disruptions.

@Mathwiz, I agree, legacy is dead in terms of development, their use comes in the ability to keep installing the old ones in browsers like basilisk but all of the energy today is with we and it's going to stay that way.

Link to comment
Share on other sites

4 hours ago, roytam1 said:

One problem introduced by the PM team's change is that Basilisk will will now accept add-ons that won't work anymore since it identifies as 52.9.something. So to keep Basilisk from auto-updating legacy add-ons to now-incompatible WE add-ons, the PM team changed the "get add-ons" site from AMO to a new one they're setting up (not ready yet) for Basilisk: http://addons.basilisk-browser.org.

But @roytam1's builds retain Basilisk's original WE support :worship:, so the change to "get add-ons" keeps any WE add-ons from auto-updating properly. But I think this can be fixed by just changing these about:config prefs: extensions.update.background.url and extensions.update.url, back to addons.mozilla.org.

Edited by Mathwiz
Link to comment
Share on other sites

Please, when will be out a NM/PM 28.x SSE build?

I am looking for one with a newer JS version, which could work on aukro.cz.

The 27.x SSE ones (~ FF 45.9) do not work there, the JS engine is too old.

Thanks.

Edited by redfoxcz
Link to comment
Share on other sites

3 hours ago, redfoxcz said:

Please, when will be out a NM/PM 28.x SSE build?

I am looking for one with a newer JS version, which could work on aukro.cz.

The 27.x SSE ones (~ FF 45.9) do not work there, the JS engine is too old.

Thanks.

not possible since javascript engine in gecko > 49 (goanna >= 4) will emit SSE2 instructions unconditionally, as a result SSE2 is mandatory.

Link to comment
Share on other sites

New build of basilisk/UXP for XP!

Test binary:
Win32 https://o.rths.cf/basilisk/basilisk52-g4.1.win32-git-20190216-77e1b07f3-xpmod.7z
Win64 https://o.rths.cf/basilisk/basilisk52-g4.1.win64-git-20190216-77e1b07f3-xpmod.7z

diff: https://o.rths.cf/basilisk/UXP-xp-gitdiff-20181110.7z

PM28XP build:
Win32 https://o.rths.cf/palemoon/palemoon-28.4.0a1.win32-git-20190216-77e1b07f3-xpmod.7z
Win64 https://o.rths.cf/palemoon/palemoon-28.4.0a1.win64-git-20190216-77e1b07f3-xpmod.7z

Official repo changes since my last build:
- Expose TLS 1.3 cipher suite prefs. (8beab28bf)
- Allow empty string on `location.search` setter. (487afe9f4)
- Add "check for updates" to main menu and AppMenu v2 (dd418226c)
- Restore app.update.url.override preference. (71c81eb90)
- Remove webextensions conditional code from Basilisk. (6bb02d95f)
- Remove WebExtension support from the platform. (43d44975b)
- Remove the WebExtension Add-on Manager from our tree. (1e0da1994)
- Move "No proxy for" control down to clarify it is a global effect. (8e0fdf931)
- Fix line endings (0e80d10f4)
- Implement origin-clean algorithm for ImageBitmap. (91799767e)
- Use C++11 thread-safe statics with MSVC. (f595579f0)
- Disable "helpful" MSVC warning about AVX instructions. (9a090b794)
- Bump goanna version for updated canvas handling. (4ec8be4ae)
- Use C++11 thread-safe statics with MSVC. (js) (71d32272e)
- Update browse URL for AM search to Phoebus 2.0 (0d88098e3)
- Port several Skia upstream fixes. (a6ddde909)
- Preserve transparency when copying a DIB to/from the clipboard. (77e1b07f3)

My changes since my last build:
- nspr: update nspr to hg rev 753fe0f7964c
- nss: update nss to hg rev 395a93dbc02e with vc2013 patch applied
- reverted following changes:
 - Remove webextensions conditional code from Basilisk. (6bb02d95f)
 - Remove WebExtension support from the platform. (43d44975b)
 - Remove the WebExtension Add-on Manager from our tree. (1e0da1994)
 - Use C++11 thread-safe statics with MSVC. (f595579f0)
 - Use C++11 thread-safe statics with MSVC. (js) (71d32272e)

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...