Android is like the Windows XP days with little regards to user's protection

Months ago, I made a statement to my friends that effectively compared Android's operations or lack of security to the days of Windows XP and prior. The open neglect seems to follow the same excuse Windows use to make it easy for people to use. Now my observation is supported,

The Android threat landscape is starting to resemble that of Windows, according to F-Secure's Mobile Threat Report 

The Android threat landscape is growing in both size and complexity with cyber criminals adopting new distribution methods and building Android-focused malware services, according to a report from Finnish security vendor F-Secure.

The number of mobile threats has increased by nearly 50 percent during the first three months of 2013, from 100 to 149 families and variants, F-Secure said in its Mobile Threat Report for Q1 2013 that was released on Tuesday. Over 91 percent of those threats target the Android platform and the rest target Symbian.

What frightens me most and at the same annoying me is that when you install most applications, they demand access to your account, your phone, or other facilities that do not seem to be related to what the main function of the applications.

For example, I once wanted to install a PDF viewer and it demanded permission to access my phone contacts, etc. I have yet to see a PDF viewer in Linux/Windows demanding access to my Outlook or Thunderbird phone book, or my Google account. After all, it is just a program to render the PDF document and all it really need is read access to certain area where the document is held.

Then the other date I want to install a GPS logger but it too needed my Google Account, phone Contacts, phone logs, etc. Why? Is it just a program to jolt down the GPS location regular interval or on demand? All it really requires should be write access to the user's area and no more and no less.

If application demanding this kind of unnecessarily access of elevated privilege or to areas in Windows and Linux, they will be exposed as Trojan or Malware. But in Android, a form of Linux, it is an acceptable practice. Why?

As a result, I often do not install those applications that demand unreasonably access.

The only way to fix this rampant neglect of security is to turn everything off and then allowing the user to enable/disable access relating to features user requires. Ultimately it should be the responsibility of the phone owner. At the moment, the big switch is just too wide much like Windows XP where most people were using it without security.

XmlSerialization - why two runtime behaviour for class with read-only properties?

Following on from the previous blog post, and just to recap, there are at least two ways to write a class with read only property.

The old way is:

    [ Serializable ]
    public class PersonReadOnly {
        String m_Name;
        Int32 m_Age;

        public String Name {
            get{ return m_Name; }
        }
        public Int32 Age { 
            get{ return m_Age; }
        }

        public PersonReadOnly() {
        }

        public PersonReadOnly (String name, Int32 age) {
            this.m_Name = name;
            this.m_Age = age;
        }
    }

and the other way is to use private setter like this:

    [ Serializable ]
    public class PersonReadOnly1 {
        String m_Name;
        Int32 m_Age;

        public String Name {
            get{ return m_Name; }

            private set { m_Name = value; }
        }
        public Int32 Age { 
            get{ return m_Age; }

            private set { m_Age = value; }
        }

        public PersonReadOnly1() {
        }

        public PersonReadOnly1 (String name, Int32 age) {
            this.Name = name;
            this.Age = age;
        }
    }

These two classes functionally are the same. However, the XmlSerializer exhibits very different behaviour depending on how you write the class. This to me seem rather odd.

In the case of PersonReadOnly, there is no runtime exception, except that the state of the class, namely Name and Age, are not serialized as in agreement with the specification. So when the stream is deserialized, the values of Name and Age are that of the null and 0, respectively. Fair enough!

But when one writes the class as in the style promoted in PersonReadOnly1, the runtime behaviour is radically different. XmlSerializer throws the following InvalidOperationException, which is caused by the exception in sgen.exe,

System.InvalidOperationException: Unable to generate a temporary class (result=1).
error CS0200: Property or indexer 'TestSerialization.PersonReadOnly1.Name' cannot be assigned to -- it is read only
error CS0200: Property or indexer 'TestSerialization.PersonReadOnly1.Age' cannot be assigned to -- it is read only

   at System.Xml.Serialization.Compiler.Compile(Assembly parent, String ns, XmlSerializerCompilerParameters xmlParameters, Evidence evidence)
   at System.Xml.Serialization.TempAssembly.GenerateAssembly(XmlMapping[] xmlMappings, Type[] types, String defaultNamespace, Evidence evidence, XmlSerializerCompilerParameters parameters, Assembly assembly, Hashtable assemblies)
   at System.Xml.Serialization.XmlSerializer.GenerateTempAssembly(XmlMapping xmlMapping, Type type, String defaultNamespace)
   at System.Xml.Serialization.XmlSerializer..ctor(Type type, String defaultNamespace)
   at System.Xml.Serialization.XmlSerializer..ctor(Type type)
   at TestSerialization.TestXmlSerialization.SerializeClassWithNonPublicSetter_PersonReadOnly1() in E:\Projects\SerializationDemo2\TestSerialization\TestXmlSerialization.cs:line 74

The question is: should CLR exhibit the same runtime behaviour regardless of how the class is constructed?

XmlSerializer - Difference in runtime behaviour between MS .Net and Mono runtime

There are several ways to define a class in C# with read-only properties.

You could define it like this:

    [ Serializable ]
    public class PersonReadOnly
    {
        String m_Name;
        Int32 m_Age;
        public String Name {
            get{ return m_Name; }
        }
        public Int32 Age { 
            get{ return m_Age; }
        }

        public PersonReadOnly()
        {
        }

        public PersonReadOnly (String name, Int32 age)
        {
            this.m_Name = name;
            this.m_Age = age;
        }
    }

This is the good old way of doing it. When this class is serialized using Xml Serialization, the values of the properties are not serialized.

Alternately, you can declare one with a private setter or using the auto-generated property syntax with private setter, like this:

    [ Serializable ]
    public class WithAutoPropertyReadOnly
    {
        public String Name { get; private set; }
        public Int32 Age { get; private set; }

        public WithAutoPropertyReadOnly() { }

        public WithAutoPropertyReadOnly( string name, Int32 age )
        {
            this.Name = name;
            this.Age = age;
        }
    }

The end result of this class WithAutoPropertyReadOnly is to produce private setters for properties Name and Age.

While WithAutoPropertiesReadOnly and PersonReadOnly classes are functionally the same, the runtime treatments in CLR (MS .Net) and Mono runtime are very different.

CLR and Mono differences
The Mono runtime used in this experiment is version 2.10.8.1 hosted in Ubuntu 12.04 LTS).

When one tries to construct an XmlSerializer object for the class WithAutoPropertiesReadOnly class, like this:

       XmlSerializer ser = new XmlSerializer( typeof(WithAutoPropertiesReadOnly) ); 

CLR runtime throws an exception of type InvalidOperationException while Mono blissfully serializes and deserializes with XmlSerializer in defiant of the specification.

This is dangerous as it introduces runtime differences that can affect cross-platform compatibility. Irrespective if the above piece of code is run in CLR or Mono, the same runtime behaviour should result.

This anomaly between CLR (runtime 2.0 & 4.0) and Mono only manifested by the presence of non-public property setter. In fact, the exception thrown in CLR is due to the runtime exception thrown by sgen.exe when the runtime tries to generate the temporary serialization DLL.

There is no disagreement when trying to serialize the class PersonReadOnly; both CLR and Mono yield the same result that the values for the properties are not serialized in Xml Serialization.

A bug in Jorte Calendar - Always showing am in the Task popup

This is clearly a bug in Jorte Calendar version 1.5.10 running in Android 4.x.

If you create a Task and assign the start or/and end times as somewhere in the pm, in the brief view, shown here, it always shows am:

Notice the time circled in red.

If one goes ahead and edit this task, the full editing view shows a different story:

The times are clearly defined as in the pm and not in the am. In fact, regardless if one defines the time as am or pm, the brief version dialog box always shows am.

It therefore appears to show that the programmer has failed to parse the times and to choose the am or pm at all! It seems they have left that at the default, which I guess is the am.

While this Calendar app is one of the better ones in the Google Play, its user interface leaves plenty to be desired. For example when defining time, why put the AM/PM selector on the left hand side of the numeral where most others by convention and by standard putting it on the right?

Back to the drawing board and hopefully someone will test it properly and while at it, put the AM/PM selector on the right hand side of the numerals please. Or better still in the locale correct location.