Auto Tagging
This version includes auto tagging. Now when you tag a transaction and keep ‘Apply to All’ set to ‘Yes’ then all transactions with a matching description will be tagged the same.

We try and be smart about ignoring dates in the description, and ignoring numbers when you tag things as Cheque.

Any new transactions that match one of the rules will be automatically tagged in the same way.

You can now delete tags entirely, so they wont show up in the list when you choose to tag a transaction, and you can remove individual rules. Go to the settings page and choose ‘Tags’

Now we are cracking on working these features into the Android app. Updates soon

With the most recent release of iOs, version 5.1 (and in previous beta and developer releases since 5.0) they have purposefully hobbled one of the most useful features in the recent set of recommendations… Localstorage.

The current set of recommendations form the draft HTML5 specification and whilst each version of HTML takes many years to finalise, many recommendations dont change much during those years, and many appear in browsers long before the final version is published. This is the case with Localstorage.

In iOS 5.1 Apple have moved the location of localStorage files into a Caches folder which is subject to occasional clean up, at the behest of the OS, typically if space is short. It is likely that Apple have done this to stop localStorage being backed up to iCloud.

The real problem here is not to do with Apples choice to have the OS move files or where they are stored, or any other implementation detail. All the things Apple’s iOs is doing is their business. Whether WebKit local storage gets backed up to iCloud is up to Apple, and has nothing to do with the HTML5 recommendations.

The problem is simply that the recent changes have a disastrous breaking side effect.

Webkit on iOS no longer has persistant localStorage

By moving localStorage to the Caches folder, they have allowed localStorage to be cleaned up whenever iOS wishes.

Persistance is one of the two things that the localStorage recommendation makes explicit, even if by obvious implication….

“User agents should expire data from the local storage areas only for security reasons or when requested to do so by the user.”

A reasonable interpretation of that line would be the following two specifications.

1. Users should expect localStorage to be persistant, unless there is a security problem.
2. Users can explicitly delete localStorage.

Going into settings and deleting the database or localStorage is a valid implementation of the second requirement. Having the OS deleting localStorage is not.

So in summary, I don’t care that Apple wanted to back up less data to iCloud, I dont care where they store the data for their implementation, or if they move it around.

I simply care that there is a standard localStorage API available to my javascript code that is consistent with the recommendations and accepted behaviour for that API.

iOS 5.1 now has a broken implementation of localStorage, rendering it useless for its intended purpose.

In a recent forum discussion another commenter suggested that because the recommendation only says ‘SHOULD’ then iOS clearing out localStorage as it wishes does not mean the implementation is broken.

I replied that I don’t think ‘SHOULD’ should be quite such an easy get out clause…

Looking at RFC 2119, should is defined as:

3. SHOULD This word, or the adjective “RECOMMENDED”, mean that there
may exist valid reasons in particular circumstances to ignore a
particular item, but the full implications must be understood and
carefully weighed before choosing a different course.

In the case of iOS the ‘full implication’ of the changes is that localStorage can clearly not be considered persistent, and is therefore no more than a temporary cache, subject to garbage collection, which is definitely not what localStorage was conceived for.

Mobile device or not, systematic non deterministic removal of persistant data is bad form. There are much more sensible policies to mediate shortage of space.

If this is a case of Apple loosely interpreting the spec to mean localStorage should be treated as a temporary cache, then I think they have made a naive mistake. If they have taken the spec as it was clearly intended then their implementation is very broken.

This is the kind of interpretation that led Internet Explorer into a cul-de-sac of hate, so I hope it is just a slip up on Apples part, though they knew about it in 5.01, and allowed it to make its way into 5.1!

This issue affects Phonegap apps (like ours) but Shazron had released a patch a while ago… https://issues.apache.org/jira/browse/CB-330

Having a wrapping framework mitigates this kind of breaking change, but thats not really the point, discussed further on Tim Andersons blog

UPDATE

In fact on re-reading the recommendation, it is clear that it states that localStorage is an API for persistent storage of data, the *SHOULD* referred to above is actually should clear localstorage when there is a security risk.

Part of the watering down is also due to the fact that some sites and services use ‘military grade’ to mean they use one technology that some military organisations use.

When a technical person reads ‘Military Grade Security’ they think ‘right they use SSL’, and perhaps even start to worry that is all the site or service is using.

At Money Toolkit we say military grade security because we mean it! Our staff and consultants have worked as suppliers to the UK government and military. For us SSL is just one essential component…

• 1. We use SSL for all our communication over HTTP – between our apps and servers and between servers. Our trafic can not be eavesdropped.
• 2. All other administration communication is done via SSH.
• 3. Passwords are never stored – we always use SHA hashed passwords.
• 4. All other data is encrypted on our servers, using AES.
• 5. The data centers we use are accredited to ISAE 3402
• 6. A lot of our service runs on Google App Engine who have an exemplary security record… 24 hour guarded data centers, airlock entry, NO security breach ever and more… more info.
• 7. We are a small company, and every employee or contractor is well known, and follows the best security practices. No customer data is ever allowed on individual storage devices, so can never leave the data center.
• 8. All of our systems and servers are regularly patched and hardened, no personal data is ever stored in any logs.
• 9. Our development and deployment process is strictly controlled with a continuous integration server running a battery of tests, not just for reliability, but for security as well.

So we have just pushed live our first draft of our public READ ONLY Api.

We are working on granting third parties read only tokens to your data so other developers can do cool stuff as well.

In the examples below, the tkn query parameter would normally be a one of token that you receive from and authorisation request (more details over at github)

the in=2 query parameter is to pretty print the JSON response with a 2 character indent..

Some sample Url’s…

An individual – showing some bank accounts:

https://www.moneytoolkit.com/pub/person/dan3?tkn=dummy_test_token&in=2

You can then use the ‘keyname’ for each account to look at the transactions for each account…

https://www.moneytoolkit.com/pub/person/dan3/account/a1?tkn=dummy_test_token&in=2

Or list all accounts and all transactions for an individual:

https://www.moneytoolkit.com/pub/person/dan3/account?tkn=dummy_test_token&in=2

Of course if you are not so techy – you can always just dump all your data out as CSV

Theres plenty more where that came from and we will provide more detail and documentation at our github page:
https://github.com/MoneyToolkit/Public-API/wiki

I was going to blog about the fact that Money Toolkit, and similar services are totally impervious to this kind of ‘Man in the Browser’ attack.

Whilst Money Toolkit is not entirely immune to other forms of attack, (as no device can be) it is extremely well protected

But it got me thinking a bit more about the story, and the scale of fraud reported in the article.

The article reports that…

Online banking fraud losses totalled £16.9 million in the first six months of 2011, according to Financial Fraud Action UK.

Wow, thats a lot! The banks definitely need to get smarter about security. In fact it is a subject banks do like to talk about a lot. Whilst some bank have started to do more things to help protect these losses, most banks simply use ‘security concerns’ as another excuse to explain away the lack of banking innovation and why they have not improved customer engagement and ultimately consumer empowerment.

Banks love this kind of article because if keeps their smoke screen smouldering…

The real news is that banks are still defrauding their customers to the tune of a few £billion a year.

Putting the numbers into perspective, i was going to call this post “Fraudsters dupe UK current account holders out of £2.6 Billion” ….

These numbers are based on the OFT report from 2008 – £2.6 billion in ‘unpaid item’ penaly charges during 2006 (there’s actually another £0.5billion in unauthorised overdraft fees as well)

This number is probably now a tiny bit high today – since a more recent OFT report in 2010 show the average unpaid item fee has halved since the 2008 reports numbers, but when you factor in the other penalty fees, it won’t be far off.

You know I wouldn’t be surprised if the banks didn’t like a little bit of fraud – especially if its online – then they can keep not delivering the services that would help many more people to avoid these (still) ridiculous fees and charges. I wonder if any banks have a secret ‘hacker department’

(btw I’m using hacker in the now more common ‘bad guy at a computer’ way. Not the original and (correct) meaning, as per Zuks recent misunderstood statement)

Whilst the banks have cleaned up their act a bit – we must applaud them for halving the average penalty from £34 to £17 – the OFT report in 2008, provides some choice insight into why the banks like these sneaky, after the event, charges…

The lack of visibility of insufficient funds charges to consumers has reduced the incentive for
the banks to compete on these aspects. As a result some banks appear to see insufficient
funds charges in particular as an attractive way to generate additional revenue without
affecting demand for their accounts.

A footnote goes into more detail…

During the course of this market study, the OFT has seen banks’ internal documents on the level of charges that include statements such as: ‘in order to maximise fee revenue, whilst maintaining our competitive position, selective increases in [insufficient funds charges] are proposed’, and ‘Increasing [insufficient funds] charges will have less impact on our marketing position… due to its lower visibility.’

Note Well – that there is not a hint of this being ‘handling costs’, its not that the cost to service the un-arranged debt has gone up – simply that they could generate profit whilst hiding the cause!

Its easy for high earners, and those that manage their accounts well to blame the individuals foolishness, but it is seriously easy to get caught out, almost everyone has been tripped up at one time or another. To get a feel or the scale of the problem (from the 2008 report) ….

• over a fifth of consumers were unaware of insufficient funds charges until they had incurred one
• over 12.6 million accounts (23 per cent of active accounts) incurred at least one insufficient funds charge in 2006, and
• those consumers who incurred an insufficient funds charge in 2006 were more likely to incur at least six charges than just one.

So why would banks not want to offer compelling online and mobile services to keep us well on top of our finances. Why would they not want to ‘be on our side’ and help us out with timely warnings and reminders, and quick emergency transfers?

Well of course that would be a ‘security concern’.

(by the way don’t worry about the banks not making enough money in this economic downturn ‘profits are soaring’ )

The iPhone and iPad versions will be submitted to the app store soon, along with a couple more bug fixes.

This allows you to see all your Santander accounts on your mobile phone. As always our service is read only you can’t do full mobile banking.

The big advantage with Money Toolkit is that it is very simple to log into and still extremely safe and of course you can add any of your other bank accounts so you can see all your accounts in one place.

Find Money Toolkit in the market here…

Existing users will have to upgrade to the latest version to be able to add Santander accounts.

I had blogged before how I thought Silverlight was a big technology mistake, and I questioned if they could survive such an error, well it looks as though they are going to give it a good try…

A recent tweet confirms the news…

@Ben_Houghton Hi Ben, Html and Javascript version in development; expected release in spring. Moving away from Silverlight.

This was in reply to Ben Houghton’s sensible tweet:

@moneydashboard just curious, why use Silverlight for MDB? Surely better for security & accessibility to use open standard like JavaScript?

I am obviously really interested in seeing what they come up with. The original post suggested a spring release – so a UI rewrite in 9 months is good going, for an estimated team of 3-4 developers.

My money is on a summer release

Existing customers don’t need to update their Android app, though it is a good idea to keep up to date with new versions as they often include bug fixes.

Here is the pdf…

Paul Lewis has been tweeting about it too…

Some folk have found it hard to se on their mobile phones so here it is …

Full list of branches forming the Verde Business

Cheltenham & Gloucester
Lloyds TSB England & Wales
Lloyds TSB Scotland

(top)