Showing posts with label Google Apps. Show all posts
Showing posts with label Google Apps. Show all posts

Tuesday, February 27, 2024

Extracting core concepts with ChatGPT 4 from OCR of scanned sample examination PDF - Feb 2024

I think this is an interesting example of what works and doesn't work on the personal AI front in early 2024.

My son was given a printed practice exam in microeconomics. I wanted ChatGPT 4 to extract and summarize the core concepts. This turned out to require two steps, one of which only worked with Google.

Step One: OCR and download text file

I scanned the document in ScanSnap and produced a scan PDF. I tried getting ChatGPT to do the OCR but it abandoned that task. I then tried Gemini and it told me it didn't do OCR. Next I tried Microsoft Lens, but it seemed to only do OCR from a local image, I couldn't see how to use it with a OneDrive PDF. ChatGPT claimed that I could open a OneDrive PDF in Office 365 Word but that did not work with the web version (perhaps it works with full Word?). ChatGPT did not know of a way to do PDF OCR on Sonoma.

The only thing that worked was Google Drive. It allowed me to open the PDF in Google Docs and then export a .txt version.

Step Two: ChatGPT 4 analysis

I asked ChatGPT 4 to extract the key concepts from the .txt file. It provided a plausible set and then proceeded to answer some of the exam questions. Concepts captured were:
... equilibrium price, consumer's surplus, producer's surplus, total surplus, efficient output levels, negative externalities, deadweight loss (DWL), price ceilings, and the impact of taxes on market outcomes ...

I don't think it added much to the textbook chapter topic loss but it did provide a plausible set of topics to emphasize in my son's studying. I was primarily interested in the workflow today. It will be interesting to look back on this in a year and see what's different.

Tuesday, January 09, 2024

Google Account without Google email that routes email to a Google Workspace address

My son has an email address of the form tim@familyname.com where familyname.com is a pseudonym for a domain I own with legacy free Google Apps (now Workspace) accounts.

He also has a Google Account with the Google Account ID of tim@familyname.com. I think he created it somehow with YouTube. (He has a cognitive disability which doesn't stop him from doing some weird shit I can't figure out.)

His second Google Account does not have the email address of tim@familyname.com because that belongs to the Google Workspace account. Instead of it has an email of the form: tim%familyname.com@gtempaccount.com. If I send email to that gtempaccount.com address it redirects to tim@familyname.com.

This feels like a security risk waiting to be exploited. It certainly is weird. It reminds me that Google Workspace accounts don't have the same meaning and privileges as full Google @gmail.com accounts.




Monday, March 13, 2023

Google Apps (Workspace) email failing? How to check DKIM and update in your DNS settings if needed.

When I travel every bit of IT in our family starts to malfunction. On a recent trip this included Emily's emails, they were intermittently rejected by Gmail recipients. Once I was home I had to dig up old knowledge; I found the answers in prior blog posts (see references below). It looks like something wiped out our Dreamhost DNS DKIM records a few weeks ago [1]. 

It's hard these days to do email with anything that's not full hosted on the big three.

The refs have more detail but here's the outline of the process:
  1. In Google Workspace - Apps - Gmail - Authenticate email get the DKIM text value. You will probably have to generate a new record.
  2. In Dreamhost control panel manage websites click on DNS settings for domain and enter google._domainkey as host and the TXT record value. (DH UI makes this look like it appends a suffix to this but it really doesn't.)
  3. Once DH says the record has propagated return to the Admin console and click "start authentication"
It can take 48 hours for this to fully propagate but a few minutes after adding the key it did work when I validated as below.

To see if DKIM is working follow the process Google outlines (Usual automated testing services don't work with the way Google Apps do DKIM -- the selector won't work):
Send an email message to someone who is using Gmail or Google Workspace. (You can't verify DKIM is on by sending yourself a test message.) 
In the message header, look for Authentication-Results. Receiving services use different formats for incoming message headers, however the DKIM results should say something like DKIM=pass or DKIM=OK.

If the message header doesn't include a line about DKIM, messages sent from your domain aren't signed with DKIM.

When I looked at view original sent form Emily's account to my personal gmail account I didn't see DKIM=pass or DKIM=OK but I did see two entries starting with:

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;

X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; 

More importantly when I scrolled up a bit (this is in Gmail View Original) I saw a header that's interpreting the email headers (I think this might be a newer feature):

Message ID ....

Created at: Mon, Mar 13, 2023 at 2:59 PM (Delivered after 12 seconds)

From: Emily ....

To: John ...

Subject: test DKIM content

SPF: NEUTRAL with IP ...

DKIM: 'PASS' with domain ...

You can also paste the "original message" headers into toolbox.googleapps.com/apps/messageheader/. That gave similar results.

When I tested on a second family domain that did NOT have DNS TXT entry for DKIM it showed as DKIM 'PASS" in the email header interpretation with an odd domain string -- BUT in Google Apps it showed as NOT authenticating. I cannot explain this. 

Once I updated the DNS TXT DKIM entry for that domain and allowed a few minutes for propagation it did show in the Google Apps admin console as authenticating with DKIM and the headers showed the correct domain name.

DH's note on SPF records says they cannot be updated if we are using Google Workspace. This is new since 2018 and I think that's correct.

- fn -

[1] Eons ago every Dreamhosted domain had a free option to add Google Apps (now Google Workspace). That went away and earlier this year Google said they would discontinue the legacy free Google Apps. That was a thrash but on the edge of doom Google relented. I figured a DH script wiped the records but their first tier support said they hadn't done anything and instead referred to Google automated scripts that might change their DNS records (!).

- refs -

Sunday, May 15, 2022

How to leave Google Apps / G Suite / Google Workspace

UPDATE: As of early May 2022 Google has relented and will allow continued personal use of legacy G Suite domains. You need to login to your domain and then use this URL. (The option is described, a bit obscurely, in a support page).

<background>
It's hard to remember now, but there was a time that geeks had some affection for both Google and Apple (but, TBH, never Microsoft). Those were the glory days my friend.

This year's bitter resentment is brought to you by Google ending free Google Apps services. Back in the glory days Dreamhost bundled these with domains, I picked up 7-9 of them. Two of these Google App domains have been heavily used by my family. They are the core of a wide range of daily things we do, including email addresses association with numerous logins, credentials, passwords, and so on. (But not with Google OAUTH identity services, that is not supported for Google Apps email addresses.)

A few months ago, in early 2022, Google told us that these services, once as permanent as gmail (*cough*, they're coming for you), would become quite expensive. For us the costs to maintain our current setup would be hundreds to thousands of dollars a year. Shortly after this announcement we were told that there *might* be a reprieve, that non-business services would continue. This false-hope was never officially withdrawn, but in May 2022 it has been replaced by a bizarre offer to maybe continue but, like, without email or domain?

Google's very limited online guidance does not review how to exit Google Suite. In email communications they mention a 'suspended state' but do not describe what that means.

So now I have to spend several lovely days in May sitting at my computer trying to salvage our digital identities. We will clearly have to pay for at least one of our domains - principles be damned. Charges begin Aug 1, 2022. </background>

The following is a rough guide to what I will do. Much of this requires knowledge from decades ago that I'm having to refresh.

Considerations and discoveries

  1. It's difficult to move IMAP emails between services. IMAP emails can be copied to a local store. In mail. app I've had success dragging and dropping emails from one IMAP inbox to another, but I believe this is fragile and unreliable. You can also copy, see this iCloud example.
  2. Local store email is barely supported any more. Mail.app, for example, 
  3. My domains are managed by Dreamhost which does provide some classic web services though fewer than it once did.
  4. Domain based email forwarding is fragile -- many services including google will reject it. See DKIM notes below.
  5. Modern email is both essential and a river of spam and Google has good spam filtering (though it was better once)
  6. The knowledge of how to manage DNS settings is more esoteric now than it once was, and Google Search no longer works.
  7. My Dreamhost DNS and mail forwarding has lots of old detritus. That's on me!

References related to closing Google Workspace accounts

  1. Microsoft on switching to Office 365 - cancel subscription
  2. Fastmail also has switching options, but price not much less that Google Workspace
  3. Google has not provided any migration guidance.
  4. You close your account by canceling the subscription: https://admin.google.com/ac/billing/subscriptions/ then deleting the account (see below).

References for migrating to Dreamhost email services

  1. Dreamhost email client configuration
  2. The Dreamhost custom MX config panel has 'uses Gmail' management links that take you to Google admin (so not terribly useful but at least can tell what to change.
  3. Dreamhost used to support both a mailbox and a forwarding action but you can't do that any more (still works for old settings). Dreamhost uses Roundcube Webmail but has not enabled forwarding in that app. You can use forwarding directly from a domain but I think Google treats emails forwarded this way as spam. (At one time we were supposed to have had quite large storage caps with Dreamhost, but I think email overwhelmed them. Similar to the days our Gmail storage was to be unlimited.)
  4. A comment on this post mentioned imap sync for moving email: "For transferring IMAP email, imapsync works well. There's a free version you can download and run on your computer (or on your hosting provider if you have ssh access). It's well documented and relatively easy to get your head around, and is fast and reliable. I’ve not got any affiliation, but someone pointed me to it a couple of years ago, and I’ve since used imapsync to migrate email hosts for a small organisation. Highly recommended."

References for migrating to Apple iCloud+ email

Apple supports custom domains with iCloud+ email including family sharing.
  1. You can assign up to 5 domains to a family group and for each domain each member can have up to 3 email addresses.
  2. Apple will instruct on how to do DNS settings (there's a bug in the quotes apparently) - there's also a tech note on DNS settings.
  3. Useful twitter stream on migration to iCloud
  4. Detailed twitter thread on migration - Google takeout mbox, import into Mail, then drag from local to iCloud.

My steps to closing an essentially unused account where I didn't worry about forwarding

  1. Go to Google admin console for account.
  2. Review how many users exist. (typically one)
  3. For that user review email to see if there's anything important, sites, docs, etc. Don't forget google  voice!
  4. From Google Admin account cancel your subscription. Now pay close attention so you don't miss the next step - delete your account (https://admin.google.com/ac/companyprofile/accountmanagement)
When you choose to delete account you see:
Now return to Dreamhost
  1. Go to DNS for domain and delete the Google CNAME records
  2. Go Custom MX controls and Choose "make me regular email". It may take hours for this to work.
  3. At this point Dreamhost enables webmail. But I wonder if this actually blocks email forwarding even if you set that up! (The lack of warning doesn't give me a happy feeling about Dreamhost TBH.) So disable webmail. Dreamhost also has a control panel for email forwarding that I think is a disabled feature.) - NEED TO TEST MORE HERE
  4. Go to Manage Email and set up a forwarding account as needed. This can take a while. Apple picked up the DNS changes within about 15-30 minutes, but Google took 1-2h. (I wonder if DNS propagation in general works as well as it once did.)
  5. Enable DKIM if not already enabled.

Saturday, September 19, 2020

ToDo apps: Microsoft's solution

I've used Appigo's ToDo app for about 12 years (with Toodledo at first). It's had problems over the years, but in general it's been a good subscription choice. There's a fairly hard data lock (maybe SQLite?) but manual reentry is feasible albeit annoying.

Lately, however, ToDo has been more ragged. A recent server side change induced a date bug (time zone?) that in turn showed me I was using a macOS app last updated in 2016. It appears to have been abandoned on the Mac App Store. When I went to Twitter I found Appigo's account was closed years ago for violating TOS. Eventually I found I could download a current version of their other App Store app from their web site.

At the moment the app is more or less working again, though parts of the macOS app UI are kind of weird. I figure there was some violent ownership transition with lost dev passwords in Appigo's history (maybe they got ransomwared?).

I decided to go shopping again. I'm looking at:

  • Apple Reminders: hard data lock and I have to upgrade from Mojave to get to latest version (not happening).
  • Google Todo: this is one hell of a weird product. WTF is their web strategy? Tied to Gmail? Tied to Calendar? At least there's data export.
  • Things
  • OmniFocus: poor Omni is in some disarray ...
  • Microsoft To Do
Today I dug into Microsoft To Do. Of course it's a mess, but this is 2020 so we expect that. The mess starts with Microsoft reusing product names. To simplify a bit:
  • There are classic Outlook Tasks. I'll call these TasksClassic. TasksClassic was excellent in many ways, including, once upon a time, great import/export options and lots of view flexibility (I like to sort by last modified!). Unfortunately it's dead, just barely hanging on in the current desktop app with some degree of synchronization with the new product.
  • There's the new Wanderlist-based product variable called Microsoft To Do and ... Outlook Tasks (name reuse!). I'll call these TasksW for Wanderlist.
If you open the Help screen page for macOS TasksW (To Do) it takes one to a page on Outlook synchronization that's obsolete -- because the Outlook.com version of Tasks has switched from TasksClassic to TasksW. On the other hand the version of Office 365 on my Mac still has TasksClassic, and it does synchronize with TasksW as displayed on macOS and iOS Microsoft To Do.app.

Are you still with me?

This gave me a brief moment of hope that there was some data freedom here. I remember the import/export options of old Windows Outlook. Alas, the only import/export from macOS Outlook is Microsoft's PST format. There might be some way to do things with Outlook Windows or with 3rd party tools but I don't have the energy for that.

At this time I think TasksW is probably a decent enough product, but this has reminded me how screwed up Microsoft is. So I'm setting this one aside for the moment.

See also:

Monday, July 20, 2020

Blogger (draft) supports mobile

If you are using Blogger Draft you will find that it works fairly well in Safari.app and Chrome.app for iOS.

The new interface is responsive. 

I’d prefer a different font for writing on mobile but it’s very doable. Competitive with WordPress mobile app but expect some rough edges.

(Eons ago there was a mobile app for Blogger, but it was discontinued. I doubt it will return.)

Saturday, June 29, 2019

Chrome: Default pjkljhegncpnkpknbcohdijeoejaedia quit unexpectedly

For years I’ve launched gmail and gcalendar on my Mac using apps in my user/application folder I’d named gCal.app and gMail.app. I loved them. Not only did they let me go directly to gCal and gMail from spotlight they also opened in my preferred user profile rather than the last user profile I’d used.

Today they crash on use.

Intermittently I got this error message:

Default pjkljhegncpnkpknbcohdijeoejaedia quit unexpectedly.

That looks like malware, but apparently pjkljhegncpnkpknbcohdijeoejaedia is an undocumented internal Google Chrome extension. (Very cute Google.)

After a bit of research I believe those apps were known as Chrome apps, and years ago Google supported creating them on the Mac. Google ended support in 2017. I think the apps lived in a Chrome folder that was removed, but on my machine they survived because I’d moved copies into a user folder.

Today my extended use luck ran out. Now they crash [1] under Chrome 75.0.3770.100. I suspect my Mac was updated today or yesterday, this version of Chrome was released June 18.

I REALLY miss the desktop app functionality. “Progressive Web Apps” were supposed to replace it but I don’t think they happened [2]. I might try this 2018 tip to see if I can restore it.

Or maybe the next release of Chrome will fix the crash :-).

- fn -

[1] sample start of log

Process: app_mode_loader [1087]
Path: /Users/USER/*/gCal (jfaughnan).app/Contents/MacOS/app_mode_loader
Identifier: com.google.Chrome.app.Default-ejjicmeblgpmajnghnpcppodonldlgfn-internal
Version: 4.5.6 (2564.97)
Code Type: X86-64 (Native)
Parent Process: ??? [1]
Responsible: app_mode_loader [1087]
User ID: 502

Date/Time: 2019-06-29 14:33:12.397 -0500
OS Version: Mac OS X 10.14.5 (18F132)
Report Version: 12
Anonymous UUID: C285F89D-D3A8-7245-0199-81B760782A83


Time Awake Since Boot: 2100 seconds

System Integrity Protection: enabled

Crashed Thread: 0 Dispatch queue: com.apple.main-thread

Exception Type: EXC_BREAKPOINT (SIGTRAP)
Exception Codes: 0x0000000000000002, 0x0000000000000000
Exception Note: EXC_CORPSE_NOTIFY

Termination Signal: Trace/BPT trap: 5
Termination Reason: Namespace SIGNAL, Code 0x5
Terminating Process: exc handler [1087]

Application Specific Information:
dyld2 mode

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread

[2] No, didn’t happen on Mac. Over a year late now:

Progressive Web Apps on Desktop 
Progressive Web Apps now work on the desktop, including Chrome OS and Windows, with support for Mac and Linux coming soon.

For Google macOS is not a priority platform.

 

Saturday, May 12, 2018

Google sent my family into email Hell. This is how we climbed out.

… we’re living in a time when algorithmic software is just good enough to eat the world and still bad enough to be endlessly frustrating. (Daniel Genser, via Twitter)

A few days ago I sent an email to Emily and a few seconds later this came back:

Mail Delivery System <MAILER-DAEMON@homiemail-mx1.g.dreamhost.com>
Tue, May 8, 9:52 PM (4 days ago)

This is the mail system at host homiemail-mx1.g.dreamhost.com.

I'm sorry to have to inform you that your message could not
be delivered to one or more recipients. It's attached below.

                DreamHost Email Support

   <emily@googleappdomain.com> (expanded from <emily@redirectemail.com>): host
    ASPMX.L.GOOGLE.com[173.194.202 .27] said: 550-5.7.1 [208.97.132.209      12]
    Our system has detected that this message is 550-5.7.1 likely unsolicited
    mail. To reduce the amount of spam sent to Gmail, 550-5.7.1 this message
    has been blocked. Please visit 550-5.7.1
    https://support.google.com/mai l/?p=UnsolicitedMessageError 550 5.7.1  for
    more information. q3-v6si11849599pgn.272 - gsmtp (in reply to end of DATA
    command)

Google had sent me to email Hell. Everything I sent to Emily was rejected. It was the same story with emails sent to my children. Whatever I sent, Google rejected.

I think the problem, as far as Google was concerned, was that I was using redirects. This is old net tech. If you own a domain, say “kateva.org”, your hosting service will usually let you define as many redirect “email addresses” in the domain as you might want. They aren’t real email addresses though, they’re redirects. You have to define a true email recipient for each one.

Google didn’t see the email I sent Emily as coming from my personal gmail account, it saw it as coming from the SMTP service that works with my domain (which I’ll call “kateva.org"); in this case homiemail-mx1.g.dreamhost.com. It appears either my domain, or that sending service, had bad Google-karma [1]. Google sent the rejection to “homiemail” (I think!) and homiemail sent it to me.

We were in trouble. It was likely that email sent to our family members was going to be bouncing back in a very confusing way.

I tested sending from various email addresses and using various software (web client vs. iOS Mail, etc) to see which was rejected and which accepted:

Sender Redirect Result
GSuite (web client) Yes Success
Yahoo (web client) Yes Success
Gmail (web client) Yes Success
GSuite (macOS mail, iOS mail)  Yes Success
Gmail (macOS mail, iOS mail)  Yes FAIL
Gmail (macOS mail, iOS mail)  NO Success

It turned out my mail was only hitting Google’s spam threshold when I sent it from my personal Gmail (not GSuite email) using iOS or macOS Mail. Everything else worked, including using my personal Gmail by web interface.

No, I don’t understand what’s happening here. I can speculate that Google rates sending services roughly as follows: GSuite_web > Gmail_web, Yahoo_web > GSuite_client > Gmail_client. The combination of Gmail_client (macOS Mail) and the redirect dropped my email score below Google’s internal cutoff.

There’s not much to do about this. It’s not like Google is going to help. I was on my own and we were in trouble.

The first thing I did was change the redirects to send all the mail to an old school Dreamhost local webmail box. That stopped the bouncing. I could forward from that box to my gmail and reroute important emails manually to other addresses for Emily and the kids.

Next I discovered, contrary to their documentation, that Dreamhost had not enabled DKIM or SFP on my domain. I fixed that (separate post pending) to see if it would improve the reputation score for my domain but it had no effect. I suspect the reputation that mattered was that of homiemail-mx1.g.dreamhost.com.

That left me with these options …

  1. Setup Dreamhost mailboxes for each person and create redirects to them.
    1. Set up a forward from the DH mailbox to another of our family GSuite emails (I picked several Google Apps/GSuite things when they were free)
    2. Have our family GSuite emails do POP retrieval from the DH mailbox.

Dreamhost recommended the 1.2 (second). But I had a third option…

… even though I’d not used it, the problem domain (“kateva.org”) had an old legacy GSuite. I went into that GSuite, defined an account for Emily and kids, and then switched Dreamhost MX to use the GSuite email rather than DH email [2]. I had lost some faith in DreamHost by that point and I figured that since Google rules the net I was better off inside their castle.

And that’s where we are at the moment.

One more weird thing. For 2-3 family members I received a notice that a non-apps Gmail account already existed for them. I didn’t create those accounts but maybe my kids did? (It’s complicated, but somehow when I did Google Voice for them it did … something … brain shutting down ….) Apparently Google lets one do this! They wouldn’t have received email though, DNS records were using DreamHost MX redirects. If you own a domain, and create Google Apps account that matches the existing address, it gets renamed to something like “username%domainname@gtempaccount.com” email. Wow. [3]

It’s Google’s world, we just play in it.

Oh — and don’t use redirects. Google doesn’t approve.

- fn -

[1] Dreamhost denies that they’re in any kind of trouble with Google — but really, how would anyone know. Maybe it was my domain that Google didn’t like — we get a lot of spam and in this setup all that spam would seem to be coming from my domain.

[2] This wipes out all the past redirects. GSuite supported aliases so I moved them into there. Fortunately I’d saved the redirect records before making the MX switch.

[3] Google has an article on conflicting accounts, here is how they are resolved. I think Google Voice was the primary route for creating conflicting accounts — an artifact of how Google switched Voice credential systems post acquisition. 

Wednesday, December 30, 2015

A Google Doc I wrote in 2010 has lost its images

Every 1-3 years I write a “solstice letter”. Since 2010 or so I’ve used Google Docs; it’s the best match to sharing it via PDF and web. 

Today I discovered the 2010 document has lost its images. The text is there, but the images are gone. I tried downloading as PDF, but they don’t show there.

It’s a significant non-recoverable Google Cloud data loss, probably related to old versions of Google Docs.

I’d saved a local .docx version to my personal web site so I still have something like the original. Because I’m a particular kind of paranoid; that is, the experienced kind.

Not good Google. Not good at all.

Tuesday, December 22, 2015

Calendar sharing between Google and iCloud is very confusing: webcal vs http vs. https

A book project forced me to dig into a perennially painful topic — Calendar sharing and subscription in iOS and OS X (MacOS Yosemite) for Google and Apple.

I discovered:

  • iCloud uses Webcal protocol links to share public calendars among iCloud users. Google can parse these, but it in my tests no events appeared. Old web pages say Apple blocks Google access to public iCloud calendars (robots.txt).
  • Google uses https links to an ICS file to share public calendars. Yosemite Calendar.app can use these links and iOS Calendar.app can use these URLs [1], but iCloud.com Calendar can’t. At least in my testing, with Yosemite, Calendar.app on MacOS and Calendar.app on iOS don’t share these calendar subscriptions.
  • Safari.app on iOS will pass an iCloud webcal URL link to Calendar.app and this will trigger a calendar subscription. Google ICS file (https) links won’t work, renaming them to webcal doesn’t work either (I think it might have in the past).
This confusing situation is reminiscent of the complex hoops required to support CalDAV sync for multiple Google Calendars in iOS and MacOS. Apple and Google have very different models for calendaring and they also appear to have different approaches to implementing CalDAV (and they’re probably on different CalDAV versions too).
 
On balance I much prefer Google’s approach to managing Calendars. On the other hand, if one stays entirely within iCloud and ignores Google calendar sharing, then Apple’s Calendars are simpler to use and understand and are better documented.
 
Don’t bother trying to share a public iCloud Calendar to the world, when Apple says “public” they really mean “iCloud”. If you do want to subscribe to a Google Calendar on your iPhone or MacOS, you will have to do it separately on every device you use (it my testing these subscriptions do not sync, I do hope they are backed up).
 
If you are sharing a Google Calendar, you’ll want to provide directions for iOS and MacOS users and you’ll need to explain that they won’t be able to see the calendar using iCloud.com.
 
Sample links used in my testing:
- fn -

[1] Documentation: Subscribe to a calendar. Go to Settings > Mail, Contacts, Calendars, then tap Add Account. Tap Other, then tap Add Subscribed Calendar. Enter the server and filename of the .ics file to subscribe to. You can also subscribe to an iCalendar (.ics) calendar published on the web, by tapping a link to the calendar. The second part of this documentation is incorrect, you can only subscribe for a webcal URL and only iCloud seems to produce the “right” ones.

See also (references)

Sunday, September 06, 2015

Weirdness with Yosemite Google accounts and email configuration: "This message may not have been sent... Report phishing"

I noticed my daughter was receiving email sent from my iPhone with my email address but the sender name of “Gmail personal”.

It took a while to figure out that this sender name was coming from how I named one of the user accounts for Mail.app … on OS X.

I really don’t understand this, but a Google search somehow sent me to this seemingly unrelated conversation ...

Fortunately, I know better than to ignore the nsAI of our time (non-sentient AI) - so I started poking around the configuration of my “Internet Accounts” (Yosemite, click Details after choose account name) and my OS Mail.app Account settings (which are sort of like the “Internet accounts” and sort of not like them).

There I found some oddball settings for Outgoing Mail Server — on a freshly configured machine (I didn’t migrate from prior machine):

Screen Shot 2015 09 06 at 8 57 01 PM

Screen Shot 2015 09 06 at 8 57 29 PM

I deleted the odd outgoing mail server .. .and Mail.app stopped sending email.

There’s a problem with Yosemite and multiple Google accounts on one OS X user account. i’m still figuring this out. I suspect the keychain is involved...

Update: It seems to be working at the moment. I had to create a unique SMTP server for each account and entering my Google credentials (2F bypass password for one of ‘em). I don’t think it’s supposed to work this way. I think in theory there’s a typical Apple hack whereby one does Google authentication in OS X System Preferences and OS X is supposed to create keychain entries Mail.app uses. In practice this appears to fail when a user has more than one Google account...

An AskDifferent thread also implications the keychain, and since the keychain is iCloud synced its configuration can poison multiple clients. i suspect Apple (engineer? product?) simply decided to ignore people with multiple Google accounts.

Update 9/26/2015

In much the same thread I ran into a similar configuration problem on a different Yosemite Mac. This time a correspondent reported Google was warning him my email was suspicious:

Screen Shot 2015 09 26 at 3 03 46 PM

I figured that Google was seeing a mismatch between the stated sender domain and the SMTP sending service domain. When I looked in Mail.app account configuration (not to be confused with OS X account configuration) I found this:

Screen Shot 2015 09 26 at 3 00 02 PM

I have two Google accounts configured, one a Google Apps account (single factor) and another a Gmail account (2FA). The “Home” (2FA) account was using the SMTP server I’d labeled “Gmail Work”. Wrong one.

I switched the the Gmail Home (my definition) SMTP server, which was setup this way by OS X. NOTE the lack of password. Despite the UI displayed here OS X doesn’t actually use the account password. It does some other form of authentication for this 2FA account, possibly via some OAUTH token magic stored in the OS X keychain (which is synchronized between devices, and since Google looks for matches between device and credentials I suspect that causes issues):

Screen Shot 2015 09 26 at 3 05 20 PM

After switching the SMTP service to this one (“Gmail Home”) my next email did not generate a phishing warning.

Tuesday, August 25, 2015

Mac web authoring for non-experts: My choices 2015.

In the beginning we wrote web pages in BBEdit and we FTPd them to a NeXT box.

Things progressed quickly. Almost two decades ago, when Microsoft FrontPage 97 was released and Macromedia created Dreamweaver, there were many powerful Windows applications for creating largely static web pages - with dynamic reflow based on HTML tables [1]. Operating systems, like Windows 95, shipped with a native web server. Netscape added Composer, fulfilling TBL’s original vision of the web as authoring environment. Non-technical users worked with server based systems, ultimately producing millions of web pages on sites like GeoCities [3].

Technology has moved in odd ways. There’s nothing quite like mass market FrontPage today, though Sharepoint Designer/Wiki came close and SeaMonkey survives. Dreamweaver is the strongest survivor of the original era, but it has evolved into a high end tool leased for $20 a month. I don’t think there’s a practical way to move Dreamweaver content to another platform, so adopting Dreamweaver is a deep commitment to the Adobe platform.

At one point I thought the Wiki would fill the vanishing mid-market niche [2], but Wiki solutions seem to have stalled out - much like WebDAV technologies. iWeb/MobileMe came and went quickly - an early sign of Apple’s decade (so far) of dysfunctional application development and fondness for destroying customer data.

Today developers hand code web sites in Coda, a programmer’s tool not so different from the BBEdit we started with. Other experts use Adobe's deep lock-in solutions, from Dreamweaver to Muse ($15/month) or open-source server-based WordPress (Less technical users some might use Blogger in a similar way).

For non-experts Weebly’s small business oriented server side authoring platform is an option, but it’s another deep data lock commitment to one vendor. Google Sites, amazingly, is still around, but focused on intranet solutions.

There are two longlived Mac desktop products both sold for $80 on the Mac App Store: RapidWeaver (presumably inspired by DreamWeaver) and Sandvox. I’ve tried both in the past, Sandvox more frequently than RapidWeaver. Neither product supports wysiwyg table authoring. RapidWeaver was last updated in January of 2014 and has three stars in the Mac App Store; it may be in maintenance mode. SandVox was last updated in April 2015 and has recently added a hosting service (revenue stream!), it has 4-5 star ratings. It’s App Store page still references iPhoto and Aperture however. Of these two I think Sandbox is more likely to make it to 2017.

It’s rarely mentioned anywhere, but TextEdit will export to well formatted HTML, and it even has table support (since 2006 at least). You can embed images and export — but only in single file “webarchive” format. As a simple page editor it’s not too bad, and it’s as standard as anything is these days, but the image limitations are a killer. (I suppose one could similarly author in Pages then view in Pages/web and export the code.)

Similarly one could author in Blogger or WordPress (example: free wordpress.com blog) wysiwyg mode, switch to HTML mode, and paste the HTML into a text editor (Coda?) for FTP upload. Or I could author in MarsEdit (as in this post) and similar export the HTML view as a file. Nisus Express and Pro both include HTML import and export; I don’t know how well their table export works and if embedded images are exported. When I last tried them years ago they weren’t a practical HTML authoring solution.

Google Docs work quite well for sharing and editing online, but they’re not useful for a root (www) web document. Very proprietary of course, but in some ways Google Docs are the closest thing we have today to the original view/edit vision of the www. I haven’t tried sharing iCloud Pages web sharing, but it seems like it would work similarly; it also can’t serve as root page of a web site.

Of the options today, what makes the most sense for me? There aren’t a lot of options on the table, so things should filter quickly with a few constraints:

  • I’d like to avoid dying products.
  • I want to be able to produce a reasonably pretty looking site without a lot of effort (iWeb pretty at least).
  • I’d like a solution that works with Dreamhost and it’s (typical) constraints on www/domain mapping [4]. 
  • I don’t want to sell my soul to Adobe. 
  • I’m not a developer and web authoring isn’t my profession. 
  • I really miss wysiwyg HTML tables and table based layout, but they are clearly gone. Still, I’d love basic table support.
  • I’d prefer to avoid hard data lock.
  • I’d like something that managed a site and updated links when I rearranged web page relationships or renamed pages.
  • I’d like to avoid major malware and security issues. Static sites are very nice that way.
  • Mac (or course) or Safari if server based.

Based on my review of the options, and applying my constraints, it’s easy to see that my best choice is ….  is …. Ok. Nothing survived the constraints. It’s easy to see why I’ve been struggling with this for about 15 years.

If I relax a few constraints I think my least bad options are WordPress (free) and Karelia Sandvox ($80). So I’m going to try both of those — and maybe, if only to close the long loop, Coda too.

Am I missing anything?

See also

- fn -

[1] I think we took the wrong road when we entirely substituted CSS for dynamic tables; no modern tool approaches the table management power of FrontPage 98. Perhaps this happened because it was insanely difficult to manage table authoring by hand, it was really a job computers did better than humans.

[2] Speaking of vanishing mid-market, remember when personal finance software was big? Intuit is trying to find a buyer for Quicken and its future looks quite bleak.

[3] The immolation of GeoCities, echoed on a smaller scale with the 2012 death of MobileMe’s iWeb based web pages, should not be forgotten.

[4] The odd handling of the www domain is, I think, a legacy of early net development. It is a pain in the butt.

Update 4/29/2016

Sandbox can be used free for up to 5 pages. I gave it a good try with a book site I’m working on. The lack of both drag-and-drop placement and tables made me give up on Sandbox. 

Of course RapidWeaver doesn’t do tables either, but I’m going to try it anyway.

It’s obvious that tables are insanely hard to implement; I wonder if CSS support made the challenge even greater. I wouldn’t mind an editor that handled CSS tables, but no tables at all reminds me of all the software functionality and value we have lost over the past 15 years (yeah, Apple Aperture, I miss you.)

Oh, and vendors, please stop trying to tell us we don’t really want tables or that HTML tables are fine. You are just insulting our intelligence. Just say something like “tables are extremely hard to do …”

Wednesday, May 20, 2015

How I moved my daughters iOS Notes from school to personal iCloud account

Please don’t put data into iOS Notes. Really, it’s quite horrid [1]

If you do you may find it’s stuck there. We ran into this when my daughter’s school iPad had to be wiped and we needed to rescue Notes that were only stored on her iPad (school iCloud account doesn’t support Notes, neither does school Google Apps).

I did this:

  1. Used AirDrop to move notes one at a time from her iPad to my iPhone 6 (her 4s doesn’t support AirDrop).
  2. Since my iPhone 6 is configured to use iCloud, each time a note arrived via AirDrop it went via iCloud to Notes.app on Mavericks [2]
  3. On Mavericks the notes appeared in my iCloud account. I added my daughters Google Account to my Mavericks User account. I could then select ALL notes (yay) and drag and drop them to the Google account.
  4. Then I created an OS X User account and associated it with her personal iCloud Account and added her personal Google Account. Then I did the drag and drop from her Google to her iCloud. 
I did something similar with her school Contacts. Interestingly the account drag and drop behaves differently — Notes are moved, but Contacts are copied.
 
- fn -

[1] I took a look at the folder where Apple stores Notes.app data: ~/Library/Containers/com.apple.Notes/Data/Library/Notes. (Yes, the organization is bizarre). The data is in NotesV2.storedata-wal. I inspected the binary file in Mavericks [2] and found it contains text of Notes I deleted long ago. So if you had sensitive data in Notes.app deleting it won’t remove it from your Mac. It seems the file is never purged.

More — in Mavericks, it only looks like you can drag and drop notes to the desktop. It doesn’t actually work.

More — Notes can sort of hold images and rich text, in some Apple OS but not in others. Definitely not in Google IMAP.

More — Notes was implemented unsung an oddball IMAP hack. It’s like nothing else.

More — Like Contacts Notes can have Groups / Folders in OS X, but in iOS you can’t do anything with these.

There’s still more…

[2] Yeah, I’m still on Mavericks. Yosemite has … issues. I’m waiting for a fix for the crazy network problem.

Saturday, March 07, 2015

Transferring eNom domain with associated Google Apps services to Dreamhost: 2015 Edition

It’s hard to imagine now, but once upon a time Google gave big stuff away. Until Dec 2012 anyone could get extended family Google Apps services and a companion domain for a pittance — $10 a year.  Today I still have most of the features of Google’s $50/user/year ’Apps for Work’, but I only pay for domain registration. [4]

Naturally I acquired quite a few Google Apps services, either directly from Google or through Dreamhost (referral link) [1]. Today I still have 10 Google Apps suites. 

The ones I got directly through Google were registered with eNom. This worked reasonably well until Google ended their first generation payment systems, so each eNom account had its own payment data and was completely independent from all others. Since then I’ve been slowly migrating accounts from eNom to Google.

Very slowly! I last moved a Google Apps associated eNom domain in 2009. Yeah, six years ago. [2] Over the past few weeks I’ve moved two more, enough that I’m getting the hang of it. The process is similar to what I wrote about years ago, but there are some added security steps.

I’m going to try to document what I did here — as much for me as for anyone else. Don’t trust what I write though — read Google’s documentation as well, they include registrar specific advice as well:

Key Concepts 

If you understand these concepts things are a lot simpler:

  1. There are 3 independent services involved in this process:
    1. Google Apps services
    2. DNS services (primarily CNAME and MX, the latter is email specific and is particularly old and crotchety).
    3. Registrar services (ex: management of kateva.org, including pointing to DNS services for Kateva.org wherever they might be.)
  2. One business could provide all 3 services [3] or each service could be with a different service. Throughout the process below Google provided Google Services, but I started out with eNom providing both DNS and Registrar services. Then I moved DNS services to Dreamhost. Seven days later Registrar services completed their move to Dreamhost.
  3. The things that connect a Domain to Google Apps are…
    1. Google stores the name of the domain in its records
    2. DNS entries that point to ghs.google.com. When you enter a URL the Domain Name Server sends the request to ghs.google.com, it looks up the domain name and handles it. (Similar magic for MX records).

Steps to follow

This assumes you’re paying for full featured Dreamhost hosting [1]. Quick steps here, more notes below.

  1. Go to eNOM domain settings on Google Apps. Confirm contact information email works. Don’t use contact email that belongs to the domain you’re moving.
  2. Go to Dreamhost, add the domain you’re going to move to Domains Hosted per DreamHost CNAME record instructions as a fully hosted domain under your Dreamhost username. Yes, you can and should do this before you actually move the domain. You’re setting up DNS services at Dreamhost and soon you’ll tell eNom to use those instead of eNom’s native services.
    1. Go to Manage Domains and “Add Hosting” choose Fully Hosted. I put everything under my one username.
    2. Click the box for Google Apps. Dreamhost will configure standard CNAMEs and especially MX records.
    3. Add additional CNAMEs as needed: calendar, docs, drive, blog based on what you see in your eNom records. Don’t need to repeat DomainKey entry used to verify with Google (?). The A record that Dreamhost creates is used to redirect the naked domain to ‘www’.
  3. Go to eNom settings and change eNOM DNS information to use Dreamhost. (ns1.dreamhost.com, etc) Once you do this eNom is now only your registrar.
  4. Confirm DNS still works and can send email to address in domain. I’m not sure how long this takes, 
  5. NOW, Request unlock of the eNom domain by email (see example below. Yes, by email and include your eNom password!). Once this is processed you’ll get two emails from Google, one with authorization key (EPP key).
  6. Go to Dreamhost Reg Transfer, request transfer using the EPP key and complete form. Pay for new registrar service, seems to vary from $10 to $10 depending on domain. Initiate transfer. You’ll see a notice that a 7 day countdown has begun. Dreamhost shows something like this:
    Screen Shot 2015 03 10 at 9 11 24 PM 
  7. About 30-40 min later you’ll get an email from Dreamhost at your official domain email contact that you verified above. Click the link. Go to approval page. Agree. See “your response has been recorded”
  8. Receive notice from Google in 1-2 hr (no action required unless wish to cancel)

    STANDARDIZED FORM OF AUTHORIZATION
    DOMAIN NAME TRANSFER - Confirmation of Registrar Transfer Request

  9. Receive notice after 7 days that is complete. Now go to Dreamhost. Lock the domain. Enable auto-renewal. Test email and google services.
  10. LAST: Google tries to renew registration, fails, sends note domain moved. However, Google never fixes up its Domain settings on the legacy account, they always show “enom” (sic) as registrar.

Sample of eNom letter

GoogleClients@enom.com

Please unlock this domain, disable Google ID Protect, and send authorization code. Thank you!

Domain : yourdomainame.com
Password : u5yhtt5p965965 (your eNom pw, not your Google pw. Get this from Google Apps Domain Settings.
Customer service PIN : (if you know it, optional)

This is what eNom sends if you ask how to proceed.

 Greetings ,

To transfer your domain, you're going to need the domain to be unlocked and the authorization code for the domain. I can assist you with both of those if you can give me the domain password that Google supplied you. (Note: this is NOT your Google Apps login password.)

When you registered the domain, Google set up a privacy protect service and I will disable that in order for the transfer to be successful.

Also, please be aware that in order to transfer the domain, it needs to be 60 days after registration. This isn't an eNom-specific rule - this is a rule for all registrars set by ICANN.

Please e-mail me back with the domain name and password and I can get started on getting you the information you need.

If you don't know your domain password, follow these steps to find it:

Enter your domain name at the access login screen (http://access.enom.com), with AAA as the password, then copy the verification code. Click "Log In" to submit the information.

Put the name in again and then click on the "forgot password" link and it will be emailed to you at the address on file with Google for your domain name.

***IMPORTANT: Remember log into your domain manager at http://access.enom.com to ensure your Registrant and Administrative contact information is valid BEFORE transferring the domain name***

Alternately, IF YOU DID NOT CHANGE THE PASSWORD, you may also recover your Google domain password using the following steps:

To access your Advanced DNS settings, please follow these steps:

Log in to your account at admin.google.com.
Click on the Domains icon on your Admin console dashboard. You may need to click on More controls at the bottom of the screen to find the Domains icon.
Click on the Advanced DNS settings link associated with your Primary Domain.
To make changes to your DNS settings, sign into your DNS console with the login information provided on this page.
When you access Advanced DNS settings, you'll be directed away from Google, and to the domain registration partner that registered your domain name. This is currently available in English only.

Regards,

Google Advanced Domain Support

Provided by eNom, Inc.
email googleclients@enom.com

and this is what you get from eNom after you unlock:

Thank you for proper verification of domain ownership by supplying the domain password.

The domain has been unlocked, ID Protect has been disabled for transfer and your authorization code has been sent to the following email address in a separate e-mail. Please check your spam folder or filters as this is often captured.

***IMPORTANT: Remember log into your domain manager at http://access.enom.com to ensure your Registrant and Administrative contact information is valid BEFORE transferring the domain name***

YOUR EMAIL HERE

If the above email address is invalid, please log into the access control panel (http://access.enom.com) and update the contact information. Once the email address has been updated please reply back at your earliest convenience so that we may resend the EPP/ Authorization code.

Your domain is ready for transfer.

As a note: the transfer process does take 5-7 days for the domain to arrive at the gaining registrar. Once started by you, there is nothing you need to contact us about again. You can however ask us to confirm if the domain is pending transfer should you need to check.

DNS Result after setting up in Dreamhost as fully hosted with Google Apps services

Screen Shot 2015 03 10 at 8 34 37 PM

Additional Custom CNAME (copied from eNom) that I added (some, like ‘sl’ are really exotic. Don’t worry about it.)

Custom cname

Miscellaneous artifacts

Some sample email excerpts:

-

We have requested your domain.com to be transferred to DreamHost! First, your admin contact will receive an email with a link to approve the transfer from us. They will then receive another email from the current registrar with instructions on how to approve the transfer from their side. Typically, transfers take about 7-10 days to go through. You will receive an email from us when we've learned if the transfer has been approved or denied. Note: If you'd like to also host with us, please visit "Manage Domains" now.

-

Domains must be "unlocked" at their current registrar or the transfer will fail. Domains may not be transferred within 60 days of their initial registration or their most recent transfer! You should do any name server changes (e.g. to ns1.dreamhost.com, etc) before transferring! You must make sure you have access to the admin contact email currently listed for your domain! You will receive an email from do-not-reply@dreamhostregistry.com with instructions on how to complete the transfer to DreamHost. If you do not receive it in a few hours, please check your spam filter. The entire process may take 7-10 days or longer before it is complete!

- fn -

[1] Dreamhost has worked well for me for many years. I you sign up and use my PROMO code of KATEVA you get $50 off the 1st  year (I get $47.)

[2] That freaks me out a bit, I vaguely remember when 6 years was more than yesterday. 

[3] Recently Google began providing domain services itself, but i don’t know much about it.

[4] Ok, so you can still get Google Voice (thought it’s a bit trickier than it once was). That service has saved me thousands of dollars on mobile phone calls to Canada.

Wednesday, December 24, 2014

Canadian mobile for Americans: A primer. (Koodo, Google Voice/Hangout)

It is hard for Americans to understand how awful Canada’s mobile and Internet options are. Imagine that your only option for cell and net access was the equivalent of Comcast. That gets  you half way there. Now double the cost.

Canada’s lousy net/mobile situation probably explains part of why, when I travel to Quebec, the web experience feels more like 1998 than 2014 (language requirements don’t help).

Why is it so bad and why don’t Canadians scream more? Geography always factors into Canadian economics - a country that’s 5,000 miles wide, 100 miles high, thinly populated, and sitting atop a monster, is always gonna have weird markets. There’s also culture — Canadians don’t whine enough. (We Americans lead the world in whining, wailing, and complaining. Gotta be good at something.) And maybe a bit of a Blackberry hangover. [2]

It’s so bad now even Canadians are getting fed up. There are rumblings about turning net/mobile access into a regulated utility — some of my relatives think Rogers and Shaw are getting nervous. We’ll see. Canadians can tolerate a lot of abuse.

This is on my mind now because I’m trying to figure out the best options for my sister.

I currently have her on an American AT&T iPhone 4 [1] and a $17/mo Virgin Mobile prepaid plan (Virgin is a Rogers MVNO). On her plan voice costs 0.40/min (!) and she gets 100MB a month of data (iMessage, Facebook, email). This plan costs about 4 times my kids H2O wireless plan and delivers less value [3]. It’s not great and she needs voice services [4]. 

Koodo, a Telus MVNO, seems to be the value choice (the dread CDMA acronym appears). The IMEI for my sister’s AT&T 4 passed the Koodo compatibility test, so it’s possible her current/future AT&T 4/4s would work with their SIM.

Looking at the options, and starting with these assumptions…

  1. 500+ min of talk
  2. No home internet service (so tethering [7], which is supported, is the only way to use, say, an old 32bit Mac Mini running Snow Leopard [5])
I end up with, tentatively [9], two Koodo options [6]. One caveat — Koodo, weirdly, does not support Canada’s Interac system for making payment [9].
  1. Postpaid: $60-$70 month (1-2GB) + fees
  2. Prepaid:  $90 (at time of purchase a 13% HST is typically paid)
    1. $35: text and unlimited incoming calls
    2. $30: data (1 GB)
    3. $25: 500 anytime minutes

Which brings me to Google Hangout/Voice. Having GV on her phone would provide some nice cost-saving options. Alas, even though Google has .ca domain documentation on Google Voice, neither GV nor Hangout are available in Canada (nor Skype!). One workaround uses a US Skype number to full Google, but of course that would give her a US number — not terribly useful actually [8]. Sigh.

So I think it’s going to be Koodo — either postpaid or prepaid depending on hidden fees with postpaid.

 - fn -

[1] The 4 (soon to be 4s) has been compatible with Rogers/Virgin frequency. I recently tried my unlocked AT&T 5s with a Virgin SIM however and the data service failed completely — I don’t know if this was due to Virgin’s fragile infrastructure or a frequency problem with the 5s chips.

[2] More culture. Canadians love BlackBerry, the little company that could. It’s dead now, but Canadians are a loyal bunch. So their expectations of mobile are kind of 2005.

[3] One twist — in Canada some cell plans don’t use minutes for incoming calls. Some do. Koodo does on some plans at some times. Complex, but if you know the rules you can text and ask someone to call and thus talk for free. Koodo’s old crappy website has an “unlimited incoming call” add-on for about $10/mo - but it’s unclickable on a modern browser. By the way, the website offers the same add-on for unlimited minute plans — where it adds no value. I wonder how many are paying an extra $10/mo to Koodo.

[4] If we cancel her home phone she needs 500+ minutes of talk a week.

[5] The best desktop device/OS combination Apple ever made — before the mediocrity hit. You can’t buy something as good today though there are obvious security issues with such an old OS.

[6] In US postpaid plans there are many hidden fees and taxes. I don’t know if that’s true in Canada, but in some provinces taxes add 25% to costs. I know the Virgin prepaid plan has no additional taxes, I assume that’s true of Koodo too. Makes prepaid/postpaid comparison harder.

[7] Desktop OS are not made for tethering — they randomly suck volumes of data. Modern “cloud” devices are big offenders, so a pre-iCloud Mac has an advantage. Still, it’s a worry esp. for a postpaid account. I don’t know how Koodo handles overages on a prepaid account; in the US H2O seems to just cut coverage but Ptel (Tmobile) will burn the number with a huge overage cost.

[8] The site also recommended “tellfi.com", but if you try to visit that site Google warns that the cert expired 270 days ago. Don’t go there unless you want your computer to serve Russia.

[9] Koodo’s website is broken — the add-ons can’t be selected using Chrome or Safari. There may be more options if the add ons features worked. I think the broken web site/funding situation may also explain their lack of Interac support.

Thursday, November 13, 2014

Force Chrome to remember iCloud password - how I ended up with LastPass

I don’t use iCloud for much - Apple’s cloud functionality is almost as lacking as its reliability. Our family has used Google Calendar for 7 years [1], I use Simplenote and nvAlt [3] as an information store, Gmail for email [4] and Toodledo/Todo.app for tasks. [5]

That leaves Contacts in Apple’s badlands — they’re too tightly coupled to iOS and OS X to readily migrate. So Contacts are the only bit of iCloud I use; I have to admit that they have been relatively reliable.

Hang on — this does get to the part about forcing Chrome to remember an iCloud password. But first I need a bit of setup. I have to explain something about corporate life and personal data.

Fifteen years ago many employees mixed their personal and corporate data on business laptops and workstations. It wasn’t unusual to use a single email for both work and personal use. Ever since then the two worlds have been dividing - driven by legal and security concerns. Even thumb drives are encrypted on insertion now; data on the increasingly locked down corporate laptop belongs to the corporation.

Which is fine for email and work documents - they should belong to my employer. Contacts though — they’re a problem. They don’t divide neatly between work and personal — and my work Contacts are pretty important for my future employment and family food. So, when it came time to decide where my Contacts should live, I moved them entirely into the personal sphere.

Which is why I need to use a corporate browser (Chrome [6]) to access iCloud — that’s where all of my Contacts live. I need ‘em when I work. 

Ok, so we’ve established I need to use Chrome to access iCloud. Now the problem — it makes me enter my password way too often. And my passwords aren’t easy to type or remember. There are extensions that once forced Chrome to store this password, but they don’t work any more.

So today I broke down. LastPass has a freemium model for online credential storage; the web app and Chrome extension are free. (LastPass charges for mobile services.) Unlike 1Password, which I use on iOS and OS X, there’s no need to buy a Windows client — and I don’t want to put all my credentials in the Cloud anyway. So I signed up for free LastPass, and created an account with a single stored credential - my iCloud ID and password.

It works fine. So one of my longstanding annoyances has been fixed — I can quickly bring up iCloud Contacts.

- fn - 

[1] Calendars 5.app is essential for the Google Calendar power user — we have it on every phone [2]. My native iOS Calendar syncs to my corporate calendar, Calendars 5 reads the iOS calendar database so it appears inline with my other 17 calendars, including 1 for each family member and one ‘all family’ calendar. Our family grandfathered into free Google Apps accounts, but if we didn’t I’d probably pay for the business service. Free has been nice though.

[2] It’s $7 a user. Since it’s not funded by in app purchases I believe iOS family sharing would allow one purchase to support five users. If it did use in app purchases that wouldn’t work. FWIW we still share a single Apple Store only AppleID, I use a different AppleID with iCloud.

[3] nvAlt is in maintenance mode for now — but so is Notational Velocity. Brett has a commercial replacement in the queue, as of today “it’s amazing and will probably be released”.

[4] Google’s broke Gmail usability with their last UI redo. I use Mail.app on iOS and sometimes Airmail on Mac, but mostly I gnash my teeth and weep and use Gmail.

[5] Nobody would do this by choice. Is a legacy choice.  Works and I hate to change things that work.

[6] The corporate standard is IE 9 — thanks to legacy apps. So IE for corporate apps, Chrome elsewhere.

Friday, April 18, 2014

Google is closing little used Google Apps accounts

For a few years Google offered a free version of Google Apps, and even after that was discontinued you could get a free Apps service with a new Dreamhost domain (I think that’s been discontinued). It was a great deal; I ended up with a dozen or so. One of them has provided all of our family email and calendars since 2007; even after Google ended the new signups they let freeloaders like us hang around.

Recently though I’ve received notices from Google warning that they will close unused Google Apps accounts. So if you have some Google Apps you’d like to keep, be sure they are setup with a valid forwarding address [1] and periodically log in and send an email.

In one case I did authenticate, but I still received a second notice of pending termination. I hope that’s just a glitch.

[1] In some cases an Apps account is also associated with a companion Domain, so if the Apps account is lost the domain control may be lost too. Check.

Thursday, October 31, 2013

How to get back the Gmail compose that you used to love.

It's simple, at least in Chrome.

Control-Click on the Compose button. Your Compose opens in a tab - with To and Subject line exposed, full view. Alternatively, shift-click to get a new window.

Shift-C works too, opens a proper compose. Ctrl-C doesn't work though.

Reply isn't as elegant.  Shift-R when in the context of a menu creates a right sided 'pop-out', shift-click or ctrl-click on top right icon to get it in a separate window. Alas, subject line is still hidden, that's another click to expose (Google hates subject lines, no kb shortcut either). Also, prior text is hidden -- yet another click.

Shift-A replies all in new window.

Have I mentioned I don't like Google?

We need a Chrome Extension that fixes Reply.

Sunday, June 09, 2013

CloudPull - backup your Google Cloud properties -- including your old shares and your multiple Drive accounts.

I've been using Golden Hill Software's CloudPull Premium ($15 now, I only paid 410 due to a promo, TidBITS users can jump get a 20% discount if they insist) for a month or so. It backs up parts of the Google data associated with 3 of my Google identities -- Personal, Public (jgordon@kateva.org) and Work. Sooner or later I'll start backing up the kids stuff too.

The backup data includes my Google Calendars (primary and subscription/shared as .ics), Google Contacts (3,496 as .vcf), Drive files (Google versions converted to iWork, else native) and Reader subscriptions, starred, shared and liked (not sure of format, seems a mix of database  and references). The repositories are searchable through CloudPull and, since I changed the store setting to be in my Documents folder, via Spotlight. I don't backup my email accounts; those are in Mail.app.

The app seems to work very well. It's designed to backup every 1 to 24 hours, but I just run it every few weeks. It would be nice to have a once weekly or once monthly backup option, or to be able to schedule backups for the wee hours of the morning. I don't backup 

My archive includes about 40,000 Google Reader shared articles, a SQLite database of about 400MB and total storage of about 5 GB. Not trivial, but manageable. The storage architecture makes use of SQLite and many shortcut links.

I am quite fond of this app. It has a minor glitch in an early version, the developer fixed that quickly. Highly recommended for every Mac user of Google products.