The changes of this CL are made using the following script.
```
target_directory="content/browser"
replace_string_in_files() {
old_string="$1"
new_string="$2"
find "$target_directory" -type f \( -name "*.cc" -o -name "*.h" \) \
-exec sed -i '' "s/$old_string/$new_string/g" {} +
}
delete_include() {
find "$target_directory" \( -name "*.h" -o -name "*.cc" \) -print0 | while IFS= read -r -d '' file; do
grep -v '#include "base/strings/string_piece.h"' "$file" > "$file.tmp" && mv "$file.tmp" "$file"
done
}
add_include() {
find "$target_directory" \( -name "*.h" -o -name "*.cc" \) -print0 | while IFS= read -r -d '' file; do
local include_added=false
local tempfile=$(mktemp)
if grep -qE 'std::(string|u16string)_view' "$file"; then
while IFS= read -r line; do
echo "$line" >> "$tempfile"
if [[ $line =~ ^\s*#include ]]; then
if ! $include_added; then
echo "#include <string_view>" >> "$tempfile"
include_added=true
fi
fi
done < "$file"
mv "$tempfile" "$file"
if $include_added; then
echo "Added #include <string_view> after the first include line in $file"
else
echo "No include line found in $file"
fi
else
echo "std::string_view not found in $file"
fi
done
}
replace_string_in_files "base::StringPiece16" "std::u16string_view"
replace_string_in_files "base::StringPiece" "std::string_view"
delete_include
add_include
```
Replaced base::StringPiece16 with std::u16string_view
Replaced base::StringPiece with std::string_view
Removed header "base/strings/string_piece.h"
Added header "<string_view>" where applicable
Bug: 40506050
Change-Id: I2bc22c79dd9a0c839745afe065123f7a53c4a5ca
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5401117
Reviewed-by: Arthur Sonzogni <arthursonzogni@chromium.org>
Commit-Queue: Arthur Sonzogni <arthursonzogni@chromium.org>
Reviewed-by: Mike West <mkwst@chromium.org>
Reviewed-by: Rakina Zata Amni <rakina@chromium.org>
Reviewed-by: Will Harris <wfh@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1281746}
Prior to this CL, any origin with a trailing dot in the host name would
fail the origin-validity check in ChildProcessSecurityPolicyImpl::
AddOriginIsolationStateForBrowsingInstance() during attempts to
opt-in or out of origin isolation.
This CL corrects this, and adds a test.
Bug: 1446661
Change-Id: Iba17968adcb7d3c3af24b605f662318f5c5dc25b
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4544436
Commit-Queue: James Maclean <wjmaclean@chromium.org>
Reviewed-by: Alex Moshchuk <alexmos@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1149853}
With the advent of OriginAgentCluster(OAC)-by-default, the number of
navigations getting OAC isolation is expected to increase dramatically. Prior to this CL, each time a navigation got OAC (either via header or
OAC-by-default) we had to check if the navigation's origin had ever
been isolated before, and if not do a potentially expensive search of
the frame tree and session history to verify that we hadn't previously
encountered the origin in the current BrowsingInstance.
To avoid OAC-by-default causing a performance regression due to many
additional global walks, this CL refactors the global walk logic so
that it is only invoked when the OAC header is explicitly present,
either for opt-in or opt-out, and not invoked when an origin gets
OAC-by-default. Since the number of sites explicitly opting-out is expected to be small, this should help keep the total number of global walks small.
When OAC-by-default is enabled, we will explicitly track all origins
that have sent the OAC header, along with the requested opt-in or
opt-out state. All untracked origins will be assumed to have the
default OAC-enabled state.
When OAC-by-default is not enabled, we continue to track only origins
that have explicitly requested opt-in via the header.
This CL also renames a number of functions used in the global walk
to make their behavior more easily understood.
More details about the global walk and this refactor/redesign can
be found at
https://docs.google.com/document/d/1zrMXDOXDhp4-qFZvkZkDVSuqsT718Y-kRVRPqestiMY/edit?usp=sharing
Bug: 1259920
Change-Id: I0a31641eebe187f3961ddfcb2a2d1977a7a3f1f6
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3763843
Reviewed-by: Alex Moshchuk <alexmos@chromium.org>
Reviewed-by: Charlie Reis <creis@chromium.org>
Commit-Queue: James Maclean <wjmaclean@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1027872}
In order to make BasicStringPiece API compatible with C++17's
std::basic_string_view this change removes the starts_with() API and
updates call sites to use base::StartsWith instead.
In order to keep this callsites concise, base::StartsWith's
case_sensitivity parameter now defaults to CompareCase::SENSITIVE.
TBR=dcheng
Bug: 1049498
Change-Id: Ie621c6d08283d2ffd1055c5753ade5451f5c0b1d
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2358745
Commit-Queue: Jan Wilken Dörrie <jdoerrie@chromium.org>
Reviewed-by: Daniel Cheng <dcheng@chromium.org>
Cr-Commit-Position: refs/heads/master@{#799265}
The fourth (and final) CL in implementing origin-/site-keying of
SiteInstances. https://crbug.com/1085275/#c2 lists the sequence of CLs
and what each will accomplish.
This CL adds the keying bit to SiteInfo, and updates MakeTie() and
ComputeSiteInfo() to use it. It removes the prior hack in GetSiteForURL
regarding isolated base origins, and adds/updates tests that involve
isolated base origins.
This CL also changes the order in which we check isolated origins, so
that opt-in isolation requests take precedence over command-line
isolation.
Bug: 1067389, 1085275
Change-Id: I3f91fe94a1a61a7ef272d83232a6ff4e6e3bff3d
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2269516
Commit-Queue: James MacLean <wjmaclean@chromium.org>
Reviewed-by: Aaron Colwell <acolwell@chromium.org>
Reviewed-by: Alex Moshchuk <alexmos@chromium.org>
Reviewed-by: Charlie Reis <creis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#798294}
Fix code that was implicitly depending on logging.h or its
dependencies.
For example, code that uses DISALLOW_COPY_AND_ASSIGN should
include base/macros.h, but it currently happens to work if
it pulls in logging.h directly or through some dependency.
This is part of refactoring the codebase to use
check.h/check_op.h for the CHECK and CHECK_op macro
instead of logging.h.
Bug: 1031540
Change-Id: Ic7acb86282462f129ef926d5879c14df0a486a7e
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2156948
Commit-Queue: Nasko Oskov <nasko@chromium.org>
Reviewed-by: Nasko Oskov <nasko@chromium.org>
Auto-Submit: Hans Wennborg <hans@chromium.org>
Cr-Commit-Position: refs/heads/master@{#761520}
This CL is a first step towards implementing origin isolation opt-in
via OriginPolicy.
At present, this CL just looks for the existence of any top-level
"isolation" key (true or a dict) in the OriginPolicy manifest.
The opt-in status is stored in ChildProcessSecurityPolicyImpl in two
ways:
* a master opt-in list that reflects the opt-in status for a given
origin as of the most recently received OriginPolicy, and
* a per-BrowsingInstance map that tracks all origins that have been
loaded into that BrowsingInstance and have isolation enabled.
The first navigation to an origin in a BrowsingInstance will respect the
current opt-in status in the master opt-in list, and if the origin opts
in to isolation the opt-in status with respect to the BrowsingInstance
is set at that time. However, if an origin does not opt in, then this
CL does not track that (this will be in a near-future CL).
This CL should be a functional implementation of origin-isolation opt-in
and only requires --enable-features=OriginPolicy to enable it. Of
course, one also needs an origin's server to send an appropriate
OriginPolicy manifest.
Bug: 1042415
Change-Id: I1d7ecb4c77a52048bd2ebe780d763e47270ea5e9
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1956014
Commit-Queue: James MacLean <wjmaclean@chromium.org>
Reviewed-by: Alex Moshchuk <alexmos@chromium.org>
Reviewed-by: Kinuko Yasuda <kinuko@chromium.org>
Cr-Commit-Position: refs/heads/master@{#735125}
Other enterprise features use the [*.] syntax to specify wildcard
matching, modify the wildcard isolated origins code to use this syntax
for consistency.
Bug=chromium:926997
Change-Id: Ib753aa626a8020b6391db6e9a500690cfa8d80e0
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1688539
Reviewed-by: Łukasz Anforowicz <lukasza@chromium.org>
Commit-Queue: Andrew Stone <ajws@google.com>
Cr-Commit-Position: refs/heads/master@{#675932}
1. Add a string variant of AddIsolatedOrigins().
Command line, enterprise policy and field trial code presents isolated
origins as a single comma separated string.
ChildProcessSecurityPolicy can now parse these strings directly,
avoiding the need to make the internal implementation of wildcard
patterns visible to /src/content/public.
This change enables wildcard domains (domains of the form
"http(s)://**.foo.bar.com") to be specified alongside non-wildcard
domains on the command line, as part of a field trial or via
enterprise policy.
For example, start Chrome with the command line switch
"--isolate-origins=https://**.foo.bar.com,https://baz.com" to ensure
that baz.com is an isolated origin, and any origin under foo.bar.com
will be treated as an isolated origin, i.e. https://a.foo.bar.com and
https://b.foo.bar.com will be treated as separate origins.
2. Add BrowserTests for wildcard origins.
Show that navigations between hosts within wildcard isolated
sub-domains always receive new processes, while not affecting process
reuse of navigations within a non-wildcard domain.
3. Fix operator== of IsolatedOriginPattern.
|pattern_| was erroneously included in operator==(), which meant that
equivalent domains with different patterns would fail equality checks,
e.g "https://foo.com/" and "https://foo.com" would not be considered
equal because of the trailing slash, yet they are equivalent when used
as url::Origins. Unit tests for this behaviour are added as part of
ChildProcessSecurityPolicyTest.
Bug=chromium:926997
Change-Id: I4fcad7fd8cc641cfacd94903466ff4e46317b616
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1666371
Commit-Queue: Andrew Stone <ajws@google.com>
Reviewed-by: Łukasz Anforowicz <lukasza@chromium.org>
Reviewed-by: Alex Moshchuk <alexmos@chromium.org>
Cr-Commit-Position: refs/heads/master@{#672429}
1. Make GetMatchingIsolatedOrigin() respect wildcard isolated origins.
The matching behaviour for GetMatchingIsolatedOrigin() is changed such
that when iterating the list of isolated origins per site, if a
wildcard origin is encountered, the function returns immediately. This
prevents a non-wildcard isolated origin elsewhere in the set being
matched.
2. Add isolating wildcard domains to ChildProcessSecurityPolicy.
Provide an additional implementation of AddIsolatedOrigins which
accepts a list of IsolatedOriginPatterns, correctly preseving whether
or not they are wildcard isolated origins when converted to
IsolatedOriginEntries.
3. Add IsolatedOriginPattern, a container class for wildcard patterns.
In order to add support for isolating all sub-domains of an origin,
expressed by a double asterisk (e.g. https://**.foo.com) a new
container class is required. We are unable to use GURL or url::Origin
to hold these patterns as they escape the '*' character to '%2A', which
would make parsing brittle if this behaviour ever changes in the
future.
Instead we propose to hold user-supplied data in an
IsolatedOriginPattern instance, which correctly identifies and removes
wildcards. After removal of the wildcards conversion to url::Origin()
is possible, requiring only minimal changes to code that calls
ChildProcesssecurityPolicyImpl::AddIsolatedOrigins().
4. Add double-wildcard support to IsolatedOriginEntries.
Double wildcard origins are origins for which any sub-domain should be
subject to site isolation. By default the varaiable is initialised to
false; future commits will permit callers of
ChildProcessSecurityPolicy::AddIsolatedOrigins() to specify URLs of
the form https://**.foo.com to isolate any sub-domain that matches the
specified pattern.
Design doc for these chanes is available here:
http://doc/1nAL_ZH64weVOaTSpfA85MOdNW1RzTAZg2A3i1oixAuE
Bug=chromium:926997
Change-Id: I5259cf1e7fd69ad933ce741debb979c155d0a9bb
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1589080
Reviewed-by: Łukasz Anforowicz <lukasza@chromium.org>
Reviewed-by: Alex Moshchuk <alexmos@chromium.org>
Commit-Queue: Andrew Stone <ajws@google.com>
Cr-Commit-Position: refs/heads/master@{#667030}
Previously, if bar.foo.com was an isolated origin, subdomains like
subdomain.bar.foo.com would end up in a different SiteInstance (using
"foo.com" for its site URL) than the isolated origin, which was
confusing/undesirable. There was also confusion with subdomains if an
etld+1 (e.g., isolated.com) was marked as an isolated origin: we would
try to assign a different SiteInstance to foo.isolated.com than
isolated.com, yet the site URL would still resolve to "isolated.com".
This CL changes this behavior to keep subdomains in the isolated
origin's SiteInstance. It also adds conflict resolution, which allows
adding multiple isolated origins with a common domain (e.g., c.b.a.com
and a.com), where the most specific isolated origin is used when
picking the SiteInstance site URL for a particular URL (e.g., b.a.com
would use a.com, but d.c.b.a.com would use c.b.a.com).
For more discussion about this, see the isolated origin design doc:
https://goo.gl/99ynqK
BUG=713444
Review-Url: https://codereview.chromium.org/2891443002
Cr-Commit-Position: refs/heads/master@{#483881}