7 tips for safe surfing while traveling

I’ve been asked many times how do I safely use the internet while traveling. Here’s a summary of my notes that will significantly reduce the possibility of having your identity, credit card info or online credentials stolen. None of us are 100% vigilant and fool-proof especially during the haste and confusion of modern day travel. These are all simple suggestions that can provide you with peace-of-mind.

No free Wifi. Avoid free Wifi if at all possible, period. Being cheap can end up costing you a lot. In my humble opinion, the risks of free Wifi when you are traveling simply aren’t worth it. For more details keep reading and I also offer suggestions to protect your online presence if you have to use free Wifi.

Use 3G or 4G.  Instead, I recommend you use your cellular data plan, tethering or buy a cellular hotspot. Generally speaking, 3G and 4G is more secure than Wifi because the equipment to crack it is significantly more expensive and heavily regulated. If you travel to a foreign country you can also buy phones with short term rental contracts, or if your phone uses a SIM card you buy one of those with a data plan. This may cost less and provide a greater amount of data allowance than having your existing provider activate international roaming.

Verify Wifi SSIDs. If you have to use Wifi, have hotel staff or restaurants/coffee shops write down the SSID number of their free Wifi. That way you are sure to log in to the correct network. The fastest way to get virtually compromised is to accidentally log into an increasing number of fake networks specifically designed to steal credentials. If you aren’t an expert in network security, and that’s the vast majority of us, then you may not know this happened until it’s too late.

Use a VPN. Considering using Virtual Private Network or VPN software. Most companies offer these to their business travelers. Consumers can use these as well, and an example of that is proXPN which has both free and paid options: https://www.proxpn.com. A VPN encrypts your traffic and helps to double protect user names, passwords and content. Look for VPNs that protect not just internet traffic but instant messaging and any other software you may be running such as Skype. The proXPN paid version protects all traffic on web clients and mobile devices, where the free version only protects basic internet surfing. Paid versions also typically provide better surfing speeds than free versions.

Use Tor. Check out the Tor browser for general surfing as it provides you with a decent measure of security against criminals snooping your email or online purchases. If it’s legal for the country you are in, consider installing Tor: https://www.torproject.org/. Recent versions work on Android devices, as well. And, Tor can be used along with some VPNs for even greater levels of security. Not every online vendor that you use is practicing 100%, up-to-date perfect security practices.

Verify HTTPS. Make sure your email connections are using HTTPS. Most browsers have indicators or lock symbols that indicate a secure connection, the most important thing to look for is HTTPS in the URL of the website. In some circumstances this may not protect your username and password but it’s better than no encryption. It will help to protect the contents of your email. Without HTTPS everything you send will be in clear text for bad guys to easily read as a road-side billboard.

Use pre-paid credit. Use a pre-paid credit card for any online transactions while your traveling, for example MasterCard offers these. Doing this can help protect your main credit card for emergencies. If you have to pay for something via the internet it’s much safer to use a pre-paid credit card that has a finite amount of money that you can lose.

Last Words

The good news is that new forms of authentication, such as two-step authentication, are being increasingly used and definitely help reduce the possibility of account hijacking. Having your credit card number stolen while surfing, however, poses immediate challenges unless you happen to carry around a ton of cash with you all the time. Employing the methods above while you are away from home easily provide an extra layer of security to make sure you get home safely and on time with as little disruption and stress as possible.

Web developers: 10 ways to deal with intermittent connections

This post is about web applications designed for online-only usage that for reasons beyond your control will occasional go offline, or appear to have connection problems to non-techy end users. Even though we expect it, connectivity is not guaranteed. The good news: there are many things that you can control to help improve the usability of your sites and the perception of its uptime.

The Internet is inherently unreliable and it goes up and down as well as faster and slower all the time. It’s even more unreliable if you are talking about mobile web as compared to being plugged into a dedicated Ethernet or WiFi connection. Failures can happen within the app, on the Internet connection and even at the web server or CDN and when it happens it can frustrate users and eventually turn them into unhappy customers. The challenge for you as web developers and IT managers: it’s often hard for the people managing websites to get a real good look at the end-user experience because it can be so hard to duplicate.

In general most users typically blame their “internet connection” which is a euphemism for it’s the cellphone providers fault or the DSL or cable company’s fault. And, most people don’t know or really care where the problem is, they just want it fixed.  A common reflex when there is a problem is for a user to simply reload the entire page. In some cases, a full page reload isn’t possible or it’s painful such as more complex sites where a full reload means potentially walking about through several steps to get to back to the final page or view.

So here are a few suggestions to you, as a web developer, to help minimize occasional disruptions and keep users as happy as possible. Some of these are major repeats but they are well worth seeing yet again:

Performance. Make your web pages as lightweight as possible. Pages that load faster will ‘appear’ to be more responsive to requests even if you aren’t concerned about millisecond response times. Most of you will have already had this drilled into your head over and over: The goal should be fewer and smaller files, using CDNs, moving CSS and JavaScript library loading operations to the bottom of your html pages, use inline images and the list goes on and on. There are many articles on the web about improving performance. Search for ‘website performance’ to find out more. Another example, Steve Souder has an excellent website and even written books on the subject.

Caching. Consider page cache settings carefully. The subject of setting header caches, such as ETags, Expires and Last-Modified headers, is often overlooked and usually misunderstood. Cached content cuts down on the total number of HTTP requests when someone loads your web page. Static content, or content that doesn’t change much, usually has longer cache times than content that changes frequently.  Even though there are many articles on the web about caching, doing it well can be tricky. It can be very handy to hire an expert to figure out optimal configurations in a short period of time. Or in my case, I spent several months of experimenting while subjecting my blog readers to unnecessary page lag, and variety of other problems, until I finally broke down and hired an expert.

HTTP requests that block. Be aware of any HTTP operations that block the loading or use of your pages.  If you have to use a blocking HTTP request then make sure you set a timeout in the client request, such as 20 seconds and display some sort of a loading icon. A good web designer can help walk you through the UI experience. Most modern web servers have server-based timeouts that are longer than most people are willing to wait.

Auto-retry. Alternatively, consider a significantly shorter HTTP timeout setting and retry the connection several times before failing and notifying the user that the app couldn’t connect. These days a single 404 error doesn’t necessarily mean the website is down. But…very, very few websites employ this pattern. So what happens in response is most people reflexively keep hitting reload when there are any loading problems. Reloading an entire page is much more bandwidth intensive on your servers as compared to having the app simply retrying quietly and quickly in the background to load a specific item.

More efficient database polling. Long running database queries can give the impression that the connection is broken. If you have requirements to poll a server-side database for changes, consider implementing a server-based process that simply returns a JSON-based Boolean such as {changes: “false”} if there are no changes. In comparison, most server-side database requests typically run entire and potentially complex SQL queries with every internet request to tell you nothing changed.  From a server resource preservation viewpoint, it’s significantly less overhead to return a simple JSON-based Boolean and let a long-running server side process do all the heavy lifting on a regular timer cycle.

Fail gracefully.  Don’t hang an entire page if your app fails to load a JavaScript library or some other content throws a 404 error, or if a database request fails. Don’t do it. I know this seems obvious, but I see it all the time when doing my daily web surfing. See my suggestions above for handling HTTP requests. Most major companies seem to be guilty of this for activities such as viewing billing pages.  Let the end user know through some sort of a pop-up that a connection has failed or timed out. Native mobile applications have built in mechanisms for doing this, and granted they can auto-detect when the Internet connection goes down, but I still believe regular web apps should mimic the behavior when possible.

ApplicationCache. Consider storing some pages and resources for when a connection goes down by using the HTML5 ApplicationCache interface. This lets you go beyond the typical caching mechanisms using patterns that can be easier to understand and control as compared to the somewhat black box and variable nature of header settings.

Feedback. The ability to email web administrators directly has lost favor over the last five years or so. I suggest bringing this back in a big way, along with clearly posted links. Sometimes the best way to know something is down or slow is to hear it directly and immediately from a customer. Yeh sure, you’ll get some spam email but if it means keeping customers happy then there are both automated and manual ways to deal with it that work. I can speak personally on this topic as my blog has received over 40,000 spam attempts of which I’ve personally deleted over 3,000, and I’m just a team of one. Some techy sites do provide a “Performance” section of their forums, which is fine as long as employees are actually monitoring it (often). The problem with forums is notification of new posts…and, of course, is usually done via email.

Uptime Monitors. Use uptime monitors from different spots around the country you live in, or around the world if you are using a worldwide CDN. Some providers can do this for you, but you should ask questions. The most common scenario I’ve seen is that the update monitor lives in the same server farm as the web server. This is okay but it doesn’t cover the scenario of connectivity outside your firewall. Uptime monitors should not just ping a website, they should also attempt to load and parse actual content, throw a warning email or text message if the content throws an error and throw a warning if a connection takes too long. There are many reasons why you may think your website is up and it’s not. For example, a CDN node could be down, a CDN server could have the wrong permissions, a major Internet router could be down, or your support folks could be using an internal pathway to view pages on your web server that is no longer visible to the outside world. These types of monitors don’t cost much to operate and can significantly boost customer service ratings and help keep customers happy.

Browser Support. Last but not least and probably the touchiest subject is browser support. My recommendation is if you don’t support a particular browser type, then give the end user a message that says some functionality may not work properly. We’ve all been to sites on our tablets or phones, for example, and popups didn’t work right or things didn’t display properly. Non-tech -savvy end users can easily misunderstand these types of things since it rightly gives the appearance that something is broken. If a popup didn’t work it may appear that a sale did not complete, for example. It’s very easy these days to use libraries for browser detection. Doing browser detection should always be part of a web app deployment plan.

Resources

HTTP Caching Protocols (W3C)

What is a CDN?

Beginners Guide to ApplicationCache

Browser support – Caniuse.com

Staying competitive: The costs of rapid technological advancement

There is no doubt that consumers benefit from today’s unprecedented rapid technological innovation in mobile and web. But, there are costs that business incur as a result.

Here’s an overview of some of the costs that you should take into account when building budgets as well as mobile and web strategies. Some have argued that the trend of B.Y.O.D., or Bring Your Own Device, has mitigated some costs to corporations and organizations. That may be true, but after reading this you will probably agree that the costs listed below reach beyond the cost of the actual device. These are all things you have to take into account to stay competitive in today’s hard charging environment.

Hardware turnover.  The advantage here goes to iOS devices. Android devices can become obsolete within six months because cell providers are allowed to provide phones and tablets with customized versions of the Android OS. They essentially lock you into a forced hardware upgrade because you’ll only get one or two minor OS upgrades per device. Your company will have to balance that software it can run on various device operating system versions. Whereas iOS devices, on the other hand, get access to the latest updates. Also, like the traditional PC upgrade path, with mobile devices you may have to upgrade to gain access to greater memory or CPU capabilities.

Code updates. You’ll spend a significant amount of time keeping up with the latest capabilities. It takes time to learn how best to adapt to the latest coding patterns, UI design patterns, and technological advancements.

Reverse compatibility. Some business have a requirement to maintain their code on older versions of browsers and operating systems.  The further back you have to support OS versions the larger the support costs. The larger the gap between the latest versions of SDKs, APIs, devices and browsers and legacy versions the greater the cost.

Security. It can be very challenging to secure smartphones and tablets from physical intrusions and viruses. These breaches can give criminals access to your internal systems. Tracking down security leaks and fixing breaches can be very expensive and time consuming.

Replacement devices. You’ll need to decide whether or not to carry insurance on each device, or take the chance that a device will never get dropped, broken or stolen. Replacement costs are extremely expensive if you have no warranty and no option from the cellular carrier to get a subsidized upgrade.

Poor connectivity. This may seem like an odd cost to list, but poor connectivity can cripple the productivity of a remote workforce. The more reliant an organization becomes on internet connections, especially for real-time systems, the greater the cost that can be incurred when users encounter connectivity problems. Poor connectivity means slow, intermittent or a non-existent internet connection.

Cellular data costs. Another byproduct of being increasingly mobile is dealing with how your architecture handles data transactions between clients and servers. Chatty applications, or applications that move a lot of data back and forth, and heavy web pages, or web pages that are physically large when loaded into a browser, can result in significant internet and cellular data charges.  For example, if your application is 3 MBs and it is accessed 1000 times per day by your workforce, that adds up to 3 GBs of data usage per day.