Enhancing product security with CSP for internal pages

[Frederik Braun]

Hi folks,

For those who don't know me, I'm a Security Engineer working on Firefox
OS (mostly Gaia and Gecko things). I have been pursuing a security goal
for quite some time now but haven't yet announced this to throughout the
project.

A few months ago I had the idea to add a Content Security Policy (CSP)
to our internal pages, like about:newtab for example.
This is a "defense in depth" mechanism which can prevent Cross-Site
Scripting (XSS) flaws in chrome context (i.e., in privileged pages)
being exploited. These simple XSS oversights in privileged pages would
mean complete code execution on the system of the victim!
The benefit is therefore quite clear and there have been multiple issues
with script and other injections in the past.


To move on, all affected pages have to be modified so that stylesheets
and JavaScript live in different documents. This means moving inline
styles style tags and attributes, script tags and event attributes
(e.g., onclick, onload) into separate documents.

The good thing is that most of these changes are just tiny patches which
can be handed out to volunteers and new contributors: We have already
made some progress and rewrote some of those files (thanks to so many
volunteers). I filed "good first bugs" (linked to the tracking bug
923920) and the current progress is well documented on the wiki (link
below).

What I am asking of you is quite simple:
* If you have some spare time, file additional bugs and link them to the
tracking bug 923920
* If you are a module peer, consider to require that updated and new
internal pages contain no inline script. Our progress has been
diminished by pages being patched towards CSP incompatibility again.


Thanks!
Frederik


Further reading:
* XSS: https://en.wikipedia.org/wiki/Cross-site_scripting
* CSP: https://en.wikipedia.org/wiki/Content_Security_Policy
* Vulnerabilities: MFSA 2012-78, MFSA 2013-52, MFSA 2012-95
* This project on the Wiki:
https://wiki.mozilla.org/Security/Inline_Scripts_and_Styles
* Tracking bug for rewriting HTML/JS:
https://bugzilla.mozilla.org/show_bug.cgi?id=923920
* Tracking bug for Gecko changes:
https://bugzilla.mozilla.org/show_bug.cgi?id=923902
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Recommendations on source control and code review

[Aryeh Gregor]

On Mon, Apr 14, 2014 at 5:01 AM, Karl Tomlinson  wrote:
> Very often I've found that the intended approach changes during the
> life of a bug, and there is no clear summary in the bug of what
> eventually was done.  It is then necessary to go back through
> multiple revisions of the patch and associated comments and
> replies to find out the reasoning.  Add in the complexity of
> multiple changes in one bug, and having a single summary in one
> place would be very helpful, and is, when it is there.

I strongly agree with this, and was particular to write detailed
commit messages in the other large project I ever worked on
(MediaWiki).  But doesn't Mercurial hide all but the first line by
default in the places you'd normally look for it (e.g., log)?  If so,
given how few Mozillans currently use detailed commit messages, it
would be a waste of effort to write them.  It's unlikely that anyone
will ever look.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

RuntimeWarning: couldn't determine platform's TOTAL_PHYMEM warnings.warn("couldn't determine platform's TOTAL_PHYMEM", RuntimeWarning) while run ./mach build for Ubuntu 12.04 64 bit os

[himanshu . mistri]

Hello I android developer i just work to build Firefox android build by Step 
given in This Site :

https://wiki.mozilla.org/Mobile/Fennec/Android#Explained

Now let me give my system Info :
Ubuntu 12.04 64 Bit OS 
4 GB RAM
Processor :Intel(R) Core(tm) i3-2120 CPU @ 3.30GHz × 4

I follow below step and which work fine with out any Error :

sudo apt-get update
sudo apt-get build-dep firefox
sudo apt-get install ant
wget http://dl.google.com/android/ndk/android-ndk-r8e-linux-x86_64.tar.bz2
tar -xjf android-ndk-r8e-linux-x86_64.tar.bz2
wget http://dl.google.com/android/adt/adt-bundle-linux-x86_64-20131030.zip
unzip adt-bundle-linux-x86_64-20131030.zip
apt-get install -y ia32-libs
sudo apt-get install mercurial ccache
sudo apt-get build-dep firefox

I have create .mozconfig by  below code :

# Add the correct paths here:
 ac_add_options --with-android-ndk="$HOME/android-ndk-r8e"
 ac_add_options 
--with-android-sdk="$HOME/adt-bundle-linux/sdk/platforms/android-16"

 # android options
 ac_add_options --enable-application=mobile/android
 ac_add_options --target=arm-linux-androideabi

Now when i Run first time :

Mozilla/src$ ./mach build

It process and setup some file and at end it say me re run  same command .

Now when i re run it it give below Error :
Mozilla/src$ ./mach build
/home/ubbvand2/Himanshu/Mozilla/src/python/psutil/psutil/_pslinux.py:108: 
RuntimeWarning: couldn't determine platform's TOTAL_PHYMEM
  warnings.warn("couldn't determine platform's TOTAL_PHYMEM", RuntimeWarning)
Error running mach:

['build']

The error occurred in code that was called by the mach command. This is either
a bug in the called code itself or in the way that mach is calling it.

You should consider filing a bug for this issue.

If filing a bug, please include the full output of mach, including this error
message.

The details of the failure are as follows:

AttributeError: 'module' object has no attribute 'get_sysinfo'

  File 
"/home/ubbvand2/Himanshu/Mozilla/src/python/mozbuild/mozbuild/mach_commands.py",
 line 287, in build
monitor.init(warnings_path)
  File 
"/home/ubbvand2/Himanshu/Mozilla/src/python/mozbuild/mozbuild/controller/building.py",
 line 161, in init
self.resources = SystemResourceMonitor(poll_interval=1.0)
  File 
"/home/ubbvand2/Himanshu/Mozilla/src/testing/mozbase/mozsystemmonitor/mozsystemmonitor/resourcemonitor.py",
 line 180, in __init__
virt = psutil.virtual_memory()
  File "/home/ubbvand2/Himanshu/Mozilla/src/python/psutil/psutil/__init__.py", 
line 1170, in virtual_memory
return _psplatform.virtual_memory()
  File "/home/ubbvand2/Himanshu/Mozilla/src/python/psutil/psutil/_pslinux.py", 
line 143, in virtual_memory
total, free, buffers, shared, _, _ = _psutil_linux.get_sysinfo()

I found solution here :https://bugzilla.mozilla.org/show_bug.cgi?id=930808#c5

But that seem does not work in my case .
My  python package for  python-psutil   1.2.1-1~ppa1 is installed.


Any help will be great to go further for me.



___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: RuntimeWarning: couldn't determine platform's TOTAL_PHYMEM warnings.warn("couldn't determine platform's TOTAL_PHYMEM", RuntimeWarning) while run ./mach build for Ubuntu 12.04 64 bit os

[himanshu . mistri]

On Monday, April 14, 2014 4:27:07 PM UTC+5:30, himansh...@brainvire.com wrote:
> Hello I android developer i just work to build Firefox android build by Step 
> given in This Site :
> 
> 
> 
> https://wiki.mozilla.org/Mobile/Fennec/Android#Explained
> 
> 
> 
> Now let me give my system Info :
> 
> Ubuntu 12.04 64 Bit OS 
> 
> 4 GB RAM
> 
> Processor :Intel(R) Core(tm) i3-2120 CPU @ 3.30GHz × 4
> 
> 
> 
> I follow below step and which work fine with out any Error :
> 
> 
> 
> sudo apt-get update
> 
> sudo apt-get build-dep firefox
> 
> sudo apt-get install ant
> 
> wget http://dl.google.com/android/ndk/android-ndk-r8e-linux-x86_64.tar.bz2
> 
> tar -xjf android-ndk-r8e-linux-x86_64.tar.bz2
> 
> wget http://dl.google.com/android/adt/adt-bundle-linux-x86_64-20131030.zip
> 
> unzip adt-bundle-linux-x86_64-20131030.zip
> 
> apt-get install -y ia32-libs
> 
> sudo apt-get install mercurial ccache
> 
> sudo apt-get build-dep firefox
> 
> 
> 
> I have create .mozconfig by  below code :
> 
> 
> 
> # Add the correct paths here:
> 
>  ac_add_options --with-android-ndk="$HOME/android-ndk-r8e"
> 
>  ac_add_options 
> --with-android-sdk="$HOME/adt-bundle-linux/sdk/platforms/android-16"
> 
> 
> 
>  # android options
> 
>  ac_add_options --enable-application=mobile/android
> 
>  ac_add_options --target=arm-linux-androideabi
> 
> 
> 
> Now when i Run first time :
> 
> 
> 
> Mozilla/src$ ./mach build
> 
> 
> 
> It process and setup some file and at end it say me re run  same command .
> 
> 
> 
> Now when i re run it it give below Error :
> 
> Mozilla/src$ ./mach build
> 
> /home/ubbvand2/Himanshu/Mozilla/src/python/psutil/psutil/_pslinux.py:108: 
> RuntimeWarning: couldn't determine platform's TOTAL_PHYMEM
> 
>   warnings.warn("couldn't determine platform's TOTAL_PHYMEM", RuntimeWarning)
> 
> Error running mach:
> 
> 
> 
> ['build']
> 
> 
> 
> The error occurred in code that was called by the mach command. This is either
> 
> a bug in the called code itself or in the way that mach is calling it.
> 
> 
> 
> You should consider filing a bug for this issue.
> 
> 
> 
> If filing a bug, please include the full output of mach, including this error
> 
> message.
> 
> 
> 
> The details of the failure are as follows:
> 
> 
> 
> AttributeError: 'module' object has no attribute 'get_sysinfo'
> 
> 
> 
>   File 
> "/home/ubbvand2/Himanshu/Mozilla/src/python/mozbuild/mozbuild/mach_commands.py",
>  line 287, in build
> 
> monitor.init(warnings_path)
> 
>   File 
> "/home/ubbvand2/Himanshu/Mozilla/src/python/mozbuild/mozbuild/controller/building.py",
>  line 161, in init
> 
> self.resources = SystemResourceMonitor(poll_interval=1.0)
> 
>   File 
> "/home/ubbvand2/Himanshu/Mozilla/src/testing/mozbase/mozsystemmonitor/mozsystemmonitor/resourcemonitor.py",
>  line 180, in __init__
> 
> virt = psutil.virtual_memory()
> 
>   File 
> "/home/ubbvand2/Himanshu/Mozilla/src/python/psutil/psutil/__init__.py", line 
> 1170, in virtual_memory
> 
> return _psplatform.virtual_memory()
> 
>   File 
> "/home/ubbvand2/Himanshu/Mozilla/src/python/psutil/psutil/_pslinux.py", line 
> 143, in virtual_memory
> 
> total, free, buffers, shared, _, _ = _psutil_linux.get_sysinfo()
> 
> 
> 
> I found solution here :https://bugzilla.mozilla.org/show_bug.cgi?id=930808#c5
> 
> 
> 
> But that seem does not work in my case .
> 
> My  python package for  python-psutil 1.2.1-1~ppa1 is installed.
> 
> 
> 
> 
> 
> Any help will be great to go further for me.

If any one have same issue like me then they can follow step like below .

1)sudo apt-get --purge remove python-psutil

2)sudo apt-get --purge autoremove

3)sudo apt-get update

4)Follow step from this link to install psutil-1.0.1.tar.gz  
https://bugzilla.mozilla.org/show_bug.cgi?id=908296

5) Unzip it and sudo -s

6)cd psutil
python setup.py install
python -c "import psutil; psutil.virtual_memory()"

make sure when you are running above two command you have root permission else 
it may be fail due to permission issue .

8) sudo -s

9)Mozilla /src/./mach build 

it is now working for me.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Disabling b2g reftests on mozilla-aurora and m-b2g26 & m-b2g28 (was Re: Disabling b2g reftests on the minis on trunk)

[Armen Zambrano G.]

Hello,
This week we will be disabling a handful of tests on m-b2g26 and m-b2g28
branches so we can fully move to run b2g reftests on the EC2 instances
[1] and disable the old mac minis.

The need to disable tests is due to the lack of lack of resources to
investigate those few tests on release branches. The tests will stay
active for trunk and mozilla-aurora.

This will allow us to be ready to finally get rid of the old mac minis
(talos-r3-fed-XXX and talos-r3-fed64-XXX).

If you have any questions or concerns reach us out through bug 818968.

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=818968#c106

regards,
Armen

On 2014-04-10, 6:36 PM, Armen Zambrano G. wrote:
> Hello,
> Due to bug 907770 we're going to disable b2g reftests on the trunk trees
> on the Mac Rev3 minis a week earlier. We will keep running b2g reftests
> on the EC2 instances.
> 
> The b2g reftests on EC2 having reliably green for several weeks already.
> 
> Next week we will disable the jobs on the minis for mozilla-aurora and
> mozilla-b2g26/28.
> 
> If you want the full details or add any comments please visit:
> https://bugzilla.mozilla.org/show_bug.cgi?id=994936
> 
> regards,
> Armen
> 


-- 
Zambrano Gasparnian, Armen (armenzg)
Mozilla Senior Release Engineer
https://mozillians.org/en-US/u/armenzg/
http://armenzg.blogspot.ca
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Recommendations on source control and code review

[Gavin Sharp]

On Sun, Apr 13, 2014 at 10:01 PM, Karl Tomlinson  wrote:
> Very often I've found that the intended approach changes during the
> life of a bug, and there is no clear summary in the bug of what
> eventually was done.  It is then necessary to go back through
> multiple revisions of the patch and associated comments and
> replies to find out the reasoning.  Add in the complexity of
> multiple changes in one bug, and having a single summary in one
> place would be very helpful, and is, when it is there.

Indeed, putting the rationale in the commit message helps ensure what
gets pushed is what gets explained, by removing one level of
indirection.

But if people aren't writing good Bugzilla comments now, they're
probably not going to write good commit messages either. So we need to
both make it easier and enforce it more consistently through the
review process.

Gavin
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Recommendations on source control and code review

[Boris Zbarsky]

On 4/14/14 5:13 AM, Aryeh Gregor wrote:

 But doesn't Mercurial hide all but the first line by
default in the places you'd normally look for it (e.g., log)?


The normal place I'd look for the detailed message is something like 
https://hg.mozilla.org/mozilla-central/rev/, which shows the 
full commit message.



It's unlikely that anyone will ever look.


The only time someone will look is if your code isn't doing what they 
think it should for whatever reason.  This is true for commit messages 
in general.


-Boris

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Recommendations on source control and code review

[smaug]

On 04/14/2014 12:42 AM, Robert O'Callahan wrote:

On Sat, Apr 12, 2014 at 8:29 AM, Gregory Szorc  wrote:


I came across the following articles on source control and code review:

* https://secure.phabricator.com/book/phabflavor/article/
recommendations_on_revision_control/
* https://secure.phabricator.com/book/phabflavor/article/
writing_reviewable_code/
* https://secure.phabricator.com/book/phabflavor/article/
recommendations_on_branching/

I think everyone working on Firefox should take the time to read them as
they prescribe what I perceive to be a very rational set of best practices
for working with large and complex code bases.

The articles were written by a (now former) Facebooker and the
recommendations are significantly influenced by Facebook's experiences.
They have many of the same problems we do (size and scale of code base,
hundreds of developers, etc). Some of the pieces on feature development
don't translate easily, but most of the content is relevant.

I would be thrilled if we started adopting some of the recommendations
such as more descriptive commit messages and many, smaller commits over
fewer, complex commits.



As a reviewer one of the first things I do when reviewing a big patch is to
see if I can suggest a reasonable way to split it into smaller patches.



As a reviewer I usually want to see _also_ a patch which contains all the 
changes.
Otherwise it can be very difficult to see the big picture.
But sure, having large patches split to smaller pieces may help.





Honestly, I think we're already pretty close to most of those
recommendations, most of the time. "More descriptive commit messages" is
the only recommendation there that is not commonly followed, as far as I
can see.


I always just use the link to the bug, so I haven't seen multiline comment 
useful at all.
Mostly they are just annoying, making logs harder to read.



-Olli




Rob



___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Is there any replacement for Domain Policy in CAPS ( Bug 913734 )

[xunxun]

Hi,

I noticed that Domain Policy in CAPS has been removed in 
https://bugzilla.mozilla.org/show_bug.cgi?id=913734, which means, we 
can't use the config capability.policy after 29.0


Is there any easy way to replace it (about:config)? ( Except 
installing NoScript )


Thanks.

--
Best Regards,
xunxun
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Is there any replacement for Domain Policy in CAPS ( Bug 913734 )

[Bobby Holley]

On Mon, Apr 14, 2014 at 10:38 AM, xunxun  wrote:,

> I noticed that Domain Policy in CAPS has been removed in
> https://bugzilla.mozilla.org/show_bug.cgi?id=913734, which means, we
> can't use the config capability.policy after 29.0
>

Correct.

> Is there any easy way to replace it (about:config)? ( Except
> installing NoScript )
>

What are you trying to do?

If you're trying to block script from running, there's a new API
(introduced in bug 840488, and currently used by NoScript).

If you're trying to grant extra privileges to certain web pages, you should
write a custom add-on with a page-mod content script. See the suggestion
here: https://bugzilla.mozilla.org/show_bug.cgi?id=995943#c5

bholley
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Is there any replacement for Domain Policy in CAPS ( Bug 913734 )

[xunxun]

于 2014/4/15 星期二 1:57, Bobby Holley 写道:
On Mon, Apr 14, 2014 at 10:38 AM, xunxun > wrote:,


I noticed that Domain Policy in CAPS has been removed in
https://bugzilla.mozilla.org/show_bug.cgi?id=913734, which means,
we can't use the config capability.policy after 29.0


Correct.

Is there any easy way to replace it (about:config)? ( Except
installing NoScript )


What are you trying to do?
I want to use a configurable way like 
https://developer.mozilla.org/en-US/docs/Midas/Security_preferences, 
which can solve some strange issues on a single js, NoScript is too big 
for the problem.


For example, I use the policy by default on my custom build:

|pref("capability.policy.policynames", "pcxnojs");|
|pref("capability.policy.pcxnojs.sites", "http://nsclick.baidu.com";);|
|pref("capability.policy.pcxnojs.javascript.enabled", "noAccess");|

|nsclick.baidu.com  |can cause firefox tab 
closing costs too much time, so I use the policy to avoid it.


If you're trying to block script from running, there's a new API 
(introduced in bug 840488, and currently used by NoScript).


If you're trying to grant extra privileges to certain web pages, you 
should write a custom add-on with a page-mod content script. See the 
suggestion here: https://bugzilla.mozilla.org/show_bug.cgi?id=995943#c5


bholley



--
Best Regards,
xunxun
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Recommendations on source control and code review

[Gregory Szorc]

On 4/14/14, 8:31 AM, Boris Zbarsky wrote:

On 4/14/14 5:13 AM, Aryeh Gregor wrote:

 But doesn't Mercurial hide all but the first line by
default in the places you'd normally look for it (e.g., log)?


The normal place I'd look for the detailed message is something like
https://hg.mozilla.org/mozilla-central/rev/, which shows the
full commit message.


Simple solution:

$ hg log -v

More advanced solution:

If the default output of `hg log` doesn't meet your fancy, it is fully 
customizable!


You can modify the "[ui] style" config option to define a custom "style 
file" to use. The style file holds a bunch of named templates that are 
used by various Mercurial commands. The default one is at [1] and should 
be installed as a "map-cmdline.default" file in your Mercurial install. 
If you want to display all lines of the commit message by default, copy 
that file and modify the "changeset" entry so "{desc|firstline}" is 
"{desc}" and update ui.style to reference the new file.


[1] 
http://selenic.com/repo/hg/file/76f68595ff8e/mercurial/templates/map-cmdline.default


___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Is there any replacement for Domain Policy in CAPS ( Bug 913734 )

[Bobby Holley]

On Mon, Apr 14, 2014 at 11:12 AM, xunxun  wrote:

> I want to use a configurable way like
> https://developer.mozilla.org/en-US/docs/Midas/Security_preferences,
> which can solve some strange issues on a single js, NoScript is too big for
> the problem.
>
> For example, I use the policy by default on my custom build:
>
> pref("capability.policy.policynames", "pcxnojs");
> pref("capability.policy.pcxnojs.sites", "http://nsclick.baidu.com";);
> pref("capability.policy.pcxnojs.javascript.enabled", "noAccess");
>
> nsclick.baidu.com can cause firefox tab closing costs too much time, so I
> use the policy to avoid it.
>

 NoScript has the capability to do exactly that. You're also welcome to
write an extension that uses the same API, though you should know that only
one extension may use the API at a given time (so your users would not be
able to install NoScript).

See the API here:
http://mxr.mozilla.org/mozilla-central/source/caps/idl/nsIScriptSecurityManager.idl#221
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

MemShrink Meeting - Tuesday, 15 April 2014 at 4:00pm PDT

[Jet Villegas]

The next MemShrink meeting will be brought to you by auto-minified javascript 
code in B2G chrome:
https://bugzilla.mozilla.org/show_bug.cgi?id=903149

The wiki page for this meeting is at:
   https://wiki.mozilla.org/Performance/MemShrink

Agenda:
* Prioritize unprioritized MemShrink bugs.
* Discuss how we measure progress.
* Discuss approaches to getting more data.

Meeting details:

* Tue, 15 April, 4:00 PM PDT
* http://arewemeetingyet.com/Los%20Angeles/2014-04-15/16:00/MemShrink%20Meeting
* Vidyo: Memshrink
* Dial-in Info:
   - In office or soft phone: extension 92
   - US/INTL: 650-903-0800 or 650-215-1282 then extension 92
   - Toll-free: 800-707-2533 then password 369
   - Conference num 98802
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Is XPath still a thing?

[Eric Shepherd]

I think I know the answer to this, but want to confirm: is XPath a 
going concern? We want to be sure of its current status before 
migrating its documentation to where it ought to be assuming that it is 
in fact something people still use.


--
Eric Shepherd
Developer Documentation Lead
Mozilla
Blog: http://www.bitstampede.com/
Twitter: @sheppy

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Is XPath still a thing?

[Anne van Kesteren]

On Mon, Apr 14, 2014 at 10:28 PM, Eric Shepherd  wrote:
> I think I know the answer to this, but want to confirm: is XPath a going
> concern? We want to be sure of its current status before migrating its
> documentation to where it ought to be assuming that it is in fact something
> people still use.

I don't think we should actively recommend it. We're maintaining the
existing code, but are not upgrading our level of support or anything.
And if we could get rid of the existing code, we would.


-- 
http://annevankesteren.nl/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Is XPath still a thing?

[David Burns]

On 14/04/2014 22:28, Eric Shepherd wrote:
I think I know the answer to this, but want to confirm: is XPath a 
going concern? We want to be sure of its current status before 
migrating its documentation to where it ought to be assuming that it 
is in fact something people still use.


XPath is still a going concern from where I stand. Web Testing people, 
who use Selenium WebDriver, use XPath extensively since they struggle to 
get to have testable documents. Having decent documentation for them 
would be awesome :)


David

P.S. Having a "native" implementation of XPath makes Selenium WebDriver 
a lot faster than say Internet Explorer which doesnt have a "native" 
implementation and relies on a JavaScript polyfill.


___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Is XPath still a thing?

[Eric Shepherd]

On 2014-04-14 21:38:24 +, David Burns said:

XPath is still a going concern from where I stand. Web Testing people, 
who use Selenium WebDriver, use XPath extensively since they struggle 
to get to have testable documents. Having decent documentation for them 
would be awesome :)


On 2014-04-14 21:38:20 +, Anne van Kesteren said:


I don't think we should actively recommend it. We're maintaining the
existing code, but are not upgrading our level of support or anything.
And if we could get rid of the existing code, we would.


Well, there's the expected yes/no answer I was looking for. My 
inclination is to go ahead and migrate the doc and keep it in the main 
body of our documentation content, but maybe with an added notice that 
support is limited yadda yadda yadda...


Any disagreements?

--
Eric Shepherd
Developer Documentation Lead
Mozilla
Blog: http://www.bitstampede.com/
Twitter: @sheppy

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Is XPath still a thing?

[David Burns]

Not from my side!

David

On 14/04/2014 22:41, Eric Shepherd wrote:

On 2014-04-14 21:38:24 +, David Burns said:

XPath is still a going concern from where I stand. Web Testing 
people, who use Selenium WebDriver, use XPath extensively since they 
struggle to get to have testable documents. Having decent 
documentation for them would be awesome :)


On 2014-04-14 21:38:20 +, Anne van Kesteren said:


I don't think we should actively recommend it. We're maintaining the
existing code, but are not upgrading our level of support or anything.
And if we could get rid of the existing code, we would.


Well, there's the expected yes/no answer I was looking for. My 
inclination is to go ahead and migrate the doc and keep it in the main 
body of our documentation content, but maybe with an added notice that 
support is limited yadda yadda yadda...


Any disagreements?



___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Is XPath still a thing?

[Jorge Villalobos]

On 4/14/14, 3:46 PM, David Burns wrote:
> Not from my side!
> 
> David
> 
> On 14/04/2014 22:41, Eric Shepherd wrote:
>> On 2014-04-14 21:38:24 +, David Burns said:
>>
>>> XPath is still a going concern from where I stand. Web Testing
>>> people, who use Selenium WebDriver, use XPath extensively since they
>>> struggle to get to have testable documents. Having decent
>>> documentation for them would be awesome :)
>>
>> On 2014-04-14 21:38:20 +, Anne van Kesteren said:
>>
>>> I don't think we should actively recommend it. We're maintaining the
>>> existing code, but are not upgrading our level of support or anything.
>>> And if we could get rid of the existing code, we would.
>>
>> Well, there's the expected yes/no answer I was looking for. My
>> inclination is to go ahead and migrate the doc and keep it in the main
>> body of our documentation content, but maybe with an added notice that
>> support is limited yadda yadda yadda...
>>
>> Any disagreements?
>>
> 

FWIW, many add-ons use XPath. If there's anything we should be
recommending add-on developers to migrate to, please let me know.

Jorge
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Oculus VR support & somehwat-non-free code in the tree

[Vladimir Vukicevic]

Hey all,

I have a prototype of VR display and sensor integration with the web, along 
with an implementation for the Oculus VR.  Despite there really being only one 
vendor right now, there is a lot of interest in VR.  I'd like to add the web 
and Firefox to that flurry of activity... especially given our successes and 
leadership position on games and asm.js.

I'd like to get this checked in so that we can either have it enabled by 
default in nightlies (and nightlies only), or at least allow it enabled via a 
pref.  However, there's one issue -- the LibOVR library has a 
not-fully-free-software license [1].  It's compatible with our licenses, but it 
is not fully "free".

There are a couple of paths forward, many of which can take place 
simultaneously.  I'd like to suggest that we do all of the following:

1. Check in the LibOVR sources as-is, in other-licenses/oculus.  Add a 
configure flag, maybe --disable-non-free, that disables building it.  Build and 
ship it as normal in our builds.

2. Contact Oculus with our concerns about the license, and see if they would be 
willing to relicense to something more standard.  The MPL might actually fit 
their needs pretty well, though we are effectively asking them to relicense 
their SDK code.  There is no specific driver for the OVR; it shows up as a USB 
HID device, and LibOVR knows how to interpret the data stream coming from it.  
This gets them easy compat with all operating systems, and the support I'd add 
would be for Windows, Mac, and Linux.

3. Start investigating "Open VR", with the intent being to replace the 
Oculus-specific library with a more standard one before we standardize and ship 
the API more broadly than to nightly users.

The goal would be to remove LibOVR before we ship (or keep it in assuming it 
gets relicensed, if appropriate), and replace it with a standard "Open VR" 
library.

There are a few other options that are worse:

1. We could ship the VR glue in nightly, but the Oculus support packaged as an 
addon.  This is doable, but it requires significant rework in changing the 
interfaces to use XPCOM, to do category-based registration of the Oculus 
provider, in building and packaging the addon, etc.  It also requires a 
separate install step for developers/users.

2. We could ship the VR integration as a plugin.  vr.js does this already.  But 
we are trying to move away from plugins, and there's no reason why the Oculus 
can't function in places where plugins are nonexistent, such as mobile.  
Delivering this to developers via a plugin would be admitting that we can't 
actually deliver innovative features without the plugin API, which is untrue 
and pretty silly.

3. Require developers to install the SDK themselves, and deploy it to all of 
the build machines so that we can build it.  This is IMO a very non-pargmatic 
option; it requires a ton more fragile work (everyone needs to get and keep the 
SDK updated; releng needs to do the same on build machines) and sacrifices 
developer engagement (additional SDKs suck -- see the DirectX SDK that we're 
working on eliminating the need for) in order to try to preserve some form of 
purity.

3. We do nothing.  This option won't happen: I'm tired of not having Gecko and 
Firefox at the forefront of web technology in all aspects.

Any objections to the above, or alternative suggestions?  This is a departure 
in our current license policy, but not a huge one.  There were some concerns 
expressed about that, but I'm hoping that we can take a pragmatic path here.

   - Vlad

[1] https://developer.oculusvr.com/license
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Enhancing product security with CSP for internal pages

[Neil]

Frederik Braun wrote:


A few months ago I had the idea to add a Content Security Policy (CSP) to our 
internal pages, like about:newtab for example.


So this just applies to about: pages?

--
Warning: May contain traces of nuts.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Is there any replacement for Domain Policy in CAPS ( Bug 913734 )

[Neil]

xunxun wrote:


For example, I use the policy by default on my custom build:

pref("capability.policy.policynames", "pcxnojs");
pref("capability.policy.pcxnojs.sites", "http://nsclick.baidu.com";);
pref("capability.policy.pcxnojs.javascript.enabled", "noAccess");

nsclick.baidu.com can cause firefox tab closing costs too much time, 
so I use the policy to avoid it.


Can you not use the content blocker to block scripts from 
nsclick.baidu.com? (I don't know what UI Firefox has for it, I normally 
use the Data Manager. I've successfully blocked Facebook and Twitter for 
example.)


--
Warning: May contain traces of nuts.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Is XPath still a thing?

[gNeandr]

On 14.04.2014 23:54, Jorge Villalobos wrote:

On 4/14/14, 3:46 PM, David Burns wrote:

Not from my side!

David

On 14/04/2014 22:41, Eric Shepherd wrote:

On 2014-04-14 21:38:24 +, David Burns said:


XPath is still a going concern from where I stand. Web Testing
people, who use Selenium WebDriver, use XPath extensively since they
struggle to get to have testable documents. Having decent
documentation for them would be awesome :)


On 2014-04-14 21:38:20 +, Anne van Kesteren said:


I don't think we should actively recommend it. We're maintaining the
existing code, but are not upgrading our level of support or anything.
And if we could get rid of the existing code, we would.


Well, there's the expected yes/no answer I was looking for. My
inclination is to go ahead and migrate the doc and keep it in the main
body of our documentation content, but maybe with an added notice that
support is limited yadda yadda yadda...

Any disagreements?





FWIW, many add-ons use XPath. If there's anything we should be
recommending add-on developers to migrate to, please let me know.

Jorge



With Reminderfox add-on (FX, TB and SM) we use XPath to aggregate and 
output calendar listing. That's a very flexible method and can be edited 
without XPI code change. Loosing XPath would disable Printing/Viewing of 
calendar details.

Which alternatives?

Guenter
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Oculus VR support & somehwat-non-free code in the tree

[Ralph Giles]

On 2014-04-14 3:41 PM, Vladimir Vukicevic wrote:

> 2. Contact Oculus with our concerns about the license, and see if they
would be willing to relicense to something more standard.

We should certainly ask, and explain what the problem is for us.

> The goal would be to remove LibOVR before we ship (or keep it in assuming it 
> gets relicensed, if appropriate), and replace it with a standard "Open VR" 
> library.

Can you dlopen the sdk, so it doesn't have to be in-tree? That still
leaves the problem of how to get it on a user's system, but perhaps an
add-on can do that part while the interface code in is-tree.

Finally, did you see Gerv's post at
http://blog.gerv.net/2014/03/mozilla-and-proprietary-software/

 -r

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Oculus VR support & somehwat-non-free code in the tree

[Mike Hommey]

On Mon, Apr 14, 2014 at 03:41:49PM -0700, Vladimir Vukicevic wrote:
> Hey all,
> 
> I have a prototype of VR display and sensor integration with the web,
> along with an implementation for the Oculus VR.  Despite there really
> being only one vendor right now, there is a lot of interest in VR.
> I'd like to add the web and Firefox to that flurry of activity...
> especially given our successes and leadership position on games and
> asm.js.
> 
> I'd like to get this checked in so that we can either have it enabled
> by default in nightlies (and nightlies only), or at least allow it
> enabled via a pref.  However, there's one issue -- the LibOVR library
> has a not-fully-free-software license [1].  It's compatible with our
> licenses, but it is not fully "free".
> 
> There are a couple of paths forward, many of which can take place
> simultaneously.  I'd like to suggest that we do all of the following:
> 
> 1. Check in the LibOVR sources as-is, in other-licenses/oculus.  Add a
> configure flag, maybe --disable-non-free, that disables building it.
> Build and ship it as normal in our builds.

Should be opt-in, not opt-out. And I don't think temporarily checking in
problematic source code is fine. See further below.

> 2. Contact Oculus with our concerns about the license, and see if they
> would be willing to relicense to something more standard.  The MPL
> might actually fit their needs pretty well, though we are effectively
> asking them to relicense their SDK code.  There is no specific driver
> for the OVR; it shows up as a USB HID device, and LibOVR knows how to
> interpret the data stream coming from it.  This gets them easy compat
> with all operating systems, and the support I'd add would be for
> Windows, Mac, and Linux.
> 
> 3. Start investigating "Open VR", with the intent being to replace the
> Oculus-specific library with a more standard one before we standardize
> and ship the API more broadly than to nightly users.
> 
> The goal would be to remove LibOVR before we ship (or keep it in
> assuming it gets relicensed, if appropriate), and replace it with a
> standard "Open VR" library.
> 
> There are a few other options that are worse:
> 
> 1. We could ship the VR glue in nightly, but the Oculus support
> packaged as an addon.  This is doable, but it requires significant
> rework in changing the interfaces to use XPCOM, to do category-based
> registration of the Oculus provider, in building and packaging the
> addon, etc.  It also requires a separate install step for
> developers/users.

You don't necessarily have to use XPCOM to make it an addon.

> 2. We could ship the VR integration as a plugin.  vr.js does this
> already.  But we are trying to move away from plugins, and there's no
> reason why the Oculus can't function in places where plugins are
> nonexistent, such as mobile.  Delivering this to developers via a
> plugin would be admitting that we can't actually deliver innovative
> features without the plugin API, which is untrue and pretty silly.
> 
> 3. Require developers to install the SDK themselves, and deploy it to
> all of the build machines so that we can build it.  This is IMO a very
> non-pargmatic option; it requires a ton more fragile work (everyone
> needs to get and keep the SDK updated; releng needs to do the same on
> build machines) and sacrifices developer engagement (additional SDKs
> suck -- see the DirectX SDK that we're working on eliminating the need
> for) in order to try to preserve some form of purity.

Arguably, the feature doesn't need to be enabled for every local build,
which implies not all developers need the SDK themselves. Only those
working on the feature. That still leaves the issue with the builders,
but we now can use tooltool almost everywhere (except non-desktop b2g
aiui) to "deploy" files on builders.

That being said, i'm not sure I'm comfortable with the implications of
your proposal. Balancing with the fact that VR sounds to me like a hype
that'll never see widespread use (it's not like there haven't been
attempts in the past), I'm not convinced it's worth being more than a
plugin/addon.

Mike
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Oculus VR support & somehwat-non-free code in the tree

[Vladimir Vukicevic]

On Monday, April 14, 2014 7:29:43 PM UTC-4, Ralph Giles wrote:
> > The goal would be to remove LibOVR before we ship (or keep it in assuming 
> > it gets relicensed, if appropriate), and replace it with a standard "Open 
> > VR" library.
> 
> Can you dlopen the sdk, so it doesn't have to be in-tree? That still
> leaves the problem of how to get it on a user's system, but perhaps an
> add-on can do that part while the interface code in is-tree.

Unfortunately, no -- the interface is all C++, and the headers are licensed 
under the same license.  A C layer could be written, but then we're back to 
having to ship it separately via addon or plugin anyway.

> Finally, did you see Gerv's post at
> 
> http://blog.gerv.net/2014/03/mozilla-and-proprietary-software/

Yes -- perhaps unsurprisingly, I disagree with Gerv on some of the particulars 
here.  Gerv's opinions are his own, and are not official Mozilla policy.  That 
post I'm sure came out of a discussion regarding this very issue here.  In 
particular, my stance is that we build open source software because we believe 
there is value in that, and that it is the best way to build innovative, 
secure, and meaningful software.  We don't build open source software for the 
sake of building open source.

- Vlad
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Oculus VR support & somehwat-non-free code in the tree

[Andreas Gal]

Vlad asked a specific question in the first email. Are we comfortable using 
another open (albeit not open enough for MPL) license on trunk while we rewrite 
the library? Can we compromise on trunk in order to innovate faster and only 
ship to GA once the code is MPL friendly via re-licensing or re-writing? What 
is our view on this narrow question?

Andreas

On Apr 14, 2014, at 5:35 PM, Vladimir Vukicevic  wrote:

> On Monday, April 14, 2014 7:29:43 PM UTC-4, Ralph Giles wrote:
>>> The goal would be to remove LibOVR before we ship (or keep it in assuming 
>>> it gets relicensed, if appropriate), and replace it with a standard "Open 
>>> VR" library.
>> 
>> Can you dlopen the sdk, so it doesn't have to be in-tree? That still
>> leaves the problem of how to get it on a user's system, but perhaps an
>> add-on can do that part while the interface code in is-tree.
> 
> Unfortunately, no -- the interface is all C++, and the headers are licensed 
> under the same license.  A C layer could be written, but then we're back to 
> having to ship it separately via addon or plugin anyway.
> 
>> Finally, did you see Gerv's post at
>> 
>> http://blog.gerv.net/2014/03/mozilla-and-proprietary-software/
> 
> Yes -- perhaps unsurprisingly, I disagree with Gerv on some of the 
> particulars here.  Gerv's opinions are his own, and are not official Mozilla 
> policy.  That post I'm sure came out of a discussion regarding this very 
> issue here.  In particular, my stance is that we build open source software 
> because we believe there is value in that, and that it is the best way to 
> build innovative, secure, and meaningful software.  We don't build open 
> source software for the sake of building open source.
> 
>- Vlad
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Oculus VR support & somehwat-non-free code in the tree

[Bobby Holley]

On Mon, Apr 14, 2014 at 9:47 PM, Andreas Gal  wrote:

> Vlad asked a specific question in the first email. Are we comfortable
> using another open (albeit not open enough for MPL) license on trunk while
> we rewrite the library? Can we compromise on trunk in order to innovate
> faster and only ship to GA once the code is MPL friendly via re-licensing
> or re-writing?
>

I'm for it.

bholley
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Oculus VR support & somehwat-non-free code in the tree

[Doug Turner]

+1 to breaking licensing dogma in favor of innovation + moving faster.

On Mon, Apr 14, 2014 at 9:55 PM, Bobby Holley  wrote:
> On Mon, Apr 14, 2014 at 9:47 PM, Andreas Gal  wrote:
>
>> Vlad asked a specific question in the first email. Are we comfortable
>> using another open (albeit not open enough for MPL) license on trunk while
>> we rewrite the library? Can we compromise on trunk in order to innovate
>> faster and only ship to GA once the code is MPL friendly via re-licensing
>> or re-writing?
>>
>
> I'm for it.
>
> bholley
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Oculus VR support & somehwat-non-free code in the tree

[Nick Alexander]

On 2014-04-14, 9:47 PM, Andreas Gal wrote:


Vlad asked a specific question in the first email. Are we comfortable using 
another open (albeit not open enough for MPL) license on trunk while we rewrite 
the library? Can we compromise on trunk in order to innovate faster and only 
ship to GA once the code is MPL friendly via re-licensing or re-writing? What 
is our view on this narrow question?


The idea that we will only "ship to GA once the code is MPL friendly via 
re-licensing or re-writing" sounds tricky in practice.  If including 
libovr has value, the incentive will be to ship, regardless of license. 
 (Personally, I am a VR skeptic.)  We could view this as an experiment: 
include libovr until it's dead weight or proven to be valuable enough to 
demand the resources to re-write it for GA.


We want to move faster and experiment more freely, and in tree has huge 
developer benefits, so my first impression is to include it, but I have 
a question. vlad said:


> The goal would be to remove LibOVR before we ship (or keep it in 
assuming it gets relicensed, if appropriate), and replace it with a 
standard "Open VR" library.


Can somebody save me some license reading and explain what the existing 
framework around shipping libovr is?  Is it explicitly allowed? 
Explicitly dis-allowed?  If I read gerv's post [1] correctly, it is 
allowed, but it's hard to distinguish gerv's opinion from Mozilla legal's.


Nick

[1] http://blog.gerv.net/2014/03/mozilla-and-proprietary-software/, in 
particular section 1B.

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Oculus VR support & somehwat-non-free code in the tree

[Nick Alexander]

1. Check in the LibOVR sources as-is, in other-licenses/oculus.  Add a
configure flag, maybe --disable-non-free, that disables building it.
Build and ship it as normal in our builds.


Should be opt-in, not opt-out.


+1

Nick
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform