Plan to move macOS 10.9, 10.10 and 10.11 users to ESR78

[Romain Testard]

Hello All,

*tl;dr:

We plan on moving macOS 10.9, 10.10 and 10.11 users to ESR78 as part of the
first step towards end of support for these platform versions.

*Goal*

Continue to provide an excellent browsing experience and ongoing security
updates to macOS 10.9, 10.10 and 10.11 users and reduce cost of supporting
these platform versions.

*Plan*

- Move macOS 10.9, 10.10 and 10.11 users to an Extended Support Release
when Firefox 78 branches

- Continue to provide security updates for the life of ESR 78 (until summer
2021)

- In summer 2021, when ESR 78 reaches the end of support, leave macOS 10.9,
10.10 and 10.11 users on the last version of ESR78 - these users won’t be
receiving security updates past this point

*Background*

While Apple doesn’t have a public policy governing security updates for
older macOS releases, their ongoing practice has been to support the most
recent three releases (i.e. version N, N-1, and N-2) - the last security
update applicable to macOS 10.11 was made available in July 2018 (
https://support.apple.com/en-us/HT201222). Unsupported operating systems
receive no security updates, have known exploits, and can be dangerous to
use, which makes it difficult to maintain Firefox on those versions.

The affected macOS versions represent 2.8M MAU with the following breakdown
(you can access details of queries related to the migration on
https://sql.telemetry.mozilla.org/dashboard/moving-macos-10-9-10-10-10-11-users-to-esr-78
):

   -

   OSX 10.9 548,000 MAU
   -

   OSX 10.10: 855,000 MAU
   -

   OSX 10.11 1,426,000 MAU


We feel that continuing to provide updates via ESR 78 allows us to reduce
the opportunity cost of supporting these OS versions, while keeping users
as safe as we can.

*Opportunity Cost of Supporting macOS 10.9, 10.10 and 10.11*

By removing macOS 10.9, 10.10 and 10.11 from new Firefox releases we can:

   - Lower testing/operational costs

   - Avoid macOS 10.9, 10.10 and 10.11 specific bugs/regressions

*What does this mean for macOS 10.9, 10.10 and 10.11 users?*

   - Firefox 78 will be the last version of Firefox available to them

   - They will continue to get security updates until summer 2021

*How will this plan be communicated?*

Subsequent to the collection of feedback from this email, I will be
drafting a blog post describing the finalized plan. In addition, we just
published a SUMO page (https://support.mozilla.org/en-US/kb/macos-users-esr)
describing the plans.

If you have questions/comments, please reply to the *dev-platform* mailing
list.


Thanks,

Romain

Product manager on Firefox desktop
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to unship: FTP protocol implementation

[Romain Testard]

Would it make sense to ship after Chrome to help ensure this does not lead
to churn?
Also at a time people try to find ways to work from home and share files
(spike of usage in Firefox send), potentially breaking ways people have to
share files may not be good timing?

On Thu, Mar 19, 2020 at 10:42 AM Frederik Braun  wrote:

> > We're doing this for security reasons. FTP is an insecure protocol and
> > there are no reasons to prefer it over HTTPS for downloading resources.
> > Also, a part of the FTP code is very old, unsafe and hard to maintain
> > and we found a lot of security bugs in it in the past.
>
> I know this used to be (is?) a widely used feature, but I can second
> these considerations. It's not right to waste smart network engineering
> time on decades old legacy code and it's likely even harder to justify a
> rewrite.
> ___
> 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: Announcing the next Extended Support Release of Firefox - ESR60 with policy engine

[Romain Testard]

Some enterprises may indeed find that enabling site isolation is worth the
trade-offs (memory usage seems to be the main one on Chrome's
implemenation).
Our current goal is to make sure enterprise users retain the same feature
set with the next ESR and that we deliver a capability that allows easy
integration of new policies and third party management tools. We'll be
reaching out to enterprise users to collect feedback that should help
prioritize our next features, right now it's it's pretty hard to assess how
critical stronger security isolation is when compared to customization
features we're considering in the medium term like the ability to disable
printing.

On Fri, Jan 5, 2018 at 7:09 PM, Gijs Kruitbosch 
wrote:

> On 04/01/2018 18:06, Tom Ritter wrote:
>
>> I am curious what Enterprise users are asking for.  I'd like to
>> think/hope that a primary concern of enterprise is "Security" (or the
>> separate topic of Privacy); but I'm not certain it is.
>>
>> In particular, I am curious if enterprise users would be interested in
>> flipping preferences that would provide stronger security isolation at
>> the cost of more resources (like process/memory).  This is basically
>> what Chrome is providing with command-line flags for site isolation. A
>> company can decide that domains of their choosing get allocated into
>> per-origin processes, at the potential cost of a bunch of additional
>> processes.
>>
>
> Yes, in fact this (process-per-site) has specifically already come up on
> the enterprise list in the last few days.
>
> ~ Gijs
>
>
>> -tom
>>
>> On Thu, Dec 21, 2017 at 10:09 AM, Mike Kaply  wrote:
>>
>>> We currently do not plan to allow arbitrary preferences, but if certain
>>> preferences are important, we can add policies for them.
>>>
>>> We could also add policies that set groups of preferences for specific
>>> purposes.
>>>
>>> Mike
>>>
>>> On Thu, Dec 21, 2017 at 10:03 AM, Luke Crouch 
>>> wrote:
>>>
>>> On Wednesday, December 20, 2017 at 9:42:50 AM UTC-6, Sylvestre Ledru
 wrote:

> First, as Dave Camp mentioned during the Firefox All Hands, we are
>
 started some developments to improve

> our support for enterprise users.
> More information can be found on the wiki: https://wiki.mozilla.org/
>
 Firefox/EnterprisePolicies

 The first example configuration.json I saw on the page only shows some
 custom policy configs - e.g., bookmarks_on_toolbar, allow_popups_from,
 etc.

 Will the policy config allow admins to set other/any about:config prefs
 to
 custom values?

 I'm thinking specifically it would be cool to let Enterprise+InfoSec
 admins set some security + privacy about:config prefs to more hardened
 defaults.
 ___
 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: Firefox Hello new data collection

[Romain Testard]

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
<https://www.mozilla.org/en-US/privacy/firefox-hello/>).

>
> ~ Gijs
> ___
> 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

Firefox Hello new data collection

[Romain Testard]

Hi all,


We wanted to let you know about new data collection that we will be doing
for Firefox Hello starting with FF46 launch on April 19th, and the steps we
took to prevent it from collecting personal identification. We want to
collect more data about the websites that people share with Hello, to help
optimize the product UX, understand what people use our new tab sharing
feature for, and prioritize features accordingly. The product features and
UX can be very different if we decide to optimize against “Shopping
together” use cases as opposed to “Playing online games together”, just as
examples.


We did a lot of diligence for this and explored several options for getting
the data. The approach described below is the one we settled on. It
prevents personal identification and gets us the data we need to build the
best tool we can while being sensitive to our users. This involves
collecting the domain names for tabs shared on Firefox Hello on our own
servers.


How we collect the data


We plan to put in place a data collection solution that prevents personal
identification. The technical approach to doing this through the use of
client-side whitelisting is outlined here:



   -

   Data will go to our servers and will be stored with our other server
   metrics.  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.
   -

   Users who have disabled Health Reports will also not submit this data.
   -

   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. We would subtract
   the sites from the Adult
    category and add all
   the subdomains of:


   -

  google.com
  (e.g.,
  drive.google.com)
  -

  yahoo.com (e.g., games.yahoo.com)
  -

  developer.mozilla.org, bugzilla.mozilla.org, wiki.mozilla.org (this
  helps us understand how much our user base is Mozillians)
  -

  tunes.apple.com
  -

   You can see the exact list here: DomainWhitelist.jsm
   




   -

   The data will only be kept for 6 months and we plan to revisit this
   collection in 6 months. We’ll evaluate at the end of this period if we
   should carry on collecting the data (the data is still useful and will help
   further shape the product) or just stop.


This e-mail is intended to make everyone aware of the data we’re collecting
in Hello in an effort to be as transparent as possible. We want make sure
people get the full picture of what we are trying to achieve and what we’re
putting in place to protect our users.


Let me know if you have any questions.



Implementation bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1211542

Technical documentation:
https://github.com/mozilla/loop/blob/master/docs/DataCollection.md


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