subject:"Intent to implement and ship"

Re: Intent to implement and ship: DOMTokenList.prototype.supports

2016-05-03 Thread Karl Dubost


Le 4 mai 2016 à 05:24, Boris Zbarsky  a écrit :
> In practice, this is the set of  values I'm claiming we support: 
> "import" (if IsImportEnabled()), "prefetch", "dns-prefetch", "stylesheet", 
> "next", "alternate", "preconnect", "icon".  Anything else I'm missing?  Do we 
> do anything useful with rel="feed" anymore?

for feed, I guess, it is still in the menu and you can put it back on the main 
bar and I suspect add-ons are still using it. Also found
https://dxr.mozilla.org/mozilla-central/source/browser/modules/ContentLinkHandler.jsm#48

I also wonder in addition of "icon" about "favicon".
I don't think the browser does anything with "canonical" and "nofollow" (search 
engines).


fwiw
https://github.com/search?l=JavaScript=DOMTokenList=Repositories=%E2%9C%93

example
https://github.com/jwilsson/domtokenlist/blob/master/src/relList.js


-- 
Karl Dubost, Mozilla
http://www.la-grange.net/karl/moz

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

Re: Intent to implement and ship: DOMTokenList.prototype.supports

2016-05-03 Thread Boris Zbarsky


On 5/3/16 7:20 PM, Domenic Denicola wrote:

Does Firefox support "next" in some interesting way?


Yes.  We treat it as an alias for "prefetch".


I, uh, have no idea why we included "next" but not "prev".


The theory, presumably, is that people typically go forward through 
things in order.  Mostly.  Or something.


-Boris

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

Re: Intent to implement and ship: DOMTokenList.prototype.supports

2016-05-03 Thread Domenic Denicola

On Tuesday, May 3, 2016 at 4:24:26 PM UTC-4, Boris Zbarsky wrote:

> In practice, this is the set of  values I'm claiming we 
> support: "import" (if IsImportEnabled()), "prefetch", "dns-prefetch", 
> "stylesheet", "next", "alternate", "preconnect", "icon".  Anything else 
> I'm missing?  Do we do anything useful with rel="feed" anymore?

Does Firefox support "next" in some interesting way? Maybe it is confusing to 
have it in the spec, but IIRC the idea was that this would be used for people 
trying to figure out if annotating their links with "next" would actually 
affect the user agent's processing or UI in some way.

I, uh, have no idea why we included "next" but not "prev".
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship: DOMTokenList.prototype.supports

2016-05-03 Thread Boris Zbarsky


On 5/3/16 4:38 PM, smaug wrote:

Do we need "import" ever?


Is IsImportEnabled() ever true?


I guess that will be removed once we remove import related code.


Seems plausible.

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

Re: Intent to implement and ship: DOMTokenList.prototype.supports

2016-05-03 Thread smaug

Ok to me, given that adding the API to the platform is supported by other
browser vendors too.

(Though it is a bit mystery to me why DOMTokenList.supports is considered fine when it is pretty much similar feature to Node.isSupported and that one
was considered harmful to the platform. But I'm not going to reopen that question.)

On 05/03/2016 11:24 PM, Boris Zbarsky wrote:

Summary: A way to feature-detect which values of various tokenlist attributes
actually do something. Useful for things like which iframe sandbox
tokens are supported, or what "rel" values for are supported.

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

Link to Standard: If only it were so simple. The basic feature is defined at
https://dom.spec.whatwg.org/#dom-domtokenlist-supports but it depends on
consumers of token lists defining the set of "supported tokens" for them. In practice
that means HTML. HTML defines supported tokens for "rel" on
, , and , "sandbox" on , and "dropzone" on all elements. Most
of these definitions are sane, but the one includes a
"yeah, just monkeypatch this" aspect that makes it a bit hard to figure out
what the actual set of supported tokens is.

Anyway, the relevant definitions are:
https://html.spec.whatwg.org/multipage/semantics.html#attr-hyperlink-rel

https://html.spec.whatwg.org/multipage/embedded-content.html#attr-iframe-sandbox

https://html.spec.whatwg.org/multipage/interaction.html#the-dropzone-attribute
https://html.spec.whatwg.org/multipage/semantics.html#linkTypes

In practice, this is the set of values I'm claiming we support: "import" (if IsImportEnabled()),
"prefetch", "dns-prefetch", "stylesheet",
"next", "alternate", "preconnect", "icon". Anything else I'm missing? Do we do anything
useful with rel="feed" anymore?

Do we need "import" ever? I guess that will be removed once we remove import
related code.

Estimated or target release: Firefox 49

Preference behind which this is implemented: none.

DevToolks bug: none; I'm not sure we need anything special here.

Support in other browsers: Blink supports this, though only for iframe@sandbox
and link@rel (because its a@rel is not a DOMTokenList). Not sure about
others.

Security/privacy concerns: none.

-Boris

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

Intent to implement and ship: DOMTokenList.prototype.supports

2016-05-03 Thread Boris Zbarsky

Summary: A way to feature-detect which values of various tokenlist 
attributes actually do something.  Useful for things like which iframe 
sandbox tokens are supported, or what "rel" values for  are supported.


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

Link to Standard: If only it were so simple.  The basic feature is 
defined at https://dom.spec.whatwg.org/#dom-domtokenlist-supports but it 
depends on consumers of token lists defining the set of "supported 
tokens" for them.  In practice that means HTML.  HTML defines supported 
tokens for "rel" on , , and , "sandbox" on , and 
"dropzone" on all elements.  Most of these definitions are sane, but the 
 one includes a "yeah, just monkeypatch this" aspect that makes it 
a bit hard to figure out what the actual set of supported tokens is.


Anyway, the relevant definitions are:
  https://html.spec.whatwg.org/multipage/semantics.html#attr-hyperlink-rel

https://html.spec.whatwg.org/multipage/embedded-content.html#attr-iframe-sandbox

https://html.spec.whatwg.org/multipage/interaction.html#the-dropzone-attribute
  https://html.spec.whatwg.org/multipage/semantics.html#linkTypes

In practice, this is the set of  values I'm claiming we 
support: "import" (if IsImportEnabled()), "prefetch", "dns-prefetch", 
"stylesheet", "next", "alternate", "preconnect", "icon".  Anything else 
I'm missing?  Do we do anything useful with rel="feed" anymore?


Estimated or target release: Firefox 49

Preference behind which this is implemented: none.

DevToolks bug: none; I'm not sure we need anything special here.

Support in other browsers: Blink supports this, though only for 
iframe@sandbox and link@rel (because its a@rel is not a DOMTokenList). 
Not sure about others.


Security/privacy concerns: none.

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

Re: Intent to implement and ship: rel="noopener" on links

2016-05-03 Thread Boris Zbarsky


On 4/25/16 10:47 PM, Boris Zbarsky wrote:

Ah.  Perhaps we should hold off on doing this until
https://bugzilla.mozilla.org/show_bug.cgi?id=1257849 is fixed then.  And
the window.open thing would still not be detectable, so people would
probably start assuming the anchor bit implied the window thing.  :(


Looks like Chrome doesn't actually implement 
HTMLAnchorElement.prototype.relList, so this can't be feature-detected 
anyway by sites.  They have to rely on browser sniffing.


So I guess we can do whatever we want here, since sites are screwed 
anyway.  :(


-Boris

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

Re: Intent to implement and ship: IIRFilterNode

2016-04-28 Thread Karl Tomlinson

Thanks for the replies, Dan and Roy.

A first order filter node with AudioParam inputs seems a likely
future addition AFAIK.

Even with that though, having a way to apply a custom biquad
without needing to decompose into multiple textbook filters is
useful I think.  And I agree that implementing this with
AudioParams seems unnecessary and risky wrt stability.

So I think the IIRFilterNode will still be useful as a basic
building block for authors (and that is the kind of node that Web
Audio should be providing).

The discussion re extending BiquadFilterNode for this has passed
but there is an elegance in the generality of IIRFilterNode.

Daniel Minor writes:

> In this case, my plan
> was to import the blink IIRFilter as utility code as we've done in the
> past, so I don't think supporting the IIRFilterNode will cost us much time
> or effort and keeps us compatible with the spec.

I wanted to think this through now because, once this is shipped,
we can't take it back, so the cost is ongoing.

When Gecko has used Blink or Webkit's implementation in the past,
the WG has sometimes used this to argue that quirks in multiple
existing implementations should be maintained even if not
desirable.

Sometimes we just live with the quirks.  Other times the nodes
have been deprecated and replaced, but we still need to continue
to support the old nodes for backward compatibility.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship: IIRFilterNode

2016-04-28 Thread Daniel Minor

On Wed, Apr 27, 2016 at 6:35 PM, Karl Tomlinson  wrote:

> Daniel Minor writes:
>
> > Summary: This provides an alternative to using BiquadFilterNode when
> > odd-order filters are required or automation is not needed. It is part of
> > the Web Audio spec and is already implemented in Blink.
>
> Thanks for looking at this, Daniel.
>
>
Thanks for your comments Karl!

To be honest, I'm not sure how useful IIRFilterNodes will be in practice.
One could argue that we should see how widely the blink implementation is
used "in the wild" before we implement it ourselves.In this case, my plan
was to import the blink IIRFilter as utility code as we've done in the
past, so I don't think supporting the IIRFilterNode will cost us much time
or effort and keeps us compatible with the spec.

> I fear that high order filters are going to have problems due to numerical
> round-off, as pointed out in
> https://github.com/WebAudio/web-audio-api/issues/323#issuecomment-60545047
>
> Do you know whether that is going to be a general problem or whether many
> high order filters will be OK in practice?
>
>
We're using doubles rather than floats, but I'm not sure if this is
sufficient to avoid numerical problems with higher order filters.

> There is some discussion here but my understanding is limited:
> http://signal.ece.utexas.edu/~arslan/courses/dsp/lecture25.ppt
>
> There was some tinkering of test output precision for up to 4th order
> filters
> in patch sets 7, 8, 9, and 19 of
> https://codereview.chromium.org/1361233004/
>
> The Blink implementation doesn't factor into low-order filters, and I
> expect
> it would be quite some work to do this.
>
> I wonder whether it may be that the IIRFilterNode should be used only for
> first and second order filters and higher order filters should be composed
> as
> a series of these?
>
> IIRFilterNode is probably an OK solution for first-order and custom biquad
> filters, as long as we don't then need a pole/zero filter node with
> AudioParam
> parameters because someone wants automation (as already requested for and
> available with BiquadFilterNode).  Then we'd have yet another filter node,
> which would be unfortunate.  Do you think this is likely?
>

The discussion in https://github.com/WebAudio/web-audio-api/issues/323
ruled this out because it seemed of limited utility and could be
challenging to implement. We should work to make sure that automation does
not sneak in.

I think it might make sense to raise your concerns as issues against the
Web Audio spec. I'm sure you'll get more informed feedback than I can
provide :)

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

Re: Intent to implement and ship: IIRFilterNode

2016-04-27 Thread Karl Tomlinson

Daniel Minor writes:

> Summary: This provides an alternative to using BiquadFilterNode when
> odd-order filters are required or automation is not needed. It is part of
> the Web Audio spec and is already implemented in Blink.

Thanks for looking at this, Daniel.

I fear that high order filters are going to have problems due to numerical
round-off, as pointed out in
https://github.com/WebAudio/web-audio-api/issues/323#issuecomment-60545047

Do you know whether that is going to be a general problem or whether many
high order filters will be OK in practice?

There is some discussion here but my understanding is limited:
http://signal.ece.utexas.edu/~arslan/courses/dsp/lecture25.ppt

There was some tinkering of test output precision for up to 4th order filters
in patch sets 7, 8, 9, and 19 of https://codereview.chromium.org/1361233004/

The Blink implementation doesn't factor into low-order filters, and I expect
it would be quite some work to do this.

I wonder whether it may be that the IIRFilterNode should be used only for
first and second order filters and higher order filters should be composed as
a series of these?

IIRFilterNode is probably an OK solution for first-order and custom biquad
filters, as long as we don't then need a pole/zero filter node with AudioParam
parameters because someone wants automation (as already requested for and
available with BiquadFilterNode).  Then we'd have yet another filter node,
which would be unfortunate.  Do you think this is likely?
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to implement and ship: IIRFilterNode

2016-04-27 Thread Daniel Minor

Summary: This provides an alternative to using BiquadFilterNode when
odd-order filters are required or automation is not needed. It is part of
the Web Audio spec and is already implemented in Blink.

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

Link to standard:
http://webaudio.github.io/web-audio-api/#the-iirfilternode-interface

Platform coverage: all platforms.

Estimated or target release: Firefox 49

Preference behind which this will be implemented: None.

Support in other engines: Supported in Blink.  Not sure about others.

Thanks,

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

Re: Intent to implement and ship: rel="noopener" on links

2016-04-25 Thread Boris Zbarsky


On 4/25/16 10:31 PM, Domenic Denicola wrote:

On Monday, April 25, 2016 at 2:09:07 PM UTC-4, Boris Zbarsky wrote:


1) This is not feature-detectible, as far as I can see.  So it's not
clear to me that sites will know they can use this, short of relying on
browser sniffing.


If you implement DOMTokenList.prototype.supports, it should be; supports was 
added specifically for this use case.


Ah.  Perhaps we should hold off on doing this until 
https://bugzilla.mozilla.org/show_bug.cgi?id=1257849 is fixed then.  And 
the window.open thing would still not be detectable, so people would 
probably start assuming the anchor bit implied the window thing.  :(


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

Re: Intent to implement and ship: rel="noopener" on links

2016-04-25 Thread Domenic Denicola

On Monday, April 25, 2016 at 2:09:07 PM UTC-4, Boris Zbarsky wrote:

> 1) This is not feature-detectible, as far as I can see.  So it's not 
> clear to me that sites will know they can use this, short of relying on 
> browser sniffing.

If you implement DOMTokenList.prototype.supports, it should be; supports was 
added specifically for this use case.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship: rel="noopener" on links

2016-04-25 Thread Boris Zbarsky


On 4/25/16 2:57 PM, Tanvi Vyas wrote:

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

I think you meant to link to bug
https://bugzilla.mozilla.org/show_bug.cgi?id=1222516 here.


Er... right you are.  Too many identical-looking tabs.  ;)

-Boris

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

Re: Intent to implement and ship: rel="noopener" on links

2016-04-25 Thread Tanvi Vyas


Very cool!  Thanks for implementing.

On 4/25/16 11:09 AM, Boris Zbarsky wrote:

Summary: The idea is to be able to write

  Go 
there


and not have "someone-I-don't-trust" be able to get hold of your 
window via window.opener.


This is already possible with rel="noreferrer", but that also prevents 
sending a referrer, which is undesirable in cases like search engine 
result pages.


Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1267339 
I think you meant to link to bug 
https://bugzilla.mozilla.org/show_bug.cgi?id=1222516 here.





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

Intent to implement and ship: rel="noopener" on links

2016-04-25 Thread Boris Zbarsky


Summary: The idea is to be able to write

  Go 
there


and not have "someone-I-don't-trust" be able to get hold of your window 
via window.opener.


This is already possible with rel="noreferrer", but that also prevents 
sending a referrer, which is undesirable in cases like search engine 
result pages.


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

Link to standard: https://html.spec.whatwg.org/#following-hyperlinks-2 
step 4.


Platform coverage: all platforms.

Estimated or target release: Firefox 48 or 49 depending on how long this 
discussion and reviews take.


Preference behind which this will be implemented: None.

Support in other engines: Supported in Blink.  Not sure about others.

Possible issues:

1) This is not feature-detectible, as far as I can see.  So it's not 
clear to me that sites will know they can use this, short of relying on 
browser sniffing.
2) Unlike Blink we are _not_ implementing the window.open feature yet. 
That's tracked in 
.  This is either 
mitigated or exacerbated by issue #1, depending on how you want to look 
at it


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

Intent to implement and ship: text-combine-upright: all

2016-03-21 Thread Xidorn Quan

Summary:
According to some people from Japanese ebook companies,
text-combine-upright (a.k.a horizontal-in-vertical, or tate-chu-yoko) is a
must for Japanese vertical layout. Without the proper support of this
feature, a book may not be considered complete, and thus cannot be sold
online. This is also a common pattern for layout of Traditional Chinese.

There are two values for text-combine-upright, one is "all", the other is
"digits ". We are currently going to implement only "all", because
that's much easier to implement and can solve the majority of the problem
people have.

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

Link to standard:
https://drafts.csswg.org/css-writing-modes-3/#text-combine-upright

Platform coverage: all

Estimated or target release: Firefox 48 (or 49 if missed the cycle of 48)

Preference behind which this will be implemented:
layout.css.text-combine-upright.enabled

DevTools bug: This doesn't seem to need any additional support from
DevTools.

Do other browser engines implement this?
All other browser engines have had the support of the functionality of
"text-combine-upright: all". Edge and Blink have already been shipping it
unprefixed.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to implement and ship: fetch() cache control API

2016-02-29 Thread Ehsan Akhgari

*Summary*: This API allows a web page to specify how the resources it
fetches interact with the browser HTTP cache.
*Bug*: https://bugzilla.mozilla.org/show_bug.cgi?id=1120715
*Link to standard*: https://fetch.spec.whatwg.org/
*Platform coverage*: All platforms
*Estimated or target release*: Firefox 48 (or 47 if we get lucky)
*Preference behind which this will be implemented*: No preference
*DevTools bug*: This doesn't require explicit devtools support as it's
about implementing a new DOM API.
Do other browser engines implement this? Blink is planning to implement
this as well.  As part of this, I'm planning to write web-platform-tests
against this feature.

Since this is a small scoped feature, I'm planning to land the patches to
implement it fully and let it ride the trains in Firefox 48 (or Firefox 47
in case the patches are ready and reviewed by the end of this week).

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

Intent to implement and ship: IDBKeyRange.includes()

2016-02-26 Thread Kyle Huey

*Summary*: This simple API allows one to test whether a given key is
included in an IDBKeyRange
*Bug*: https://bugzilla.mozilla.org/show_bug.cgi?id=1251498
*Link to standard*: http://w3c.github.io/IndexedDB/#dom-idbkeyrange-includes
*Platform coverage*: All platforms
*Estimated or target release*: Firefox 47
*Preference behind which this will be implemented*: No preference
Do other browser engines implement this? Blink is planning to implement and
ship this per discussions with Joshua Bell.

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

Intent to implement and ship: fetch() referrer and referrer policy APIs

2016-02-26 Thread Ehsan Akhgari

*Summary*: These APIs allow a web page to specify a referrer and a referrer
policy when fetching a resource.
*Bug*: https://bugzilla.mozilla.org/show_bug.cgi?id=1184549
*Link to standard*: https://fetch.spec.whatwg.org/
*Platform coverage*: All platforms
*Estimated or target release*: Firefox 47
*Preference behind which this will be implemented*: No preference
*DevTools bug*: This doesn't require explicit devtools support as it's
about implementing a few DOM APIs.
Do other browser engines implement this? Blink ships the referrer API, and
they plan to implement and ship the referrer policy API.  Both our
implementations are tested against the web-platform-tests for this feature.

Since this is a small scoped feature, I'm planning to land the patches to
implement it fully and let it ride the trains in Firefox 47.

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

Re: Intent to implement and ship: FIDO U2F API

2016-02-16 Thread Frederic Martin

By the way, I just got informed (from Google) that TLS Channel ID, even if 
activated on Google servers (including appspot), is only enforced for few users 
for now (even If I am not sure how they do that :) )

So Firefox users should not be blocked for that reason :)

They seem to agree you probably should focus on "the updated specification, the 
Token Binding one. Since that has a better chance of getting approved in the 
IETF"
https://tools.ietf.org/html/draft-ietf-tokbind-protocol-04

So great news. Please consider looking the new Token Binding specifications...

Thanx again for all your great work.
--
Frédéric



On Monday, February 8, 2016 at 11:36:38 PM UTC+1, Eric Rescorla wrote:
> On Mon, Feb 8, 2016 at 10:13 PM, Frederic Martin 
> wrote:
> 
> > Hi,
> >
> > thanx for the answer.
> >
> > Quoting Dirk Balfanz (one of the TLS Channel ID specifications author, a
> > few days ago on FIDO DEV forum):
> >
> > "the new spec that replaces ChannelID is called "Token Binding", and is in
> > the process of being standardized by the IETF (
> > https://datatracker.ietf.org/wg/tokbind/documents/).
> >
> > It turns out that as far as FIDO is concerned, a Token Binding key or a
> > ChannelID key are really the same thing: it's a public key that will be
> > included in the client data and signed by the Authenticator. So while
> > you're correct in pointing out that it's a bit weird that FIDO should
> > reference a non-standard, other than changing a few words here and there I
> > don't expect any changes to the FIDO specs once the Token Binding drafts
> > have become standards."
> >
> > Source :
> > https://groups.google.com/a/fidoalliance.org/d/msg/fido-dev/hn_T6pKS0wU/aEO29oIeEAAJ
> >
> 
> I'm not following how this is responsive to my point, which isn't about the
> text
> in FIDO but rather about what actually goes into Firefox. From that
> perspective,
> what Dirk says is correct, namely that the FIDO interface to Token Binding
> and Channel ID are very similar. However, we have to implement one or the
> other or both in TLS, and I don't see a lot of value in doing both.
> 
> 
> I am still concerned about Mozilla Foundation deciding not to implement
> > this protection inside Firefox for two main reasons.
> >
> > 1) From a security architect perspective. This is an official
> > recommendation that makes sens to prevent MITM attacks. FIDO U2F was
> > created to minimize/eliminate that kind of risk. This would rather be a
> > more secure decision to fully implement the best options. (I am working for
> > a FIDO U2F device manufacturer and that's what we did on our side).
> 
> 
> I don't understand this point. The manufacturer doesn't implement token
> binding:
> it's in the browser stack.
> 
> 
> 2) Firefox users could be discriminated out of servers implementing this
> > protection. Even if this is mostly/only the case on Google authentication
> > servers now, this would already make a difference. I am not a Google fan
> > boy -and I am working with other online services to integrate FIDO U2F
> > technology- but protecting their services accounts is often what everyone
> > is thinking about now when discussing FIDO U2F (protecting Gmail, Gdrive,
> > Youtube, or whatever Google related accounts). Did you speak with Google
> > team guys to know if they will let Firefox be compatible with their FIDO
> > U2F second factor option even without ChannelID protection on the client
> > side?
> 
> 
> Well, I see Ryan Sleevi responded below, but no, I haven't validated this
> one way
> or the other with Google. With that said, I would be somewhat disappointed
> if
> Google required Token Binding with U2F, given that they don't require it
> without
> U2F. It's certainly not consistent with previous claims -- or the
> underlying design
> of FIDO -- to say that token binding is required for FOD to add value.
> 
> 
> 
> > (this would mean that they'll accept to lower their security to make it
> > compatible to Mozilla/Firefox implementation...
> 
> 
> Not really. See above.
> 
> 
> They can decide that, even if questionable...)
> >
> 
> Well, it's worth noting that while they are different mechanisms, U2F +
> pinning offers
> much of the MITM protection that Token Binding provides, and Firefox already
> pins Google services.
> 
> -Ekr
> 
> 
> --
> > Fred
> >
> > On Monday, February 8, 2016 at 5:28:37 PM UTC+1, Eric Rescorla wrote:
> > > On Fri, Feb 5, 2016 at 3:22 PM, Fred Le Tamanoir
> > > wrote:
> > >
> > > > Hi,
> > > >
> > > > Great news about you making progress on this !
> > > >
> > > > Since I read here and there that you are working with Firefox & Chrome
> > U2F
> > > > support consistency in mind, what's your take on TLS Channel ID (Token
> > > > Binding) support inside Firefox ?
> > > >
> > > > It is a recommended feature for FIDO U2F client (Firefox here) inside
> > > > official specifications for additional protection against MITM
> > attacks...
> > > > and it is implemented on Google

Re: Intent to implement and ship: FIDO U2F API

2016-02-08 Thread Fred Le Tamanoir

Hi,

Great news about you making progress on this !

Since I read here and there that you are working with Firefox & Chrome U2F
support consistency in mind, what's your take on TLS Channel ID (Token
Binding) support inside Firefox ?

It is a recommended feature for FIDO U2F client (Firefox here) inside
official specifications for additional protection against MITM attacks...
and it is implemented on Google authentication servers (and on Chrome
client side of course). I don't know if Google team will make it mandatory
for non-Chrome browsers to be compatible with their own authentication
servers but anyway, I think this is an important issue to be discussed...

...and my personal point: we need this :)

On Thu, Feb 4, 2016 at 10:49 PM, J.C. Jones  wrote:

> All,
>
> We're making progress on implementing FIDO U2F in Firefox. The effort is
> split into a number of bugs at present. First, a quick rundown of where we
> are:
>
> * The tracking bug for U2F support is Bug 1065729.
> * Bug 1198330 is to implement USB HID support in Firefox.
> * Bug 1231681 implements the WebIDL and the outline of the JS API. This
> bug’s code is in review.
> * Bug 1244959 completes the AppId/FacetId algorithm.
> * Bug 1245527 implements the state machines (USBToken) between the JS API
> and the USB HID support.
> * Bug 1244960 expands an NSS-based U2F token (NSSToken) for expanded
> integration and developer testing.
>
> A couple of notes/clarifications about how we’re planning to build U2F
> support:
>
> * The `window.u2f` API endpoint will only be available to code loaded from
> secure origins, in keeping with our policy for new features [1]. (This is
> also consistent with U2F support that is built into recent versions of
> Google Chrome.)
> * We are implementing the high-level JavaScript API version 1.1. The
> specification for v1.1 is not yet published, but is already implemented in
> recent versions of Chromium [2].
> * For the time being, U2F support will be gated behind preferences and
> disabled by default.
>
> [1]
> https://blog.mozilla.org/security/2015/04/30/deprecating-non-secure-http/
> [2]
> https://chromium.googlesource.com/chromium/src/+/master/chrome/browser/resources/cryptotoken/webrequest.js
>
> - J.C.
>
>
> On Wed, Jan 27, 2016 at 2:44 AM, Frederic Martin  > wrote:
>
>> Nearly two
>> months since that post...
>> Any news on this ?
>>
>> a) on Mozilla Foundation joining FIDO Alliance?
>> b) on FIDO U2F implementation inside Firefox Core?
>>
>> Thanx.
>> ___
>> 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 implement and ship: FIDO U2F API

2016-02-08 Thread Eric Rescorla

On Fri, Feb 5, 2016 at 3:22 PM, Fred Le Tamanoir 
wrote:

> Hi,
>
> Great news about you making progress on this !
>
> Since I read here and there that you are working with Firefox & Chrome U2F
> support consistency in mind, what's your take on TLS Channel ID (Token
> Binding) support inside Firefox ?
>
> It is a recommended feature for FIDO U2F client (Firefox here) inside
> official specifications for additional protection against MITM attacks...
> and it is implemented on Google authentication servers (and on Chrome
> client side of course). I don't know if Google team will make it mandatory
> for non-Chrome browsers to be compatible with their own authentication
> servers but anyway, I think this is an important issue to be discussed...
>

See:
https://groups.google.com/d/msg/mozilla.dev.platform/IVGEJnQW3Uo/o9WzWgEqCwAJ

We're not likely to implement Channel ID, but we probably will implement
Token Binding
when it seems sufficiently stable

-Ekr



>
> ...and my personal point: we need this :)
>
> On Thu, Feb 4, 2016 at 10:49 PM, J.C. Jones  wrote:
>
> > All,
> >
> > We're making progress on implementing FIDO U2F in Firefox. The effort is
> > split into a number of bugs at present. First, a quick rundown of where
> we
> > are:
> >
> > * The tracking bug for U2F support is Bug 1065729.
> > * Bug 1198330 is to implement USB HID support in Firefox.
> > * Bug 1231681 implements the WebIDL and the outline of the JS API. This
> > bug’s code is in review.
> > * Bug 1244959 completes the AppId/FacetId algorithm.
> > * Bug 1245527 implements the state machines (USBToken) between the JS API
> > and the USB HID support.
> > * Bug 1244960 expands an NSS-based U2F token (NSSToken) for expanded
> > integration and developer testing.
> >
> > A couple of notes/clarifications about how we’re planning to build U2F
> > support:
> >
> > * The `window.u2f` API endpoint will only be available to code loaded
> from
> > secure origins, in keeping with our policy for new features [1]. (This is
> > also consistent with U2F support that is built into recent versions of
> > Google Chrome.)
> > * We are implementing the high-level JavaScript API version 1.1. The
> > specification for v1.1 is not yet published, but is already implemented
> in
> > recent versions of Chromium [2].
> > * For the time being, U2F support will be gated behind preferences and
> > disabled by default.
> >
> > [1]
> >
> https://blog.mozilla.org/security/2015/04/30/deprecating-non-secure-http/
> > [2]
> >
> https://chromium.googlesource.com/chromium/src/+/master/chrome/browser/resources/cryptotoken/webrequest.js
> >
> > - J.C.
> >
> >
> > On Wed, Jan 27, 2016 at 2:44 AM, Frederic Martin <
> fredletaman...@gmail.com
> > > wrote:
> >
> >> Nearly two
> >> months since that post...
> >> Any news on this ?
> >>
> >> a) on Mozilla Foundation joining FIDO Alliance?
> >> b) on FIDO U2F implementation inside Firefox Core?
> >>
> >> Thanx.
> >> ___
> >> 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
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship: FIDO U2F API

2016-02-08 Thread Frederic Martin

On Monday, February 8, 2016 at 10:54:36 PM UTC+1, Ryan Sleevi wrote:
> On Mon, Feb 8, 2016 at 1:13 PM, Frederic Martin wrote:
> >
> > 1) From a security architect perspective. This is an official 
> > recommendation that makes sens to prevent MITM attacks. FIDO U2F was 
> > created to minimize/eliminate that kind of risk.
> 
> U2F itself addresses phishing. Token Binding (attempts) to address
> MITM, but it's worth noting that they are separate problems with
> separate solutions. U2F / FIDO are still able to handedly address the
> former problem, without requiring treatment of the latter - it merely
> establishes how they can be used cooperatively, but that's not
> intrinsically necessary, nor necessarily wise.

Regarding "Addressing phishing", we all know this is a claim that can be 
supported very badly :) I heard so many times SMS codes and/or (T)OTP were 
supposed to cover that. Of course not. We both know that. Oh My.
http://www.neowave.fr/pleaseno/SMS_OTP_TOTP_QRCODE_SSL_ARE_NOT_SOLUTIONS.pdf

I really do support the simplified PKI design behind FIDO U2F (I am used to 
more standard and more complex to deploy PKI based token...) and I believe FIDO 
U2F is a great way to fight phishing attacks... but FIDO U2F security was 
designed to rely partially on SSL security since the server is identified 
through its hashed domain name... and users are supposed to be confident with 
this domain name through SSL server certificates. That's why... while I agree 
that fighting phishing and MITM may be different problems with different 
solutions, even the official FIDO U2F specifications makes it clear that TLS 
Channel ID is a recommended Security Measure linked to U2F architecture.
Search "[SM-12]" inside 
https://fidoalliance.org/specs/fido-u2f-v1.0-nfc-bt-amendment-20150514/fido-security-ref.html
I don't say there is a magical solution when mixing decentralized PKI and 
"pyramidal" PKI and there is no true server to device mutual authentication, 
SSL/TLS is used at this level (FIDO U2F Client/browser is still in charge of 
server authentication), SSL/TLS security is really linked to U2F regarding to 
MITM attacks conter measure.

> > 2) Firefox users could be discriminated out of servers implementing this 
> > protection.
> 
> Hopefully, you can likely recognize why this represents a very
> troubling problem of Token Binding - it enables service providers
> greater control to discriminate against users, reducing user freedom
> and the role of the browser as the user's agent.

Oh, there are already tons of way to discriminate browsers :)
Here it is just trying to push security recommendations to the max.
FIDO U2F technically even allow servers to discriminate token manufacturers. It 
goes both way and I am not even sure it is a real problem...
For now, the real problem is that FIDO U2F is the most secure way for users to 
authenticate directly to Google, Dropbox or GitHub services... and Firefox 
users (like myself) are already discriminated out of this security 
level/option. GitHub server authentication do not use TLS Channel ID (that's 
why we can already use firefox with the FIDO U2F Firefox addon from Pawel 
Chmielowski). For now, you can make your firefox trying to impersonate Chrome, 
it won't pass Google servers TLS Channel ID.

> While I think there's no disagreement that 'hostile' MITM is bad,
> there are plenty of cases where users intentionally and actively MITM
> themselves, for purposes that range from 'clearly legitimate' to
> 'questionable, but it's the user's call". In the case of "clearly
> legitimate", consider the work of security researchers and developers
> who wish to MITM themselves or their applications, in order to
> determine what data is leaking out. Any solution that actively
> prohibits this can end up undermining user's security.
> 
> If you think this is academic, consider that many service providers
> consider it a form of DRM to employ - that is, preventing MITM - and
> as such, represent's a loss of user privilege. What if your favourite
> sites all required you to do this, or other forms of protection (such
> as hardware-attested token binding keys that reveal unique
> identifiers). While the idea is that token binding keys can be
> rotated, we've certainly seen sites, particularly video providers, use
> every available fingerprinting mechanism they can in order to restrict
> how and on which devices a user accesses a given service - I doubt we
> would want to see or encourage more of that.
> 
> I think it's important to consider the harmful effects that Token
> Binding will have, and not just the positive. And that's why it's
> worthwhile to keep it under consideration, rather than commit. It is
> truly unfortunate that Chrome decided to launch this feature, without
> public discussion or review, and without concern for the implications
> of the ecosystem such as the one you raise - providers like Google
> using it to block out other browsers.

I am hardly following you on

Re: Intent to implement and ship: FIDO U2F API

2016-02-08 Thread Frederic Martin

Hi,

thanx for the answer.

Quoting Dirk Balfanz (one of the TLS Channel ID specifications author, a few 
days ago on FIDO DEV forum):

"the new spec that replaces ChannelID is called "Token Binding", and is in the 
process of being standardized by the IETF 
(https://datatracker.ietf.org/wg/tokbind/documents/).

It turns out that as far as FIDO is concerned, a Token Binding key or a 
ChannelID key are really the same thing: it's a public key that will be 
included in the client data and signed by the Authenticator. So while you're 
correct in pointing out that it's a bit weird that FIDO should reference a 
non-standard, other than changing a few words here and there I don't expect any 
changes to the FIDO specs once the Token Binding drafts have become standards."

Source : 
https://groups.google.com/a/fidoalliance.org/d/msg/fido-dev/hn_T6pKS0wU/aEO29oIeEAAJ

I am still concerned about Mozilla Foundation deciding not to implement this 
protection inside Firefox for two main reasons.

1) From a security architect perspective. This is an official recommendation 
that makes sens to prevent MITM attacks. FIDO U2F was created to 
minimize/eliminate that kind of risk. This would rather be a more secure 
decision to fully implement the best options. (I am working for a FIDO U2F 
device manufacturer and that's what we did on our side). I know this protection 
could sound like a oh-not-again-Google initiative, but it is rather efficient 
and it is not very complex to implement (it is mostly about returning a TLS 
related Channel ID public key used by the browser to communicate with the 
server...) and is very close of future "Token Binding" thing.

2) Firefox users could be discriminated out of servers implementing this 
protection. Even if this is mostly/only the case on Google authentication 
servers now, this would already make a difference. I am not a Google fan boy 
-and I am working with other online services to integrate FIDO U2F technology- 
but protecting their services accounts is often what everyone is thinking about 
now when discussing FIDO U2F (protecting Gmail, Gdrive, Youtube, or whatever 
Google related accounts). Did you speak with Google team guys to know if they 
will let Firefox be compatible with their FIDO U2F second factor option even 
without ChannelID protection on the client side? (this would mean that they'll 
accept to lower their security to make it compatible to Mozilla/Firefox 
implementation... They can decide that, even if questionable...)

Regards
--
Fred

On Monday, February 8, 2016 at 5:28:37 PM UTC+1, Eric Rescorla wrote:
> On Fri, Feb 5, 2016 at 3:22 PM, Fred Le Tamanoir 
> wrote:
> 
> > Hi,
> >
> > Great news about you making progress on this !
> >
> > Since I read here and there that you are working with Firefox & Chrome U2F
> > support consistency in mind, what's your take on TLS Channel ID (Token
> > Binding) support inside Firefox ?
> >
> > It is a recommended feature for FIDO U2F client (Firefox here) inside
> > official specifications for additional protection against MITM attacks...
> > and it is implemented on Google authentication servers (and on Chrome
> > client side of course). I don't know if Google team will make it mandatory
> > for non-Chrome browsers to be compatible with their own authentication
> > servers but anyway, I think this is an important issue to be discussed...
> >
> 
> See:
> https://groups.google.com/d/msg/mozilla.dev.platform/IVGEJnQW3Uo/o9WzWgEqCwAJ
> 
> We're not likely to implement Channel ID, but we probably will implement
> Token Binding
> when it seems sufficiently stable
> 
> -Ekr
> 
> 
> 
> >
> > ...and my personal point: we need this :)
> >
> > On Thu, Feb 4, 2016 at 10:49 PM, J.C. Jones  wrote:
> >
> > > All,
> > >
> > > We're making progress on implementing FIDO U2F in Firefox. The effort is
> > > split into a number of bugs at present. First, a quick rundown of where
> > we
> > > are:
> > >
> > > * The tracking bug for U2F support is Bug 1065729.
> > > * Bug 1198330 is to implement USB HID support in Firefox.
> > > * Bug 1231681 implements the WebIDL and the outline of the JS API. This
> > > bug's code is in review.
> > > * Bug 1244959 completes the AppId/FacetId algorithm.
> > > * Bug 1245527 implements the state machines (USBToken) between the JS API
> > > and the USB HID support.
> > > * Bug 1244960 expands an NSS-based U2F token (NSSToken) for expanded
> > > integration and developer testing.
> > >
> > > A couple of notes/clarifications about how we're planning to build U2F
> > > support:
> > >
> > > * The `window.u2f` API endpoint will only be available to code loaded
> > from
> > > secure origins, in keeping with our policy for new features [1]. (This is
> > > also consistent with U2F support that is built into recent versions of
> > > Google Chrome.)
> > > * We are implementing the high-level JavaScript API version 1.1. The
> > > specification for v1.1 is not yet published, but is already implemented
> >

Re: Intent to implement and ship: FIDO U2F API

2016-02-08 Thread Ryan Sleevi

On Mon, Feb 8, 2016 at 1:13 PM, Frederic Martin wrote:
>
> 1) From a security architect perspective. This is an official recommendation 
> that makes sens to prevent MITM attacks. FIDO U2F was created to 
> minimize/eliminate that kind of risk.

U2F itself addresses phishing. Token Binding (attempts) to address
MITM, but it's worth noting that they are separate problems with
separate solutions. U2F / FIDO are still able to handedly address the
former problem, without requiring treatment of the latter - it merely
establishes how they can be used cooperatively, but that's not
intrinsically necessary, nor necessarily wise.

> 2) Firefox users could be discriminated out of servers implementing this 
> protection.

Hopefully, you can likely recognize why this represents a very
troubling problem of Token Binding - it enables service providers
greater control to discriminate against users, reducing user freedom
and the role of the browser as the user's agent.

While I think there's no disagreement that 'hostile' MITM is bad,
there are plenty of cases where users intentionally and actively MITM
themselves, for purposes that range from 'clearly legitimate' to
'questionable, but it's the user's call". In the case of "clearly
legitimate", consider the work of security researchers and developers
who wish to MITM themselves or their applications, in order to
determine what data is leaking out. Any solution that actively
prohibits this can end up undermining user's security.

If you think this is academic, consider that many service providers
consider it a form of DRM to employ - that is, preventing MITM - and
as such, represent's a loss of user privilege. What if your favourite
sites all required you to do this, or other forms of protection (such
as hardware-attested token binding keys that reveal unique
identifiers). While the idea is that token binding keys can be
rotated, we've certainly seen sites, particularly video providers, use
every available fingerprinting mechanism they can in order to restrict
how and on which devices a user accesses a given service - I doubt we
would want to see or encourage more of that.

I think it's important to consider the harmful effects that Token
Binding will have, and not just the positive. And that's why it's
worthwhile to keep it under consideration, rather than commit. It is
truly unfortunate that Chrome decided to launch this feature, without
public discussion or review, and without concern for the implications
of the ecosystem such as the one you raise - providers like Google
using it to block out other browsers.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship: FIDO U2F API

2016-02-08 Thread Eric Rescorla

On Mon, Feb 8, 2016 at 10:13 PM, Frederic Martin 
wrote:

> Hi,
>
> thanx for the answer.
>
> Quoting Dirk Balfanz (one of the TLS Channel ID specifications author, a
> few days ago on FIDO DEV forum):
>
> "the new spec that replaces ChannelID is called "Token Binding", and is in
> the process of being standardized by the IETF (
> https://datatracker.ietf.org/wg/tokbind/documents/).
>
> It turns out that as far as FIDO is concerned, a Token Binding key or a
> ChannelID key are really the same thing: it's a public key that will be
> included in the client data and signed by the Authenticator. So while
> you're correct in pointing out that it's a bit weird that FIDO should
> reference a non-standard, other than changing a few words here and there I
> don't expect any changes to the FIDO specs once the Token Binding drafts
> have become standards."
>
> Source :
> https://groups.google.com/a/fidoalliance.org/d/msg/fido-dev/hn_T6pKS0wU/aEO29oIeEAAJ
>

I'm not following how this is responsive to my point, which isn't about the
text
in FIDO but rather about what actually goes into Firefox. From that
perspective,
what Dirk says is correct, namely that the FIDO interface to Token Binding
and Channel ID are very similar. However, we have to implement one or the
other or both in TLS, and I don't see a lot of value in doing both.


I am still concerned about Mozilla Foundation deciding not to implement
> this protection inside Firefox for two main reasons.
>
> 1) From a security architect perspective. This is an official
> recommendation that makes sens to prevent MITM attacks. FIDO U2F was
> created to minimize/eliminate that kind of risk. This would rather be a
> more secure decision to fully implement the best options. (I am working for
> a FIDO U2F device manufacturer and that's what we did on our side).


I don't understand this point. The manufacturer doesn't implement token
binding:
it's in the browser stack.


2) Firefox users could be discriminated out of servers implementing this
> protection. Even if this is mostly/only the case on Google authentication
> servers now, this would already make a difference. I am not a Google fan
> boy -and I am working with other online services to integrate FIDO U2F
> technology- but protecting their services accounts is often what everyone
> is thinking about now when discussing FIDO U2F (protecting Gmail, Gdrive,
> Youtube, or whatever Google related accounts). Did you speak with Google
> team guys to know if they will let Firefox be compatible with their FIDO
> U2F second factor option even without ChannelID protection on the client
> side?


Well, I see Ryan Sleevi responded below, but no, I haven't validated this
one way
or the other with Google. With that said, I would be somewhat disappointed
if
Google required Token Binding with U2F, given that they don't require it
without
U2F. It's certainly not consistent with previous claims -- or the
underlying design
of FIDO -- to say that token binding is required for FOD to add value.



> (this would mean that they'll accept to lower their security to make it
> compatible to Mozilla/Firefox implementation...


Not really. See above.


They can decide that, even if questionable...)
>

Well, it's worth noting that while they are different mechanisms, U2F +
pinning offers
much of the MITM protection that Token Binding provides, and Firefox already
pins Google services.

-Ekr


--
> Fred
>
> On Monday, February 8, 2016 at 5:28:37 PM UTC+1, Eric Rescorla wrote:
> > On Fri, Feb 5, 2016 at 3:22 PM, Fred Le Tamanoir
> > wrote:
> >
> > > Hi,
> > >
> > > Great news about you making progress on this !
> > >
> > > Since I read here and there that you are working with Firefox & Chrome
> U2F
> > > support consistency in mind, what's your take on TLS Channel ID (Token
> > > Binding) support inside Firefox ?
> > >
> > > It is a recommended feature for FIDO U2F client (Firefox here) inside
> > > official specifications for additional protection against MITM
> attacks...
> > > and it is implemented on Google authentication servers (and on Chrome
> > > client side of course). I don't know if Google team will make it
> mandatory
> > > for non-Chrome browsers to be compatible with their own authentication
> > > servers but anyway, I think this is an important issue to be
> discussed...
> > >
> >
> > See:
> >
> https://groups.google.com/d/msg/mozilla.dev.platform/IVGEJnQW3Uo/o9WzWgEqCwAJ
> >
> > We're not likely to implement Channel ID, but we probably will implement
> > Token Binding
> > when it seems sufficiently stable
> >
> > -Ekr
> >
> >
> >
> > >
> > > ...and my personal point: we need this :)
> > >
> > > On Thu, Feb 4, 2016 at 10:49 PM, J.C. Jones 
> wrote:
> > >
> > > > All,
> > > >
> > > > We're making progress on implementing FIDO U2F in Firefox. The
> effort is
> > > > split into a number of bugs at present. First, a quick rundown of
> where
> > > we
> > > > are:
> > > >
> > > > * The

Re: Intent to implement and ship: FIDO U2F API

2016-02-04 Thread J.C. Jones

All,

We're making progress on implementing FIDO U2F in Firefox. The effort is
split into a number of bugs at present. First, a quick rundown of where we
are:

* The tracking bug for U2F support is Bug 1065729.
* Bug 1198330 is to implement USB HID support in Firefox.
* Bug 1231681 implements the WebIDL and the outline of the JS API. This
bug’s code is in review.
* Bug 1244959 completes the AppId/FacetId algorithm.
* Bug 1245527 implements the state machines (USBToken) between the JS API
and the USB HID support.
* Bug 1244960 expands an NSS-based U2F token (NSSToken) for expanded
integration and developer testing.

A couple of notes/clarifications about how we’re planning to build U2F
support:

* The `window.u2f` API endpoint will only be available to code loaded from
secure origins, in keeping with our policy for new features [1]. (This is
also consistent with U2F support that is built into recent versions of
Google Chrome.)
* We are implementing the high-level JavaScript API version 1.1. The
specification for v1.1 is not yet published, but is already implemented in
recent versions of Chromium [2].
* For the time being, U2F support will be gated behind preferences and
disabled by default.

[1]
https://blog.mozilla.org/security/2015/04/30/deprecating-non-secure-http/
[2]
https://chromium.googlesource.com/chromium/src/+/master/chrome/browser/resources/cryptotoken/webrequest.js

- J.C.

On Wed, Jan 27, 2016 at 2:44 AM, Frederic Martin 
wrote:

> Nearly two months
> since that post...
> Any news on this ?
>
> a) on Mozilla Foundation joining FIDO Alliance?
> b) on FIDO U2F implementation inside Firefox Core?
>
> Thanx.
> ___
> 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 implement and ship: FIDO U2F API

2016-01-27 Thread Frederic Martin

On Wednesday, December 2, 2015 at 2:23:28 AM UTC+1, Richard Barnes wrote:
> The FIDO Alliance has been developing standards for hardware-based
> authentication of users by websites [1].  Their work is getting significant
> traction, so the Mozilla Foundation has decided to join the FIDO Alliance.
> Work has begun in the W3C to create open standards using FIDO as a starting
> point. We are proposing to implement the FIDO U2F API in Firefox in its
> current form and then track the evolving W3C standard.
> 
> Background: The FIDO Alliance has been developing a standard for
> hardware-based user authentication known as "Universal Two-Factor" or U2F
> [2].  This standard allows a website to verify that a user is in possession
> of a specific device by having the device sign a challenge with a private
> key that is held on the hardware device.  The browser's role is mainly (1)
> to route messages between the website and the token, and (2) to add the
> origin of the website to the message signed by the token (so that the
> signature is bound to the site).
> 
> Several major websites now support U2F for authentication, including Google
> [3], Dropbox [4], and Github [5].  Axel Nennker has filed a Bugzilla bug
> for U2F support in Gecko [6].  The W3C has  begun the process of forming a
> "WebAuthentication" working group that will work on a standard for enhanced
> authentication using FIDO as a starting point [7].
> 
> Proposed: To implement the high-level U2F API described in the FIDO JS API
> specification, with support for the USB HID token interface.
> 
> Please send comments on this proposal to the list no later than Monday,
> December 14, 2015.
> 
> -
> 
> Personally, I have some reservations about implementing this, but I still
> think it's worth doing, given the clear need for something to augment
> passwords.
> 
> It's unfortunate that the initial FIDO standards were developed in a closed
> group, but there is good momentum building toward making FIDO more open.  I
> have some specific concerns about the U2F API itself, but they're
> relatively minor.  For example, the whole system is highly vertically
> integrated, so if we want to change any part of it (e.g., to use a curve
> other than P-256 for signatures), we'll need to build a whole new API.  But
> these are issues that can be addressed in the W3C process.
> 
> We will continue to work on making standards for secure authentication more
> open.  In the meantime, U2F is what's here now, and there's demonstrated
> developer interest, so it makes sense for us to work on implementing it.
> 
> Thanks,
> --Richard
> 
> [1] https://fidoalliance.org/
> [2] https://fidoalliance.org/specifications/download/
> [3] https://support.google.com/accounts/answer/6103523?hl=en
> [4] https://blogs.dropbox.com/dropbox/2015/08/u2f-security-keys/
> [5]
> https://github.com/blog/2071-github-supports-universal-2nd-factor-authentication
> [6] https://bugzilla.mozilla.org/show_bug.cgi?id=1065729
> [7] http://w3c.github.io/websec/web-authentication-charter

Nearly two months since that post...
Any news on this ?

a) on Mozilla Foundation joining FIDO Alliance?
b) on FIDO U2F implementation inside Firefox Core?

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

Re: Intent to implement and ship: WebKitCSSMatrix

2016-01-15 Thread Mike Taylor


On 1/14/16 9:09 PM, L. David Baron wrote:

It seems to me this is important to have behind a preference that is
specific to new webkit-prefixed features, given the compatibility
risks of shipping support for some but not all webkit-prefixed
features.

(It's possible it could be the same preference as other new
webkit-prefixed CSS features.)

/lists.mozilla.org/listinfo/dev-platform

This is probably a good idea, given the (frequent) interdependency 
between WebKitCSSMatrix and webkitTransform:




--
Mike Taylor
Web Compat, Mozilla
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship: WebKitCSSMatrix

2016-01-14 Thread L. David Baron

On Thursday 2016-01-14 14:06 -0800, William Chen wrote:
> *Summary*: WebKitCSSMatrix has been available for years in WebKit based
> browsers and has seen widespread usage on the web. This feature is
> currently available in Chrome, Safari and Edge. Mike Taylor has been
> working on standardizing the feature and it is being implemented in Gecko
> to improve web compatibility.
> 
> *Bug*: https://bugzilla.mozilla.org/show_bug.cgi?id=717722
> 
> *Link to standard*:
> https://compat.spec.whatwg.org/#webkitcssmatrix-interface
> 
> 
> *Platform coverage*: All platforms.
> 
> *Estimated or target release*: Firefox 46

It seems to me this is important to have behind a preference that is
specific to new webkit-prefixed features, given the compatibility
risks of shipping support for some but not all webkit-prefixed
features.

(It's possible it could be the same preference as other new
webkit-prefixed CSS features.)

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


signature.asc
Description: Digital signature
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship: WebKitCSSMatrix

2016-01-14 Thread Jonas Sicking

Ship it!

On Thu, Jan 14, 2016 at 2:06 PM, William Chen  wrote:
> *Summary*: WebKitCSSMatrix has been available for years in WebKit based
> browsers and has seen widespread usage on the web. This feature is
> currently available in Chrome, Safari and Edge. Mike Taylor has been
> working on standardizing the feature and it is being implemented in Gecko
> to improve web compatibility.
>
> *Bug*: https://bugzilla.mozilla.org/show_bug.cgi?id=717722
>
> *Link to standard*:
> https://compat.spec.whatwg.org/#webkitcssmatrix-interface
> 
>
> *Platform coverage*: All platforms.
>
> *Estimated or target release*: Firefox 46
> ___
> 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

Intent to implement and ship: WebKitCSSMatrix

2016-01-14 Thread William Chen

*Summary*: WebKitCSSMatrix has been available for years in WebKit based
browsers and has seen widespread usage on the web. This feature is
currently available in Chrome, Safari and Edge. Mike Taylor has been
working on standardizing the feature and it is being implemented in Gecko
to improve web compatibility.

*Bug*: https://bugzilla.mozilla.org/show_bug.cgi?id=717722

*Link to standard*:
https://compat.spec.whatwg.org/#webkitcssmatrix-interface


*Platform coverage*: All platforms.

*Estimated or target release*: Firefox 46
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship: FIDO U2F API

2015-12-08 Thread hillbrad

I'm no longer directly involved with the FIDO Alliance, so I can't speak to the 
FIDO 2.0 timelines, but my general experience there plus at the W3C tells me 
that it will some time before the new APIs stabilize.  I hope that this won't 
dissuade Mozilla from beginning work on implementing U2F more-or-less 
immediately.

1) Much of the work involved is in building the USB transports (the crypto is 
rather simple) and that code will likely be highly reusable for 2.0 APIs.

2) There is a growing set of services adopting U2F today, a robust and 
competitive market for the hardware, and Firefox support would be a important 
contributor to "critical mass" for the FIDO approach, regardless of the 
particular version.  A privacy-friendly, strong and origin-bound authentication 
mechanism, based on open protocols, with hardware chosen by the user, seems to 
fit very well within the general values and vision of Mozilla.  I think it is 
valuable to give it momentum at a time when alternative approaches that don't 
respect user privacy or the web security model in the same way are being 
heavily pushed.

3) I think it would be OK to leave out Channel ID support as the approach is 
clearly being deprecated and it represents only a tiny fraction of the value 
provided by U2F.

cheers,

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

Re: Intent to implement and ship: FIDO U2F API

2015-12-04 Thread smaug

On 12/04/2015 06:56 PM, smaug wrote:

Looks like the spec could be made implementable by fixing
https://fidoalliance.org/specs/fido-u2f-v1.0-nfc-bt-amendment-20150514/fido-u2f-javascript-api.html#high-level-javascript-api

"provide a namespace object u2f of the following interface" doesn't mean
anything, so either there is supposed to be an instance of u2f interface
somewhere (in Window object?), but feels odd to expose interface called u2f and
having u2f as a property of Window.
Perhaps the idea there is that the interface has only static methods?
Then register() and sign() should be marked as static and there wouldn't be an
instance of u2f, but one would just call those static methods
on the u2f interface.

But whether that is compatible with Chrome - no idea.

(Nit, the convention is that interfaces start with a capital letter. For some
odd reason 'u2f' doesn't follow that.)

-Olli

On 12/02/2015 11:20 PM, smaug wrote:

On 12/02/2015 03:23 AM, Richard Barnes wrote:

The FIDO Alliance has been developing standards for hardware-based
authentication of users by websites [1]. Their work is getting significant
traction, so the Mozilla Foundation has decided to join the FIDO Alliance.
Work has begun in the W3C to create open standards using FIDO as a starting
point. We are proposing to implement the FIDO U2F API in Firefox in its
current form and then track the evolving W3C standard.

Background: The FIDO Alliance has been developing a standard for
hardware-based user authentication known as “Universal Two-Factor” or U2F
[2]. This standard allows a website to verify that a user is in possession
of a specific device by having the device sign a challenge with a private
key that is held on the hardware device. The browser’s role is mainly (1)
to route messages between the website and the token, and (2) to add the
origin of the website to the message signed by the token (so that the
signature is bound to the site).

Several major websites now support U2F for authentication, including Google
[3], Dropbox [4], and Github [5]. Axel Nennker has filed a Bugzilla bug
for U2F support in Gecko [6]. The W3C has begun the process of forming a
“WebAuthentication” working group that will work on a standard for enhanced
authentication using FIDO as a starting point [7].

Proposed: To implement the high-level U2F API described in the FIDO JS API
specification, with support for the USB HID token interface.

As I said in the other email,
I don't understand how this could be implemented when the spec has left the key
piece undefined, as far as I see.
As the spec puts it "This specification does not describe how such a port is
made available to RP web pages, as this is (for now) implementation and
browser dependent. "

Please send comments on this proposal to the list no later than Monday,
December 14, 2015.

Personally, I have some reservations about implementing this, but I still
think it’s worth doing, given the clear need for something to augment
passwords.

It’s unfortunate that the initial FIDO standards were developed in a closed
group, but there is good momentum building toward making FIDO more open. I
have some specific concerns about the U2F API itself, but they’re
relatively minor. For example, the whole system is highly vertically
integrated, so if we want to change any part of it (e.g., to use a curve
other than P-256 for signatures), we’ll need to build a whole new API. But
these are issues that can be addressed in the W3C process.

We will continue to work on making standards for secure authentication more
open. In the meantime, U2F is what’s here now, and there’s demonstrated
developer interest, so it makes sense for us to work on implementing it.

Thanks,
--Richard

[1] https://fidoalliance.org/
[2] https://fidoalliance.org/specifications/download/
[3] https://support.google.com/accounts/answer/6103523?hl=en
[4] https://blogs.dropbox.com/dropbox/2015/08/u2f-security-keys/
[5]
https://github.com/blog/2071-github-supports-universal-2nd-factor-authentication
[6] https://bugzilla.mozilla.org/show_bug.cgi?id=1065729
[7] http://w3c.github.io/websec/web-authentication-charter

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

Re: Intent to implement and ship: FIDO U2F API

2015-12-04 Thread smaug

Looks like the spec could be made implementable by fixing
https://fidoalliance.org/specs/fido-u2f-v1.0-nfc-bt-amendment-20150514/fido-u2f-javascript-api.html#high-level-javascript-api

(Nit, the convention is that interfaces start with a capital letter. For some
odd reason 'u2f' doesn't follow that.)

-Olli

On 12/02/2015 11:20 PM, smaug wrote:

On 12/02/2015 03:23 AM, Richard Barnes wrote:

Proposed: To implement the high-level U2F API described in the FIDO JS API
specification, with support for the USB HID token interface.

Please send comments on this proposal to the list no later than Monday,
December 14, 2015.

Personally, I have some reservations about implementing this, but I still
think it’s worth doing, given the clear need for something to augment
passwords.

Thanks,
--Richard

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

Re: Intent to implement and ship: FIDO U2F API

2015-12-03 Thread smaug


On 12/02/2015 11:37 PM, Frederic Martin wrote:

As I said in the other email,
I don't understand how this could be implemented when the spec has left the 
>key piece undefined, as far as I see.


You are completely right ! For now, FIDO 2 is currently being written (far far 
far from finished) and can't be implemented, so let's focus on existing 
solutions with existing specifications and existing products (the ones that 
work with google/gmail, github, dropbox and many federated identity portals.

FIDO U2F specifications are complete for USB/HID devices & desktop browsers.


Can you show me how a web page gets access to some API entry point? I haven't 
seen any spec defining how
the relevant MessagePort or some u2f object can be accessed.
To me the spec looks very much incomplete, in the sense that based on it one 
can't create
interoperable implementations.


-Olli




Additional information (copy/paste from a previous post of mine above
with small updates):

- FIDO 2.0 will not replace FIDO U2F
- There will probably not be any kind of FIDO U2F 2.0 inside FIDO 2.0
- FIDO 2.0 has no goal to be compatible with FIDO U2F (and won't be)
- FIDO U2F is already here and here to stay. It is a great WORKING
   solution: a secure second factor for strong web authentication
   through a simple HID based API.
- There is already plenty of FIDO U2F related source code available
   to help people building great solutions (Chromium client source code,
   Google JS library source code and different Java/PHP/Go/etc. server code)
- Nearly all FIDO U2F products have really secure architectures
   (i.e. nearly every products are using secure elements / smart cards
   components, even if not mandatory, that's great)
- FIDO U2F over NFC and BLE specifications are currently being
   finalized, so there will be flexibility to cover mobile platforms.
- FIDO 2.0 W3c submission have no real details regarding technical
   implementation because FIDO 2 is only for now a very confusing draft
   with strange (*cough*) directions, so do not put too many hopes
   into FIDO 2.0 (that's really not important for now)

=> So let's focus on U2F :)



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

Re: Intent to implement and ship: FIDO U2F API

2015-12-02 Thread Richard Barnes

On Wed, Dec 2, 2015 at 12:25 AM, <ryan.sle...@gmail.com> wrote:

> On Tuesday, December 1, 2015 at 6:04:30 PM UTC-8, Jonas Sicking wrote:
> > Oh well. Bummer.
> >
> > / Jonas
>
> If it cheers you up any, the 2.0 API that replaces the U2F API uses
> promises - http://www.w3.org/Submission/2015/SUBM-fido-web-api-20151120/
>
> Richard, it would help if you could clarify - are you proposing that
> Firefox implement the 'old and deprecated' U2F API [1], or the 'fresh and
> new and hoping to be standards track' W3C member submission API [2].
>
> I originally wanted to reply with 'good news' that Chrome only shipped
> this for google.com, and only for HTTPS, and that we were committed to
> the W3C member submission as the path forward, but as I was working to back
> up a citation to this, I found out that we submarine-launched the API in
> Chrome 40 [3], for all HTTP and HTTPS origins, without an Intent to
> Implement / Intent to Ship.
>
> So, speaking solely on my behalf and not that of my employer, sorry that
> Chrome put Firefox in this position of "old and busted" and "new hotness",
> with "damned either way" as the result. I'm trying to find out more about
> this, as well as Chrome and Chromium's future commitments regarding this
> API.
>
> That said, knowing full well that the FIDO Alliance intends the W3C member
> submission to the path forward, could you provide greater clarity:
> 1) What it is you intend to implement?
>

My initial intent was to propose implementing [1], then implementing [2]
when it's ready.  After all, there's a lot in common, and as you say, the
W3C version will be much nicer.



> 2) If you intend to implement [1], whether or not you'll unship that
> if/as/when [2] progresses?
>

I think we would treat this just like we treat other early-stage things
that get shipped, gradually turning it off when the real thing shows up.

I don't remember what the current conventional wisdom about prefixing is,
but I would be open to shipping with a prefix if people thought that would
ease pain in the eventual transition.

--Richard



> [1]
> https://fidoalliance.org/specs/fido-u2f-v1.0-nfc-bt-amendment-20150514/fido-u2f-javascript-api.html
> [2] http://www.w3.org/Submission/2015/SUBM-fido-web-api-20151120/
> [3]
> https://chromium.googlesource.com/chromium/src/+/d60fcd7caafa7046da693fe2c3206ab5cf20%5E%21/#F9
> ___
> 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 implement and ship: FIDO U2F API

2015-12-02 Thread fredletamanoir

Hi All, great news !

TL;DR version:
--

I love U2F, I love Firefox
FIDO U2F is here to stay. 
FIDO 2.0 do not exist and will not replace U2F.
FIDO U2F is really great.
Please implement FIDO U2F.
Please please please implement TLS Channel ID Binding support
(important part of FIDO U2F specifications, but not mandatory)
Please consider larger HID support (as in Chrome).

Full version:
-

As you may know, we are several people to push for Firefox FIDO U2F 
support (https://bugzilla.mozilla.org/show_bug.cgi?id=1065729)
I joined the Bounty source initiative and was following the recent 
Firefox U2F support made through the small firefox extension...
(it works even if there is no TLS Channel ID Binding protection,
see below about that)

I am a Mozilla supporter for many many years and I work as a security 
architect inside a small company manufacturing FIDO U2F USB products...
so this is the kind of discussion I was dreaming of :)

> If it cheers you up any, the 2.0 API that replaces the U2F API uses
> promises - http://www.w3.org/Submission/2015/SUBM-fido-web-api-20151120/
> Richard, it would help if you could clarify - are you proposing that 
> Firefox implement the 'old and deprecated' U2F API [1], or the 'fresh
> and new and hoping to be standards track' W3C member submission API [2].

Let's be clear with some real information here:
- FIDO 2.0 will not replace FIDO U2F
- There will probably not be any kind of FIDO U2F 2.0 inside FIDO 2.0
- FIDO 2.0 has no goal to be compatible with FIDO U2F (and won't be)
- FIDO U2F is already here and here to stay. It is a great WORKING 
  solution: a secure second factor for strong web authentication 
  through a simple HID based API.
- There is alrady plenty of FIDO U2F related source code available
  to help people building great solutions (Chromium client source code,
  Google JS library source code and different Java/PHP server code)
- Nearly all FIDO U2F products have really secure architectures
  (for example, nearly every products are using secure elements /
   smart cards components, even if not mandatory, that's great)
- FIDO U2F over NFC and BLE specifications are currently being
  finalized, so there will be flexibility to cover mobile platforms.
- FIDO 2.0 W3c submission have no real details regarding technical
  implementation because FIDO 2 is only for now a very confusing draft 
  and there are lots of pressure to forget desktop based authentication, 
  to forget to use hardware with secure elements and several other 
  strange things you'll have to discover by yourself... Please do
  not put too many hopes into FIDO 2.0 (that's really not important)

> I originally wanted to reply with 'good news' [...] 
> [...] put Firefox in this position of "old and busted" and 
> "new hotness", with "damned either way" as the result. I'm trying to 
> find out more about this, as well as Chrome and Chromium's future 
> commitments regarding this API.

So, U2F is not old and busted, U2F is working and kicks ass :)
Google contributions to the specs and the Alliance were amazing.
And this is a real open standard, with real standard crypto.

- More and more services are directly adopting U2F.
- Federated Identity providers / web SSO solutions are adopting it.
- Firefox MUST adopt it :)

> That said, knowing full well that the FIDO Alliance intends the W3C 
> member submission to the path forward, could you provide greater clarity:
> 1) What it is you intend to implement?
> 2) If you intend to implement [1], whether or not you'll unship that 
> if/as/when [2] progresses?
> 
> [1] 
> https://fidoalliance.org/specs/fido-u2f-v1.0-nfc-bt-amendment-20150514/fido-u2f-javascript-api.html
> [2] http://www.w3.org/Submission/2015/SUBM-fido-web-api-20151120/

So, let's forget about 2 for now, it is not a real thing... and
well.. let's forget it. (If you read both specs you should see
real differences and problems...)

There are probably other questions Mozilla Core Team should ask to
themselves :

- Having a greater/larger HID Support, outside the FIDO U2F scope ?
(This allows web services to communicate with HID devices - i.e. 
that's how some cryptocurrencies hardware wallets are using HID 
Chrome interface)

- Have TLS Channel ID Binding support. (Oh, this is really important)
When you'll check FIDO U2F specifications, you'll see that TLS Channel
ID Binding is an important part of the security against attacks like
SSL Proxy and similar MITM attacks. This part is not mandatory. But 
Google servers are using this and Chrome supports it. So... please 
REALLY consider implementing it: it will bring higher security and 
probably will give a chance too in the future to be accepted as a 
supported browser on Google servers (I am not from Google so I can't 
speak on their behalf but this should be a rational requirements there).
This is the only way to provide a full anti-phishing solution.

By the way, thanx for all the work and recent contributions to this

Re: Intent to implement and ship: FIDO U2F API

2015-12-02 Thread Ms2ger

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 12/02/2015 03:48 PM, Richard Barnes wrote:
> I think we would treat this just like we treat other early-stage
> things that get shipped, gradually turning it off when the real
> thing shows up.

That would mean only shipping it on Nightly and maybe Aurora for now.

> I don't remember what the current conventional wisdom about
> prefixing is, but I would be open to shipping with a prefix if
> people thought that would ease pain in the eventual transition.

No. Nonononononononono.

Ms2ger
-BEGIN PGP SIGNATURE-

iQEcBAEBAgAGBQJWXwXcAAoJEOXgvIL+s8n2ZwIH/2XJbkWFfG57Bvsum1EIREVz
bSbRXE3eLsUyYtOIWhT8NX3PWuvqFH8/xmkvTGq57CwHxVQiHT6Su+voLG7qLNpK
pInNX475lLK/oj81mHvRAlymlC3MjVHWp53UeAz1fTW3i66ez0YT/vZtD2iA5YMo
iOcIL6VhSXFUHI8yWwFJIcQ/p60pwRBOEA9IJIIAJJk84xf9tEakNbqM1pQwFesW
ROyL7ZFOxLH/oGWCPWxoYfM/btfEqcYDC4FuEsd4SIruyD8liGJ3SMLnXkt7y9k8
8RcfqfUKjlhbE2fzzOf0ooNokpmzhxk2flEzNX8Y/bWl8glMKsbs0Dy89re8tTw=
=Z0LB
-END PGP SIGNATURE-
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship: FIDO U2F API

2015-12-02 Thread Mike Taylor


On 12/2/15 8:53 AM, Ms2ger wrote:

I don't remember what the current conventional wisdom about
prefixing is, but I would be open to shipping with a prefix if
people thought that would ease pain in the eventual transition.


No. Nonononononononono.


This is the conventional wisdom. Prefixes end up causing pain.

--
Mike Taylor
Web Compat, Mozilla
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship: FIDO U2F API

2015-12-02 Thread Frederik Braun

On 02.12.2015 18:53, Robert O'Callahan wrote:
> On Wed, Dec 2, 2015 at 9:37 AM, Eric Rescorla  wrote:
> 
>> Are you thinking of something like WebUSB?
>> (https://reillyeon.github.io/webusb/)? This is something we've looked at
>> a bit but we're still trying to wrap our heads around the security
>> implications.
>>
> 
> Where are we discussing that? I'd really like to see WebUSB with USB device
> IDs are bound to specific origins (through a registry for legacy devices
> and through the USB protocol extensions defined in that spec) so that
> vendors can host apps that access their devices --- and so that vendor
> pages in an  can define and vend "safe" APIs to any third-party
> application. We'd finally have decentralized extensibility for Web APIs to
> hardware.
> 
> Rob
> 

This is an interesting architecture.
I was originally thinking about allowing to list all possible devices
*and* preventing fingerprinting through a chrome dialog that mediates
between content and the user: The user chooses which device(s) to expose
to the specific website they are on. Similar to .
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship: FIDO U2F API

2015-12-02 Thread Eric Rescorla

On Wed, Dec 2, 2015 at 9:53 AM, Robert O'Callahan 
wrote:

> On Wed, Dec 2, 2015 at 9:37 AM, Eric Rescorla  wrote:
>
>> Are you thinking of something like WebUSB?
>> (https://reillyeon.github.io/webusb/)? This is something we've looked at
>> a bit but we're still trying to wrap our heads around the security
>> implications.
>>
>
> Where are we discussing that?
>

Richard and I have discussed it privately and had some offline interactions
with the authors. IIRC I made some comments on one of the bugs and on
some mailing list a while ago.

> I'd really like to see WebUSB with USB device IDs are bound to specific
> origins (through a registry for legacy devices and through the USB protocol
> extensions defined in that spec) so that vendors can host apps that access
> their devices --- and so that vendor pages in an  can define and
> vend "safe" APIs to any third-party application.
>

This seems to be roughly the API contemplated by the WebUSB spec.
To be honest, I'm not very excited about that design. Having a system
where the only people who can talk to USB device X are the manufacturers
and the browser is just a conduit for that interaction doesn't really seem
that
great for the Open Web.

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

Re: Intent to implement and ship: FIDO U2F API

2015-12-02 Thread Ehsan Akhgari


On 2015-12-02 9:48 AM, Richard Barnes wrote:

On Wed, Dec 2, 2015 at 12:25 AM, <ryan.sle...@gmail.com> wrote:


On Tuesday, December 1, 2015 at 6:04:30 PM UTC-8, Jonas Sicking wrote:

Oh well. Bummer.

/ Jonas


If it cheers you up any, the 2.0 API that replaces the U2F API uses
promises - http://www.w3.org/Submission/2015/SUBM-fido-web-api-20151120/

Richard, it would help if you could clarify - are you proposing that
Firefox implement the 'old and deprecated' U2F API [1], or the 'fresh and
new and hoping to be standards track' W3C member submission API [2].

I originally wanted to reply with 'good news' that Chrome only shipped
this for google.com, and only for HTTPS, and that we were committed to
the W3C member submission as the path forward, but as I was working to back
up a citation to this, I found out that we submarine-launched the API in
Chrome 40 [3], for all HTTP and HTTPS origins, without an Intent to
Implement / Intent to Ship.

So, speaking solely on my behalf and not that of my employer, sorry that
Chrome put Firefox in this position of "old and busted" and "new hotness",
with "damned either way" as the result. I'm trying to find out more about
this, as well as Chrome and Chromium's future commitments regarding this
API.


That would be awesome, thanks, Ryan!

Do you mind also checking to see if this feature has an associated use 
counter in Chrome, and if so, how widely it's being used?



That said, knowing full well that the FIDO Alliance intends the W3C member
submission to the path forward, could you provide greater clarity:
1) What it is you intend to implement?



My initial intent was to propose implementing [1], then implementing [2]
when it's ready.  After all, there's a lot in common, and as you say, the
W3C version will be much nicer.




2) If you intend to implement [1], whether or not you'll unship that
if/as/when [2] progresses?



I think we would treat this just like we treat other early-stage things
that get shipped, gradually turning it off when the real thing shows up.


We usually keep such features on Nightly and Aurora and don't let them 
ride the trains all the way to release.  However in this particular 
case, I'm not sure if doing that would make sense if we end up deciding 
on not shipping the old API at all.


Given the Chrome situation, and that Edge seems to be working on 
implementing the new version of the API 
<https://dev.windows.com/en-us/microsoft-edge/platform/status/fido20webapis>, 
perhaps we should wait to see if Chrome compat requires us to implement 
the v1 of the API, and if not, skip it?


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

Re: Intent to implement and ship: FIDO U2F API

2015-12-02 Thread Ryan Sleevi

On Wednesday, December 2, 2015 at 1:17:46 PM UTC-8, smaug wrote:
> I don't understand how 1) could be implemented when the spec has left the key 
> piece undefined, as far as I see.
> As the spec puts it "This specification does not describe how such a port is 
> made available to RP web pages, as this is (for now) implementation and 
> browser dependent. "

Um, that's fairly standard for specs.

The spec defines the interface, as well as the observable behaviours
of that interface. How that interface is implemented is up to the UA.

For example, Chrome "implements" the interface by allowing extensions
to inject JS into pages, and allowing said JS to communicate back to
the extension ( see https://developer.chrome.com/extensions/messaging
). A future, 'native' implementation in Chrome could, rather than
using extension, directly expose the IDL via the navigator interface,
which then exposes a JS MessagePort that fulfills the contract.

The text you cite is by no means proof of an 'incomplete' spec -
rather, it's standard spec sauce, the same way that, say, WebGL
doesn't say "You must use NVidia driver 3.0 or later, and only on
Intel machines" - it says "This is the API of WebGL - you can
implement it however you wish, so long as you abide by this contract"
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship: FIDO U2F API

2015-12-02 Thread smaug

On 12/02/2015 03:23 AM, Richard Barnes wrote:

Proposed: To implement the high-level U2F API described in the FIDO JS API
specification, with support for the USB HID token interface.

As I said in the other email,
I don't understand how this could be implemented when the spec has left the key
piece undefined, as far as I see.
As the spec puts it "This specification does not describe how such a port is made available to RP web pages, as this is (for now) implementation and
browser dependent. "

Please send comments on this proposal to the list no later than Monday,
December 14, 2015.

Personally, I have some reservations about implementing this, but I still
think it’s worth doing, given the clear need for something to augment
passwords.

Thanks,
--Richard

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

Re: Intent to implement and ship: FIDO U2F API

2015-12-02 Thread Frederic Martin

>As I said in the other email, 
>I don't understand how this could be implemented when the spec has left the 
>>key piece undefined, as far as I see. 

You are completely right ! For now, FIDO 2 is currently being written (far far 
far from finished) and can't be implemented, so let's focus on existing 
solutions with existing specifications and existing products (the ones that 
work with google/gmail, github, dropbox and many federated identity portals. 

FIDO U2F specifications are complete for USB/HID devices & desktop browsers. 

Additional information (copy/paste from a previous post of mine above
with small updates):

- FIDO 2.0 will not replace FIDO U2F 
- There will probably not be any kind of FIDO U2F 2.0 inside FIDO 2.0 
- FIDO 2.0 has no goal to be compatible with FIDO U2F (and won't be) 
- FIDO U2F is already here and here to stay. It is a great WORKING 
  solution: a secure second factor for strong web authentication 
  through a simple HID based API. 
- There is already plenty of FIDO U2F related source code available 
  to help people building great solutions (Chromium client source code, 
  Google JS library source code and different Java/PHP/Go/etc. server code) 
- Nearly all FIDO U2F products have really secure architectures 
  (i.e. nearly every products are using secure elements / smart cards 
  components, even if not mandatory, that's great) 
- FIDO U2F over NFC and BLE specifications are currently being 
  finalized, so there will be flexibility to cover mobile platforms. 
- FIDO 2.0 W3c submission have no real details regarding technical 
  implementation because FIDO 2 is only for now a very confusing draft 
  with strange (*cough*) directions, so do not put too many hopes 
  into FIDO 2.0 (that's really not important for now) 

=> So let's focus on U2F :)
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship: FIDO U2F API

2015-12-02 Thread Justin Dolske


On 12/2/15 6:48 AM, Richard Barnes wrote:


My initial intent was to propose implementing [1], then implementing [2]
when it's ready.  After all, there's a lot in common, and as you say, the
W3C version will be much nicer.


This seems like like a strange path to take. Why implement both?

From elsewhere in the thread, it sounds like v.1 is basically importing 
a defacto-standard (?), in which case I'd wonder how realistic is it to 
implement a different version later and actually get sites to switch to it.


I'd also wonder just how far off v.2 is... It is something that's likely 
to get to a final spec in a reasonable timeframe (and should we just 
wait for that), or is it so far off in la-la land that it's not actually 
likely to ever be implemented by anyone? Somewhere in between?


Would the v.1 implementation be deprecated by the v.2 implementation, or 
do both need to be carried around forever?


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

Re: Intent to implement and ship: FIDO U2F API

2015-12-02 Thread Frederic Martin

Le jeudi 3 décembre 2015 01:28:51 UTC+1, Justin Dolske a écrit :
> On 12/2/15 6:48 AM, Richard Barnes wrote:
> 
> > My initial intent was to propose implementing [1], then implementing [2]
> > when it's ready.  After all, there's a lot in common, and as you say, >the 
> > W3C version will be much nicer.
> 
> This seems like like a strange path to take. Why implement both?

(already discussed but let's summarize)

There are plenty of existing U2F source code, online services and hardware 
products already available for U2F, unluckily only support by Chrome for now. 
U2F specifications are finalized. Nobody knows when FIDO2 will be ready. FIDO2 
is a different approach and will not be compatible with U2F. It doesn't mean 
FIDO U2F support will be dropped (they can completely coexist). U2F reaches its 
goal as a great secure simple second factor. Please read specifications, it is 
nice and simple. It works. Great. Already.

>  From elsewhere in the thread, it sounds like v.1 is basically importing 
> a defacto-standard (?), in which case I'd wonder how realistic is it to 
> implement a different version later and actually get sites to switch to >it.
> 
> I'd also wonder just how far off v.2 is... It is something that's likely 
> to get to a final spec in a reasonable timeframe (and should we just 
> wait for that), or is it so far off in la-la land that it's not actually 
> likely to ever be implemented by anyone? Somewhere in between?
> 
> Would the v.1 implementation be deprecated by the v.2 implementation, or 
> do both need to be carried around forever?

So nobody knows when it will be ready. It will, for sure. That's all. It won't 
make U2F deprecated. U2F use case is not even cover by FIDO2. FIDO U2F and 
FIDO2 can nicely coexist. Let's not wait please and deal with existing products 
and services. :)
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship: FIDO U2F APIU

2015-12-02 Thread Boris Zbarsky


On 12/2/15 5:42 PM, Ryan Sleevi wrote:

On Wednesday, December 2, 2015 at 1:17:46 PM UTC-8, smaug wrote:

I don't understand how 1) could be implemented when the spec has left the key 
piece undefined, as far as I see.
As the spec puts it "This specification does not describe how such a port is 
made available to RP web pages, as this is (for now) implementation and
browser dependent. "


Um, that's fairly standard for specs.


It's not standard for web specs, in the sense that web specs aim to have 
interoperable behavior in terms of what's exposed to pages.


That means not just defining how objects behave once you have your hands 
on them but also defining how to get your hands on them.  The 
alternative is things like when pages were creating XMLHttpRequest 
objects via constructors in some browsers and ActiveX gunk in others: no 
one is happy with that.


Now I know you know all this, so I'm assuming you simply misunderstood 
Olli's objection... but if that's not what's going on, I would like to 
understand what your line of reasoning is here.



The spec defines the interface, as well as the observable behaviours
of that interface. How that interface is implemented is up to the UA.


The "interface" for a typical web spec includes "how do I, as a web 
author, get the objects this spec is defining".



For example, Chrome "implements" the interface by allowing extensions
to inject JS into pages, and allowing said JS to communicate back to
the extension ( see https://developer.chrome.com/extensions/messaging
). A future, 'native' implementation in Chrome could, rather than
using extension, directly expose the IDL via the navigator interface,
which then exposes a JS MessagePort that fulfills the contract.


Here's my question.  From the point of view of a web author, do these 
look like the same interface?  That is, are injections adding members to 
navigator?



The text you cite is by no means proof of an 'incomplete' spec


It sure sounds like it is to me.


rather, it's standard spec sauce, the same way that, say, WebGL
doesn't say "You must use NVidia driver 3.0 or later, and only on
Intel machines" - it says "This is the API of WebGL - you can
implement it however you wish, so long as you abide by this contract"


The API of WebGL also says that the way you get hold of a 
WebGLRenderingContext is via a getContext() call on an 
HTMLCanvasElement, with certain arguments.  Without that part, the WebGL 
spec would in fact be "incomplete".


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

Re: Intent to implement and ship: FIDO U2F API

2015-12-02 Thread Frederic Martin

Le mercredi 2 décembre 2015 23:43:00 UTC+1, Ryan Sleevi a écrit :
> On Wednesday, December 2, 2015 at 1:17:46 PM UTC-8, smaug wrote:
> > I don't understand how 1) could be implemented when the spec has left the 
> > key piece undefined, as far as I see.
> > As the spec puts it "This specification does not describe how such a port 
> > is made available to RP web pages, as this is (for now) implementation and 
> > browser dependent. "
> 
> Um, that's fairly standard for specs.
> 
> The spec defines the interface, as well as the observable behaviours
> of that interface. How that interface is implemented is up to the UA.
> 
> For example, Chrome "implements" the interface by allowing extensions
> to inject JS into pages, and allowing said JS to communicate back to
> the extension ( see https://developer.chrome.com/extensions/messaging
> ). A future, 'native' implementation in Chrome could, rather than
> using extension, directly expose the IDL via the navigator interface,
> which then exposes a JS MessagePort that fulfills the contract.
> 
> The text you cite is by no means proof of an 'incomplete' spec -
> rather, it's standard spec sauce, the same way that, say, WebGL
> doesn't say "You must use NVidia driver 3.0 or later, and only on
> Intel machines" - it says "This is the API of WebGL - you can
> implement it however you wish, so long as you abide by this contract"

Sorry, but I don't understand why you are denying the evidence, anyone 
at Fido alliance will confirm that even non-public FIDO 2 drafts are far
far far from finished. Regarding the glimpse that was published in W3c website, 
this is even more flagrant.

Are you following the Fido Alliance on going work? there are tons of 
things that are currently discussed without even an agenda. And I don't even 
speak about the authenticator side, there is no information/specifications at 
all for that.

Please focus on existing full specifications with existing services and 
products : FIDO U2F.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship: FIDO U2F API

2015-12-02 Thread Ryan Sleevi

On Wednesday, December 2, 2015 at 3:08:44 PM UTC-8, Frederic Martin wrote:
> Sorry, but I don't understand why you are denying the evidence, anyone 
> at Fido alliance will confirm that even non-public FIDO 2 drafts are far
> far far from finished. Regarding the glimpse that was published in W3c 
> website, this is even more flagrant.

So, apologies that I misunderstood your bone of contention with the 2.0 part, 
which Boris clarified.

That said, I think we're in violent agreement that the specs are far, far, far 
from finished - and I'm unclear whether we're in agreement that one is under 
active development, while the other is a technological dead end which, through 
a series of unfortunate events, happened to have been launched beyond the scope 
of a few limited sites.

> Are you following the Fido Alliance on going work? there are tons of 
> things that are currently discussed without even an agenda. And I don't even 
> speak about the authenticator side, there is no information/specifications at 
> all for that.

To an extent my sanity permits, yes.

> Please focus on existing full specifications with existing services and 
> products : FIDO U2F.

The problem is that U2F represents a dead-end of sorts. It, along with FIDO 
UAF, tried to provision high-level APIs for two very disjoint use cases. The 
FIDO 2.0 work tries to embrace the extensiblewebmanifesto portion by providing 
the common low-level primitives shared by UAF/U2F, so that appropriate high 
level APIs can be built atop the low-level communication mechanism.

Yes, there are sites that support and use the U2F high-level API, and yes, 
unfortunately Chrome ships a built-in extension that is automatically granted 
sufficient privileges to polyfill that high-level API atop our (extension-only) 
USB HID API, allowing the extension to inject into sites and transparently add 
support 'as if' it was implemented through the standard Chrome feature process, 
but unfortunately bypassing it, and thus suffering many of the known issues 
with implementing and shipping specs before consensus - such as ossification 
due to premature deployment.

However, the U2F API inherently is something that will be replaced in the 
future - it will presumably be supplanted with the FIDO 2.0 API low-level 
primitives, for which there can then be 'many' high-level polyfill APIs 
implemented through support libraries independent of the UA, perhaps 'some' of 
which will be standardized, as such extensiblewebmanifesto-y things go.

This was captured by threads like 
https://groups.google.com/a/fidoalliance.org/d/msg/fido-dev/zvS9BM8HXLQ/4GmJaSTTSN4J
 and such.

I think we'd also all agree that supporting a "U2F 1.0 API, U2F 1.1 API, UAF 
1.0 API, and FIDO 2.0 API" all within a browser is also... non-ideal. That's 
why I was trying to get clarification about both the short- and long-term 
commitments of the Firefox folks, while we try to get things clarified on the 
Chrome side.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship: FIDO U2F API

2015-12-02 Thread smaug


On 12/02/2015 07:25 AM, ryan.sle...@gmail.com wrote:

On Tuesday, December 1, 2015 at 6:04:30 PM UTC-8, Jonas Sicking wrote:

Oh well. Bummer.

/ Jonas


If it cheers you up any, the 2.0 API that replaces the U2F API uses promises - 
http://www.w3.org/Submission/2015/SUBM-fido-web-api-20151120/

Richard, it would help if you could clarify - are you proposing that Firefox 
implement the 'old and deprecated' U2F API [1], or the 'fresh and new
and hoping to be standards track' W3C member submission API [2].

I originally wanted to reply with 'good news' that Chrome only shipped this for 
google.com, and only for HTTPS, and that we were committed to the
W3C member submission as the path forward, but as I was working to back up a 
citation to this, I found out that we submarine-launched the API in
Chrome 40 [3], for all HTTP and HTTPS origins, without an Intent to Implement / 
Intent to Ship.

So, speaking solely on my behalf and not that of my employer, sorry that Chrome put Firefox in this 
position of "old and busted" and "new hotness",
with "damned either way" as the result. I'm trying to find out more about this, 
as well as Chrome and Chromium's future commitments regarding this
API.

That said, knowing full well that the FIDO Alliance intends the W3C member 
submission to the path forward, could you provide greater clarity: 1)
What it is you intend to implement? 2) If you intend to implement [1], whether 
or not you'll unship that if/as/when [2] progresses?

I don't understand how 1) could be implemented when the spec has left the key 
piece undefined, as far as I see.
As the spec puts it "This specification does not describe how such a port is made available to RP web pages, as this is (for now) implementation and 
browser dependent. "





[1] 
https://fidoalliance.org/specs/fido-u2f-v1.0-nfc-bt-amendment-20150514/fido-u2f-javascript-api.html
 [2]
http://www.w3.org/Submission/2015/SUBM-fido-web-api-20151120/ [3]
https://chromium.googlesource.com/chromium/src/+/d60fcd7caafa7046da693fe2c3206ab5cf20%5E%21/#F9



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

Re: Intent to implement and ship: FIDO U2F API

2015-12-02 Thread Eric Rescorla

On Wed, Dec 2, 2015 at 1:11 PM, Frederic Martin 
wrote:

> > > There are probably other questions Mozilla Core Team should ask to
> > > themselves :
> > >
> > > - Having a greater/larger HID Support, outside the FIDO U2F scope ?
> > > (This allows web services to communicate with HID devices - i.e.
> > > that's how some cryptocurrencies hardware wallets are using HID
> > > Chrome interface)
> > >
> >
> > Are you thinking of something like WebUSB?
> > (https://reillyeon.github.io/webusb/)? This is something we've looked at
> > a bit but we're still trying to wrap our heads around the security
> > implications.
>
> No. I am thinking about something like:
> https://developer.chrome.com/apps/hid
> but that's outside the pure FIDO U2F scope: it is a reminder that Chrome
> already allows wep pages/JS to communicate with HID non-U2F device and
> that Mozilla will have to chose on their side if the HID API will be
> restricted to U2F usage or not.


I believe the plan is to have that be the case for now.


>
> > - Have TLS Channel ID Binding support. (Oh, this is really important)
> > > When you'll check FIDO U2F specifications, you'll see that TLS Channel
> > > ID Binding is an important part of the security against attacks like
> > > SSL Proxy and similar MITM attacks. This part is not mandatory. But
> > > Google servers are using this and Chrome supports it. So... please
> > > REALLY consider implementing it: it will bring higher security and
> > > probably will give a chance too in the future to be accepted as a
> > > supported browser on Google servers (I am not from Google so I can't
> > > speak on their behalf but this should be a rational requirements
> there).
> > > This is the only way to provide a full anti-phishing solution.
> > >
> >
> > My understanding is that Channel ID is being superseded by token binding
> > (https://datatracker.ietf.org/wg/tokbind/charter/), so if we do
> > something in this area, it's more likely we would do token binding
> > than channel ID,
> > I expect.
>
> Hi, I don't think this is exactly something that you can freely chose...
> As you read FIDO U2F specifications, you'll see that added security is
> provided by TLS channel binding.
>
> Search "Channel Binding" inside
>
> https://fidoalliance.org/specs/fido-u2f-v1.0-nfc-bt-amendment-20150514/fido-glossary.html
> and again here
>
> https://fidoalliance.org/specs/fido-u2f-v1.0-nfc-bt-amendment-20150514/fido-security-ref.html


I know what Channel Bindings are, but they're different from Channel ID
(though Channel ID *uses* Channel Bindings). But as I said, Channel ID
is Google-specific sauce. The IETF token binding working group
(https://datatracker.ietf.org/wg/tokbind/charter/) is standardizing the
next generation of this technology. Given that, my instinct is to wait
for the standard.

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

Re: Intent to implement and ship: FIDO U2F API

2015-12-02 Thread Frederic Martin

> That said, I think we're in violent agreement that the specs are far, far, 
> far from finished - and I'm unclear whether we're in agreement that one is 
> under active development, while the other is a technological dead end which, 
> through a series of unfortunate events, happened to have been launched beyond 
> the scope of a few limited sites.

Oh believe me, U2F is not ready to die. 
U2F is a great second factor solution, whatever ongoing FIDO 2 discussion.

> > Are you following the Fido Alliance on going work? 
> 
> To an extent my sanity permits, yes.
> 
> > Please focus on existing full specifications with existing services and 
> > products : FIDO U2F.
> 
> The problem is that U2F represents a dead-end of sorts. It, along with FIDO 
> UAF, tried to provision high-level APIs for two very disjoint use cases. The 
> FIDO 2.0 work tries to embrace the extensiblewebmanifesto portion by 
> providing the common low-level primitives shared by UAF/U2F, so that 
> appropriate high level APIs can be built atop the low-level communication 
> mechanism.

Perhaps when FIDO 2 will be reality, and it is far from being a reality, this 
discussion will make more sens. Why discouraging existing services and products 
support ? Perhaps FIDO U2F won't evolve a lot but it serves a purpose and 
reached its goal. FIDO 2 is also a very disjoint branch from UAF and U2F, and 
it seems to follow a strange way by promoting smartphone based application, 
marginalizing again the use of secure elements, unknown pairing, and so on... 
There are now many existing FIDO U2F solutions that are pushing for FIDO based 
solutions. Let's welcome Mozilla inside the Alliance and let Mozilla deal with 
existing actors, please... (insert a begging smiley here).


> Yes, there are sites that support and use the U2F high-level API, and yes, 
> unfortunately Chrome ships a built-in extension that is automatically granted 
> sufficient privileges to polyfill that high-level API atop our 
> (extension-only) USB HID API, allowing the extension to inject into sites and 
> transparently add support 'as if' it was implemented through the standard 
> Chrome feature process, but unfortunately bypassing it, and thus suffering 
> many of the known issues with implementing and shipping specs before 
> consensus - such as ossification due to premature deployment.
> 
> However, the U2F API inherently is something that will be replaced in the 
> future - it will presumably be supplanted with the FIDO 2.0 API low-level 
> primitives, for which there can then be 'many' high-level polyfill APIs 
> implemented through support libraries independent of the UA, perhaps 'some' 
> of which will be standardized, as such extensiblewebmanifesto-y things go.

Wow, I won't follow you on this path :) If Google had strange ways to reach the 
goal, now it is working, and no, FIDO2 will not replace U2F. The second factor 
(authent after user+pass) is not even a part of FIDO 2. And compatibility is 
not even discussed. So if Mozilla waits (for an unknown period of time) and 
implements FIDO 2 (that will have its problems too...), this won't help people 
with their FIDO U2F based products and services.

> This was captured by threads like 
> https://groups.google.com/a/fidoalliance.org/d/msg/fido-dev/zvS9BM8HXLQ/4GmJaSTTSN4J
>  and such.

I know, I am the same Fred there :)

> I think we'd also all agree that supporting a "U2F 1.0 API, U2F 1.1 API, UAF 
> 1.0 API, and FIDO 2.0 API" all within a browser is also... non-ideal. That's 
> why I was trying to get clarification about both the short- and long-term 
> commitments of the Firefox folks, while we try to get things clarified on the 
> Chrome side.

Thanx for all the information, I hope you'll understand that we just want to 
enjoy the Mozilla announcement to support FIDO, please let them cover U2F. I 
don't see any kind of problem for them to cover FIDO 2 later when available and 
even support them side by side.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to implement and ship: FIDO U2F API

2015-12-01 Thread Richard Barnes

The FIDO Alliance has been developing standards for hardware-based
authentication of users by websites [1].  Their work is getting significant
traction, so the Mozilla Foundation has decided to join the FIDO Alliance.
Work has begun in the W3C to create open standards using FIDO as a starting
point. We are proposing to implement the FIDO U2F API in Firefox in its
current form and then track the evolving W3C standard.

Background: The FIDO Alliance has been developing a standard for
hardware-based user authentication known as “Universal Two-Factor” or U2F
[2].  This standard allows a website to verify that a user is in possession
of a specific device by having the device sign a challenge with a private
key that is held on the hardware device.  The browser’s role is mainly (1)
to route messages between the website and the token, and (2) to add the
origin of the website to the message signed by the token (so that the
signature is bound to the site).

Several major websites now support U2F for authentication, including Google
[3], Dropbox [4], and Github [5].  Axel Nennker has filed a Bugzilla bug
for U2F support in Gecko [6].  The W3C has  begun the process of forming a
“WebAuthentication” working group that will work on a standard for enhanced
authentication using FIDO as a starting point [7].

Proposed: To implement the high-level U2F API described in the FIDO JS API
specification, with support for the USB HID token interface.

Please send comments on this proposal to the list no later than Monday,
December 14, 2015.

-

Personally, I have some reservations about implementing this, but I still
think it’s worth doing, given the clear need for something to augment
passwords.

It’s unfortunate that the initial FIDO standards were developed in a closed
group, but there is good momentum building toward making FIDO more open.  I
have some specific concerns about the U2F API itself, but they’re
relatively minor.  For example, the whole system is highly vertically
integrated, so if we want to change any part of it (e.g., to use a curve
other than P-256 for signatures), we’ll need to build a whole new API.  But
these are issues that can be addressed in the W3C process.

We will continue to work on making standards for secure authentication more
open.  In the meantime, U2F is what’s here now, and there’s demonstrated
developer interest, so it makes sense for us to work on implementing it.

Thanks,
--Richard

[1] https://fidoalliance.org/
[2] https://fidoalliance.org/specifications/download/
[3] https://support.google.com/accounts/answer/6103523?hl=en
[4] https://blogs.dropbox.com/dropbox/2015/08/u2f-security-keys/
[5]
https://github.com/blog/2071-github-supports-universal-2nd-factor-authentication
[6] https://bugzilla.mozilla.org/show_bug.cgi?id=1065729
[7] http://w3c.github.io/websec/web-authentication-charter
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship: FIDO U2F API

2015-12-01 Thread Jonas Sicking

Any chance that the API can be made a little more JS friendly? First
thing that stands out is the use of success/error callbacks rather
than the use of Promises.

Also the use of numeric codes, rather than string values, is a pattern
that the web has generally moved away from.

/ Jonas

On Tue, Dec 1, 2015 at 5:23 PM, Richard Barnes  wrote:
> The FIDO Alliance has been developing standards for hardware-based
> authentication of users by websites [1].  Their work is getting significant
> traction, so the Mozilla Foundation has decided to join the FIDO Alliance.
> Work has begun in the W3C to create open standards using FIDO as a starting
> point. We are proposing to implement the FIDO U2F API in Firefox in its
> current form and then track the evolving W3C standard.
>
> Background: The FIDO Alliance has been developing a standard for
> hardware-based user authentication known as “Universal Two-Factor” or U2F
> [2].  This standard allows a website to verify that a user is in possession
> of a specific device by having the device sign a challenge with a private
> key that is held on the hardware device.  The browser’s role is mainly (1)
> to route messages between the website and the token, and (2) to add the
> origin of the website to the message signed by the token (so that the
> signature is bound to the site).
>
> Several major websites now support U2F for authentication, including Google
> [3], Dropbox [4], and Github [5].  Axel Nennker has filed a Bugzilla bug
> for U2F support in Gecko [6].  The W3C has  begun the process of forming a
> “WebAuthentication” working group that will work on a standard for enhanced
> authentication using FIDO as a starting point [7].
>
> Proposed: To implement the high-level U2F API described in the FIDO JS API
> specification, with support for the USB HID token interface.
>
> Please send comments on this proposal to the list no later than Monday,
> December 14, 2015.
>
> -
>
> Personally, I have some reservations about implementing this, but I still
> think it’s worth doing, given the clear need for something to augment
> passwords.
>
> It’s unfortunate that the initial FIDO standards were developed in a closed
> group, but there is good momentum building toward making FIDO more open.  I
> have some specific concerns about the U2F API itself, but they’re
> relatively minor.  For example, the whole system is highly vertically
> integrated, so if we want to change any part of it (e.g., to use a curve
> other than P-256 for signatures), we’ll need to build a whole new API.  But
> these are issues that can be addressed in the W3C process.
>
> We will continue to work on making standards for secure authentication more
> open.  In the meantime, U2F is what’s here now, and there’s demonstrated
> developer interest, so it makes sense for us to work on implementing it.
>
> Thanks,
> --Richard
>
> [1] https://fidoalliance.org/
> [2] https://fidoalliance.org/specifications/download/
> [3] https://support.google.com/accounts/answer/6103523?hl=en
> [4] https://blogs.dropbox.com/dropbox/2015/08/u2f-security-keys/
> [5]
> https://github.com/blog/2071-github-supports-universal-2nd-factor-authentication
> [6] https://bugzilla.mozilla.org/show_bug.cgi?id=1065729
> [7] http://w3c.github.io/websec/web-authentication-charter
> ___
> 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 implement and ship: FIDO U2F API

2015-12-01 Thread Jonas Sicking

Oh well. Bummer.

/ Jonas

On Tue, Dec 1, 2015 at 5:36 PM, Richard Barnes  wrote:
> It's my understanding that U2F qua U2F is considered pretty much baked by
> the developer community, and there's already code written to it.  But these
> concerns will be great for the W3C group and the successor API.  I've got a
> similar list started related to crypto and future-proofing.
>
>
> On Tue, Dec 1, 2015 at 8:29 PM, Jonas Sicking  wrote:
>>
>> Any chance that the API can be made a little more JS friendly? First
>> thing that stands out is the use of success/error callbacks rather
>> than the use of Promises.
>>
>> Also the use of numeric codes, rather than string values, is a pattern
>> that the web has generally moved away from.
>>
>> / Jonas
>>
>> On Tue, Dec 1, 2015 at 5:23 PM, Richard Barnes 
>> wrote:
>> > The FIDO Alliance has been developing standards for hardware-based
>> > authentication of users by websites [1].  Their work is getting
>> > significant
>> > traction, so the Mozilla Foundation has decided to join the FIDO
>> > Alliance.
>> > Work has begun in the W3C to create open standards using FIDO as a
>> > starting
>> > point. We are proposing to implement the FIDO U2F API in Firefox in its
>> > current form and then track the evolving W3C standard.
>> >
>> > Background: The FIDO Alliance has been developing a standard for
>> > hardware-based user authentication known as “Universal Two-Factor” or
>> > U2F
>> > [2].  This standard allows a website to verify that a user is in
>> > possession
>> > of a specific device by having the device sign a challenge with a
>> > private
>> > key that is held on the hardware device.  The browser’s role is mainly
>> > (1)
>> > to route messages between the website and the token, and (2) to add the
>> > origin of the website to the message signed by the token (so that the
>> > signature is bound to the site).
>> >
>> > Several major websites now support U2F for authentication, including
>> > Google
>> > [3], Dropbox [4], and Github [5].  Axel Nennker has filed a Bugzilla bug
>> > for U2F support in Gecko [6].  The W3C has  begun the process of forming
>> > a
>> > “WebAuthentication” working group that will work on a standard for
>> > enhanced
>> > authentication using FIDO as a starting point [7].
>> >
>> > Proposed: To implement the high-level U2F API described in the FIDO JS
>> > API
>> > specification, with support for the USB HID token interface.
>> >
>> > Please send comments on this proposal to the list no later than Monday,
>> > December 14, 2015.
>> >
>> > -
>> >
>> > Personally, I have some reservations about implementing this, but I
>> > still
>> > think it’s worth doing, given the clear need for something to augment
>> > passwords.
>> >
>> > It’s unfortunate that the initial FIDO standards were developed in a
>> > closed
>> > group, but there is good momentum building toward making FIDO more open.
>> > I
>> > have some specific concerns about the U2F API itself, but they’re
>> > relatively minor.  For example, the whole system is highly vertically
>> > integrated, so if we want to change any part of it (e.g., to use a curve
>> > other than P-256 for signatures), we’ll need to build a whole new API.
>> > But
>> > these are issues that can be addressed in the W3C process.
>> >
>> > We will continue to work on making standards for secure authentication
>> > more
>> > open.  In the meantime, U2F is what’s here now, and there’s demonstrated
>> > developer interest, so it makes sense for us to work on implementing it.
>> >
>> > Thanks,
>> > --Richard
>> >
>> > [1] https://fidoalliance.org/
>> > [2] https://fidoalliance.org/specifications/download/
>> > [3] https://support.google.com/accounts/answer/6103523?hl=en
>> > [4] https://blogs.dropbox.com/dropbox/2015/08/u2f-security-keys/
>> > [5]
>> >
>> > https://github.com/blog/2071-github-supports-universal-2nd-factor-authentication
>> > [6] https://bugzilla.mozilla.org/show_bug.cgi?id=1065729
>> > [7] http://w3c.github.io/websec/web-authentication-charter
>> > ___
>> > 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 implement and ship: FIDO U2F API

2015-12-01 Thread Richard Barnes

It's my understanding that U2F qua U2F is considered pretty much baked by
the developer community, and there's already code written to it.  But these
concerns will be great for the W3C group and the successor API.  I've got a
similar list started related to crypto and future-proofing.


On Tue, Dec 1, 2015 at 8:29 PM, Jonas Sicking  wrote:

> Any chance that the API can be made a little more JS friendly? First
> thing that stands out is the use of success/error callbacks rather
> than the use of Promises.
>
> Also the use of numeric codes, rather than string values, is a pattern
> that the web has generally moved away from.
>
> / Jonas
>
> On Tue, Dec 1, 2015 at 5:23 PM, Richard Barnes 
> wrote:
> > The FIDO Alliance has been developing standards for hardware-based
> > authentication of users by websites [1].  Their work is getting
> significant
> > traction, so the Mozilla Foundation has decided to join the FIDO
> Alliance.
> > Work has begun in the W3C to create open standards using FIDO as a
> starting
> > point. We are proposing to implement the FIDO U2F API in Firefox in its
> > current form and then track the evolving W3C standard.
> >
> > Background: The FIDO Alliance has been developing a standard for
> > hardware-based user authentication known as “Universal Two-Factor” or U2F
> > [2].  This standard allows a website to verify that a user is in
> possession
> > of a specific device by having the device sign a challenge with a private
> > key that is held on the hardware device.  The browser’s role is mainly
> (1)
> > to route messages between the website and the token, and (2) to add the
> > origin of the website to the message signed by the token (so that the
> > signature is bound to the site).
> >
> > Several major websites now support U2F for authentication, including
> Google
> > [3], Dropbox [4], and Github [5].  Axel Nennker has filed a Bugzilla bug
> > for U2F support in Gecko [6].  The W3C has  begun the process of forming
> a
> > “WebAuthentication” working group that will work on a standard for
> enhanced
> > authentication using FIDO as a starting point [7].
> >
> > Proposed: To implement the high-level U2F API described in the FIDO JS
> API
> > specification, with support for the USB HID token interface.
> >
> > Please send comments on this proposal to the list no later than Monday,
> > December 14, 2015.
> >
> > -
> >
> > Personally, I have some reservations about implementing this, but I still
> > think it’s worth doing, given the clear need for something to augment
> > passwords.
> >
> > It’s unfortunate that the initial FIDO standards were developed in a
> closed
> > group, but there is good momentum building toward making FIDO more
> open.  I
> > have some specific concerns about the U2F API itself, but they’re
> > relatively minor.  For example, the whole system is highly vertically
> > integrated, so if we want to change any part of it (e.g., to use a curve
> > other than P-256 for signatures), we’ll need to build a whole new API.
> But
> > these are issues that can be addressed in the W3C process.
> >
> > We will continue to work on making standards for secure authentication
> more
> > open.  In the meantime, U2F is what’s here now, and there’s demonstrated
> > developer interest, so it makes sense for us to work on implementing it.
> >
> > Thanks,
> > --Richard
> >
> > [1] https://fidoalliance.org/
> > [2] https://fidoalliance.org/specifications/download/
> > [3] https://support.google.com/accounts/answer/6103523?hl=en
> > [4] https://blogs.dropbox.com/dropbox/2015/08/u2f-security-keys/
> > [5]
> >
> https://github.com/blog/2071-github-supports-universal-2nd-factor-authentication
> > [6] https://bugzilla.mozilla.org/show_bug.cgi?id=1065729
> > [7] http://w3c.github.io/websec/web-authentication-charter
> > ___
> > 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 implement and ship: FIDO U2F API

2015-12-01 Thread ryan . sleevi

On Tuesday, December 1, 2015 at 6:04:30 PM UTC-8, Jonas Sicking wrote:
> Oh well. Bummer.
> 
> / Jonas

If it cheers you up any, the 2.0 API that replaces the U2F API uses promises - 
http://www.w3.org/Submission/2015/SUBM-fido-web-api-20151120/

Richard, it would help if you could clarify - are you proposing that Firefox 
implement the 'old and deprecated' U2F API [1], or the 'fresh and new and 
hoping to be standards track' W3C member submission API [2].

I originally wanted to reply with 'good news' that Chrome only shipped this for 
google.com, and only for HTTPS, and that we were committed to the W3C member 
submission as the path forward, but as I was working to back up a citation to 
this, I found out that we submarine-launched the API in Chrome 40 [3], for all 
HTTP and HTTPS origins, without an Intent to Implement / Intent to Ship.

So, speaking solely on my behalf and not that of my employer, sorry that Chrome 
put Firefox in this position of "old and busted" and "new hotness", with 
"damned either way" as the result. I'm trying to find out more about this, as 
well as Chrome and Chromium's future commitments regarding this API.

That said, knowing full well that the FIDO Alliance intends the W3C member 
submission to the path forward, could you provide greater clarity:
1) What it is you intend to implement?
2) If you intend to implement [1], whether or not you'll unship that if/as/when 
[2] progresses?

[1] 
https://fidoalliance.org/specs/fido-u2f-v1.0-nfc-bt-amendment-20150514/fido-u2f-javascript-api.html
[2] http://www.w3.org/Submission/2015/SUBM-fido-web-api-20151120/
[3] 
https://chromium.googlesource.com/chromium/src/+/d60fcd7caafa7046da693fe2c3206ab5cf20%5E%21/#F9
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship: Performance.translateTime

2015-11-20 Thread Jonas Sicking

On Thu, Nov 19, 2015 at 5:38 PM, Boris Zbarsky  wrote:
>> Though Service Workers do actually have a 'client' object which
>> represent window objects. So we could enable passing those as global
>> to the translate function.
>
> That's a good idea.  Want to raise it with the webperf WG?  Seems like it
> wouldn't be that hard to implement.

I'd be quite happy if someone else would :)

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

Re: Intent to implement and ship: Performance.translateTime

2015-11-19 Thread Jonas Sicking

On Thu, Nov 19, 2015 at 2:48 PM, Boris Zbarsky  wrote:
> On 11/19/15 5:39 PM, Jonas Sicking wrote:
>>
>> This API doesn't seem to work for nested workers (which Blink doesn't
>> implement), does it? Since there's no way in the window to get hold of
>> a reference of a sub-sub-worker.
>
> While true, there is also no way to directly get a message from a
> sub-sub-worker, right?  The only way to get one is via the intermediate
> worker.

You can actually create a MessageChannel and then send one of the
ports to a sub-sub-worker.

Unfortunately the other port can't be used as something that
represents the sub-sub-worker since even after a port has started
getting used, it can be sent around again.

> So you have a window create worker W1, W1 creates W2.  W2 does something,
> posts a message back to W1 with some timestamps.  W1 translates those into
> its timeline and posts message back to the window, which translates into its
> timeline.

Yes, this is possible. It's not great, but it's probably a fine enough solution.

>> It also doesn't seem possible for a worker to convert to the timeline
>> of a parent window, since there's no object representing the parent of
>> a worker.
>
> That's true.  If you want to ship timestamps from a window to a worker,
> there's no convenient way to do that, though you can hack it together like
> so:
>
>   w.postMessage(myTimeStamp - Performance.translateTime(0, w))
>
> It seemed to me when this was being discussed that typically your timestamps
> would flow the other way, but maybe that's a bad assumption?

I suspect having a worker which takes care of coordinating network
traffic to a server is likely to be a good design. Especially having a
sharedworker or serviceworker take care of coordinating the network
traffic if the website expects the user to have multiple tabs open.

Though Service Workers do actually have a 'client' object which
represent window objects. So we could enable passing those as global
to the translate function.

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

Intent to implement and ship: Changes to Worker performance.now() zero time

2015-11-19 Thread Boris Zbarsky

Summary: Currently for a dedicated worker, we set its 0 time for 
performance.now() purposes to the zero time of its parent worker or 
window.  The spec defines a different behavior, now that there is a spec 
for this.  Consumers that rely on the timebases matching right now can 
use translateTime instead.


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

Spec: http://w3c.github.io/hr-time/

Target release: 45

State in other UAs: Chrome plans to implement, unclear on the others. 
One of IE and Safari (can't recall which one) doesn't even implement 
performance.now() in workers.


-Boris

P.S.  I'm not doing the impl work, just the paperwork.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship: Performance.translateTime

2015-11-19 Thread Boris Zbarsky


On 11/19/15 5:39 PM, Jonas Sicking wrote:

This API doesn't seem to work for nested workers (which Blink doesn't
implement), does it? Since there's no way in the window to get hold of
a reference of a sub-sub-worker.


While true, there is also no way to directly get a message from a 
sub-sub-worker, right?  The only way to get one is via the intermediate 
worker.


So you have a window create worker W1, W1 creates W2.  W2 does 
something, posts a message back to W1 with some timestamps.  W1 
translates those into its timeline and posts message back to the window, 
which translates into its timeline.



It also doesn't seem possible for a worker to convert to the timeline
of a parent window, since there's no object representing the parent of
a worker.


That's true.  If you want to ship timestamps from a window to a worker, 
there's no convenient way to do that, though you can hack it together 
like so:



  w.postMessage(myTimeStamp - Performance.translateTime(0, w))

It seemed to me when this was being discussed that typically your 
timestamps would flow the other way, but maybe that's a bad assumption?


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

Intent to implement and ship: text-emphasis

2015-11-17 Thread Xidorn Quan

Summary: It implements emphasis marks which are symbols next to each
character to emphasize a piece of text. It is mainly used in East
Asian documents.

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

Link to standard: https://drafts.csswg.org/css-text-decor-3/#emphasis-marks

Platform coverage: all platforms

Estimated or target release: 45 or 46

Preference behind which this will be implemented:
layout.css.text-emphasis.enabled

DevTools bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1225411

Do other browser engines implement this? WebKit has shipped this
feature unprefixed, and Blink has a leagcy prefixed implementation
inherited from WebKit.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship: window.orientation and orientationchange event

2015-10-20 Thread Jonas Sicking

On Tue, Oct 20, 2015 at 2:49 AM, Mounir Lamouri  wrote:
> Should we add this to the Screen Orientation specification?

I think so yes.

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

Re: Intent to implement and ship: window.orientation and orientationchange event

2015-10-20 Thread Mounir Lamouri

FWIW, this is the usage of window.orientation in the wild recorded by
Chrome:
https://www.chromestatus.com/metrics/feature/timeline/popularity/285

However, Google's internal tools allow me to see the repartition between
platforms and this seen a lot by Chrome Android users.

Should we add this to the Screen Orientation specification?

-- Mounir

On Tue, 20 Oct 2015, at 04:56, Jonas Sicking wrote:
> As someone pushing for the ScreenOrientation API, I agree with this
> intent nonetheless.
> 
> It *might* be worth warning about this property being inconsistent,
> and that it's better for users to use the ScreenOrientation API. But I
> think it's really only worth doing if this is something that other
> browsers agree to do as well.
> 
> / Jonas
> 
> 
> On Mon, Oct 19, 2015 at 8:29 PM, William Chen  wrote:
> > *Summary*: window.orientation returns a value corresponding to the screen
> > orientation. The orientationchange event is fired when the orientation of
> > the viewport is changed. These features are non-standard but have been
> > implemented by other browser vendors on mobile platforms leading to
> > widespread usage on major websites. In order to improve web compatibility,
> > these features are also going to be implemented by Gecko on mobile
> > platforms and we are also working on standardizing the feature. Web authors
> > should avoid these features because the values returned by
> > window.orientation are unreliable as it means different things across
> > different platforms. Instead, authors should use the ScreenOrientation API
> > which offers the more functionality and better specified behavior.
> >
> > *Bug*: https://bugzilla.mozilla.org/show_bug.cgi?id=920734
> >
> > *Link to standard*: https://compat.spec.whatwg.org/#dom-window-orientation
> >
> > *Platform coverage*: Firefox for Android and Firefox OS.
> >
> > *Estimated or target release*: Firefox 44
> >
> > These features are currently implemented by the stock Android browser,
> > Safari on iOS, Chrome for Android and Internet Explorer on Windows Phone.
> > ___
> > 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
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship: window.orientation and orientationchange event

2015-10-20 Thread Mike Taylor


On 10/20/15 6:12 AM, Jonas Sicking wrote:

On Tue, Oct 20, 2015 at 2:49 AM, Mounir Lamouri  wrote:

Should we add this to the Screen Orientation specification?


I think so yes.


I also think so. In my mind the Compat Standard should be transitional 
in nature, rather than something we maintain forever.


Ideally the "standard" equivalents (or logical parent specs or whatever) 
will take in what's specced there as historical APIs or aliases needed 
for compatibility with the de-facto web.


--
Mike Taylor
Web Compat, Mozilla
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship: HTMLElement.innerText

2015-10-19 Thread Ms2ger

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 10/19/2015 06:02 AM, Robert O'Callahan wrote:
> https://bugzilla.mozilla.org/show_bug.cgi?id=264412
> 
> Webkit, Blink and Trident have been shipping this for years without
> a spec and with poor interop. We held off on implementing it since
> you can polyfill a better implementation in JS without much
> difficulty, but we have to implement something for Web compat.
> Because Mozilla, I've drafted a spec here:
> https://github.com/rocallahan/innerText-spec which will hopefully 
> find its way through the W3C WICG, but given the state of the
> world, us shipping this with or without a spec can hardly cause any
> more harm.

Please submit tests to web-platform-tests and create a pull request to
the HTML standard.

Thanks
Ms2ger
-BEGIN PGP SIGNATURE-

iQEcBAEBAgAGBQJWJN+pAAoJEOXgvIL+s8n2z6oH/jhSjQw3ZLxFlFTtFqwcjQzL
3sS8HdLQbZ4t5lueZAujE80HLWaWBS5nEVXkP5F25Va/u6Y6LmeLSqHx/6VnmuY7
kRpXFylJ8WsXEi0H3GBwGBaVjjgc+7y+SJCq9YcBzyGzKiIcvSMdRNSaXt051BSM
vpRTEL5j+wiUTHXSNsOHDVF7xG+rFwHqElQvkWyvye/ENnY45N9iuK3ctozAku3s
PlETA8VGcjQQu3Y1nuejBxrvdQ9uPjb2xO0ZI998MwqIdn4i/BUhfS46zBJzjnwI
469Qyc+h9+PH953X4Ce1jjgRh3eh0YOrwtAyYxcVXIXPAmXeOoaDe/iasPV05O8=
=XBnK
-END PGP SIGNATURE-
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship: HTMLElement.innerText

2015-10-19 Thread Robert O'Callahan

On Tue, Oct 20, 2015 at 1:18 AM, Ms2ger  wrote:

> Please submit tests to web-platform-tests and create a pull request to
> the HTML standard.
>

Will do, after a decent interval to collect feedback. I wrote
web-platform-tests to land with our implementation.

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
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship: window.orientation and orientationchange event

2015-10-19 Thread Jonas Sicking

As someone pushing for the ScreenOrientation API, I agree with this
intent nonetheless.

It *might* be worth warning about this property being inconsistent,
and that it's better for users to use the ScreenOrientation API. But I
think it's really only worth doing if this is something that other
browsers agree to do as well.

/ Jonas


On Mon, Oct 19, 2015 at 8:29 PM, William Chen  wrote:
> *Summary*: window.orientation returns a value corresponding to the screen
> orientation. The orientationchange event is fired when the orientation of
> the viewport is changed. These features are non-standard but have been
> implemented by other browser vendors on mobile platforms leading to
> widespread usage on major websites. In order to improve web compatibility,
> these features are also going to be implemented by Gecko on mobile
> platforms and we are also working on standardizing the feature. Web authors
> should avoid these features because the values returned by
> window.orientation are unreliable as it means different things across
> different platforms. Instead, authors should use the ScreenOrientation API
> which offers the more functionality and better specified behavior.
>
> *Bug*: https://bugzilla.mozilla.org/show_bug.cgi?id=920734
>
> *Link to standard*: https://compat.spec.whatwg.org/#dom-window-orientation
>
> *Platform coverage*: Firefox for Android and Firefox OS.
>
> *Estimated or target release*: Firefox 44
>
> These features are currently implemented by the stock Android browser,
> Safari on iOS, Chrome for Android and Internet Explorer on Windows Phone.
> ___
> 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 implement and ship: webkitMatchesSelector

2015-10-19 Thread Boris Zbarsky


On 10/19/15 12:46 PM, Anne van Kesteren wrote:

On Mon, Oct 19, 2015 at 6:36 PM, Boris Zbarsky  wrote:

Summary: The web more or less depends on one of the prefixed versions of
matchesSelector (being implemented).


I think you mean matches() is being implemented, while the web depends
on a prefixed version of matchesSelector(). matches() and
webkitMatchesSelector() are in the standard.


Er, I have no idea what those parens are doing in what I wrote...  What 
I meant was:


  The web more or less depends on one of the prefixed versions of
  matchesSelector being implemented.

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

Intent to implement and ship: window.orientation and orientationchange event

2015-10-19 Thread William Chen

*Summary*: window.orientation returns a value corresponding to the screen
orientation. The orientationchange event is fired when the orientation of
the viewport is changed. These features are non-standard but have been
implemented by other browser vendors on mobile platforms leading to
widespread usage on major websites. In order to improve web compatibility,
these features are also going to be implemented by Gecko on mobile
platforms and we are also working on standardizing the feature. Web authors
should avoid these features because the values returned by
window.orientation are unreliable as it means different things across
different platforms. Instead, authors should use the ScreenOrientation API
which offers the more functionality and better specified behavior.

*Bug*: https://bugzilla.mozilla.org/show_bug.cgi?id=920734

*Link to standard*: https://compat.spec.whatwg.org/#dom-window-orientation

*Platform coverage*: Firefox for Android and Firefox OS.

*Estimated or target release*: Firefox 44

These features are currently implemented by the stock Android browser,
Safari on iOS, Chrome for Android and Internet Explorer on Windows Phone.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to implement and ship: webkitMatchesSelector

2015-10-19 Thread Boris Zbarsky

Summary: The web more or less depends on one of the prefixed versions of 
matchesSelector (being implemented).  We might as well implement the 
webkit one and drop the moz one.


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

Standard: https://dom.spec.whatwg.org/#dom-element-webkitmatchesselector

Platform coverage: all

Estimated or target release: 44

Preference behind which this will be implemented: No preference, though 
I could add one for now if we want to bake this for a few releases on 
nightly/aurora before shipping it.


Other information:

Q: Do other browser engines implement this?

A: This is implemented by WebKit and Blink, of course.  According to 
https://github.com/whatwg/compat/issues/3 this is also implemented by MS 
Edge.  That means everyone except us implements it, as far as I can tell.


Q: What are the web designer / developer use-cases?

A: No comment.

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

Re: Intent to implement and ship: webkitMatchesSelector

2015-10-19 Thread Anne van Kesteren

On Mon, Oct 19, 2015 at 6:36 PM, Boris Zbarsky  wrote:
> Summary: The web more or less depends on one of the prefixed versions of
> matchesSelector (being implemented).

I think you mean matches() is being implemented, while the web depends
on a prefixed version of matchesSelector(). matches() and
webkitMatchesSelector() are in the standard.

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

Intent to implement and ship: HTMLElement.innerText

2015-10-18 Thread Robert O'Callahan

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

Webkit, Blink and Trident have been shipping this for years without a spec
and with poor interop. We held off on implementing it since you can
polyfill a better implementation in JS without much difficulty, but we have
to implement something for Web compat. Because Mozilla, I've drafted a spec
here: https://github.com/rocallahan/innerText-spec which will hopefully
find its way through the W3C WICG, but given the state of the world, us
shipping this with or without a spec can hardly cause any more harm.

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
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship ::backdrop pseudo-element for Fullscreen API

2015-10-17 Thread Xidorn Quan

On Sun, Oct 18, 2015 at 12:59 AM, Jean-Yves Perrier  wrote:
> On 16/10/2015 02:39, Xidorn Quan wrote:
>
>> Blink has shipped this pseudo-element unprefixed for modal 
>> element (but not yet for fullscreen)
>>
> I have a side question here: do we plan to support ::backdrop for modal
>  in the future, or is it a Blink oddity.

I think the answer is yes. I may start looking into  later.

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

Re: Intent to implement and ship ::backdrop pseudo-element for Fullscreen API

2015-10-17 Thread Jean-Yves Perrier


On 16/10/2015 02:39, Xidorn Quan wrote:


Blink has shipped this pseudo-element unprefixed for modal 
element (but not yet for fullscreen)

I have a side question here: do we plan to support ::backdrop for modal 
 in the future, or is it a Blink oddity.


--
Jean-Yves Perrier
Senior St. Project Manager / Documentation Project / MDN
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to implement and ship ::backdrop pseudo-element for Fullscreen API

2015-10-15 Thread Xidorn Quan

Summary: This pseudo-element is rendered immediately below every
fullscreen element, and covers the other part of the document by
default. This is part of the effort to update our Fullscreen API
implementation to the latest spec. And it is the last non-trivial part
before I'm going to unprefix the Fullscreen API.

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

Link to standard: https://fullscreen.spec.whatwg.org/#::backdrop-pseudo-element

Platform coverage: all

Target release: 44

Preference behind which this will be implemented: none

DevTools bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1209831

Other browser support:
IE has shipped a prefixed version of this pseudo-element for
fullscreen since 11, and Edge shpped it unprefixed:
https://msdn.microsoft.com/en-us/library/dn312072%28v=vs.85%29.aspx
Blink has shipped this pseudo-element unprefixed for modal 
element (but not yet for fullscreen)

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

Re: Intent to Implement and Ship: Permissions API

2015-09-02 Thread Mounir Lamouri

On Wed, 2 Sep 2015, at 03:50, Ehsan Akhgari wrote:
> On 2015-09-01 9:57 PM, Jonas Sicking wrote:
> > But I agree that we should make it clear that we do not intend to
> > implement a request API.
> 
> There is actually a valid use case for a request API.  It has become 
> clear that we need to expose pasting functionality to the Web, and the 
> most natural way of doing so is document.execCommand("paste").  This 
> operation however cannot be exposed without permission because of 
> privacy reasons.  And this is an API where modifying it to add support 
> for requesting permission doesn't make sense.
> 
> AFAIK right now the Chrome team is experimenting with creating a 
> solution for this use case using the request API.  If they manage to 
> come up with a good UX, I think we need to implement it (at least for 
> the "paste" permission) as well.

Correct.

I don't want to derail the thread and it should probably be a question
for later but I don't understand why websites shouldn't be able to
request permissions when Notifications allows it, Persistent Storage
(latest version) allows it and for the other API it is possible to
actually write a polyfill to request permissions (eg.
navigator.geolocation.getCurrentPosition(function(){}) actually request
the permission). We are just making web developers life harder by
requiring them to request permission indirectly.

There are other reasons why request() would benefit the platform. For
example, being able to request permission for a feature that is used in
some kind of Workers (where permissions can't be requested). Though,
again, I don't want to derail the thread.

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

Re: Intent to Implement and Ship: Permissions API

2015-09-01 Thread Jonas Sicking

On Mon, Aug 24, 2015 at 11:57 PM, Anne van Kesteren  wrote:
> On Sat, Aug 22, 2015 at 5:03 AM, Birunthan Mohanathas
>  wrote:
>> Summary: The Permissions API allows a web application to be aware of
>> the status of a given permission, to know whether it is granted,
>> denied or if the user will be asked whether the permission should be
>> granted.
>
> I'm not a big fan of this API.
>
> 1) It doesn't map well to what browsers do internally. Rather than
> simple strings it uses some kind of convoluted dictionary design.

I agree that this is somewhat unfortunate. But in practice it'll mean
that the syntax will be

navigator.permissions.query({ name: "foo" })
rather than
navigator.permissions.query("foo")

which I think in practice is not that big of a problem.

> 2) It would be better to simply expose the permission status of a
> particular feature near a particular feature. If you want to know
> whether geolocation is already granted you should just be able to call
> navigator.geolocation.permission() or some such.

I'm not convinced of this argument. I think this runs the risk of each
API having subtle differences in the querying which IMO is even worse.

Most importantly, I think this API fills a need long asked for by
developers. I.e. while geolocation and similar APIs have taken their
sweet time solving this problem, this API solves the problem here and
now. That's much more valuable than arguing over the exact syntax.

> 3) It seems the API is evolving in ways to also request permission
> without then directly using that permission. It's not clear that is a
> good idea.

I don't see that this risk is higher with a dedicated API compared to
a per-API solution.

But I agree that we should make it clear that we do not intend to
implement a request API.

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

Re: Intent to Implement and Ship: Permissions API

2015-09-01 Thread Ehsan Akhgari


On 2015-09-01 9:57 PM, Jonas Sicking wrote:

But I agree that we should make it clear that we do not intend to
implement a request API.


There is actually a valid use case for a request API.  It has become 
clear that we need to expose pasting functionality to the Web, and the 
most natural way of doing so is document.execCommand("paste").  This 
operation however cannot be exposed without permission because of 
privacy reasons.  And this is an API where modifying it to add support 
for requesting permission doesn't make sense.


AFAIK right now the Chrome team is experimenting with creating a 
solution for this use case using the request API.  If they manage to 
come up with a good UX, I think we need to implement it (at least for 
the "paste" permission) as well.


Cheers,
Ehsan

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

Re: Intent to implement and ship

2015-08-26 Thread Ehsan Akhgari


On 2015-08-26 10:08 AM, Adam Roach wrote:

On 8/26/15 08:36, Ehsan Akhgari wrote:

Have you considered the implications of making the alias falsey in
conditions, similar to document.all?


The issue with doing so is that we see code in the wild that looks like
this:

|var NativeRTCPeerConnection = (window.webkitRTCPeerConnection || 
||window.mozRTCPeerConnection);|

And a falsey value would simply make things not work.

For all the cases I can think of (at least, in short order), making the
alias falsey breaks as many things as simply removing it.


That's fair.

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

Re: Intent to implement and ship

2015-08-26 Thread Ehsan Akhgari


On 2015-08-25 5:45 PM, Martin Thomson wrote:

Maybe some day we can remove the aliases by just backing out the patch
that creates prefixed aliases, but that seems unlikely in the short
term [1][2].


Do the aliases only work when you call them or can the webpage also detect
them?  IOW, what would code like below do?

if (window.mozRTCPeerConnection)
   foo();
else if (window.RTCPeerConnection)
   bar();


The following code would call foo().  In the patch that I have,
mozRTCPeerConnection looks exactly like RTCPeerConnection.  That means
that window.mozRTCPeerConnection is present, can be instantiated, can
be tested with instanceof, and can be passed to any functions that
accept RTCPeerConnection (there aren't any that I can think of there).

The only difference I'm aware of is that constructing the prefixed
version drops a polite warning (using document-WarnOnceAbout()) into
the console.


Hmm, I see.  Have you considered the implications of making the alias 
falsey in conditions, similar to document.all?  Without doing that, we 
would never know if the bar() path in the above example will break 
content when we remove the alias.


Also, I think it's probably a good idea to add a use counter for the 
aliased name.

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

Re: Intent to implement and ship

2015-08-26 Thread Adam Roach


On 8/26/15 08:36, Ehsan Akhgari wrote:
Have you considered the implications of making the alias falsey in 
conditions, similar to document.all?


The issue with doing so is that we see code in the wild that looks like 
this:


|var NativeRTCPeerConnection = (window.webkitRTCPeerConnection || 
||window.mozRTCPeerConnection);|

And a falsey value would simply make things not work.

For all the cases I can think of (at least, in short order), making the 
alias falsey breaks as many things as simply removing it.


--
Adam Roach
Principal Platform Engineer
a...@mozilla.com
+1 650 903 0800 x863
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship

2015-08-26 Thread Ms2ger

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 08/26/2015 03:36 PM, Ehsan Akhgari wrote:
 Hmm, I see.  Have you considered the implications of making the
 alias falsey in conditions, similar to document.all?

No. No. Nononononono.

Ms2ger
-BEGIN PGP SIGNATURE-

iQEcBAEBAgAGBQJV3dq3AAoJEOXgvIL+s8n2LvwIAIgP8Sw0LUU7ietAmwMPzQGU
QykxqEWJr7Y/O+rSU2FmmXzeZWzBRtlh67F5V6yGPPgdljXEtq2pbQjhN3GCM1M/
k7ix7exbJVypy5Xi3NlXIxTaT0leCBImKhZGvkkRfiNap8meWglbFqEY228rNa8M
hw9o5tRvjuhX4INU06ihlvqt/sCJqhyyy5o/ggM2xbuTO0IvksTK4SlGuaK9rxAX
uQDIh+ss7Xv0Cex1izPOOeQkJnyPQtUB7wzf5WSHVXoSh63SDx7MhQ0BFKTOaVVp
PYmW5pndDi4657lzmbzTaW1t418RmvQZ5/RfmKbJJyVAKqnQQ6+/4fGdxE814/M=
=+/Wn
-END PGP SIGNATURE-
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to Implement and Ship: Permissions API

2015-08-25 Thread Martin Thomson

On Tue, Aug 25, 2015 at 2:12 AM, Anne van Kesteren ann...@annevk.nl wrote:
 3) It seems the API is evolving in ways to also request permission
 without then directly using that permission. It's not clear that is a
 good idea.

 This is something that is already doable. If a webpage calls
 navigator.geolocation.getCurrentPosition(), it doesn't need to do
 anything with the position (this can apply to roughly any API). The
 Notififcations API has an explicit call for requesting too.

 The Notifications API is a special case as is noted in its
 specification. It's one of the few cases where we decided this was
 acceptable.

On this point, I agree with Anne.  Notifications doesn't get the
option of an in-context request, and what we have there is the best we
could do at the time.  It is possible that we could do better; I've
not given up on that just yet.

 Furthermore,
 allowing requests will open some new possibilities like requesting a
 'paste' permission which can't be done today.

 If we do indeed need that we could add an API for it. But we should
 first carefully consider if another approach is not better.

I'd like to more directly encourage that as well.  Asking permission
in context has its risks, but out of context has relevancy problems.
I'd rather we carefully examine every instance where we are tempted to
ask users questions, because I don't believe that asking questions
like that is good.

Reducing the friction for adding new ways to bother users with
questions is a drawback of the API.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to Implement and Ship: Permissions API

2015-08-25 Thread Anne van Kesteren

On Sat, Aug 22, 2015 at 5:03 AM, Birunthan Mohanathas
birunt...@mohanathas.com wrote:
 Summary: The Permissions API allows a web application to be aware of
 the status of a given permission, to know whether it is granted,
 denied or if the user will be asked whether the permission should be
 granted.

I'm not a big fan of this API.

1) It doesn't map well to what browsers do internally. Rather than
simple strings it uses some kind of convoluted dictionary design.
2) It would be better to simply expose the permission status of a
particular feature near a particular feature. If you want to know
whether geolocation is already granted you should just be able to call
navigator.geolocation.permission() or some such.
3) It seems the API is evolving in ways to also request permission
without then directly using that permission. It's not clear that is a
good idea.


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

Re: Intent to Implement and Ship: Permissions API

2015-08-25 Thread Anne van Kesteren

On Tue, Aug 25, 2015 at 11:06 AM, Mounir Lamouri mou...@lamouri.fr wrote:
 Browsers internal implementation can change. The API will have to stay
 as it is in the long run. It's better to have an flexible API that would
 allow different implementation strategies.

Even if you have only strings today, there's several ways you could
imagine changing that in the future if the need indeed arises. We've
learned long ago that we shouldn't ship complicated frameworks where a
simple API would do.


 This isn't working for some APIs. For example, MIDI has a very basic
 navigator.requestMIDIAccess(). Should we start having
 navigator.queryMidiAccess()?

Sure, or navigator.midiPermission().


 3) It seems the API is evolving in ways to also request permission
 without then directly using that permission. It's not clear that is a
 good idea.

 This is something that is already doable. If a webpage calls
 navigator.geolocation.getCurrentPosition(), it doesn't need to do
 anything with the position (this can apply to roughly any API). The
 Notififcations API has an explicit call for requesting too.

The Notifications API is a special case as is noted in its
specification. It's one of the few cases where we decided this was
acceptable.


 Furthermore,
 allowing requests will open some new possibilities like requesting a
 'paste' permission which can't be done today.

If we do indeed need that we could add an API for it. But we should
first carefully consider if another approach is not better.


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

Re: Intent to Implement and Ship: Permissions API

2015-08-25 Thread Mounir Lamouri

On Tue, 25 Aug 2015, at 07:57, Anne van Kesteren wrote:
 On Sat, Aug 22, 2015 at 5:03 AM, Birunthan Mohanathas
 birunt...@mohanathas.com wrote:
  Summary: The Permissions API allows a web application to be aware of
  the status of a given permission, to know whether it is granted,
  denied or if the user will be asked whether the permission should be
  granted.
 
 I'm not a big fan of this API.
 
 1) It doesn't map well to what browsers do internally. Rather than
 simple strings it uses some kind of convoluted dictionary design.

Browsers internal implementation can change. The API will have to stay
as it is in the long run. It's better to have an flexible API that would
allow different implementation strategies.

 2) It would be better to simply expose the permission status of a
 particular feature near a particular feature. If you want to know
 whether geolocation is already granted you should just be able to call
 navigator.geolocation.permission() or some such.

This isn't working for some APIs. For example, MIDI has a very basic
navigator.requestMIDIAccess(). Should we start having
navigator.queryMidiAccess()?

 3) It seems the API is evolving in ways to also request permission
 without then directly using that permission. It's not clear that is a
 good idea.

This is something that is already doable. If a webpage calls
navigator.geolocation.getCurrentPosition(), it doesn't need to do
anything with the position (this can apply to roughly any API). The
Notififcations API has an explicit call for requesting too. Furthermore,
allowing requests will open some new possibilities like requesting a
'paste' permission which can't be done today.

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

Intent to implement and ship

2015-08-25 Thread Martin Thomson

WebRTC was shipped with a prefix.

Bug 1155923 moves our codebase to non-prefixed names, but includes a
patch to restore aliases with the prefix.  Thus we will expose
`RTCPeerConnection` and use that ourselves, but permit legacy code to
use `mozRTCPeerConnection`.

Maybe some day we can remove the aliases by just backing out the patch
that creates prefixed aliases, but that seems unlikely in the short
term [1][2].

Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1155923
Link to standard: http://w3c.github.io/webrtc-pc/
Platform coverage: everywhere
Target release: 43
Preference behind which this will be implemented: none
DevTools bug: none

Chrome and Opera ship with a 'webkit' prefix.  I'm not aware of any
shipping implementation of this API in other browsers.

[1] Compatibility on the WebRTC API has been very poor in the past.
I'm not aware of any code that doesn't detect browsers based on the
prefixed names and then does something browser-specific.

[2] However, this situation has been improving rapidly.  In any case,
a less-than perfect interoperability situation is no excuse for using
prefixes.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship

2015-08-25 Thread Martin Thomson

On Tue, Aug 25, 2015 at 2:16 PM, Ehsan Akhgari ehsan.akhg...@gmail.com wrote:
 On 2015-08-25 4:07 PM, Martin Thomson wrote:

 WebRTC was shipped with a prefix.

 Bug 1155923 moves our codebase to non-prefixed names, but includes a
 patch to restore aliases with the prefix.  Thus we will expose
 `RTCPeerConnection` and use that ourselves, but permit legacy code to
 use `mozRTCPeerConnection`.

 Is our RTCPeerConnection and the corresponding spec considered as stable?

Stable enough to use the name, certainly [see
https://tools.ietf.org/html/rfc6648].  But maybe that wasn't your
question...

The core parts of the spec are stable and have been for years.  There
are parts that are still unstable.  I don't expect that to change
appreciably for some time, even though the W3C working group has a
goal for a big 1.0 release.

 Maybe some day we can remove the aliases by just backing out the patch
 that creates prefixed aliases, but that seems unlikely in the short
 term [1][2].

 Do the aliases only work when you call them or can the webpage also detect
 them?  IOW, what would code like below do?

 if (window.mozRTCPeerConnection)
   foo();
 else if (window.RTCPeerConnection)
   bar();

The following code would call foo().  In the patch that I have,
mozRTCPeerConnection looks exactly like RTCPeerConnection.  That means
that window.mozRTCPeerConnection is present, can be instantiated, can
be tested with instanceof, and can be passed to any functions that
accept RTCPeerConnection (there aren't any that I can think of there).

The only difference I'm aware of is that constructing the prefixed
version drops a polite warning (using document-WarnOnceAbout()) into
the console.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship

2015-08-25 Thread Ehsan Akhgari


On 2015-08-25 4:07 PM, Martin Thomson wrote:

WebRTC was shipped with a prefix.

Bug 1155923 moves our codebase to non-prefixed names, but includes a
patch to restore aliases with the prefix.  Thus we will expose
`RTCPeerConnection` and use that ourselves, but permit legacy code to
use `mozRTCPeerConnection`.


Is our RTCPeerConnection and the corresponding spec considered as stable?


Maybe some day we can remove the aliases by just backing out the patch
that creates prefixed aliases, but that seems unlikely in the short
term [1][2].


Do the aliases only work when you call them or can the webpage also 
detect them?  IOW, what would code like below do?


if (window.mozRTCPeerConnection)
  foo();
else if (window.RTCPeerConnection)
  bar();

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

Re: Intent to Implement and Ship: Permissions API

2015-08-24 Thread Ehsan Akhgari


On 2015-08-21 11:03 PM, Birunthan Mohanathas wrote:

Hi,

navigator.permissions.query has been Nightly-only for a few weeks. We
are going to let it ride the trains. Other parts of the spec (such as
Permissions.request) will be implemented when the spec is complete.


Just to double check, do we support geolocation, notifications and 
push?  If yes, SGTM to ship this!


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

Re: Intent to Implement and Ship: Permissions API

2015-08-24 Thread Birunthan Mohanathas

On 24 August 2015 at 09:47, Ehsan Akhgari ehsan.akhg...@gmail.com wrote:
 Just to double check, do we support geolocation, notifications and
 push?

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

Re: Intent to implement and ship: CSS and SVG filters for canvas 2D

2015-08-24 Thread Tantek Çelik

Just to keep this thread moving forward:

On Tue, Jun 16, 2015 at 2:35 AM, Markus Stange msta...@themasta.com wrote:

 On 2015-06-15 8:15 PM, Robert O'Callahan wrote:

 On Tue, Jun 16, 2015 at 11:23 AM, Robert O'Callahan rob...@ocallahan.org
 
 wrote:

 I think we're not quite there yet, but we're very close. There are two
 things I want before we ship:
 -- Get normative spec text up somewhere.
 -- Get a signal from some other browser vendor that they're OK with this
 feature. That no-one objected in WHATWG is a good sign. I've reached out
 to
 a Blnk danvas dev for a slightly stronger signal.


 I got a reply from that Blink dev saying that they want this feature, want
 to implement it soon, and just need spec text.


We're documenting our spec text for CanvasFilters on the Mozilla wiki for
now:

https://wiki.mozilla.org/CanvasFilters

Please feel free to edit with issues / questions inline.

Thanks!

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

Re: Intent to Implement and Ship: Permissions API

2015-08-22 Thread Jonas Sicking

I'm less psyched about Permissions.request, but looking forward to
having .query ship!

Does it also work in workers?

/ Jonas

On Sat, Aug 22, 2015 at 5:03 AM, Birunthan Mohanathas
birunt...@mohanathas.com wrote:
 Hi,

 navigator.permissions.query has been Nightly-only for a few weeks. We
 are going to let it ride the trains. Other parts of the spec (such as
 Permissions.request) will be implemented when the spec is complete.

 Summary: The Permissions API allows a web application to be aware of
 the status of a given permission, to know whether it is granted,
 denied or if the user will be asked whether the permission should be
 granted.

 Use cases: See 
 https://docs.google.com/document/d/12xnZ_8P6rTpcGxBHiDPPCe7AUyCar-ndg8lh2KwMYkM/preview?pli=1#heading=h.yeaa13evs6re

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

 Spec: https://w3c.github.io/permissions/

 Platform coverage: All platforms

 Target release: Firefox 43

 Other vendor implementations: Supported by Chrome (43)

 Cheers,
 Biru
 ___
 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 Implement and Ship: Permissions API

2015-08-22 Thread Birunthan Mohanathas

On 22 August 2015 at 06:24, Jonas Sicking jo...@sicking.cc wrote:
 Does it also work in workers?

Not yet, that was left for bug 1193373.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to Implement and Ship: Permissions API

2015-08-21 Thread Birunthan Mohanathas

Hi,

navigator.permissions.query has been Nightly-only for a few weeks. We
are going to let it ride the trains. Other parts of the spec (such as
Permissions.request) will be implemented when the spec is complete.

Summary: The Permissions API allows a web application to be aware of
the status of a given permission, to know whether it is granted,
denied or if the user will be asked whether the permission should be
granted.

Use cases: See 
https://docs.google.com/document/d/12xnZ_8P6rTpcGxBHiDPPCe7AUyCar-ndg8lh2KwMYkM/preview?pli=1#heading=h.yeaa13evs6re

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

Spec: https://w3c.github.io/permissions/

Platform coverage: All platforms

Target release: Firefox 43

Other vendor implementations: Supported by Chrome (43)

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

Re: Intent to implement and ship: Unprivilaged WEBGL_debug_renderer_info

2015-06-20 Thread Florian Bösch

On Thursday, June 18, 2015 at 9:32:30 PM UTC+2, Chris Peterson wrote:
 It sounds like there are three use cases for WEBGL_debug_renderer_info:
 
 1. Correlating GPU info with bug reports (e.g. YouTube).
 2. Web content workarounds for GPU bugs.
 3. Fingerprinting for user tracking.

There are more usecases to list just a few:

* performance (preset) targeting. Where a guess is made as to which performance 
tier preset is used rather than starting at the lowest tier and using FPS 
ranging (which has its own problems due to FPS capping) and/or user input to 
arrive at a satisfactory setting.
* General GPU statistics (much like user-agent and capability statistics) which 
would be quite eye opening to many WebGL developers.
* Site-specific GPU statistics (because general statistics are rarely 
representative of a given sites visitor base)
* GPU statistics can inform web-developers what devices are representative for 
their visitor-base, so they know what machines to test their code on (rather 
than just the latest and greates GPU that happens to find itself in so many 
WebGL developers machines)
* QA verification of deployments to identify trouble spots, gauge their impact 
and prioritize engineering time to deal with the issue (actual scenario I'm in 
right now)
* Comperative performance targeting: By analyzing the GPU population you see, 
and comparing it to the performance you get for your usecase on your test farm, 
you can come up with a factor to assign to GPUs (using other GPU benchmark 
numbers such as those found on gfxbench.com as well as GPU information such as 
core-count and flops). This factor can quantitatively tell you how fast your 
application will run for how many of your visitors, and you can adjust your 
development accordingly to make sure you're not building features into your 
application that'll make the experience far less enjoyable for the majority of 
your visitors.

 To get #1, some of #2, and none of #3, can we just whitelist 
 WEBGL_debug_renderer_info for youtube.com or a couple of A-tier sites?
I (and many others on the open web) are very much not in favor of features that 
give you an advantage which are denied to the general public and are invite 
only.
 
A couple of other points I'd like to make about GPU strings:

Fingerprinting is hard to objectively quantify (because of the variety of 
privacy protecting features these days such as etag/cookie wiping). However a 
lot of the suspected bits that a GPU string would expose, area already 
contained in in the parameters that WebGL 1 exposes. And WebGL 2 comes with 
twice as many parameters to query. I don't feel a discussion on the dangers of 
fingerprinting is terribly conductive without any quantification. There's also 
a certain element of mootness to discuss the implications of a few more bits to 
fingerprint a user, when users can already be supercookied/fingerprinted 
perfectly without it.

Internet Explorer and Chrome enabled this feature and the world hasn't ended. 
By far and large we're not seeing breakage because somebody used that feature 
inappropriately. WebGL developers do want their content to run on as many 
visitors machines as is possible and we're very conscious of making decisions 
and code that limits that.

In closing, the GPU string helps in a variety of ways and over-simplifying it 
to 2 use-cases does a disservice to that. It is also generally useful to 
anybody who deploys WebGL content, and has the wherewithal/budget to make use 
of that information, and it shouldn't be a browsers place to tell who may or 
who may not.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

< 1 2 3 4 5 6 7 >

401 - 500 of 676 matches

Mail list logo