Re: Enabling Pointer Events in Firefox (desktop) Nightly on Mac and Linux

[L. David Baron]

On Thursday 2017-04-06 00:33 -0400, Ehsan Akhgari wrote:
> In general, I should also say that designing features with
> fingerprinting in mind is *extremely* difficult and takes a lot of
> effort on the part of all browser vendors, which would be difficult to
> do effectively without some broad agreement that the extra effort spent
> is worth it.  WHATWG (in HTML at least) mostly treats this by
> documenting the exposed vectors
> .
>  I wonder what the position of the W3C TAG is?

That's actually a pretty easy question to answer:
https://www.w3.org/2001/tag/doc/unsanctioned-tracking/
(Unsanctioned Web Tracking, W3C TAG Finding 17 July 2015)

-David

-- 
턞   L. David Baron http://dbaron.org/   턂
턢   Mozilla  https://www.mozilla.org/   턂
 Before I built a wall I'd ask to know
 What I was walling in or walling out,
 And to whom I was like to give offense.
   - Robert Frost, Mending Wall (1914)


signature.asc
Description: PGP signature
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Enabling Pointer Events in Firefox (desktop) Nightly on Mac and Linux

[Ehsan Akhgari]

On 2017-04-05 5:44 PM, Tom Ritter wrote:
> On Wed, Apr 5, 2017 at 12:29 PM, Aryeh Gregor  wrote:
>> On Wed, Apr 5, 2017 at 7:34 PM, Tom Ritter  wrote:
>>> It looks like this exposes pointerType, which reveals whether the user
>>> is using a mouse, pen, or touch input.
>>>
>>> It also exposes detailed information about the geometry of the input
>>> (size of the thing pointing, pressure, tilt, twist.
>>>
>>> All of these are more detailed information that websites currently
>>> receiving, meaning that this can be used as a mechanism for
>>> fingerprinting (and tracking) users.
>>
>> I think this has been discussed here before, but I don't recall a firm
>> conclusion: has anyone established whether a nontrivial number of
>> users are non-fingerprintable as things stand?  If the vast majority
>> of users can be fingerprinted right now, and there are no realistic
>> plans to change that, it doesn't seem like we should care about
>> increasing fingerprinting ability.  I haven't investigated, but I'd be
>> surprised if there are a lot of users who can't be fingerprinted yet,
>> given the huge and rapidly-expanding number of features in the web
>> platform.
> 
> Firstly, this does not change the fact that this feature does have
> Privacy implications. This is the second 'Intent to Implement' I have
> replied to in the past two months that said "No Security or Privacy
> Implications" when there are in fact. This trend is disturbing.

This is the point of having this process.  :-)  Hopefully people will
start to think more about the implications of this in the future.  But
see below about fingerprinting.

> Besides that - the goal of anti-fingerprinting is not to make all
> users uniform, but rather to make it harder and harder to single
> individual users out. The more features we provide about users'
> configuration details (like mouse pointer size, type, functionality),
> the easier it is to single them out. For private browsing modes,
> ideally there would be a mapping or abstraction mechanism that covers
> a common denominator.
> 
> I'm not sure how much review this feature has had. In (my) ideal
> world, I think when we add a feature like this, the first question we
> would ask is "Why is this detailed information needed in the first
> place?" and if we have a compelling answer, we would follow it up with
> "Why can't we make this optional, so that it's either not exposed in
> privacy preserving modes or is only exposed in ways that represent
> user intention to release it?"  Perhaps these questions were already
> considered. But if no one thought this information was related to
> Privacy to begin with, my assumption is that they were not given
> serious weight.
> 
> Finally, Mozilla _is_ actively working on making users less
> fingerprintable. We're devoting resources to integrating
> anti-fingerprinting patches
> (https://wiki.mozilla.org/Security/Fingerprinting), which is the
> groundwork needed to expose the functionality to users (beyond
> individual pref flags). Obviously this is tricky - it's hard to put
> smoke back into bags once it's bet let out and relied upon all over
> the web (which is why it's so important to adequately consider things
> in Intent to X threads.). We're exploring options for this in
> https://bugzilla.mozilla.org/show_bug.cgi?id=1308340 but some ideas
> have been integrating with Private Browsing Mode and/or Tracking
> Protection.  Of course this presumes adequate research to measure
> breakage, etc etc - but my point is - we're not ignoring this problem
> and we do in fact care about it.

I agree that it would be nice to be proactive for hooking into
privacy.resistFingerprinting for features like this.  And I think we
should do that for this feature specifically but of course we need to
figure out the details of what to expose instead of the real info.

But what is our official policy towards fingerprinting in Gecko in the
face of the (now public knowledge) existence of attacks such as the HSTS
super cookie?  See

 I was under the impression that given that we already expose arbitrary
number of bits through the existing features of the Web platform, this
is a lost cause.  :/

In general, I should also say that designing features with
fingerprinting in mind is *extremely* difficult and takes a lot of
effort on the part of all browser vendors, which would be difficult to
do effectively without some broad agreement that the extra effort spent
is worth it.  WHATWG (in HTML at least) mostly treats this by
documenting the exposed vectors
.
 I wonder what the position of the W3C TAG is?

(FWIW, I don't think we should hold off enabling this feature on Nightly
for this discussion, I'm excited to see it happen!)

CodeCoverage Monthly Update

[Kyle Lahnakoski]

This is the second monthly update on our CodeCoverage effort:

## The Progress to Date

* Coverage is scheduled to run daily on central.
https://treeherder.mozilla.org/#/jobs?repo=mozilla-central=cov
* The UCOSP[1] students have completed their term, and can show
aggregate statistics by folder with the code coverage ui [5]
https://ericdesj.github.io/moz-coco-w17-preview/
* c/c++ coverage is being ETL'ed into our unified coverage datastore,
but does not yet show in the UI
* `grcov`[4] was written mcastelluccio to process coverage artifacts
much faster; reducing processing time from hours to
seconds. `grcov` also outputs multiple formats, including for coveralls.io
* There is exploration into using coveralls.io:
https://coveralls.io/jobs/24085087, the main page is
https://coveralls.io/github/marco-c/gecko-dev.
* JSVM coverage got working today!
https://treeherder.mozilla.org/#/jobs?repo=try=ce2c56eeceb1bc252c6b25a50304f725c320d5e0


## The Blockers

These items are further behind than I would like.  If you can help,
please do.

* Getting Rust to emit coverage artifacts is important:
https://bugzilla.mozilla.org/show_bug.cgi?id=1335518
* Continuing the hard work of enabling C/C++ codecoverage on all our
tests: https://bugzilla.mozilla.org/show_bug.cgi?id=1301170

## The Biggest Problem

**Our test suites are unstable**. Many of you may already know that many
tests fail intermittently; these "intermittents" impact code coverage;
either by breaking the test run, and preventing coverage collection; or
by changing code paths. The challenge is automating the metatdata
collection and having a strategy to mitigate the loss of data. [8]
https://bugzilla.mozilla.org/show_bug.cgi?id=1337241

Even so, **test runs are not deterministic**, so we expect fluctuation
in the aggregate coverage statistics; How large this fluctuation is we
do not know.

Got ideas?  You want to work on a problem that no one will thank you
for?  ;)  Please talk to me! [3]

## The Current Plan

For the next month we will be continuing work on:

* validating the data and process, including adding Rust and more test
suites.
* Adding per-line coverage to the CoCo UI: The aggregate numbers are
good for identifying sections of code that are not tested, but we need
line-level details to inform action.
https://github.com/mozilla/moz-coco/issues/7
* Explore how coveralls.io can be used to make that job easier  
* Explore how to leverage Taskcluster-generated coverage artifacts with
local coverage tools [9]
https://bugzilla.mozilla.org/show_bug.cgi?id=1350446
* We are investigating if coverage tools behave differently when e10s is
enabled, then enabling it.
* JSVM ETL pipeline work will commence:
https://bugzilla.mozilla.org/show_bug.cgi?id=1301174


## Motivation

*Unchanged from last email* - Knowing code coverage statistics and code
coverage specifics can help evaluate risk in code: It can show what test
suites cover what lines, it can show if new code is covered by an
existing test.  There are many other exciting insights we can extract
from code coverage. But first, we must collect it.

## Reference

[1] UCOSP (Undergraduate Capstone Open Source Projects) http://ucosp.ca/

[2] The original plan:
https://docs.google.com/document/d/1dOWi18qrudwaOThNAYoCMS3e9LzhxGUiMLLrQ_WVR9w/edit#

[3] Kyle Lahnakoski email: klahnako...@mozilla.org  irc: ekyle on
#at...@irc.mozilla.org

[4] grcov https://github.com/marco-c/grcov

[5] (Co)de (Co)verage UI preview -
https://ericdesj.github.io/moz-coco-w17-preview/

[5b] CoCo is on Github - https://github.com/mozilla/moz-coco

[6] CoCo relay - https://github.com/ericdesj/moz-coco-relay

[7] Rust Coverage Tracking
https://bugzilla.mozilla.org/show_bug.cgi?id=1335518

[8] Knowing when the coverage is complete:
https://bugzilla.mozilla.org/show_bug.cgi?id=1337241

[9] Coverage with local tools:
https://bugzilla.mozilla.org/show_bug.cgi?id=1350446
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Rationalising Linux audio backend support

[Chris Coulson]

On 05/04/17 19:38, Henri Sivonen wrote:
> On Mar 31, 2017 4:49 PM, "Chris Coulson" 
> wrote:
>
> The Firefox package in Ubuntu is maintained by 1 contributor in his
> spare time and myself who is only able to do the minimum in order to
> provide updates,
>
>
> Does today’s announcement of Ubuntu’s change in direction affect resourcing
> for Firefox packaging?
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
I don't have the answer to that right now.

- Chris



signature.asc
Description: OpenPGP digital signature
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Enabling Pointer Events in Firefox (desktop) Nightly on Mac and Linux

[Tom Ritter]

On Wed, Apr 5, 2017 at 12:29 PM, Aryeh Gregor  wrote:
> On Wed, Apr 5, 2017 at 7:34 PM, Tom Ritter  wrote:
>> It looks like this exposes pointerType, which reveals whether the user
>> is using a mouse, pen, or touch input.
>>
>> It also exposes detailed information about the geometry of the input
>> (size of the thing pointing, pressure, tilt, twist.
>>
>> All of these are more detailed information that websites currently
>> receiving, meaning that this can be used as a mechanism for
>> fingerprinting (and tracking) users.
>
> I think this has been discussed here before, but I don't recall a firm
> conclusion: has anyone established whether a nontrivial number of
> users are non-fingerprintable as things stand?  If the vast majority
> of users can be fingerprinted right now, and there are no realistic
> plans to change that, it doesn't seem like we should care about
> increasing fingerprinting ability.  I haven't investigated, but I'd be
> surprised if there are a lot of users who can't be fingerprinted yet,
> given the huge and rapidly-expanding number of features in the web
> platform.

Firstly, this does not change the fact that this feature does have
Privacy implications. This is the second 'Intent to Implement' I have
replied to in the past two months that said "No Security or Privacy
Implications" when there are in fact. This trend is disturbing.

Besides that - the goal of anti-fingerprinting is not to make all
users uniform, but rather to make it harder and harder to single
individual users out. The more features we provide about users'
configuration details (like mouse pointer size, type, functionality),
the easier it is to single them out. For private browsing modes,
ideally there would be a mapping or abstraction mechanism that covers
a common denominator.

I'm not sure how much review this feature has had. In (my) ideal
world, I think when we add a feature like this, the first question we
would ask is "Why is this detailed information needed in the first
place?" and if we have a compelling answer, we would follow it up with
"Why can't we make this optional, so that it's either not exposed in
privacy preserving modes or is only exposed in ways that represent
user intention to release it?"  Perhaps these questions were already
considered. But if no one thought this information was related to
Privacy to begin with, my assumption is that they were not given
serious weight.

Finally, Mozilla _is_ actively working on making users less
fingerprintable. We're devoting resources to integrating
anti-fingerprinting patches
(https://wiki.mozilla.org/Security/Fingerprinting), which is the
groundwork needed to expose the functionality to users (beyond
individual pref flags). Obviously this is tricky - it's hard to put
smoke back into bags once it's bet let out and relied upon all over
the web (which is why it's so important to adequately consider things
in Intent to X threads.). We're exploring options for this in
https://bugzilla.mozilla.org/show_bug.cgi?id=1308340 but some ideas
have been integrating with Private Browsing Mode and/or Tracking
Protection.  Of course this presumes adequate research to measure
breakage, etc etc - but my point is - we're not ignoring this problem
and we do in fact care about it.

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

Re: Intent to ship: IntersectionObserver API

[Jet Villegas]

Thanks, Tobias. If all goes well, please request uplift to FF 54 for
this after a few days in Nightly 55 to unblock bugs like:
https://bugzilla.mozilla.org/show_bug.cgi?id=1131937#c28

--Jet

On Wed, Apr 5, 2017 at 2:21 PM, Tobias Schneider  wrote:
> Out final experiment on 100% of our Nightly user population just finished.
> We enabled the API for 110605 users. Out of that we only had 2 reported
> crashes related to the Intersection Observer API. Both were causes by
> Add-ons using the API in XUL documents. We  already addressed this issue in
> https://bugzilla.mozilla.org/show_bug.cgi?id=1353529. I think its safe to
> go ahead and finally enabling this feature by default.
>
> On Fri, Mar 24, 2017 at 7:32 AM, Tobias Schneider 
> wrote:
>
>> We just successfully run another experiment, enabling the
>> IntersectionObserver API for 50% of our Nightly user population. No related
>> stability issues reported. Also, find a Gecko profile using an Intersection
>> Observer per element (109192 total) on the single page version of the HTML5
>> spec here: https://www.dropbox.com/s/cm55ixrvk7bqaxu/
>> SinglePageHTML5SpecIntersectionObserver.sps.json.zip?dl=0.
>>
>> On Thu, Mar 16, 2017 at 1:52 AM, Patrick Brosset 
>> wrote:
>>
>>> >
>>> > 1)  Is there devtools support for this (e.g. to be able to see what
>>> > intersection observers are registered where)?  If not, are there at
>>> least
>>> > bugs tracking it?
>>>
>>>
>>> I filed https://bugzilla.mozilla.org/show_bug.cgi?id=1347849 for this.
>>> MutationObserver would be a good one to add support for too!
>>>
>>> On Thu, Mar 16, 2017 at 8:39 AM, Anne van Kesteren 
>>> wrote:
>>>
>>> > On Wed, Mar 15, 2017 at 7:38 PM, Boris Zbarsky 
>>> wrote:
>>> > > On 3/15/17 1:32 PM, Tobias Schneider wrote:
>>> > >> 2.3) Platform tests are in the process of being upstreamed by Google
>>> (
>>> > >> https://github.com/w3c/web-platform-tests/pull/4384).
>>> > >
>>> > > That seems to be in limbo for well over a month now.  jgraham just
>>> poked
>>> > it
>>> > > in hopes of at least getting automated testing going so we find out
>>> > whether
>>> > > Firefox passes the tests... but that will test release, afaik. Have
>>> you
>>> > > checked whether we pass these tests?
>>> >
>>> > They would be run against Nightly.
>>> >
>>> >
>>> > --
>>> > https://annevankesteren.nl/
>>> > ___
>>> > 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
>>>
>>
>>
> ___
> 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: Intent to ship: IntersectionObserver API

[Tobias Schneider]

Out final experiment on 100% of our Nightly user population just finished.
We enabled the API for 110605 users. Out of that we only had 2 reported
crashes related to the Intersection Observer API. Both were causes by
Add-ons using the API in XUL documents. We  already addressed this issue in
https://bugzilla.mozilla.org/show_bug.cgi?id=1353529. I think its safe to
go ahead and finally enabling this feature by default.

On Fri, Mar 24, 2017 at 7:32 AM, Tobias Schneider 
wrote:

> We just successfully run another experiment, enabling the
> IntersectionObserver API for 50% of our Nightly user population. No related
> stability issues reported. Also, find a Gecko profile using an Intersection
> Observer per element (109192 total) on the single page version of the HTML5
> spec here: https://www.dropbox.com/s/cm55ixrvk7bqaxu/
> SinglePageHTML5SpecIntersectionObserver.sps.json.zip?dl=0.
>
> On Thu, Mar 16, 2017 at 1:52 AM, Patrick Brosset 
> wrote:
>
>> >
>> > 1)  Is there devtools support for this (e.g. to be able to see what
>> > intersection observers are registered where)?  If not, are there at
>> least
>> > bugs tracking it?
>>
>>
>> I filed https://bugzilla.mozilla.org/show_bug.cgi?id=1347849 for this.
>> MutationObserver would be a good one to add support for too!
>>
>> On Thu, Mar 16, 2017 at 8:39 AM, Anne van Kesteren 
>> wrote:
>>
>> > On Wed, Mar 15, 2017 at 7:38 PM, Boris Zbarsky 
>> wrote:
>> > > On 3/15/17 1:32 PM, Tobias Schneider wrote:
>> > >> 2.3) Platform tests are in the process of being upstreamed by Google
>> (
>> > >> https://github.com/w3c/web-platform-tests/pull/4384).
>> > >
>> > > That seems to be in limbo for well over a month now.  jgraham just
>> poked
>> > it
>> > > in hopes of at least getting automated testing going so we find out
>> > whether
>> > > Firefox passes the tests... but that will test release, afaik. Have
>> you
>> > > checked whether we pass these tests?
>> >
>> > They would be run against Nightly.
>> >
>> >
>> > --
>> > https://annevankesteren.nl/
>> > ___
>> > 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
>>
>
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to change editor newline behavior

[Daniel Veditz]

On Wed, Apr 5, 2017 at 7:14 AM, Aryeh Gregor  wrote:

> > really help.  :-(  But to me it seems like the kind of thing that we'd
> > want to be able to quickly turn off on the release channel through
> > shipping a hotfix add-on that sets a pref if something goes wrong...
>
> FWIW, changing the default back to  is a one-line change already.
>

​One line or a thousand isn't the point; building, release and update
testing, and shipping 90 locales times 6 platforms​ is a huge amount work.
If we have a pref and break something we can back it out easily and
quickly. We could even do a slow roll-out independent of a release if we're
extra concerned about compat (as we have done with e10s and sha1
deprecation, for example).

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

Re: Rationalising Linux audio backend support

[Henri Sivonen]

On Mar 31, 2017 4:49 PM, "Chris Coulson" 
wrote:

The Firefox package in Ubuntu is maintained by 1 contributor in his
spare time and myself who is only able to do the minimum in order to
provide updates,


Does today’s announcement of Ubuntu’s change in direction affect resourcing
for Firefox packaging?
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Changing the behavior for inheriting the Security Context of data: URLs

[Bobby Holley]

Really glad to hear that this is getting close - thanks for working on this
stuff!

On Wed, Apr 5, 2017 at 1:59 AM, Christoph Kerschbaumer <
christ...@christophkerschbaumer.com> wrote:

> Hey everyone,
>
> we are in the process of changing the handling of data: URLs to which user
> agents navigate. Rather than inheriting the origin of the settings object
> responsible for the navigation, they will be treated as unique, opaque
> origins. In other words that means that data: URLs loaded inside an iframe
> are not same-origin with their including context anymore. (Other browsers
> are already doing that). Overall progress of the project will be tracked
> here [1].
>
> Important when adding new tests:
> At the moment we are updating our test suite to align with this new
> security inheritance model. Please do *not* add new tests that rely on the
> old security inheritance model. If in doubt, please flip the pref
> security.data_uri.inherit_security_context [2] to make sure your test
> succeeds before landing on inbound.
>
> Cheers,
>   Christoph
>
> [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1324406 <
> https://bugzilla.mozilla.org/show_bug.cgi?id=1324406> - Treat 'data:'
> documents as unique, opaque origins
> [2] https://hg.mozilla.org/mozilla-central/rev/c11fe7c58837#l1.14 <
> https://hg.mozilla.org/mozilla-central/rev/c11fe7c58837#l1.14>
>
> ___
> 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: Enabling Pointer Events in Firefox (desktop) Nightly on Mac and Linux

[Aryeh Gregor]

On Wed, Apr 5, 2017 at 7:34 PM, Tom Ritter  wrote:
> It looks like this exposes pointerType, which reveals whether the user
> is using a mouse, pen, or touch input.
>
> It also exposes detailed information about the geometry of the input
> (size of the thing pointing, pressure, tilt, twist.
>
> All of these are more detailed information that websites currently
> receiving, meaning that this can be used as a mechanism for
> fingerprinting (and tracking) users.

I think this has been discussed here before, but I don't recall a firm
conclusion: has anyone established whether a nontrivial number of
users are non-fingerprintable as things stand?  If the vast majority
of users can be fingerprinted right now, and there are no realistic
plans to change that, it doesn't seem like we should care about
increasing fingerprinting ability.  I haven't investigated, but I'd be
surprised if there are a lot of users who can't be fingerprinted yet,
given the huge and rapidly-expanding number of features in the web
platform.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to change editor newline behavior

[Mike Taylor]

On 4/4/17 7:12 PM, Ehsan Akhgari wrote:

We should also notify the Web Compatibility team.  CCing Mike Taylor as
proxy.  :-)


Thanks -- I've let the team know to be on the lookout for new editor-ish 
bugs.


--
Mike Taylor
Web Compat, Mozilla
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Enabling Pointer Events in Firefox (desktop) Nightly on Mac and Linux

[Tom Ritter]

On Tue, Apr 4, 2017 at 10:29 PM,   wrote:
> Security & Privacy Concerns: none

It looks like this exposes pointerType, which reveals whether the user
is using a mouse, pen, or touch input.

It also exposes detailed information about the geometry of the input
(size of the thing pointing, pressure, tilt, twist.

All of these are more detailed information that websites currently
receiving, meaning that this can be used as a mechanism for
fingerprinting (and tracking) users.

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

Re: Intent to change editor newline behavior

[Boris Zbarsky]

On 4/5/17 10:14 AM, Aryeh Gregor wrote:

On Wed, Apr 5, 2017 at 4:48 PM, Ehsan Akhgari  wrote:

But to me it seems like the kind of thing that we'd
want to be able to quickly turn off on the release channel through
shipping a hotfix add-on that sets a pref if something goes wrong...


FWIW, changing the default back to  is a one-line change already.


The difference is that a hotfix addon does not involve people restarting 
their browser to pick up an update, don't involve creating a new 
release, etc, etc.


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

Changing the behavior for inheriting the Security Context of data: URLs

[Christoph Kerschbaumer]

Hey everyone,

we are in the process of changing the handling of data: URLs to which user 
agents navigate. Rather than inheriting the origin of the settings object 
responsible for the navigation, they will be treated as unique, opaque origins. 
In other words that means that data: URLs loaded inside an iframe are not 
same-origin with their including context anymore. (Other browsers are already 
doing that). Overall progress of the project will be tracked here [1].

Important when adding new tests:
At the moment we are updating our test suite to align with this new security 
inheritance model. Please do *not* add new tests that rely on the old security 
inheritance model. If in doubt, please flip the pref 
security.data_uri.inherit_security_context [2] to make sure your test succeeds 
before landing on inbound.

Cheers,
  Christoph

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1324406 
 - Treat 'data:' 
documents as unique, opaque origins
[2] https://hg.mozilla.org/mozilla-central/rev/c11fe7c58837#l1.14 


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

Re: Intent to change editor newline behavior

[Aryeh Gregor]

On Wed, Apr 5, 2017 at 4:48 PM, Ehsan Akhgari  wrote:
> Originally it seemed that you are working under the assumption that most
> sites are overriding our default newline handling behavior.  This is
> very easy to measure through telemetry by adding a probe for example
> that looks when an HTML editor object is destroyed whether the
> defaultParagraphSeparator command was used to override our default
> behavior, you can send a value of 0 for the false case and a value of 1
> for the true case and we can get a percentage of pages where this
> override actually happens on based on this data.

I think I wasn't clear.  By "overriding" I meant that when the user
presses Enter, they intercept the keystroke and modify the DOM
themselves, and the editor code is never invoked.  I didn't mean that
the sites alter defaultParagraphSeparator.  So we could add a probe
that detects when the editor's Enter-handling code is run at all.

>> If it's not so low, however, we'd need
>> to look at the actual sites to see if they break.  Can we do that
>> somehow through telemetry, or is it a privacy problem?
>
> Detecting the actual breakage that can happen is much more difficult in
> code because you would need to first define what the breakage would
> result in to try to detect it in code which is extremely difficult in
> this case.

If we had a list of top sites that used our Enter-handling code, we
could test them manually.  (But such testing would be unlikely to be
comprehensive.)

> Getting the kind of data I'm suggesting above _now_ that the patch is
> landed seems rather pointless.  There seems to be a lot of disagreement
> on the degree of the risk involved in this change in the first place,
> and until we agree on the level of risk arguing about the details like
> this may be pointless.

It's not pointless if we pref it only to Aurora, and leave it there
until we have more data.

> At the end of the day, this is Masayuki's call.  I certainly understand
> that in the past with changes like this we've had a lot of difficulty
> detecting regressions before the patches have hit the release channel,
> so I'm not sure how much keeping the patch on pre-release channels would
> really help.  :-(  But to me it seems like the kind of thing that we'd
> want to be able to quickly turn off on the release channel through
> shipping a hotfix add-on that sets a pref if something goes wrong...

FWIW, changing the default back to  is a one-line change already.

> Perhaps I'm missing something about the nature of what changed here.
> How is this seldom used?  Am I misunderstanding that the change happened
> was how *Gecko* reacts to the user pressing Enter by default in a
> contenteditable section?  It's true that some editing widgets override
> this behavior somehow, but I'd be really shocked if that's true 100% of
> the time, so I don't understand how you argue this is a seldom used
> feature...

Yes, I do mean that AFAIK high-profile editing frameworks do override
this kind of behavior.  Johannes Wilm seems to be the founder of the
"Fidus Writer" editor project, and when I asked "Do editors all
override hitting Return, Backspace, etc.?" he said "Those involve
taking apart and merging paragraphs, so I cannot really imagine how
one would create an editor without doing that. At the very least one
will need to monitor what the browser does and then adjust if needed."
   The
second sentence is what we have to worry about, though.

One thing I know for sure is, when I looked into it several years ago,
execCommand() usage among high-profile editors seemed to be
nonexistent.  Once you're writing all the code yourself to handle
styling and block formatting and so on, overriding the behavior for
hitting Enter is a no-brainer.

It wouldn't be hard to test whether various sites use our built-in
linebreak behavior when the user hits Enter.  Just put a printf in the
relevant function and see if it gets hit.  Maybe I'll do that.

> I guess I'm personally coming from the perspective of having bitten by
> regressing various things about the editor behavior too many times in
> the past, and every time it happened, we could make an argument about
> how it's extremely unlikely to happen beforehand.  :-)

Yes, on reconsideration, I expect some fallout.  Phasing this in more
cautiously seems like a good idea to me.  I think it might be best to
just leave it in Aurora and Beta for longer than usual before
promoting it.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to change editor newline behavior

[Ehsan Akhgari]

On 2017-04-05 7:27 AM, Aryeh Gregor wrote:
> On Wed, Apr 5, 2017 at 3:12 AM, Ehsan Akhgari  wrote:
>> Exactly.  We can hypothesize either way, but we certainly can't know easily
>> without getting some data first.  But unfortunately it's not possible to
>> collect data about what sites are doing in terms of DOM fix-ups like this.
>> We can, at least, collect data about whether they are overriding the newline
>> behavior wholesale though.  Is there any reason why we should not at least
>> first collect this data before changing the behavior here?
> 
> What exact data would you want?  We could collect data on how often
> our built-in newline behavior is used, and if it's low enough we'd be
> confident the change is safe.

Originally it seemed that you are working under the assumption that most
sites are overriding our default newline handling behavior.  This is
very easy to measure through telemetry by adding a probe for example
that looks when an HTML editor object is destroyed whether the
defaultParagraphSeparator command was used to override our default
behavior, you can send a value of 0 for the false case and a value of 1
for the true case and we can get a percentage of pages where this
override actually happens on based on this data.

> If it's not so low, however, we'd need
> to look at the actual sites to see if they break.  Can we do that
> somehow through telemetry, or is it a privacy problem?

Detecting the actual breakage that can happen is much more difficult in
code because you would need to first define what the breakage would
result in to try to detect it in code which is extremely difficult in
this case.

> If someone has suggestions for the exact telemetry probe to use here,
> I'm happy to add one, and maybe keep the change in Aurora until we get
> data to make a decision.  I'm not familiar enough with telemetry
> (either the theoretical options or our implementation) to decide what
> the right probe is.

Getting the kind of data I'm suggesting above _now_ that the patch is
landed seems rather pointless.  There seems to be a lot of disagreement
on the degree of the risk involved in this change in the first place,
and until we agree on the level of risk arguing about the details like
this may be pointless.

At the end of the day, this is Masayuki's call.  I certainly understand
that in the past with changes like this we've had a lot of difficulty
detecting regressions before the patches have hit the release channel,
so I'm not sure how much keeping the patch on pre-release channels would
really help.  :-(  But to me it seems like the kind of thing that we'd
want to be able to quickly turn off on the release channel through
shipping a hotfix add-on that sets a pref if something goes wrong...

> On Wed, Apr 5, 2017 at 3:31 AM, Benjamin Smedberg  
> wrote:
>> I agree that it doesn't seem likely that telemetry can answer this sort of
>> question. However, we could collect data! Pick N top editing tools and
>> actually test their behavior. We probably can't get full confidence, but we
>> can get a much better picture of the risk involved. If we break (or
>> significantly change behavior) on five sites out of 40, that's a strong
>> indicator that we're going to have problems.
>>
>> As an example, have we already tested or is it in a plan to test:
>> google docs
>> basic and rich text editors on wikipedia
>> office 365
>> github editor
>> common rich text editor libraries, and common CRM software (I don't have a
>> list)
>> the top hosted email sites: gmail, yahoo, hotmail/outlook, aol, icloud,
>> yandex
>>
>> Being able to assert, before landing this change, that it doesn't break any
>> of these sites, would really help in terms of making assertions about the
>> risk profile.
> 
> I did not test this specific change on those sites.  However, some
> years ago I did research execCommand() usage on the web, and found
> that high-profile richtext editors essentially didn't use it, because
> of browser incompatibilities.  Instead, they wrote their own
> functions.  The same incompatibilities exist in newline behavior, so
> it's reasonable to say that they would write their own functions for
> that too.
> 
> This is also supported by a discussion I had with a couple of
> developers of major richtext editing libraries (I don't remember which
> offhand).  They said that changes like this make no difference to
> them, because they don't use the functionality anyway.  They're
> interested in fixes in things like selection handling, which they do
> use, and features that allow them to more easily override browser
> behavior.
> 
> Also anecdotally, in terms of dealing with editor bugs like this --
> the reports most often come from Thunderbird.  Maybe Ehsan or Masayuki
> could weigh in too, but I think that we get very few bug reports in
> these parts of the editor from real-world websites.  (We do get some
> reports in other parts of the editor, like 

Re: Intent to change editor newline behavior

[Aryeh Gregor]

On Wed, Apr 5, 2017 at 3:12 AM, Ehsan Akhgari  wrote:
> Exactly.  We can hypothesize either way, but we certainly can't know easily
> without getting some data first.  But unfortunately it's not possible to
> collect data about what sites are doing in terms of DOM fix-ups like this.
> We can, at least, collect data about whether they are overriding the newline
> behavior wholesale though.  Is there any reason why we should not at least
> first collect this data before changing the behavior here?

What exact data would you want?  We could collect data on how often
our built-in newline behavior is used, and if it's low enough we'd be
confident the change is safe.  If it's not so low, however, we'd need
to look at the actual sites to see if they break.  Can we do that
somehow through telemetry, or is it a privacy problem?

If someone has suggestions for the exact telemetry probe to use here,
I'm happy to add one, and maybe keep the change in Aurora until we get
data to make a decision.  I'm not familiar enough with telemetry
(either the theoretical options or our implementation) to decide what
the right probe is.

On Wed, Apr 5, 2017 at 3:31 AM, Benjamin Smedberg  wrote:
> I agree that it doesn't seem likely that telemetry can answer this sort of
> question. However, we could collect data! Pick N top editing tools and
> actually test their behavior. We probably can't get full confidence, but we
> can get a much better picture of the risk involved. If we break (or
> significantly change behavior) on five sites out of 40, that's a strong
> indicator that we're going to have problems.
>
> As an example, have we already tested or is it in a plan to test:
> google docs
> basic and rich text editors on wikipedia
> office 365
> github editor
> common rich text editor libraries, and common CRM software (I don't have a
> list)
> the top hosted email sites: gmail, yahoo, hotmail/outlook, aol, icloud,
> yandex
>
> Being able to assert, before landing this change, that it doesn't break any
> of these sites, would really help in terms of making assertions about the
> risk profile.

I did not test this specific change on those sites.  However, some
years ago I did research execCommand() usage on the web, and found
that high-profile richtext editors essentially didn't use it, because
of browser incompatibilities.  Instead, they wrote their own
functions.  The same incompatibilities exist in newline behavior, so
it's reasonable to say that they would write their own functions for
that too.

This is also supported by a discussion I had with a couple of
developers of major richtext editing libraries (I don't remember which
offhand).  They said that changes like this make no difference to
them, because they don't use the functionality anyway.  They're
interested in fixes in things like selection handling, which they do
use, and features that allow them to more easily override browser
behavior.

Also anecdotally, in terms of dealing with editor bugs like this --
the reports most often come from Thunderbird.  Maybe Ehsan or Masayuki
could weigh in too, but I think that we get very few bug reports in
these parts of the editor from real-world websites.  (We do get some
reports in other parts of the editor, like selection/focus handling.)
This also suggests websites aren't actually using this code much.
(Although maybe it means they just work around our bugs already.)

In fact, I dropped this patch set for a while because the feature is
seldom-used enough on the web that it doesn't seem worth fixing.  I
get the impression that Ehsan shares this point of view.

It's also worth noting that contenteditable is a very complicated
feature to use in real life, particularly given browser
incompatibilities, and I think almost all sites that use it are either
very large or use one of the major rich-text editing libraries.  If
I'm correct, then we don't have to worry so much about breaking a long
tail of small sites that won't get reported quickly.  If Gmail,
Wikipedia, TinyMCE, etc. break, we (or they) are likely to get reports
soon enough.  Large sites are also usually well-maintained and do
their own testing, and will fix the issue quickly.  (But if a library
breaks, or software like MediaWiki, there will be a long tail of old
sites that will remain broken even after the library is fixed, because
they keep using old versions of the library.)

So that's my reasoning for why I don't think this is *so* risky.  But
I agree that I don't really know.  As I said, I'd be happy to let this
stay on Aurora or beta for longer, and/or add some telemetry (if
someone tells me what telemetry we want).
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

[MozReview] Request to Review fix for the bug 1353460

[Utkarsh Anand]

Here's the link to the review request showing the diff:
https://reviewboard.mozilla.org/r/126582/diff/1#index_header
Here's a link to the bug: https://bugzilla.mozilla.org/
show_bug.cgi?id=1353460
Description: Rust is not installed via package manager by default on fedora
25 when using bootstrap. bootstrap manually installs it and prepends the
appropriate path to PATH. But it requires us to start a new shell window in
order to build, say, firefox. It won't detect rust compiler otherwise. So,
I decided to add rust to the list of packages being installed. Can someone
please review it and make the change permanent?
Regards,
Utkarsh Anand
___

Github: http://www.github.com/utkarsh009
LinkedIN profile: https://www.linkedin.com/in/utkarsh-anand-02a953115/
Blogs: bumblebeesky.blogspot.com , micromax-mmx-310g.blogspot.com
-BEGIN PGP PUBLIC KEY BLOCK-
Version: GnuPG v2

mQENBFjBXnMBCADNZuwqZzijCTbyO12P9/Ws3BcUzjr7CD2AT0WFwwOByX2RO4yc
naYNfPC8wZ5iC9JEuazKuFiyODyhmQQ71icrNgHJZXb+F9WO303artjp+ic+msQ2
wHyNkcggc3BW9kybJIB/x/zkoK5zeH0mBQEK3q0HfwDHcDh0dRNQIUdAXauvoBkC
P5KfeKPOcCgYrE3IM6x52lLNQYFC5j0R3U22+IwsAVKPALcK09M0aI++L/mIe+bt
/GT1rwjEVTkbFLGMEzP706ljiFTNAMIp/ybt6Pe7O7iLe6OrqIkJtaSEqRf7JtpF
ezTnbpsaQKVJC2hjuyRgM2A4GJI/lExkooz5ABEBAAG0OFV0a2Fyc2ggQW5hbmQg
KFRoaXMgaXMgbXkga2V5IF5fXikgPHVhbmFuZDAwOUBnbWFpbC5jb20+iQE3BBMB
CAAhBQJYwV5zAhsDBQsJCAcCBhUICQoLAgQWAgMBAh4BAheAAAoJEJbmYduHTMg/
ig0IAJ4Y3uaut+WeJvXUyLUYvXTGI7tett1huNctZg2fQzgzUDA8Qf+038YatPxB
6zY0fAnswAzjSH0ty0g7mHfKTGojFaiLFTBHJNOPUFwXPSQbClnra6CcKa9meRjV
m+23uUP9C3brF8lF3NRzvCHmbxAq83wMxHEVmb+4FNI1vH0IaxPneQuqDsIGQ+6p
nHdiKYh2ETcBRP1nCzfw+NPL6o10TumGoY6PN6z+RHkSyvDMcjzGbsFPjX4uXCz/
vJcuXyVwdmF5vfxmWFSlQ1Z5uZuX9k+ObUe+WrVSrzKC3NMT/NR6/ZQE5ocmnsjt
Qx42w3PTVNYgqIFTB8yejQYXzbq5AQ0EWMFecwEIAOYHR238r22z6weL/vAwqek0
9Q21JF6zLvKwaWzOBgDeug8dKaIDbg+I7I3WIKYAFt+d6qMsz8XhebIFASI1fWuN
iRbuDmpt1iRkvDZYR7MY5zlFYj1QYkjqYMP63Tqojniz6Gx7L/D1VOfeMtkpjt9E
eKLzUrj6sX/x5Lriy2o/qFDKz/LkUE9G7XNmqg6NOJST9MvfsG2CwBSUDWGEccQC
dnAV6G/5ywVgNQ1gzOOk8rDxUcb3/rw82+nJLnrdG6QRpD2R9VKqFW2MybnFUMjI
JOqFZwYwTw2de1mWrZTDA+vQjtMMY9KV1O/+p89lLKAke73QTfCCL6eLCo0ATRUA
EQEAAYkBHwQYAQgACQUCWMFecwIbDAAKCRCW5mHbh0zIP2FIB/9lnJh0+a+YL6O8
xh6O38HkTfVrwQg8ySCQCrvGGu/gLE2c4VxDYnTASxdfCu5v+8d0ADt7YnkqtxXm
o7dpKlgpmDuFYYc3DYHNXXn7vq5sTIPI6zh5squvsCDEsjqbaj39Qsf225eZSPTp
mgDQ+ATaaQ750QJ2OWt7IiNBXLHR5AqrxxFbwFHKNZCY7NgCsGZifAeZDuqQ+khh
maPYe0VMZTw/D9zPDFTfQ9vGIOV803ESLXeeUThrudyjkcUCdWzY0CRdQUv/tOMy
OoCbeb9I+IMLQl5cTFG7WxKYediUKx7cdBBXRd33CIcHdO2c7ia8D9M2nEZqG57b
Xo7Em3Tp
=aSGy
-END PGP PUBLIC KEY BLOCK-
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform