Signs on the Sand

 Gmail client for mobile devices was released by Google a month ago. It's Java ME MIDP2 application, cool looking as one could expect from Google. I went and installed it last week on my Motorola V3X. Well, I found out that while Gmail for mobile work on hundreds of different mobile devices ...

Anyway, while digging around my phone filesystem I found a folder where J2ME applications are installed (/a/mobile/kjava/installed/) and there I found Gmail jar, image png file and other working files including RMS file. RMS stands for MIDP Record Management System (RMS) - a persistent storage for J2ME MIDlets. Seeing string "Login store" inside it I couldn't resist to scan it. What I found though was my Gmail username and password in clear text!

0000000FF0:  FF FF FF FF FF FF FF FF │ FF FF FF FF FF FF FF FF                  
0000001000:  00 10 6F 6C 65 67 74 6B │ 40 67 6D 61 69 6C 2E 63   ►olegtk@gmail.c
0000001010:  6F 6D 00 0A 6D 79 70 61 │ 73 73 77 6F 72 64 FF FF  om ◙mypassword  
0000001020:  FF FF FF FF FF FF FF FF │ FF FF FF FF FF FF FF FF                  

 WTF??? 

Well, I can't affirm that Gmail for mobile application indeed stores user password in clear text, because I never got it fully working on my phone. Chances are they encrypt it after first successful login.

I need somebody to confirm this. If you've got Gmail for mobile application installed on your mobile, please take a look how your password is stored. I have no idea which mobile devices allow direct access to the file system, but at least it's very easy for Motorola phones. Just install P2K drivers and P2K Phone File Manager, run it and open /a/mobile/kjava/installed/ folder. Find Gmail's RMS file and inspect it.

PS. I did contact Google about this issue, but never got any response.

I saw today Josh Christie post about "Better HTML parsing and validation with HtmlAgilityPack". HtmlAgilityPack is an open source project on CodePlex.  It provides standard DOM APIs and XPath navigation -- even when the HTML is not well-formed! Well, DOM and XPath over malformed HTML isn't new idea. I've been using ...

I just uploaded nxslt v2.1 release. In addition to the nxslt.exe command line tool it now also includes nxslt task implementation for NAnt and MSBuild. ...

Why another XSLT task? Because existing ones suck. NAnt includes standard "style" task, but it uses obsolete slow and buggy XslTransform engine to perform transformations. MSBuild doesn't include XSLT task at all, while the Xslt task from the MSBuild Community Tasks Project is broken. Not no mention these tasks are barebone ones. If you need a better XSLT task for NAnt or MSBuild - nxslt task is for you.

Here is some highlights on this new nxslt task.

nxslt task is a free feature-rich task for NAnt and MSBuild that allows to perform XSL Transformations (XSLT) using .NET Framework 2.0 XSLT 1.0 implementation - XslCompiledTransform class. nxslt task supports plenty of advanced features:

• XML Base, XInclude, XPointer
• Embedded stylesheets
• <?xml-stylesheet?> processing instruction
• Multiple output documents via exsl:document extension element
• Custom URI resolving
• Custom extension functions
• 70+ EXSLT and EXSLT.NET extension functions
• Credentials to access XML documents and XSLT stylesheets
• Pretty printing
• Batch processing

nxslt and nxslt task are free tools under BSD license. Download here.

Btw, besides transforming XML documents nxslt task can also be used for pretty printing or resolving XIncludes. I'll post on this later.