Pale Moon for Android public beta!

Old discussions related to the Android/mobile version of Pale Moon.
dark_moon

Re: Pale Moon for Android public beta!

Unread post by dark_moon » 2014-08-02, 11:35

And F-Droid is nice for users which didn't have the google store and didn't use it, like custom android rom users.

rnewman

Re: Pale Moon for Android public beta!

Unread post by rnewman » 2014-08-02, 23:26

tuxman wrote:And how about some sort of "compression mode" as Opera/Chrome on Android have? I have a "bad" mobile ISP, so every saved byte is worth extra effort for me.
Mozilla is working on it: Janus

This will probably end up as a hosted HTTP2 proxy.

There's an add-on you can use in Nightly to experiment, but this is very bleeding-edge.

rnewman

Re: Pale Moon for Android public beta!

Unread post by rnewman » 2014-08-02, 23:33

Moonchild wrote:Understand one thing above all: I'm pushing for an Android version in an accelerated way because Mozilla broke sync, leaving Pale Moon desktop users dead in the water if they want to sync their mobile devices.
Can you clarify what you mean by "broke sync"?

The old Sync 1.1 client implementation is almost 100% shared with Sync 1.5, and the old 1.1 auth layer is still present and largely unchanged all the way through to Firefox 34: Android Settings > Accounts & sync > Add > Firefox Sync (deprecated).

Encouraging people to use a browser that's missing 11 months of security and stability fixes (PM is based on Fx24, right?) seems pretty irresponsible to me.

User avatar
Moonchild
Pale Moon guru
Pale Moon guru
Posts: 35476
Joined: 2011-08-28, 17:27
Location: Motala, SE
Contact:

Re: Pale Moon for Android public beta!

Unread post by Moonchild » 2014-08-03, 09:39

rnewman wrote:Can you clarify what you mean by "broke sync"?
Sync 1.5 is incompatible with sync 1.1 clients. So-called "c-class" data support is not implemented.

Sync 1.1 servers are still running at Mozilla at this point in time in a limited capacity (no new users or devices) but will likely be shut down soon.
rnewman wrote:Encouraging people to use a browser that's missing 11 months of security and stability fixes (PM is based on Fx24, right?) seems pretty irresponsible to me.
It would indeed be irresponsible, but you're making a wrong assumption here that PM hasn't included any security or stability updates since FF 24.0 - nothing is less true.
I still don't understand why people make this assumption... Despite all the posts and articles already explaining what the situation is and that the major version number is maintained because it is linked to extension compatibility (and PM needs some more work to split off its GUID from Firefox). PM 24.7 != FF 24.0
FF 24.0 was the point where PM clearly split off from FF, but all applicable and relevant security and stability patches authored by Mozilla have been applied, in addition to PM's own development of code.
"Sometimes, the best way to get what you want is to be a good person." -- Louis Rossmann
"Seek wisdom, not knowledge. Knowledge is of the past; wisdom is of the future." -- Native American proverb
"Linux makes everything difficult." -- Lyceus Anubite

tuxman

Re: Pale Moon for Android public beta!

Unread post by tuxman » 2014-08-03, 10:01

rnewman wrote:Mozilla is working on it: Janus

This will probably end up as a hosted HTTP2 proxy.

There's an add-on you can use in Nightly to experiment, but this is very bleeding-edge.
Nice, thanks!

rnewman

Re: Pale Moon for Android public beta!

Unread post by rnewman » 2014-08-03, 15:10

Moonchild wrote:Sync 1.5 is incompatible with sync 1.1 clients. So-called "c-class" data support is not implemented.

Sync 1.1 servers are still running at Mozilla at this point in time in a limited capacity (no new users or devices) but will likely be shut down soon.
I don't think that's "broken". Also incorrect: you can pair new devices.

Self-hosting of Sync 1.5 is totally possible — it's even documented — and only a little more complex than hosting 1.1. Self-hosting of 1.1 is unchanged. Mozilla-hosted 1.1 doesn't have a firm deadline for decommissioning yet, but it'll be well-communicated with a reasonable timeline when it happens.

C-class data is one of the theoretical tributaries of the work done for release. I think you mean "non-derived keys"; a better solution for that is in the pipeline.

Other than a marginal increase in vulnerability to phishing (only one secret credential), Sync 1.5 is of comparable strength to 1.1, but with the gigantic advantage that a steady stream of users don't reinstall Windows and then discover that they don't have their recovery key, and have thus lost all of their data.

(I've been trying to kill Weave and Sync 1.1 for nearly four years now; Sync 1.5 isn't what I wanted, but at least it doesn't actively those harm unsuspecting users, and it fixes many of the identified issues that users had with setting up Sync.)

It sounds like your definition of "broke" is "the new version doesn't interop with Pale Moon's old Sync 1.1", which is totally true, but unavoidable. Sync 1.1 clients can't compute keys in the same way that 1.5 clients can. Such is the business of forking.
Moonchild wrote:I still don't understand why people make this assumption...
I'm on the Fennec development team, so call it an educated guess!

I find it very hard to believe that you've followed the commit history for mozilla-central for a year — hg tells me that's about 70k changesets — finding every single sec bug and backporting them to your fork, as the two codebases drift ever further apart. If you're using ESR to reduce the effort, it's not enough: Fennec sec bugs don't get backported to the ESR branch, because we don't maintain an ESR release. (And even ESR 24 support ended when ESR 31 arrived.)

I find it even harder to believe that you've done that for stability or performance fixes, given that they're often intertwined with new feature work, and are also not backported.

I'd be very pleased to hear that I'm wrong on that, and you have backported all of our sec fixes… it would make me much less concerned for your users, and it would also be an act of engineering heroism, which is worth applauding.

User avatar
Moonchild
Pale Moon guru
Pale Moon guru
Posts: 35476
Joined: 2011-08-28, 17:27
Location: Motala, SE
Contact:

Re: Pale Moon for Android public beta!

Unread post by Moonchild » 2014-08-03, 20:58

You can think whatever you want. Of course I haven't ported everything on m-c over because then I might as well be building Firefox nightly, which is obviously not what I'm doing. I've kept an eye on all relevant security bugs and all commits applicable to the code base. Before ESR I manually ported everything back (ask the Mozilla Security team if you will) by requesting individual sec bug access with each FF release. ESR just allowed me to focus on other parts of the browser that also needed work.
Also, I've seen a good number of /mobile sec bugs in the ESR branch, so I don't think ESR has actually been "left to sit" as you suggest.

That being said, Android builds have not been considered until very recently, so likely Fennec has been a bit behind in that respect.

If ESR 24 support ended when ESR 31 arrived, the Mozilla is not sticking to what they should for corporate users and what is published in their life cycle timeline: 2 version overlap for qualification, so I don't think that assumption is correct either.

And I have to correct you on sync. It is not possible to create new accounts on Mozilla's sync 1.1 server. Which, in effect, makes it unusable for people installing Pale Moon and setting up sync. This means it's broken from a client perspective, hence my statement.

Also, sync 1.1 does not need to compute any sort of key derivative to send to the sync servers since the entropy source remains where it should be: on the client system. See also other threads on this forum about it at the time this was sprung on me. And as for clearly communicating sync matters, Mozilla has not done so before when sync 1.1 servers got limited and FF 29 was published, I didn't hear about this until very close to release, in fact. I don't think there will be more than a passing note "for old ESR users" when they are going to be shut down. They may not have stated a clear date for this, but the message communicated was "very soon". Since Pale Moon uses a sync 1.1 client, it is imperative that a service is set up to take over.

I already gathered that you were a Mozilla dev, by the way, if for nothing else but the way things are addressed.

If Android based on the current code base is clearly not safe to use, then I'll be more than happy to drop it. It's been a headache anyway. But as stated the reason I put work in it is because Pale Moon users want to be able to sync Pale Moon with their mobile devices.

The bottom line is sync. Pale Moon uses sync 1.1 for several reasons, not in the least because Sync 1.5 is not standalone anymore and ties into FxA. Having my own sync 1.5 server does not, unlike 1.1, provide an independent service, because of FxA. Running your own FxA server is experimental and poorly documented. So, that means not only do Pale Moon users have to send their encryption entropy source to a sync server, it will also be tied in with Mozilla's FxA accounts on servers that are not under my control unless I somehow muddle through and manage to guess together an accounts server as well (which is 2 components as well). You HAVE to understand that that is not something I consider acceptable for my users' data.
Because sync 1.1 is used in Pale Moon/desktop, it also has to be used in whatever android version is built. FF/Android 29+ doesn't use sync 1.1, after all, so i can't use a later code base even if I wanted to.
"Sometimes, the best way to get what you want is to be a good person." -- Louis Rossmann
"Seek wisdom, not knowledge. Knowledge is of the past; wisdom is of the future." -- Native American proverb
"Linux makes everything difficult." -- Lyceus Anubite

rnewman

Re: Pale Moon for Android public beta!

Unread post by rnewman » 2014-08-03, 21:59

Moonchild wrote:Also, I've seen a good number of /mobile sec bugs in the ESR branch, so I don't think ESR has actually been "left to sit" as you suggest.
It has certainly been ignored by the mobile team. That doesn't mean that there aren't uplifts, only that mobile uplifts are unusual. "Routine" mobile sec bugs and critical stability bugs are not uplifted as they are for desktop. Furthermore, Gecko bugs that are uplifted to ESR24 might break Fennec in ways that tests don't catch; as far as I know we don't QA Fennec builds from ESR at all, so there's no validation that the ESR branches work. (If they do, great, but that's a happy accident.)
Moonchild wrote:If ESR 24 support ended when ESR 31 arrived, the Mozilla is not sticking to what they should for corporate users and what is published in their life cycle timeline: 2 version overlap for qualification
Sorry, I misspoke; the last scheduled release of ESR 24 will be on the release of 32, which is in about 4 weeks.
Moonchild wrote:And I have to correct you on sync. It is not possible to create new accounts on Mozilla's sync 1.1 server. Which, in effect, makes it unusable for people installing Pale Moon and setting up sync. This means it's broken from a client perspective, hence my statement.
That's not what I said; if you got that impression, I'm sorry for being unclear.

Client support is still present in Fennec. If you have an existing Sync 1.1 account, or host your own Sync 1.1 server, you should have no trouble using Nightly — and that includes pairing new devices.

Fennec has never supported creating new Sync 1.1 accounts, so there is no missing capability there.

Moonchild wrote:Also, sync 1.1 does not need to compute any sort of key derivative to send to the sync servers since the entropy source remains where it should be: on the client system.
Teaching me about Sync is unnecessary; I own the Android Sync module, and I've maintained the desktop codebase since 2010, including implementing the current data encryption scheme on both platforms.

Moonchild wrote:I don't think there will be more than a passing note "for old ESR users" when they are going to be shut down.
There will be in-app messaging ("grey bar"), for one thing.

Moonchild wrote:If Android based on the current code base is clearly not safe to use, then I'll be more than happy to drop it. It's been a headache anyway. But as stated the reason I put work in it is because Pale Moon users want to be able to sync Pale Moon with their mobile devices.
I wouldn't recommend continuing to use a Firefox 24-based Fennec. If you're interested in making Sync 1.1 front-and-center, just rename the "Firefox Sync (deprecated)" account type and remove the FxA account type, and ship 34/35/etc. That'll carry you forward until we finally kill 1.1 and remove the client from the product. Even that won't totally screw you — the 1.5 codebase is largely shared with 1.1, so there will be only a few files and some manifest entries that go into the trash.

Moonchild wrote:So, that means not only do Pale Moon users have to send their encryption entropy source to a sync server…
They don't. Sync 1.5 uses HAWK and a token server. Your credentials do not pass to the server.

You might want to spend the time to read this: https://blog.mozilla.org/warner/2014/05/23/the-new-sync-protocol/

It should address your crypto concerns.

Moonchild wrote:FF/Android 29+ doesn't use sync 1.1, after all, so i can't use a later code base even if I wanted to.
That is incorrect. Here's a screenshot of the Sync 1.1 setup wizard in a current unmodified 34 build.

User avatar
Moonchild
Pale Moon guru
Pale Moon guru
Posts: 35476
Joined: 2011-08-28, 17:27
Location: Motala, SE
Contact:

Re: Pale Moon for Android public beta!

Unread post by Moonchild » 2014-08-03, 23:11

In favor of not getting a "yes/no" again about the sending of credentials vs. sending of entropy sources, and preaching to the choir in both directions, I'll just leave it at this.
We both know what we're talking about, but we both don't necessarily know what the other is talking about, and I have better things to do than to try and equalize all misunderstandings in what is said.

If sync 1.1 on the client side still works in mobile on current FF, then it's obviously a different story than desktop - this also means that people can happily keep using Firefox on Android if they so wish to sync against the Pale Moon sync 1.1 server. Also, it makes it a question about how different Sync 1.5 really is from sync 1.1 - and if Pale Moon could possibly continue using the Mozilla sync servers from a sync 1.1 client despite what was published. That would save everyone a lot of headaches.

Also, if I understand correctly, fennec can currently talk to both sync 1.1 and 1.5 servers? What's the bug# for that change? last I heard they were mutually exclusive.
"Sometimes, the best way to get what you want is to be a good person." -- Louis Rossmann
"Seek wisdom, not knowledge. Knowledge is of the past; wisdom is of the future." -- Native American proverb
"Linux makes everything difficult." -- Lyceus Anubite

rnewman

Re: Pale Moon for Android public beta!

Unread post by rnewman » 2014-08-03, 23:43

Moonchild wrote:Also, it makes it a question about how different Sync 1.5 really is from sync 1.1
They share a storage format. The auth protocol and some other protocol-level aspects (headers etc.) differ. They're close enough that they can share lots of non-auth code.

1.5 is almost entirely focused on providing a user-understandable email + password front-end to Sync. There wasn't time for the more ambitious changes we wanted to make either for Sync 2.0 or PiCL. So it goes.

Moonchild wrote:and if Pale Moon could possibly continue using the Mozilla sync servers from a sync 1.1 client despite what was published. That would save everyone a lot of headaches.
Not really. Apart from switching "1.1" to "1.5" in the URL, you'd need to send the right FxA assertions, get a cert and a node allocation (the user/ API is gone), and get a storage token. Once you have a storage token they're pretty close, but storage tokens expire quickly, and both getting a token and handling expiry are all new.

Moonchild wrote:Also, if I understand correctly, fennec can currently talk to both sync 1.1 and 1.5 servers? What's the bug# for that change? last I heard they were mutually exclusive.
You can't have accounts of both types at the same time and have things work reliably, but you can choose either one. The mutual exclusion work (not yet implemented) is Bug 965924. Removing the 1.1 account type is Bug 957845. Implementing 1.5 was Bug 799726 (mostly Bug 808813).

User avatar
Moonchild
Pale Moon guru
Pale Moon guru
Posts: 35476
Joined: 2011-08-28, 17:27
Location: Motala, SE
Contact:

Re: Pale Moon for Android public beta!

Unread post by Moonchild » 2014-08-03, 23:52

Just for the hell of it, I plugged the FF31-included sync server URL into a test setup of Pale Moon (with sync 1.1 client). And there was no issue setting up a new account OR syncing everything (including master password protected passwords)... So either the Mozilla sync 1.5 servers now understand sync 1.1 clients, or stuff gets redirected to a sync 1.1 server. If the former, then that would solve all issues. If the latter, then that would solve issues up to the point where the former becomes available (if the 1.1 nodes are kept on-line until such time, of course)
"Sometimes, the best way to get what you want is to be a good person." -- Louis Rossmann
"Seek wisdom, not knowledge. Knowledge is of the past; wisdom is of the future." -- Native American proverb
"Linux makes everything difficult." -- Lyceus Anubite

rnewman

Re: Pale Moon for Android public beta!

Unread post by rnewman » 2014-08-03, 23:59

Moonchild wrote:Just for the hell of it, I plugged the FF31-included sync server URL into a test setup of Pale Moon (with sync 1.1 client).
What server URL did you use?

User avatar
Moonchild
Pale Moon guru
Pale Moon guru
Posts: 35476
Joined: 2011-08-28, 17:27
Location: Motala, SE
Contact:

Re: Pale Moon for Android public beta!

Unread post by Moonchild » 2014-08-04, 00:01

rnewman wrote:
Moonchild wrote:Just for the hell of it, I plugged the FF31-included sync server URL into a test setup of Pale Moon (with sync 1.1 client).
What server URL did you use?
https://auth.services.mozilla.com/
"Sometimes, the best way to get what you want is to be a good person." -- Louis Rossmann
"Seek wisdom, not knowledge. Knowledge is of the past; wisdom is of the future." -- Native American proverb
"Linux makes everything difficult." -- Lyceus Anubite

rnewman

Re: Pale Moon for Android public beta!

Unread post by rnewman » 2014-08-04, 00:03

Yeah, that's the Sync 1.1 auth endpoint. I'm not at all surprised that it works.

The FxA ones are all "*.fxa*" in about:config.

User avatar
Moonchild
Pale Moon guru
Pale Moon guru
Posts: 35476
Joined: 2011-08-28, 17:27
Location: Motala, SE
Contact:

Re: Pale Moon for Android public beta!

Unread post by Moonchild » 2014-08-04, 00:17

I'm just surprised it would still be in FF 31 then, since it uses Sync 1.5 and would have no use for the old end point? I mean, the sync client would still be using services.sync.serverURL to determine which sync data server to use. The only .fxa prefs are there for terms/timeouts; so unless I'm missing a prefs file somewhere, it seems to use the same end point for sync 1.1 and 1.5.
"Sometimes, the best way to get what you want is to be a good person." -- Louis Rossmann
"Seek wisdom, not knowledge. Knowledge is of the past; wisdom is of the future." -- Native American proverb
"Linux makes everything difficult." -- Lyceus Anubite

rnewman

Re: Pale Moon for Android public beta!

Unread post by rnewman » 2014-08-04, 00:31

Moonchild wrote:I'm just surprised it would still be in FF 31 then, since it uses Sync 1.5 and would have no use for the old end point? I mean, the sync client would still be using services.sync.serverURL to determine which sync data server to use.
Fx31 still supports existing Sync 1.1 users. (This will continue to be the case until those users are migrated and the service is EOLed.)

The in-browser account creation UI is gone, because that's a recipe for confusion, and maintaining and QAing both is a waste of investment.

services.sync.serverURL, which is https://auth.services.mozilla.com/, is needed even after initial setup (e.g., to find a new clusterURL during node reassignment). If we removed that pref, we'd break existing 1.1 users.

Literally the only thing removed from desktop Fx is the setup UI. Existing users have to keep working.
Moonchild wrote:The only .fxa prefs are there for terms/timeouts; so unless I'm missing a prefs file somewhere, it seems to use the same end point for sync 1.1 and 1.5.
The FxA endpoints are identity.fxaccounts.auth.uri, identity.fxaccounts.remote.signin.uri etc.

User avatar
Moonchild
Pale Moon guru
Pale Moon guru
Posts: 35476
Joined: 2011-08-28, 17:27
Location: Motala, SE
Contact:

Re: Pale Moon for Android public beta!

Unread post by Moonchild » 2014-08-04, 01:02

Understood.

Well, in that case it seems there's a big dilemma, since syncing is particularly useful for PM on Android.
  1. Mozilla has a working setup for sync 1.1 clients - something I have worked over 2 weeks on to try and reproduce but the sync 1.1 server fails to be stable, despite using the exact steps documented on the Mozilla services website for running your own sync 1.1 server.
  2. The actual sync setup @ Mozilla is undocumented (how exactly it's set up, using which front-end on which OS, any specific changes made, etc.)
  3. Alternatives are either N/A for a public service or do not work/are incomplete. This makes my own implementation of a sync 1.1 service to have Android users sync with desktop Pale Moon problematic - since the only working and usable solution is unstable.
  4. Sync 1.1 is greatly preferred over sync 1.5 for a number of reasons, not in the least the more extensive infrastructure needed and the incomplete documentation for FxA if I wanted to set that up myself, let alone making everything simple-signon dependent (which is a data security concession simply for a very low usage threshold for end users)
Who would I contact to find out details from (2) to solve these stability issues with server-full on my own server by trying to reproduce the exact environment currently in use?
Since it works on Mozilla's boxes, it should be possible to get it stable on my own server(s) as well, after all. Alternatively, what would it take for at least one of the Mozilla Sync 1.1 servers to remain on-line for an extended period of time, and who would I contact for that? Data wipes are no issue, of course.
"Sometimes, the best way to get what you want is to be a good person." -- Louis Rossmann
"Seek wisdom, not knowledge. Knowledge is of the past; wisdom is of the future." -- Native American proverb
"Linux makes everything difficult." -- Lyceus Anubite

rnewman

Re: Pale Moon for Android public beta!

Unread post by rnewman » 2014-08-04, 01:25

Moonchild wrote:Mozilla has a working setup for sync 1.1 clients - something I have worked over 2 weeks on to try and reproduce but the sync 1.1 server fails to be stable, despite using the exact steps documented on the Mozilla services website for running your own sync 1.1 server.
You should ask in #services-dev on IRC, or on the sync-dev mailing list.
Moonchild wrote:Sync 1.1 is greatly preferred over sync 1.5 for a number of reasons, not in the least the more extensive infrastructure needed and the incomplete documentation for FxA if I wanted to set that up myself, let alone making everything simple-signon dependent (which is a data security concession simply for a very low usage threshold for end users)
Just to be clear: Sync 1.1 support (server, maintained server code, and client code) will be going away at some point from mainline Firefox. If you elect to depend on it, you'll be taking on a significant maintenance burden — client, server, and infrastructure.

And more Mozilla services (Marketplace, Where's My Fox, …) will use a Firefox Account. Identity-attached services are simply table stakes for a browser in 2014.

If interop with official Firefox, other Mozilla clients, and other Mozilla services are part of your offering (rather than just being a plain ol' browser), then it's probably worth thinking about directions that will preserve that interop. You might simply decide that waiting for ckarlof and warner to design and ship a pure-key/pairing-based approach on top of 1.5 is the right avenue.

Again, such is life for a fork, and I'm sure this is no news to you, but it bears repeating.
Moonchild wrote:Alternatively, what would it take for at least one of the Mozilla Sync 1.1 servers to remain on-line for an extended period of time, and who would I contact for that? Data wipes are no issue, of course.
I imagine that's not an option — we're trying to eliminate that hosting cost. It's not just one server: it's storage, a webhead, user API, an LB, DNS, switches, A/C, dcops, and all the rest. But you can ask in one of the media mentioned above.

User avatar
Moonchild
Pale Moon guru
Pale Moon guru
Posts: 35476
Joined: 2011-08-28, 17:27
Location: Motala, SE
Contact:

Re: Pale Moon for Android public beta!

Unread post by Moonchild » 2014-08-04, 10:29

rnewman wrote: If you elect to depend on it, you'll be taking on a significant maintenance burden — client, server, and infrastructure.
The thing is -- if it is already a working system, maintenance would not be particularly much. I already have the client, I already have infrastructure, the only problem is server setup. If it isn't broken, there isn't much to maintain. Change in such a service isn't always inevitable.
rnewman wrote:And more Mozilla services (Marketplace, Where's My Fox, …) will use a Firefox Account. Identity-attached services are simply table stakes for a browser in 2014.

If interop with official Firefox, other Mozilla clients, and other Mozilla services are part of your offering (rather than just being a plain ol' browser), then it's probably worth thinking about directions that will preserve that interop. You might simply decide that waiting for ckarlof and warner to design and ship a pure-key/pairing-based approach on top of 1.5 is the right avenue.
I think we're living in slightly different ecosystems here. Pale Moon users are not looking for a Firefox Marketplace or identity-attached services. In fact quite a number of them very much want what you call "a plain ol' browser" and that is also one of the goals of the Pale Moon project. So no, nobody is eager to jump into FxA or being tethered to MozCo for services. I repeat myself: the reason Pale Moon for Android was accelerated was because people wanted sync - the good ol' sync - and nothing else was requested despite other service implemented in Mozilla Cloud Services. ckarlof and warner should have had pure-key/pairing in place in sync 1.5 before it was pushed because of the implication of the new system for data security. At that point (when c-class data is supported, as callahad called it), using FxA will become an acceptable compromise; not before.
rnewman wrote:
Moonchild wrote:Alternatively, what would it take for at least one of the Mozilla Sync 1.1 servers to remain on-line for an extended period of time, and who would I contact for that? Data wipes are no issue, of course.
I imagine that's not an option — we're trying to eliminate that hosting cost. It's not just one server: it's storage, a webhead, user API, an LB, DNS, switches, A/C, dcops, and all the rest. But you can ask in one of the media mentioned above.
I understand - considering the infrastructure is set up to cater to a vastly larger number of users.
Still: if you need all that, then the sync implementation used for 1.1 must have serious scalability issues.
"Sometimes, the best way to get what you want is to be a good person." -- Louis Rossmann
"Seek wisdom, not knowledge. Knowledge is of the past; wisdom is of the future." -- Native American proverb
"Linux makes everything difficult." -- Lyceus Anubite

a550914

Re: Pale Moon for Android public beta!

Unread post by a550914 » 2014-08-13, 09:51

Any idea why HTTPS Everywhere won't install? (https://www.eff.org/https-everywhere)

It's not available from the standard mozilla addons directory (where I am able to install addons).

I was able to install the android version of noscript without any problems (also not in the standard mozilla directory: http://noscript.net/nsa/).

The only error I receive is a generic "not compatible" one.

Locked