After ZDNet's Tech Shakedown, Nike buttons up the security on its Flash-based payment pages

A few weeks back, I did a Tech Shakedown of the Flash-based payment pages on Nike's online store which lacked the Net's accepted practice of connecting Web browsers to HTTPS-based URLs, thus resulting in the display of a padlock somewhere in a browsers' status bar.  These are the two visual queues that online shoppers are routinely urged to look for before sending personal information or credit card data to any Web site through a Web page.

In the case of Nike's payment pages, the intitial entry point into the Flash-based user interface was through HTTP instead of HTTPS (the secure, encrypted version of the Web's primary protocol).  Once in that Flash-based interface, communications between the UI and Nike's servers did in fact switch to HTTPS (as I showed with a protocol analyzer in a video that went with my initial Tech Shakedown) when it came time to transmit what would normally be confidential information.  But, buy not switching to an HTTPS-based URL or displaying the padlock, Nike was essentially defying some of the most important best practices that e-commerce sites are encouraged to follow in order to build consumer security and confidence in online shopping.

If more sites followed in that practice, the value of having HTTPS in the URL field and the padlock in the status bar would be completely undermined with the net result being that, unless you had a protocol analyzer like I do, there'd be no way to tell which sites are secure and which aren't.  If we ever got to that point, the likelihood that online shoppers might insecurely submit personal information to a Web page would increase substantially. Eventually, the Web would get labeled as being insecure even though that really wouldn't be the case.

In the wake of that shakedown, it now appears as though Nike has fixed it's Web site to reflect HTTPS in the URL and the padlock in the status bar even though the pages are still Flash-based.  Its method for doing this is a redirection to a new HTTPS-based URL once the time comes to start submitting personal information.  So, from a coding perspective (for all you site designers looking to build richer end-to-end shopping experiences), this means leaving one Flash-based execution environment (the part started over HTTP where shoppers are browsing online and loading their shopping carts) and entering another Flash-based environment through an HTTPS-based URL. Being able to do this sort of switcheroo so it takes place as transparently as possible to the user is the trick and Nike has definitely managed that pretty well.

While my fellow blogger George Ou has the details on Nike's change to its Web site, I tested the user interface and Nike has indeed done a good job bridging between two distinctly separate Flash-based execution environments (1) without the need to launch a separate browser tab, and (2) without losing the user's shopping context  in the event the browser's back button is pressed.  It's nicely done and it's evidence that shopping experiences can be built from beginning to end in rich interactive runtimes like Adobe's Flash without losing some of the traditional security accoutrement that online shoppers will be looking for.