Two years ago I used Netflorist to buy some flowers, but first I needed to login. I had forgotten my password, so I used the "Forgot Password" option.

In the email I got was my actual password - which shows a MASSIVE problem in the design of the system that Netflorist uses. The password is either:

1. Stored in plain text
2. Encrypted

Why am I talking about it now? Because after two years, Netflorist has not fixed it! They have had the time to fix it, so let’s talk about it & if this info helps some horrible person hack them (& am not suggesting people do that) then tough for them.

What is plain text?

This is plain text - it is just the text. Why is this a problem for passwords? The reason is that if someone gets access to the database (physically, remotely, via hack, restoring a backup etc...) they can see ALL the passwords.

This has low risk for Netflorist since credit card details are not stored but this has a MASSIVE risk for Netflorist customers.

The sad truth is that most people are lazy & reuse the same password across multiple websites, which means the details on Netflorist can be used to commit fraud & theft elsewhere.

Scenario

Netflorist, being a good company, keeps 5 year’s worth of backups off site. Someone at the offsite company accesses those files, restores the DB and gets all the email addresses & passwords for everyone. They then go to TakeALot and log in with those details. Since TakeALot's credit card provider stores credit card numbers the criminal then purchases tons of stuff!

Just imagine the damage that could be done if someone uses the same password for their email & their second factor bank authentication goes to email – all your money is stolen… thanks to Netflorist not doing it right. If that happens and since the bank wasn’t at fault you wouldn’t be able to get the money back from the bank!

Encryption is enough! Right?

So we going to get a little technical now, there is actually many types of encryption (2 way, public/private key) but the core here is that in all cases there is encrypted data & a salt (or key or password - they are all synonyms) is used to decrypt the data.

So if we store the password encrypted in the database, we also need to put the key somewhere so it can be decrypted when the mail is sent out. The issue here is if someone can get access to the database, there is a high chance to get access to the salt too. Once someone has the data & salt - it is plain text.

Yes, this is tougher to do than plain text - but tougher is not the same as impossible.

So how should Netflorist this be fixed?

This is not simple, because we are working with security & doing it correctly isn’t easy. Thankfully OWASP has created some guide to help with this:

• Password Storing
• Forgot password features

In short they should do three things. Note this is the SUPER simplified version. If you are doing this, read the above documents for all the details.

• We do not store the password in plain text or even encrypted. We hash it. Hashing can be think of a way one encryption – so we can take the password + salt and a result (the hash), but we can never go from the hash to the original password.
• The hash relies on a salt too, so we should use a salt that is unique per user. This solves the possibility of rainbow attacks.
• Lastly is “The Forgot Password” system, since we can never get the password back from the hash, it cannot send it to the user requesting the password. The solution is to have a password reset option, where a user puts in some unique info and using a secure channel can put in a new password when they forget their password.

What can you do?

First, communicate with Netflorist (Twitter, email) about this risk and hopefully they fix it. Second, you can lower your personal risk by never share passwords across websites. This can easily be done by tools like LastPass (which manages the passwords for you & ensures strong & unique passwords are used) or find a trick that enables you to easily remember a unique password for each website. For example use a pass phrase like:

• Netflorist could be: This is netflorist222
• TakeALot could be: This is takealot222

It is easy to remember the unique password plus it is a pretty strong password. This is just an example, so come up with your own & be sneaky!

It has been an entire year since my last presentation dump, so following that tradition – here are some of the talks I gave in the last year that were not immediately available:

Protection of Personal Information Bill (POPI)

Description

A short presentation that focuses on the proposed POPI law, how it impacts businesses, technology, IT depts & the cloud. It was based on a draft so some aspects may have changed.

Thoughts

This was a tough talk for me, because the law isn’t something I spend much time focusing on. I spent a lot of time reading the bill & analysis for it and really was impressed how approachable all of it is. This is definitely a law we need to be aware of, but for most companies (who do things correctly now) it will mean either no changes or a slight update to some documents.

Open Source Licensing

Description

This talk focuses on what open source licensing is, how it should be applied inside & outside companies. It also looks at how Open Source != Free.

Thoughts

This talk looks at how open source licensing works & more importantly how it applies to company projects. Once again a bit of legal focus but very valuable info in it!

JavaScript Toolkit

Description

This presentation provides a quick glance at a number of tools that make development with JavaScript easy, quick & bug free. Loads of tools & ideas in it :)

Thoughts

The JavaScript toolkit talk looks at a LOT of tools and libraries for JavaScript & as I do a lot of this day by day – it was easy to get ready & a lot of fun to present.

How to give a great presentation

Description

This slide deck was used to give students an overview on how to give a great presentation, especially a technical presentation. It covers aspects like purposeful movement, technology, slide creation etc....

Thoughts

This is a talk I gave to some students about how to do a great talk & it pulls a lot of my own learning’s & learning’s from experts like Hanselman into it.

.NET 4.5 Async

Description

A look at some of the complexities of .NET 4.5 Async

Thoughts

The newest talk here which covers the Async keyword. The core focus here was not on the simple scenarios but rather to dive into the more complex scenarios and areas of pain that can occur with this new keyword.

For the Rangers Treasure Map, we had an amazing development focused sprint where we all just dug in and got stuff done. The sprint after that became minor feature work but mostly just work on bug fixes & UX improvements. This meant that for each item we needed to identify the fix and apply it – the problem is that some of those fixes couldn’t easily be applied with our existing “tools”.

Tools in this case, refers not to Visual Studio or TFS – in this case it refers to our design pattern (MVVM) & the Microsoft guidelines. Let’s look at three examples of where we came up against those:

Keyboard support

The first issue was the keyboard support was bad for our app – you would not be able to navigate easily through MANY of the levels because of it. Windows is normally thought of mouse & touch – but there is a lot of keyboard support & keyboard guidance, so for us, it was vital to give an amazing experience with this too.

The core problem was our way of using SelectedItem on our lists for navigation, which works great for mouse/touch but doesn’t work for keyboard. So, with the VERY limited time left, what do we do? We had three options:

1. Leave in bad keyboard support.
2. Develop a ton of additional code to allow the view to work with this model or change the view some how – basically allowing us to keep PURE MVVM.
3. Break the MVVM pattern to solve this.

Option one, wasn’t even an option for us – so that left options two & three. Since we had limited time & other issues, if we did two, we would’ve had to drop other parts or leave other issues unfixed. The choice really was to break the pattern & have the code behind for the View handle the calling the View Model for the navigation.

This isn’t really my a smart idea, it comes from people like Sam Guckenheimer wrote in his book, this is the standard tetrahedon for software development:  time, money, features & quality. Since time & money for us are not movable – we have to chose quality or features.

At the end of the day, focusing on what is important, making sure what we ship is awesome for the user, even if the code base has a few ugly spots in it – meant we broke MVVM. You know what is awesome here though? Windows development allows it, because not every scenario is a perfect fit for a pattern every time.

Aside: I do hope in our v3 release we will get a whole sprint, or two, to do refactoring's, which will include moving this to the point two solution & making it better to unit test!

Right click – show appbar

Another example is that if you right clicked a list item, the appbar would not show (because item grabbed the event & the page never got it). Here the solution is once again, to go to the code behind. However, I do not personally feel this breaks MVVM. I acknowledge we could’ve found a MVVM way to do it, but this sort of experience is PURELY View related & so the code behind for the view is the right place to do this.

I know a lot of MVVM people believe all code behind is evil, but really, there is no evil here – these are just tools to make our lives easier & ship better software. We should use them, but not believe in them.

Alt+Left

The final example is a bug with pressing Alt+Left, which the Windows guidelines state, should take you back a page. However it breaks if you and Alt+Tab to get to the app (the Alt key is seen as stuck then, and just pressing left will make it go back). For us, the solution here is to not implement this guideline.

The experience of our users MUST triumph all guidelines, even those from Microsoft.

References

• ALM Readiness Treasure Map (Table of Content) TOC Post
• ALM Readiness Treasure Map Windows Store App

Today I got to present to the ever amazing audience at JSinSA (it is one of my favourite conferences, so I may be biased). The talk I gave was very simple: Visual Studio, it is THE BEST tool for web developers, regardless of what technology you use. So if you use ASP.NET, PHP, Ruby, CoffeeScript etc... it does not matter – Visual Studio is right for you!

If you attended and are looking for the slides, demo bits, or a script of the demo – have a look below! For those who couldn’t be there, I have since done a recording of it to YouTube, which is also below!

YouTube

Slides

In the short video below I cover how you can configure Nuget package sources to either local copy, which is great for backups when doing a presentation which relies on Nuget, or the the cache, which can provide an emergency store for recent packages if you have no Internet access.

If you are logging into TFS Service with your normal account and are suddenly seeing a prompt to “Create a Visual Studio account”, where is nothing to fear. It is just a Terms & Conditions update that is BADLY labelled.

Click create and go on with your day

Seriously your mobile strategy can exclude iPhone, you don’t need to support that platform – it isn’t really that important. 

Before you move to the comment to call me a Microsoft kool-aid guzzling fanboy, let me explain. I see three reasons that fuel the myth that iPhone is an important platform and they are:

• Lies, Damned Lies & Statistics
• The FNB Effect
• Development is hard for these other platforms

Lies, Damned Lies & Statistics

I have been totally guilty of helping this cause of the myth prevail by standing in front of thousands of Windows Phone 7 developers & showing how Gartner & IDC both predicted that Windows Phone would grow to 2nd place behind Android by 2015, pushing ahead of iPhone – which at the time the stats said was the number two smart phone OS.

The truth is, Windows Phone is ALREADY ahead of iPhone. It also leads Android. Really, it does – maybe not world wide or even in your country, but in South Africa it does.

In South Africa the picture is very different, Symbian leads by a massive margin (44%) followed by BlackBerry (15%), then Windows Phone (9%), forth place is Android (8%) and last is iPhone (4%).

The problem is we look at these analysts and international reports and assume they apply to us – they do not and should not influence our understanding of our market.

The FNB Effect

First National Bank, the bank that launched the first transactional smart phone app in South Africa & changed how we look at banking and did a lot to jump start app developed from companies. What platform did they launch on? iPhone & much (much) later an Android app was launched too – still no Windows Phone, Symbian or Blackberry app (or as I see it 68% of the market). Since there the number of times I have heard competing banks & companies in other industries start their mobile strategy with “FNB has iPhone – our customers expect iPhone”.

Those people are idiots. Their customers do not expect iPhone because FNB had an iPhone app, they expect an app for THEIR phone.

There are two sub-points to also consider with this factor which are vitally important in understanding why FNB’s choice of iPhone worked for them & why it may be right or wrong for your mobile strategy.

Know you customers

This is as much about the FNB effect as it is about statistics – looking at the statistics even for a country is almost completely flawed too. You need to look at what your customers have. To help explain this, let’s compare two companies who both produced an iPhone app:

• SABC
• Discovery

For Discovery it totally makes sense to have an iPhone. Private health care & life insurance are expensive and really only the top portions of the country can afford it. That is the same market who buys iPhone. You market has iPhone, you build iPhone.

SABC, like so much at the national broadcaster, needs to appeal to the broad population. So they should be looking at the total market share and building based on that. The issue makes less sense when you think that DSTV’s news channels & eTV’s news appeal to the upper LM groups more – so in reality SABC SHOULD be targeting the lower income groups who buy cheap Symbian & Blackberry phones. They didn’t & it is just stupid of them.

In fact they should have a mobi site since that would allow even broader reach – but of course that doesn’t quiet work either…

FNB app isn’t special – their marketing dept. is

The FNB app isn’t special. At best the app idea was a just smart business seeing what the rest of the world is doing & getting on the band wagon first. So why do we care? Because FNB’s marketing dept. is so damn amazing, they made it an important point in many of their adverts. They used it to highlight how far ahead they were & how slow & old their competitors are. They also used it in an aspirational way to appeal to lower income groups: One day I will be rich & own an iPhone. Then I want to be at a bank with an app.

All four of the major banks in South Africa have apps for iPhone now & still we only ever talk about FNB. This isn’t because theirs is the best – but because they sold their app the best. They own the mind share.

A second aspect to this story is FNB have made it ridiculously easy to get an iPhone with them – which firstly pushes up their stats of which platforms are important and secondly re-enforces the marketing stories: Wish your bank had an app? Wish you had a phone that could run an app? Come to FNB, we make it easy to have both.

Development is hard for these other platforms

The final contributing factor to myth that iPhone is the first port of call, is from the prima donna’s involved in these strategies. You may know them as software developers. These folks will tell you that development for Symbian is tougher than milking a rattlesnake & development for Blackberry is tougher than getting a date with Megan Fox. iPhone, Android & Windows Phone development is easy by comparison and so you can get it a lot cheaper/quicker/better.

That is, naturally, complete bull shit. It is easier because these are sexier platforms and because of that

• they don’t want to feel like an idiot when sharing what they do with their friends – who knows? Megan Fox maybe there and who will she date the iPhone dev or the Symbian dev? (I call this embarrassment tax – you pay extra for a developer to be embarrassed)
• they likely have the devices today and understand the platforms already because they played with it in their free time. I am talking about platform & not development. Understanding why something works on a platform is just as important as learning to code for it.
• they like the fact they do not need to learn new languages/tools. Android & Windows Phone developers are especially bad here since it is the top most common development platforms .NET & Java.

In reality Symbian is a marvellously stable & well developed platform with many tools. In fact, if you don’t need a transactional app, they have tools that are completely code-less (i.e. everything is done visually). I haven’t ever worked with Blackberry myself, so I can’t comment on their tools but I have been on projects where someone else did BlackBerry work & I did Windows Phone.  In those scenarios we were mostly matched for development performance and any difference was not because of the tooling.

Lastly, with tools like PhoneGap & Worklight getting better all the time, the need to native apps is getting REALLY small – you can easily use web development skills with those tools to create hybrid apps for BlackBerry & Symbian. There seems to be this belief though that if you go hybrid you go all in – which is totally bullshit too. I can totally see a native app built for your premier clients & then using hybrid, which may be a second rate experience, to clean up the rest of the market share platforms have in your customers.

Summary

In reality iPhone maybe the right choice to go for. The issue is there are so many people who do not apply their minds to what they really need. Rather these lazy people who make the decisions or feed information into the decision makers just regurgitate the bullshit that is out their. What I have hoped to highlight is there is no one right strategy but with a bit of thought & investigation you can find the one that is right for you and more importantly, your customers.

In my sabbatical to Redmond I learnt there are two departments at Microsoft who you never want to hear from because it is never good, one being HR and the second being Legal. On the 13th May I got an email from Microsoft’s legal dept., and it wasn’t good.

Microsoft after 60 000+ downloads, almost 6 months & even getting some mail from members of the Bing team, decided that my application, Bing my lockscreen, violated their copyright (It did, I am not disputing that) and so it was to be suspended until it was fixed.

So in the last two updates I have done the process to rename a Windows Store App and I am proud to notify you that the application is now called Amazing Lock Screen & is available in the store again!

In addition to the rename, I have made two UI changes in the latest release:

• Hero Image: The latest image is shown double the size of the previous ones & shows the image copyright text on it (similar to the Bing web site does).
• AppBar: The AppBar (the bit at the bottom of the Window) is now hidden by default, like most other Windows Store apps. The reason for the changes is I think the users are getting used to the Windows Style so I do not need to prompt as much as when Windows 8 was launched.

For more posts in this series, see the series index.

The above video shows the great XAMLSPY tool which is a massively helpful tool when working with any XAML based application, like a Windows Store app. XAMLSpy allows you to get insights such as performance & memory usage but for me the real value is when you add it to the application you get a set of small tools to use in the app to help identify and navigate the XAML.

Once you have found the piece of XAML that is causing issues, you can test out your ideas in real time using the real time editor functions which really speeds up development. This is a must have tool for those who really have pride in their craft!

For more posts in this series, see the series index.

This post is both a development snack, i.e. something I think you should know to build better Windows Store apps, as well as being part of the Treasure Map transparency, which are meant to show you how we built a real Windows Store app.

Size Matters

Lab Rat

In web development, there is often a concern to get the download size of the page down & there are plenty of tools to help with this (Visual Studio has a lot for CSS & JavaScript) but when we get to app development, size isn’t always as big a concern.

Windows Phone development made 20Mb an important limit, since that meant the download could go over 3G rather than requiring WiFi – this is why my Lab Rat comic book for Windows Phone is 17Mb in size. I made a very conscience choice to ensure it would fit under 20Mb.

Windows Store apps don’t have a similar limit to Windows Phone – so when I was recreating Lab Rat for Windows 8, I just went with the highest resolution images I could so it would look great. This resulted in the download being 225Mb!

Treasure Map

With version 1 of the treasure map, no one really thought of file size either rather focusing on making it look and feel great. Which resulted in it containing a lot of high resolution images and many of them in the JPEG format. When we shipped version 1, we shipped a 57Mb install!

Small is better

For version 2 of the treasure map, one piece of feedback we got (I believe the awesome Mike Fourie raised it) was that it was a big download. So I spent some time looking through our assets and doing some sneaky clean-up and in the process learnt a bit.

JPEG

It’s crap – use PNG. PNG is better quality and for most scenarios is smaller in file size. So in both Lab Rat & Treasure Map the first step was to replace all the JPEG images (including assets like store logo) with PNG.

If you want more info on the differences between JPEG and PNG see this amazing StackOverflow answer.

PNG 32, 24, 16, 8… oh my

A PNG isn’t PNG – in fact PNG’s can specify the bit depth of each of the channels they support which directly impacts how distinct colours they support. They can also allocate a specific bit in the colours to indicate transparency. However if you do not need transparency, which in the case for the bulk of Lab Rat & Treasure Map is true, you can save bit for a colour.

Very few images will have all 16 million colours that are needed, so if you identify how many unique colours there are, then you can shrink the bit depth which results in a smaller file. I did some work on this and found two pretty interesting tools:

• TinyPNG – a free website to do this. Only downside, one file at a time.
• PNGoo – a free Windows tool that can do bulk changes. Not as easy as the website to use though.

So I ran both Lab Rat & Treasure Map through that and we got a MASSIVE saving in disk.

• Treasure Map went from 57Mb to (approx.) 11Mb – so a saving of 80%. The 11Mb is just a test on my machine and also includes a lot of new resources, so it may change by release.
• Lab Rat went from 225Mb to 89Mb! So a saving of 60%!

Summary

So in summary, use PNG not JPG & make sure you compress your images before you release!