Author: agup

Dispelling Responsive App Testing Myths

There’s been a lot of buzz about Firefox’s Responsive Design View and to a lesser extent Chrome’s User Agent swapper. These built-in, ready-to-go tools are awesome and huge time savers for web developers. But, they are NOT a substitute for testing your app across multiple browsers and on different devices.

A highly simplified definition of responsive design is it lets your web app dynamically adjust content based on screen height, width and pixel density. There are over a dozen responsive frameworks including Twitter Bootstrap, 960 Grid, jQuery and Titan. The number of them has exploded in recent years and it’s a daunting task to figure out which ones meet your project’s needs. So, the intent of this blog post is to provide some super simple, quick guidelines for getting started with testing your apps against them.

What does Firefox’s Responsive Design View do? It lets you change the dimensions of your application on-the-fly and even rotate it by simply clicking a button. Very cool! It lets you pretend to see what your app will look like on different screen sizes. In the latest versions of Firefox, you can access this view via Tools > Web Developer > Responsive Design View.  See the screenshot for an example of what the tool looks like.

What does Responsive Design View not do? It does not emulate the actual functionality of browsers on different sized devices. So, simply swapping screen sizes on your Windows desktop Firefox browser is not a valid substitute for physically testing your app on a tablet or smartphone. Firefox offers a separate download for Firefox on Android if you want to test on a mobile device.

What does a user-agent do? The user-agent is intended to identify a browser to a webserver or web application. It is sent by the browser in the HTTP request header. The agent can be parsed and used to determine if any specific actions need to be taken within an application. So, if you are using Chrome you can spoof using Internet Explorer 9. Here’s an example of a user-agent for Firefox running on Windows 7 64-bit:

Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20100101 Firefox/16.0

The most common use of user-agents on webservers is for creating site visit statistics that provide a generalized break-down of site visitors by browser type.

The most common use of user-agents in web applications is for determine how content is displayed and how JavaScript may be used in that browser. If you have some JavaScript that you know won’t work in IE, then you want to try and do your best to detect specific versions of IE to control your content.

Why spoof the user-agent? Simply put, it tricks an application into being displayed based on the user-agent characteristics. The key word is “display”. The user-agent spoof does not emulate actual browser functionality. It only shows you what the app looks like if it contains browser-specific code by tricking it into thinking it’s running on a specific browser. However, to properly test full browser functionality you need an actual install of the browser on a specific device and operating system.

Is user-agent detection reliable? In general, no. User-agent detection within your code is not reliable. Because user-agents can be easily spoofed these days, it is no longer a single reliable source for determining how your application will display content. Even jQuery, for example, recommends against relying on user-agents as a sole means of determining browser type.

For JavaScript, it’s usually best to check to see what is supported by a particular JavaScript library, for example in jQuery.

$("p").html("This frame uses the W3C box model: <span>" +
jQuery.support.boxModel + "</span>");

Or, if you are building larger applications consider a special detection library like Modernizr that helps with HTML, CSS and JavaScript coding patterns.

What about CSS3 Media Queries? CSS3 Media Queries are considered to be an integral part of responsive design coding patterns. They let you use CSS to detect certain characteristics of a browser in order to adjust the styling of an application by doing things such as swapping visibility of HTML elements or even adding or removing DIVs from the layout. Using Firefox’s Responsive Design tool or Chrome’s user-agent swapper can be used to test these elements with a healthy dose of caution. You still need to do your final testing for browser-specific functionality on the respective browsers themselves. Here is an example of a media query looking for maximum and minimum screen width:

@media screen and (min-device-width:768px) and (max-device-width:1024px) {
    /* styles go here */
}

You can also run media queries from within JavaScript:

var portraitMatch = window.matchMedia("(orientation: portrait)");
portaitMatch.addListener(orientationChangeHandler);
function orientationChangeHandler() {
  if (portraitMatch.matches) {
    // Portrait orientation
  } else {
    // Landscape orientation
  }
}

Using Media Queries is considered a best practice when used in conjunction with a feature detection library such as Modernizr, or feature detection coding patterns to validate if a CSS feature works on a particular browser.  Feature detection code may be the way to go if you are only detecting a handful of CSS3 attributes and don’t need the extra weight of a full blown library like Modernizr, for example:

if (document.createElement("detect").style.borderRadius === "") {
    //TODO if borderRadius detected
}

if (document.createElement("detect").style.WebkitBorderRadius === "") {
    //TODO if webkitBorderRadius detected
}

Simple steps for avoiding malicious spam emails

This post covers some simple things, in addition to having anti-virus software, that you can do to help prevent accidentally getting tricked by malicious spam email. I’m assuming you already have a full fledged virus checker installed. It was inspired by several friends and family members that aren’t particularly technically savvy, and they got infected via email.

It’s a fact that there are some potentially important emails that look absolutely legitimate at first glance. And, criminals are getting better every day at copying the look-and-feel of legitimate and highly recognizable companies. Four to five years ago, security experts instructed us to simply delete any email that seemed fraudulent. However, flash forward to 2012 and there is a chance you may be deleting a legitimate email.

How could I get infected when I have a virus checker?

Having a virus checker simply minimizes the chances of being infected. And, even major online email services can be fooled. Sorry to break the news, but virus checkers aren’t 100% effective.

Here’s one example and there are many, many more. Let’s say you have set up your bank account to send you monthly statements via email. Sounds reasonable enough, right? Well, recently I’ve seen some very convincing looking spam emails that did a really decent job of mimicking legitimate emails from a bank. The good news is there were a few things in the email that made me suspicious and fortunately I followed my suspicions and didn’t click on any of the links. One particular well done email came under the guise that the password had been changed on an account, and in fact it had been changed. How’s that for coincidence?

Two easy steps.

Step 1 is to use an email client that allows you to turn off the message preview feature. There are infectious agents out there that can nail you through JavaScript and HTML code that is run when the email is viewed via preview mode. One recent example was dubbed “Drive-By spam” by security experts. Another option it to use “text-only” mode, but for most of us text only messages are really boring and ugly to look at, and you also lose all images and styling.

Step two is view the message source code and look for links where the domain name does not match the domain name of the company that sent you the email. If there is anything suspicious then use the phishing reporting feature in your email service. DO NOT open the email, dude.

Now, criminals can change malicious URLs faster than anti-virus software vendors can keep up. So, everything in an email may look legitimate with the sole exception being the link they ask you to click on that could lead to a harmful website.

Step three is if you want to dig even deeper you can verify if the senders IP address is legitimate using an IP address lookup service. The senders IP can be found in the header information of the email source. If the email is sent from a block of computers not registered with the correct company name then I’d be highly suspicious. All legitimate and important emails should always originate from a company’s domain name. If it didn’t then there’s a really good chance it’s marketing related and trying to sell you something, or its hostile.

A note about your spam folder. I have actually received legitimate emails from banks that ended up in the spam folder because I forgot to put let my email client know email from that domain was legit. It was human error and it happens. So, simply saying I shouldn’t have opened it because it was labeled as spam isn’t 100% true. But, it is an indication that you need to proceed with caution. I agree that in general all the emails that are placed in a spam folder by your email vendor are actually 100% certifiable spam. But, human nature makes us curious especially when it appears to come from a legitimate source. The good news is you can still be curious and protect yourself by following these three steps above.

What does hostile email source code look like? It can actually look very much like a real email in the source code. Looks for the code specifically related to things such as links for “Getting Started”, “Log in”, and “Click here for more information”. Hopefully you get the idea. It will be wrapped inside a tag called “<a href=”, and if you are a software developer you already knew this.

Hostile code can also be downloaded through JavaScript. It’s much, much harder to detect hostile JavaScript code because it may have already run when the email was viewed. One option that’s not appealing to most people is you can disable JavaScript in your browser when using browser based clients. The downside is this makes browsing the web an awful experience because much of the dynamic nature of modern websites is driven by JavaScript.

As I mentioned above, some criminals are getting better at re-using templates from legitimate emails. So I’ve received email where all the logos, banner images and help links pointed to real and legitimate sources. In fact, in a recent phishing email that seemingly came from a well-known bank, everything looked perfect except for the code tied to the getting started button. Even the “reply-to” email address was correct.

Here’s an example of an email supposedly from a major, name brand bank where I have obfuscated the URL for security:

<a href="https://--some other non-bank website name---.com/spa---/"><b>Click here to get started</b></a></p></font></td>

Here’s what the header of the email looked like, it’s also been obfuscated:

x-store-info:4r51+eLowCe79NzwdU2kR...
Authentication-Results: hotmail.com; sender-id=softfail (sender IP is 70.---.---.142)
header.from=AmericanExpress@---.com; dkim=none header.d=welcome.---.com; x-hmca=fail
X-SID-PRA: AmericanExpress@---.com
X-DKIM-Result: None
X-SID-Result: SoftFail
X-AUTH-Result: FAIL
X-Message-Status: n:n
X-Message-Delivery: Vj0xLjE7dXM9...
X-Message-Info: uTMDiBlPf5+Op9WrkKVGnq8+zr4Yfrs3...
Received: from server.DRGARCIA.local ([70.---.---.142]) by ... with Microsoft SMTPSVC(6.0.3790.4900);
Wed, 17 Oct 2012 07:11:24 -0700
Received: from USER ([198.--.--.35]) by server.DRGARCIA.local with Microsoft SMTPSVC(6.0.3790.4675);
Thu, 27 Sep 2012 12:20:10 -0500
Content-Type: text/html
SUBJECT: Important: Notification of Limited Account Access

FROM: American Express &lt;AmericanExpress@---.com&gt;

Bcc:

Return-Path: AmericanExpress@---.com

How to view an email source using Gmail or Outlook.com? In Outlook.com you can simply right click on any email and select “view message source”. In Gmail, you have to open the message and in the Reply options pull down list select “view original”.

I use Outlook.com (formerly Hotmail) because it lets you view a messages source code without having to first open or preview the email. On the other hand, Gmail forces you to open the email first, and then you can view its source code. Simply by opening or previewing a potentially hostile email can allow malicious code to be installed on your computer. This seems like a major security hole to me.

Conclusion. If you have an email in your inbox or spam folder that looks legit and you absolutely have to open it, then the two steps listed above should help protect you, your computer and your data. Criminals are getting better every day at creating the illusion that an email is totally real. And, if you know how to read the source code of the email you can potentially avoid an infected computer.

DISCLAIMER. Of course I have to have a disclaimer these days. The contents of this post do not 100% guarantee that you still won’t be tricked into doing something unintentional that causes personal trauma, data loss, catastrophic damage to your hard drive or even cause kittens to purr. If followed properly, these steps will significantly improve the safety of your computer and electronic data. But, hey…even experts can be tricked!

You should also have anti-virus software installed and up-to-date. Yes, some virus checkers offer email protection of sorts and that should also be enabled. I’m also here to tell you that some viruses can and will slip through that protection. Sometimes, when a virus, Trojan, worm etc. infects your computer it takes hours to remove it, or in drastic cases you have to completely rebuild your system.

Going mobile Part 2 – dealing with legacy content

This is part two in my “Going Mobile” series. As some you know I’m migrating my website to work on all smartphones and tablets. It’s been a really fun process, especially since at my day job I usually consult on how to do this. So, it’s been great to actually sink my teeth into my own full-blown project that also includes a content management system.

As I’ve mentioned before, I have almost 100 posts to manage through this transition along with a variety of plugins and hundreds of images. This site is not custom so upgrades and changes should be fairly routine.  What I mean is it’s a fairly run-of-the-mill WordPress installation so there isn’t anything really fancy or complicated about it. And, that’s the way I like it so it just runs itself without much maintenance or intervention.

So, I’m still in the preparatory phase of migrating over to mobile. There’s been a lot more things to deal with than the typical applications that I build. Here are some of the issues I’m working through now:  

Images not optimized for mobile. I have hundreds of images that I pasted into blog posts. Some of these are up to 400 pixels wide, which covers most of the screen for your average smartphone. Perhaps some good news is all of my images are PNG format, but they were intended for use on 1024×768 or greater monitor sizes. Now, if I change the size of these it could affect my default page formatting. I tried to avoid that type of problem in the very beginning in terms of how my images are placed on the page, but we’ll see. I’m still experimenting on what do, and in my estimation it all comes down to performance. If anyone has any recommendations let me know?

Web Server Permissions. My blog hosting provider is fairly strict on the server configurations and the mobile plug-in model requires server-side access. I basically traded some access for massively reliable uptime.  There have been some issues with the mobile plug-in and how it works with various pieces of WordPress, PHP and the web server itself. If you work for an organization with full admin access to your web server then this shouldn’t be much of an issue.

Blog post length. I have some long blog posts that require a bit of scrolling. I don’t know if there is a right or wrong answer on the appropriate length of a non-paginated blog post. Personally, I hate paginated websites and as a default I expect to get the full article. I read a few blogs already on my phone and while I don’t mind scrolling down I’ll have to see what kind of feedback I get from visitors and regular readers.

Cross-browser testing. With my current blog, I’ve never ever had to worry about cross-browser testing. WordPress just works, period. I’ve occasionally received browser-related complaints. However, after some investigation the majority of the complaints were spam emails try to trick you into clicking on a hostile link. Once I get everything up and running I’ve created a simple test sheet with various check-off items to make sure I’m (mostly) comfortable and can sleep at night knowing I didn’t just hose things up dramatically.

Plug-in compatibility with WordPress upgrades. This is a major concern. I like building my own software because I can adapt it to any underlying changes. With a plug-in you are at the mercy of the plug-in vendor and your content management system. My fallback plan for this is I can always disable the plug-in. For now while I’m in the experimenting phase, my blog foundation will remain fixed and designed for 1024×768 content. Ah yes good old 1024×768. So, if I do pull the plug on the plug-in (no pun intended) then in theory everything should revert back to my default theme until I can figure out a fix or move on to a more responsive design approach.