Sunday, September 05, 2010

Better Spotlight in 10.6: search current Finder folder and more

This is new in 10.6. I just read of it. For me it's one of the very best things about Snowie ...
TidBITS Problem Solving: Find Files More Easily in Mac OS X
... you can restrict Spotlight to search the current Finder folder by default, instead of This Mac. To do this, choose Finder -> Preferences, click the Advanced button, and choose Search the Current Folder from the pop-up menu. From then on, when you invoke the Finder's Find command by choosing File > Find (Command-F), searches will be limited to the current folder showing in the frontmost Finder window....
The search window in the Finder menu will also default to searching the currently selected folder.

Drives me crazy that the best features of 10.6 are bloody secrets.

Now if I could only search by file name instead of all contents...
... you can make sure the Search bar at the top of the Finder window is set to File Name without requiring an additional click. Hold down the Shift key, and choose File > Find by Name (Command-Shift-F). This command is available in both Mac OS X 10.5 Leopard and 10.6 Snow Leopard...
Auggghhhahaha! Now they tell me. I just did it. It works.

Wow. Search scoped by folder context, default to file name.... It doesn't get better than this. If only this were the default behavior ...

Yeah, search by file name can be mapped to Cmd-F -- but it requires a logout and login to work. You can also tweak the search results window layout and add a "Last Modified" column to the list view. Please read the original article and send TidBITS some love.

Oh, one last thing. Suppose you've done all of the above but you want to restrict your search to only folder names and modified after 1/1/2010. That looks like this:
kind:folder date:>1/1/2010
Yes, you can use the same sort of operators with Spotlight that you can use with Windows Search. Alas, they aren't identical, so if you do both you are more or less doomed. (I was wrong, they do overlap.)

These operators are usually described as "undocumented", the including in this excellent 7/10 CNET article. That article gives us examples like:
"Apple Computer" kind:pdf OR "Apple Computer" kind:text NOT (Google OR Yahoo OR "Microsoft Corporation")
In fact in 10.6 these features are documented in the little known OS X feature known only as "Help". (It's still not as good as Windows Help, but it no longer sucks.). Search Help on "Spotlight" and look for these Help articles:
  • Performing a Boolean or metadata search
  • Searching for specific types of items
at 1 comment:
Labels:

Saturday, September 04, 2010

My Google (gmail) account is hacked - by ductus.com

9/20/10: I've updated this post to fix some errors. For example, I originally misread whois and thought tucows owned the hacked domain, they are the registrar. My longer term evaluation and responses are in a separate post.

My Gmail/Google account has a robust password. So this notice surprised me:

It showed up when I connected to Gmail. I was told my account had been accessed from an atypical location 1 day ago. The next thing I saw was that it was accessed from ductus.com (WA, IP 63.83.70.14), a domain that belonged to a software company in the 1990s. [1]

I followed the advice and changed my password. I looked into my Google store account but didn't see any new transactions or sent email.

After my password change things got a little odd. My new password wasn't recognized. I had to do a password reset (fortunately I'd followed Google's password reset advice). That worked, but it's like going to the reserve parachute. It's a very bad thing. Not to mention that I now need to change my stored Gmail/Google password in about 30 places.

Clearly something bad is going down.

The best answer is that this is a false alarm. That's bad enough.

The less best option is that either my Google password has leaked or Google has a global security issue. A dictionary attack wouldn't work on my prior password; I don't change my Google password very often (like most security professionals), but it's a robust non-word five letter four number sequence. (Now, of course, every string in my 58,000 + emails is potentially part of a dictionary attack. I will eventually need to change every password I and my family use.)

Assuming my Google password leaked, how did that happen?

I don't store my Google password with online services, but I can't rule out a leak from an old forgotten online account or a wifi intercept. I very rarely log-in on public sites, but I do log-in from work. My employer could certainly be logging my keystrokes, but it is very unlikely that my large corporate employer would take the risk of hacking my Google account via an abandoned domain (though HP did do something like that to its board members). On the other hand, we do get virus infections every few months, and I don't think we catch them all.

I do store my Google pw in several iPhone apps. Any of those could steal that password but they are all pretty high profile apps.

For now I'm redoing all my passwords everywhere. This will take weeks, but I'll start with the highest security sites. I discuss the implications and possible attacker profile in a later post.


footnotes

[1] Ductus was a company in 1998:  "Ductus, Inc. is a Mountain View, California-based company that develops and markets 2D graphics software and hardware http://www.ductus.com". So this domain was abandoned.

See also:
Update: If Google doesn't limit the number of login attempts, then my old password would be vulnerable simply because it was only 10 characters. That will fall to a brute force attack. Interestingly I can't locate any documentation on this. From my own testing I think the first time you access Google from a new location you have to enter a CAPTCHA as well as a password. If the password fails you keep getting a CAPTCHA.

Update 9/14/10 - useful links
at 4 comments:
Labels: , , ,

CrashPlan Fail - you still can't remove an account

Is it obvious how to delete your account and all data and services?
This rule is always important, but it's critically important for a Cloud backup service. Do you really want to forget or lose control of a complete backup of all your unencrypted data?

CrashPlan failed this test, and others, seven months ago. Back then, during a trial period, I had my backup data on their servers. Their FAQ then didn't describe how to delete it.

I was later told you could delete it by logging in to the CrashPlan account web site, then choosing CrashPlan Central -> Destinations>Online, then selecting "Remove Backup Destination". There was no way to remove an account however.

Today I checked. My account still remains, but now that the trial period ended I don't see an option to remove my data from their servers. Perhaps the data is gone, or maybe if I paid up I'd see it reappear. I wouldn't be surprised by either option.

There's still no way to remove an account from the web site. I also noticed that "My Profile" includes "Receive promotional emails from CrashPlan.com". Hell freezes over the day I opt-in to promotional emails, so that was a sneak play.

CrashPlan is on course to crash landing. When they go into receivership their creditors will own your data. Creditors who need to recover some of their losses.

Update: See comments from CrashPlan. They tell me the data is likely overwritten, and is not recoverable after the promotional period ends. They have no plans at this time for an account removal feature, that requires email (seems a risky practice). Maybe that will change. Comments underscored the importance of client-side encryption.

See also:

at 8 comments:
Labels: , ,

VMware Virtual Machines - the backup problem

It's times like this that I really miss Byte (or BYTE?) magazine. They would have had great coverage of VMWare VMs - how they work, and what the risks are. Now that's specialist knowledge. Knowledge that, when I use Google, is obscured by a haze of marketing material.

The best we non-specialists can do is share our limited experience in blog posts, like this one sharing my experience with VM backup. That's been a problem for me.

First - my experience. I've used VMWare Fusion on my Macs for a few years. I need it less than once a month, typically to launch XPSP4 and run Access or (yech) Quicken. On the other hand, I configured and use a VMWare Workstation on a 64bit Win7 machine at work. That VM is running a Windows 2003 Server environment with terminal server and I use it very frequently.

Both my Fusion and Workstation VMs are configured to store the VM data as many files rather than a single monolithic file. Both are about 80-100 GB in size and store as little of my data as possible; on the Mac the individual .vmdk files vary in size from about 200 to 500 MB. I don't have the Workstation VM at hand but I think its files are all a fixed size.

The host OS X machine is backed up using Time Capsule (sigh) and SuperDuper! (sigh). Neither give me the warm fuzzies of Retrospect at its best. The Windows 7 machine is backed up using (Dantz -> EMC -> Roxio) Retrospect Professional.

I configured both VMs to use multiple files because of the VM backup problem I knew about.

The obvious backup problem for these machines is that if you configure a VM as one monolithic file, then every time you touch it the host system backup software has to backup a 100GB backup event. That will overload Time Machine (Capsule) or Retrospect pretty quickly. (More sophisticated backup software can manage this differently, but I don't think TM or Retrospect can.)

That's why I went with separate files. Backups would only have to manage the files that changed. (Ahh, but how does the backup software know what's changed - esp. if the files are a fixed size?)

I think that approach does work when the VM is shut down. I think it works on my Mac. It doesn't work with Retrospect Professional on the Windows 7 machine where our VM is always running.

I learned that the hard way when we tried to do a restore. The restored VM seemed good at first, but it was soon clear that we'd somehow ended up with different time slices. We had to kill the VM. Fortunately, because I'm justifiably paranoid about backup, we also had a file system backup that was only a few weeks old. Since we don't keep data on the VM we lost very little.

This is a nasty problem. As best I can tell, at least on Windows, Retrospect Professional can't do a reliable backup of a running multi-file VMWare VM. The limited VMWare marketing material I could find suggests this isn't just a Retrospect problem. The solution is, of course, to buy their costly backup software. You can also do backup from within the client OS, but that adds a new level of cost and complexity to overall backup. Retrospect Professional, for example, won't install on Windows 2003 server. For that you need their much more costly server backup.

Now you know what I know. If you know any more, or can point me to anything that's not marketing material, I'd be grateful.

I do miss Byte.

--My Google Reader Shared items (feed)
at 1 comment:
Labels: , , ,

Saturday, August 28, 2010

Transferring the mnspecialhockey.org domain - what remains of Google Apps

The last step of the mnspecialhockey.org migration took place at DreamHost. The provide an optional mixed hosting service. I had some files in a traditional ftp site on a DH server, but also Gmail and Google Apps via Google.

From their control panel I turned off the Gmail and Google Apps connection. (See the posts list below for my prior action).

Then, since DH was also the registrar for mnspecialhockey.org I switched to the new DNS servers. I'll update this post if I learn what really happens to the data that was at the old site.

See also (note, some are old)!
Update 8/29/10: After the transfer

The mnspecialhockey.org domain now points to a new site. What happened to the old content?
  • sites: they still exist! The URLs are of the form: http://sites.google.com/a/mnspecialhockey.org/sites/system/app/pages/meta/dashboard 
  • docs: they still exist! The URL is of the form: http://docs.google.com/a/mnspecialhockey.org/#all
  • mail: it still exists for my account (I removed the others) with URL: http://mail.google.com/a/mnspecialhockey.org/?tab=om#inbox
In fact, I can still manage the domain using the URL

https://www.google.com/a/cpanel/mnspecialhockey.org/Dashboard

So I have, at least for the moment, answered the question about what happens to Google Apps content when the original Google App Domain is gone. Turns out, it persists. Even the Domain settings persist (Google Apps thinks the domain is still mnspecialhockey.org, even though it no longer references this site).

If this remains true, it shows there's only a loose coupling between a domain-associated Google Apps suite and the domain itself. 

That's rather nice to know. It's not completely surprising however.
at No comments:
Labels: ,

Closing a Google Apps domain: document liberation and more

I'm closing down a Google Apps domain because the domain name is moving (donated) to a new owner. Since I don't know what happens to the data after I transfer the domain name I've so far:

My next step is to get a local copy of all the documents. Again, the DLF has directions. This turns out to be built into the Docs framework. On export you can specify a file format, I chose RTF for documents, Excel for spreadsheets, and native for the rest (PDF).

I also made sure so share all the documents with my personal account, but I wasn't able to transfer ownership. Currently that's not supported in Google Apps.

We had the non-profit version of Google Apps (free from Google) so we had all the yummy pro features, like the ability to associated a secondary domain. I have some I could use and I considered doing that to provide a way to access data post transfer, but I decided to skip that step in the interests of time.

at No comments:
Labels: ,

Closing a Google Apps project: downloading sites

When MN Special Hockey signed up with a web hosting project, I needed to transfer the domain.

The domain was managed through my Dreamhost (love 'em - click here to evaluate my discount on their ISP services) accounts. There it has associated Google Apps services. I really didn't know what would happen to the account data when I switched away the host name, so I decided to see what I could backup.

Naturally I turned to Google's Data Liberation Front - my heroes. They provide a Java app for this purpose. It can allegedly be used to move a site from one location to another! 
Sites - the Data Liberation Front
A site can be downloaded using the open-source tool available at the Google Sites Liberation Project Page. Note that this tool requires Java 1.5 or later. Once the tool has been downloaded, double-click on the JAR file to launch the application. 

It opened easily on OS X 10.6.

You will need the documentation. Instead of www.mnspecialhockey.org (didn't fit their model) I tried sites.mnspecialhockey.org and I found two sites to copy:
  • http://sites.google.com/a/mnspecialhockey.org/www/
  • http://sites.google.com/a/mnspecialhockey.org/mn-special-hockey-site/
From their documentation I think the values are:
  • host: sites.google.com (optional)
  • domain: mnspecialhockey.org (optional)
  • webspace: www and mn-special-hockey-site (two webspaces)
There's an option to download revisions, but I didn't care about that. I was fine with the latest version.

It worked, but the result was not pretty! Without style sheets it renders poorly in Safari, and  some of the character encoding was off. Still, the bulk of the content was there including associated PDFs that were a part of the site.

The Java app is pretty simple. You have to quit and restart to do a second site. Still, did I mention it worked?
at 2 comments:
Labels: ,
Subscribe to: Posts (Atom)