Don't force non-session only cookies to be session only cookies, instead delete on shutdown

Don't force non-session only cookies to be session only cookies, instead delete on shutdown

this is more consistent with how we treat other web site data types

All storage backends except for cookies use the SpecialStoragePolicy to decide what data to delete and what to keep. Also, since they commonly don't have a session only notion, they will delete the data on shutdown.

This CL unifies the way content settings are applied to storage systems by passing a SpecialStoragePolicy to the cookie store backend, and delete cookies on shutdown.

BUG=129349
TEST=SQLitePersistentCookieStoreTest.TestSpecialStoragePolicy

Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=139544

[jochen (gone - plz use gerrit), 2012-05-23 15:47:37]

plz review

I'll add a patch tomorrow

[willchan no longer on Chromium, 2012-05-23 15:59:45]

profiles/ LGTM
jochen tells me Erik will handle c/b/n/ which SGTM

Asked jochen to update the CL description to explain why passing this
SpecialStoragePolicy object has the effect in the subject of this cl.

[erikwright (departed), 2012-05-23 17:00:06]

From a reliability point of view, deleting on startup (in addition to or instead
of at shutdown) is more reliable because shutdown doesn't always happen.

I also wish we weren't introducing a module dependency that differs
significantly from anything already present.

I wonder what the typical usage patterns are. Does this usually only apply to a
few domains? It might make sense to invert the checks (only check for cookies
present from domains that have special policies). I suppose you could go one way
or the other depending on the number of domains with cookies vs. the number of
domains with special policies.

Let me think about the dependency aspect a bit more.

[jochen (gone - plz use gerrit), 2012-05-23 17:49:27]

On 2012/05/23 17:00:06, erikwright wrote:
> From a reliability point of view, deleting on startup (in addition to or
instead
> of at shutdown) is more reliable because shutdown doesn't always happen.

That is true. However, the goal is to rename the content setting to "delete at
shutdown" to be more consistent with what we do for other cookie-like types,
which we all delete at shut down.

> 
> I also wish we weren't introducing a module dependency that differs
> significantly from anything already present.

It's a new dependency for cookies, that's true. But it also unifies the way
site-data is handled.

> I wonder what the typical usage patterns are. Does this usually only apply to
a
> few domains? It might make sense to invert the checks (only check for cookies
> present from domains that have special policies). I suppose you could go one
way
> or the other depending on the number of domains with cookies vs. the number of
> domains with special policies.

I expect two scenarios.

1) the default is set to session only and only a few allow exceptions exists, so
almost all domains will be wiped

2) only very few domains are set to session only by manually created rules.

overall, I expect only a tiny fraction of our users will have session related
cookie settings.


> 
> Let me think about the dependency aspect a bit more.

[jochen (gone - plz use gerrit), 2012-05-24 11:04:03]

PTAL

I updated the descriptino, and added tests.

I also left some comments explaining why I did certain changes.

https://chromiumcodereview.appspot.com/10407124/diff/8001/chrome/browser/cont...
File chrome/browser/content_settings/host_content_settings_map.h (right):

https://chromiumcodereview.appspot.com/10407124/diff/8001/chrome/browser/cont...
chrome/browser/content_settings/host_content_settings_map.h:58: void
RegisterExtensionService(ExtensionService* extension_service);
Since I create a SpecialStoragePolicy during profile construction now, the host
content settings map is created before the ExtensionSystem is initialized. To
work around this, I added this function to update the HCSM once the extension
system is ready.

https://chromiumcodereview.appspot.com/10407124/diff/8001/chrome/browser/net/...
File chrome/browser/net/sqlite_persistent_cookie_store.cc (right):

https://chromiumcodereview.appspot.com/10407124/diff/8001/chrome/browser/net/...
chrome/browser/net/sqlite_persistent_cookie_store.cc:973: GURL url(
compare to CookiesTreeModel::PopulateCookieInfoWithFilter

https://chromiumcodereview.appspot.com/10407124/diff/8001/chrome/browser/net/...
File chrome/browser/net/sqlite_persistent_cookie_store_unittest.cc (left):

https://chromiumcodereview.appspot.com/10407124/diff/8001/chrome/browser/net/...
chrome/browser/net/sqlite_persistent_cookie_store_unittest.cc:121:
AddCookie("A", "B", "http://foo.bar", "/", base::Time::Now());
the domain key of a cookie doesn't have a scheme. updated the tests to be more
realistic

https://chromiumcodereview.appspot.com/10407124/diff/8001/chrome/browser/prof...
File chrome/browser/profiles/profile_impl.cc (right):

https://chromiumcodereview.appspot.com/10407124/diff/8001/chrome/browser/prof...
chrome/browser/profiles/profile_impl.cc:384: GetSpecialStoragePolicy());
this ends up creating a HostContentSettingsMap

https://chromiumcodereview.appspot.com/10407124/diff/8001/chrome/chrome_tests...
File chrome/chrome_tests.gypi (right):

https://chromiumcodereview.appspot.com/10407124/diff/8001/chrome/chrome_tests...
chrome/chrome_tests.gypi:4193:
'browser/net/sqlite_persistent_cookie_store_perftest.cc',
I have no idea why this test was not compiled before. It seems to work fine

https://chromiumcodereview.appspot.com/10407124/diff/8001/chrome/test/functio...
File chrome/test/functional/cookies.py (left):

https://chromiumcodereview.appspot.com/10407124/diff/8001/chrome/test/functio...
chrome/test/functional/cookies.py:18: self.test_host =
os.environ.get('COOKIES_TEST_HOST', 'www.google.com')
www.google.com sets cookies for google.com. We'll create exceptions based on
this host. To actually match the cookies, I updated the hostname to google.com

[erikwright (departed), 2012-05-24 11:07:15]

Here are some draft comments from the previous patchset. I'll look at the new
one shortly.

http://codereview.chromium.org/10407124/diff/1/chrome/browser/net/sqlite_pers...
File chrome/browser/net/sqlite_persistent_cookie_store.cc (right):

http://codereview.chromium.org/10407124/diff/1/chrome/browser/net/sqlite_pers...
chrome/browser/net/sqlite_persistent_cookie_store.cc:843: std::map<std::string,
int> cookies_per_domain;
cookie_delta_per_domain?

http://codereview.chromium.org/10407124/diff/1/chrome/browser/net/sqlite_pers...
chrome/browser/net/sqlite_persistent_cookie_store.cc:964: for (domain =
cookies_per_domain_.begin();
I'm all for putting the declaration of domain inside the 'for (;;)'. But if it
looks ugly to you it's also fine as is.

http://codereview.chromium.org/10407124/diff/1/chrome/browser/net/sqlite_pers...
File chrome/browser/net/sqlite_persistent_cookie_store.h (right):

http://codereview.chromium.org/10407124/diff/1/chrome/browser/net/sqlite_pers...
chrome/browser/net/sqlite_persistent_cookie_store.h:28: // of the parent class
|net::CookieMonster::PersistentCookieStore|.
Document how SpecialStoragePolicy is respected.

http://codereview.chromium.org/10407124/diff/1/chrome/browser/net/sqlite_pers...
chrome/browser/net/sqlite_persistent_cookie_store.h:32:
SQLitePersistentCookieStore(
Document the ownership/lifetime considerations of the new parameter.

[jochen (gone - plz use gerrit), 2012-05-24 11:34:54]

https://chromiumcodereview.appspot.com/10407124/diff/1/chrome/browser/net/sql...
File chrome/browser/net/sqlite_persistent_cookie_store.cc (right):

https://chromiumcodereview.appspot.com/10407124/diff/1/chrome/browser/net/sql...
chrome/browser/net/sqlite_persistent_cookie_store.cc:843: std::map<std::string,
int> cookies_per_domain;
On 2012/05/24 11:07:19, erikwright wrote:
> cookie_delta_per_domain?

Done.

https://chromiumcodereview.appspot.com/10407124/diff/1/chrome/browser/net/sql...
chrome/browser/net/sqlite_persistent_cookie_store.cc:964: for (domain =
cookies_per_domain_.begin();
On 2012/05/24 11:07:19, erikwright wrote:
> I'm all for putting the declaration of domain inside the 'for (;;)'. But if it
> looks ugly to you it's also fine as is.

Done.

https://chromiumcodereview.appspot.com/10407124/diff/1/chrome/browser/net/sql...
File chrome/browser/net/sqlite_persistent_cookie_store.h (right):

https://chromiumcodereview.appspot.com/10407124/diff/1/chrome/browser/net/sql...
chrome/browser/net/sqlite_persistent_cookie_store.h:28: // of the parent class
|net::CookieMonster::PersistentCookieStore|.
On 2012/05/24 11:07:19, erikwright wrote:
> Document how SpecialStoragePolicy is respected.

Done.

https://chromiumcodereview.appspot.com/10407124/diff/1/chrome/browser/net/sql...
chrome/browser/net/sqlite_persistent_cookie_store.h:32:
SQLitePersistentCookieStore(
On 2012/05/24 11:07:19, erikwright wrote:
> Document the ownership/lifetime considerations of the new parameter.

Done.

[erikwright (departed), 2012-05-24 17:36:58]

http://codereview.chromium.org/10407124/diff/8001/chrome/browser/net/sqlite_p...
File chrome/browser/net/sqlite_persistent_cookie_store.cc (right):

http://codereview.chromium.org/10407124/diff/8001/chrome/browser/net/sqlite_p...
chrome/browser/net/sqlite_persistent_cookie_store.cc:973: GURL url(
On 2012/05/24 11:04:03, jochen wrote:
> compare to CookiesTreeModel::PopulateCookieInfoWithFilter

Presumably this should be matching whoever defines the SpecialStoragePolicy. Can
you provide a reference to that?

I don't like the way this is coupled to whatever code is defining the policy.

I see that the SpecialStoragePolicy is URL-oriented. I think it makes sense to
define an interface (living somewhere in chrome/browser/ I think) that is
domain-oriented. The implementation of that interface can do the conversion to a
GURL and delegate to a SpecialStoragePolicy if that is what makes sense.

If you want to discuss this further, feel free to schedule a VC in my Friday AM.

[jochen (gone - plz use gerrit), 2012-05-24 17:53:43]

On 2012/05/24 17:36:58, erikwright wrote:
>
http://codereview.chromium.org/10407124/diff/8001/chrome/browser/net/sqlite_p...
> File chrome/browser/net/sqlite_persistent_cookie_store.cc (right):
> 
>
http://codereview.chromium.org/10407124/diff/8001/chrome/browser/net/sqlite_p...
> chrome/browser/net/sqlite_persistent_cookie_store.cc:973: GURL url(
> On 2012/05/24 11:04:03, jochen wrote:
> > compare to CookiesTreeModel::PopulateCookieInfoWithFilter
> 
> Presumably this should be matching whoever defines the SpecialStoragePolicy.
Can
> you provide a reference to that?

In Chrome, we use an ExtensionSpecialStoragePolicy, the session-onlyness is
determined by the CookieSettings. Whether or not something is protected is
defined by whether it's covered by an app-extend:

http://code.google.com/searchframe#OAMlx_jo-ck/src/chrome/browser/extensions/...

CookieSettings can have separate rules for http and https, so we could convert
secure cookies to https origins.

If you create a cookie setting in a straight forward way in our UI, it'll match
both

> 
> I don't like the way this is coupled to whatever code is defining the policy.
> 
> I see that the SpecialStoragePolicy is URL-oriented. I think it makes sense to
> define an interface (living somewhere in chrome/browser/ I think) that is
> domain-oriented. The implementation of that interface can do the conversion to
a
> GURL and delegate to a SpecialStoragePolicy if that is what makes sense.

I guess I'll need to do a similar change to SQLiteServerBoundCertStore which
also doesn't keep the protocol (although it's clear that certs only apply to ssl
connections).

I think introducing a wrapper that does the origin + secure/insecure to url
mapping and only exposes the three methods of the special storage policy
actually required here makes sense.

> 
> If you want to discuss this further, feel free to schedule a VC in my Friday
AM.

[erikwright (departed), 2012-05-24 17:59:23]

That sounds right to me too.

Thanks!

On Thu, May 24, 2012 at 1:53 PM, <jochen@chromium.org> wrote:

> On 2012/05/24 17:36:58, erikwright wrote:
>
> http://codereview.chromium.**org/10407124/diff/8001/chrome/**
>
browser/net/sqlite_persistent_**cookie_store.cc<http://codereview.chromium.org/10407124/diff/8001/chrome/browser/net/sqlite_persistent_cookie_store.cc>
>
>> File chrome/browser/net/sqlite_**persistent_cookie_store.cc (right):
>>
>
>
> http://codereview.chromium.**org/10407124/diff/8001/chrome/**
>
browser/net/sqlite_persistent_**cookie_store.cc#newcode973<http://codereview.chromium.org/10407124/diff/8001/chrome/browser/net/sqlite_persistent_cookie_store.cc#newcode973>
>
>> chrome/browser/net/sqlite_**persistent_cookie_store.cc:**973: GURL url(
>> On 2012/05/24 11:04:03, jochen wrote:
>> > compare to CookiesTreeModel::**PopulateCookieInfoWithFilter
>>
>
>  Presumably this should be matching whoever defines the
>> SpecialStoragePolicy.
>>
> Can
>
>> you provide a reference to that?
>>
>
> In Chrome, we use an ExtensionSpecialStoragePolicy, the session-onlyness is
> determined by the CookieSettings. Whether or not something is protected is
> defined by whether it's covered by an app-extend:
>
> http://code.google.com/**searchframe#OAMlx_jo-ck/src/**
> chrome/browser/extensions/**extension_special_storage_**
> policy.cc&exact_package=**chromium&q=extension_special_**
>
storage_policy.cc&type=cs&l=39<http://code.google.com/searchframe#OAMlx_jo-ck/src/chrome/browser/extensions/extension_special_storage_policy.cc&exact_package=chromium&q=extension_special_storage_policy.cc&type=cs&l=39>
>
> CookieSettings can have separate rules for http and https, so we could
> convert
> secure cookies to https origins.
>
> If you create a cookie setting in a straight forward way in our UI, it'll
> match
> both
>
>
>
>  I don't like the way this is coupled to whatever code is defining the
>> policy.
>>
>
>  I see that the SpecialStoragePolicy is URL-oriented. I think it makes
>> sense to
>> define an interface (living somewhere in chrome/browser/ I think) that is
>> domain-oriented. The implementation of that interface can do the
>> conversion to
>>
> a
>
>> GURL and delegate to a SpecialStoragePolicy if that is what makes sense.
>>
>
> I guess I'll need to do a similar change to SQLiteServerBoundCertStore
> which
> also doesn't keep the protocol (although it's clear that certs only apply
> to ssl
> connections).
>
> I think introducing a wrapper that does the origin + secure/insecure to url
> mapping and only exposes the three methods of the special storage policy
> actually required here makes sense.
>
>
>
>  If you want to discuss this further, feel free to schedule a VC in my
>> Friday
>>
> AM.
>
>
>
http://codereview.chromium.**org/10407124/<http://codereview.chromium.org/104...
>

[jochen (gone - plz use gerrit), 2012-05-25 11:39:47]

I added ClearOnExitPolicy that wraps the SpecialStoragePolicy and does the host
->url magic.

I also applied the same change to SQLiteServerBoundCertStore, as I'll need to do
that anyway for getting rid of the clear on exit pref

PTAL

[jochen (gone - plz use gerrit), 2012-05-29 12:23:13]

Friendly ping

[erikwright (departed), 2012-05-29 13:08:57]

mmenke: this change introduces a "SELECT origin FROM origin_bound_certs" in the
shutdown of the OB cert store. Is this expected to be fully paged in memory and
of reasonable size?

Alternative would be to cache a set of origins having certs.

Other than that, I only have a few minor requests.

http://codereview.chromium.org/10407124/diff/13044/chrome/browser/net/chrome_...
File chrome/browser/net/chrome_network_delegate.cc (left):

http://codereview.chromium.org/10407124/diff/13044/chrome/browser/net/chrome_...
chrome/browser/net/chrome_network_delegate.cc:307: options->set_force_session();
It looks like this bit and related logic can go away?

If so, a separate CL is OK.

http://codereview.chromium.org/10407124/diff/13044/chrome/browser/net/sqlite_...
File chrome/browser/net/sqlite_persistent_cookie_store.cc (right):

http://codereview.chromium.org/10407124/diff/13044/chrome/browser/net/sqlite_...
chrome/browser/net/sqlite_persistent_cookie_store.cc:202: // and
|cookies_per_origin_|.
As far as I can tell, cookies_per_origin_ is only accessed on DB thread
(assertions at the top of each method that touches it).

If so, you can avoid locking around those accesses and you can remove the
temporary deltas structure.

http://codereview.chromium.org/10407124/diff/13044/chrome/browser/net/sqlite_...
chrome/browser/net/sqlite_persistent_cookie_store.cc:845: CookiesPerOriginMap
cookies_delta_per_origin;
nit: cookies_delta -> cookie_deltas

http://codereview.chromium.org/10407124/diff/13044/chrome/browser/net/sqlite_...
File chrome/browser/net/sqlite_server_bound_cert_store.cc (right):

http://codereview.chromium.org/10407124/diff/13044/chrome/browser/net/sqlite_...
chrome/browser/net/sqlite_server_bound_cert_store.cc:489: sql::Statement
select_smt(db_->GetCachedStatement(
Can you comment on the difference between the cookie DB and the
origin_bound_certs DB that leads to the former caching origin counts and not the
latter?

Although Will said it SGTH for me to review this whole directory, I would ask
the author/owner of this store about the performance implications, if any, here.

http://codereview.chromium.org/10407124/diff/13044/chrome/browser/net/sqlite_...
File chrome/browser/net/sqlite_server_bound_cert_store_unittest.cc (right):

http://codereview.chromium.org/10407124/diff/13044/chrome/browser/net/sqlite_...
chrome/browser/net/sqlite_server_bound_cert_store_unittest.cc:540: // Make sure
the store gets written at least once.
It's not evident to me that this has ensured a write to the DB. A simple way to
show it would be to:

1) Create a store without a clear policy. Insert the cert, then destroy the
store (write to disk).
2) Create a store with the policy, load and verify count=1.
3) Load the store with or without the policy and verify count=0

Also, can you add one domain that is unaffected by the policy?

[mmenke, 2012-05-29 13:29:43]

On 2012/05/29 13:08:57, erikwright wrote:
> mmenke: this change introduces a "SELECT origin FROM origin_bound_certs" in
the
> shutdown of the OB cert store. Is this expected to be fully paged in memory
and
> of reasonable size?

I know nothing about the OB cert store (Or SQL, or origin-bound certs for that
matter), so I suspect you have the wrong person.  Perhaps you meant mattm?

[erikwright (departed), 2012-05-29 13:33:42]

[+mattm, mmenke to bcc]

Sure do!
On May 29, 2012 9:29 AM, <mmenke@chromium.org> wrote:

> On 2012/05/29 13:08:57, erikwright wrote:
>
>> mmenke: this change introduces a "SELECT origin FROM origin_bound_certs"
>> in
>>
> the
>
>> shutdown of the OB cert store. Is this expected to be fully paged in
>> memory
>>
> and
>
>> of reasonable size?
>>
>
> I know nothing about the OB cert store (Or SQL, or origin-bound certs for
> that
> matter), so I suspect you have the wrong person.  Perhaps you meant mattm?
>
>
http://codereview.chromium.**org/10407124/<http://codereview.chromium.org/104...
>

[mattm, 2012-05-29 19:56:58]

The ob cert store is expected to be fairly small (it selects the whole thing
into memory on loading), so this shouldn't be a problem unless you're just
worried about the extra reads slowing shutdown a bit.

On 2012/05/29 13:33:42, erikwright wrote:
> [+mattm, mmenke to bcc]
> 
> Sure do!
> On May 29, 2012 9:29 AM, <mailto:mmenke@chromium.org> wrote:
> 
> > On 2012/05/29 13:08:57, erikwright wrote:
> >
> >> mmenke: this change introduces a "SELECT origin FROM origin_bound_certs"
> >> in
> >>
> > the
> >
> >> shutdown of the OB cert store. Is this expected to be fully paged in
> >> memory
> >>
> > and
> >
> >> of reasonable size?
> >>
> >
> > I know nothing about the OB cert store (Or SQL, or origin-bound certs for
> > that
> > matter), so I suspect you have the wrong person.  Perhaps you meant mattm?
> >
> >
>
http://codereview.chromium.**org/10407124/%3Chttp://codereview.chromium.org/1...>
> >

[erikwright (departed), 2012-05-29 20:05:40]

On 2012/05/29 19:56:58, mattm wrote:
> The ob cert store is expected to be fairly small (it selects the whole thing
> into memory on loading), so this shouldn't be a problem unless you're just
> worried about the extra reads slowing shutdown a bit.
> 
> On 2012/05/29 13:33:42, erikwright wrote:
> > [+mattm, mmenke to bcc]
> > 
> > Sure do!
> > On May 29, 2012 9:29 AM, <mailto:mmenke@chromium.org> wrote:
> > 
> > > On 2012/05/29 13:08:57, erikwright wrote:
> > >
> > >> mmenke: this change introduces a "SELECT origin FROM origin_bound_certs"
> > >> in
> > >>
> > > the
> > >
> > >> shutdown of the OB cert store. Is this expected to be fully paged in
> > >> memory
> > >>
> > > and
> > >
> > >> of reasonable size?
> > >>
> > >
> > > I know nothing about the OB cert store (Or SQL, or origin-bound certs for
> > > that
> > > matter), so I suspect you have the wrong person.  Perhaps you meant mattm?
> > >
> > >
> >
>
http://codereview.chromium.**org/10407124/%253Chttp://codereview.chromium.org...>
> > >

LGTM with the following requests:

1) Remove the unused bit if appropriate.
2) Remove the lock and temp data structure if safe.
3) Enhance the test of the OB cert behaviour as previously mentioned.

Each of these can be a separate CL with a local owner, CC to me.

[jochen (gone - plz use gerrit), 2012-05-30 11:28:42]

http://codereview.chromium.org/10407124/diff/13044/chrome/browser/net/chrome_...
File chrome/browser/net/chrome_network_delegate.cc (left):

http://codereview.chromium.org/10407124/diff/13044/chrome/browser/net/chrome_...
chrome/browser/net/chrome_network_delegate.cc:307: options->set_force_session();
On 2012/05/29 13:09:03, erikwright wrote:
> It looks like this bit and related logic can go away?
> 
> If so, a separate CL is OK.

Will upload a separate CL

http://codereview.chromium.org/10407124/diff/13044/chrome/browser/net/sqlite_...
File chrome/browser/net/sqlite_persistent_cookie_store.cc (right):

http://codereview.chromium.org/10407124/diff/13044/chrome/browser/net/sqlite_...
chrome/browser/net/sqlite_persistent_cookie_store.cc:202: // and
|cookies_per_origin_|.
On 2012/05/29 13:09:03, erikwright wrote:
> As far as I can tell, cookies_per_origin_ is only accessed on DB thread
> (assertions at the top of each method that touches it).
> 
> If so, you can avoid locking around those accesses and you can remove the
> temporary deltas structure.

Done.

http://codereview.chromium.org/10407124/diff/13044/chrome/browser/net/sqlite_...
chrome/browser/net/sqlite_persistent_cookie_store.cc:845: CookiesPerOriginMap
cookies_delta_per_origin;
On 2012/05/29 13:09:03, erikwright wrote:
> nit: cookies_delta -> cookie_deltas

removed the variable as per above comment

http://codereview.chromium.org/10407124/diff/13044/chrome/browser/net/sqlite_...
File chrome/browser/net/sqlite_server_bound_cert_store.cc (right):

http://codereview.chromium.org/10407124/diff/13044/chrome/browser/net/sqlite_...
chrome/browser/net/sqlite_server_bound_cert_store.cc:489: sql::Statement
select_smt(db_->GetCachedStatement(
On 2012/05/29 13:09:03, erikwright wrote:
> Can you comment on the difference between the cookie DB and the
> origin_bound_certs DB that leads to the former caching origin counts and not
the
> latter?
> 
> Although Will said it SGTH for me to review this whole directory, I would ask
> the author/owner of this store about the performance implications, if any,
here.

I expect less data in the store (there's only one cert per origin, and this
feature is still hardly used)

http://codereview.chromium.org/10407124/diff/13044/chrome/browser/net/sqlite_...
File chrome/browser/net/sqlite_server_bound_cert_store_unittest.cc (right):

http://codereview.chromium.org/10407124/diff/13044/chrome/browser/net/sqlite_...
chrome/browser/net/sqlite_server_bound_cert_store_unittest.cc:540: // Make sure
the store gets written at least once.
On 2012/05/29 13:09:03, erikwright wrote:
> It's not evident to me that this has ensured a write to the DB. A simple way
to
> show it would be to:
> 
> 1) Create a store without a clear policy. Insert the cert, then destroy the
> store (write to disk).
> 2) Create a store with the policy, load and verify count=1.
> 3) Load the store with or without the policy and verify count=0
> 
> Also, can you add one domain that is unaffected by the policy?

Done.

[marja, 2012-05-30 11:44:06]

lgtm

[commit-bot: I haz the power, 2012-05-30 13:46:06]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/jochen@chromium.org/10407124/25001

[commit-bot: I haz the power, 2012-05-30 15:48:52]

Change committed as 139544