Re: Intent to Ship: Web Authentication

[J.C. Jones]

On Wed, Dec 6, 2017 at 10:24 AM, James Graham 
wrote:

> Are the web-platform-tests going to be done before we ship?
>

I hope so, though as-of-now no one from Mozilla is contributing to the
web-platform-tests [1]. Originally some FIDO Alliance-associated folk were
going to take the lead on them, but I've not been tracking it.


> For my information, what was missing from wpt that meant you had to write
> mochitests? (I don't doubt that there are good reasons, it's just
> understanding what they are helps shape future work).
>

I think most everything except the tests for tab-switch and maybe some of
the more exotic cross-origin behaviors can move to web-platform-tests, and
I hope that our existing mochitest logic can be mostly ported over there.
The only reason for not doing these as web-platform-tests to begin with was
cross-company communication inefficiencies. I fully expect this to be
remedied in 2018.

[1] https://github.com/w3c/web-platform-tests/tree/master/webauthn
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship WebRTC RTCRtpReceiver contributing and synchronization sources

[Nico Grunbaum]

Thank you for the link to the template Boris.

Intent to ship WebRTC RTCRtpReceiver contributing and synchronization 
sources


Summary: RTCRtpReceiver's[1] getSynchronizationSources() method allows 
WebRTC applications to monitor volume levels of call participants 
without having to use the costly getStats()[2] call. RTCRtpReceiver's 
getContributingSources() method enables WebRTC applications to monitor 
the volume level of participants whose audio is being mixed upstream if 
the mixer includes this data in the RTP extension headers.


It is in nightly now, and we intend to ship these interfaces in 59. 
Chrome shipped a partial implementation[3] of getContributingSources() 
in 59. Edge has partial support[4] for getContributingSources().


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

Link to standard: https://w3c.github.io/webrtc-pc/#rtcrtpreceiver-interface
Testing: WPT are disabled, as the tests are themselves not functional[5] 
and there is ongoing spec discussion as how to fix them[6].


[1] https://w3c.github.io/webrtc-pc/#dom-rtcrtpreceiver
[2] https://w3c.github.io/webrtc-pc/#dom-rtcrtpreceiver-getstats()
[3] https://bugs.chromium.org/p/chromium/issues/detail?id=703122=2
[4] https://msdn.microsoft.com/en-us/library/mt502507(v=vs.85).aspx
[5] https://bugzilla.mozilla.org/show_bug.cgi?id=1419900
[6] https://github.com/w3c/webrtc-pc/pull/1668#issuecomment-346951615

-- Nico Grunbaum


On 12/6/17 5:42 AM, Boris Zbarsky wrote:

Would you mind filling out the other parts of the intent templates at
https://wiki.mozilla.org/WebAPI/ExposureGuidelines#Intent_to_Implement 
and https://wiki.mozilla.org/WebAPI/ExposureGuidelines#Intent_to_Ship ?


At the very least, what is the status in other implementations and 
what is the testing situation?


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


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

Re: Firefox build issues with Rust and the new VS2017 15.5 update

[Adam Gashlin]

I encountered an issue building with the latest VS update, warnings treated
as errors regarding TR1 deprecation, in at least some gtest files. This can
be avoided by running as

CXXFLAGS=-D_SILENCE_TR1_NAMESPACE_DEPRECATION_WARNING ./mach build

though I imagine there are better ways of adding in that define.

On Tue, Dec 5, 2017 at 11:14 AM, Ryan VanderMeulen <
rvandermeu...@mozilla.com> wrote:

> As a follow-up, it looks like updating to a newer LLVM version fixes the
> problem. That update is being tracked in https://bugzilla.mozilla.org/
> show_bug.cgi?id=1423307.
>
> For anybody already hitting this bustage locally, you can try updating
> your clang toolchain under ~/.mozbuild/clang to the one below until the
> in-tree changes are landed:
> https://queue.taskcluster.net/v1/task/Q7sN0gfPSE-
> OAEV5vuGtEA/runs/0/artifacts/public/build/clang.tar.bz2
>
> -Ryan
>
> On Tue, Dec 5, 2017 at 11:16 AM, Ryan VanderMeulen <
> rvandermeu...@mozilla.com> wrote:
>
>> FYI, the VC++ 2017 v14.12 toolset included in the recently-released
>> VS2017 15.5 update appears to have broken building Firefox due to issues
>> with the Rust compiler (in particular, the version of libclang we ship with
>> it) and one of the system headers:
>>
>> C:\PROGRA~2\MIB055~1\2017\COMMUN~1\VC\Tools\MSVC\1412~1.258\include\type_traits:898:47:
>> error: '_Ty' does not refer to a value
>>
>> Which in turns leads to a Rust panic and build failure.
>>
>> The Visual Studio installer allows you to install the prior v14.11
>> toolset as well, but I haven't verified yet that our build system will
>> properly use it if it's there. In the mean time, I'd strongly advise
>> avoiding this update until it's sorted out.
>>
>> -Ryan
>>
>
>
> ___
> firefox-dev mailing list
> firefox-...@mozilla.org
> https://mail.mozilla.org/listinfo/firefox-dev
>
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: Do not allow a http-auth prompt requested by an image resource loaded from a cross-origin

[Daniel Veditz]

On Wed, Dec 6, 2017 at 9:13 AM, Dragana Damjanovic 
wrote:

> Bug 1423522 should fix this.
>

​That doesn't fix it, that reenables the phishing risk. There's no reason
the phisher's server can't pretend to be a proxy if that's what it takes to
get a spoofy auth prompt to show up on a discussion board that allows
images in their comments.

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

Re: Intent to ship: Do not allow a http-auth prompt requested by an image resource loaded from a cross-origin

[Dragana Damjanovic]

Bug 1423522 should fix this.

dragana

On Wed, Dec 6, 2017 at 5:53 PM, Daniel Veditz  wrote:

> On Tue, Dec 5, 2017 at 1:29 PM, Xidorn Quan  wrote:
>
> > Would this affect authentication from proxy? For example, if the
> > cross-origin image is on a domain which PAC decides to use proxy for,
> > and the proxy requires authentication, would the dialog prompt for it be
> > suppressed as well? If so, it sounds a bit unfortunate.
> >
>
> Note that we're blocking the auth _prompt_, not auth itself. If your first
> connection with that proxy is on an  tag in some other site then yes,
> that will be blocked. But if you've auth'd with the proxy already we will
> respond normally to the authentication headers.
>
> Work-around: right-click on the broken image and choose "View Image" or
> equivalent, then go back to the original page and it will load.
>
> -Dan Veditz
> ___
> 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 ship: Do not allow a http-auth prompt requested by an image resource loaded from a cross-origin

[Daniel Veditz]

On Tue, Dec 5, 2017 at 1:29 PM, Xidorn Quan  wrote:

> Would this affect authentication from proxy? For example, if the
> cross-origin image is on a domain which PAC decides to use proxy for,
> and the proxy requires authentication, would the dialog prompt for it be
> suppressed as well? If so, it sounds a bit unfortunate.
>

Note that we're blocking the auth _prompt_, not auth itself. If your first
connection with that proxy is on an  tag in some other site then yes,
that will be blocked. But if you've auth'd with the proxy already we will
respond normally to the authentication headers.

Work-around: right-click on the broken image and choose "View Image" or
equivalent, then go back to the original page and it will load.

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

Re: Intent to Ship: Web Authentication

[Jonathan Watt]

This is really awesome and a significant advance on other 2FA solutions. I've
been looking forward to us shipping this. Thank you for all your hard work!

On 05/12/2017 20:44, J.C. Jones wrote:
> Summary: Support public key cryptographic authentication devices
> through Web Authentication.
> 
> Web Authentication is backward compatible with FIDO U2F second-factor
> tokens, and also supports more advanced capabilities in future FIDO
> 2.0 devices. We intend to ship support for USB-connected FIDO U2F
> devices initially, with other transports and FIDO 2.0 device support
> to follow in 2018.
> 
> Tracking bug: https://bugzilla.mozilla.org/show_bug.cgi?id=webauthn
> 
> Spec: https://www.w3.org/TR/webauthn/
> 
> (Note that the latest working draft,
> https://www.w3.org/TR/2017/WD-webauthn-20171205/, is considered by the
> WG to be feature complete, and no more normative changes are
> anticipated.)
> 
> Estimated target release: 60
> 
> Preference behind which this is implemented:
> security.webauth.webauthn
> 
> DevTools support:
> N/A
> 
> Support by other browser engines:
> - Blink: In-progress [1]
> - Edge: In-progress [2]
> - Webkit: No public announcements
> 
> Testing:
> Mochitests in-tree; https://webauthn.io/; https://webauthn.bin.coffee/
> ; Web Platform Tests in-progress
> 
> 
> Cheers,
> J.C. Jones and Tim Taubert
> 
> [1] https://www.chromestatus.com/feature/5669923372138496
> [2] https://msdn.microsoft.com/en-us/library/mt697638(v=vs.85).aspx
> 

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

Re: Intent to ship WebRTC RTCRtpReceiver contributing and synchronization sources

[Boris Zbarsky]

On 12/6/17 12:19 AM, Nico Grunbaum wrote:

We intend to ship these interfaces in 59, and they are on nightly now.

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

[1] https://w3c.github.io/webrtc-pc/#dom-rtcrtpreceiver
[2] https://w3c.github.io/webrtc-pc/#dom-rtcrtpreceiver-getstats()


Would you mind filling out the other parts of the intent templates at
https://wiki.mozilla.org/WebAPI/ExposureGuidelines#Intent_to_Implement 
and https://wiki.mozilla.org/WebAPI/ExposureGuidelines#Intent_to_Ship ?


At the very least, what is the status in other implementations and what 
is the testing situation?


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

Re: Intent to ship: Do not allow a http-auth prompt requested by an image resource loaded from a cross-origin

[Dragana Damjanovic]

On Tue, Dec 5, 2017 at 10:29 PM, Xidorn Quan  wrote:

> On Wed, Dec 6, 2017, at 01:25 AM, Dragana Damjanovic wrote:
> > Hi all,
> >
> > We have implemented this for a log time, but the pref was turned off.
> > I intend to switch on the pref for this in bug 1423146.
> > After the pref is switched a http-authentication dialog prompt will not
> > be
> > shown if it is triggered by an image resource from a cross-origin.
>
> Would this affect authentication from proxy? For example, if the
> cross-origin image is on a domain which PAC decides to use proxy for,
> and the proxy requires authentication, would the dialog prompt for it be
> suppressed as well? If so, it sounds a bit unfortunate.
>
>
Good point.
Currently it would be blocked. I think we should change that. I will file a
bug (I will also leave the security team to have a final word).

dragana



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