Cookies and passwords are stored per app.
==Open questions==
===Format for trusted and certified apps===
Need to determine a package format We need an application delivery mechanism that provides assurances on app integrity and authenticity, and also allows for well-defined application & privilege scope (domain) enforcement so integrity can be maintained at runtime.
1) Extend We will extend the appcache manifest to include hashes, and the of all app store would sign the whole thing core assets (add magic crypto dust hereHTML, JS, CSS, media). This would allow app App store authenticates and reviews all assets to still live on websiteagainst this manifest, but have many of verifying that the rationale provided for explicit permissions meets the benefits of code signingapp behavior. This has issues with defining a clear application scope (i.e. need a separate Both manifests are then signed by the app domain from store, and verified by the origin domain)client at install time.
2) Use existing This proposal allows app assets to still live on website, but have many of the benefits of code/widget package formatsigning. We get It requires developers to keep different versions separate on their site as they may have different versions circulating in the benefit of a well-tested formatwild, and the developer doesn't have to pay for domain registration, hosting, SSL certs, etc. We also get a well-defined domain for each app (ex. jar://myapp). See [[Apps/Security/Distribution]] for ideashash mismatch will result in installation failure. 3) We should not invent Yet Another Installer Package
==Open questions==
===Application Scope===
Foundational assumption was that there was only one app per domain. This is because an origin is effectively the only security boundary in the browser, and determining the security implications of allowing apps with different permissions on the same domain is a time consuming exercise for the 1.0 timeframe.
