Sync Oracle Calendar to Google Calendar + iCal + iPhone

I've been searching for a reliable method to automate the synchronization of events from Oracle Calendar (formerly CorporateTime) to my Google Calendar, iCal on my Mac, and internal iPhone calendar on my iPhone.

Recently I learned of a promising iPhone app available at iTunes called Todo+Cal+Sync that could do most of what I was looking for with synchronizing calendars. However, I didn't want to fork over $14.99 for an application that, instead of importing Oracle Calendar events into the native iPhone calendar, added an additional calendar application on my iPhone. Synthesis AG, the developer of the Todo+Cal+Sync application, is required to do this because of limitations imposed by Apple's iPhone software development kit (SDK). In other words, Apple does not allow 3rd part applications, such as Todo+Cal+Sync, to access the internal iPhone calendar, nor sync with iCal. This is a risk/benefit that Apple needs to manage; is the benefit of restricting access to the internal iPhone calendar worth the impact it has on the development of 3rd party applications and subsequent ripple effect? Until Apple's iPhone SDK allow such access, I did not want two calendar applications and continued looking for something that would better match my needs.

After digging around and tinkering with different solutions, I worked out a method that did exactly what I wanted. To make this solution even better, it cost $0 - in other words, FREE!

Below are the steps that I came up with to make the calendar sync work for me. Steps 1-3 are also useful for those who do not necessarily have an iPhone or iTouch but want to sync their Oracle Calendar with other devices and/or calendar apps that support Google Calendar's CalDAV sync.

1. Begin by changing your password for your Oracle Calendar user account. Make it a unique password that you are not using anywhere else. In other words, your new Oracle Calendar password should not be the same password as you're using for other email accounts, online banking, eBay, PayPal, etc. This new password should also comply to any password policies that may exist for users of the Oracle Calendar system.
2. Create a "magic" URL using SyncML2iCal.com. This URL will be used in step #3. You will want your magic URL to look something like the following:

Example - Oracle Calendar supporting https on port 443

http://sync.syncml2ical.com/?serverurl=https://YOUR.ORACLE.CALENDAR.COM:443/ocas-bin/ocas.fcgi?sub=syncml&user=USERNAME&pass=PASSWORD&eventsdb=./Calendar/Events?/dr(-7,30)

SECURITY WARNING - There is an increased security risk with this method. It's up to you to determine if this is a risk you are willing to accept and that it doesn't violate any policies or restrictions imposed by the organization running the Oracle Calendar service that you are using. The risks include:

• Unauthorized interception of your password from the URL as it's being transmitted to SyncML2iCal.com or from SyncML2iCal.com.
• SyncML2iCal.com itself becoming compromised and allowing an attacker to intercept your password.

In my opinion, the likelihood of the above risks happening are medium to low. You can keep this risk on the lower end by never connecting to untrusted networks or using insecure wireless, which includes wireless networks that use WEP encryption.

Additionally, you will need to determine if the impact of an unauthorized user obtaining your Oracle Calendar password would have a significant impact or not. In most instances, I would imagine the impact would be low.

This is why doing step #1 above is critical in helping minimize the impact if your password was compromised.

Anyone using an application that syncs using the SyncML functionality of Oracle Calendar should take the same precautions irregardless if he or she are using SyncML2iCal.com as a proxy to convert SynchML to iCal format.

3. Go to Google Calendar and add a new calendar by selecting Add by URL . You will use the URL you created from step #2. You may also want to change the display name and color of this new calendar on Google Calendar.
   
   Do note that Google has stated that external feeds added via the "Add by URL" method should be refreshed every 24 hours.
   

4. Download and run Calaboration from Google Code. This will allow you to add your Oracle calendar to your Mac's iCal application. Before you can add the new calendar, click on preferences within Calaboration and enable allowing read only calendars to be added. Make sure your new calendar is selected and let Calaboration do the setup work for you. Your Oracle calendar will then sync with iCal.

5. Use iTunes to sync Oracle calendar from iCal to your iPhone.

One minor annoying issue I came across was with how day events and day notes from Oracle Calendar were handled by the time they showed up in iCal. Day events and notes from Oracle Calendar showed up in iCal as being a blocked all-day event from 0000-2359. As a quick temporary solution I simply denied day events and notes within Oracle Calendar and re-synced. This temporary approach was acceptable for me since I use Google Calendar to manage my daily notes and I can look at a user's Oracle calendar if I need to know if he or she is on vacation, on-call, etc.

As for effectively managing tasks using your iPhone, see my previous article titled, Tools To Get Things Done.

Steve

###

Forensics: Blackberry Curve 8310 and Incorrect EXIF Time Stamp

While working on a forensic investigation that involved a Blackberry 8310 I ran into an issue that just didn't settle right with me. I wanted to ensure that, beyond a reasonable doubt, the EXIF time stamp embedded within a photo taken by the Blackberry device was written accurately by the device. Before signing off on the validity of the EXIF time stamp, something just didn't seem right. After digging around and doing countless tests, I was surprised that I was able to consistently recreate a failure whereby the incorrect time stamp was written to the original date/time EXIF field. Here are additional details:

DEVICE: Blackberry Curve 8310 smartphone (EDGE)

VERSIONS: v4.5.0.55 (Platform 2.7.0.68) & v4.5.0.110 (Platform 2.7.0.90)

PROVIDER: AT&T

DATE/TIME SOURCES: Blackberry & Network

ADDITIONAL ENABLED SETTINGS WORTH NOTING:

• PASSWORD (options | security options | general settings | password)
• BACKLIGHT TIMEOUT value of 30 seconds (options | screen/keyboard | backlight timeout)
  
• SECURITY TIMEOUT value of 1 minute (options | security options | general settings | security timeout)

OBSERVED BEHAVIOR:

The EXIF original date/time embedded within a photo taken by the Blackberry 8310 had the incorrect time stamp. Consistently and repeatedly I was able to have the Blackberry device write the incorrect time stamp to the EXIF field. The EXIF original date/time was inconsistent with the actual date/time that the photo was taken in addition to the “Last Modified” time displayed by the Blackberry device.

SCENARIO REPRODUCING THE PROBLEM:

1. I take a photo with the Blackberry at 0600 on 1/22/2009. The image name is IMG00001. Using the Blackberry and looking at the properties of photo IMG00001 I see the correct “Last Modified” date and time of “Jan 22, 2009 6:00AM”. Emailing the photo to my email address I then view the EXIF data of the photo on a separate forensics system and see the correct original date/time of “2009:01:22 06:00:00”.
2. An hour passes. I delete IMG00001 from the Blackberry and then take a photo at 0700 on 1/22/2009. The image name is IMG00002. Using the Blackberry and looking at the properties of photo IMG00002 I see the correct “Last Modified” date and time of “Jan 22, 2009 7:00AM”. Again, I email myself the photo and view the EXIF data of the photo on a separate forensics system. However, this time I see the incorrect original date/time. The EXIF field shows “2009:01:22 07:02:00”.
3. [update: 1/23/2009] - I can also reproduce this EXIF incorrect time stamp issue without deleting photos. This issue presents itself only with the first photo taken after the phone has automatically locked, requiring a password to unlock before the said photo with the incorrect EXIF time stamp can be taken by the device. Subsequent photos taken before the security timeout locks the device have the correct EXIF time stamps.

IMPLICATIONS:

An assumption is made that the Blackberry device is writing the correct date/time within the EXIF data when a photo is taken with the device. EXIF data within photos could potentially be used as evidence to support what an individuals recorded statement (e.g., whereabouts at a given time). From my tests there’s reasonable doubt that the EXIF time stamp of a photo taken by a Blackberry 8310 device (and perhaps others) may be incorrect. Therefore, EXIF time stamps from photos used as evidence becomes highly questionable and ultimately, and likely, could be rendered irrelevant.

ADDITIONAL NOTES & QUESTIONS:

• Blackberry and RIM have been contacted to investigate and confirm the issue.
• I was able to reproduce this issue on a single Blackberry Curve 8310 which was initially running v4.5.0.55 (Platform 2.7.0.68). I was also able to reproduce the failure after upgrading the same Blackberry Curve 8310 to v4.5.0.110 (Platform 2.7.0.90).
• I viewed the EXIF data on a Mac using both “EXIF Viewer” and “Preview”. I viewed the EXIF data on a Windows XP system using “InfranView” with the EXIF plugin installed.
• Can others reproduce the same issue on 8310’s running similar and/or different firmwares?
• Can others reproduce the same issue on non-8310 Blackberry devices?
• [update: 1/23/2009] - Could this be a residual artifact of the security lockout feature? (will need to test after disabling the security timeout)
  

Steve

###