More about:config regressions
More about:config regressions
After this viewtopic.php?f=56&t=12702 i check my settings and found more regressions in about:config.
# full-screen-api.enabled goes back to true if set to false before PM26 upgrade.
And this entries have no default value- are they removed in PM26?:
# security.ssl3.dhe_rsa_des_ede3_sha
# security.ssl3.ecdhe_rsa_des_ede3_sha
# security.ssl3.dhe_dss_aes_128_sha
# security.ssl3.dhe_dss_aes_256_sha
# dom.network.enabled
# network.websocket.enabled
# full-screen-api.enabled goes back to true if set to false before PM26 upgrade.
And this entries have no default value- are they removed in PM26?:
# security.ssl3.dhe_rsa_des_ede3_sha
# security.ssl3.ecdhe_rsa_des_ede3_sha
# security.ssl3.dhe_dss_aes_128_sha
# security.ssl3.dhe_dss_aes_256_sha
# dom.network.enabled
# network.websocket.enabled
Re: More about:config regressions
Its hidden but works.
Set canvas.poisondata to true.
Set canvas.poisondata to true.
Re: More about:config regressions
So basically nothing's changed.dark_moon wrote:Its hidden but works.
Set canvas.poisondata to true.
Re: More about:config regressions
Did you read the linked thread and my thread?
The topic isn't about the canvas poison option.
The topic isn't about the canvas poison option.
Re: More about:config regressions
Yes I did, and yes I know that. Clearly you didn't see me quote your reply to me.dark_moon wrote:Did you read the linked thread and my thread?
The topic isn't about the canvas poison option.
Re: More about:config regressions
I suggest that in the initial state:
...until WebRTC is completely removed from Pale Moon (27+).
See also bug #959893
Code: Select all
media.peerconnection.enabled = false
See also bug #959893
Re: More about:config regressions
As far as i am aware,WEBRTC has never been in pale moon.GMforker wrote:I suggest that in the initial state:...until WebRTC is completely removed from Pale Moon (27+).Code: Select all
media.peerconnection.enabled = false
See also bug #959893
user of multiple puppy linuxes..upup,fossapup.scpup,xenialpup.....
Pale moon 29.4.1
Pale moon 29.4.1
Re: More about:config regressions
We previously have never built with webrtc.. Except for "Sumozi" which I produced. We are reconsidering WebRTC for Tycho as it is a much better up to date implementation which we do have enabled in the alphas.. As in being built.
-
- Astronaut
- Posts: 650
- Joined: 2015-07-30, 20:29
- Location: Vaughan, ON, Canada
Re: More about:config regressions
At the very least, default it to "off". The bug discussion https://bugzilla.mozilla.org/show_bug.cgi?id=959893 shows some of the privacy implications of webrtc. Firefox is dropping "Hello" https://www.neowin.net/news/firefox-49- ... efox-hello What use-case is there left for webrtc that benefits the end-user as opposed to corporate trackers? Webrtc should be an optional add-on.Matt A Tobin wrote:We previously have never built with webrtc.. Except for "Sumozi" which I produced. We are reconsidering WebRTC for Tycho as it is a much better up to date implementation which we do have enabled in the alphas.. As in being built.
There's a right way
There's a wrong way
And then there's my way
There's a wrong way
And then there's my way
Re: More about:config regressions
Also wasn't the Pale Moon team that made the decision to leave out WebRTC for security reasons?Walter Dnes wrote:At the very least, default it to "off". The bug discussion https://bugzilla.mozilla.org/show_bug.cgi?id=959893 shows some of the privacy implications of webrtc. Firefox is dropping "Hello" https://www.neowin.net/news/firefox-49- ... efox-hello What use-case is there left for webrtc that benefits the end-user as opposed to corporate trackers? Webrtc should be an optional add-on.Matt A Tobin wrote:We previously have never built with webrtc.. Except for "Sumozi" which I produced. We are reconsidering WebRTC for Tycho as it is a much better up to date implementation which we do have enabled in the alphas.. As in being built.
Re: More about:config regressions
The old implementation and spec had major security issues and was also too primitive to be useful to anything wanting to use WebRTC as the spec progressed so it had those going against it.
However, what user benefits? Well, a number of up and coming corporate solutions use WebRTC, as does Google Hangouts and Facebook video chat not to even mention Microsoft Skype for Web. Likely other sites as well.. Google Hangouts at this point and time remain the big one. The ancient Google Talk and Chat NPAPI plugin is ONLY 32 bit and for Windows (maybe Mac but NOT Linux) and is completely deprecated. It isn't even that easy to find the installer for it. In addition, Google has been phasing it's use out and one day won't work anymore to provide what Hangouts need.
Firefox's Hello service is irrelevant except it too used WebRTC so that has no barring here as we don't have it.
Also, WebRTC's hooks into the platform require it to be built with the platform. There isn't a viable NPAPI replacement for it not one that is useful to anyone.. It is invoked using HTML5 and latest javascript technologies directing the multimedia components to do much of the work. So any plugin solution would have to be supported at the service provider level. Also, an extension wouldn't be up to the task.
As, I said, we are evaluating. If the implementation we inherited in Tycho is viable there shouldn't be a reason NOT to use it. If it isn't viable, we will just go back to not having it at all.. So please, don't freak out about it.
However, what user benefits? Well, a number of up and coming corporate solutions use WebRTC, as does Google Hangouts and Facebook video chat not to even mention Microsoft Skype for Web. Likely other sites as well.. Google Hangouts at this point and time remain the big one. The ancient Google Talk and Chat NPAPI plugin is ONLY 32 bit and for Windows (maybe Mac but NOT Linux) and is completely deprecated. It isn't even that easy to find the installer for it. In addition, Google has been phasing it's use out and one day won't work anymore to provide what Hangouts need.
Firefox's Hello service is irrelevant except it too used WebRTC so that has no barring here as we don't have it.
Also, WebRTC's hooks into the platform require it to be built with the platform. There isn't a viable NPAPI replacement for it not one that is useful to anyone.. It is invoked using HTML5 and latest javascript technologies directing the multimedia components to do much of the work. So any plugin solution would have to be supported at the service provider level. Also, an extension wouldn't be up to the task.
As, I said, we are evaluating. If the implementation we inherited in Tycho is viable there shouldn't be a reason NOT to use it. If it isn't viable, we will just go back to not having it at all.. So please, don't freak out about it.