As technology continues to evolve and push boundaries some of that newer technology inevitably raises concerns about privacy. As developers there is a level of moral ethicality we are responsible for upholding. The balance between creating a richer experience for users whilst avoiding deliberate invasion of their privacy.

Unfortunately, for many without deeper involvement in technology and the internet they are casually unaware of what newer technology has afforded to developers.

Ever since Version 6 of Flash in March 2002 we've had Local Storage Objects (LSOs) or "Flash Cookies". It wasn't until a study conducted by Ashkan Soltani (UC Berkeley) in August 2009 revealed the possibility, and extent of privacy exploitation. Wired Magazine followed up with this article: You Deleted Your Cookies? Think Again!. A wave of litigation followed in 2010 with plaintiffs bringing cases against companies like Nordstrom.

Norstrom are now very careful to note in their Privacy Policy:

We may use Flash Cookies (also known as Local Stored Objects) or other similar technologies.

- http://shop.nordstrom.com/c/nordstrom-com-privacy-policy

Flash Cookies, original intended as a method for storing Flash game data, quickly gave way to marketing/privacy exploitation.

This practice is still in use today. YouTube, eBay and Google to name a few, although litigation has forced some level of moral accountability. Now dwindling with the lack of support for Flash on mobile devices, that practice is moving onto newer technologies. HTML5 API's notably: Local Storage, Session Storage and IndexedDB capabilities.

Local and Session Storage are similar in a lot of respects, except that Session Storage, as the name suggests, only holds the data for the current session. These API's afford developers the capability of storing data client side. You can begin to see how easy this is to escalate and already some major platforms like Facebook are leveraging this technology.

Local Storage affords benefits over traditional Cookie use. Whereas Cookies are primarily for reading server-side, Local Storage is primarily for reading client-side affording developers the benefit of not wasting bandwidth sending information between server and client. Important in mobile applications. Additionally; data is much more persistent and this is where the possibility of privacy exploitation comes in. Storing data in a way that profiles users online habits, useful for targeted advertising but at what cost to privacy? IndexedDB takes it one stage further.

Local Storage and IndexedDB are also similar in a lot of respects, this excerpt from Wiki addresses the differences:

On the surface the two technologies may seem directly comparable, however if you spend some time with them you'll soon realize they are not. They were designed to achieve a similar goal, client side storage, but they approach the task at hand from significantly different perspectives and work best with different amounts of data.

localStorage, or more accurately DOM Storage, was designed for smaller amounts of data. It's essentially a strings only key - value storage, with a simplistic synchronous API. That last part is key. Although there's nothing in the specification that prohibits an asynchronous DOM Storage, currently all implementations are synchronous (i.e. blocking requests). Even if you didn't mind using a naive key - value storage for larger amounts of data, your clients will mind waiting forever for your application to load.

indexedDB, on the other hand, was designed to work with significantly larger amounts of data. First, in theory, it provides both a synchronous and an asynchronous API. In practice, however, all current implementations are asynchronous, and requests will not block the user interface from loading. Additionally, indexedDB, as the name reveals, provides indexes. You can run rudimentary queries on your database and fetch records by looking up theirs keys in specific key ranges. indexedDB also supports transactions, and provides simple types (e.g. Date).

At this point, indexedDB might seem the superior solution for every situation ever. However, there's a penalty for all its features: Compared to DOM Storage, its API is quite complicated. indexedDB assumes a general familiarity with database concepts, whereas with DOM Storage you can jump right in. If you have ever worked with cookies, you won't have an issue working with DOM Storage. Also, in general you'll need to write more code in indexedDB to achieve exactly the same result as in DOM Storage (and more code == more bugs). Furthermore, emulating DOM Storage for browsers that don't support it is relatively straightforward. With indexedDB, the task wouldn't be worth its time. Lastly, before you dive into indexedDB, you should first take a look at the Quota API.

- http://programmers.stackexchange.com/questions/219953/how-is-localstorage-different-from-indexeddb

Curious to see what's being stored locally?

Fortunately there are tools and methods out there for the curious minded.

• LSO browser plugin for FireFox
• Most newer web browsers come with "Developer Tools". Usually under "Tools". With this feature active most tool sets will let you explore localStorage, sessionStorage and indexedDB data

Further Reading

• Session Storage
• The Past, Present & Future of Local Storage for Web Applications
• IndexedDB - Performance Comparisons: Part 2

In an effort to thwart large-scale account compromises many online resources now offer "Two-Step Authentication" in addition to their traditional login authentication models.

Most major banks now offer this to their online customers as do most of the major tech' power houses (Google, Microsoft et al) when authenticating to their services. Usually it's buried pretty deep in your account settings, but with large-scale compromises becoming more common "Two-Step Authentication" is slowly (until we have efficient and reliable biometric authentication), becoming the norm'.

One nifty little app' that Google have (available for both Droid in "Google Play" and iOS in the "App Store") is called Google Authenticator. At the heart of it is a Time-based One-Time Password (TOTP) token system.

Using the advanced two-step authentication settings of Microsoft, Google and other your other online services, you are able to establish a connection between your device (the application) and your online service using a traditional QR code. Now, when logging into your online service of choice, not only will you have to authenticate with a traditional password but also the TOTP token displayed in Google Authenticator on your mobile device.

Also, don't worry if your device is lost or stolen. You can revoke a devices access to Google Authenticator by removing those privileges in your online account settings for each particular service.

Update: In an article published by the BBC, it now seems that the US and Israel were behind Stuxnet. Read Article.

... the first (Malware) to target the industrial equipment used in power plants and other large scale installations.

; this seemingly innocuous story caught my attention last Friday (Nov 19th).

A "Worm" made of three distinct components; a very complex ability to control PLC's (Programmable Logic Controllers) used in large scale industrial applications, an ability to distribute and replicate itself and lastly a method for it's creators to communicate with it.

What makes the story interesting though is the implications that it brings about if true. The article goes on to claim that the programming logic left behind several important clues in tracing it's origins. Tom Parker of security firm Securicon went on to suggest that the PLC component was possibly the work of a contracted coder from the West whilst the latter 2 components that dealt with distribution and control were added later with less advanced code, implying that the Worm was the work of "a Western nation" rather than high-tech criminals.

Arousing the conspirator in me you could debate several conclusions. The implications: A "Western nation" contracted PLC programming logic from a third-party and then developed it's own distribution and control logic. PLC logic has the potential to control the operation of pumps and motors in large industrial scale applications; most notably centrifuges, an important component in Uranium enrichment.

Referred to as "Stuxnet", the Worm has since been associated with Iran's continuing Uranium enrichment problems. Now think about it. Most NATO countries (particularly Western countries) have issues with Iran pursuing Uranium enrichment citing a possible nuclear weapons program as the real reason for it's continuing nuclear program. A Western nation has been suspected of contracting the PLC component and it's method of distribution.

Could a Western nation be trying to sabotage Iran's ability to successfully enrich Uranium? Recently Western nation's have become very nervous of Iran and North Korea's nuclear programs. Only just today the U.S. sent Stephen Bosworth as "Special Representative for North Korea Policy" to North Korea to investigate claims of a possible North Korea/Iranian connection.

The U.S. is openly public about it's skepticism towards North Korea and Iran's nuclear programs, so much so that sanctions and embargoes were levied on Iran.

Is this Malware a contracted attempt to ensure that a "Western nation" could retain control over the debatable intent of other nations nuclear enrichment programs? To spy on other nations nuclear programs?

Could Iran or North Korea have planted this Malware themselves to grow momentum and support against the West's over site of their nuclear programs?

Whilst Iran and North Korea are a decade or more, I hope, away from Uranium enrichment and "plausible" nuclear weapons, it stills makes me a little nervous of the outcome if these implications are true. Could we have another potential Cold War era?

We can all take a guess as to where the U.S's largest satellite, launched today and, ironically, replacing "a slew of Cold War-era satellites", will be heading! : -)

Further Reading

• BBC - Stuxnet 'hit' Iran nuclear plans
• BBC - Code clues point to Stuxnet maker