Sorry, was away last week.
I'm very much in favor of an incremental approach that'll make the longer term
goals easier, but I'm aware that for now it's entirely a client resource issue.
If you folks can do it, I'm a +1.
Toby
On Oct 13, 2014, at 5:50 PM, Richard Newman wrote:
>> Presumably,
What is a submission here? Just general FF usage, or FF usage with sync enabled?
Great to finally be getting numbers here.
Thanks,
Toby
On Sep 25, 2014, at 11:06 AM, Chris Karlof wrote:
> We put in some telemetry probes to measure custom sync configurations (e.g.,
> self hosting) in Nightly.
On Jul 3, 2014, at 8:41 AM, Richard Newman wrote:
>
> If you're looking to build your own client software stack, reusing some of
> Mozilla's code, you can start building your own auth on top of Sync.
This is a path (albeit a scary one). The tokenserver is authentication agnostic
- if you want
On Jun 4, 2014, at 5:41 PM, Richard Newman wrote:
> An add-on is more feasible on Android than forcing users to modify
> about:config, but there are a lot of add-on discoverability issues on Fennec
> (the overwhelming majority of users don't use them, and almost certainly
> don't know how to f
On Feb 19, 2014, at 1:26 PM, Richard Newman wrote:
>> We will not fail because TLS-level attackers replay users' requests. We are
>> much more likely to fail by not being able to manage self-induced complexity
>> and repelling users with frustrating experiences resulting from that
>> complexi
This seems like the best answer beyond throwing time (and HAWK) out the window
entirely. We're carrying baggage from multiple different machines; asking the
client to sort that out seems doomed.
It's unlikely to be an issue for external users, as their install will all be
on the same box in mos
cluded a pointer to the correct place. Thanks for pointing it out.
Regards,
Toby Elliott
___
Sync-dev mailing list
Sync-dev@mozilla.org
https://mail.mozilla.org/listinfo/sync-dev
On Jan 30, 2014, at 11:17 AM, Stefan Arentz wrote:
> The token server for production is
> https://token.services.mozilla.com/1.0/sync/1.5 which means ‘give me a token
> for sync 1.5’. But the endpoint that it returns is
> https://sync-1-us-east-1.sync.services.mozilla.com/1.1/$UID. Note the 1
You have two step 9s in the sync overall flow diagram. (One is a not-often
needed extra step, but it's a little confusing).
Otherwise, looks good.
Toby
On Jan 29, 2014, at 2:56 PM, Gene Wood wrote:
> Here's an operations-focused high level diagram of the user flow and network
> connections
On possibility that Ryan and I discussed - if the tokenserver gets a new
generation cert, it immediately rejects and backs off all clients of that
account for the token expiry period. That way we can guarantee that when the
writes start again, every client is using the new key.
It's a little ha
I have a few concerns here. It's quite possible that I'm misunderstanding this
proposal, so please correct me if I have it wrong, but I see two hurdles:
1) One of the goals of the tokenserver is to abstract the relationship between
the auth mechanism and the service so that a single tokenserver
On Jan 7, 2014, at 4:06 PM, Nick Alexander wrote:
> On 1/7/2014, 2:43 PM, Mark Mayo wrote:
>> We move forward with Chris' plan [1] with the following
>> amendments/clarification:
>>
>> 1) We support old-sync-signin for existing users (i.e. "let 'em be") in
>> 29+, yes. But we do not allow for o
On Jan 3, 2014, at 5:02 PM, Brian Warner wrote:
>
> I don't know as much about the tokenserver (design or deployment) as I
> should, but if current-Sync is using it, then I imagine that we could
> run a single tokenserver that understands both old and new/FxA schemes,
> it will have a DB with a
On Jan 3, 2014, at 3:59 PM, Chris Karlof wrote:
> Hi all,
>
> I see today listed as the deadline for a decision on a transition plan. I
> haven't seen significant discussion on this over the last day or two.
>
I've also been asking for some clarity and getting a lot of different answers.
Th
I think the v is unnecessary, but don't feel that strongly about it.
What has worked for us is MAJOR.MINOR versions. This lets you communicate
small, backwards-compatible changes (going from 1.0 to 1.1) in a way that
single-number versions don't . Something going from v1 to v2 tells you nothing
On Aug 12, 2013, at 12:21 PM, Mark Mayo wrote:
> On Mon, Aug 12, 2013 at 12:12 PM, Toby Elliott wrote:
>
> Is the idea that the data would sit on the servers unencrypted? How far
> reduced are you thinking?
>
> I believe the idea is that the data would be encrypted
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 capable of) about how users
> will log into different firefox products, and how we can really achieve
I cannot answer all of these questions, but here's the bulk of them.
On Aug 10, 2013, at 8:07 PM, Mark Finkle wrote:
> 1. In my early discussions with the old Services team, Sync 2.0 was termed:
> (Sync 1.1 + bug fixes) + pluggable Auth. This that a reasonable definition?
Yes, plus taking what
On Aug 9, 2013, at 8:57 PM, Andreas Gal wrote:
> Help me understand why we need a second flag day when changing wire
> formats or storage formats.
Auth changeover wouldn't (necessarily) require a flag day. We could set the old
servers to accept both auth types.
Where it gets tricky is when so
On Aug 9, 2013, at 4:37 PM, Lloyd Hilaiel wrote:
> 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 abo
On Aug 9, 2013, at 7:13 AM, Lloyd Hilaiel wrote:
> 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
On Jul 24, 2013, at 12:26 PM, Mark Finkle wrote:
>
> Observation 1: The CouchDB API or the Dropbox File API is likely good enough
> for syncing independent (or even mostly independent) records (e..g, history,
> passwords, tabs). Future stuff like calendar events, contacts, reading list,
> etc
22 matches
Mail list logo
