Re: Rebootable Sync Nodes

There's another option here that hasn't been mentioned: switch to storing tabs on disk. It's possible that the considerations that caused us to not persist them are no longer worth the difference in behavior. Most users will have relatively small tabs records. We already persist other churny data,

Re: Rebootable Sync Nodes

> > We could potentially count the clients records and only restore users with > a single client. > I worry about client records having been TTLed, which makes this measurement inaccurate. (Check and see how many accounts have zero client records!) I feel that restoring an earlier point in time i

Re: Rebootable Sync Nodes

I didn’t see a reply to this, so here’s mine from the plane. So long as the tabs collection is bumped to zero in info/collections (which, given that i/c is in memcache and will be rebuilt after reboot, should be the case, right?), there’s a good chance that clients will repopulate it. If not, i

Re: So, I wrote some code to put places.sqlite data into Mentat

Thanks for doing this, Thom! It's quite a while since I did something similar. A few quick notes on import: - We expect writes to be relatively slow (indeed, we expect everything to be relatively slow, because we haven't done much performance tuning yet), but that importer code is runnin

Re: Data issues with cloned profiles

I see https://bugzilla.mozilla.org/show_bug.cgi?id=1419505 already exists for this, so this mail might just be a broader headsup! On Mon, Feb 5, 2018 at 3:04 PM, Richard Newman wrote: > As we briefly discussed some months ago, this will cause Sync devices to > collide: you'll have t

Re: Data issues with cloned profiles

As we briefly discussed some months ago, this will cause Sync devices to collide: you'll have two profiles that both believe they're FxA device 12345 and Sync client abcdef. Avoiding this should be possible by allocating a new Sync client ID, forcing the clients collection to need a sync (lastSync

Re: Syncing Bookmark Tombsones

A quick reply to this: - First, to get it out of the way, I don't think we need to be concerned about cost of keeping tombstones. However, the more we store — timestamps, states, etc. — the more we have to worry about this. Imagine that poor user with multi-duplicated bookmarks thanks to old bugs,

Re: Firefox 57 and 58 shaping up to be the best Sync releases ever!

That's fantastic. Not only the level of quality — which I'm confident *is* the highest ever — but also actually having useful metrics, and a team that cares about them and moves the needle in the right direction. I've seen some really impressive and professional engineering done by this team in th

Re: Should FxA remove support for old browser integrations?

IIRC, Sync itself still has upgrade-required messaging — if we send a 200/404/513 with soft-eol or hard-eol, the device should tell the user that they need to upgrade to continue syncing. It might be worth flipping that to soft-eol for the pre-45 population — which we can identify via UA — and see

Re: Sync-dev Digest, Vol 47, Issue 10

Let's try dev-fxacct for this question. -R On Sun, Jun 25, 2017 at 10:34 AM, Chris Tybur wrote: > Gabriel: > > Thanks for the suggestion. I was hoping to avoid having to incorporate an > entirely new way of doing the authentication, if possible. > > I should also mention that what I had working

Re: "Choose what to Sync" for autofill

> > * New engines are landed with pref defaulted to disabled. > This is a great time to point at Bug 1322428, which would go a long way towards broadening our funnel. ___ Sync-dev mailing list Sync-dev@mozilla.org https://mail.mozilla.org/listinfo/sync-d

Re: "Choose what to Sync" for autofill

> > To me, it’s a little weird to see autofill in one of my sync options but I > cannot find anywhere to use it on my phone. If we prefer to go for this > proposal, could we at least inform users that autofill only available in > desktop (for now)? > I'm pretty sure I've seen one of rfeeley's mock

Re: "Choose what to Sync" for autofill

> > It's not obvious to me when that "appropriate time" would be though; do >> users who miss seeing the option during signup have to discover it by going >> into their sync preferences, or are we considering some sort of in-product >> messaging to advertise it? > > > I believe the intention is tha

Re: "Choose what to Sync" for autofill

Bear in mind that we have 'declined' in meta/global, which is intended to support exactly this scenario. A user signing up on Android or iOS can upload a meta/global without "payments" (or whatever), but it also won't be in 'declined'. Desktop can use that hook — a locally supported engine that

Re: New Sync bug components

> > Thumbs up? Thumbs down? > > Thumbs up from me. ___ Sync-dev mailing list Sync-dev@mozilla.org https://mail.mozilla.org/listinfo/sync-dev

Re: Lifetime of an object marked as deleted on the storage server

://mozilla-services.readthedocs.io/en/latest/storage/apis-1.5.html which covers the BSO/envelope fields; objectformats.html covers only payloads. On Thu, Mar 30, 2017 at 6:04 PM, Mark Hammond wrote: > On 3/31/17 1:14 AM, Richard Newman wrote: > >> Ideally, the lifetime is "until the tombstone is wr

Re: Lifetime of an object marked as deleted on the storage server

Ideally, the lifetime is "until the tombstone is wrong" (as when an item is restored from backup). That usually means forever. See Bug 1332290 for discussion. From: Sync-dev on behalf of Gabriel Ivașcu Sent: Thursday, March 30, 2017 3:57:31 AM To: sync-dev-own

Re: Strangeness with duplicate bookmark records and reordering

or desktop have mis-duped? - Failure to delete the original server record. - Partial write. - Seeing a reconcile in progress by another client? - …? -R On Mon, Mar 20, 2017 at 9:55 AM, Mark Hammond wrote: > On 20/3/17 7:45 pm, Richard Newman wrote: > >> Did you ever run the Fennec t

Re: Strangeness with duplicate bookmark records and reordering

Did you ever run the Fennec test suite against your device? One of the test feeds is Planet Mozilla… ___ Sync-dev mailing list Sync-dev@mozilla.org https://mail.mozilla.org/listinfo/sync-dev

Re: Real world case of accounts with per-collection keys

> > If yes, how and when are they generated? > The capability exists in the format and in each Mozilla client. All clients will behave correctly if a per-collection key is introduced. Only an add-on would introduce one (outside of tests) — by default only a default key is used by Firefox. > Shou

Re: Status of desktop bookmark repair

I'm hoping for a complete diff against m-c; Part 1 is just scaffolding, IIRC, and it would be nice to see the totality of what's expected to land.  (I presume you're planning to land rebased commits rather than try to merge elm with merge commits into m-c, so a PR with that stack on GitHub would

Re: Syncing from a system extension

Replies inline. -R > Moving this discussion to the public sync-dev list since there's nothing > private about it. > Thanks, Matt. On Fri, Feb 17, 2017 at 2:44 AM, Joe Cheng wrote: >> >> >>- >> >>Can the sync engine land in a system extension? >> >> There's no significant reason why n

Re: Sharing a common device list

The original goal I was pushing for, many years ago, was for the FxA device list to be canonical: it shouldn't be as vulnerable to bugs, duplicates, TTLs, and stale records as anything a particular identity-attached service stores. When you kick a device out of your account, its Sync tabs record

Re: Best practices for data types to be synced

> > As far as form data, I think we can include it with passwords. In our > recent card sort, 42% of users grouped together Form Autofill Options and > Saved Logins & Passwords. > To drill down on this: Existing form history is actually already controlled by the *History* checkbox — it's the hist

Re: Best practices for data types to be synced

> > Any feedback are welcome. > > Thanks, > Luke > > [1] https://docs.google.com/document/d/1HsJCn5XtWKD3kWupZQ6o > XgHeEp3Dq1Z88xWSCO3weLY/edit?usp=sharing > [2] https://dxr.mozilla.org/mozilla-central/source/toolkit/components/ > passwordmgr/LoginStore.jsm > > >

Re: Best practices for data types to be synced

> > I guess it depends on how we would want to handle a conflict where two > clients changed their phone numbers (added or removed) before a sync > happened. Some methods for handling that would require more than just an > array of strings containing phone numbers e.g. timestamps. > You can make t

Re: Best practices for data types to be synced

> > Is there documentation on best practices for making a new data type that >> will eventually be synced? I'm trying to figure out a schema and storage >> backend for Form Autofill profiles (on desktop to start) and though we're >> not implementing the sync engine initially, I would like the data

Re: Improving password reset

> > I like the idea of having an encryption key that is generated randomly. > We used to do that. The difficulty was in moving it around between machines. We used J-PAKE to exchange credential bundles, but that required users to have both devices together at the same time. We used printable/savable

Re: Improving password reset

> > Great discussion. The worry I have with any stored key file is that I > suspect many of the users resetting their passwords no longer have the old > hardware. Their old one died. They bougt a new one. Signed in to their > cloud accounts, and treated Firefox like any other cloud-based account. >

Re: Improving password reset

My suspicion is that non-tech users do one of these things: 1. Blame themselves if they can't remember the answers. They remember going through the process… gosh darn my bad memory, I'm just not good with computers.2. Get the answers right (at least after trying different capitalization), becaus

Re: Improving password reset

> > Under the hood there would be a bunch of shamir's secret sharing and key > wrapping palaver to actually make things go. > You mean like wrapping the user's kB with their own kA (prove ownership of your account) plus your friend's kB (prove non-resetness of their account)? Yeah, that's a dance,

Re: Improving password reset

> > Maybe we could build an escrow service that's still in control of the user, > for example by splitting the recovery key using shamir's secret sharing and > assigning each part to a recovery step, with a threshold of 3 to > reconstruct > the recovery key. > > That's hard to do in practice, but s

Re: Improving password reset

Another little bit of history: we discussed having a 'slider' when you set up Sync, either per-account or per-datatype: * I prioritize recovery over security: keep my data if I reset my password (use kA) * I prioritize security over recovery (use kB) * I prioritize security over convenience (use "

Re: How to use kA and kB

> > What exactly are generation numbers and how are they created? > I suspect that you can ignore the details here, because you control neither the IdP nor the consumer; just know that this can fail, and doing so implies either bad input or a bug somewhere — see e.g., Bug 985504, Bug 1042109. Prom

Re: How to use kA and kB

> > This seems pretty vague though. Can anyone explain (or point me to > some documentation) how exactly are the kA and kB keys used to > encrypt/decrypt the synchronized data records? > Very loosely, you can read https://docs.services.mozilla.com/sync/storageformat5.html#cryptography and substi

Re: Improving the latency of Sync

I think it's worth separating this into at least two different problems. Sync — a shared whiteboard object store — is currently (ab)used to achieve two and a half different things: 1. Real shared data like passwords. All clients read and write the same records. 2. One-way data like open tabs. One

Re: Managing format of push payloads

Speaking at a very high level: so long as you version the protocol, version the data format, and strongly define the types in the format (none of the "sometimes a number, sometimes a number as a string" crap we have in Sync), I'm happy. Remember that users don't upgrade clients as often as we'd li

Re: Sync login suddenly not working

Looks like https://bugzilla.mozilla.org/show_bug.cgi?id=1265617 That bug should give you all the pointers you need. You should coordinate with rfkelly if you need more info for your app. On Sun, Apr 24, 2016 at 4:23 PM, Simon Grätzer wrote: > Hey, > > I recently started to see the same error m

Re: What happens if the server time travels?

> > So what would happen to clients if the server suddenly has an older > version of the data? In sync terms this would mean the last modified > timestamp is older than what a client would have gotten in a previous > response. Basically time travel. > Clients assume that server versions (née times

Re: Favicon service?

> > So I can't see why we shouldn't use the same preference (possibly renamed) > and if it in the default state, just fetch the favicons for bookmarks using > the existing favicon service. > I agree with that if we're talking about point-of-use: e.g., on display of the toolbar, go grab icons, just

Re: Favicon service?

Yes; see discussion in Bug 428378, particularly my penultimate paragraph in Comment 44. Effectively this would be building a shared special-purpose hash-keyed proxy. Doing it right would be a little more work. There's also discussion in Bug 1246076. On Thu, Mar 31, 2016 at 8:57 AM, Ryan Feeley

Syncing bookmarks

Hi folks, Figured I'd send a note to a wide distribution. We have preliminary bookmark telemetry from iOS clients in the wild. This is the first time we've been able to measure the health of users' bookmark collections: whether or not all of their bookmarks have made it to their Firefox Account,

Re: Syncing bookmarks

> > From the above I assume it still differs from the behaviour of the > currently-relased iOS version? > No, it's exactly the same — it just has all the mechanisms and storage sophistication under the hood to sync bidirectionally. The behavior will be the same as now: the client will robustly mi

Re: Entrypoint: none?

I briefly one-sided discussed this on IRC. Android's code looks pretty thorough; all the obvious entry points are annotated correctly. And even 5K here is only 150 per day, which given our number of Android users is very low — support pages/forums/user typing sounds like a good enough explanation

Re: Social media support for Sync?

CC Rachel; this seems like it's in her area of interest! On Wednesday, January 6, 2016, Ryan Feeley wrote: > Hi deep syncers, > > I have a saved search on Twitter to find people struggling with Sync. > > "mozilla OR firefox sync OR syncing fail OR problem OR error OR not" > > > https://twitter.c

Re: Sync fail help needed

> > I deleted my account, reset it up to no avail. No desktop bookmarks sync. > I have 4101 bookmarks. > Hi Thomas, If you have more than 5,000 bookmark *records* — which, if you see 4,101 bookmarks, is probably the case, thanks to folders and deleted items — then Firefox for Android will refuse

Re: Firefox Sync deleted all Bookmarks in Folders

lients in sync which each other > over the syncserver) lead to a situation where the bookmarks in subfolders > were eventually missing in both? > > > > On Thu, Sep 10, 2015 at 4:27 PM, Richard Newman > wrote: > >> I know that Firefox keeps many bookmark backups and will

Re: Firefox Sync deleted all Bookmarks in Folders

> > I know that Firefox keeps many bookmark backups and will restore them in > some cases (eg, on a corrupt places.db) - so it seems possible that > something unrelated to Sync went wrong initially and Firefox made an > attempt to recover bookmarks, which caused Sync to delete the server copy > of

Re: Self-hosted services.sync.clusterURL being overwritten

I think you might be misunderstanding clusterURL, Andrew. clusterURL is the final server that Sync talks to. It's never been a configurable option; it's derived from protocol interactions with auth servers. In old Sync, there was 'serverURL' (where you went to get a node assignment) and 'clusterU

Re: Is changing the password a way to boot unwanted devices?

It should boot other devices… but it will take several minutes for them to detect that they've been booted, because they have cached tokens. If it doesn't, and the other devices are still syncing an hour later without complaint, then something very strange is happening. On Wed, Jul 15, 2015 at 10:

Re: Seamonkey sync

As far as I can see, this work is tracked in Bug 1022319: https://bugzilla.mozilla.org/show_bug.cgi?id=1022319 The current status seems to be "waiting for someone who cares to do the work". Seamonkey is entirely supported by the community, so someone needs to step up and do it. On Sat, Jun 20, 2

Re: Windows 10 error dbConnection is not defined

Hi Rachel, I filed this about six months ago, seen in an Android test run: Bug 1120552. Most likely it means the profile directory is read-only or the database file couldn't be opened. >From a support perspective, make sure the user can read and write their profile directory. about:support conte

Re: Question about court orders and Sync data.

> > It's not quite correct that we see your private key, even encrypted; but > it's close enough for these purposes. Mozilla could be compelled to > provide information that gives law enforcement a privileged attack on your > password. If you choose a strong password, this is as hard as breaking

Re: PSA/RFC: Sync, FxA, and FHR cipher suites and protocols on Android

Landed: https://bugzilla.mozilla.org/show_bug.cgi?id=1061273#c28 shows the final change. Please file a bug and CC me if you see any problems. Thanks to Bob, Ryan, Richard, and the rest for their help. On Tue, Jun 2, 2015 at 10:07 AM, Richard Newman wrote: > This change will be landing

Re: PSA/RFC: Sync, FxA, and FHR cipher suites and protocols on Android

This change will be landing in Nightly *this week*, so if you have comments, please send them my way. On Fri, May 29, 2015 at 3:50 PM, Richard Newman wrote: > tl;dr: we're planning to switch the cipher suites and TLS versions > supported by Sync and other background services in

PSA/RFC: Sync, FxA, and FHR cipher suites and protocols on Android

tl;dr: we're planning to switch the cipher suites and TLS versions supported by Sync and other background services in Firefox for Android. If you self-host and sync with Firefox for Android, maintain a third-party Sync client, or are very interested in cipher suites, read on. *History* We used

Re: Sync recovery?

If you have an email, password, and recovery key, your previous account is "Old Sync". It sounds like you just created a new Firefox Account, which is a new system. Last I checked you can still sign in to an old account: 1. Create a new profile. 2. Set services.sync.username to any value (in abou

Re: Signin fails on Android with custom server: "unable to connect to network"

> > I can try making a wildcard cert, but if SNI isn't accepted, will that be? > I know of no reason why a wildcard cert wouldn't work. > What is the SNI issue about anyway? I do seem to recall reading a doc or > bug that dealt with this, but I can't put my hand to it now. The version of Http

Re: Signin fails on Android with custom server: "unable to connect to network"

Bear in mind that Sync on Android, being an Android SyncAdapter, doesn't use Gecko's own network stack. Adding your self-signed cert inside Firefox by browsing is not enough to make Sync use it. Try doing the same via the Android stock browser, which uses the system cert store. You also need to m

Re: Sync security question

> > Thanks, this means I will indeed be able to use Sync once my > distribution ships 34 or later. > Sidenote: if your distribution is still shipping a release earlier than 34, you should probably find a new distribution, or stop using their version of Firefox. 33 shipped six months ago. You're m

Re: Sync in Firefox OS

> > I also tend to think that the current Firefox Sync solution could be the > way to go for this kind of data, at least initially. We can start working > on making Firefox OS use the existing Firefox Sync platform for browser > related data like history, bookmarks, form autocomplete data, > reques

Re: Forced sync upgrade

Stefan, are you aware that self-hosting Sync 1.5 and the FxA stack is possible? https://blog.mozilla.org/services/2014/05/08/firefox-accounts-sync-1-5-and-self-hosting/ https://docs.services.mozilla.com/howtos/run-sync-1.5.html https://docs.services.mozilla.com/howtos/run-fxa.html#howto-run-fxa Y

Re: Old Sync account retrieval

Hi Jose, The easiest thing to do is to install an older version of Firefox, sign in with your credentials, let it sync, disconnect from Sync, then upgrade. IIRC Firefox 28 should do fine: http://ftp.mozilla.org/pub/mozilla.org/firefox/releases/28.0/ Remember to upgrade when you're done! On Sun,

Re: Sync Migration and how to pull the trigger.

> This plan is somewhat unfortunate for Android. The Android migration plan > has always been that it will only perform migration when it notices another > device has already migrated - ie, an Android device will never be the first > device upgraded for a user. Our plan to only offer migration

Re: Back-compat extension #2: clients

> Thanks for getting this done, Richard. Hopefully we can start making use of > this new metadata. I know we could start filing some bugs on our mobile > clients. For Android: Bug 1101344, Bug 1101343. bnicholson, wesj, and stefan were CCed for our other efforts. I’m holding off on filing bug

Re: Back-compat extension #2: clients

clients to tailor their iconography and descriptions; e.g., using a tablet icon for Android tablets, or showing a Windows or Mac OS logo, or showing contextual hints that are real screenshots of the appropriate device OS. Two follow-up bugs (Bug 1100722, Bug 1100723) track adding formfactor and

Re: Back-compat extension #2: clients

This is filed as Bug 1097218. An etherpad is here: https://etherpad.mozilla.org/rnewman-client-record Please opine if you have thoughts. -R On 6 Nov 2014, at 1:32 PM, Richard Newman wrote: > (For context, see > <https://mail.mozilla.org/pipermail/sync-dev/2014-October/00

Re: Back-compat extension #3: search history

> Given this, would the simplest approach to getting Fennec search terms into > Sync… To have the Fennec “formhistory" sync engine simultaneously sync to the form history DB and the SearchHistory provider, yes. There would be a small amount of data loss in the SearchHistory provider (just as t

Re: Back-compat extension #3: search history

> We do sync form history on Android -- it was one of the first things I ever > wrote as a MoCo employee. Collection "forms", only columns are "key" and > "value" IIRC. Huh, that fell out of my brain. So then… two of three platforms. > I don't understand how "the name search-history" makes se

Re: Back-compat extension #3: search history

> Isn't search history a subset of form history? > > (Bug 461820 prevented it from being saved/retrieved for web forms, but > as far as I know the storage is still shared.) You’re right, and it syncs (between desktops). Neat! Thanks for pointing that out! The downsides for this that I can see:

Back-compat extension #3: search history

(For context, see ) The “history” checkbox in Sync is an umbrella that hides two concrete engines: browsing history and form history. I’d like it to hide a third: search history. This would implement the minor part of Bug 44

Back-compat extension #2: clients

(For context, see ) The Sync 1.5 clients format is very limited: it essentially includes name and mobile/not mobile, and some version metadata that we included in 1.5 clients. I’d like to make a backwards-compatible extension

Re: Common values for ttl field

> Do I see this correctly: only history, clients and tabs get a ttl value of 30 > days? This is your best reference: http://mxr.mozilla.org/mozilla-central/search?string=_TTL&case=1&find=services%2Fsync%2Fmodules%2Fengines%2F&findi=&filter=^%5B^\0%5D*%24&hitlimit=&tree=mozilla-central Forms = 6

Re: Behavior on syncID change

> I’m building a client for sync storage 1.5 and I am wondering about the exact > behavior of a client if a changed syncID in the Metaglobal Record is detected. > Is the client supposed to drop all local data? The documentation just talks > about 'cached data’. When the syncID changes (either gl

Re: [proposal] Backwards-compatible extension of Storage Format 5

> Presumably, with this approach, if an older client overwrites the new field, > then nothing bad happens. And we eventually converge on everyone supporting > the new field as clients upgrade. Old clients will do one of three things: 1. Upload a new record that’s missing fields. New clients wil

Re: [proposal] Backwards-compatible extension of Storage Format 5

> This idea sounds great to me, but staffing levels and back logs might still > make this tricky for the desktop team in the short term. The sync migration > project is probably considered a higher priority and at the moment I'm > struggling to get even bug-fixes on our iterations. Most of the

Re: [proposal] Backwards-compatible extension of Storage Format 5

Just to flesh these points out a little for the record: > One idea we could do is partition our datatypes. We could turn off and leave > behind an old collection type (say tabs) and only sync a new replacement > collection type (tabs2 or newtabs). This is actually pretty much what bumping a c

[proposal] Backwards-compatible extension of Storage Format 5

Hello folks, As most of you know, we didn’t have time to rev the Sync storage format when we shipped 1.5. There are a swath of improvements that we wish we had[1], were planning for Sync 2.0, but never got to ship. The lack of some of this information — more info about clients (platform?), ab

Re: Paging through a collection

> Do we have an idea when we will have clients that are going to use those new > APIs? The existing clients aren’t likely to see a switch like this any time soon. 1. It’s a big (potentially breaking) change that would require different behavior for 1.1 and 1.5. Client code is currently identica

Re: Paging through a collection

On 29 Sep 2014, at 8:12 AM, Stefan Arentz wrote: > I don’t understand the logic here. Why doesn’t the client use the limit and > offset parameters to grab all history in three requests? You’re exercising an old code path that was intended for use by mobile. Nobody has stripped this out, becau

Re: own sync 1.1 with latest Firefox for Android

> I understand that it is currently not possible to connect a new Android > device with the own, old sync server. Open Android settings. Accounts & sync. Click +. Choose "Firefox Sync (deprecated)". ___ Sync-dev mailing list Sync-dev@mozilla.org http

Re: Sync-reg / FXA : Active Directory authentication

> The goal would be to at least allow users to have one password for Sync & AD. If your directory service knows the user password, or even a weak hash of it, then by definition that's a non-goal, because it would defeat Sync's ability to do end-to-end encryption. If your directory service does

Re: Hello!

> The global project include Desktop (windows) and mobile (android). Our goal > is to include SSO in as many application as it's possible. Firefox seems to > support SSO with Kerberos, but the question is does "Sync" support it too and > if not, is it possible to be close as possible to a fake-s

Re: Hello!

> So you do have something ready for large scale or at least redundancy. My > main concern is about "if my server crash ... how my users will sync". Sync isn't designed to require high availability. Clients will retry quietly if their storage server is unavailable. It doesn't even require durabi

Re: Making custom Sync configs easier

> Would an add-on approach be viable for Fennec as well? Nick, Ryan and I have had some conversations around this. I sent a rough UI proposal to Ryan a few days ago, on which I'm awaiting comments. An add-on is more feasible on Android than forcing users to modify about:config, but there are a

Re: Firefox for android Sync problem

> Hi Folks, > > i hope ive got here to the right place for that purpose... I want to > synchronize the data of the firefox on my laptop with them on my android > device using my own server. We discussed this on IRC: the user was using a self-signed cert without adding it to Android's certificat

Re: Migrate “Tabs From Other Devices” (mzsync: message 15 of 20) web to “Synced Tabs” native UX

> contrary to the old sync, tab groups and windows will be synced now, > right ? No. The underlying sync implementation is the same. We WONTFIXed Tab Groups support; that feature is just waiting to be removed from the browser. https://bugzilla.mozilla.org/show_bug.cgi?id=589336 Window affiliat

Re: Migrate “Tabs From Other Devices” web to “Synced Tabs” native UX

> On a side node: is it possible to rename Fennec devices with FXA? If there > is going to be a menu I would like to not have it read "Firefox on Evo" for > my phone. https://bugzilla.mozilla.org/show_bug.cgi?id=788688 ___ Sync-dev mailing list Sync-d

Re: Migrate “Tabs From Other Devices” web to “Synced Tabs” native UX

> 1. An Australis-friendly menu that puts synced tabs on its own that can be > positioned as other menus (e.g. History) > 2. Combining synced tabs with current tabs spillover menu, and possibly > including recent tabs from this and other devices. Bear in mind that a number of tabs-altering add-o

Re: On clocks

> 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 > complexity. +eleventy. __

Re: On clocks

Note that having perfect clocks on the server helps, but doesn't eliminate the problem. We could assume that the token server and the storage servers have the same skew, but that's about it. The issues with network transitions, restarts, client clock changes, etc. etc. all continue to apply.

Re: On clocks

> One approach we took was that the Server Timestamp is generally > distributed with every response from the server (The "Date:" header). > The client simply recorded the difference between the server and local > clock skew, and added that difference to the TS value used in the OAuth > headers. Th

On clocks

At the risk of opening this email with a pun: we've invested a bunch of time on both desktop[0] and Android[1] addressing clock skew problems. (And in server-side tests, too: [2].) Auth, token, and storage requests are all Hawk-authenticated. The Hawk authentication process bakes in a timestamp

Re: comparison with current sync and when new FxA/sync lands into (mzsync: message 2 of 20) stable firefox

> So > https://wiki.mozilla.org/Identity/AttachedServices/Architecture#Data_Security > is outdated, then. Yes. > I understand the Mozilla teams are very busy just now, but is there > authoritative documentation ? Wiki:https://wiki.mozilla.org/User_Services/Sync/Relaunch Storage: http://docs

Re: comparison with current sync and when new FxA/sync lands into stable firefox

> As far as I understand, the new sync weakens users' privacy but gives > the convenience of recovering bookmarks, history, preferences when > having forgotten the password and/or lost the recovery key. Is this a > fair statement ? No. Recoverability was an early goal that was dropped from the pr

Re: Desktop 29 bug list clean-up

>>> We do still need to implement the desktop-discovers-additional- >>> engines logic that ibarlow and a few of us discussed. >> >> Are you filing that? > > Yup, I'll do it. Filed: https://bugzilla.mozilla.org/show_bug.cgi?id=969669 -- desktop https://bugzilla.mozilla.org/show_bug.cgi?id=96967

Re: Desktop 29 bug list clean-up

>> We did not do this for Android, though it would (have) made things easier in >> both places. > > I guess I misunderstood > https://bugzilla.mozilla.org/show_bug.cgi?id=951295#c4? It sounds like > you're saying "not 29" at this point. Sorry, that was a triage closure where I only read the bug

Re: Desktop 29 bug list clean-up

> - https://bugzilla.mozilla.org/show_bug.cgi?id=951373 per-client sync > options (seems like Android made this switch, so we need to as well?) We did not do this for Android, though it would (have) made things easier in both places. We do still need to implement the desktop-discovers-additional

Re: boom headshot!

> Your decision whether to use your personal profile, but you do, I encourage > you to keep backups in case of any corruption. Of course, that's a great recommendation for Old Sync, too :P ___ Sync-dev mailing list Sync-dev@mozilla.org https://mail.moz

Re: status update: tokenserver/syncstorage production deployment

> But the more important question is, could clients with bad clocks (which is > very common i think) get in trouble here? We compute skew from failed server requests, and use that to adjust timestamps. See Bug 929066 and friends. ___ Sync-dev mailing l

  1   2   >