Intent to implement and ship the CSS Scroll Snap Module Level 1 and unship old scroll snap properties

[Hiroyuki Ikezoe]

Summary:
  The scroll snap specification has been significantly changed since we
 implemented.  scroll-snap-coordinate, scroll-snap-destination and
 scroll-snap-points-{x,y} were dropped, instead, scroll-snap-align,
 scroll-snap-margin and scroll-snap-padding were added in the spec.  Also,
 scroll-snap-type was changed to a longhand property and its syntax was
 changed in the spec.
  Due to the scroll-snap-type change, this migration will happen
irreversibly
 in terms of the scroll-snap-type property.  Once the change happens in bug
 1312163 [1], you can no longer use the old longhands,
scroll-snap-type-{x,y},
 and no longer use the old shorthand syntax like `scroll-snap-type:
mandatory`.
 That means that, for example, sites specifying only scroll-snap-type-x will
 be broken.  To mitigate it, I am going to land a bunch of relevant stuff
at the
 same time so that we can switch to the new scroll snap at once.

Bug:
 A meta bug is
  https://bugzilla.mozilla.org/show_bug.cgi?id=1231777

Link to standard:
 https://drafts.csswg.org/css-scroll-snap-1/

Platform coverage: all

Estimated or target release: Firefox 68

Preference behind which this will be implemented:
 layout.css.scroll-snap-v1.enabled

Is this feature enabled by default in sandboxed iframes?
 Yes

DevTools bug:
 https://bugzilla.mozilla.org/show_bug.cgi?id=1133666

Do other browser engines implement this?
 Chrome and Safari already shipped

web-platform-tests:
 http://w3c-test.org/css/css-scroll-snap/

Additional notes:
 scroll-snap-stop which was introduced in the new spec is not going to be
 implemented now since it's marked at-risk in the spec

Thanks,
hiro

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1312163
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement: Limit the maximum life-time of cookies set through document.cookie to seven days

[Ehsan Akhgari]

On Thu, Mar 7, 2019 at 7:31 PM Ehsan Akhgari 
wrote:

> *Estimated or target release*: in which version do you want to/plan to
> release this? Getting enabled in Nightly in 67, staying Nightly only for
> now in order to collect some early feedback.  No estimated target release
> available yet since this is an early exploration.
>
Minor correction, in order to avoid conflicting with the soft freeze I will
hold off to enable this in the beginning of the next cycle.

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

Intermediate CA Preloading is enabled for desktop Nightly users

[J.C. Jones]

# tl;dr #

At the end of February I enabled Intermediate CA Preloading for all
desktop Nightly users to begin gathering telemetry. This means all
intermediate CAs disclosed to Mozilla will be pre-loaded into
profiles, so the common secure website misconfiguration of forgetting
this certificate won’t stop Firefox users. It has other benefits, too,
but for those read on.




In Bug 1404934 we've added support to download the Intermediate
Certificate Authorities that have been disclosed to the Mozilla CA
Root Program from Kinto in the background during normal Firefox
operation. I turned this on for all desktop nightly users a bit more
than a week ago, prompting Nightly users to download 100 intermediate
CA certs into their profile each day. I do not have a timeline at
present for this to ride the trains.


# What it does #

Websites using encryption should provide two digital PKI certificates
[0] when connecting to clients: One for the website itself, and one
for the intermediate CA that produced the website's digital
certificate. Sometimes, websites are set up incorrectly.


When other browsers encounter this case, they use AIA-chasing, a
mechanism where the user's browser then, in the background, connects
to the CA and downloads the certificate during the TLS handshake.

## Performance benefit ##

Preloading the intermediate CA data avoids the just-in-time network
fetch, which delays the connection.

## Privacy ##

Avoiding the network fetch is also a privacy improvement, as it
doesn't disclose your browsing pattern to the certificate authority
that issued the misconfigured website's certificate.

It's also helpful because it's possible to "fingerprint" a user by a
website carefully analyzing what other websites load or do not load
due to which intermediate CAs have been "seen" by a user [1].
Preloading ensures that all users have "seen" all the same
intermediate CAs.

## Protection ##

The Mozilla CA program requires all members to disclose unconstrained
intermediate CAs before using them, as a safety measure. However,
there is not currently a way to technically enforce that. Intermediate
Preloading could eventually be used to perform that enforcement, by
only trusting intermediate CAs which were disclosed already. This
protects against a scenario where a compromised CA is coerced into
producing an undisclosed secret intermediate CA, which is then used to
attack people on the Internet.


## Future usefulness ##

The experimental CRLite concept [2] (aiming to replace OCSP) requires
a mapping of Intermediate CAs to an “enrollment status” flag. Since we
need to enumerate the Intermediate CAs for that future functionality,
actually preloading their data is a rational extension.


# How it works #

Intermediate Preloading fetches ~100 intermediate certificate
authorities' certificates once a day during the Kinto main update [3],
and loads them into your profile, as if you had visited a site that
used that intermediate. At 100 per day, summing to between 300-500 kB,
it will take approximately three weeks for a Firefox profile to
preload all intermediates [4]. We will likely increase the rate after
the initial experiments.

The certificate data is loaded into the NSS Certificate Database, as
is done for normal web browsing. In the future, we will use the faster
Rust "rkv" database, in Bug 1530545.

Currently preloading is only enabled for desktop users on Nightly. We
will want to (A) restrict the download to be only over WiFi and maybe
plugged in, and (B) switch to the faster database before enabling on
mobile. (Bug 1520297)


# What we expect #

Intermediate Preloading should reduce the number of
SEC_ERROR_UNKNOWN_ISSUER errors seen by Firefox users over time, which
is our most common secure connection error. It will also remove the
tracking vector (above, Privacy), and give us a path to enforce CA
disclosure.


# Things to keep in mind #

Right now, these certificates go into the NSS Certificate Database,
and are visible in / totally overcrowding the Certificate Manager (Go
To about:preferences#privacy , View Certificates.., Authorities tab).
That’ll change when this moves to rkv.

This is potentially a bunch of data, approximately 3 megabytes of
binary, but it’s data that changes only very slowly.


# Telemetry #

Telemetry for Intermediate Preloading is available in the histograms:

  "INTERMEDIATE_PRELOADING_ERRORS"
  "INTERMEDIATE_PRELOADING_UPDATE_TIME_MS"

and the scalars:

  "security.intermediate_preloading_num_pending"
  "security.intermediate_preloading_num_preloaded"

... which show how many of the ~2300 intermediates have been loaded,
per profile.

# More info #

Well, maybe. ;) There's a wiki page about this which can be used to
help explain the same things as are in this post. Otherwise, send your
questions to me, Mark Goodwin, or Dana Keeler.

https://wiki.mozilla.org/Security/CryptoEngineering/Intermediate_Preloading

:: Footnotes::

[0] The WebPKI generally has one root CA certificate, one 

Re: Intent to implement: Limit the maximum life-time of cookies set through document.cookie to seven days

[Ehsan Akhgari]

On Fri, Mar 8, 2019 at 11:54 AM James Graham  wrote:

> On 08/03/2019 15:06, Boris Zbarsky wrote:
> > On 3/7/19 7:31 PM, Ehsan Akhgari wrote:
> >> *web-platform-tests*: This is an intervention which different engines do
> >> not agree on yet.  Creating a web-platform-test for it would be very
> >> simple
> >> but it will be failing in the engines that do not agree with the
> >> intervention.  I'm not sure what the recommendation for testing these
> >> types
> >> of changes is, would be happy to submit a test if there is a path for
> >> getting them accepted into wpt.
> >
> > Other vendors have been landing tests with ".tentative" as the last part
> > of the filename before the suffixes the test harness expects (so e.g.
> > "web-locks/mode-shared.tentative.https.any.js").
> >
> > I think doing that here is fine; we may want the tests or the commit
> > message involved to point to an explainer or something tracking the need
> > for a spec change or something like that...
>
> Yes, this seems correct to me too; a .tentative. test is the right way
> to land a test for something that isn't yet standardised, and it should
> somehow link to the relevant discussion but there isn't an explicit
> convention for how that should happen (commit message vs comment vs link
> element, for example). See the end of [1] for the documentation.
>

Thanks for the suggestion, sounds good.  I filed
https://bugzilla.mozilla.org/show_bug.cgi?id=1533827 to track this.

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

Intent to Implement: Trim the Referer header sent to third-party tracking resources to origin by default through modifying the default referrer policy

[Ehsan Akhgari]

*Summary*: With Enhanced Tracking Protection gradually rolling out to our
users on the release channel, we are limiting the ability of third-party
trackers to store unique client identifiers on the user's device in order
to capture a history of their browsing across different sites.  However we
are still leaking important browsing history data to these trackers in the
Referer header, which may still be tied to the user through identifiers
such as the IP address which may be stable for some users.  It is well
known that the Referer header can contain a lot of sensitive information
such as the user's search query, their user ID on various sites, and so on.

In 2017 we did a study <
https://blog.mozilla.org/data/2018/01/26/improving-privacy-without-breaking-the-web/>
on measuring the breakage impact of a number of privacy features including
limiting the Referer data sent to third-parties to origin only, and
discovered very low breakage impact from doing so.  Since then, we have
modified the default referrer policy for all third-parties in private
browsing mode with great results in terms of web compatibility.

This intent is sent to experiment with applying the same idea to
third-party tracking resources when Enhanced Tracking Protection is turned
on, through setting a default referrer policy of
strict-origin-when-cross-origin on them.  We'd like to get some early
testing by enabling this feature on the Nightly channel in the next cycle.

*Bug*: This feature landed in
https://bugzilla.mozilla.org/show_bug.cgi?id=1530076, and
https://bugzilla.mozilla.org/show_bug.cgi?id=1533763 has been filed to
enable it on Nightly.  The intention is to enable it on normal windows,
since in private windows all third-party content already has this
restriction applied to it.
*Link to standard*: https://github.com/whatwg/fetch/issues/879
*Platform coverage*: Everywhere.
*Estimated or target release*: It is unclear as of yet, we are still in
early exploration phase for this feature,
*Preference behind which this will be implemented*:
network.http.referer.defaultPolicy.trackers and
network.http.referer.defaultPolicy.trackers.pbmode, available for testing
in Nightly right now.  I'm proposing to set the value of the former pref to
2 on Nightly.
*Is this feature enabled by default in sandboxed iframes?* If not, is there
a proposed sandbox flag to enable it? If allowed, does it preserve the
current i

Please link to the test suite. If any part of the feature is not tested by
web-platform-tests, please include links to one or more of:

   - A web-platform-tests issue explaining why a certain thing cannot be
   tested (example ).
   - A spec issue for some change that would make it possible to test (
   example ).
   - A Bugzilla bug for the creating web-platform-tests.

nvariants in terms of what sandboxed iframes can do? I'm proposing to
enable this feature in sandboxed iframes by default.  It will preserve the
current invariants.
*DevTools bug*: No specific bug, since devtools already supports showing
the referrer policy applied to each network resource in the network
monitor, as well as the individual Referer headers sent alongside each
request, of course.
*Do other browser engines implement this?* Safari shipped this for origins
with tracking capabilities since some point last year with their ITP 2.0
release (https://webkit.org/blog/8311/intelligent-tracking-prevention-2-0/).
Firefox has shipped this for third-party origins in private windows since
Firefox 59.
*web-platform-tests*: https://bugzilla.mozilla.org/show_bug.cgi?id=1533825
is filed to track adding them.

*Is this feature restricted to secure contexts?* It's not. This
intervention is performed for protecting the user's privacy and the same
argument applies for non-secure contexts as well. Also, Referer headers
sent over non-secure contexts would be visible to network MITM attackers so
arguably protecting them is even more valuable than protecting the secure
context ones.
Please let me know if you have any questions or concerns.

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

Re: Intent to implement: Limit the maximum life-time of cookies set through document.cookie to seven days

[James Graham]

On 08/03/2019 15:06, Boris Zbarsky wrote:

On 3/7/19 7:31 PM, Ehsan Akhgari wrote:

*web-platform-tests*: This is an intervention which different engines do
not agree on yet.  Creating a web-platform-test for it would be very 
simple

but it will be failing in the engines that do not agree with the
intervention.  I'm not sure what the recommendation for testing these 
types

of changes is, would be happy to submit a test if there is a path for
getting them accepted into wpt.


Other vendors have been landing tests with ".tentative" as the last part 
of the filename before the suffixes the test harness expects (so e.g. 
"web-locks/mode-shared.tentative.https.any.js").


I think doing that here is fine; we may want the tests or the commit 
message involved to point to an explainer or something tracking the need 
for a spec change or something like that...


Yes, this seems correct to me too; a .tentative. test is the right way 
to land a test for something that isn't yet standardised, and it should 
somehow link to the relevant discussion but there isn't an explicit 
convention for how that should happen (commit message vs comment vs link 
element, for example). See the end of [1] for the documentation.


[1] https://web-platform-tests.org/writing-tests/file-names.html
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement: Limit the maximum life-time of cookies set through document.cookie to seven days

[Boris Zbarsky]

On 3/7/19 7:31 PM, Ehsan Akhgari wrote:

*web-platform-tests*: This is an intervention which different engines do
not agree on yet.  Creating a web-platform-test for it would be very simple
but it will be failing in the engines that do not agree with the
intervention.  I'm not sure what the recommendation for testing these types
of changes is, would be happy to submit a test if there is a path for
getting them accepted into wpt.


Other vendors have been landing tests with ".tentative" as the last part 
of the filename before the suffixes the test harness expects (so e.g. 
"web-locks/mode-shared.tentative.https.any.js").


I think doing that here is fine; we may want the tests or the commit 
message involved to point to an explainer or something tracking the need 
for a spec change or something like that...


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

Re: Intent to implement: Limit the maximum life-time of cookies set through document.cookie to seven days

[zan]

Apologies, this was the outcome of a poor FastMail mobile UI interaction.

On Fri, Mar 8, 2019, at 9:48 AM, z...@falconsigh.net wrote:
> 
> 
> On Fri, Mar 8, 2019, at 1:31 AM, Ehsan Akhgari wrote:
> > *Summary*: As part of the anti-tracking project, we'd like to experiment
> > with a new feature in order to mitigate the impact of third-party tracking
> > scripts running in top-level documents.  As we are planning to start
> > removing the storage capabilities of third-party trackers, which removes
> > their ability to store unique identifiers for each client in cookies which
> > would be transmitted to servers across websites, a number of cross-site
> > trackers have started to switch to using first-party cookies to store their
> > unique identifiers.  The way that this works typically is through
> > annotating outbound links to the target website with a unique query string
> > parameter, and then reading and storing that unique parameter in the
> > first-party cookie storage through the third-party scripts that they
> > control which are running in the context of the top-level target site when
> > the user follows such a link.
> > 
> > This is bad because it would allow cross-site trackers to keep tracking the
> > user through a unique identifier, but it would also expose the unique
> > identifier used by tracker1 to all of the other trackers that have active
> > code running on the page, which would allow them to sync up each others'
> > tracking identifiers without resorting to practices such as cookie syncing <
> > https://clearcode.cc/blog/cookie-syncing/>.
> > 
> > We'd like to experiment with imposing a short maximum life-time on cookies
> > set through document.cookie in order to ensure that these unique
> > identifiers would expire relatively quickly once they are established, and
> > wouldn't allow cross-site trackers to establish a pervasive permanent
> > unique identifier.  We're picking seven days to be compatible with Safari
> > which has been shipping this for a while now <
> > https://webkit.org/blog/8613/intelligent-tracking-prevention-2-1/>.
> > 
> > *Bug*: This was implemented originally in (disabled by default)
> > https://bugzilla.mozilla.org/show_bug.cgi?id=1529836.  The bug to enable
> > this on Nightly is https://bugzilla.mozilla.org/show_bug.cgi?id=1533584.
> > *Link to standard*: No public standard change has been made for this
> > feature yet.  We should modify the cookie RFC when we know more about
> > whether we would like to ship this change or not given that we would be the
> > second web engine doing so.
> > *Platform coverage*: where will this be available? Everywhere.
> > *Estimated or target release*: in which version do you want to/plan to
> > release this? Getting enabled in Nightly in 67, staying Nightly only for
> > now in order to collect some early feedback.  No estimated target release
> > available yet since this is an early exploration.
> > *Preference behind which this will be implemented*: if applicable, how can
> > interested parties test this before it ships pref'd on by default? The
> > preference for this feature, available in Nightly right now, is
> > privacy.documentCookies.maxage.  The value of this pref is the maximum
> > life-time cap in seconds.  A value of 0 would disable enforcing a cap (0 is
> > the current default.)
> > *Is this feature enabled by default in sandboxed iframes?* If not, is there
> > a proposed sandbox flag to enable it? If allowed, does it preserve the
> > current invariants in terms of what sandboxed iframes can do? I'm proposing
> > to enable this feature in sandboxed iframes by default.  It will preserve
> > the current invariants.
> > *DevTools bug*: No specific bug, since devtools already supports showing
> > the expiry date of cookies and once this feature gets enabled it will
> > correctly display the expiry date for those cookies where Firefox would
> > enforce this cap on.
> > *Do other browser engines implement this?* Answer with: Safari shipped
> > (since version 12.0.x, tested in 12.0.3, announced as part of ITP 2.1
> > recently:  > >).
> > 
> > *web-platform-tests*: This is an intervention which different engines do
> > not agree on yet.  Creating a web-platform-test for it would be very simple
> > but it will be failing in the engines that do not agree with the
> > intervention.  I'm not sure what the recommendation for testing these types
> > of changes is, would be happy to submit a test if there is a path for
> > getting them accepted into wpt.
> > 
> > *Is this feature restricted to secure contexts?* It is not.  This is an
> > intervention which is trying to protect the user's privacy, and we would
> > like to ensure the protections would be applicable to non-secure contexts
> > as well.  Arguably these protections are even more important for non-secure
> > contexts given the fact that cookies set through document.cookie would be
> > visible to 

Re: Intent to implement: Limit the maximum life-time of cookies set through document.cookie to seven days

[zan]

On Fri, Mar 8, 2019, at 1:31 AM, Ehsan Akhgari wrote:
> *Summary*: As part of the anti-tracking project, we'd like to experiment
> with a new feature in order to mitigate the impact of third-party tracking
> scripts running in top-level documents.  As we are planning to start
> removing the storage capabilities of third-party trackers, which removes
> their ability to store unique identifiers for each client in cookies which
> would be transmitted to servers across websites, a number of cross-site
> trackers have started to switch to using first-party cookies to store their
> unique identifiers.  The way that this works typically is through
> annotating outbound links to the target website with a unique query string
> parameter, and then reading and storing that unique parameter in the
> first-party cookie storage through the third-party scripts that they
> control which are running in the context of the top-level target site when
> the user follows such a link.
> 
> This is bad because it would allow cross-site trackers to keep tracking the
> user through a unique identifier, but it would also expose the unique
> identifier used by tracker1 to all of the other trackers that have active
> code running on the page, which would allow them to sync up each others'
> tracking identifiers without resorting to practices such as cookie syncing <
> https://clearcode.cc/blog/cookie-syncing/>.
> 
> We'd like to experiment with imposing a short maximum life-time on cookies
> set through document.cookie in order to ensure that these unique
> identifiers would expire relatively quickly once they are established, and
> wouldn't allow cross-site trackers to establish a pervasive permanent
> unique identifier.  We're picking seven days to be compatible with Safari
> which has been shipping this for a while now <
> https://webkit.org/blog/8613/intelligent-tracking-prevention-2-1/>.
> 
> *Bug*: This was implemented originally in (disabled by default)
> https://bugzilla.mozilla.org/show_bug.cgi?id=1529836.  The bug to enable
> this on Nightly is https://bugzilla.mozilla.org/show_bug.cgi?id=1533584.
> *Link to standard*: No public standard change has been made for this
> feature yet.  We should modify the cookie RFC when we know more about
> whether we would like to ship this change or not given that we would be the
> second web engine doing so.
> *Platform coverage*: where will this be available? Everywhere.
> *Estimated or target release*: in which version do you want to/plan to
> release this? Getting enabled in Nightly in 67, staying Nightly only for
> now in order to collect some early feedback.  No estimated target release
> available yet since this is an early exploration.
> *Preference behind which this will be implemented*: if applicable, how can
> interested parties test this before it ships pref'd on by default? The
> preference for this feature, available in Nightly right now, is
> privacy.documentCookies.maxage.  The value of this pref is the maximum
> life-time cap in seconds.  A value of 0 would disable enforcing a cap (0 is
> the current default.)
> *Is this feature enabled by default in sandboxed iframes?* If not, is there
> a proposed sandbox flag to enable it? If allowed, does it preserve the
> current invariants in terms of what sandboxed iframes can do? I'm proposing
> to enable this feature in sandboxed iframes by default.  It will preserve
> the current invariants.
> *DevTools bug*: No specific bug, since devtools already supports showing
> the expiry date of cookies and once this feature gets enabled it will
> correctly display the expiry date for those cookies where Firefox would
> enforce this cap on.
> *Do other browser engines implement this?* Answer with: Safari shipped
> (since version 12.0.x, tested in 12.0.3, announced as part of ITP 2.1
> recently:  >).
> 
> *web-platform-tests*: This is an intervention which different engines do
> not agree on yet.  Creating a web-platform-test for it would be very simple
> but it will be failing in the engines that do not agree with the
> intervention.  I'm not sure what the recommendation for testing these types
> of changes is, would be happy to submit a test if there is a path for
> getting them accepted into wpt.
> 
> *Is this feature restricted to secure contexts?* It is not.  This is an
> intervention which is trying to protect the user's privacy, and we would
> like to ensure the protections would be applicable to non-secure contexts
> as well.  Arguably these protections are even more important for non-secure
> contexts given the fact that cookies set through document.cookie would be
> visible to network MITM attackers after that point.
> 
> Here are the answers to a few other questions which you may have on your
> mind regarding this proposed change.
> 
> *Would this change cause people to get logged out of services?* We believe
> the answer to that should be no, at least for 

Soft code freeze for Firefox 67 starts March 11

[Pascal Chevrel]

Hi all,

On March 11, we will be merging Firefox 67 from mozilla-central to beta
for the first time. In order to avoid invalidating the testing we get
out of late Nightly and the early Developer Edition builds and to ensure
that we can roll out Beta 67 to a wider audience with confidence, we'd
like to ask that any risky changes be avoided from March 11 until after
the version bump to 68 on March 18. Please also be mindful of any
landings late this week or over the weekend as there will be very little
buffer between the first merge and shipping the 67.0b1 builds.

Some reminders for the soft code freeze period:

Do:
- Be ready to backout patches that cause crash spikes, new crashes,
severe regressions
- Monitor new regressions and escalate merge blockers
- Support release management by prioritizing fixing of merge blockers

Do Not:
- Land a risky patch or a large patch
- Land new features (that affects the current Nightly version) — be
mindful that code behind NIGHTLY_BUILD or RELEASE_OR_BETA ifdefs can
lead to unexpected CI results
- Flip prefs that enable new Features that were untested in Nightly cycle
- Plan to kick off new experiments that might impact a feature's merge
readiness

Please let us know if you have any questions/concerns.

Thanks,

Release Management Team

-- 
Pascal Chevrel
Firefox Release Manager
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform