Re: Intent to implement and ship: Web Authentication

[Anders Rundgren]

On Wednesday, November 30, 2016 at 5:42:30 PM UTC+1, Anders Rundgren wrote:
> It is a pity that external tokens have become the
> focus when the majority will rather rely on embedded
> security solutions which nowadays is a standard feature
> in Android and Windows platforms.

Slight clarification to the above: The IoT folks pretty much build 100% on 
embedded security with car-keys as an obvious exception.

On mobile I would say that over 99% of all existing security solutions based on 
cryptographic keys are relying on embedded (or "App level") keys with Apple Pay 
as the most advanced example.

That is, the token vendors and security folks do not represent the actual 
market comprising of end-users and service providers.

Maybe this is a project primarily targeting the desktop?
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: W3C Proposed Recommendation: Webmention

[Tantek Çelik]

Thanks very much for the detailed comments Joe.

tl;dr  We have to wrap this up tonight (W3C vote deadline) and I'm
pretty sure I've captured the suggestions you've made (greatly
appreciated) with public github issues (which hopefully you've
received notifications thereof).

public github issues filed for specifics, to which anyone is invited
to follow-up, even beyond tonight's AC vote submission deadline:
* https://github.com/w3c/webmention/issues/75
* https://github.com/w3c/webmention/issues/76
* https://github.com/w3c/webmention/issues/84

We can submit our vote to W3C approving the Webmention PR and asking
for these changes.

Details inline below:


On Fri, Nov 4, 2016 at 9:56 AM, Joe Hildebrand  wrote:
>> On Nov 4, 2016, at 9:29 AM, Tantek Çelik  wrote:
>>
>>> There should be some mention of the prior art in this space.
>>
>> Why in the spec? (honestly interested to know what you think should be
>> in a spec without making it more wordy as Martin pointed out)
>
> Because there has been a lot of security work done on the prior protocols, 
> particularly in terms of implementation detail in spam prevention.  It's also 
> just good karma to call out the giant upon whose shoulders you are standing.  
> Informative links from the in the document will be nice decades from now when 
> nobody remembers that those other protocols once existed.
>
>>> Pingbacks and trackbacks at least.
>>
>> https://indieweb.org/Webmention-faq#Why_webmention_instead_of_pingback
>
> Agree that this is much simpler than either.  That likely makes it easier for 
> spammers and other attackers to abuse.

Agreed about the explicit mention of Pingback in the spec with the
reasoning you gave, issue filed:

https://github.com/w3c/webmention/issues/76


>>> Section 4.5 "Limit access to protected resources" points out that this 
>>> protocol is an attractive nuisance.  Anyone who deploys it is likely to 
>>> make their infrastructure more insecure by mistake.
>>
>> Could you expand on this? How? Definitely interested in any and all
>> security concerns.
>
> Nobody is going to remember to sandbox the network connection of the process 
> that is checking the targets.  I send you a webmention whose target is 
> "https://intranet/;, your process requests that URL, and you post a synopsis 
> of what you found as a comment on the blog entry I put in the source.  Yes, 
> there are protections you can put in place for that, but I can't think of any 
> that can be coded generically into a piece of open source software that 
> doesn't open up your internal resources by default.
>
> Even requiring CORS (with the origin as "something interesting", like a 
> constant) on the target would be a step toward making this better.

Explicitly mentioning using CORS for this is quite sensible.

Issue filed: https://github.com/w3c/webmention/issues/84


>>> If there's a good reason to publish this that isn't obvious, I might be 
>>> more excited about it.
>>
>> It's interoperably implemented across double-digit implementations,
>> and deployed an interoperably in use across tens of thousands of
>> websites.
>
> That's a good enough reason.

Thanks much, and thanks again for your review!

And welcome on board at Mozilla as well!

Tantek

P.S. And from previously - to fix the JSON reference:
https://github.com/w3c/webmention/issues/75
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: autoland cleanup

[Gregory Szorc]

On Wed, Nov 30, 2016 at 1:24 PM, Karl Tomlinson  wrote:

> Gregory Szorc writes:
>
> > On Wed, Nov 30, 2016 at 12:40 PM, Karl Tomlinson 
> wrote:
> >> When history is rewritten, is there a way to view the original
> >> history through the web interface, so that autoland tinderbox
> >> builds can be used to find regression ranges?
> >
> > No. Rewritten changesets should result in "replacement" automation
> results.
> > So there should be no loss of automation coverage. So there should be no
> > major impact to things like regression range searching.
>
> Are the "replacement" results tests re-run with builds from the
> new revisions?
>

Yes.


>
> Or are the results copied from results for the previous revisions?
>

No.


> If so, is this detectable in treeherder somehow?
>

Making treeherder react to rewrites is one of the blockers for bug 1288845.


>
> >> https://hg.mozilla.org/integration/autoland/rev/04a37d89a469
> >> says "An error occurred while processing your request"
> >
> > This is likely bug 1321344. Ugh, it looks like that issue is more
> > widespread than I thought. I'll try to fix it in the next hour.
>
> I thought the "no" answer above would indicate changesets that
> have been rewritten would no longer be visible through the URLs
> such as above, but would you expect rewritten changsets to remain
> visible on these URLs (if bug 1321344 were fixed)?
>

Rewritten changesets will HTTP 404. (Although this behavior may change in
future versions of Mercurial.)


>
> >> Is it necessary to pull autoland and use the evolve extension?
> >
> > It isn't necessary to have evolve enabled to pull the autoland repo. But
> if
> > evolve is enabled, rewritten changesets that you have pulled from the
> > autoland repo will disappear automatically. Otherwise your local repo
> will
> > keep accumulating old heads now have since been rewritten on the autoland
> > repo.
>
> Thanks.  Just to be clear, will pulling from autoland pull old
> heads that have been rewritten?
>

No. The server does not expose rewritten changesets. Its similar to how Git
doesn't expose commits that have no refs encasing them: the data is still
there but since it is obsolete it isn't accessible via normal means.


>
> (i.e. I'm not clear whether the accumulating old heads need to be
> pulled before the rewrite.)
>

If you pull a changeset that is later rewritten, you will accumulate heads
(the heads rewrites occurred on) unless evolve hides them automagically.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: autoland cleanup

[Karl Tomlinson]

Gregory Szorc writes:

> On Wed, Nov 30, 2016 at 12:40 PM, Karl Tomlinson  wrote:
>> When history is rewritten, is there a way to view the original
>> history through the web interface, so that autoland tinderbox
>> builds can be used to find regression ranges?
>
> No. Rewritten changesets should result in "replacement" automation results.
> So there should be no loss of automation coverage. So there should be no
> major impact to things like regression range searching.

Are the "replacement" results tests re-run with builds from the
new revisions?

Or are the results copied from results for the previous revisions?
If so, is this detectable in treeherder somehow?

>> https://hg.mozilla.org/integration/autoland/rev/04a37d89a469
>> says "An error occurred while processing your request"
>
> This is likely bug 1321344. Ugh, it looks like that issue is more
> widespread than I thought. I'll try to fix it in the next hour.

I thought the "no" answer above would indicate changesets that
have been rewritten would no longer be visible through the URLs
such as above, but would you expect rewritten changsets to remain
visible on these URLs (if bug 1321344 were fixed)?

>> Is it necessary to pull autoland and use the evolve extension?
>
> It isn't necessary to have evolve enabled to pull the autoland repo. But if
> evolve is enabled, rewritten changesets that you have pulled from the
> autoland repo will disappear automatically. Otherwise your local repo will
> keep accumulating old heads now have since been rewritten on the autoland
> repo.

Thanks.  Just to be clear, will pulling from autoland pull old
heads that have been rewritten?

(i.e. I'm not clear whether the accumulating old heads need to be
pulled before the rewrite.)
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: autoland cleanup

[Gregory Szorc]

On Wed, Nov 30, 2016 at 12:40 PM, Karl Tomlinson  wrote:

> Gregory Szorc writes:
>
> > When the autoland repository was introduced, it was advised to not pull
> > from this repository because we plan to do rewrites like this frequently
> in
> > the future. So if this rewriting impacted your local repo and you aren't
> a
> > sheriff, you should consider changing your workflow to not rely on
> pulling
> > the autoland repo.
>
> Thank you for cleaning up the accidental delete/adds.
> Do you think it would be worth blocking commits from git that add
> and remove files to avoid this happening in future?
> This is not the first time this has happened.
> Bug 1313432 (automv) may help on autoland, but the problem is not
> specific to autoland.
>

Loss of copy and rename metadata due to human error and poor tooling has
been a problem for years. Plans are in motion to require autoland for all
landings. Probably sometime in 2017. (Note: this won't necessarily require
MozReview.) So once autoland is handling everything, we can do copy/rename
detection in autoland and this wont be a problem any more.

As for a stop gap to block commits without copy metadata, that is
computationally expensive and not something I feel comfortable deploying on
the server side.


>
> When history is rewritten, is there a way to view the original
> history through the web interface, so that autoland tinderbox
> builds can be used to find regression ranges?
>

No. Rewritten changesets should result in "replacement" automation results.
So there should be no loss of automation coverage. So there should be no
major impact to things like regression range searching.


>
> https://hg.mozilla.org/integration/autoland/rev/04a37d89a469
> says "An error occurred while processing your request"
>

This is likely bug 1321344. Ugh, it looks like that issue is more
widespread than I thought. I'll try to fix it in the next hour.


>
> Is it necessary to pull autoland and use the evolve extension?
>

It isn't necessary to have evolve enabled to pull the autoland repo. But if
evolve is enabled, rewritten changesets that you have pulled from the
autoland repo will disappear automatically. Otherwise your local repo will
keep accumulating old heads now have since been rewritten on the autoland
repo. If Git users pull from autoland, it will appear as if a force push
occurred.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: autoland cleanup

[Karl Tomlinson]

Gregory Szorc writes:

> When the autoland repository was introduced, it was advised to not pull
> from this repository because we plan to do rewrites like this frequently in
> the future. So if this rewriting impacted your local repo and you aren't a
> sheriff, you should consider changing your workflow to not rely on pulling
> the autoland repo.

Thank you for cleaning up the accidental delete/adds.
Do you think it would be worth blocking commits from git that add
and remove files to avoid this happening in future?
This is not the first time this has happened.
Bug 1313432 (automv) may help on autoland, but the problem is not
specific to autoland.

When history is rewritten, is there a way to view the original
history through the web interface, so that autoland tinderbox
builds can be used to find regression ranges?

https://hg.mozilla.org/integration/autoland/rev/04a37d89a469
says "An error occurred while processing your request"

Is it necessary to pull autoland and use the evolve extension?
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

autoland cleanup

[Gregory Szorc]

There was a sub-optimal landing in the autoland repository. Long story
short, we rewrote a handful of changesets on the autoland repository and
their corresponding pushlog entries.

Accidental fallout from the rewrite was all autoland requests queued since
the tree was closed ~14 hours ago failed. I /think/ I managed to retrigger
them all. But if you tried to autoland something recently, you may want to
check that it went through.

If you pulled the repo starting from ~14 hours ago until ~1 hour ago and
you don't have Mercurial's evolve extension enabled, you'll need to run `hg
--config extensions.strip= strip -r 04a37d89a469` to clean up the
now-rewritten changesets from your local repo.

When the autoland repository was introduced, it was advised to not pull
from this repository because we plan to do rewrites like this frequently in
the future. So if this rewriting impacted your local repo and you aren't a
sheriff, you should consider changing your workflow to not rely on pulling
the autoland repo.

Bug 1321184 tracked this work.

Sorry for the mess.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship: Web Authentication

[Anders Rundgren]

It is a pity that external tokens have become the focus when the majority will 
rather rely on embedded security solutions which nowadays is a standard feature 
in Android and Windows platforms.

On Tuesday, November 15, 2016 at 8:47:49 PM UTC+1, JC Jones wrote:
> Apologies, this got caught in a filter. Re-sending for posterity on the
> list.
> -- Forwarded message --
> From: J.C. Jones
> Date: Tue, Nov 15, 2016 at 12:01 PM
> Subject: Re: Intent to implement and ship: Web Authentication
> To: berniepa...@gmail.com
> Cc: dev-platform@lists.mozilla.org
> 
> 
> Hey Bernie,
> 
> That's one possibility, but I expect WebAuthn to support the U2F
> attestation payloads in its MakeCredential and GetAssertion calls, and then
> Firefox will implement the U2F HID protocol initially rather than jumping
> to CTAP v1.1.
> 
> Cheers,
> J.C.
> 
> On Mon, Nov 14, 2016 at 6:08 PM,  wrote:
> 
> > Le lundi 14 novembre 2016 22:41:37 UTC+1, berni...@gmail.com a écrit :
> > > Le lundi 14 novembre 2016 18:34:11 UTC+1, JC Jones a écrit :
> > > > Bernie,
> > > >
> > > > You're right that the current WD does not contain the "U2F HID token"
> > > > attestation format, but the WG is _intending_ to add it [1] -- and
> > support
> > > > for such devices -- in Working Draft 4 [2] as soon as a larger
> > in-document
> > > > refactor is complete.
> > > >
> > > > I won't guarantee success at this point, but I believe it likely that
> > > > WebAuthn will ultimately support most fielded U2F HID-compliant
> > devices.
> > > >
> > > > [1] https://github.com/w3c/webauthn/issues/214
> > > > [2] https://github.com/w3c/webauthn/milestone/8
> > > >
> > > > Cheers!
> > > > J.C.
> > > >
> > > >
> > > >
> > > > On Sun, Nov 13, 2016 at 4:36 PM, Bernie wrote:
> > > >
> > > > > Le vendredi 11 novembre 2016 22:18:58 UTC+1, JC Jones a écrit :
> > > > > > The W3C Web Authentication Working Group [1] was formed to produce
> > a
> > > > > > browser-facing standard for using strong, cryptographic scoped
> > > > > credentials
> > > > > > to authenticate to web applications in an un-phishable way. The
> > Working
> > > > > > Group began working from specifications produced by the FIDO
> > Alliance,
> > > > > but
> > > > > > through the W3C process ensured there was a web-focus to the final
> > > > > result.
> > > > > >
> > > > > > We have been tracking the Web Authentication standard since last
> > year’s
> > > > > > FIDO U2F announcement [2],  and we believe Web Authentication
> > provides a
> > > > > > valuable augmentation to web application security in an inclusive
> > way. We
> > > > > > are proposing to implement the current draft specification for Web
> > > > > > Authentication [3], and then track the evolution through to its
> > final
> > > > > > Recommendation state.
> > > > > >
> > > > > > Background: The Mozilla Foundation joined the FIDO Alliance to
> > support
> > > > > the
> > > > > > work of providing augmented security to user logins across the
> > Web. We
> > > > > > encouraged FIDO to evolve their browser specifications within the
> > W3C, to
> > > > > > enable larger community involvement than simply Alliance members.
> > This
> > > > > > specification is a result of that wider effort.
> > > > > >
> > > > > > Web Authentication defines a way to use credentials from a secure
> > element
> > > > > > to authenticate to web applications using public key cryptography.
> > As
> > > > > with
> > > > > > FIDO U2F, the browser’s role is mainly to provide the interface
> > between
> > > > > the
> > > > > > secure element (such as a USB dongle) and the web application, and
> > to
> > > > > > enforce a scoped security model to bind the resulting attestation
> > to the
> > > > > > specific web application.
> > > > > >
> > > > > > Web Authentication support is currently in development for
> > Microsoft Edge
> > > > > > [4] [5]. Google Chrome’s support is also in-development.  Several
> > > > > websites
> > > > > > have deployed support for U2F, the predecessor to WebAuthn,
> > including
> > > > > > Gmail, Dropbox, and Github. Additionally, there are many U2F
> > devices in
> > > > > use
> > > > > > today which will function with the Web Authentication API.
> > > > > >
> > > > > > Proposed: To implement the Web Authentication API, with support
> > for the
> > > > > USB
> > > > > > U2F HID token attestation format.
> > > > > >
> > > > > > Please send comments on this proposal to the list no later than 21
> > > > > November
> > > > > > 2016.
> > > > > >
> > > > > > [1] https://www.w3.org/blog/webauthn/
> > > > > >
> > > > > > [2] https://groups.google.com/d/msg/mozilla.dev.platform/
> > > > > > IVGEJnQW3Uo/Eu5tvyLmCgAJ
> > > > > >
> > > > > > [3] https://www.w3.org/TR/webauthn/
> > > > > >
> > > > > > [4] https://blogs.windows.com/msedgedev/2016/04/12/a-world-
> > > > > > without-passwords-windows-hello-in-microsoft-edge/#XKWsxS6Pw
> > LOtBYrG.97
> > > > > >
> > > > > > [5] 

Volunteer maintainer wanted: mac x86

[Benjamin Smedberg]

As of Firefox 53, we are intending to switch Firefox on mac from a
universal x86/x86-64 build to a single-architecture x86-64 build.

To simplify the build system and enable other optimizations, we are
planning on removing support for universal mac build from the Mozilla build
system.

The Mozilla build and test infrastructure will only be testing the x86-64
codepaths on mac. However, we are willing to keep the x86 build
configuration supported as a community-supported (tier 3) build
configuration, if there is somebody willing to step forward and volunteer
as the maintainer for the port. The maintainer's responsibility is to
periodically build the tree and make sure it continues to run.

Please contact me directly (not on the list) if you are interested in
volunteering. If I do not hear from a volunteer by 23-December, the Mozilla
project will consider the Mac-x86 build officially unmaintained.

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

Re: Removing the Battery Status API?

[Mounir Lamouri]

On Tue, 29 Nov 2016, at 15:17, Boris Zbarsky wrote:
> > I understand the privacy concerns, but why can't these be handled similar 
> > to the Geolocation API? Ask permission to use / user opts in.
> 
> Because prompting users is generally an antipattern.  If, as a user, you 
> got a battery API prompt on every single page (because the trackers on 
> it were trying to use it), what would be your reaction?

There are other solutions that are not prompting. The specification even
provide guidance such as returning less granular values or even default
values.

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

Re: Intent to implement: Web2Native Bridge

[Anders Rundgren]

On Tuesday, November 29, 2016 at 10:01:38 PM UTC+1, Nicholas Alexander wrote:
Hi Nick,
Many thanks for your elaborate comments!

If we begin with security, Android already allows Web-sites to invoke apps 
which they have no specific relation to using the custom URI scheme.  I don't 
see that the ability of "talking back" to the calling Web page would introduce 
new vulnerabilities. I haven't noted any web-site registry involved in this 
operation either, you do a one-time grant for selecting browser (if needed) and 
that's it.  The only quirk seems to be that the invocation must be related to a 
user action.

Anyway, the *long-term* goal for this API is that Web-enabled Apps should be 
*vetted* for this kind of usage which also involves changes in "AppStores" and 
OSes to work.  The need for vetting may also depend on what local resources an 
App access.  This part will likely be vendor-and OS-specific.

A security review of mine regarding the Google/Mozilla/Microsoft take on the 
matter:
https://lists.w3.org/Archives/Public/public-webappsec/2015Oct/0071.html


If you look into the W2NB docs it says it is an "emulator", not the real deal.  
The application ID is just a proposal which though should fit Android pretty 
well.

Now over to the actual implementation...

I see two possibilities, one which is more of a PoC allowing people testing the 
core concept on a standard Android phone.  It is still not clear to me if this 
is technically feasible :-(  Hopefully the links you provided give some 
answers.  I'm also looking into Web Payment API which I (believe) does quite 
similar things albeit in a very specific manner.  If this doesn't work I'm will 
try another route which I cannot write about on a public list.

If Mozilla could consider giving me some support, I would be more than happy to 
build on Firefox!

The Web2Native Bridge is the core of a more ambitious effort which among many 
things is about transcending on-line payments from the pitiful state it has 
been in the last 20 years or so.  Well, Google and Apple have already done 
that, but I'm targeting the other 99.9% who don't have a platform they can 
update whenever there's a need.

Best
Anders

> Hi Anders,
> 
> On Tue, Nov 29, 2016 at 9:10 AM, Anders Rundgren <
> anders.rundgren@gmail.com> wrote:
> 
> > There are virtually tons of developers out there using Android Intents to
> > start "Apps" from the Web.
> >
> 
> Aye, and Firefox does support this custom URI scheme.
> 
> 
> > However, this mechanism sucks big-time since:
> > 1. It leaves the invoking Web page in an "orphaned" state
> > 2. There's no way to "talk back" to the invoked Web page
> > 3. There's no Web page security context available to invoked "App"
> > 4. There's no App/Web life-cycle control
> >
> > The Web2Native Bridge does all that:
> > https://github.com/cyberphone/web2native-bridge#api
> 
> 
> I took a look at this and don't yet see how this translates to Android.  It
> all seems very Chrome OS specific: "Applications callable by the Web2Native
> Bridge emulator *must* be written in Java and stored in a for the purpose
> dedicated directory."
> 
> Is your intention to define a new specification for how an Android App
> advertises this capability and how the browser connects to it?  (Android
> Intents, an AIDL and handshake protocol, etc...)  This would be
> interesting; it's similar in spirit to the Chrome Custom Tabs work, which
> goes in the opposite direction: it makes Apps have better entry into the
> browser (where-as you want content in the browser to have better entry into
> a companion App).
> 
> Unfortunately (or maybe you guys think fortunately) I will most likely
> > implement this in Chromium since there is more activity in that channel.
> >
> 
> I never think it's fortunate when folks passionate enough to implement a
> thing don't implement under the Mozilla umbrella!  I can provide some
> guidance on doing this in Firefox for Android, if you'd like to try it
> under our umbrella.  I can't speak to things like ship criteria and release
> schedules, though :(
> 
> As a bizarre "Mozilla bonus point", I bet you can do this in a bootstrapped
> extension using the essentially undocumented "Java addons" feature!  It's
> 100% non-obvious how to use it, but you can add a classes.dex to a Firefox
> addon and load it using a Java class loader.  See
> https://dxr.mozilla.org/mozilla-central/source/mobile/android/javaaddons/java/org/mozilla/javaaddons/JavaAddonInterfaceV1.java
> and the test at
> https://dxr.mozilla.org/mozilla-central/source/mobile/android/tests/browser/chrome/test_java_addons.html,
> which appears to be still running in our automation.  Using this, you could
> have your extension inject the `navigator.nativeConnect` method into the
> content context (at least I think this is possible, I did it once -- see
> https://github.com/ncalexan/bootstrapped-webapi-skeleton -- but I think
> this approach may no longer work) and then use a Java addon to