Unfortunately Google knows the version of my app can't handle encryption, so they've been treating this in one of two ways. If you already have bookmarks in ChromeMarks, Google would simply not send you any updates. At. All. If you are syncing ChromeMarks from the beginning (i.e. after a reset/reinstall) then Google took a different tack and decided to throw an obscure "database id" error:
Unfortunately if I add in code to detect encrypted bookmarks then Google will detect that and will then assume the app can handle encryption and will no longer send the errors! Grrr!
1. Chrome is written in c and Android isn't. To work out how to implement this, I had to understand the intricacies of the Chrome code, find the bits that do the encryption, decryption and work out how to do the same in Android. Android is in Java. Which isn't the same as c! So I basically had to write a line by line match for the existing c code into a different language which worked a completely different way and had different dependencies and expectations!
2. I tried in Java first, but struggled to work out how to do basic decryption. I found some Java code on the web and took some of the basic unit tests in chrome to test against, but it never worked. After several days pulling my hair out, I found some obscure documentation on the web that explained some of the Java decryption classes are at bit level not byte level. After a bit of division by 8, suddenly one of the Chrome test packs passed!
3. I spent another week writing more Java to keep testing it and adding in more functionality to match Chrome, including code to decode the keys that Chrome stores in the sync database that are the key to decrypting your bookmarks. This started working well, so when I was confident I'd got it all good, decided to stick some of it in the app and test drive it.
4. It failed immediately when run on Android. I discovered that the security classes in Android's Java have been crippled at birth. Basically several years ago, the US government decided they didn't want the free Java code to include the best encryption code, also for free. With the normal panic over terrorism, they wanted to restrict many counties of the world to only have access to the weak encryption in java and save all the strong stuff for USA and the countries it trusts. Android has a bit of an old version of Java in it and Android is also available over the world. So it lacks the tough stuff - the stuff Chrome uses and requires by default. Grrrr.
5. This basically meant all the Java stuff I had done tested locally was effectively worthless as it would not run in Android. Of course nowadays, the restrictions in Java have been lifted and there are other libraries you can also plugin to do the job instead. But I can't upgrade the version of Java on your device. And I couldn't use the other libraries as they annoyingly have to have files copied into your Java installation and again that isn't possible on Android.
6. So I went back to Chrome and tried to see if I could compile some of the Chrome code as native code and see if that would work instead. But after another few days playing, it became obvious that I'd need a significant amount of the Chrome code base to get anywhere, and I'm definitely nowhere near a reasonable c coder to attempt that! Plus this was also a few weeks before they started actually checking in the initial code to the Chrome code base that might bring Android compatibility (note to readers, don't get excited...its a long way off before we will a nightly release of Chrome that runs natively on Android). But like the chrome devs, I still can't compile a working version for Android.
7. So instead I tried to see if I could compile some of the open source c libraries instead such as nss or openssl. Although I could find some posts out there from people who could compile it for android, I just couldn't get the damn thing to compile under cygwin. I tried ubuntu but got almost the same problems. In the end I went back to Java and persisted and managed to find a website that listed an alternative implementation of the missing encryption algorithm and found a way to simply invoke it manually (read: hook/crook/square peg/round hole) instead of via the default Java security classes - this avoided the need to install it on the device. Sorted.
8. Then started plugging it into Android. However Android doesn't have the operating system crypt classes that Windows and Macs have by default (or linux that would actually compile and work), so encryption on Android is increeeeeeeeeeedibly slow. I haven't had enough time to see if I can work out by how much...!
9. Then I had to find a way around what is sure to be the biggest gripe. Chrome uses your actual account password to encrypt and decrypt the bookmarks. Without your password, it ain't possible. If the app asks for your password, there will be uproar from people whingeing "why does this app need my password, it will have access to my Google checkout and credit card and emails, etc." Sigh. Of course people wouldn't remember that in Chrome where they ticked the radio button that says "encrypt my bookmarks", it says immediately below it "Use my Google account password." So people have already agreed to this - its the way Chrome works, people, and you agreed to it! Don't have a go at me!
10. But I knew this will bring complaints. So I next thought about the screen I'd need to get the users password. Instead of a simple standard popup, I made a full size screen that deliberately looked like the normal Android credentials popup. Here's a shot of the new password request/passphrase request screen:
In it, I then added a screenshot of the box in Chrome mentioning it would use your password and underlined it to make it clear to the user. Hopefully if anyone wants to complain, they can see this and realise they already agreed to Chrome using their password and its clear there is no other option other than disabling encryption completely or using a passphrase instead.
If you click on the "more info" button, you get an image cut from Chrome to prove why the password is requested by [ subtly! ] underlining some key text from Chrome in red: