Open 1Password Logins from LaunchBar or QuickSilver

This is a Ruby script that will export your 1Password bookmarks as an HTML file with each login as a link that will auto-fill your passwords. This file can be indexed in LaunchBar as a Bookmarks file (or in any other launcher that can index a file of URLs) for easy login to your indexed websites. Run this script on a scheduled basis using your favorite automation software, tell LaunchBar to index it as a bookmarks file, and you’re on your way.

Usage is fairly simple. Just run the script along with the path to your keychain file and the path to your bookmarks file. For example:

ruby agiletohtml.rb “/Users/me/Dropbox/1Password.agilekeychain” ”/Users/me/Documents/1PasswordBookmarks.html”

Bookmark the Shit out of It

I have begun to wildly and indiscriminately bookmark my online life and jam it into Evernote. The results have been fantastic: I now have the Internet (insofar as it’s relevant to me) synced up across my computer and my phone. Wifi out? No problem, my favorite nineteen Wikipedia articles are right where they’re supposed to be! Forget a website I visited? No need for browsing history, if it’s even remotely interesting, it’s probably in Evernote already. PDF reports from vendors and agencies? Yup, they’re in there, too.

My biggest tool in this regard is IfTTT, which I’ve written about before. It carefully pushes my Twitter, Facebook, blog Google Reader faves, and Instapaper archives into Evernote (and these are probably the best indicators of stuff I find interesting).

Is this good for you (or for me)? Maybe, or maybe not. It’s made searching Evernote a challenge (I’m working on sorting that out), but it’s still entirely functional. I wish (a little), that I could use something like EagleFiler to handle this, so that it’s just a little less proprietary, but with Evernote’s extensive API, it seems like I’m at least fourteen hops, six skips and eleven jumps away from disintermediating Evernote, should I want to at a later time.

Hacked (again)

Once again, this site got hacked. A lovely lesson in why you need to keep all your CMS stuff up to date and otherwise keep things secure. Now that I’m spending less time sysadmining, I haven’t been as diligent as I probably should have. So, while this all gets sorted out, things will look a little strange and I’ll probably be missing some features. I have a number of sites to get back up and running, so this may take a little while.

Maybe it’s time to give up on my own CMS and move all of this to a hosted blogging platform.

Cookiegate

Jonathan Mayer, a diligent researcher, discovered that Google is bypassing Safari’s third-party cookie settings. This has put Google in a bit of hot water, since this seems like a clear-cut case of ignoring how users want their content to be managed.

But the problem actually lies with Safari, which has known flaws in its security model for how it manages cookies. Once a site sets cookies, Safari will grant access to those cookies, regardless of changes to your cookie security settings.

This is very easy to demonstrate. Make sure that cookies are enabled in Safari, and log in to Facebook. Once logged in, go to your privacy settings and block ALL cookies. Close the window, open a new one, and navigate back to Facebook. You’ll see that you’re still logged in.

Now try this same trick with Firefox. You’ll find that as soon as you disable cookies, Facebook logs you out, because Firefox denies Facebook access to the cookie immediately.

As for Google’s (and others’) work-arounds to Safari’s active cookie policy, these exploits have been well documented for over a year, and totally ignored by Apple.

If you’d like to experiment, I’ve set up a test page: cookietest.html

This page uses the embedded buttons for common social networks, every one of which relies to some degree on being able to post and access cookies on your computer. Try visiting the page with Safari and your other browsers and see how they manage cookies depending on your settings. Every single social plugin will load and operate properly if Safari has logged in to the individual sites before visiting the page, even if you subsequently deny third party cookies. Chrome and Firefox work properly, and deny access to these cookies as soon as you set your preference to block them, whether or not they’ve already been set.

There is another odd behavior which is that Safari will let sites set cookies on the initial visit, even with cookies blocked. These cookies seem to be inaccessible to the site that set them, but the cookies are still stored. Very odd behavior.

Apple has a pretty poor track record in keeping up with security problems, especially in Safari. As much as Google may be at fault here for using this exploit, Apple’s cookie implementation is sub-par, and shows that Apple cares a lot less about their users’ privacy than they claim.

Mountain Lion: Initial Thoughts

Apple’s released the first look at MacOS X 10.somethingorother, “Mountain Lion.” Like Lion, it’s a further adoption of iOS technologies at the desktop. Unlike Lion, these adoptions are more than skin deep. Mountain Lion becomes a peer device with your iPad and iPhone. Whether that’s a promotion or demotion of the status of the Mac in your digital life is certainly debatable.

First off, there’s all the new apps. Bringing iMessage into a new iChat replacement, a better to-do manager than iCal’s half-assed handling of the same, and Notes taking on the best of the old Notepad desk accessory and Stickies looks great. Even if I’ll never use most of these things, since I already have half my life in OmniFocus and Evernote, they’re still fine additions.

But then there’s iCloud and Gatekeeper.

Gatekeeper is the most immediately controversial. It simply controls what applications are allowed to be installed, sort of a user security policy. If you want to be able to install applications that are made by developers who have not registered with Apple, you’ll need to change a setting. While this is billed as the “middle ground” between App-Store-Only and the current wide-open standard, I think that misses the point that in order to be able to easily distribute apps, you must register with Apple first.

Next, we have iCloud. Keeping all my files sync’d up across all my Macs without any hard work sounds great. I love DropBox and ChronoSync, and making that system level sounds zippy. Well, except that lots of apps won’t support it at all, especially all of the ones that won’t be distributed through the MAS, which will thereby be ineligible for iCloud.

Not so trouble free, is it?

And in either case, I’ll need to register with Apple, because iCloud’s become a necessity, not the really-just-a-payment-method AppleID of old.

Basically, Apple’s pulling a Google here. They’re taking more and more data on its developers and users, and taking more and more of its consumers’ digital stuff onto its own servers.

This is, I’ll admit, a little alarmist. They’ve always asked for product registration, and an AppleID is pretty much a must-have and with XCode’s distribution on the MAS, a requirement to be a developer. But it still shows a level of personal-level control and management that Apple’s never taken on before.

Pages

Subscribe to Nik's Blog RSS