Re: Proposed W3C Charter: Audio Working Group

[Tantek Çelik]

On Wed, Oct 26, 2016 at 7:25 PM, L. David Baron  wrote:
> On Friday 2016-10-21 15:01 -0700, Tantek Çelik wrote:
>> Support revised charter, with requested changes:
>> * Hyperlink the phrase "Community Group" in the charter to the
>> specific Community Group they mean, and perhaps title the hyperlink
>> more specifically as well.
>> * List the Community Group explicitly in the coordination section
>> http://www.w3.org/2011/audio/charter/audio-2016.html#coordination and
>> describe the relationship between the WG and the CG.
>
> So the only community group mention I can see in the charter is to
> say that work that is out of scope for the working group could
> instead occur in a community group (which I think means a
> hypothetical community group).  If that's the case, I don't think
> the second comment makes sense since the intent is that the material
> be out of scope for the working group.  It could be clearer that the
> community group is hypothetical, though.
>
> I'm inclined to submit the comment as:
>> One basically-editorial suggestion:
>>
>> Either:
>>
>> * Hyperlink the phrase "Community Group" in the charter to the
>> specific Community Group intended, and perhaps title the hyperlink
>> more specifically as well.
>>
>> * Or, if no such community group exists, make it clearer that it's
>> a hypothetical community group.
>
> (and record it as a support-with-optional-changes).

Yes, support with optional-changes, and how you've worded it works for me.

Thanks,

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

Re: Proposed W3C Charter: Audio Working Group

[L. David Baron]

On Friday 2016-10-21 15:01 -0700, Tantek Çelik wrote:
> Support revised charter, with requested changes:
> * Hyperlink the phrase "Community Group" in the charter to the
> specific Community Group they mean, and perhaps title the hyperlink
> more specifically as well.
> * List the Community Group explicitly in the coordination section
> http://www.w3.org/2011/audio/charter/audio-2016.html#coordination and
> describe the relationship between the WG and the CG.

So the only community group mention I can see in the charter is to
say that work that is out of scope for the working group could
instead occur in a community group (which I think means a
hypothetical community group).  If that's the case, I don't think
the second comment makes sense since the intent is that the material
be out of scope for the working group.  It could be clearer that the
community group is hypothetical, though.

I'm inclined to submit the comment as:
> One basically-editorial suggestion:
> 
> Either:
> 
> * Hyperlink the phrase "Community Group" in the charter to the
> specific Community Group intended, and perhaps title the hyperlink
> more specifically as well.
> 
> * Or, if no such community group exists, make it clearer that it's
> a hypothetical community group.

(and record it as a support-with-optional-changes).

-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: Intent to restrict to secure contexts: navigator.geolocation

[Matthew N.]

On Wed, Oct 26, 2016 at 4:26 PM, Jan-Ivar Bruaroey  wrote:

> On 10/26/16 6:28 PM, Matthew N. wrote:
>
>> On 2016-10-26 1:40 PM, Jan-Ivar Bruaroey wrote:
>>
>>> At the risk of sounding pragmatic/opportunistic, why not wait until the
>>> usage numbers go down, as they're bound to?
>>>
>>
>> And in the meantime we could remove the "always allow" option for
>> geolocation over HTTP like we do for another permission (WebRTC IIRC).
>>
>> Matthew
>>
>
> Good point. Mind filing a bug if there isn't one already?
>

​I filed ​
https://bugzilla.mozilla.org/show_bug.cgi?id=1313242
​​
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to restrict to secure contexts: navigator.geolocation

[Matthew N.]

On 2016-10-26 1:40 PM, Jan-Ivar Bruaroey wrote:

At the risk of sounding pragmatic/opportunistic, why not wait until the
usage numbers go down, as they're bound to?


And in the meantime we could remove the "always allow" option for 
geolocation over HTTP like we do for another permission (WebRTC IIRC).


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

New presentation of startup crashes on crash-stats

[Nicholas Nethercote]

Greetings,

The presentation of start-up crashes on crash-stats has improved
recently. If you look at the top crashes for Nightly
(https://crash-stats.mozilla.com/topcrashers/?product=Firefox=52.0a1=7)
you will see three different icons that are next to some crash
signatures: a rocket, a red flag, and a yellow flag. If you hover over
these you will see the following explanatory tool-tips.

- Rocket: "Potential Startup Crash, more than half of the crashes
happened during the first minute after launch". This icon has been
used for a long time and its meaning has not changed.

- Red flag: "Startup Crash, all crashes happened during startup". This
icon was added in
https://bugzilla.mozilla.org/show_bug.cgi?id=1297966. Its presence is
based on a new annotation in crash reports, called "StartupCrash",
which was added in
https://bugzilla.mozilla.org/show_bug.cgi?id=1295934 and landed in
Firefox 51. The annotation is initially set to 1 and then gets set to
zero once the browser reaches a certain point during start-up. This
annotation is only added in the chrome process. See the bug for more
details.

- Yellow flag: "Potential Startup Crash, M out of N crashes happened
during startup". This is similar to the red flag, but applied when not
all crashes have StartupCrash=1. It is never shown at the same time as
the red flag.

The rocket heuristic is fairly crude (e.g. it's affected by the speed
of your computer) and generous and so may include crashes that aren't
genuine start-up crashes; it also can only be applied to a group of
crashes, as opposed to a single crash.

The StartupCrash annotation has a much clearer meaning. It is also
stricter, and so quite a few crash signatures have the rocket icon but
neither flag icon. You can also view the StartupCrash annotation for
individual crashes and search for it.

The exact definition of "startup crash" isn't clear in general, so
some crashes that some people might consider "startup crashes" may not
get both a rocket icon and a flag icon. But if a crash signature has
the red flag icon, it meets a quite strict definition of "startup
crash", and should be prioritized accordingly. Also, crash signature
with a yellow flag icon and a high StartupCrash=1 proportion should be
considered similarly.

It's possible that the rocket icon will go away eventually. We are
currently evaluating the flag icons against the rocket icon to see how
they compare. Feedback is welcome. (For example, it just occurred to
me that the red vs. yellow distinction might be problematic for
colour-blind users.) Thank you.

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

Re: Intent to restrict to secure contexts: navigator.geolocation

[Jan-Ivar Bruaroey]

At the risk of sounding pragmatic/opportunistic, why not wait until the 
usage numbers go down, as they're bound to?


.: Jan-Ivar :.

On 10/25/16 7:10 PM, Karl Dubost wrote:

Interesting thread. Going back to the starting email:

Le 22 oct. 2016 à 04:49, Richard Barnes  a écrit :

Around 21% of these requests were (1) from "http:" origins, and
(2) granted by the user.  So the average rate of permissions being granted
to non-secure origins per pageload is 4.6M * 21% / 3B = 0.0319%.


Do we have the top 100 or top 1000 sites asking for geolocation on HTTP?
If not, what would be the best way to get these data?

Means and stats are maybe hiding more subtleties and could lead to a better 
informed decision on fixing this.
For example, hypothetically speaking if 90% of these 21% are made by 10 Web 
sites, it's a different issue than if there are made by 1 Web sites.


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

Re: Removing the Battery Status API?

[Chris Peterson]

On 10/26/2016 9:21 AM, Boris Zbarsky wrote:

So I decided to see what sites were doing with it.  I set a breakpoint
in getBattery() and tried browsing.  The first site I tried loading was
cnn.com, and it hit the breakpoint.  It's hitting it because it's using
the "boomerang" library from https://github.com/yahoo/boomerang (or one
of its various clones) as far as I can tell, and
https://github.com/yahoo/boomerang/blob/b70cb237c175debf1fda31ab9ae44e1cfa7996ca/plugins/memory.js#L177-L203
pokes at the battery API.  Looks like it reports the battery level as
part of its telemetry?  The original commit that introduces that is
https://github.com/yahoo/boomerang/commit/b0c41b144913338ea905f03fc28f32130c5521e5
which is not terribly informative as to _why_ that data is being collected.


Thanks, Boris. That's a great analysis.

Boomerang reporting users' battery levels, hardwareConcurrency, and 
maxTouchPoints sounds like active fingerprinting (what the library calls 
"beaconing"). Boomerang also extracts third-party tracking IDs from 
Google, Adobe, and IBM analytics cookies:


https://github.com/yahoo/boomerang/blob/b70cb237c175debf1fda31ab9ae44e1cfa7996ca/plugins/third-party-analytics.js


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

Re: Removing the Battery Status API?

[Boris Zbarsky]

On 10/26/16 3:30 AM, Chris Peterson wrote:

The BATTERY_STATUS_COUNT probe [4] reports over 200M battery API calls
for Firefox 49. The USE_COUNTER2_DEPRECATED_NavigatorBattery_PAGE probe
[5] reports that 6% of web pages use the Battery API, IIUC. That seems
surprisingly high given the few legitimate use cases. (Could that
counter be inadvertently triggered by web content that simply enumerates
the navigator object's properties without actually calling
navigator.getBattery()?)


In Firefox 49, the BATTERY_STATUS_COUNT thing counts actual calls to 
getBattery() _and_ calls to the .battery getter (it distinguishes the 
two, though); the latter would be affected by enumeration of Navigator 
but the former would not.  Also, it counts only the first call for the 
given document, which means that 200M number is NOT inflated by multiple 
per-page calls.


In particular, looking at the actual histogram, we have about 105M uses 
of navigator.battery and 116M uses of navigator.getBattery().  Out of 
how many loads?  See below.  Also, this may somewhat undercount 
getBattery() calls, because the way our telemetry code is written if the 
page does .battery before doing .getBattery() we will count the former 
but not the latter.  If the order is reversed we will count both.


The USE_COUNTER2_DEPRECATED_NavigatorBattery_PAGE counter counts gets of 
Navigator.battery and _would_ be affected by enumeration.  This attibute 
was removed in Firefox 50 (see 
https://bugzilla.mozilla.org/show_bug.cgi?id=1259335 which I'm pretty 
sure you knew about already ;) ).


The good news is that the deprecated counter lets us answer the "out of 
how many loads?" question, sort of.  The numbers above are out of 924 
million toplevel pageloads.  However, note that BATTERY_STATUS_COUNT 
counts per _document_, so can count multiple accesses per pageload when 
iframes are involved.


One way to reconcile the two sets of numbers is that the 105M 
_documents_ that use navigator.battery per the BATTERY_STATUS_COUNT 
counter corresponds to 57M _pageloads_ that use navigator.battery per 
the deprecated operation counter.  Assuming that this ratio holds for 
getBattery() (may not be a good assumption), that means about 6% of 
pageloads also end up using getBattery().  That does seem ludicrously high.


So I decided to see what sites were doing with it.  I set a breakpoint 
in getBattery() and tried browsing.  The first site I tried loading was 
cnn.com, and it hit the breakpoint.  It's hitting it because it's using 
the "boomerang" library from https://github.com/yahoo/boomerang (or one 
of its various clones) as far as I can tell, and 
https://github.com/yahoo/boomerang/blob/b70cb237c175debf1fda31ab9ae44e1cfa7996ca/plugins/memory.js#L177-L203 
pokes at the battery API.  Looks like it reports the battery level as 
part of its telemetry?  The original commit that introduces that is 
https://github.com/yahoo/boomerang/commit/b0c41b144913338ea905f03fc28f32130c5521e5 
which is not terribly informative as to _why_ that data is being collected.


Anyway, if that library is popular enough, that could account for a lot 
of the telemetry we see.  :(


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

Re: Intent to remove: nsIHTMLEditor.setDocumentTitle()

[Jörg Knobloch]

On 26/10/2016 09:50, Masayuki Nakano wrote:
nsIHTMLEditor.setDocumentTitle() is used only by Thunderbird, Mail and 
Composer of SeaMonkey. Additionally, they can set editable document 
title with |document.title = "foo";|. 


No problem. Thanks for the heads-up.

Already addressed in https://bugzilla.mozilla.org/show_bug.cgi?id=1313033

Jörg - Thunderbird Developer (Thunderbird, Compose and Mailnews Editor 
and MIME peer) - Member of the Thunderbird Council


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

Re: Removing the Battery Status API?

[Jonathan Kew]

On 26/10/2016 08:30, Chris Peterson wrote:

What is the use case for the Battery Status API [0],
navigator.getBattery()? Can we remove the Battery API or perhaps
restrict it to non-web content like browser extensions or privileged web
apps? Chrome and Firefox support the Battery API, but neither Edge nor
WebKit have signaled an intent to implement it [3].

In theory, web developers would use the Battery API to save document
data before the battery dies, to ease off heavy computation when the
battery is low, or to implement the Firefox OS settings app. The real
world use cases, however, seem to be fingerprinting users [1] and
inflating Uber prices for desperate users with low batteries [2].


Maybe it was just me, but I initially (mis)interpreted this as a claim 
that Uber does this. The article at [2], however, doesn't say that. It 
does suggest this -could- be done, but not that it -has- been; and the 
Uber representative is quoted as saying that "[w]e absolutely don’t use 
that...".


I imagine the negative publicity if a company like Uber were caught 
actually doing this -- which seems like it wouldn't be too hard for an 
investigative reporter to confirm -- could well outweigh any benefit 
they might hope to reap.


JK

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

Re: Removing the Battery Status API?

[Gijs Kruitbosch]

On 26/10/2016 08:54, Anne van Kesteren wrote:

On Wed, Oct 26, 2016 at 9:30 AM, Chris Peterson  wrote:

(Could that counter be
inadvertently triggered by web content that simply enumerates the navigator
object's properties without actually calling navigator.getBattery()?)


That seems unlikely given it's a method so enumerating would not
trigger any side effects.

(I support removal by the way. I tried to advocate for removal at some
point, but it didn't really go anywhere.)


Not that it matters much, but I would support removal so we get rid of 
this class of bugs: https://bugzilla.mozilla.org/show_bug.cgi?id=1274731 
, which is at least incidental evidence that "random" webpages use this 
API, likely for fingerprinting reasons (that is, I can't think of a 
"real" reason something like imgur.com would care about your battery).


Perhaps Andrea also has an opinion they would like to share, so CC'ing.

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

Re: Intent to restrict to secure contexts: navigator.geolocation

[Peter Dolanjski]

>
> On 10/25/2016 6:26 AM, Ehsan Akhgari wrote:
>
>> FWIW, and to the extent that my opinion matters on the topic, I strongly
>> disagree that breaking the websites that people use silently is the
>> right thing to do.
>>
>> Let's ignore the HTTPS Everywhere part of the thread, and instead pay
>> more attention to what our users will see after we roll this out.  It's
>> easy to ignore this when looking at the ratio of granted non-secure
>> geolocation prompts per all page loads, but we _are_ talking about
>> breaking a fifth of geolocations on the web for our users.
>>
>
> I strongly agree with Ehsan that breaking a fifth of geolocation requests
> is a bad user experience.


According to Richard's original link [1], there are significant differences
in results for different populations.  Yes, around 21% of the aggregate are
over http and granted by the user.  However, if you just look at OSX and
Linux users that number is 62%!

Breaking a fifth of geolocation requests that are granted/denied (not sure
if this data includes prompts that are not acted upon) doesn't sound
entirely unreasonable, but doing so likely affects certain types of users
(based on the sites they tend to visit) significantly more than the average.

Peter

[1] https://mzl.la/2eeoWm9

On Tue, Oct 25, 2016 at 12:51 PM, Chris Peterson 
wrote:

> On 10/25/2016 6:26 AM, Ehsan Akhgari wrote:
>
>> FWIW, and to the extent that my opinion matters on the topic, I strongly
>> disagree that breaking the websites that people use silently is the
>> right thing to do.
>>
>> Let's ignore the HTTPS Everywhere part of the thread, and instead pay
>> more attention to what our users will see after we roll this out.  It's
>> easy to ignore this when looking at the ratio of granted non-secure
>> geolocation prompts per all page loads, but we _are_ talking about
>> breaking a fifth of geolocations on the web for our users.
>>
>
> I strongly agree with Ehsan that breaking a fifth of geolocation requests
> is a bad user experience.
>
> What is the threat model for geolocation over HTTP? That a coffee shop,
> ISP, or Big Brother will MITM a non-secure site so as to sniff a user's
> location? To reduce location leaks without breaking non-secure geolocation,
> perhaps we could always require door hanger permission for geolocation
> requests on HTTP sites?
>
> chris
>
> ___
> 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: Proposed W3C Charter: Audio Working Group

[Paul Adenot]

We should support this new charter. 

We've been commenting, specifying and implementing both specs of this
Working Group (Although we've not shipped Web MIDI at the moment), and
we're participating very actively in the development of those standards
(V1.0 and V2.0 for Web Audio API, lighter involvement with Web MIDI).

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

Re: Removing the Battery Status API?

[Anne van Kesteren]

On Wed, Oct 26, 2016 at 9:30 AM, Chris Peterson  wrote:
> (Could that counter be
> inadvertently triggered by web content that simply enumerates the navigator
> object's properties without actually calling navigator.getBattery()?)

That seems unlikely given it's a method so enumerating would not
trigger any side effects.

(I support removal by the way. I tried to advocate for removal at some
point, but it didn't really go anywhere.)


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

Intent to remove: nsIHTMLEditor.setDocumentTitle()

[Masayuki Nakano]

nsIHTMLEditor.setDocumentTitle() is used only by Thunderbird, Mail and 
Composer of SeaMonkey.  Additionally, they can set editable document 
title with |document.title = "foo";|.


The only difference of a call of |nsIHTMLEditor.setDocumentTitle()| and 
|document.title = "foo";| is, nsIHTMLEditor.setDocumentTitle() makes the 
change undoable.


However, only for the method, we need to maintain 
mozilla::SetDocumentTitleTransaction class. Of course, I don't want to 
do that without some good reasons.


As I explained in bug 1312989 comment 0, I don't think that undoable 
document title change doesn't make sense for users. Therefore, I suggest 
to remove supporting undoable document title change in bug 1312989 and 
nsIHTMLEditor.setDocumentTitle() itself in bug 1312991.


https://bugzilla.mozilla.org/show_bug.cgi?id=1312989
https://bugzilla.mozilla.org/show_bug.cgi?id=1312991

Note that I don't want to do them in 52 because 52 will be the next ESR. 
So, I'd like to do them in 53.


--
Masayuki Nakano 
Manager, Internationalization, Mozilla Japan.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Removing the Battery Status API?

[Chris Peterson]

What is the use case for the Battery Status API [0], 
navigator.getBattery()? Can we remove the Battery API or perhaps 
restrict it to non-web content like browser extensions or privileged web 
apps? Chrome and Firefox support the Battery API, but neither Edge nor 
WebKit have signaled an intent to implement it [3].


In theory, web developers would use the Battery API to save document 
data before the battery dies, to ease off heavy computation when the 
battery is low, or to implement the Firefox OS settings app. The real 
world use cases, however, seem to be fingerprinting users [1] and 
inflating Uber prices for desperate users with low batteries [2]. Can 
anyone point to a real website using the Battery API for a legitimate 
purpose?


The BATTERY_STATUS_COUNT probe [4] reports over 200M battery API calls 
for Firefox 49. The USE_COUNTER2_DEPRECATED_NavigatorBattery_PAGE probe 
[5] reports that 6% of web pages use the Battery API, IIUC. That seems 
surprisingly high given the few legitimate use cases. (Could that 
counter be inadvertently triggered by web content that simply enumerates 
the navigator object's properties without actually calling 
navigator.getBattery()?)


I have a patch that makes the Battery API chrome-only and fixes the 
web-platform tests.


[0] https://developer.mozilla.org/en-US/docs/Web/API/Battery_Status_API
[1] 
http://randomwalker.info/publications/OpenWPM_1_million_site_tracking_measurement.pdf

[2] http://www.forbes.com/sites/amitchowdhry/2016/05/25/uber-low-battery/
[3] https://www.chromestatus.com/feature/4537134732017664
[4] https://mzl.la/2eDFvbR
[5] https://mzl.la/2eDG4Cj
[6] https://mzl.la/2eKcZ6d
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to restrict to secure contexts: navigator.geolocation

[Anne van Kesteren]

On Tue, Oct 25, 2016 at 8:24 PM, Aryeh Gregor  wrote:
> By that logic, we should not permit users to submit forms to non-HTTPS
> either.

And we are starting to flag pages that request passwords over
non-HTTPS: 
https://blog.mozilla.org/tanvi/2016/01/28/no-more-passwords-over-http-please/.
Baby steps.


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