Master passwords are now inherently online? And q's about an upgraded install

Jack, thanks for the detailed response. Your analysis of my older machine is exactly correct, I believe (I still have a local primary vault, though it's now completely empty, all items migrated to your cloud). But still one thing's not clear. On that machine, when I unlock with my master password, I'm not providing the master password known to my.1password.com - instead, as you say, it's the master for my local vault. So... how is my local 1Pv7 client signed into your service? [Edit: 1p7 is clearly keeping a separate copy of the cloud password; when I changed the pw and opened 1p7 on the old mac, it immediately complained about not being able to log in, so I had to give it the new master password.]

When I asked about my local vaults in 1p8, I meant the local cache (hm, is that a false assumption?? I assumed you keep a local cache in case of network failures reaching your cloud. No?). However, in light of your use of SRP, while I'm still not thrilled with feeding my master PW to your javascript (as per a previous discussion, this is not quite as secure as a local native app), I will live with that, changing the new master PW to match the old one.

My comment about supporting keysplitting should be taken as a feature request, and I suggest that this should take priority, since it addresses a key security issue that 1password has so far ignored: the security of the "emergency kit". By supporting n of m keysplitting, you would allow customers to never have a single stealable document that completely reveals the contents of their vaults, while still allowing a means of recovery should the master PW and/or secret key be lost. (For those following along who don't know what keysplitting is, it's sort of like using a RAID to protect your key. You chop it, with redundancy added, into "m" pieces, but you can fully reconstitute it from fewer ("n") pieces.)