We refactor several of the static creator methods for
SharedStorageEventParams in preparation for adding several new members
to the class.
Bug: 401011862
Change-Id: Idfafcccce0f8ecd3d530e3223fc0036b79efd654
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6351803
Reviewed-by: Yao Xiao <yaoxia@chromium.org>
Commit-Queue: Cammie Smith Barnes <cammie@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1432387}
At construction, we assign a monotonically increasing ID to each
SharedStorageWorkletHost, which will be reported to DevTools for
each worklet event.
The current CL only partially plumbs the worklet ID to DevTools by
setting it in the event params for addModule, createWorklet, run, and
selectURL.
Followups will have to send the ID for the remaining worklet events,
as well as update the DevTools protocol and forward to the DevTools
frontend.
Bug: 401011862
Change-Id: I554d3c2ac3b6ce9f239dddcebe71a7b52359517f
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6348125
Reviewed-by: Yao Xiao <yaoxia@chromium.org>
Commit-Queue: Cammie Smith Barnes <cammie@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1432308}
We send the `resolve_to_config` bool to the SharedStorageWorkletHost
in preparation for adding it to SharedStorageEventParams, so that
it can be reported to DevTools sharedStorageAccessed events.
Bug: 401011862
Change-Id: I8e28232bcc4a7b5d3630173582cfa76c9e77d139
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6344311
Reviewed-by: Yao Xiao <yaoxia@chromium.org>
Reviewed-by: Joe Mason <joenotcharles@google.com>
Commit-Queue: Cammie Smith Barnes <cammie@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1431224}
This is part 1 of a multi-CL change intended to update the
DevTools sharedStorageAccessed events so that instead of using
a single long *AccessType enum, they use the cross product of shorter
*AccessScope and *AccessMethod enums.
The current CL addresses the bulk of the content/browser changes.
The next followup will make the necessary changes to the
browser_protocol.pdl file and finish updating content::protocol::
StorageHandler. Subsequently, one or more CLs will be needed to roll
the protocol changes to the frontend, and to make the existing
frontend compatible.
Bug: 401011862
Change-Id: I8a97fdf36b9bce7a9c77b56caf8baa6a4933d075
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6335479
Reviewed-by: Andrey Kosyakov <caseq@chromium.org>
Commit-Queue: Cammie Smith Barnes <cammie@chromium.org>
Reviewed-by: Yao Xiao <yaoxia@chromium.org>
Reviewed-by: Avi Drissman <avi@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1430450}
For createWorklet, while we are already sending the data origin itself
from the renderer process to the browser process, we don't currently
notify the browser process whether this origin was calculated as a
context origin, script origin, or custom origin.
For DevTools createWorklet event notifications, we would like to report
which parameters were used in the call (up to defaults and
canonicalization). While we could work backwards in the browser
process to estimate which parameter was used by JavaScript, doing so
would give information that would be inaccurate in some instances.
A followup will actually pass this new information to DevTools
backend as part of an updated `content::SharedStorageEventParams`.
Further followups will update the DevTools protocol and the frontend
so that this will be visible from the relevant subview of the
Application Panel.
Bug: 401011862
Change-Id: I13998b9034130e7bb5559db95efea07522cbca1d
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6330825
Reviewed-by: Andrey Kosyakov <caseq@chromium.org>
Reviewed-by: Yao Xiao <yaoxia@chromium.org>
Reviewed-by: Ken Buchanan <kenrb@chromium.org>
Commit-Queue: Cammie Smith Barnes <cammie@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1430337}
In preparation for using a cross product of shorter enums instead of
the existing enum SharedStorageRuntimeManager::
SharedStorageObserverInterface::AccessType, as well as for adding
further members to SharedStorageEventParams, we simplify the error
logging in TestSharedStorageObserver.
Previously this logging relied on LOG(ERROR) statements when
expected values did not match actual values. Instead, we implement
an operator== and an operator<< for SharedStorageEventParams. This
is cleaner and will be easier to extend when we make future changes.
Bug: 401011862
Change-Id: I053905bba8e30f2b8300e61735edc49ac2e6a6e0
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6329731
Commit-Queue: Cammie Smith Barnes <cammie@chromium.org>
Reviewed-by: Yao Xiao <yaoxia@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1429765}
We move SharedStorageLockManager::AccessScope to
third_party/blink/public/common/shared_storage/shared_storage_utils,
and now call it blink::SharedStorageAccessScope.
This is in preparation for replacing the current
SharedStorageRuntimeManager::SharedStorageObserverInterface::AccessType
enum with a shorter ::AccessMethod enum listing only methods, and then
using a pair of enum values from SharedStorageAccessScope and
AccessMethod, respectively to denote the access type. (In other words,
we will use a cross product of two shorter enums.)
Bug: 401011862
Change-Id: I7c084b919f4126bde61b3c1f4b28e955d65aa94e
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6331098
Reviewed-by: Yao Xiao <yaoxia@chromium.org>
Reviewed-by: Avi Drissman <avi@chromium.org>
Commit-Queue: Cammie Smith Barnes <cammie@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1429002}
This is needed to break a circular dependency between the request and
the policy that would appear in an upcoming CL where the policy will be
added onto the request.
This was a hack anyway that was added when requests had no access to
permissions policies but after crrev.com/c/6320262 they will have access
to them and all functions like this should be moved to the request
object. Ideally `PermissionsPolicy` shouldn't read flags from the
request and change behavior based on them, the request object should
handle things like this. A todo bug was created for this.
Bug: 382291442
Change-Id: Idca4d34bb30cf4bc44c87695fdcf72ea623d98c1
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6332329
Reviewed-by: Ari Chivukula <arichiv@chromium.org>
Commit-Queue: Sandor «Alex» Major <sandormajor@chromium.org>
Reviewed-by: Rakina Zata Amni <rakina@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1428943}
This changes instances of `b ? "true" : "false"` to use `base::ToString(b)`
instead. It's a followup to previous changes to address things that were missed
or regressed in the meantime.
This change applies to the following directories: content
This CL was uploaded by an experimental version of git cl split
(https://crbug.com/389069356).
R=creis@chromium.org
Bug: 335797528
Change-Id: I4d4ec7cd9e8c13d09c91637bca88de27bb637842
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6318187
Auto-Submit: Devon Loehr <dloehr@google.com>
Reviewed-by: Charlie Reis <creis@chromium.org>
Commit-Queue: Charlie Reis <creis@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1427485}
The network service needs access to the permissions policy. Previous CLs
moved all the dependencies so it is now safe to move this class.
The following files need to include permissions_policy.h because
otherwise they want to have access into incomplete `PermissionsPolicy`:
* components/permissions/permission_uma_util.cc
* third_party/blink/common/manifest/manifest_util.cc
* third_party/blink/renderer/core/html/client_hints_util.cc
* third_party/blink/renderer/modules/payments/payment_app_service_worker_registration.cc
* third_party/blink/renderer/modules/payments/payment_instruments.cc
Bug: 382291442
Low-Coverage-Reason: LARGE_SCALE_REFACTOR
Change-Id: Ifcf52df3bc5c035e8f6a45df02cf93f304b748c9
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6310821
Auto-Submit: Sandor «Alex» Major <sandormajor@chromium.org>
Owners-Override: Rick Byers <rbyers@chromium.org>
Commit-Queue: Sandor «Alex» Major <sandormajor@chromium.org>
Reviewed-by: Ari Chivukula <arichiv@chromium.org>
Reviewed-by: Rick Byers <rbyers@chromium.org>
Reviewed-by: Maks Orlovich <morlovich@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1426391}
Why: This helps to see if there are long-running worklets, which can
impact performance or be exploited for side-channel attacks. If the
result reveals such instances, we will further add UKM to investigate
the specific use cases.
Given that the existing 'UsefulResourceDuration' represents a
percentage, we add 'AbsoluteUsefulResourceDuration' for a distinction.
Bug: 398173023
Change-Id: I8b69362158a35b0861033f8f58a0aa335edb4241
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6287655
Reviewed-by: Ayu Ishii <ayui@chromium.org>
Commit-Queue: Yao Xiao <yaoxia@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1423455}
This CL changes the histogram creation APIs to take a durable
string view (i.e., a pointer+size pair referring to memory that
the programmer has annotated that it will not be freed) instead
of just an implicit pointer. The HistogramBase class internally
represents the name's length and the histogram's flags using
16 bits in order to not grow the in-memory size of Histogram
objects. The name of the histogram is subsequently exposed by
HistogramBase as a string_view.
This CL updates consumers of the histogram name's to use a
string_view of the name. This removes many string length
calculations and string copy operations. For histograms
allocated in shared memory, it also avoids potential out-of-
bounds reads if the underlying string data is modified or
corrupted such that it no longer has a trailing NUL char
at the end of the string.
Lastly, this CL updates a number of call-sites where the
histogram names were being copied into short-lived string
objects for use as search keys into various containers to
perform the functionality without making any unnecessary
copies.
Low-Coverage-Reason: TRIVIAL_CHANGE Use of string_view instead of string/char* in some error/logging paths have low coverage.
AX-Relnotes: n/a
Bug: 393394360, 40818143
Change-Id: Iee9ee5ae62335b9e7815f4ae11bde4ff80cfd4a2
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6231451
Reviewed-by: Avi Drissman <avi@chromium.org>
Reviewed-by: Antonio Rivera <antoniori@google.com>
Commit-Queue: Roger McFarlane <rogerm@chromium.org>
Reviewed-by: Etienne Pierre-Doray <etiennep@chromium.org>
Reviewed-by: Nico Weber <thakis@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1422750}
Why: this helps to understand web locks adoptions.
What:
- When a worklet is destroyed, record whether navigator.locks was
requested.
- When an update method is triggered (for individual method and for
batchUpdate() separately), record whether the 'withLock' option is
specified.
Bug: 373899210
Change-Id: I3ce97533345393c833b2861794bc52aad83573f9
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6277481
Commit-Queue: Yao Xiao <yaoxia@chromium.org>
Reviewed-by: Ayu Ishii <ayui@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1421614}
We plan to use the new class to support the new
`kPrivateAggregationApiErrorReporting` feature, which is currently
disabled by default (and not yet implemented). In this cl, the main
class is empty, with a TODO to implement the logic.
However, the nested Wrapper class is a fairly basic union type that
conditionally contains either the main class (if the error reporting
feature is enabled) or a vector of contributions (if the feature is
disabled). This cl also switches some plumbing to use this new Wrapper
class, which will simplify future implementation work. It also moves the
definition of ContributionMergeKey to the new class to reflect the new
class's intended (eventual) role.
This cl should be a no-op, given the disabled feature.
Bug: 381788013
Change-Id: I92e4dcebfa786e0327cd12c9104b4dbc9760dc1f
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6079892
Reviewed-by: Avi Drissman <avi@chromium.org>
Commit-Queue: Alex Turner <alexmt@chromium.org>
Reviewed-by: Dan McArdle <dmcardle@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1414416}
This is a behavior-preserving refactor.
This CL moves SharedStorageBrowserTestBase and
TestSharedStorageRuntimeManager out of the monolithic
shared_storage_browsertest.cc and into their own source files.
Bug: 392049826
Change-Id: Ibd9fb26c51f250284ed63d63ee210c39f061a656
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6216404
Reviewed-by: Rakina Zata Amni <rakina@chromium.org>
Commit-Queue: Dan McArdle <dmcardle@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1414093}
This is a behavior-preserving refactor.
This CL starts the process of chipping away at our currently-monolithic
shared_storage_browsertest.cc by pulling out classes into their own
source files. It also fixes a number of missing includes.
Next, we can move TestSharedStorageRuntimeManager, after which we should
be able to move SharedStorageBrowserTestBase. Once the base class is
moved, we'll be ready to move thousands of lines of tests into
shared_storage_private_aggregation_browser_test.cc, which I expect will
have a noticeable impact on build times for anyone working on these
browser tests.
Bug: 392049826
Change-Id: Ibdef9d18d26778304a307d4c8b22f611cdcd1f90
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6214056
Commit-Queue: Dan McArdle <dmcardle@chromium.org>
Reviewed-by: Alex Moshchuk <alexmos@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1414091}
This CL implements the Shared Storage side of Private Aggregation's
per-context limits feature, gated behind the blink feature flag
`kPrivateAggregationApiMaxContributions`, which is disabled by default.
Specifically, this CL makes the following changes:
* Adds a runtime-enabled `maxContributions` field to the
`SharedStoragePrivateAggregationConfig` IDL dictionary.
* Handles `maxContributions` in `CheckPrivateAggregationConfig()`.
Paired with the IDL change, this enables JS to set `maxContributions`.
* Adds browser test coverage. Primarily, we're testing that the field is
ignored when the feature is disabled, and that it actually affects the
number of contributions per report when the feature is enabled.
This CL contains no web-visible behavior changes.
Bug: 376707230
Change-Id: Icf883015af3cb00c8d72e1dc63114f2656b51b3d
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6175278
Reviewed-by: Dominic Farolino <dom@chromium.org>
Reviewed-by: Alex Turner <alexmt@chromium.org>
Reviewed-by: Dave Tapuska <dtapuska@chromium.org>
Commit-Queue: Dan McArdle <dmcardle@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1413558}
There is a console error posted when a selectURL call does not have
enough budget. Since this is an expected behavior and not indicative
of a problem with the page itself, this should be downgraded to kInfo.
Bug: 392828497
Change-Id: Id62715bf5de0c768a7f7a24fdcdf423943b476ca
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6206929
Reviewed-by: Dan McArdle <dmcardle@chromium.org>
Reviewed-by: Charlie Reis <creis@chromium.org>
Commit-Queue: Josh Karlin <jkarlin@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1412928}
This CL implements an optimization for per-context limits, which are
still gated by a feature and disabled by default.
We're making `ShouldSendReportDeterministically()` a little more clever,
with the goal of enabling Private Aggregation to send fewer null reports
without loss of privacy. Rather than requiring determinism whenever the
`std::optional<size_t> max_contributions` parameter has a value, we will
now additionally require that it would make the aggregatable report
stick out. This resembles the semantics of the `filtering_id_max_bytes`
parameter.
This CL should not contain any web-visible behavior changes, primarily
because none of the calling APIs have defined the `maxContributions`
field yet.
Bug: 376707230
Change-Id: Iee0d849170e728fd9cdc540daa83881ce96a21dc
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6183147
Commit-Queue: Dan McArdle <dmcardle@chromium.org>
Reviewed-by: Alex Moshchuk <alexmos@chromium.org>
Reviewed-by: Alex Turner <alexmt@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1412280}
This CL takes the following steps towards implementing per-context
contribution limits:
* Adds `blink::features::kPrivateAggregationApiMaxContributions`,
disabled by default.
* Implements the Private Aggregation logic for the `maxContributions`
config field and adds unit tests.
* Hardcodes `maxContributions` as `std::nullopt` in Shared Storage and
Protected Audience.
This should not contain any web-visible behavior changes, primarily
because none of the calling APIs have defined the `maxContributions`
field yet.
Bug: 376707230
Change-Id: I0b065ab8fb2383ec502cd018e6e66862ebba1ba1
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6172853
Reviewed-by: Mike Taylor <miketaylr@chromium.org>
Commit-Queue: Dan McArdle <dmcardle@chromium.org>
Reviewed-by: Arthur Sonzogni <arthursonzogni@chromium.org>
Reviewed-by: Alex Turner <alexmt@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1410414}
RFHI's permissions_policy() and GetPermissionsPolicy() are doing the
same thing, keeping the latter as that's exposed on the RFH as well.
Bug: 382291442
Change-Id: I846764815f6adb72c6906c59d6d6810e02a5d611
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6164805
Reviewed-by: Bo Liu <boliu@chromium.org>
Commit-Queue: Sandor «Alex» Major <sandormajor@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1404447}
