Introduce the concept of web schemes capable of storage

Introduce the concept of web schemes capable of storage

Cookies, local storage, IndexedDB, etc. can be used for various URL schemes,
including Chrome-specific and internal ones such as chrome-extension://,
chrome://, chrome-devtools:// etc.

However, in the browsing_data/ codebase, when the user chooses to delete
"site data", we must only delete data from actual websites that user visited,
not data from Chrome's internal modules; that means data associated with
schemes like http[s]://, file://, etc.

Until now, this definition was defined as
ChildProcessSecurityPolicy::IsWebSafeScheme() minus the embedder-specific
schemes chrome-extension:// and chrome-devtools://.

As we're moving parts of browsing_data/ codebase to content/ (crbug.com/668114),
this approach is not satisfactory. We need a definition that can be used
in content/, and embedders can possibly add more schemes, but not remove
them.

This CL introduces such definition to url_utils.h.

BUG=668114
Review-Url: https://codereview.chromium.org/2661543003
Cr-Commit-Position: refs/heads/master@{#448957}
Committed: https://chromium.googlesource.com/chromium/src/+/7e5c61fd4a063db154f623e75bc71bdcc4bf65fc

[msramek, 2017-01-27 13:36:47]

The CQ bit was checked by msramek@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-01-27 13:36:55]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[msramek, 2017-01-27 13:54:36]

msramek@chromium.org changed reviewers:
+ mkwst@chromium.org

[msramek, 2017-01-27 13:54:36]

Hi Mike,

This would be the list of "web storage" schemes we were talking about. This CL
is more to start a discussion than a polished proposal, since:

-> The list could probably be expanded.
-> The list might live better elsewhere (since it's related to StoragePartition
and browsing_data/ rather than Blink etc.)

Please have a look, and loop in anyone who might be interested in this
discussion :)

Thanks,
Martin

[commit-bot: I haz the power, 2017-01-27 15:17:34]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-01-27 15:17:35]

Dry run: This issue passed the CQ dry run.

[Mike West, 2017-02-02 20:53:58]

mkwst@chromium.org changed reviewers:
+ brettw@chromium.org

[Mike West, 2017-02-02 20:53:58]

How do you feel about this, Brett? My intuition is that it's reasonable to add
this as a //url concept, but I'd like to run it by you first.

[brettw, 2017-02-08 05:09:06]

Nice CL description! LGTM

[msramek, 2017-02-08 09:11:27]

Thanks Brett!

Mike - anything from your side?

Also, let me double-check again before proceeding. In comparison with the
previous definition used in BrowsingDataHelper, we lose kDataScheme, kBlobScheme
and kFileSystemScheme.

-> kDataScheme seems to have all storage mechanisms disabled.
-> kFileSystemScheme is used by filesystems, which are themselves a datatype of
StoragePartition (REMOVE_DATA_MASK_FILE_SYSTEMS) associated with a normal web
origin (i.e. clearing data from http://, https:// etc. will clear filesystems
created on URLs of those schemes).
-> kBlobScheme is a method of referencing objects in memory; AFAICT they should
have no way of managing their own storage (though the internal URL might support
storage itself)

Does that make sense? Anything else we might want to include in the list?

[Mike West, 2017-02-08 09:38:00]

On 2017/02/08 at 09:11:27, msramek wrote:
> Thanks Brett!
> 
> Mike - anything from your side?

If Brett's happy, I'm happy. LGTM.

> -> kDataScheme seems to have all storage mechanisms disabled.

Indeed.

> -> kFileSystemScheme is used by filesystems, which are themselves a datatype
of StoragePartition (REMOVE_DATA_MASK_FILE_SYSTEMS) associated with a normal web
origin (i.e. clearing data from http://, https:// etc. will clear filesystems
created on URLs of those schemes).
> -> kBlobScheme is a method of referencing objects in memory; AFAICT they
should have no way of managing their own storage (though the internal URL might
support storage itself)

Both of these must use the storage associated with the origin that created them.
They can't have storage of their own.

[msramek, 2017-02-08 09:56:37]

Alright, thanks! Landing this now.

[msramek, 2017-02-08 09:56:43]

The CQ bit was checked by msramek@chromium.org

[commit-bot: I haz the power, 2017-02-08 09:57:10]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-02-08 11:21:36]

CQ is committing da patch.

Bot data: {"patchset_id": 1, "attempt_start_ts": 1486547803412290, "parent_rev":
"4b9ec9d0dd42483207e9fab00d11f3df253d18e4", "commit_rev":
"7e5c61fd4a063db154f623e75bc71bdcc4bf65fc"}

[commit-bot: I haz the power, 2017-02-08 11:22:35]

Description was changed from

==========
Introduce the concept of web schemes capable of storage

Cookies, local storage, IndexedDB, etc. can be used for various URL schemes,
including Chrome-specific and internal ones such as chrome-extension://,
chrome://, chrome-devtools:// etc.

However, in the browsing_data/ codebase, when the user chooses to delete
"site data", we must only delete data from actual websites that user visited,
not data from Chrome's internal modules; that means data associated with
schemes like http[s]://, file://, etc.

Until now, this definition was defined as
ChildProcessSecurityPolicy::IsWebSafeScheme() minus the embedder-specific
schemes chrome-extension:// and chrome-devtools://.

As we're moving parts of browsing_data/ codebase to content/ (crbug.com/668114),
this approach is not satisfactory. We need a definition that can be used
in content/, and embedders can possibly add more schemes, but not remove
them.

This CL introduces such definition to url_utils.h.

BUG=668114
==========

to

==========
Introduce the concept of web schemes capable of storage

Cookies, local storage, IndexedDB, etc. can be used for various URL schemes,
including Chrome-specific and internal ones such as chrome-extension://,
chrome://, chrome-devtools:// etc.

However, in the browsing_data/ codebase, when the user chooses to delete
"site data", we must only delete data from actual websites that user visited,
not data from Chrome's internal modules; that means data associated with
schemes like http[s]://, file://, etc.

Until now, this definition was defined as
ChildProcessSecurityPolicy::IsWebSafeScheme() minus the embedder-specific
schemes chrome-extension:// and chrome-devtools://.

As we're moving parts of browsing_data/ codebase to content/ (crbug.com/668114),
this approach is not satisfactory. We need a definition that can be used
in content/, and embedders can possibly add more schemes, but not remove
them.

This CL introduces such definition to url_utils.h.

BUG=668114

Review-Url: https://codereview.chromium.org/2661543003
Cr-Commit-Position: refs/heads/master@{#448957}
Committed:
https://chromium.googlesource.com/chromium/src/+/7e5c61fd4a063db154f623e75bc7...
==========

[commit-bot: I haz the power, 2017-02-08 11:22:36]

Committed patchset #1 (id:1) as
https://chromium.googlesource.com/chromium/src/+/7e5c61fd4a063db154f623e75bc7...