Re: Triage Plan for Firefox Components

[Chris Hofmann]

You might be able to create views into these triage queue's with
combinations of existing keywords and maybe a few added ones.  For example:

Can reproduce
Can others reproduce the problem described?

has the inverse represented by needs-testcase for example.  In the case of
the bug that needed nurturing people like alice white descend on piles of
bugs that need test cases, to then find regression ranges and and apply
techniques to build test cases.  We need to re-enforce that kind of process
and maybe give people like that another keyword like "has-testcase" so
engineers with domain knowledge can descend on that set of bugs.

Then

   Why it's important
What makes this problem important or urgent to fix?

combinations of keywords like "regression", "losing-users",
"sec-[critial/high] and other keywords plus some consistent priority
setting could offer good summations of different categories of important
bugs to stay on top of.

With constant triage its now possible to find good piles of bugs that have
test cases, are regressions, have been determined to be critical and are
"assigned to nob...@mozilla.org" then with these its possible to reset
organizational priorities and individual assignments.   All that happens
but in clumsy ways.  A good first step is to take dbaron's list of things
that need to be understood, see of we have existing markings that represent
or would help lead to understanding those aspects and formalize a bit of
process around that.   The regression keyword is one that get pretty good
use, but it still doesn't reflect the kinds of ways in which regressions
have been determined to be critical or are ok with just ignoring or pushing
out to some future date or never.   The platform triage is very focused on
trying to do just that.

-chofmann

On Thu, Apr 7, 2016 at 3:22 PM, Emma Humphries  wrote:

> First: there's that Bugzilla Anthropology project (
> https://wiki.mozilla.org/Bugzilla_Anthropology) thanks. I'd heard mention
> of it and asked around.
>
> What we found during the pilot, and the Platform Team has found in their
> triage, is that list of bugs with needinfo? is
>
> I'm worried that multiple queues in a component would be adding
> complexity, but this is something I'm willing experiment with.
>
> I don't think that picking a component or group of components we could try
> that style of triage on would block implementing the Triaged:Yes|No flag
> and UX improvements in Bugzilla.
>
> Would you be up for helping me run a short pilot of the multi-queue system
> you're describing?
>
> -- Emma
>
>
> On Wed, Apr 6, 2016 at 11:50 PM, L. David Baron  wrote:
>
>> On Wednesday 2016-04-06 18:47 -0700, Emma Humphries wrote:
>> > Following up on yesterday's email: I put together a draft second
>> proposal
>> > and shopped it around some, and now I want to bring that back into the
>> main
>> > discussion.
>> >
>> > The bullet point version of this is:
>> >
>> > * Add a binary field that components can use, TRIAGED (Y/N, T/F, +,-)
>> > * In the case of Firefox related components, have a consistent
>> definition
>> > of P1-P5 and make sure that triaged bugs have a Priority assigned
>>
>> > > On Tue, Mar 29, 2016 at 1:07 PM, Emma Humphries 
>> wrote:
>> > >> Today I’m asking for feedback on the plan which is posted at:
>> > >>
>> > >>
>> > >>
>> https://docs.google.com/document/d/1FFrtS0u6gNBE1mxsGJA9JLseJ_U6tW-1NJvHMq551ko
>>
>> I'm assuming the above URL represents the current proposal, although
>> given the "draft second proposal" wording above, I'm not sure if
>> that's the case.
>>
>>
>> I don't think the idea that a bug belongs in the triage queue if it
>> is untriaged and without a needinfo? is the right process.  I think,
>> instead, that there should be less emphasis on needinfo? to a
>> specific person, and more emphasis on grouping bugs into a small
>> number of categories of information that is needed, and allowing
>> people to triage those separate queues.
>>
>> Explaining why I think that requires a little bit of a digression:
>>
>> There are a number of separate things we want to understand in a bug
>> report, as I described in http://dbaron.org/log/20120816-bug-system :
>>
>> Understand description
>> Do the developers or triagers reading the bug understand
>> what the reporter is saying?
>>
>> Agree it's a bug
>> Do the module owners or peers or other authority agree that
>> the problem is a bug?
>>
>> Can reproduce
>> Can others reproduce the problem described?
>>
>> Why it's important
>> What makes this problem important or urgent to fix?
>>
>> How to fix
>> What should be done to fix the problem?
>>
>> (I'd much rather a bug report be editable text, with history
>> available, for answers to these or similar questions -- rather than
>> a stream of permanent comments.  But we seem stuck with the horrid
>> 

Re: Triage Plan for Firefox Components

[Chris Hofmann]

re: Determining answers to any or all of the above might require
 multiple rounds of dialog, and some of them need to be understood in
 sequence rather than in parallel.  They also require very different
 sets of expertise to determine.

Yes!  We should set up systems and process and skills that encourage and
allow teams to "nuture" bugs, and get the answers to these questions.

Going into bug triage with the idea that primary and most important goal is
to get regression bugs "off the list", and to make (snap/quick) decisions
works against the process of finding important regressions, finding them
fast, and getting them fixed before we ship; which should be the main
reason we are doing all this work.

https://bugzilla.mozilla.org/show_bug.cgi?id=1249083 is an example.  seems
too bizarre to be an important or widespread problem, so ->works for me.
almost left for dead.  then resurrected and tied to an important problem
and fix.  bugs can often linger in these early stages for quite some time
before progress can be made, but we need to keep revisiting and keep trying
for breakthroughs in the information the dbaron lists.

Once the diagnosis gets better, the problems become more clear, then the
fixes can progress; often with great speed.

Streamline bugzilla to do these things and constantly remind all
participants that this is what we are trying to do.

-chofmann



> There are a number of separate things we want to understand in a bug
> report, as I described in http://dbaron.org/log/20120816-bug-system :
>
> Understand description
> Do the developers or triagers reading the bug understand
> what the reporter is saying?
>
> Agree it's a bug
> Do the module owners or peers or other authority agree that
> the problem is a bug?
>
> Can reproduce
> Can others reproduce the problem described?
>
> Why it's important
> What makes this problem important or urgent to fix?
>
> How to fix
> What should be done to fix the problem?
>
>
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Firefox Hello new data collection

[Chris Hofmann]

On Mon, Apr 4, 2016 at 3:01 AM, Romain Testard  wrote:

>
> Firefox Hello has its own privacy notice (details here
> ).
>
>
Its unclear to me reading the follow through link to the
TokBox Privacy Policy.  ->  https://tokbox.com/support/privacy-policy

Does TokBox already have access to the contents of the messages and URLs
that might have been shared?

the tokbox policy says:

The types of information collected include your name, e-mail address, and
any other data you actively choose to provide.

and leaves it vague about the definition of "other data you actively
provide."   Does that include shared URLs and message content?

Thie passage in https://www.mozilla.org/en-US/privacy/firefox-hello/ also
would lead me to believe that the contents of my communication with another
user (including shared URLs) are encrypted (and would be private).

We've just invested heavily in making this point and trying to make that
association that encryption mean strong privacy and vice-versa.
https://blog.mozilla.org/blog/2016/03/30/everyday-internet-users-can-stand-up-for-encryption-heres-how/

How are we going to address the possible take away that some will have that
we've just created a backdoor for parts (shared urls that are part of the
message content) of the hello encrypted message channel if we turn this
change on?
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Firefox Hello new data collection

[Chris Hofmann]

On Mon, Apr 4, 2016 at 1:35 PM, Ian Bicking  wrote:

> On Mon, Apr 4, 2016 at 10:44 AM, Gijs Kruitbosch  >
> wrote:
>
>   I put some comments about data bias against international users
and the .edu domains and possible data leaks that could result directly in
the bug.


> >
> > We looked into this approach originally although we found that we'd lose
> a
> >>>
> >> level of granularity that can have an importance. We may find that Hello
> >> gets used a lot with a specific Website for a specific reason and using
> >> client side categories would prevent us from learning this.
> >>
> >
> > This was explicitly not in your original motivation, so you're moving the
> > goalposts here. If the goal is about separate categories or separate
> sites
> > then those are pretty distinct goals that require different approaches.
> If
> > the real point is "we have no idea, so we figured we'd just get the data
> > and then go from there", why not be upfront about it?
>
>
> We are looking for clues about how people are using Hello, and using
> domains as one way to understand this.  So yes, it is exploratory, and we
> are looking for insight we have not yet received, rather than a more binary
> signal such as do people use Hello for shopping or not.
>
> For example, two domains that are on the whitelist: steampowered.com and
> steamcommunity.com – these would both typically be categorized as
> "gaming",
> but they represent very different use cases (store vs. discussion).  Or
> aa.com, tripadvisor.com, and expedia.com are all travel sites, but
> represent different (but overlapping) use cases.
>
> But in that case, yeah, why not consider a survey or something less
> > intrusive, like asking people explicitly what type of site they were
> using,
> > or asking if Mozilla can use the domain in question ?
>
>
> Asking people what site they were using seems challenging.


Yeah, but if it's the intent to gather insight around how people are, or
could use hello for shared browsing that seems an indirect and possibly
error prone set of data to gather with out context of what users are trying
to accomplish.


> Do we suggest
> types?  Will people acknowledge the full path of sites they used?  How much
> do we have to annoy people with questions in order to get a large enough
> sample?  Will it ever be a representative sample?  Even if we do work to
> address these, how can we tell if we have done so if we don't have real
> usage data to compare to?
>

Simply ask users what type of task they are trying to accomplish.

Maybe give them a set of hints about the standard things that people do
on-line.

With that you could start to understand some interesting use cases that
hello could be made to address in a better way, or some possible use cases
that might be in confilict and may need multiple approaches to support.
(e.g. your game playing against v. shopping together use case)

You really don't want to know particular sites people visit, you want to
understand what it is they are trying to accomplish, right?

>
> As fully implemented, including the backend collection which further
> aggregates the information, I believe we are not collecting private or
> personally revealing information.  If we ask users to opt-in to collection
> I don't think we can accurately explain to users the limits of what we are
> collecting (especially at that moment when we are interrupting what they
> are doing), and I think it will make it appear that we are trying to
> collect personal information that we are not.
>

Yes, its easy to understand and believe that its our intention not to
collect personal information.

But that intention avoids the underlying question about if browsing history
is personal data, or is consider by our users to be such.

As it's been said in the past,  the road to leaking user personal data is
paved with good intentions.

The survey approach gets us a more direct path to the data we need for
designing a better co-browsing experience or experiences, since we really
would never really design a feature against a particular site or URL, but
are really looking for a common behavior pattern that lends itself to
streamlining across many sites and application.


>
>
> >
> > Also Alexa
> >> website categories are far from perfect which would add another level of
> >> complexity to understand the collected data.
> >>
> >
> > At no point did I say I expected you to use their categorization,
> whatever
> > that is. Categorize as you see fit, rather than as Alexa does it.
> >
> > Conversely, if their categorization is questionable, then your scrubbing
> > of the Adult category sounds like it might need auditing? Also, why not
> > other categories like "Banking" or "Medical" (NB: no idea what
> > categorization Alexa employs, but these seem like categories that ought
> to
> > be scrubbed, too)?
> >
>
> For filtering out adult sites we used a well-maintained blacklist.  Alexa
> categorization 

Re: Firefox Hello new data collection

[Chris Hofmann]

It also seems like you haven't explored other alternatives to get the data
you are after, have some theories around what results you might expect, and
what possible out comes will be pursed once you get the data.

Have you looked at other studies like this and many more that tell about
general browsing habits?
http://www.adweek.com/socialtimes/online-time/463670

Have you looked at just doing a simple survey to ask people to tell you
what kinds of activities they most use when sharing sites with hello?

If the survey or data collection results tell you that some people play
games against each other  *and* some people shop together what will you do
then?

-chofmann

On Mon, Apr 4, 2016 at 3:01 AM, Romain Testard  wrote:

> The privacy review bug is
> https://bugzilla.mozilla.org/show_bug.cgi?id=1261467.
> More details added below.
>
> On Mon, Apr 4, 2016 at 11:23 AM, Gijs Kruitbosch  >
> wrote:
>
> > Hi,
> >
> > It's very concerning to me that you have not answered the obvious
> > question: what domains are collected? All of the ones visited while the
> > browser is running? The ones visited while Hello is open? The ones
> visited
> > while shared through Hello? What about the ones that someone shared with
> > you through Hello, rather than that you shared with someone else?
> >
>
> We only collect domains browsed whilst sharing your tabs on Firefox Hello
> (link generator side).
>
> >
> > What about Private Browsing mode, have you disabled collection there?
>
>
> Firefox Hello cannot be used with private browsing mode.
>
> >
> >
> > On 04/04/2016 10:01, Romain Testard wrote:
> >
> >> We would use a whitelist client-side to only collect domains that
> are
> >> part of the top 2000 domains (Alexa list of top domains). This
> >> prevents
> >> personal identification based on obscure domain usage.
> >>
> >
> > Mathematically, the combination of a set of (popular) domains shared
> could
> > still be uniquely identifying, especially as, AIUI, you will get the
> counts
> > of each domain and in what sequence they were visited / which ones were
> > visited in which session. It all depends on the number of unique users
> and
> > the number of domains they visit / share (not clear: see above). Because
> > the total number of Hello users compared with the number of Firefox users
> > is quite low, this still seems somewhat concerning to me. Have you tried
> to
> > remedy this in any way?
> >
>
> We are aggregating domain names, and are not storing session histories.
> These are submitted at the end of the session, so exact timestamps of any
> visit are not included.
>
> The beginning of your message mentioned that you were interested in
> > different "types" of sites. I don't think it would be necessary to
> optimize
> > Hello for one shopping site over another, or for one search engine over
> > another, or for one news site over another. So, why don't you categorize
> > the domains in the whitelist according to broad categories ("news",
> > "search", "shopping", "games", or something like this) on the client
> side,
> > and then send that information instead? If the set of domains is limited
> > (which it is) then this should not take that long, and get you exactly
> the
> > information you want, and limit the privacy invasion that the current
> > collection scheme represents.
> >
> > We looked into this approach originally although we found that we'd lose
> a
> level of granularity that can have an importance. We may find that Hello
> gets used a lot with a specific Website for a specific reason and using
> client side categories would prevent us from learning this. Also Alexa
> website categories are far from perfect which would add another level of
> complexity to understand the collected data.
>
>
> > 6 months also seems incredibly long. You should be able to aggregate the
> > data and keep that ("60% of users share on sites of type X") and throw
> away
> > the raw data much sooner than that.
> >
> Yes agreed, we'll look into what's the most optimal amount of time required
> to process the data and extract the useful information. I agree we should
> try to make this shorter - we'll learn from being on Beta and will adjust
> this accordingly.
>
> >
> > Finally, I am surprised that you're sharing this 2 weeks before we're
> > releasing Firefox 46. Hasn't this been tested and verified on Nightly
> > and/or other channels? Why was no privacy update made at/before that
> time?
> >
>
> We are shipping Hello through Go Faster. The Go Faster process allows us to
> uplift directly to Beta 46 directly since we're a system add-on
> (development was done about 2 weeks ago).
> Firefox Hello has its own privacy notice (details here
> ).
>
> >
> > ~ Gijs
> > ___
> > dev-platform mailing list
> > dev-platform@lists.mozilla.org
> > 

Re: Intent to deprecate: MacOS 10.6-10.8 support

[Chris Hofmann]

On Fri, Mar 11, 2016 at 9:20 AM, Benjamin Smedberg 
wrote:

>
>
> On 3/10/2016 5:25 PM, Mike Hommey wrote:
>
>>
>> It's unfair to mention those populations by percentage of the global
>> Firefox population.
>>
>
> Why do you think this is unfair? This is about making the best use of our
> limited engineering/testing/QA resources, and so what really matters is the
> total impact, not just the impact relative to the mac population.
>

The reason for considering benefits of populations relative to their own OS
are because there are two kinds of things we get out of platform support.

One is greater impact resulting from a higher overall number of users.

The other is other strategic benefits we get out of platform support like
on Linux where user numbers are low, but gecko and firefox tootling and
testing developer contributions are relatively high.

For Mac there is a possible web dev connection that's of possible strategic
value with higher concentration of web devs on that platfor that help keep
sites working well for large numbers of others.



>
> Dolske answered with more details about the numbers.
>


Dolske showed some numbers that reflects where in the decline in previous
Mac cycles that we removed support, but that could or could not be related
to our current problem of trying to find ways to stablize and stop the
decline of users.

Keeping these releases supported around just a bit longer than google gives
people incentive to come back and try firefox.  Just the thing we want to
happen.

If I look a a view of the numbers relative to all current Mac users it
looks like 10.8 has the highest value (15% of all current Mac Users) for
keeping around just a bit longer if their is any possible way to do that.
The others are in the noise.

Some one should check these numbers and see if they look right.

Version  % of all current Mac users as of back in Nov. which is the
latest data I can easily get my hands on to play with.

Mac10.8.00.1500

 Mac10.7.00.0004
 Mac10.7.40.0001
 Mac10.7.10.0001
 Mac10.7.30.0001

 Mac10.6.00.0003




>
> On 3/10/2016 6:38 PM, Nils Ohlmeier wrote:
>
>> Excuse my ignorance, but what means “deprecate support” exactly?
>>
>> I’m only asking because of the opposing reply’s so far. I’m assuming it
>> means we stop testing and building/releasing for these. Would it be a
>> possible alternative to turn of the tests, but continue to build and
>> release unsupported builds?
>>
> We intend to do the following things:
>
> * add version checking to the builds so that they refuse to run on these
> versions of MacOS
> * stop doing any software testing on these versions of MacOS
> * stop automated testing on Mac 10.6
>
> As soon as we stop testing, we are going to break things. We shouldn't be
> willing to call things "Firefox" that we aren't proud of, which includes
> real testing.
>
>
>
> On 3/10/2016 6:49 PM, Kyle Huey wrote:
>
>>
>> Why can't we just not ship e10s to these users?  We have a number of other
>> populations we're not shipping to, at least for now.
>>
>
> We did explicitly consider this option and ultimately rejected it. It
> would potentially buy us at least one more ESR cycle until next January.
> After that point we want e10s to be the only configuration. It comes at the
> cost of ignoring known issues already as well as a nontrivial amount of
> testing. Ultimately we don't believe this is the right tradeoff. It also
> prevents us making progress on other areas such non-universal builds.
>
> --BDS
>
>
> ___
> firefox-dev mailing list
> firefox-...@mozilla.org
> https://mail.mozilla.org/listinfo/firefox-dev
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Fingerprinting of battery status?

[Chris Hofmann]

I've seen a lot of GPS related tracking apps that use a lot of power
putting up warnings to users
that it might be time to go to low power mode and shut down the GPS if
you'll need it
later for navigating a critical pathway later in your journey.

-chofmann

On Mon, Aug 3, 2015 at 7:49 PM, Katelyn Gadd k...@luminance.org wrote:

 Games for mobile phones, handheld devices, and laptops often show a
 battery indicator and/or a clock in the corner of the screen while
 running in fullscreen mode. That's the only good reason I can think of
 off-hand.

 On 3 August 2015 at 12:55, Chris Peterson cpeter...@mozilla.com wrote:
  What is a legitimate use case for a web page to know my battery status?
  Battery level and time remaining can be used to fingerprint users.
 
  A mobile webapp might use battery level to throttle its activity, but
 that
  could be something the OS handles by pausing or throttling apps directly
 or
  broadcasting app lifecycle events. I can't think of a good reason why a
 web
  page in a browser, especially on a desktop OS, needs to know anything
 about
  my battery.
 
 
 http://www.theguardian.com/technology/2015/aug/03/privacy-smartphones-battery-life
 
  http://eprint.iacr.org/2015/616.pdf
 
 
  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

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

Re: Voting in BMO

[Chris Hofmann]

On Thu, Jun 11, 2015 at 1:18 PM, Mike Hoye mh...@mozilla.com wrote:

 On 2015-06-11 3:48 PM, R Kent James wrote:

 Maybe the correct fix is to start paying attention to votes.

 If you choose your project priorities based on internet voting, you're
 gonna have a bad time.

 The word vote implies that the act of voting has a direct effect on the
 outcome,


I don't see is anything in the definition that implies direct effect
http://www.merriam-webster.com/dictionary/vote

most of that is around the idea that a vote is an expression of opinion or
preference.

Seems like we don't need to, and haven't in many cases, implemented
features
or fixes with lots of votes but they at least deserve some kind of response
due to the
high level of interest, and that's generally what happens.

There are a few of us still round from the origin of many of these bugzilla
features
and for this one I think it was  mostly just intended as a mechanism to
make sure we
had some ways to get a good collection of eyeballs on a particular issue
where lots
of people shared the same experience or ideas, and to make sure at least
some kind of response was in place that explained the reason for doing,
or not doing, some course of action.

Based on that you might come away with a different opinion that voting
was working and serving a valuable service in its most simple form.

Its it just the case that we need to make it more clear that a vote means
vote for this bug to get more people looking at and discussing this bug?

It seems like the original proposal was to try and cut down on bugzilla
features
 with the idea of trying to remove and simplify.  Now its turned into yeah,
there is something
here that people want to be able to do here, but voting is not quite it,
and it might
deserve more investigation and feature work to really solve the  real
problem.

That seems like its leading more towards taking something simple like the
voting feature
we have now and turning it into something more complex.  That's an
interesting
turn in the discussion and something you are likely to run into as you try
to examine
more bugzilla features.

-chofmann



 which is clearly not the case here and really shouldn't be. But that's
 probably the root of a lot of community frustration.

 I definitely think that we need a low-friction, community-facing way to
 express interest in a bug's outcome - maybe a list the only CC's
 participants on status changes, but not on new comments? - but as it stands
 voting isn't the right thing.


 - mhoye




 ___
 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: Voting in BMO

[Chris Hofmann]

On Thu, Jun 11, 2015 at 2:38 PM, Mark Côté mc...@mozilla.com wrote:


 
  There are a few of us still round from the origin of many of these
 bugzilla
  features
  and for this one I think it was  mostly just intended as a mechanism to
  make sure we
  had some ways to get a good collection of eyeballs on a particular issue
  where lots
  of people shared the same experience or ideas, and to make sure at least
  some kind of response was in place that explained the reason for doing,
  or not doing, some course of action.
 
  Based on that you might come away with a different opinion that voting
  was working and serving a valuable service in its most simple form.
 
  Its it just the case that we need to make it more clear that a vote means
  vote for this bug to get more people looking at and discussing this
 bug?

 The original intention for voting doesn't seem to be widely understood
 or respected, as I believe you are saying.  So we either need to somehow
 communicate this intention more widely, or abandon it.  Unless someone
 is going to step up for the former, I would go with the latter.


Seems like a pretty simple change to just add text around the vote
link/button

change:
(vote
https://bugzilla.mozilla.org/page.cgi?id=voting/user.htmlbug_id=984012#vote_984012
)

to (vote to help raise visablity
https://bugzilla.mozilla.org/page.cgi?id=voting/user.htmlbug_id=984012#vote_984012
)



 Furthermore, since bugs with lots of votes also have lots of CCs (see an
 earlier post of mine), if we want to just acknowledge that a bug is
 popular, we can just use CC counts above a certain threshold.
 Admittedly there's no way to search for that, but it wouldn't be hard to
 add.


yeah, it seem reasonable that there might be correlation between
votes and cc lists at some steady state of the bug.

one interesting question is which one is the leading indicator
and which one is the lagging indicator.

1) do people add to the cc list as the result of finding
bugs with rising vote counts?

or 2) is the reverse happening that we have bugs with with big cc
lists in which people then start voting on.

or 3) is the growth in both uniform for bugs with large vote counts?

If its 1 (or maybe 3) then the system is working pretty much as originally
designed.

If its the later then votes might be just piling on and we
can leverage other indicators to give us the same info.

does the action of a vote currently add one to the cc list by default?

the ability to follow components and people also came
after voting and might also lead to a disconnect between
how many people are on the cc list of a random bug
that comes in and starts to get voted up.  that could
be valuable for new features that have just been added
that might get votes, but the component does not yet
have a big component following.

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

Re: Intent to deprecate: Insecure HTTP

[Chris Hofmann]

On Fri, May 1, 2015 at 11:16 AM, Martin Thomson m...@mozilla.com wrote:

 On Fri, May 1, 2015 at 11:06 AM, Eric Shepherd esheph...@mozilla.com
 wrote:
  There are a lot of things that don't need encryption,

 This assertion is made quite often in this context. It's been shown to
 be false in every example I've seen.  I think Richard provided several
 citations where this was believed to be correct, to the detriment of
 us all (great cannon being a prime example).


Is there a wiki page or some other comprehensive reference that defines the
issues and arguments around  this central question?

That seems like it would be good reading, and is key to developing
widespread understanding and support if this is going to move forward.

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

Re: Using rust in Gecko. rust-url compatibility

[Chris Hofmann]

check to see if we still have any automated crawlers still running that
could go looking for problems.

give the the folks that run the crawlers an instrumented build, and strong
liquor for best results.

-chofmann

On Thu, Apr 30, 2015 at 4:00 PM, Jason Duell jdu...@mozilla.com wrote:

 +1 to asserting during tests. I'd feel better about doing it on nightly too
 if there were a way to include the offending URI in the crash report.  But
 I'm guessing there's not?

 On Thu, Apr 30, 2015 at 3:42 PM, Jet Villegas jville...@mozilla.com
 wrote:

  I wonder why we'd allow *any* parsing differences here? Couldn't you just
  assert and fail hard while you're testing against our tests and in
 Nightly?
  I imagine the differences you don't catch this way will be so subtle that
  crowd-sourcing is unlikely to catch them either.
 
  --Jet
 
  On Thu, Apr 30, 2015 at 3:34 PM, Valentin Gosu valentin.g...@gmail.com
  wrote:
 
   As some of you may know, Rust is approaching its 1.0 release in a
 couple
  of
   weeks. One of the major goals for Rust is using a rust library in
 Gecko.
   The specific one I'm working at the moment is adding rust-url as a
 safer
   alternative to nsStandardURL.
  
   This project is still in its infancy, but we're making good progress. A
  WIP
   patch is posted in bug 1151899, while infrastructure support for the
 rust
   compiler is tracked in bug 1135640.
  
   One of the main problems in this endeavor is compatibility. It would be
   best if this change wouldn't introduce any changes in the way we parse
  and
   encode/decode URLs, however rust-url does differ a bit from Gecko's own
   parser. While we can account for the differences we know of, there may
  be a
   lot of other cases we are not aware of. I propose using our volunteer
  base
   in trying to find more of these differences by reporting them on
 Nightly.
  
   My patch currently uses printf to note when a parsing difference
 occurs,
  or
   when any of the getters (GetHost, GetPath, etc) returns a string that's
   different from our native implementation. Printf might not be the best
  way
   of logging these differences though. NSPR logging might work, or even
   writing to a log file in the current directory.
  
   These differences are quite privacy sensitive, so an automatic
 reporting
   tool probably wouldn't work. Has anyone done something like this
 before?
   Would fuzzing be a good way of finding more cases?
  
   I'm waiting for any comments and suggestions you may have.
   Thanks!
   ___
   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
 



 --

 Jason
 ___
 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: Tiles Design Questions (was Re: Improving trust and transparency for Suggested Tiles)

[Chris Hofmann]

I think this discussion has moved a bit off topic.

Let's all assume that if the intent was to gather public feedback by a post
in the newsgroup that a similar intent of having a meeting with interested
participant would include a good sampling of people with interest, and that
their employment status with Mozilla wouldn't matter.  Those have always
been the assumptions at mozilla.

I think the key thing that missing in this tiles discussion goes back to a
good thing that lilly once said:

...Tell me what you're trying to do, and tell me your assumptions; then I
can give you feedback.

I think that's what's missing from Ed's initial post.

We got bits and pieces of a few parts of suggest tiles, but not an
explanation of what this is trying to do for users and possible
advertisers.  What's needed are more details and assumptions how it might
connect them closer or not, and some more details about how the overall
system to generate the selection for a given tile is intended to work.

From there an explanation and discussion about how these pieces respect
user privacy and tracking choices, and value for the involved parties can
proceed.  That's how we can get to a conversation that might discover any
unintended side effects or mitigation strategies that don't really work
that the orginal plan might not have considered.

-chofmann

On Fri, Apr 24, 2015 at 7:35 AM, Eric Rescorla e...@rtfm.com wrote:

 On Fri, Apr 24, 2015 at 7:20 AM, Mike Hoye mh...@mozilla.com wrote:

   On 2015-04-24 10:14 AM, Eric Rescorla wrote:
 
   On Fri, Apr 24, 2015 at 7:05 AM, Mike Hoye mh...@mozilla.com wrote:
 
  On 2015-04-24 12:07 AM, Eric Rescorla wrote:
 
  Who said anything about excluded? It's simply much easier to discuss
  detailed topics in a small real-time setting. If there are community
  members who are well-prepared for this discussion, I don't see why they
  couldn't be participants.
 
   There's no practical difference between a meeting that explicitly
  excludes the Mozilla community and one that's not widely announced
 ahead of
  time and is difficult or impossible to participate in remotely.
 
 
   If people have something useful to say then they should presumably ask
 to
  be included in the meeting.
 
 
   But Mr Dent, the plans have been available in the local planning office
  for the last nine months.
 
  Oh yes, well as soon as I heard I went straight round to see them,
  yesterday afternoon. You hadn't exactly gone out of your way to call
  attention to them, had you? I mean, like actually telling anybody or
  anything.
 
  But the plans were on display ...
 
  On display? I eventually had to go down to the cellar to find them.
 
  That's the display department.
 
  With a flashlight.
 
  Ah, well the lights had probably gone.
 
  So had the stairs.
 
  But look, you found the notice didn't you?
 
  Yes, said Arthur, yes I did. It was on display in the bottom of a
  locked filing cabinet stuck in a disused lavatory with a sign on the door
  saying 'Beware of the Leopard'.
 
 Yes, that's exactly like having a meeting to figure out a preliminary plan
 and then
 publishing it for public comment.

 -Ekr


 
 
  - mhoye
 
 ___
 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: Web Speech API - Speech Recognition with Pocketsphinx

[Chris Hofmann]

On 10/30/14 5:24 PM, smaug wrote:

On 10/31/2014 02:21 AM, smaug wrote:

Intent to ship is too strong for this.
We need to first have implementation landed and tested ;)

I wouldn't ship the implementation in desktop FF without plenty of 
more testing.




But I guess the question is what people think about shipping the 
pocketspinx + API, even if disabled by default.


Andre, we need some numbers here. How much does Pocketsphinx increase 
binary size? or download size?
When the pref is enabled, how much does it use memory on desktop, what 
about on b2g?



This is important work and the competition is ramping quicky after many 
years of promises about this year being the year of voice recognition.  
We will probably fall behind quickly if we don't get something going 
here in the next year.


Can you also talk a bit about what the plan and set of challenges look 
like for expanding the supported languages, and how these would impact 
the numbers ollie has asked for?


The place we really need this is b2g, but phones are only shipping in 
international markets right now so english only is not all that helpful.


-chofmann




-Olli


On 10/31/2014 01:18 AM, Andre Natal wrote:
I've been researching speech recognition in Firefox for two years. 
First
SpeechRTC, then emscripten, and now Web Speech API with CMU 
pocketsphinx
[1] embedded in Gecko C++ layer, project that I had the luck to 
develop for

Google Summer of Code with the mentoring of Olli Pettay, Guilherme
Gonçalves, Steven Lee, Randell Jesup plus others and with the 
management of

Sandip Kamat.

The implementation already works in B2G, Fennec and all FF desktop
versions, and the first language supported will be english. The API and
implementation are in conformity with W3C standard [2]. The 
preference to

enable it is: media.webspeech.service.default = pocketsphinx

The required patches for achieve this are:

  - Import pocketsphinx sources in Gecko. Bug 1051146 [3]
  - Embed english models. Bug 1065911 [4]
  - Change SpeechGrammarList to store grammars inside SpeechGrammar 
objects.

Bug 1088336 [5]
  - Creation of a SpeechRecognitionService for Pocketsphinx. Bug 
1051148 [6]



Also, other important features that we don't have patches yet:
  - Relax VAD strategy to be les strict and avoid stop in the middle of
speech when speaking low volume phonemes [7]
  - Integrate or develop a grapheme to phoneme algorithm to realtime
generator when compiling grammars [8]
  - Inlcude and build models for other languages [9]
  - Continuous and wordspotting recognition [10]

The wip repo is here [11] and this Air Mozilla video [12] plus this 
wiki

has more detailed info [13].

At this comment you can see a cpu usage on flame while recognition is
happening [14]

I wish to hear your comments.

Thanks,

Andre Natal

[1] http://cmusphinx.sourceforge.net/
[2] https://dvcs.w3.org/hg/speech-api/raw-file/tip/speechapi.html
[3] https://bugzilla.mozilla.org/show_bug.cgi?id=1051146
[4] https://bugzilla.mozilla.org/show_bug.cgi?id=1065911
[5] https://bugzilla.mozilla.org/show_bug.cgi?id=1088336
[6] https://bugzilla.mozilla.org/show_bug.cgi?id=1051148
[7] https://bugzilla.mozilla.org/show_bug.cgi?id=1051604
[8] https://bugzilla.mozilla.org/show_bug.cgi?id=1051554
[9] https://bugzilla.mozilla.org/show_bug.cgi?id=1065904 and
https://bugzilla.mozilla.org/show_bug.cgi?id=1051607
[10] https://bugzilla.mozilla.org/show_bug.cgi?id=967896
[11] https://github.com/andrenatal/gecko-dev
[12] 
https://air.mozilla.org/mozilla-weekly-project-meeting-20141027/ (Jump

to 12:00)
[13] https://wiki.mozilla.org/SpeechRTC_-_Speech_enabling_the_open_web
[14] https://bugzilla.mozilla.org/show_bug.cgi?id=1051148#c14





___
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: Breakdown of Firefox full installer

[Chris Hofmann]

On 10/13/14 4:54 PM, Chris More wrote:
  I am imagining a pie chart of the the current installer and then a 
table of the name of each component, their size (KB or MB), and any 
additional meta data.
Pie charts are usually not all that useful in this kind of analysis; 
but one is attached based on Kyle's work.

http://people.mozilla.org/~chofmann/installer/installer-pie.png

Bar charts can be a bit more useful since its easier to see pct. 
contributed by each component and where the long tail of 
uninteresting/disjointed components starts to kick in.



http://people.mozilla.org/~chofmann/installer/installer-bar.png
The top 4 components make up the bulk of the package and then anything 
past the next 8 components is less that 1% of the package.


31.28% ./core/xul.dll
13.97% ./core/omni.ja
13.00% ./core/icudt52.dll
11.16% ./core/browser/omni.ja
6.10% ./core/gkmedias.dll
4.64% ./core/mozjs.dll
4.04% ./core/d3dcompiler_46.dll
2.63% ./core/D3DCompiler_43.dll
2.25% ./core/nss3.dll
1.28% ./core/icuin52.dll
1.12% ./core/uninstall/helper.exe
1.00% ./core/icuuc52.dll
0.96% ./core/msvcr100.dll
0.86% ./setup.exe
0.80% ./core/libGLESv2.dll
0.78% ./core/dictionaries/en-US.dic



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

Re: Breakdown of Firefox full installer

[Chris Hofmann]

On 10/13/14 5:16 PM, Justin Dolske wrote:

On 10/13/14 4:54 PM, Chris More wrote:


Why am I asking this?

The win32 Firefox full installer continues to grow (see attachment)
each release and it has been on an increasing growth since Firefox
29. Like anything on the web, the time it takes to download something
(webpage, binary file, etc.) affects the key conversion rate by some
amount.


We have the (much smaller) stub installer for Windows now... I know 
download size was a big factor for the full installer; do we know 
anything about kind of impact it has for the stub installer?


Justin


Sure the stub allows for some better response and user interaction in 
the early part of the process which can help sucess rates.  At a minimum 
it least give us some visibility into what is really happening at the 
early stages of visiting the web site, and getting process kicked off, 
but still leaves holes in understand the back end of the process.


There is another way to think about this.  Its not so much a size 
problem we are working against, but a time problem.   Of course size has 
impact on time, but its really time for the installer to complete the 
download and installation that is the big challenge. The longer the 
download takes the more chances there are for interruption and failure 
from network errors, user distractions and giving up, and other things 
that can get in the way of completion.


Slow networks cause increase of time and more chance for failures. If we 
are serving installers now to a higher pct. of users in under developed 
world and slower connections we should expect the failure rates to be 
increasing, and if we are expanding the size of the download we are 
increasing the problem.


I think john jensen studied this a bit and had some a/b studies where we 
increased the size of the installer and watched for failure rates to 
increase but don't recall where the results were put.   I also think 
there were some  serious limitations on the study and being able to 
measure significant changes in download size, and different failure 
rates at different download speeds/length of the installation process.


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

Re: Target Milestone field in bugzilla

[Chris Hofmann]

On 1/16/14 11:36 AM, Daniel Veditz wrote:

On 1/9/2014 9:47 AM, Gavin Sharp wrote:

In theory (mine at least), the field is free to be used for planning
which release you want the bug fixed in, before the bug is fixed.
After the bug is fixed, it should be used as you describe.

Some groups do use the field this way, for example the NSS dev team. It
shouldn't be too hard to figure out: if the bug is open the field is a
planning target; if the bug is resolved you hit that target.

-Dan Veditz



Yes, and the request that Ryan made:

 I find it useful at times to know what release a patch first landed 
on independent of where it was eventually uplifted to.

 Can be useful for regression hunting and bug archeology.

is served by target milestone and fixed resolution for where the fix 
orginally landed, plus the status flags  for each release/branch that 
give info on if other branches or releases are also 
affected/fixed/verfiied by back ports or uplifts.


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