Application Development and BYOD

I read an article a while ago in InforWorld entitled, “The unintended consequences of forced BYOD.” The Bring Your Own Device (BYOD) phenomenon will only gain in strength because more people are using their mobile devices for everything they do and corporations are continually looking for ways to improve the bottom line. The push from both sides ensures that BYOD will become a reality. The article made me think quite hard about how developers who work in the BYOD environment will face new challenges that developers haven’t even had to consider in the past.

Of course, developers have always had to consider security. Trying to maintain a secure environment has always been a problem. The only truly secure application is one that has no connectivity to anything, including the user. Obviously, none of the applications out there are truly secure—the developer has always had to settle for something less than the ideal situation. At least devices in the past were firmly under IT control, but not with BYOD. Now the developer has to face the fact that the application will run on just about any device, anywhere, at any time, and in any environment. A user could be working on company secrets with a competitor looking right at the screen. Worse, how will developers legal requirements such as the Health Insurance Portability and Accountability Act (HIPAA)? Is the user now considered an independent vendor or is the company still on the hook for maintaining a secure environment? The legal system has yet to address these sorts of questions, but it will have to do so soon because you can expect that your doctor (and other health professionals) will use a mobile device to enter information as well.

Developers will also have to get used to working with new tools and techniques. Desktop development has meant working with tools designed for a specific platform. A developer would use something like C# to create a desktop application meant for use on any platform that supports the .NET Framework, which mainly meant working with Windows unless the company also decided to support .NET Framework alternatives such as Mono (an open source version of the .NET Framework). Modern applications will very likely need to work on any platform, which means writing server-based applications, browser-based applications, or a combination of the two in order to ensure the maximum number of people possible can interact with the application. The developer will have to get used to the idea that there is no way to test absolutely every platform that will use the application because the next platform hasn’t been delivered yet.

Speed also becomes a problem for developers. When working with a PC or laptop, a developer can rely on the client having a certain level of functionality. Now the application needs to work equally well with a smartphone that may not have enough processing power to do much. In order to ensure the application works acceptably, the developer needs to consider using browser-based programming techniques that will work equally well on every device, no matter what level of power the device possesses.

Some in industry have begun advocating that BYOD should also include Bring Your Own Software (BYOS). This would mean creating an environment where developers would make data available through something like a Web service that could be accessed by any sort of device using any capable piece of software. However, the details of such a setup have yet to be worked out, much less implemented. The interface would have to be nearly automatic with regard to connectivity. The browser-based application could do this, but only if the organization could at least ensure that everyone would be required to use a browser that met minimum standards.

My current books, HTML5 Programming with JavaScript for Dummies and CSS3 for Dummies both address the needs of developers who are looking to move from the desktop into the browser-based world of applications that work anywhere, any time. Let me know your thoughts about BYOD and BYOS at John@JohnMuellerBooks.com.

 

Is Privacy a Right?

One of the readers of C# Design and Development took me to task some time ago for not discussion the matter of security in my book. He has been the only reader to ever ask me about the issue of privacy, so I didn’t think too much about it at the time. When I wrote the book, I thought it far more important to discuss security—keeping the data, application, and user safe. In fact, the book makes security part of an application triad the developer must consider during the design process. My thinking at the time was that privacy is a matter settled by management as part of a policy that is often implemented outside the developer’s control. To a certain extent that perception is still valid, but I’ve since learned that the developer does bear some responsibility toward the user when it comes to privacy.

A recent ComputerWorld article has made me think yet again about the whole issue of privacy. In this case, OnStar is collecting absolutely every last bit of information they can about you, without your permission, and selling it to anyone with a few pennies to spend. (A later article says that OnStar is reversing course on this decision.) They do tell you about spying on you, but you’ll only find this information if you read through the legalese contained in the Terms & Conditions. However, there are some people who don’t think you have any right to privacy in the first place. Industry leaders that include Facebook chief Executive, Mark Zuckerberg, Google chief, Eric Schmidt, Sun Microsystems chief, Scott McNealy, and Oracle chief, Larry Ellison would prefer you not to have any privacy whatsoever. They’d simply love to dig into every aspect of your life. The use of newer technologies, such as super cookies, have also proven that companies have a strong desire to invade your privacy.

So, the developer is faced with a number of questions when it comes to privacy. The most important of which is whether privacy is a right. According to the ComputerWorld article, the senate has finally woken up and decided that perhaps privacy is a matter they really should consider, especially when it comes to such brazen violations such as the one by OnStar. There is some validity to the belief that the Constitution and Bill of Rights offers at least some protection of privacy. Some laws, such as the Health Insurance Portability and Accountability Act (HIPAA) add additional rights. However, I imagine that we’ll experience years of delays, political wrangling, and legal interpretation before those rights are specifically spelled out in a way that developers (and others) can understand.

Assuming that a certain level of privacy is a right and that it’s legally protected, the developer still has a host of questions to answer. Here are some of the things you should think about as a developer when designing an application.

  • What is the company policy regarding privacy?
  • How does an application specifically guard or expose a user’s privacy?
  • When does a user’s right to privacy override the desire of management to invade it?
  • Which rights does a user forfeit as a member of an organization?
  • Is privacy configurable as an opt in or an opt out selection?
  • Precisely what information does the company collect?
  • Precisely what information does the company actually need to conduct business?


If the developer of the OnStar system had included a simple switch for turning the device off (disallowing any eavesdropping of any sort), the whole issue discussed in the ComputerWorld article would be moot. Unfortunately, no one thought to include such a switch, despite the fact that it would have been an obvious design addition. Of course, we don’t need to look specifically at OnStar as a bad example of privacy thwarted. Many applications today include a “call home” feature and won’t even work if you don’t have an Internet connection. In short, someone somewhere is spying on you constantly.

When you look for privacy-related design information for the developer online or in books, you find it mysteriously missing. The reader who called my book into question was right to do so. I hope that this small article has at least started you thinking about privacy and overcomes the omission in my book. Future posts will fill in some additional gaps, but I’d like to hear your perspective on the issue of privacy first. What questions do you have about privacy? How would you design an application that protects user privacy while meeting organizational needs for information? Let me know at John@JohnMuellerBooks.com.