Yeah. Pure Awesome.
Congratulations you guys - you’ve risen to meet an insane challenge.
lloyd
On Feb 1, 2014, at 8:48 PM, Chris Karlof wrote:
> I want to congratulate and thank everyone for getting FxA Sync enabled in
> Nightly yesterday, as well as the production deploys of FxA and Sync.
Weekly thanks here, weekly fist-pumping inline.
On Nov 9, 2013, at 2:04 AM, Chris Karlof wrote:
> Firefox Accounts wiki: https://wiki.mozilla.org/Identity/FirefoxAccounts
> Sync.next wiki: https://wiki.mozilla.org/User_Services/Sync
> IRC: #fxa
>
> Firefox Accounts Cloud Services and Client lib
> -z
>
> - Original Message -
>> From: "Lloyd Hilaiel"
>> To: "Austin King"
>> Cc: sync-dev@mozilla.org, dev-fxa...@mozilla.org, "Zachary Carter"
>>
>> Sent: Tuesday, November 5, 2013 1:04:49 AM
>> Subject: Re: 10.
Does it make sense to move all of our conversations here? Both FxA on FxOS
(native_identity) and the artist formerly known as picl?
irclog.gr is logging this new room: http://irclog.gr/#browse/irc.mozilla.org/fxa
lloyd
On Nov 6, 2013, at 12:20 AM, Chris Karlof wrote:
> I've started #fxa to
On Nov 4, 2013, at 8:59 PM, Chris Karlof wrote:
>
> On Nov 4, 2013, at 7:04 AM, Lloyd Hilaiel wrote:
>
>> In discussions in madrid and over the past couple weeks, it’s becoming
>> increasingly clear that we will have to host web based resources for various
>>
I continue to love these updates as a means of staying abreast of development
and rooted in reality. thanks.
On Nov 2, 2013, at 2:03 AM, Chris Karlof wrote:
> Firefox Accounts wiki: https://wiki.mozilla.org/Identity/Firefox-Accounts
> Sync.next wiki: https://wiki.mozilla.org/User_Services/Sync
On Oct 24, 2013, at 8:00 PM, Austin King wrote:
> On 10/24/13 8:17 AM, Zachary Carter wrote:
>> For FxAccounts on FxOS, we've determined that landing the browserified
>> FxAccounts client library in gaia is not really viable.
> Why isn't it viable? These kinds of details are helpful for evaluati
In discussions in madrid and over the past couple weeks, it’s becoming
increasingly clear that we will have to host web based resources for various
parts of the sign-up flows we’re implementing.
This is some squishy work that will cut across multiple efforts. I’m curious
if anyone has started
This is a thing of beauty, Nick!
/cc identity-staff
Tauni / Chris, shall we include the screencast in our bi-weekly update to
everyone@ ?
lloyd
On Oct 24, 2013, at 8:46 AM, Nick Alexander wrote:
> Hi everyone,
>
> Inspired [1] by the whole team, I finally pushed a try build of the work I've
Fernando, thanks for the creativity and working so hard to find a solution - I
realize you're trying to find a compromise that works for your peers and the
gaia and gecko teams - and I really appreciate all the energy and thought
you're putting into this. I wish I could take you out for a beer
nts. That happens on device and requires minimal
network interaction (sometimes none).
You can use that assertion to authenticate to your back end. You can use
whatever seasoning mechanism you desire.
make sense?
lloyd
> Doug
>
>
>
> // Doug Turner
>
>
> On Thu, Oct 1
On Oct 17, 2013, at 7:28 AM, Fabrice Desré wrote:
> The nav.id implementation is "kind of" remoted, in the sense that it
> works oop, but it relies on the security UI in b2g that spawns a new
> process to load network resources. That's very suboptimal, and in no way
> can we add yet another proce
On Oct 17, 2013, at 4:58 AM, Jared Hirsch <6...@mozilla.com> wrote:
> TL;DR - If you want to help danny and rfk, you should really consider doing
> it right away.
To be clear, danny and rfk are working on the Firefox accounts server. Sam,
Jed, and sometimes myself and zaach are working on FxA
On Oct 17, 2013, at 5:04 AM, Doug Turner wrote:
> Have you guys figured out how FxA is going to work between processes? That
> is, suppose the FTU sets up a user. Now, I run my application and I call
> navigator.id. What happens? Am I going to be hitting the network, or are
> you going to
Jedp and I are spending time together in Bulgaria, and the topic is how do we
implement Firefox Accounts in FirefoxOS.
We wanted to figure out enough of an architectural direction to unleash folks
in madrid. So this are concrete proposals, but keep in mind we're making some
stuff up as we go,
On Oct 11, 2013, at 4:35 AM, Gareth Aye wrote:
> That's very much what I was thinking of. I assumed that account management
> built on top of sync would be built into firefox accounts, but I gather
> that's not [yet?] general consensus.
The way I like to think about this, is Firefox Accounts i
On Oct 10, 2013, at 6:00 PM, Zachary Carter wrote:
>
>> From: "Dirkjan Ochtman"
>> To: "Lloyd Hilaiel"
>> Cc: sync-dev@mozilla.org
>> Sent: Thursday, October 10, 2013 3:56:56 AM
>> Subject: Re: Firefox Accounts on Firefox OS
>
&
Firefox Accounts is quickly growing out of it's role as an account system laser
focused on supporting sync improvements, to something more general.
Folks are scampering to build new services that authenticate using firefox
accounts.
To that end I had lots of questions about feasibility and disr
As I work more and more with jed, sam, zach, fabrice, and the FirefoxOS team, I
learn more and more.
To the question of "what does firefox accounts on firefoxos mean?", I wrote the
following document:
https://id.etherpad.mozilla.org/fxa-on-fxos
Curious to hear thoughts and constructive critici
On Oct 10, 2013, at 2:03 AM, Chris Karlof wrote:
>
> On Oct 9, 2013, at 3:49 PM, Rubén Martín wrote:
>
>> El 09/10/13 23:36, Chris Karlof escribió:
>>>
>>> There are several motivations for this, but one is that we are designing
>>> services that store encrypted user data by default. The def
On Oct 10, 2013, at 12:30 AM, John Gruen wrote:
> Wanted to circulate a mind map I threw together to give everyone a sense of
> some of the UX-relevant ideas,concerns, and questions I have about Firefox
> Accounts coming out of Summit. What you see here is highly informal and
> idiosyncratic;
This is a big question, and a fair one. I must go pick up my son right now,
but will offer a proper response in the next 24 hours if no-one beats me to it.
lloyd
On Oct 9, 2013, at 2:34 PM, Rubén Martín wrote:
> Hi,
>
> After doing some research on the current status of Firefox Accounts I ha
+1 to reducing the scope of this conversation to REST api versioning only (we
can tackle DOM/js in other threads, and iiuc that's not a problem we need to
solve right now)
+1 to prepending '/vX' (major version only, include the v)
lloyd
On Sep 24, 2013, at 3:29 AM, Mark Mayo wrote:
> In my e
home directories moved to the main repo
cheers,
lloyd
On Sep 20, 2013, at 5:06 PM, Lloyd Hilaiel wrote:
> First, version 0.5.5 of awsbox has multi-region support (thanks to chilts for
> the underlying copy support):
>
> AWS_REGION=eu-west-1 node_modules/.bin/awsbox create -n w
On Sep 21, 2013, at 12:59 AM, Chris Karlof wrote:
> Note: Mobile team was on Work Week this week.
>
> Firefox Accounts API/Server Development (Dev lead: Danny Coates)
> - Continuing work on Cassandra support and concurrency improvements
> (https://github.com/mozilla/picl-idp/issues/184)
> - Min
First, version 0.5.5 of awsbox has multi-region support (thanks to chilts for
the underlying copy support):
AWS_REGION=eu-west-1 node_modules/.bin/awsbox create -n whiskey -t c1.medium
Second, version 0.6.0-beta is on it's way to migrate off of http-proxy and onto
nginx:
npm install awsbox@0.6
Thanks again for carrying this torch, chris. I love these reports.
Fist pumping and questions inline.
On Sep 7, 2013, at 1:23 AM, Chris Karlof wrote:
> Firefox Accounts API/Server Development (Dev lead: Danny Coates)
> - Further improvements to API of node-srp module
> (https://github.com/mo
What are the tradeoffs of dictating protocol and implementing support at the os
level, vs a JavaScript api and leaving the proto decision up to an updatable
app (plus implementing or promoting an awesome js carddav is lib)?
Lloyd
Eric Rescorla wrote:
On Thu, Sep 5, 2013 at 5:41 AM, Lloyd
The difference is, users must have choice. Sure we can support the big guys,
but we should also make it so little guys can build ffx support in an
absolutely seamless manner and directly compete.
This is an area where we can give the market a fighting chance to do one thing,
do it extremely we
Thanks again for these thorough updates, Chris. They are extremely helpful.
Given the first integration of fxa setup on desktop is now r+'d, can we add a
first build (from elm) of desktop and client to next weeks goals?
Chris Karlof wrote:
I've merged both progress reports into a single email
Yo, I'z hacking on bug #904612 to push it forward, given that I have ttaubert
here on my timezone(ish) and the feedback was pretty tight and clear.
Seems like we changed the host for the sign-up flow to
http://idp-mocks.lcip.org/flow?
First, is this right, second do we have a central place that
On Aug 19, 2013, at 3:50 PM, Ryan Kelly wrote:
>
> Hi All,
>
>
> In support of moving fast on Milestone 1, I have stood up a simple dev
> deployment of a tokensever-auth-enabled Sync1.1 server. Hopefully this
> will give us something concrete to develop and test against on the
> storage inte
Geeze, first I'm sorry for making you speculate my intent. More color inline.
On Aug 20, 2013, at 2:55 AM, Brian Warner wrote:
> On 8/12/13 6:55 AM, Lloyd Hilaiel wrote:
>
>> What are the cons of reducing the security of recoverable class A data
>> such that it c
focus from milestone 1.
lloyd
> Thanks,
> Karen
>
> -Original Message-
> From: Sync-dev [mailto:sync-dev-boun...@mozilla.org] On Behalf Of Chris
> Karlof
> Sent: August 16, 2013 7:24 PM
> To: Lloyd Hilaiel
> Cc: sync-dev@mozilla.org
> Subject: Re: Reducing t
On Aug 17, 2013, at 2:24 AM, Chris Karlof wrote:
>
> On Aug 12, 2013, at 6:55 AM, Lloyd Hilaiel wrote:
>
>> Now that some of the other challenging threads have died down, let's have
>> another one.
>>
>> As I think deeply (at least as deeply as I am ca
t in my reading through this thread. How will our
localization community, which I understand has a solid process for
localizing Firefox features in XUL, deal with localizing HTML?
- A
On 8/9/2013 7:31 AM, Lloyd Hilaiel wrote:
> Chris Karlof and I were talking yesterday, and I was noti
Here's a brain dump of where we're at from my perspective. Chris, care to take
this sketch and roll it up into the holistic status like what you produced last
week?
Bug tree for mobile created:
https://bugzilla.mozilla.org/showdependencytree.cgi?id=799726&hide_resolved=1
Bug tree for desktop
On Aug 16, 2013, at 5:01 PM, Mark Finkle wrote:
>
>
> On Aug 16, 2013, at 4:37 PM, Mark Finkle wrote:
>
> When do we uplift?
>
> How about Weeklyish. Not so often that there's overly-much process, but
> frequently enough that we avoid annoying merge issues and don't drift too far
> from m
On Aug 16, 2013, at 4:37 PM, Mark Finkle wrote:
>
>
> So ttaubert and I were talking on IRC looking to land the implementation of a
> container to host HTML auth flow (hammered out by zach and vlad).
>
> Meta question came up, ttaubert asks - "should that code match m-c quality
> already? ho
So ttaubert and I were talking on IRC looking to land the implementation of a
container to host HTML auth flow (hammered out by zach and vlad).
Meta question came up, ttaubert asks - "should that code match m-c quality
already? how is that merged? what/where is elm?"
Here's the proposal:
Basic
Hey James,
Thanks for jumping in.
At a high level, we can definitely cc you on all bugs and work related to
milestone 1. I can take the action to provide you code drops with a clear
explanation of what is inside and what's ready for testing at various points of
the work.
I agree that we need
First, a high level point, then I'll read through this thread -
This is an engineering milestone. At the time it's done, we will holistically
consider where we're at, include stakeholders (we have a lot of stakeholders),
and figure out whether we want to move to ship it.
This will get us movi
c codebase) (storage architecture 1.1)
5. scope work required to avoid future flag days (but implementation not part
of milestone 1)
Who's doing the work:
picl-idp: dcoates is the lead, with support from rfk, zaach, and dev/ops to be
determined
Android: Nick Alexander is the lead.
Desktop: Llo
On Aug 13, 2013, at 2:49 AM, Nick Alexander wrote:
> On 13-08-09 7:31 AM, Lloyd Hilaiel wrote:
>> Chris Karlof and I were talking yesterday, and I was noting how awesome the
>> implementation approach of Persona on FirefoxOS has been. The, the relevant
>> code that shi
On Aug 13, 2013, at 11:53 AM, Andreas Gal wrote:
>
> You seem to be implying that I am uncomfortable with projects using different
> tools. That is as unfair as it is inaccurate. I heavily use github, github
> issues and a whole range of tools that are not bugzilla and hg. Every project
> we
On Aug 12, 2013, at 10:11 PM, Andreas Gal wrote:
>
> Lloyd Hilaiel wrote:
>>
>> On Aug 12, 2013, at 4:27 PM, Johnathan Nightingale
>> wrote:
>>
>>> On Aug 9, 2013, at 9:11 PM, Mark Finkle wrote:
>>>
>>>> My only strong opinions
On Aug 12, 2013, at 10:06 PM, Andreas Gal wrote:
>
> Andreas: "and those cases we can handle with client-driven migration."
>> Lloyd: it seems like client managed upgrade is the way to go here, "
> Sounds like we are in agreement here, no?
The only difference is that if 100% of cases require cl
On Aug 12, 2013, at 7:15 PM, Mark Finkle wrote:
>
>
> Defining such an interface and managing the multiple client and server
> versions is not awesome, but of course it can be done. And loading a
> privileged page is equivalent: the interesting part is populating the
> interface (or privile
On Aug 12, 2013, at 6:42 PM, Nick Alexander wrote:
>> So I'm going to claim a decision has been made here. We'll build a
>> container to handle authentication screens but not management. afaik,
>> zcarter is already wiring up the existing user tested mocks to interact with
>> the account ser
Now that some of the other challenging threads have died down, let's have
another one.
As I think deeply (at least as deeply as I am capable of) about how users will
log into different firefox products, and how we can really achieve a high level
of integration, I am reminded just how challengin
On Aug 12, 2013, at 4:27 PM, Johnathan Nightingale wrote:
> On Aug 9, 2013, at 9:11 PM, Mark Finkle wrote:
>
>> My only strong opinions are:
>>
>> 1. Using bugzilla as the one source of truth for bugs. Even b2g had to do
>> it.
>> 2. ELM is the place where the code ends up for nightly builds.
additional
investment and make the thing native, we can go there.
good?
lloyd
On Aug 9, 2013, at 7:01 PM, Nick Alexander wrote:
> On 13-08-09 7:31 AM, Lloyd Hilaiel wrote:
>> Chris Karlof and I were talking yesterday, and I was noting how awesome the
>> implementation approach of
gt; reset password success page") will certainly push this beyond "just
> raise a container" in terms of complexity, but it's likely overall
> simpler than building a custom UI (and it has the other benefits you
> mention).
>
> Gavin
>
> On Fri, Aug
On Aug 12, 2013, at 3:09 AM, Ryan Kelly wrote:
> On 10/08/2013 12:57 AM, Lloyd Hilaiel wrote:
>> On Aug 9, 2013, at 5:53 PM, Nick Alexander wrote:
>>> On 13-08-09 5:35 AM, Lloyd Hilaiel wrote:
>>>> 4. (chris karlof) Future Storage Implementation - This is defi
On Aug 12, 2013, at 4:26 AM, Ryan Kelly wrote:
>
> Hi All,
>
>
> Here's a quick take on how version-negotiation might look in practice.
> I'm deliberately proposing a very blunt and inelegant instrument, in an
> attempt to surface what our minimal needs really are.
>
> Version negotiation is
On Aug 12, 2013, at 5:05 AM, Andreas Gal wrote:
>
>
> Ryan Kelly wrote:
>>
>> On 12/08/2013 11:38 AM, Andreas Gal wrote:
>>> Ryan Kelly wrote:
On 11/08/2013 4:36 PM, Andreas Gal wrote:
> once we went
> through one flag day and have the data stored in cleartext we can do
> arbi
possibilities.)
>
> - Original Message -
>> From: "Nick Alexander"
>> To: sync-dev@mozilla.org
>> Sent: Friday, August 9, 2013 9:01:01 AM
>> Subject: Re: Implementation approaches for Create Account / Sign In
>>
>> On 13-08-09 7:31 AM, Llo
Grafting a better sign up onto sync 1.1 has been talked about as a way to
address usability problems in sync without having to deal with the complexity
of the current implementation. A way to release a fix to sync faster.
Talking about this as a real option makes people really uncomfortable. I
Ok, a little pushback.
My thought here was that github just has better collaboration tools than an hg
only flow. milestones, issues, pull requests, line level commenting.
My thought was that we could all use the *same* github repository to raise the
visibility of what we each do in isolation
I <3 this thread. Distillation attempting not to discount:
1. setup UI in content isn't crazy, there are a lot of benefits and plenty of
precedent
A: yay!
2. we're worried about more ops dependencies
A: If we make it part of the bridge, then we add no new ops deps. We already
will do this on
Repo at https://github.com/mozilla/picl-mozilla-central
Mark Finkle wrote:
- Original Message -
> I propose a new sub-team named "client implementation". What does that
> actually mean?
> I think this actually means a team that lands code on the elm branch, and
> incrementally uplifts
scope is my first guess, all persistence in chrome...
Lloyd
Nick Alexander wrote:
On 13-08-09 7:31 AM, Lloyd Hilaiel wrote:
> Chris Karlof and I were talking yesterday, and I was noting how awesome the
> implementation approach of Persona on FirefoxOS has been. The, the relevant
>
On Aug 9, 2013, at 5:53 PM, Nick Alexander wrote:
> On 13-08-09 5:35 AM, Lloyd Hilaiel wrote:
>> Yo all,
>>
>> In a recent letter to the identity team I proposed breaking down the
>> team by well defined projects, and having single leadership for each
>> project
Chris Karlof and I were talking yesterday, and I was noting how awesome the
implementation approach of Persona on FirefoxOS has been. The, the relevant
code that ships with the device is limited to a container capable of running
web content, and some setup code which invokes a function within t
I propose a new sub-team named "client implementation". What does that
actually mean?
I think this actually means a team that lands code on the elm branch, and
incrementally uplifts into nightly as it goes. I think this team targets
implementing new authentication on existing sync, no storage
This is email 2 in a 5 part series.
True fact: Lots of people care *deeply* about getting sync fixed and they need
to:
a. see regular progress
b. understand how we get to shipping
I'm hoping the breakdown into sub teams and naming of leaders gives each
individual what they need to communicate.
Yo all,
In a recent letter to the identity team I proposed breaking down the team by
well defined projects, and having single leadership for each project. What
does leadership mean in this context? Here's how I defined the expectations:
> 1. Run the project meetings - agenda's ahead of time,
yo all,
Wanted to start by getting elm up to date with latest moz-central, but I need a
vouch. can haz?
https://bugzilla.mozilla.org/903382
lloyd
___
Sync-dev mailing list
Sync-dev@mozilla.org
https://mail.mozilla.org/listinfo/sync-dev
On Aug 6, 2013, at 7:10 PM, Richard Newman wrote:
> Related: in all the discussions about killing Master Password, its use as a
> "filing cabinet lock" – keeping out snoopers, not attackers – seems to be the
> most compelling argument.
PIN Codes!
lloyd
_
http://blog.elliottkember.com/chromes-insane-password-security-strategy
(forwarded from dev-identity)
lloyd___
Sync-dev mailing list
Sync-dev@mozilla.org
https://mail.mozilla.org/listinfo/sync-dev
On Aug 1, 2013, at 9:58 PM, Deb Richardson wrote:
>
> == Goals ==
> The goals of this MVP release of the new Sync service are to:
> * Replace the existing Sync service with a much more reliable & scalable
> system that closely (but not precisely) matches the old Sync functionality
> * Introduce
On Aug 1, 2013, at 10:39 PM, Deb Richardson wrote:
> I've gone ahead and added these notes to the Sync v1 wiki page here:
>
> https://wiki.mozilla.org/User_Services/Sync/v1#Migration_strategy
>
> We can change anything in there as needed, I just wanted to keep everything
> in the same place
On Aug 1, 2013, at 8:54 AM, Asa Dotzler wrote:
> On 8/1/2013 7:41 AM, Nick Alexander wrote:
>> On 13-07-31 6:23 PM, Richard Newman wrote:
But they might be preparing to use Firefox on more than one
machine, or preparing to use Firefox on desktop and Android.
I think the idea is to
On Jul 31, 2013, at 3:59 PM, Deb Richardson wrote:
>
> https://wiki.mozilla.org/Firefox_Account/Sync/v1
>
> The logic being that "Firefox Account" is an overarching umbrella
> project/product that will tie a disparate bunch of user services together
> ("Sync", "Reading List", etc.), and this
On Jul 26, 2013, at 2:23 PM, Andreas Gal wrote:
>
>
> Mark Finkle wrote:
>>
>> I worry about this approach in that Firefox does not know my Facebook
>> password unless I ask Firefox to save it.
> We have your facebook cookie, which is equivalent to identify you. We are not
> storing anything
Mark, can you make your scatterplots available to either this list or if
there's any sensitive data directly to agal and whoever is interested?
lloyd
On Jul 26, 2013, at 2:11 PM, Andreas Gal wrote:
> Can you share?
>
> Lloyd Hilaiel wrote:
>>
>> On Jul 26, 201
On Jul 26, 2013, at 1:58 PM, Andreas Gal wrote:
> If I remember correctly, the average user has 500 passwords. Thats not a big
> deal compressed. Bookmarks is 500-ish as well. History 5000-ish. We can
> easily limit history for worst cases. I don't think people will have
> thousands of passwor
On Jul 26, 2013, at 1:03 PM, Andreas Gal wrote:
> In short, what I heard yesterday ("lets copy data in case of conflict") is a
> noble theory, but I am afraid wrong in practice, and I would like to hear
> comments on the observation above.
Sounds like you're refining that theory. That conflic
There's been an idea kicked around repeatedly by andreas and ekr that we could
do login to picl *implictly* based on browser knowledge of sites you visit.
The idea goes something like this "given that PiCL is inside the browser, and
the browser knows your identity on various sites, couldn't we j
performant syncing architecture (which'll make me happy).
Ok, I'm admitting we're going to have a pretty protracted conversation on this
tomorrow, and just wanted to ensure concerns were represented.
I *think* I've done a fair job. We shall see! :}
lloyd
> -R
>
On Jul 23, 2013, at 6:51 PM, Brian Warner wrote:
>>
>> I continue to seek feedback from product management to vet my belief
>> here.
>
> I think I can guess what that feedback will be :).
I've done the footwork with marketplace, and as impartial as I can be is that
we really need to have auth
I imagine tomorrow at the design review we'll want to spend some time talking
about CouchDB.
If you had to summarize all the unknowns, or areas of concern, would they fall
into this list?
# Structured data (bookmarks!)
# Protocol Limitations
# Client resource usage
# Data Representation
# Scala
On Jul 24, 2013, at 1:26 PM, Mark Finkle wrote:
> In general, I like the idea of using some form of client-side adapter to
> insulate the client from protocol/storage changes. You are pushing the
> SyncableService API and I don't have any reasons to go against it. It seems
> like a nice adapte
83 matches
Mail list logo
