Update on yesterday's Chrome contacts post
Here are some updates on yesterday's post about Chrome requesting access to contacts and Mountain Lion flagging it.
I got an anonymous comment pointing me at bug 139154, so clearly they are aware of it. The bug doesn't shed any light on why they're calling into that part of the system, however. Thanks for the feedback, anonymous tipster!
So then, earlier this morning, that post was submitted to Hacker News, and the first useful comment provided a link to the Chromium code depot. That plus a subsequent comment suggests they use it for the user's own information, presumably for filling in forms.
It turns out that I don't want Chrome to know that stuff about me, or my contacts for that matter, so I'll be leaving it blocked. Even for the form-fill scenario, I would prefer that a browser explicitly ask for each thing it wants to know about me, and then I could either tell it an approved, sanitized version of things, or just reject it entirely.
This reminds me of the first time I used the "share contact entry via SMS" feature of my iPhone with a friend shortly before leaving that place in Mountain View. It turned out that I sent her the whole nine yards, including all of my phone numbers, address details, and so on. Obviously, in that case, having her have that data was no big deal, but imagine if it had been some random business meeting! That's far too much tasty info to give out to just anyone.
Finally, there's an update regarding https posts here. The post as submitted to HN used the https variant, and while I explicitly support and encourage use of https://rachelbythebay.com/ URLs to view stuff here, I had made a mistake. In generating these pages, I was building IMG SRCs and such with a hard-coded "http://" URL scheme. This was causing "mixed content" security errors.
This has been fixed to use the neat "//rachelbythebay.com/" construct, so whatever protocol you use to ride in should also get used to fetch images now. Sorry about that.