"SCRIPT5: Access is denied" error when accessing web sites using LocalStorage

Question

We are having an issue with Internet Explorer 10 affecting users on a number of our Windows 8 workstations. When a user visits a web site that uses the Local Storage feature of HTML5, the page is not displayed correctly. For example, if you visit this page:
http://jsfiddle.net/xFtQR/
You should see text in the grey boxes in the lower-right hand corner if everything is working. For the affected users, nothing is displayed. In addition, if you open the F12 Developer Tools and reload the page, the following error message is displayed: "SCRIPT5:
Access is denied.". It appears the LocalStorage feature is broken for these users.
From the troubleshooting I've done so far, I've determined that this issue does not affect the Local Administrator account on these computers, but it does affect any domain user and any new local user I create, whether the local user is in the Administrators
group or not. This leads me to believe the issue may be related to the default user profile in the image that was applied to these computers.
Other observations:
Performing a complete reset of Internet Explorer settings (from Tools > Internet Options... > Advanced) does not resolve the issue
These sites do work correctly after turning off Protected Mode for the Internet Zone (from Tools > Internet Options... > Security) 
These sites also work correctly when InPrivate Browsing is turned on
I've tried using Process Monitor to determine whether access is being blocked to a folder. On a working computer, iexplore.exe creates a file within a folder at C:\Users\username\AppData\LocalLow\Microsoft\Internet Explorer\DOMStore. I can't see
anything on an affected computer that would prevent IE from creating this folder, as the security settings on the folder all appear to be correct.
The location of this folder appears to be stored in the registry at HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings\5.0\LowCache\Extensible Cache\DOMStore. I've tried copying this key from a working computer and blanking
it out entirely to have IE recreate it, but neither resolved the issue. I've even gone as far as to try and compare an export of the registry from the default user profile from a working system and an affected system but I haven't been able to pinpoint any
differences which I thought might be relevant.
I've tried the "Internet Explorer Performance" and "Internet Explorer Safety" troubleshooters in the Control Panel.
Here are some links to articles on other sites which make reference to the same (or a similar) issue:
http://answers.microsoft.com/en-us/ie/forum/ie10-windows_7/ie10-script5-access-is-denied/e87bdb30-7f2a-4510-bfa3-a22b995f777b
http://community.spiceworks.com/topic/357825-ie10-script5-access-is-denied
https://github.com/meteor/meteor/issues/1291
Unlike these other cases, deleting an affected user's profile does not resolve the issue (further bolstering my theory that the issue is due to an issue in the default profile in my case).
Thanks in advance for any assistance anyone can provide!

Answer 1

With some excellent detective work by Microsoft Product Support (thanks Siddarth!), the solution has been found.
It turns out that in addition to the security settings on a folder, there is an integrity setting. More information about it is
here.
The integrity setting on the AppData\LocalLow folder in each user's profile is supposed to be set to "Low" (hence the name, presumably). In our case, the integrity level was not set correctly on this folder. To rectify the problem, we will need
to run the following command under each user's profile (with a login script, for example):
icacls %userprofile%\Appdata\LocalLow /t /setintegritylevel (OI)(CI)L
As for how this incorrect setting was propagated in the first place, it is because the LocalLow folder in the C:\Users\Default\Appdata folder in our customized OS image had the wrong setting. The C:\Users\Default folder is the template for a new user profile,
so each new user on these computers was affected. I examined the C:\Users\Default\AppData folder on another machine without a customized user template and found the LocalLow folder is not present at all, so in our environment we will be deleting the C:\Users\Default\AppData\LocalLow
from each machine to prevent the issue from affecting future new users.
EDIT: If the command above does not resolve the issue, the registry key that points to the low integrity DOMStore folder may have been changed. Check the
CachePath registry value at HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings\5.0\LowCache\Extensible Cache\DOMStore. It should be
%USERPROFILE%\AppData\LocalLow\Microsoft\Internet Explorer\DOMStore.