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
> 
> 

Re: Intent to ship: WebVR on macOS

[kgilbert]

On Tuesday, February 27, 2018 at 12:51:46 PM UTC-8, kear...@kearwood.com wrote:
> On Wednesday, September 20, 2017 at 4:30:56 PM UTC-7, Kearwood  Kip  Gilbert 
> wrote:
> > As of 2017-10-01, I intend to turn WebVR on by default for macOS.  It has 
> > been developed behind the dom.vr.enabled preference.  We have already 
> > shipped WebVR by default for the Windows platform.  macOS support has been 
> > implemented for several months but disabled by default.  Our WebVR 
> > implementation supports OpenVR for the HTC Vive on macOS High Sierra, which 
> > is now hitting release.
> > This feature was previously discussed in this "intent to implement" thread: 
> > . 
> > Bug to turn on by default: 
> > https://bugzilla.mozilla.org/show_bug.cgi?id=1374399
> > Link to standard: https://w3c.github.io/webvr/spec/1.1/
> > Testing: 
> > Automated tests have been implemented and are already active for the macOS 
> > builds in taskcluster.  Platform conformance tests are shared with other 
> > UA’s.
> 
> As of 2018-02-27, I intend to turn WebVR [back] on by default for macOS.  Due 
> to hardware availability for QA, this was disabled before riding to release 
> for FF58 and FF59.  We have since gained QA approval to allow it to ride to 
> release in FF60.
> 
> Bug to turn on by default:
> https://bugzilla.mozilla.org/show_bug.cgi?id=1438044
> 
> Link to standard:
> https://w3c.github.io/webvr/spec/1.1/
> 
> Testing: 
> Automated tests have been implemented and are already active for the macOS 
> builds in taskcluster.  Platform conformance tests are shared with other UA’s.

Enabling this was delayed / rolled back due to issues with the SteamVR runtime 
on macOS occurring when we disabled the macOS nano-allocator for the Firefox 
process to fix unrelated issues.  Updates to the SteamVR runtime have corrected 
this.

This will be re-re-enabled for FF64 on 2018-10-12.  The new bug to turn on by 
default:

Bug 1476091 ((Re-) Enable WebVR by default for macOS)

___
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]

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)

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

Re: PSA - Planning to enable VR service process on desktop (Linux, macOS, and Windows)

[kgilbert]

On Monday, August 20, 2018 at 4:16:56 PM UTC-7, Kip Gilbert wrote:
> Hello all,
> 
> In order to unblock sandboxing of the GPU process and efforts to re-enable 
> macOS WebVR support, we are moving the VR device interfacing code to its own 
> “VR Service” process.  This process will only be launched when a user 
> accesses a WebVR site.
> 
> The bugs to enable this by default will flip two prefs:
> 
> Bug 1476092 (Enable the VR process by default)
> Bug 1473399 (Enable VRService thread by default)
> 
> This change will not affect the WebVR API or otherwise be user facing.
> 
> I expect to flip these prefs before the upcoming soft-freeze (2018-08-23).
> 
> Any feedback is welcome, thanks!
> 
> Cheers,
> 
>   *   Kearwood “Kip” Gilbert

Addendum - We've decided to flip the prefs after the merge date and let this 
run a full cycle in Nightly.  FF64 would be the first with the VR process 
enabled by default.
___
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 Monday, July 30, 2018 at 5:22:05 PM UTC-7, kgil...@mozilla.com wrote:
> Correction: "As of 2019-10-01" should be "As of 2018-10-01"...
> 
Also..  Should be "The implementation is expected to be completed for Firefox 
66, but would be enabled as early as Firefox 65 if implementation goes quickly. 
"
___
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]

Correction: "As of 2019-10-01" should be "As of 2018-10-01"...

On Monday, July 30, 2018 at 5:03:38 PM UTC-7, Kip Gilbert wrote:
> Summary:
> 
> The successor to WebVR 1.1, the WebXR Device API 1.0, is nearing 
> finalization.  The WebXR Device API follows modern Web API patterns, is 
> extensible additively for augmented reality, enables use within Web Workers, 
> and solves many security problems for the VR and AR enabled web.  The spec 
> has been developed jointly by implementers from all major browser vendors, 
> within the W3C Immersive Web Community Group.  A full W3C Working Group is 
> now being formed, with a charter and assigned chairs.
> 
> As of 2019-10-01 I intend to turn the WebXR Device API 1.0 on by default in 
> Nightly for on all platforms that already support WebVR (Windows, Linux, 
> macOS, and Firefox Reality / GeckoView).  Chrome 67 Beta has shipped WebXR as 
> an Origin Trial.
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to ship: WebVR on Windows in Release

[kgilbert]

As of March 1, 2017 I intend to turn WebVR on by default on Windows.  It has 
been developed behind the dom.vr.enabled preference and has been enabled by 
default on Firefox Nightly and Dev Edition since November 2015.  Other UAs 
shipping this include Samsung Internet Browser (Gear VR) and Oculus Carmel.  
Microsoft Edge and Google Chrome are also intending to ship.  Google Chrome has 
enabled WebVR on Android with an Origin Trial.

This feature was previously discussed in this "intent to ship" thread, for 
non-release builds:
 
https://groups.google.com/d/topic/mozilla.dev.platform/BeVaHGEgZNA/discussion
 
Bug to turn on by default:
 
https://bugzilla.mozilla.org/show_bug.cgi?id=1343368
 
We will support Oculus and HTC Vive by default.  Oculus is already enabled; HTC 
Vive support with OpenVR has been developed behind the “dom.vr.openvr.enabled” 
preference and will be turned on with this bug:

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

Link to standard: https://w3c.github.io/webvr/archive/prerelease/1.1/

Since the initial implementation, a W3C working group was formed including 
members from Mozilla, Google, Microsoft, Samsung, and Oculus.  The API has 
stabilized and is frozen at "WebVR 1.1" while its successor "WebVR 2.0" is 
being conceived.
 
Windows only support for WebVR would be enabled by default in Firefox 54.  OSX 
is not yet supported by current VR headsets.  Beta Linux support for HTC Vive 
has very recently landed, and will be supported by Firefox after the Firefox 54 
uplift.

Cheers,
    Kearwood “Kip” Gilbert
    :kip

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

Re: "-Moz-Element" -like API by extending WEBGL_dynamic_texture

[kgilbert]

On Thursday, January 7, 2016 at 1:32:59 AM UTC-8, Robert O'Callahan wrote:
> On Thu, Jan 7, 2016 at 8:46 PM, Anne van Kesteren  wrote:
> 
> > At least enforcing CORS-same-origin would be somewhat trivial from a
> > specification perspective since all fetches go through Fetch. Limiting
> > plugins and other affected features would be some added conditionals
> > here and there. I don't see how content changes would have an impact
> > since you can only change the policy through navigation at which point
> > you'd have a new global and such anyway.
> >
> 
> Some of the things that would need to be handled:
> --  controls need to not expose sensitive data about
> file paths
> -- For SVG images we disable native themes to avoid those being inspectable
> by the Web site
> -- Non-origin-clean canvas images,  frames and MediaStream frames
> would have to be suppressed
> -- Non-same origin content (, , etc) would have to be blocked.
> This isn't as simple as a change to Fetch, since a site could create an
> element and load its contents in an unrestricted browsing context and move
> it into a different document with different rules.
> -- :visited
> 
> Rob
> -- 
> lbir ye,ea yer.tnietoehr  rdn rdsme,anea lurpr  edna e hnysnenh hhe uresyf
> toD
> selthor  stor  edna  siewaoeodm  or v sstvr  esBa  kbvted,t
> rdsme,aoreseoouoto
> o l euetiuruewFa  kbn e hnystoivateweh uresyf tulsa rehr  rdm  or rnea
> lurpr
> .a war hsrer holsa rodvted,t  nenh hneireseoouot.tniesiewaoeivatewt sstvr
> esn

There are two use cases for this functionality needed by the WebVR team.

The one needed earliest is to implement HUD interfaces and dialogues.  In this 
case, we will only be using this API from chrome privileged code.  jgilbert has 
started on a mechanism we can use for now for this case as a chrome-only API 
(Bug 1237489).

For the second case, which could benefit everyone, we would like to use DOM 
elements in any WebGL scene.  The intent would be to deprecate the API added in 
Bug 1237489 once the Khronos specification for WEBGL_dynamic_texture is more 
mature and can be used in unprivileged content.  jgilbert mentions that the 
WEBGL_dynamic_texture specification is due for a pruning refactor that should 
simplify things a bit.

Would it help to reduce the scope and brittle-ness of the security model by 
white-listing elements that are allowed in non-privileged content?  The 
original WEBGL_dynamic_texture proposal names specifically HTMLVideoElement, 
HTMLCanvasElement and HTMLImageElement.  Perhaps these would be a good start, 
with an intent to expand later?

If we wish to style content in a way that it gets sanitized of security 
sensitive content, perhaps we could roll it up in a convenient CSS attribute 
applied to the element we are capturing as a texture while also ensuring that 
the element generates a layer and is taken out of flow from the 2d document.

How would you feel about this CSS:

position: embed

It would work like "position: absolute" in that it takes the element out of 
flow; however, the element would not be positioned or rendered in the 2d 
layout.  It would also ensure that the element generates a layer, similar to 
"will-change: transform".  When called from non-privileged content, it would 
enforce the whitelist, CORS, and sanitize any security sensitive output such as 
those that Roc has identified earlier.

A chrome-only version with a different name could be used from privileged code 
to implement backwards compatibility of 2d web pages in a VR based browser:

position: embed-unsanitized

(I'd love to hear other attribute naming ideas)

For the case of 2d web pages in a VR based browser, we would need to include 
things such as iframes, cross-origin content, and :visited link styles.  These 
could be restricted to be used by privileged code only with "position: 
embed-unsanitized"

Thanks for exploring this with me and the great feedback!
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform