[Resending from my @chromium.com address] Peter,
Many thanks for the feedback. We are planning to use HTTPS for the sync traffic so that any sensitive information stored in bookmarks is protected when sent over the wire. Bookmarks are not going to be encrypted on the client before they are sent to the server, though. We are aware of the fact that passwords and other browser data types is something we'll need to think about at some point. We wanted to focus on bookmarks and get it right first before we think about other data types. We chose bookmarks both because they are generally the most important to users, but also because they are the hardest data type to sync since we have to sync an entire hierarchy of folders/bookmarks and there are tons of difficult edge cases involved in doing that (e.g. what happens when two changes from two different clients result in a loop in the bookmark hierarchy). On Sat, Aug 1, 2009 at 5:46 AM, Peter Petrov <[email protected]> wrote: > > This sounds really awesome. Especially being based on XMPP - this goes > one step further than Mozilla Weave, which uses polling (but is > otherwise a great project). > > I have one question, which I didn't see answered in the design doc. > Will the data be encrypted client-side? This is a must for passwords > synchronization (which is the most useful sync type for me > personally). And is password synchronization on the roadmap at all? > > - Peter > > On Aug 1, 12:07 am, Tim Steele <[email protected]> wrote: > > Hi! > > > > A bunch of us have been working on a feature to sync user data in > Chromium > > with a Google account. (Surprise! :)) The great news is that we'll be > > starting to work directly in the Chromium project this week, and let me > tell > > you, are we excited to do that! This email discusses how we're planning > to > > get started, in detail (maybe too much detail... sorry). > > > > We have built a library that implements the client side of our sync > > protocol< > http://sites.google.com/a/chromium.org/dev/developers/design-document...>, > > as well as the Google server-side infrastructure to serve Google Chrome > > users and synchronize data to their Google Account. Of course, all the > code > > going into Chromium is open source, and the messages between the client > and > > server use the open protobuf <http://code.google.com/p/protobuf/> format > and > > library. Check out the sync developer > > page< > http://sites.google.com/a/chromium.org/dev/developers/design-document...> > > if > > you're interested in low-level goals and technical details. > > > > We will be landing this code in a few steps rather than one giant > changelist > > for a number of reasons. First, this makes reviewing a *lot* easier; it > > isn't the most straightforward code by nature, so the more fine grained > > scrutiny the code gets, the better. Second, we've been working in a > > proprietary environment until now because of the dependency of having to > > build the complementary Google production server environment for syncing. > > As such, the code uses a small number of internal libraries that we need > to > > open-source or replace, as well as libraries that would be redundant to > what > > Chromium already includes. Removing these, and open sourcing the entire > > sync engine, is our highest priority and we expect this to take about > three > > weeks. > > > > So how will we commit the code in pieces and not totally hose the build > in > > the process? First, a little more background. You may have come across > the > > CHROME_PERSONALIZATION #define when digging through Chromium source code. > > Right now, this is used in conjunction with a relatively small number of > > private c++ source files to conditionally build Chromium with sync > enabled. > > These files are in fact a glue layer between Chromium and what is called > > the "syncapi", which is the bulk of the client library I was talking > about > > above. On windows, syncapi is built into a DLL, and when > > CHROME_PERSONALIZATION is defined this DLL gets placed alongside > chrome.dll > > for use at runtime. Syncapi builds and runs on Linux, but not Mac (yet). > > > > With the initial checkin, we will leave the CHROME_PERSONALIZATION > #define > > as-is, so the sync code will not be built by default. We'll be working > hard > > over the coming weeks to make sure the code passes all existing test > suites > > that are part of the regular buildbot cycle, and on removing the #define. > > After that, our hope is that we will be free of the DLL altogether and > have > > all the code checked in to the repository, fully functional or not, in a > few > > weeks. We do *not* plan on ever checking in the windows-only syncapi dll > to > > the main chromium repository. So until the dll is no longer needed, the > > public repository won't have all the bits to actually build Chromium with > > sync enabled. That said, we want to keep the sync build running > smoothly, > > so we will use a combination of command-line flag (to enable sync) and > > delay-loading syncapi.dll only when it is needed. This will allow the > > "glue" code to compile as part of the normal Chromium build without > > introducing a dependency on this dll, yet still make it possible to run > with > > the dll present. > > > > On that note, we're planning to use the syncapi DLL to produce a > > sync-enabled Google Chrome build for dev-channel users in a week or so, > to > > get the feature into experimentally inclined hands. We have a great deal > of > > infrastructure, both in the browser and in the form of production Google > > services, that need to start seeing real user traffic and usage. It > takes a > > great deal of testing and confidence inspired by real usage statistics > > before any complex system like this can be deemed adequate for use by a > > large user base. So if we want to let all Google Chrome users use sync > (and > > we do! we do!), we've got to get started on this pronto. > > > > Our developer page< > http://sites.google.com/a/chromium.org/dev/developers/design-document...> > > also > > covers the hierarchy of files we're landing that you can expect to start > > syncing (in the gclient sense) down in the next couple of days. We can't > > wait (*really*) to work on this with the rest of the Chromium community > and > > going even further in creating the best browzr ever! > > > > Thanks for reading, and happy syncing! > > > > - the cloudy bunch > > {idana, nick, nickbaum, chee, munjal, brg, chron, zork, laforge, > tejasshah, > > tim} at chromium.org > > > -- -Idan --~--~---------~--~----~------------~-------~--~----~ Chromium Developers mailing list: [email protected] View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~----------~----~----~----~------~----~------~--~---
