Intent to ship: Redirect Tracking Protection (formerly ETP Cookie Purging)

[Steven Englehardt]

As of July 28th we've started a slow rollout of redirect tracking
protection feature (which we've previously called "ETP Cookie Purging") in
Firefox 79 Desktop. We’ve started with 1% of users and will slowly increase
over the coming weeks. The feature is behind the
privacy.purge_trackers.enabled preference.

Safari shipped a similar protection as part of ITP 2.0 [0] and protections
against bounce tracking are currently being discussed in the Privacy
Community Group [1].

Product: Arthur Edelstein is the product manager for this feature

Bug to turn on by default:
https://bugzilla.mozilla.org/show_bug.cgi?id=1648856.

This feature was previously discussed in this "Intent to prototype" thread:
https://groups.google.com/g/mozilla.dev.platform/c/0JjAHt59j7s.

[0] https://webkit.org/blog/8311/intelligent-tracking-prevention-2-0/
[1] https://github.com/privacycg/proposals/issues/6
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Desktop pinch zooming on in nightly

[Kartikaya Gupta]

Hi all,

In bug 1620055 I've flipped the switch to turn on "desktop zooming"
(aka pinch zooming on desktop) by default on Nightly (starting
tomorrow, probably). We know there are still some issues with this
feature, notably around interacting with scrollbars after zooming, but
we would like to enable it now to get feedback/reports of any other
problems that might exist.

If you do run into problems, please file a bug in "Core :: Panning and
Zooming". If you really need to, you can disable the feature by
setting the pref apz.allow_zooming to false, or through the
experimental features page at about:preferences#experimental

To exercise the feature you can perform "pinch" style gesture on macOS
trackpads, or on Windows/Linux touchscreens [1], or on Windows
high-precision trackpads. Linux high-precision trackpad support is
planned but not yet implemented.

Cheers,
kats

[1] Assuming you have the magic environment variables on Linux to
enable Firefox touch support
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to deprecate: Insecure HTTP

[Daniel Veditz]

You're replying to a 4 year old thread. Don't do that: you're jumping over
4 years of other conversations, and tagged on the end of an old thread
whatever arguments you're making will unseen by a lot of people depending
on how their mail readers work.

Your arguments about HTTPS overhead on poor networks make some sense, but
that tiny amount of data is completely swamped by the average size of a
single image these days, let alone an entire page.

> HTTPS should only be used for sensitive data or stateful queries.

What we've learned from "surveillance capitalism" over the past several
years is that it is _all_ sensitive data.

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

Re: New system for landing + cancelling landing jobs in Lando

[Zeid Zabaneh]

Hi all,

After running various tests on our lower environments, we've run into some
snags due to the limited amount of memory we've allocated for Lando in our
production cluster. Specifically when running some hungry mercurial
commands on `mozilla-central` which are essential for the reliability of
the system. Therefore I'm postponing the deployment of this until early
next week while we adjust the configuration of this cluster to allocate
more memory and run these tests again.

Apologies for this delay. I will send out another update once these issues
are resolved and this is deployed!

Zeid

On Thu, Jul 16, 2020 at 12:20 PM Zeid Zabaneh  wrote:

> Greetings everyone,
>
> The new Lando landing worker system has now been enabled for the below
> repositories. This system is part of Lando, and no longer uses the legacy
> Autoland-Transplant system.
>
>- phabricator-qa-stage (
>https://hg.mozilla.org/automation/phabricator-qa-stage)
>- version-control-tools (
>https://hg.mozilla.org/hgcustom/version-control-tools)
>- build-tools (https://hg.mozilla.org/build/tools/)
>- ci-admin (https://hg.mozilla.org/ci/ci-admin)
>- ci-configuration (https://hg.mozilla.org/ci/ci-configuration)
>- fluent-migration (https://hg.mozilla.org/l10n/fluent-migration)
>- comm-central (https://hg.mozilla.org/comm-central)
>- nspr (https://hg.mozilla.org/projects/nspr)
>- taskgraph (https://hg.mozilla.org/ci/taskgraph)
>- nss (https://hg.mozilla.org/projects/nss)
>
> What should you expect? Things should work the same as they did before. If
> you experience any issues when landing (for example, if a landing is stuck
> in the same state for a very long time, or if you see unexpected behaviour
> or errors) please let me know.
>
> If your repository is in the list above, you will also now have the
> ability to cancel a landing request within a certain time frame after
> submitting it. A "cancel landing request" button will show up after
> submitting a landing. Upon clicking the button, a cancel request will be
> sent. Let me know if you have any questions or if you run into any issues
> with this feature as well.
>
> The above features will be enabled for mozilla-central (
> https://hg.mozilla.org/integration/autoland) next week.
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

New system for landing + cancelling landing jobs in Lando

[Zeid Zabaneh]

Greetings everyone,

The new Lando landing worker system has now been enabled for the below
repositories. This system is part of Lando, and no longer uses the legacy
Autoland-Transplant system.

   - phabricator-qa-stage (
   https://hg.mozilla.org/automation/phabricator-qa-stage)
   - version-control-tools (
   https://hg.mozilla.org/hgcustom/version-control-tools)
   - build-tools (https://hg.mozilla.org/build/tools/)
   - ci-admin (https://hg.mozilla.org/ci/ci-admin)
   - ci-configuration (https://hg.mozilla.org/ci/ci-configuration)
   - fluent-migration (https://hg.mozilla.org/l10n/fluent-migration)
   - comm-central (https://hg.mozilla.org/comm-central)
   - nspr (https://hg.mozilla.org/projects/nspr)
   - taskgraph (https://hg.mozilla.org/ci/taskgraph)
   - nss (https://hg.mozilla.org/projects/nss)

What should you expect? Things should work the same as they did before. If
you experience any issues when landing (for example, if a landing is stuck
in the same state for a very long time, or if you see unexpected behaviour
or errors) please let me know.

If your repository is in the list above, you will also now have the ability
to cancel a landing request within a certain time frame after submitting
it. A "cancel landing request" button will show up after submitting a
landing. Upon clicking the button, a cancel request will be sent. Let me
know if you have any questions or if you run into any issues with this
feature as well.

The above features will be enabled for mozilla-central (
https://hg.mozilla.org/integration/autoland) next week.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: New system for landing + cancelling landing jobs in Lando

[Zeid Zabaneh]

Greetings everyone!

I'm happy to report that the new system for landing as well as the ability
to cancel landing jobs is now deployed and operational for the `autoland`
tree as of 7:45 p.m. UTC. You may have experienced some delays landing
things earlier as we were fixing a couple of issues that came up.

Please let me know if you do experience any unexpected behaviour, or you
can directly file a bug

under Conduit::Lando.

Regards,

Zeid

On Fri, Jul 24, 2020 at 1:48 PM Zeid Zabaneh  wrote:

> Hi all,
>
> After running various tests on our lower environments, we've run into some
> snags due to the limited amount of memory we've allocated for Lando in our
> production cluster. Specifically when running some hungry mercurial
> commands on `mozilla-central` which are essential for the reliability of
> the system. Therefore I'm postponing the deployment of this until early
> next week while we adjust the configuration of this cluster to allocate
> more memory and run these tests again.
>
> Apologies for this delay. I will send out another update once these issues
> are resolved and this is deployed!
>
> Zeid
>
> On Thu, Jul 16, 2020 at 12:20 PM Zeid Zabaneh  wrote:
>
>> Greetings everyone,
>>
>> The new Lando landing worker system has now been enabled for the below
>> repositories. This system is part of Lando, and no longer uses the legacy
>> Autoland-Transplant system.
>>
>>- phabricator-qa-stage (
>>https://hg.mozilla.org/automation/phabricator-qa-stage)
>>- version-control-tools (
>>https://hg.mozilla.org/hgcustom/version-control-tools)
>>- build-tools (https://hg.mozilla.org/build/tools/)
>>- ci-admin (https://hg.mozilla.org/ci/ci-admin)
>>- ci-configuration (https://hg.mozilla.org/ci/ci-configuration)
>>- fluent-migration (https://hg.mozilla.org/l10n/fluent-migration)
>>- comm-central (https://hg.mozilla.org/comm-central)
>>- nspr (https://hg.mozilla.org/projects/nspr)
>>- taskgraph (https://hg.mozilla.org/ci/taskgraph)
>>- nss (https://hg.mozilla.org/projects/nss)
>>
>> What should you expect? Things should work the same as they did before.
>> If you experience any issues when landing (for example, if a landing is
>> stuck in the same state for a very long time, or if you see unexpected
>> behaviour or errors) please let me know.
>>
>> If your repository is in the list above, you will also now have the
>> ability to cancel a landing request within a certain time frame after
>> submitting it. A "cancel landing request" button will show up after
>> submitting a landing. Upon clicking the button, a cancel request will be
>> sent. Let me know if you have any questions or if you run into any issues
>> with this feature as well.
>>
>> The above features will be enabled for mozilla-central (
>> https://hg.mozilla.org/integration/autoland) next week.
>>
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to prototype: cross-fade

[Zeke Medley]

Webkit and Chromium have bugs tracking the issue but it is hard to discern
from them what their plans are (Webkit
, Chromium

).

On Tue, Jul 14, 2020 at 3:18 PM Jeff Muizelaar 
wrote:

> Have other browsers expressed an interest in implementing the new syntax?
>
> On Tue, Jul 14, 2020 at 6:15 PM Zeke Medley  wrote:
> >
> > Summary:
> >
> > cross-fade is a CSS function part of the CSS Image Module Level 4.
> > cross-fade allows for the blending of multiple CSS images with varying
> > opacities. For example:
> >
> > cross-fade(url(“foo.jpg”) 50%,
> >
> >radial-gradient(circle, transparent 50%, black 150%) 50%);
> >
> > might be used to add a vignette effect to an image.
> >
> > Bug link: https://bugzilla.mozilla.org/show_bug.cgi?id=546052
> >
> > Standard: https://drafts.csswg.org/css-images-4/#cross-fade-function
> >
> > Platform coverage: all
> >
> > DevTools bug: none
> >
> > Preference: layout.css.cross-fade.enabled
> >
> > Other browsers:
> >
> > There is an older, implemented syntax. In Safari it is unprefixed and in
> > Blink based browsers it is behind the -webkit prefix. This older version
> > only supports two images at a time and has incompatible syntax with the
> > version in the spec. See this
> >  MDN
> article
> > for more information about how the older implementation differs from the
> > specified one. According to Can I Use
> >  and our own queries on
> > httparchive  this older syntax has very little
> > usage.
> >
> > As it receives little usage and does not align with the current
> cross-fade
> > spec we will implement the newer cross-fade syntax according to the CSSWG
> > specification. As the older syntax will not parse this is unlikely to
> > produce unexpected results for the very limited number of webpages
> > currently using the older cross-fade. For all intents and purposes, if a
> > website still uses the older syntax the status quo will remain in effect
> as
> > Firefox will continue to not implement their cross-fade.
> >
> > Webkit bug 179942 
> seems to
> > track this syntax mismatch.
> >
> > web-platform-tests: Will be implemented as part of bug 546052
> > .
> >
> > Secure Contexts: Enabled in secure contexts, like other similar CSS
> features
> > Is this feature enabled by default in sandboxed iframes? yes
> > ___
> > 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 prototype: cross-fade

[Zeke Medley]

I believe that this is the behavior specified by the CSSWG as well. From
the spec :

> In particular, this means that `cross-fade(white 50%, transparent 50%)`
will produce a partially-transparent solid white image. (Rather than a
partially-transparent gray, which is what you’d get if you averaged the
opaque white and transparent black pixels in non-premultiplied space.)

Is that what you're pointing out? If not, if you could clarify I'd
appreciate it so that we can make sure our implementations are consistent.

On Tue, Jul 14, 2020 at 4:30 PM  wrote:

> Common implementations of crossfade just interpolate the opacity of both
> images, leading to the background "leaking through" for a portion of the
> fade. On a white background, this is a "flash".
>
> If this features gets traction, it is an opportunity to make the "right"
> way the "easy" way. A crossfade between two opaque images, should always be
> opaque.
>
> Good luck! Cheering from the sidelines!
>
> Let me know if I can clarify further.
> ___
> 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 deprecate: Insecure HTTP

[bulk88]

On Monday, April 13, 2015 at 10:57:58 AM UTC-4, Richard Barnes wrote:
> There's pretty broad agreement that HTTPS is the way forward for the web.
> In recent months, there have been statements from IETF [1], IAB [2], W3C
> [3], and even the US Government [4] calling for universal use of
> encryption, which in the case of the web means HTTPS.
> 
> In order to encourage web developers to move from HTTP to HTTPS, I would
> like to propose establishing a deprecation plan for HTTP without security.
> Broadly speaking, this plan would entail  limiting new features to secure
> contexts, followed by gradually removing legacy features from insecure
> contexts.  Having an overall program for HTTP deprecation makes a clear
> statement to the web community that the time for plaintext is over -- it
> tells the world that the new web uses HTTPS, so if you want to use new
> things, you need to provide security.  Martin Thomson and I drafted a
> one-page outline of the plan with a few more considerations here:

For Devs who claim to be crusaders of standards, your standards last little 
more than 1 financial cycle until deprecated and 2 years until removed. TLS has 
observable overhead (more round trips) on all 2G-4G connections vs an 
equivalent cleartext HTTP 1.1. For privileged developers who carry venture 
capital funded client test devices and the most expensive dev machines that 
money can buy funded by Wall Street money, it is easy to throw away all users 
who live in developing nations on budget client hardware or lowest tier 3G or 
4G networks. Cleartext has a place, and until HTTP2/QUIC can get round trips 
and packet size to old cleartext ways on high packet loss, 2G or satellite, or 
the worst monopoly "State Post and Telegraph" 3G mobile networks, HTTPS should 
only be used for sensitive data or stateful queries.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform