I've set up sync on fennec many times. It's not so great. Here's a random idea that would improve the process for me (1) Click "Add a device" on host (2) Generate QR code under normal key (3) Read QR code with handheld camera (4) ??? (5) Fennec frontend sets up sync with key encoded in QR code 1-2 seem pretty straightforward. 3-5 is a bit more involved. I think ideally 3-4 would be done from within fennec, but that requires camera support in chrome:// and a QR decoding library. It'd be nice to let a built-in QR code reader do the hard work for us, but I'm not sure how we could securely get the decoded key from the reader into fennec. The thread is, if we somehow URL-encode (or whatever else) the sync key, then another app could register to handle that MIME/intent/... type without the user necessarily knowing it. So that evil app could set up sync and steal all the user's private data. Personally, I would be happy with a scheme that encoded the key in such a way that a web browser would be opened to handle the QR-code payload. (An app that a user trusts enough to browse the web will already have a shot at accessing all the sensitive data in a sync profile, passwords etc., when the user types them.) If the browser didn't understand that the URI referred to a sync key, then we should do some trickery to make the fallback display an ad for Firefox/Sync or something. data: URIs seem like just the trick but I don't know if QR-code readers know what to do with them. Not sure if I filed this in the right place, please let me know.

I closed this because I hadn't set up for sync for so long (good thing!) that I forgot the key goes from new->existing. Whups! IMHO this is most useful when new==phone and existing==laptop/desktop. As Brad notes, there are solid use cases for new==laptop/desktop, existing==phone, and in fact the fennec UI is the only one that can't grant access to other clients. So reopening for those use cases.

The second use case you've brought up is bug 647476.