Re: Intent to Ship: Web Authentication
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
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&desc=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
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
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: Web Authentication
On 05/12/17 20:44, J.C. Jones wrote: Summary: Support public key cryptographic authentication devices through Web Authentication. This sounds pretty cool! Testing: Mochitests in-tree; https://webauthn.io/; https://webauthn.bin.coffee/ ; Web Platform Tests in-progress Are the web-platform-tests going to be done before we ship? 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). ___ 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
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
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
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
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
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