Re: PSA: The `mach bootstrap` installed Mercurial `evolve` extension needs an update

[Jonathan Watt]

(Conversation taken to the bug.)
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Soft code freeze for Firefox 72 starts November 25

[Julien Cristau]

The next merge to central will have a 73 milestone, so please consider the
soft freeze lifted.

Thanks,
Julien

On Thu, Nov 21, 2019 at 4:25 PM Julien Cristau  wrote:

> Hi all,
>
> we're fast approaching the start of the 72 beta cycle on December 2nd,
> with our "Feature complete" milestone for 72 tomorrow, November 22nd.
>
> In order to avoid invalidating the testing we get out of late Nightly and
> to ensure that we can roll out Beta 72 to a wider audience with confidence,
> we'd like to ask that any risky changes be avoided from November 25 until
> after the version bump
> to 73 on December 2nd.
>
> Some reminders for the soft code freeze period:
>
> Do:
> - Be ready to back out 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 affect 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 the 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,
> Julien and the Release Management team
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to prototype: Delegate and restrict permission in third party context

[Thomas Nguyen]

On Wednesday, November 27, 2019 at 7:50:46 PM UTC+1, s.h...@gmail.com wrote:
> >Conversely, there would be another attack to link to
> >attacker spaces on already-trusted sites (but no top-level) >and get 
> >silently access too. 
> That is not silent, because user would have already granted permission to 
> that origin to access in previous model.
> 
> 
> >Besides, if a user granted skype.com, the origin is 
> >vulnerable to HTML injection, then when an attacker 
> >requests a permission grant, the users may not have any 
> >context for or understanding of them, that is very 
> >confusing and users tend to accept that request because 
> >they are under a trusted context of the top-level origin.
> So the way you are solving this problem is, instead of showing prompt with 
> iframe’s origin, just delegate permission from top frame or request 
> permission with the origin of top frame? How did that made the situation 
> better? You are ultimately taking away origin indicator from people who 
> understood what it means :(
> 
> I’m really disappointed that Firefox is taking this path.
The idea to change comes from a couple of reasons. One as I mentioned, there 
were attacks, deep linking to attacker spaces on already-trusted sites (not the 
top), and a couple of UI issues that could be resolved by this simplification. 
So sorry if it hurts your, anw, thanks for your idea, we will look into that to 
see if we have any mitigation 
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to prototype: Delegate and restrict permission in third party context

[s . h . h . n . j . k]

>Conversely, there would be another attack to link to
>attacker spaces on already-trusted sites (but no top-level) >and get silently 
>access too. 
That is not silent, because user would have already granted permission to that 
origin to access in previous model.


>Besides, if a user granted skype.com, the origin is 
>vulnerable to HTML injection, then when an attacker 
>requests a permission grant, the users may not have any 
>context for or understanding of them, that is very 
>confusing and users tend to accept that request because 
>they are under a trusted context of the top-level origin.
So the way you are solving this problem is, instead of showing prompt with 
iframe’s origin, just delegate permission from top frame or request permission 
with the origin of top frame? How did that made the situation better? You are 
ultimately taking away origin indicator from people who understood what it 
means :(

I’m really disappointed that Firefox is taking this path.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to prototype: Delegate and restrict permission in third party context

[Thomas Nguyen]

On Monday, November 25, 2019 at 10:38:28 PM UTC+1, s.h...@gmail.com wrote:
> 1. If a user already gave permission to certain origin (e.g. skype.com), and 
> that origin had HTML injection, does that mean attacker can now silently 
> inherit permission from skype.com?
> 
> 2. If so, how can a website mitigate the risk of permission being silently 
> taken to third party website?
Yes, I agree it might be a thing we should consider because we grant permission 
access broader. However, if the origin is vulnerable, I don't think we could 
protect more. If you have granted access to the origin, the origin can expose 
data to other via postMessage (or other mechanisms).
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to prototype: Delegate and restrict permission in third party context

[s . h . h . n . j . k]

1. If a user already gave permission to certain origin (e.g. skype.com), and 
that origin had HTML injection, does that mean attacker can now silently 
inherit permission from skype.com?

2. If so, how can a website mitigate the risk of permission being silently 
taken to third party website?
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Proposed W3C Charter: Web Payments Working Group

[L. David Baron]

The W3C is proposing a revised charter for:

  Web Payments Working Group
  https://www.w3.org/Payments/WG/charter-201910.html
  https://lists.w3.org/Archives/Public/public-new-work/2019Nov/0003.html

The differences from the previous charter are:
  
https://services.w3.org/htmldiff?doc1=https%3A%2F%2Fwww.w3.org%2FPayments%2FWG%2Fcharter-201803.html=https%3A%2F%2Fwww.w3.org%2FPayments%2FWG%2Fcharter-201910.html

Mozilla has the opportunity to send comments or objections through
Friday, December 13.

Please reply to this thread if you think there's something we should
say as part of this charter review, or if you think we should
support or oppose it.


(My one note so far is that the charter should link to the previous
charter; it currently only links to the charter before that.)

-David

-- 
턞   L. David Baron http://dbaron.org/   턂
턢   Mozilla  https://www.mozilla.org/   턂
 Before I built a wall I'd ask to know
 What I was walling in or walling out,
 And to whom I was like to give offense.
   - Robert Frost, Mending Wall (1914)
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

PSA: Expect decision task bustage from pushes using |mach try again| after pulling central

[Andrew Halberstadt]

Hey everyone,

Bug 1496768  changed
the format of try_task_config.json, the mechanism
we use to pass context surrounding your try pushes to the decision task.
Since `mach try again` works by saving generated `try_task_configs` in a
history file, using it with a config generated prior to bug 1496768 on
revision
after same could break the decision task (it's also possible it won't,
depends
which arguments you specified).

In other words, you'll need to create new history and then `mach try again`
will start working again. If you *really* need to save a push, you can edit
the file manually. Run this command to find the history file:

 $ ./mach python -c "from mozboot.util import get_state_dir;
print(get_state_dir(srcdir=True)+'/history/try_task_configs.json')"

Feel free to reach out to me if you need help doing this.
Sorry for the inconvenience!
- Andrew
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Opt your try pushes into Pernosco

[Kyle Huey via dev-platform]

On Mon, Nov 25, 2019 at 10:16 AM Valentin Gosu 
wrote:

> On Mon, 25 Nov 2019 at 18:29, Andrew Halberstadt  wrote:
>
>> Hi everyone,
>>
>> As of now, you can opt-in to Pernosco  analysis on
>> your
>> try pushes by running:
>>
>> $ ./mach try fuzzy --pernosco
>>
>> or:
>>
>> $ ./mach try chooser --pernosco
>>
>> For those who are unaware, Pernosco is a debugging service built on top of
>> rr. It will analyze your try push for failures, attempt to record the
>> failures
>> with rr, then e-mail you a link to a live debugging session. Allow a few
>> hours
>> after your task has finished for the Pernosco recording to complete.
>>
>> There are several limitations:
>>
>> 1. It only works with Linux x64 debug tests
>> 2. Failure should be reproducible (otherwise the recording might not
>> capture it)
>> 3. An @mozilla.com e-mail address is required to log-in to the service
>> (./mach
>> try will fail early if you don't have this)
>>
>
> I only have push permissions on my @gmail account, not on my @mozilla.com
> one.
> Does this mean I can't trigger a --pernosco try build, or that I need to
> log with my @moz email in order to use Pernosco?
>

The latter. To log into Pernosco you need to have your @mozilla.com email
address listed on your Github account (doesn't have to be public). We can
whitelist people for whom that poses an issue if necessary.

- Kyle


>
>
>> 4. Artifact builds are not yet supported (see bug 1598142
>> )
>>
>> Previously we were using a whitelist of developers to control which pushes
>> were
>> analyzed. For now this whitelist continues to exist. If you are on it, you
>> can opt
>> out of Pernosco by passing in `--no-pernosco`.
>>
>> Thanks to Kyle Huey for updating the Pernosco infrastructure to support
>> this
>> flag.
>>
>> Let me know if you have any questions.
>> Cheers,
>> Andrew
>> ___
>> 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: Delegate and restrict permission in third party context

[Nils Ohlmeier]

Hi Thomas,

Thank you for pushing feature policy over the finish line and making the web a 
safer place!

Best
  Nils Ohlmeier

> On 25Nov, 2019, at 04:41, Thomas Nguyen  wrote:
> 
> Summary: People don’t have a good understanding of iframes, because
> generally, no UI indicates that iframes are visible on a page, or what
> their origin is. Permission requests from iframes cause significant
> confusion for users because it is hard to determine where the requests come
> from, as the address bar does not match the site in the permission prompt.
> 
> Currently, Firefox allows iframes on a site to make permission requests and
> show up a permission prompt using the origin of the iframes. A user making
> a decision based on the third party context presented in the notification
> prompt is complicated and confusing. This confusion is exacerbated when
> managing previously stored permission decisions.
> 
> To address this problem, we would like to impose a restriction on
> permissions coming from third party context. There would be two main
> changes proposed:
> 
>   -
> 
>   Give an ability to delegate permissions from first party to third party
>   embedded iframes, and impose a restriction to embedded iframes to request
>   permission only when the iframe’s embedder has explicitly delegated it. The
>   permission request will use the top level origin to show in the prompt,
>   then users are only required to make permission decisions about the first
>   party context.
>   -
> 
>  This change is dependent on the ability of Feature Policy to disable
>  permissions by default in cross-origin iframes. It will require a site to
>  explicitly allow permissions for cross-origin iframes (setting allow
>  attribute, e.g allow=”geolocation”) otherwise, the permission
> requests will
>  be denied on that iframes.
>  -
> 
>  The change will be applied to geolocation, camera, microphone and
>  screen-sharing permission, and fullscreen request.
> 
> 
>   -
> 
>   Completely deny permissions from third party context for vibration,
>   notification, and persistent-storage permission.
> 
> 
> The plan is:
> 
>   -
> 
>   Enable Feature Policy allow attribute.
>   -
> 
>   Make permission camera/microphone/geolocation/display-capture/fullscreen
>   disabled by default in third-party iframe.
>   -
> 
>   Delegate Permissions: only cross-origin iframes that have explicit
>   delegated permission from their parent through the allow attribute will
>   have the right to make permission requests.
>   -
> 
>   Reduce the number of supported features to geolocation, camera,
>   microphone screen-sharing, and fullscreen (the above features are supported
>   for permissions UI with notification prompts, except fullscreen). And we
>   will move all other features to experimental phrase under a user preference
>   which is disabled by default.
>   -
> 
>   Simplify prompts/dialogs to only contain the top-level origin.
>   -
> 
>   Deny vibration, persistent-storage permission from third party iframe
>   (notification permission was disabled in third party context,  just do some
>   minor refactors).
> 
> 
> 
> 
> Bug: The tracking bug https://bugzilla.mozilla.org/show_bug.cgi?id=1572461
> 
> Standard: Feature Policy
> https://w3c.github.io/webappsec-feature-policy/#iframe-allow-attribute
> 
> Platform coverage: All.
> 
> Preference:
> 
> dom.security.featurePolicy.experimental.enabled: disabled by default, we
> will limit supported features in Feature Policy to geolocation, camera,
> microphone, fullscreen, display-capture and move others to experimental
> phase.
> 
> permissions.delegate.enabled: enabled by default
> 
> dom.security.featurePolicy.enabled: this pref is implemented in Firefox 65
> but enabled by default in Nightly only
> 
> Other browsers: Chrome supports permission delegation from Chrome 71.
> 
> web-platform-tests: We only have web platform tests for feature policy but
> not permission delegation
> 
> Some of Feature Policy web-platform-tests that the permissions are disabled
> by default in cross origin iframe:
> 
> https://searchfox.org/mozilla-central/source/testing/web-platform/meta/feature-policy
> 
> testing /web-platform
> /tests
> /
> permissions
> 
> /feature-policy-permissions-query.html
> 
> 
> testing /web-platform
> /tests
> /
> mediacapture-streams
> 

Re: Opt your try pushes into Pernosco

[Andrew Halberstadt]

On Mon, Nov 25, 2019 at 1:33 PM Kyle Huey  wrote:

>
> On Mon, Nov 25, 2019 at 10:16 AM Valentin Gosu 
> wrote:
>
>> I only have push permissions on my @gmail account, not on my @mozilla.com
>> one.
>> Does this mean I can't trigger a --pernosco try build, or that I need to
>> log with my @moz email in order to use Pernosco?
>>
>
> The latter. To log into Pernosco you need to have your @mozilla.com email
> address listed on your Github account (doesn't have to be public). We can
> whitelist people for whom that poses an issue if necessary.
>

Actually, also the former. I put in a check to prevent pushing without an @
mozilla.com
e-mail to avoid wasting resources and time. It'll currently error out,
though the error is
entirely superficial. Maybe we can change it to a prompt or implement some
kind of
`--force` flag to by-pass it. I filed bug 1599267
.

For now you can comment this line out:
https://searchfox.org/mozilla-central/rev/0678172d5b5c681061b904c776b668489e3355b0/tools/tryselect/templates.py#144

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

Re: Intent to prototype: Delegate and restrict permission in third party context

[Thomas Nguyen]

On Wednesday, November 27, 2019 at 4:55:35 PM UTC+1, s.h...@gmail.com wrote:
> How will you leak Geo Location, Camera data, etc, using HTML injecting? I’m 
> saying the origin is vulnerable to HTML injection, and origin is not 
> malicious.
Thanks, yes, that is a consideration we should care about, of giving broader 
permission access and obviously, this is not ideal. I have not added any 
mitigation to the implementation yet. 
Conversely, there would be another attack to link to attacker spaces on 
already-trusted sites (but not top-level) and get silently access too. I think 
there would be a trade-off between them. Besides, if a user granted skype.com, 
the origin is vulnerable to HTML injection, then when an attacker requests a 
permission grant, the users may not have any context for or understanding of 
them, that is very confusing and users tend to accept that request because they 
are under a trusted context of the top-level origin.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: PSA: The `mach bootstrap` installed Mercurial `evolve` extension needs an update

[Gijs Kruitbosch]

Note that running `./mach vcs-setup` will do this, when it prompts:


It looks like the setup wizard has already installed a copy of the
evolve extension on your machine, at {evolve_dir}.

(Relevant config option: extensions.evolve)

Would you like to update evolve to the latest version?  (Yn)


and `./mach bootstrap` offers to run that for you, with the prompt:


Mozilla recommends a number of changes to Mercurial to enhance your
experience with it.

Would you like to run a configuration wizard to ensure Mercurial is
optimally configured? (Yn):


So, if you answer Y or just hit enter on both these prompts, this 
already happens.


~ Gijs

On 02/12/2019 09:40, Jonathan Watt wrote:

Mercurial was broken for me this morning after updating Homebrew packages on
macOS. It seem that `mach bootstrap` does not yet update it's copy of the
Evolution extension to be sufficiently new. An `hg pull -u` in
`$HOME/.mozbuild/evolve` fixes things.

I filed https://bugzilla.mozilla.org/show_bug.cgi?id=1600559 to fix `mach
bootstrap`.

-Jonathan



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

Re: Intent to prototype: Delegate and restrict permission in third party context

[s . h . h . n . j . k]

How will you leak Geo Location, Camera data, etc, using HTML injecting? I’m 
saying the origin is vulnerable to HTML injection, and origin is not malicious.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

PSA: The `mach bootstrap` installed Mercurial `evolve` extension needs an update

[Jonathan Watt]

Mercurial was broken for me this morning after updating Homebrew packages on
macOS. It seem that `mach bootstrap` does not yet update it's copy of the
Evolution extension to be sufficiently new. An `hg pull -u` in
`$HOME/.mozbuild/evolve` fixes things.

I filed https://bugzilla.mozilla.org/show_bug.cgi?id=1600559 to fix `mach
bootstrap`.

-Jonathan

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

Intent to prototype: Character encoding detector

[Henri Sivonen]

# Summary

The template says this section should state the benefit to Web
developers. There is intentionally no benefit to Web developers. This
pair of features is meant to benefit users who encounter
badly-authored legacy pages, so that Firefox can retain users instead
of the users trying in Chrome on the new Edge. That is, this is about
the user experience of browsing the legacy long tail of the Web. This
is not about cool new stuff. In that sense, this feature is out of the
scope of "Intent to prototype" emails, but I'm sending one, because
this is a Web-visible feature in the sense that Web content could
detect its presence.

For newly-authored HTML pages, Web developers should use UTF-8 and
declare it (via UTF-8 BOM, , or HTTP Content-Type:
text/html; charset=utf-8). The first and last option apply to
text/plain, too.

With that out of the way, there are two features contemplated here:

1. On _unlabeled_ text/html and text/plain pages, autodetect _legacy_
encoding, excluding UTF-8, for non-file: URLs and autodetect the
encoding, including UTF-8, for file: URLs.

Elevator pitch: Chrome already did this unilaterally. The motivation
is to avoid a situation where a user switches to a Chromium-based as a
result of browsing the legacy Web or local files.

As in Chrome, UTF-8 is deliberately excluded from possible detection
outcomes on non-file: URLs in order to avoid creating a situation
where the feature would have an unwanted effect on future Web
development by causing Web developers to rely on UTF-8 detection,
which would make the platform more brittle. That is, one type of
user-facing problem is deliberately left unfixed in order to avoid a
feedback loop into authoring that would generate more of the problem.
However, feature #2 below continues to allow users to address this
problem at the cost of taking an explicit menu action.

(Full discussion of the implications of detecting UTF-8 for HTML on
non-file: URLs needs a blog post, which I intend to write but which is
out of scope for this summary. Detecting UTF-8 for text/plain would be
less problematic, since there are no scripts and stylesheets that the
encoding would get inherited into and a reload wouldn't re-run any
script side effects, so I'm willing to entertain the idea of detecting
UTF-8 on non-file: text/plain, but it seems like a slippery slope.)

(Why now? Edge switching from the "like Safari" camp to the "like
Chrome" camp made it seem substantially less likely that everyone
would agree to get rid of guessing, so it no longer makes sense to
push for that outcome for the Web Platform. Also, now that UTF-8 has
clearly won for new Web development, this feature is likely to be less
harmful that it could have been in the past.)

2. Replace the Text Encoding submenu with a single menu item Override
Text Encoding, which forces the detector to run in a mode that ignores
the TLD hint and allows UTF-8 as an outcome.

(Disabled in the situations where the menu is presently disabled and
not taking effect in the situations where the menu presently does not
take effect. The menu is presently disabled if the top-level page is
in UTF-8 and valid, the top-level page started with a BOM, the
top-level page is UTF-16[BE|LE], or the top-level page is neither
text/html nor text/plain. The menu presently doesn't take effect if
the type of the page is neither text/html nor text/plain, the HTTP
layer declared UTF-16[BE|LE], or stream starts with a BOM. [As you can
see, the latter list is a subset of the former, so it should be
possible for the latter list to matter only for framed documents.])

Elevator pitch: Telemetry shows a) a substantial proportion of menu
use is for overriding _labeled_ pages and b) a substantial proportion
of menu use is to override an already overridden encoding suggesting
that users are bad at making a choice from the menu. Retaining a
user-invocable override continues to address the issue of mislabeled
content (which is presently addressed by Firefox and by desktop Safari
by providing the menu) while eliminating the need for the user to
figure out what to choose.

(Basically, feature #2 is easy to provide once feature #1 exists.)

# Bug

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

# Standard

The HTML Standard authorizes the existence of this kind of component
without specifying exactly how it should work.

Beyond that, there is no standard, but the implementation developed
here has deliberately been created in such a way that contributing the
data tables to the WHATWG and reversing the code into spec English
would be _possible_ if there's cross-vendor interest. In contrast, the
code in Chromium is a non-Chromium-originating over-the-wall dump of
mystery (lacking public design documentation as well as tooling for
regenerating the generated parts) C++ that even the Chrome developers
can't/won't change beyond making it compile with newer
compilers.(Furthermore, my implementation relies on the browser
already containing an 

Removing "clipboard" tag for mochitest

[Julian Descottes]

The `clipboard` tag was used as a workaround to run clipboard tests on a
separate platform.
This workaround was removed in
https://bugzilla.mozilla.org/show_bug.cgi?id=1546459, making the tag
useless for automation.

I plan to remove all the `clipboard` tags from the codebase in
https://bugzilla.mozilla.org/show_bug.cgi?id=1600333 .
https://searchfox.org/mozilla-central/search?q=tags+%3F%3D+%3F.*clipboard=false=true=

If you are still using those tags for other reasons (eg custom try
pushes?), please let us know.
Will wait for a few days before moving forward with the removal.

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

[desktop] Bugs logged by Desktop Release QA in the last 7 days

[Mihai Boldan]

Hello,

Here's the list of new issues found and filed by the Desktop Release QA 
team in the last 7 days.
Additional details on the team's priorities last week, as well as the 
plans for the current week are available at: https://tinyurl.com/y2atdpjj.

Bugs logged by Desktop Release QA in the last 7 days:
*
*Firefox: Bookmarks & History
* NEW - https://bugzil.la/1600024 - [macOS] Pressing Enter didn't 
trigger the click event on the button


Firefox: Enterprise Policies
* NEW - https://bugzil.la/167 - The Enterprise Policies service is 
active but there are no policies enabled


Core: General
* NEW - https://bugzil.la/1600275 - "Share this story" on BBC with 
integrated e-mail has strange behavior


Core: Graphics
* NEW - https://bugzil.la/1599989 - [ESR68] Visual glitches when 
hovering over Tab bar and URL bar after disabling hardware acceleration 
and setting gfx.content.azure.backends to cairo


Core: Networking: DNS
* NEW - https://bugzil.la/1599816 - Requests are being handled via TRR 
while connected to a PPTP VPN server
* NEW - https://bugzil.la/1600343 - ICS domains are not being 
successfully parsed


DevTools: General
* NEW - https://bugzil.la/1599059 - Navigation between about:config and 
WebPages can break DevTools

* NEW - https://bugzil.la/1599073 - Add a min width for the Toolbox window

DevTools: What's New
* NEW - https://bugzil.la/1599014 - DevTools WNP - compensate margins so 
content is not pushed when scrollbar is enabled or hidden
* NEW - https://bugzil.la/1599028 - DevTools WNP - Instantly Send Tabs 
to Mobile container missing on dark theme
* NEW - https://bugzil.la/1599036 - DevTools WNP - Touchscreen - 
mismatch after scroll / selection in list items
* NEW - https://bugzil.la/1599039 - DevTools WNP - Right clicking links 
from the new tab page, focuses them only
* NEW - https://bugzil.la/1599064 - DevTools WNP - First time dragging a 
link to NewTab will make DevTools refresh itself


Toolkit: Application Update
* NEW - https://bugzil.la/1599821 - WNP page is not displayed for some 
supported locales (be and en-GB)
* NEW - https://bugzil.la/1600293 - [ARM64] “install of partial patch 
failed, downloading complete patch” error in browser console when 
updating from Firefox 69.0.2 and above to Firefox 71.0


Release Engineering: Release Automation: Updates
* VERIFIED FIXED - https://bugzil.la/1600046 - ESR version locked to 
60.9 ESR if updating from releases before it


This is available as a Bugzilla bug list as well: 
https://tinyurl.com/t8v9a5q.


Regards,
Mihai Boldan


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

Re: Intent to prototype: Delegate and restrict permission in third party context

[Thomas Nguyen]

On Tuesday, November 26, 2019 at 1:03:01 AM UTC+1, kgil...@mozilla.com wrote:
> On Monday, November 25, 2019 at 9:29:10 AM UTC-8, Thomas Nguyen wrote:
> > Summary: People don’t have a good understanding of iframes, because
> > generally, no UI indicates that iframes are visible on a page, or what
> > their origin is. Permission requests from iframes cause significant
> > confusion for users because it is hard to determine where the requests come
> > from, as the address bar does not match the site in the permission prompt.
> > 
> > Currently, Firefox allows iframes on a site to make permission requests and
> > show up a permission prompt using the origin of the iframes. A user making
> > a decision based on the third party context presented in the notification
> > prompt is complicated and confusing. This confusion is exacerbated when
> > managing previously stored permission decisions.
> > 
> > To address this problem, we would like to impose a restriction on
> > permissions coming from third party context. There would be two main
> > changes proposed:
> > 
> >-
> > 
> >Give an ability to delegate permissions from first party to third party
> >embedded iframes, and impose a restriction to embedded iframes to request
> >permission only when the iframe’s embedder has explicitly delegated it. 
> > The
> >permission request will use the top level origin to show in the prompt,
> >then users are only required to make permission decisions about the first
> >party context.
> >-
> > 
> >   This change is dependent on the ability of Feature Policy to disable
> >   permissions by default in cross-origin iframes. It will require a 
> > site to
> >   explicitly allow permissions for cross-origin iframes (setting allow
> >   attribute, e.g allow=”geolocation”) otherwise, the permission
> > requests will
> >   be denied on that iframes.
> >   -
> > 
> >   The change will be applied to geolocation, camera, microphone and
> >   screen-sharing permission, and fullscreen request.
> > 
> > 
> >-
> > 
> >Completely deny permissions from third party context for vibration,
> >notification, and persistent-storage permission.
> > 
> > 
> > The plan is:
> > 
> >-
> > 
> >Enable Feature Policy allow attribute.
> >-
> > 
> >Make permission camera/microphone/geolocation/display-capture/fullscreen
> >disabled by default in third-party iframe.
> >-
> > 
> >Delegate Permissions: only cross-origin iframes that have explicit
> >delegated permission from their parent through the allow attribute will
> >have the right to make permission requests.
> >-
> > 
> >Reduce the number of supported features to geolocation, camera,
> >microphone screen-sharing, and fullscreen (the above features are 
> > supported
> >for permissions UI with notification prompts, except fullscreen). And we
> >will move all other features to experimental phrase under a user 
> > preference
> >which is disabled by default.
> >-
> > 
> >Simplify prompts/dialogs to only contain the top-level origin.
> >-
> > 
> >Deny vibration, persistent-storage permission from third party iframe
> >(notification permission was disabled in third party context,  just do 
> > some
> >minor refactors).
> > 
> > 
> > 
> > 
> > Bug: The tracking bug https://bugzilla.mozilla.org/show_bug.cgi?id=1572461
> > 
> > Standard: Feature Policy
> > https://w3c.github.io/webappsec-feature-policy/#iframe-allow-attribute
> > 
> > Platform coverage: All.
> > 
> > Preference:
> > 
> > dom.security.featurePolicy.experimental.enabled: disabled by default, we
> > will limit supported features in Feature Policy to geolocation, camera,
> > microphone, fullscreen, display-capture and move others to experimental
> > phase.
> > 
> > permissions.delegate.enabled: enabled by default
> > 
> > dom.security.featurePolicy.enabled: this pref is implemented in Firefox 65
> > but enabled by default in Nightly only
> > 
> > Other browsers: Chrome supports permission delegation from Chrome 71.
> > 
> > web-platform-tests: We only have web platform tests for feature policy but
> > not permission delegation
> > 
> > Some of Feature Policy web-platform-tests that the permissions are disabled
> > by default in cross origin iframe:
> > 
> > https://searchfox.org/mozilla-central/source/testing/web-platform/meta/feature-policy
> > 
> > testing /web-platform
> > /tests
> > /
> > permissions
> > 
> > /feature-policy-permissions-query.html
> > 
> > 
> > testing 

Proposed W3C Charter: Web of Things Working Group

[L. David Baron]

The W3C is proposing a revised charter for:

  Web of Things Working Group
  https://www.w3.org/2019/11/proposed-wot-wg-charter-2019.html
  https://lists.w3.org/Archives/Public/public-new-work/2019Nov/0005.html

The differences from the previous charter are:
https://services.w3.org/htmldiff?doc1=https%3A%2F%2Fwww.w3.org%2F2016%2F12%2Fwot-wg-2016.html=https%3A%2F%2Fwww.w3.org%2F2019%2F11%2Fproposed-wot-wg-charter-2019.html

Mozilla has the opportunity to send comments or objections through
Tuesday, December 17.

Please reply to this thread if you think there's something we should
say as part of this charter review, or if you think we should
support or oppose it.

-David

-- 
턞   L. David Baron http://dbaron.org/   턂
턢   Mozilla  https://www.mozilla.org/   턂
 Before I built a wall I'd ask to know
 What I was walling in or walling out,
 And to whom I was like to give offense.
   - Robert Frost, Mending Wall (1914)
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to prototype: Delegate and restrict permission in third party context

[Thomas Nguyen]

On Tuesday, November 26, 2019 at 1:03:01 AM UTC+1, kgil...@mozilla.com wrote:
> On Monday, November 25, 2019 at 9:29:10 AM UTC-8, Thomas Nguyen wrote:
> > Summary: People don’t have a good understanding of iframes, because
> > generally, no UI indicates that iframes are visible on a page, or what
> > their origin is. Permission requests from iframes cause significant
> > confusion for users because it is hard to determine where the requests come
> > from, as the address bar does not match the site in the permission prompt.
> > 
> > Currently, Firefox allows iframes on a site to make permission requests and
> > show up a permission prompt using the origin of the iframes. A user making
> > a decision based on the third party context presented in the notification
> > prompt is complicated and confusing. This confusion is exacerbated when
> > managing previously stored permission decisions.
> > 
> > To address this problem, we would like to impose a restriction on
> > permissions coming from third party context. There would be two main
> > changes proposed:
> > 
> >-
> > 
> >Give an ability to delegate permissions from first party to third party
> >embedded iframes, and impose a restriction to embedded iframes to request
> >permission only when the iframe’s embedder has explicitly delegated it. 
> > The
> >permission request will use the top level origin to show in the prompt,
> >then users are only required to make permission decisions about the first
> >party context.
> >-
> > 
> >   This change is dependent on the ability of Feature Policy to disable
> >   permissions by default in cross-origin iframes. It will require a 
> > site to
> >   explicitly allow permissions for cross-origin iframes (setting allow
> >   attribute, e.g allow=”geolocation”) otherwise, the permission
> > requests will
> >   be denied on that iframes.
> >   -
> > 
> >   The change will be applied to geolocation, camera, microphone and
> >   screen-sharing permission, and fullscreen request.
> > 
> > 
> >-
> > 
> >Completely deny permissions from third party context for vibration,
> >notification, and persistent-storage permission.
> > 
> > 
> > The plan is:
> > 
> >-
> > 
> >Enable Feature Policy allow attribute.
> >-
> > 
> >Make permission camera/microphone/geolocation/display-capture/fullscreen
> >disabled by default in third-party iframe.
> >-
> > 
> >Delegate Permissions: only cross-origin iframes that have explicit
> >delegated permission from their parent through the allow attribute will
> >have the right to make permission requests.
> >-
> > 
> >Reduce the number of supported features to geolocation, camera,
> >microphone screen-sharing, and fullscreen (the above features are 
> > supported
> >for permissions UI with notification prompts, except fullscreen). And we
> >will move all other features to experimental phrase under a user 
> > preference
> >which is disabled by default.
> >-
> > 
> >Simplify prompts/dialogs to only contain the top-level origin.
> >-
> > 
> >Deny vibration, persistent-storage permission from third party iframe
> >(notification permission was disabled in third party context,  just do 
> > some
> >minor refactors).
> > 
> > 
> > 
> > 
> > Bug: The tracking bug https://bugzilla.mozilla.org/show_bug.cgi?id=1572461
> > 
> > Standard: Feature Policy
> > https://w3c.github.io/webappsec-feature-policy/#iframe-allow-attribute
> > 
> > Platform coverage: All.
> > 
> > Preference:
> > 
> > dom.security.featurePolicy.experimental.enabled: disabled by default, we
> > will limit supported features in Feature Policy to geolocation, camera,
> > microphone, fullscreen, display-capture and move others to experimental
> > phase.
> > 
> > permissions.delegate.enabled: enabled by default
> > 
> > dom.security.featurePolicy.enabled: this pref is implemented in Firefox 65
> > but enabled by default in Nightly only
> > 
> > Other browsers: Chrome supports permission delegation from Chrome 71.
> > 
> > web-platform-tests: We only have web platform tests for feature policy but
> > not permission delegation
> > 
> > Some of Feature Policy web-platform-tests that the permissions are disabled
> > by default in cross origin iframe:
> > 
> > https://searchfox.org/mozilla-central/source/testing/web-platform/meta/feature-policy
> > 
> > testing /web-platform
> > /tests
> > /
> > permissions
> > 
> > /feature-policy-permissions-query.html
> > 
> > 
> > testing 

Proposed W3C Charter: Second Screen Working Group

[L. David Baron]

The W3C is proposing a revised charter for:

  Second Screen Working Group
  https://w3c.github.io/secondscreen-charter/
  https://lists.w3.org/Archives/Public/public-new-work/2019Nov/.html

The differences from the previous charter are:
https://services.w3.org/htmldiff?doc1=https%3A%2F%2Fwww.w3.org%2F2014%2Fsecondscreen%2Fcharter-2018.html=https%3A%2F%2Fw3c.github.io%2Fsecondscreen-charter%2F

Mozilla has the opportunity to send comments or objections through
Friday, December 6.

Please reply to this thread if you think there's something we should
say as part of this charter review, or if you think we should
support or oppose it.


I'm inclined to be supportive of this charter.  In the past we've
encouraged this group to have a standard protocol rather than
building an API that wraps proprietary APIs (such as Google Cast or
AirPlay); this charter appears to move significantly in that
direction relative to the previous charter.  That said, I don't
think anybody from Mozilla is currently participating in this work,
and I haven't looked into the current approach in much detail.

-David

-- 
턞   L. David Baron http://dbaron.org/   턂
턢   Mozilla  https://www.mozilla.org/   턂
 Before I built a wall I'd ask to know
 What I was walling in or walling out,
 And to whom I was like to give offense.
   - Robert Frost, Mending Wall (1914)
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship: WebXR Device API in Firefox Nightly

[kgilbert]

On Tuesday, August 28, 2018 at 5:16:14 PM UTC-7, kgil...@mozilla.com wrote:
> Hi David,
> 
> These are all great points, thanks for reviewing this.
> 
> The intent is to not allow WebXR in any iframe (not just sandboxed ones), 
> until the discussions have settled.  I appreciate the feedback on the feature 
> policy approach and how the origin would be presented to the user.
> 
> Much of the recent activity in the community group is related to session 
> creation, ensuring that each UA can prompt the user in the most appropriate 
> way without affecting content.  The prompts may vary, for example, if using a 
> headset connected to a traditional PC versus an all-in-one VR computer such 
> as the "Oculus Go".  Some vendors may opt to present more granular 
> information about a WebXR presentation request (eg, notify user that site is 
> requesting specific geometry for world understanding and to present to their 
> full FOV) while others may opt to present a catch-all (eg, the site is 
> requesting access to all your sensors and camera feed).
> 
> I'll raise the concern about about delegation and what domain to associate 
> with in the community group.  This is a very good point.
> 
> The intent is to follow a fail-safe approach, that will not result in sites 
> working now that would break later.  If the specifics on iframe WebXR usage 
> are settled before implementation is complete, I hope to also enable iframe 
> WebXR usage accordingly.
> 
> On Tuesday, August 7, 2018 at 2:07:06 PM UTC-7, David Baron wrote:
> > On Monday 2018-07-30 17:03 -0700, Kip Gilbert wrote:
> > > Is this feature enabled by default in sandboxed iframes?
> > > WebXR will not be enabled by default in sandboxed iframes.  This will 
> > > likely be enabled later, by use of Feature Policy: 
> > > https://github.com/immersive-web/webxr/issues/86 
> > > 
> > 
> > I'm curious why this is specific to sandboxed iframes, rather than,
> > say, any cross-origin iframes (and perhaps also same-origin
> > sandboxed ones).
> > 
> > That said, some of this concern comes from not being sure what it
> > looks like to a user if a page wants to use XR.  Is there some sort
> > of permission prompt or request that the user sees first?
> > 
> > If there is... what domain is it associated with?
> > 
> > One of the goals of feature policy is to allow permission requests
> > be *associated* only with the toplevel page.  This is useful since
> > permission requests coming from subframes aren't particularly
> > meaningful and are also confusing -- they don't correspond to the
> > URL bar, it's not clear what persisting them would mean, etc.
> > 
> > A page would be able to use feature policy to delegate their ability
> > to use/request capabilities to a cross-origin frame.  Without that
> > delegation a cross-origin subframe would not have access to the
> > capability; with the delegation requests from the cross-origin frame
> > would appear as though they come from the toplevel document (and if
> > remembered, would be remembered as such).
> > 
> > *If* something like that is the model here, then maybe a
> > cross-origin iframes restriction rather than a sandbox iframes
> > restriction makes more sense.
> > 
> > -David
> > 
> > -- 
> > 턞   L. David Baron http://dbaron.org/   턂
> > 턢   Mozilla  https://www.mozilla.org/   턂
> >  Before I built a wall I'd ask to know
> >  What I was walling in or walling out,
> >  And to whom I was like to give offense.
> >- Robert Frost, Mending Wall (1914)

There has been much work in the W3C Immersive-Web Working Group on WebXR since 
this original intent-to-implement-and-ship thread was started.

The spec is now stable, without anticipated breaking changes.  Other vendors 
will also be imminently shipping WebXR.

WebXR will now be using feature-policy:

https://www.w3.org/TR/webxr/#feature-policy

Earlier today, Mozilla posted "Intent to prototype: Delegate and restrict 
permission in third party context":

https://groups.google.com/forum/#!topic/mozilla.dev.platform/BdFOMAuCGW8

WebXR will utilize this system to allow delegation.

The WebXR spec has been split into modules, similar to those used for CSS.  We 
intend to ship the "WebXR Core" and "WebXR Gamepads" modules initially.  Other 
modules in "incubation" are not in scope for this intent-to-implement-and-ship.

And updated target for WebXR is now FF73.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to prototype: Delegate and restrict permission in third party context

[kgilbert]

On Monday, November 25, 2019 at 9:29:10 AM UTC-8, Thomas Nguyen wrote:
> Summary: People don’t have a good understanding of iframes, because
> generally, no UI indicates that iframes are visible on a page, or what
> their origin is. Permission requests from iframes cause significant
> confusion for users because it is hard to determine where the requests come
> from, as the address bar does not match the site in the permission prompt.
> 
> Currently, Firefox allows iframes on a site to make permission requests and
> show up a permission prompt using the origin of the iframes. A user making
> a decision based on the third party context presented in the notification
> prompt is complicated and confusing. This confusion is exacerbated when
> managing previously stored permission decisions.
> 
> To address this problem, we would like to impose a restriction on
> permissions coming from third party context. There would be two main
> changes proposed:
> 
>-
> 
>Give an ability to delegate permissions from first party to third party
>embedded iframes, and impose a restriction to embedded iframes to request
>permission only when the iframe’s embedder has explicitly delegated it. The
>permission request will use the top level origin to show in the prompt,
>then users are only required to make permission decisions about the first
>party context.
>-
> 
>   This change is dependent on the ability of Feature Policy to disable
>   permissions by default in cross-origin iframes. It will require a site 
> to
>   explicitly allow permissions for cross-origin iframes (setting allow
>   attribute, e.g allow=”geolocation”) otherwise, the permission
> requests will
>   be denied on that iframes.
>   -
> 
>   The change will be applied to geolocation, camera, microphone and
>   screen-sharing permission, and fullscreen request.
> 
> 
>-
> 
>Completely deny permissions from third party context for vibration,
>notification, and persistent-storage permission.
> 
> 
> The plan is:
> 
>-
> 
>Enable Feature Policy allow attribute.
>-
> 
>Make permission camera/microphone/geolocation/display-capture/fullscreen
>disabled by default in third-party iframe.
>-
> 
>Delegate Permissions: only cross-origin iframes that have explicit
>delegated permission from their parent through the allow attribute will
>have the right to make permission requests.
>-
> 
>Reduce the number of supported features to geolocation, camera,
>microphone screen-sharing, and fullscreen (the above features are supported
>for permissions UI with notification prompts, except fullscreen). And we
>will move all other features to experimental phrase under a user preference
>which is disabled by default.
>-
> 
>Simplify prompts/dialogs to only contain the top-level origin.
>-
> 
>Deny vibration, persistent-storage permission from third party iframe
>(notification permission was disabled in third party context,  just do some
>minor refactors).
> 
> 
> 
> 
> Bug: The tracking bug https://bugzilla.mozilla.org/show_bug.cgi?id=1572461
> 
> Standard: Feature Policy
> https://w3c.github.io/webappsec-feature-policy/#iframe-allow-attribute
> 
> Platform coverage: All.
> 
> Preference:
> 
> dom.security.featurePolicy.experimental.enabled: disabled by default, we
> will limit supported features in Feature Policy to geolocation, camera,
> microphone, fullscreen, display-capture and move others to experimental
> phase.
> 
> permissions.delegate.enabled: enabled by default
> 
> dom.security.featurePolicy.enabled: this pref is implemented in Firefox 65
> but enabled by default in Nightly only
> 
> Other browsers: Chrome supports permission delegation from Chrome 71.
> 
> web-platform-tests: We only have web platform tests for feature policy but
> not permission delegation
> 
> Some of Feature Policy web-platform-tests that the permissions are disabled
> by default in cross origin iframe:
> 
> https://searchfox.org/mozilla-central/source/testing/web-platform/meta/feature-policy
> 
> testing /web-platform
> /tests
> /
> permissions
> 
> /feature-policy-permissions-query.html
> 
> 
> testing /web-platform
> /tests
> /
> mediacapture-streams
> 
> 

Proposed W3C Charter: Service Workers Working Group

[L. David Baron]

The W3C is proposing a revised charter for:

  Service Workers Working Group
  https://www.w3.org/2019/11/proposed-sw-wg-charter-2019.html
  https://lists.w3.org/Archives/Public/public-new-work/2019Nov/0004.html

The differences from the previous charter are:
https://services.w3.org/htmldiff?doc1=https%3A%2F%2Fwww.w3.org%2F2017%2F08%2Fsw-charter=https%3A%2F%2Fwww.w3.org%2F2019%2F11%2Fproposed-sw-wg-charter-2019.html

Mozilla has the opportunity to send comments or objections through
Tuesday, December 17.

Please reply to this thread if you think there's something we should
say as part of this charter review, or if you think we should
support or oppose it.


(I think we may want to comment on Background Synchronization (which
was also in the previous charter, but which we have concerns about
in [1] and [2]) and about Background Fetch (which is new to this
charter, and which I think we also have concerns about).)

-David

[1] https://github.com/mozilla/standards-positions/issues/173
[2] https://github.com/mozilla/standards-positions/issues/214

-- 
턞   L. David Baron http://dbaron.org/   턂
턢   Mozilla  https://www.mozilla.org/   턂
 Before I built a wall I'd ask to know
 What I was walling in or walling out,
 And to whom I was like to give offense.
   - Robert Frost, Mending Wall (1914)
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform