This list contains items that contain actual user data like
their device name or their downloads path, items that contain
UUIDs that could be used to track users across different
origins, sessions, or private browsing, and values that
either change occassionally or don't have enough entropy to
serve as a long-lived UUID, but do have enough entropy to be
used as a short-term correlatable identified to e.g.
de-anonymize someone use the VPN feature of containers.
Depends on D145259
Differential Revision: https://phabricator.services.mozilla.com/D145260
During testing I started hitting these cases that were not
well-documented for the person hitting the crash, so let's
improve them.
Differential Revision: https://phabricator.services.mozilla.com/D145259
Before we would stick all prefs into an immutable shared memory
region and clear our HashMap.
Now we will stick all non-sanitized prefs into the immutable
shared memory region, save the sanitized prefs in a list
temporarily, clear the hashmap, and then repopulate the hashmap
with the sanitized prefs.
As a bit of underlying complexity, to do this we must do some
tricks with the Pref Name Arena which is a chunk of memory
dedicated to storing pref names. That goes away (and we want to
wipe it to save space) - so we just need to move the sanitized
pref names to a new arena.
Depends on D141421
Differential Revision: https://phabricator.services.mozilla.com/D141422
We busted browser_preferences_usage.js by looking up a
preference too many times.
The reason we are now exceeding the pref-reading limit for
this pref is that inside ShouldSanitizePreference all of
our calls to Preferences::Something(pref_name) are causing
pref lookups. _Most_ of the time when we are in
ShouldSanitizePreference, we got there from a place that has
the actual pref object; so change the function to take in a
Pref object.
Unfortunately, there is a place we do need to look it up
by name, and that's in Static Pref getters, so we need to
keep that function around (and expose it in Preferences.h)
To minimize code duplication (i.e. not having the exact same
code for ShouldSanitizePreference(Pref) and
ShouldSanitizePreference(PrefWrapper) we do some templating
tricks because even though they expose the same API, they are
not in a class hierarchy where we could just make one function
for a base class.
Depends on D141420
Differential Revision: https://phabricator.services.mozilla.com/D141421
In the following patch we are going to change the signature of
ShouldSanitizePreference to take a Pref object. Pref is only
known to the Preferences compilation unit; so to keep this member
(whose signature will change) we would need to expose the Pref
class. However it will only be a forward declaration, one could
not construct a Pref object in e.g. the gtest.
It is simpler to just remove the member entirely and call
ShouldSanitizePreference unconditionally - the member was only
used for the gtest, and while the gtest will be less robust
because of this change, it will still do some testing.
Depends on D141419
Differential Revision: https://phabricator.services.mozilla.com/D141420
For all subprocesses, if a preference is in the blocklist,
sanitize it. (This preserves the IPC optimization behavior,
kind of. We now generate IPC traffic when we didn't before,
but we omit the value. Values were previously capped at 4 KiB
now they're 0 bytes.)
For Web Content processes, we sanitize a preference if it is
in the blocklist, or if does not have a Default value (i.e.
it is dynamically named). There is an exception list for
dynamically named preferences we know we need though.
In subprocesses, we know if a preference was sanitized
by checking its Sanitized bit.
Depends on D141416
Differential Revision: https://phabricator.services.mozilla.com/D141417
To do the correct thing in Preferences::SerializePreferences
(which is used during subprocess startup) we need to know if
the destination process is a web content process or not.
We add parameters to
SharedPreferenceSerializer::SerializeToSharedMemory that let
us figure that out.
In Preferences::SerializePreferences we fix the call to
aShouldSanitizeFn to pass the correct destination.
Depends on D141415
Differential Revision: https://phabricator.services.mozilla.com/D141416
PreferenceUpdate is the IPC message notifying a child process
that a preference has been updated. To correctly decide whether
or not a value should be sanitized in it, we need to know
what type of destination process it is; we add parameters to
Preferences::GetPreference indicating that.
Inside of ToDomPref we call ShouldSanitizePreference to
correctly populate the sanitized bit.
Depends on D141412
Differential Revision: https://phabricator.services.mozilla.com/D141413
This simplifies the number of negations needed,
and makes things easy to understand. I think
anyway; I know that without renaming it I made
several annoying-to-diagnose negation errors...
Depends on D141411
Differential Revision: https://phabricator.services.mozilla.com/D141412
A couple places where it might be a web content process
still pass 'false' - this will be corrected in a later
patch.
Depends on D141410
Differential Revision: https://phabricator.services.mozilla.com/D141411
Before we would stick all prefs into an immutable shared memory
region and clear our HashMap.
Now we will stick all non-sanitized prefs into the immutable
shared memory region, save the sanitized prefs in a list
temporarily, clear the hashmap, and then repopulate the hashmap
with the sanitized prefs.
As a bit of underlying complexity, to do this we must do some
tricks with the Pref Name Arena which is a chunk of memory
dedicated to storing pref names. That goes away (and we want to
wipe it to save space) - so we just need to move the sanitized
pref names to a new arena.
Depends on D141421
Differential Revision: https://phabricator.services.mozilla.com/D141422
We busted browser_preferences_usage.js by looking up a
preference too many times.
The reason we are now exceeding the pref-reading limit for
this pref is that inside ShouldSanitizePreference all of
our calls to Preferences::Something(pref_name) are causing
pref lookups. _Most_ of the time when we are in
ShouldSanitizePreference, we got there from a place that has
the actual pref object; so change the function to take in a
Pref object.
Unfortunately, there is a place we do need to look it up
by name, and that's in Static Pref getters, so we need to
keep that function around (and expose it in Preferences.h)
To minimize code duplication (i.e. not having the exact same
code for ShouldSanitizePreference(Pref) and
ShouldSanitizePreference(PrefWrapper) we do some templating
tricks because even though they expose the same API, they are
not in a class hierarchy where we could just make one function
for a base class.
Depends on D141420
Differential Revision: https://phabricator.services.mozilla.com/D141421
In the following patch we are going to change the signature of
ShouldSanitizePreference to take a Pref object. Pref is only
known to the Preferences compilation unit; so to keep this member
(whose signature will change) we would need to expose the Pref
class. However it will only be a forward declaration, one could
not construct a Pref object in e.g. the gtest.
It is simpler to just remove the member entirely and call
ShouldSanitizePreference unconditionally - the member was only
used for the gtest, and while the gtest will be less robust
because of this change, it will still do some testing.
Depends on D141419
Differential Revision: https://phabricator.services.mozilla.com/D141420
For all subprocesses, if a preference is in the blocklist,
sanitize it. (This preserves the IPC optimization behavior,
kind of. We now generate IPC traffic when we didn't before,
but we omit the value. Values were previously capped at 4 KiB
now they're 0 bytes.)
For Web Content processes, we sanitize a preference if it is
in the blocklist, or if does not have a Default value (i.e.
it is dynamically named). There is an exception list for
dynamically named preferences we know we need though.
In subprocesses, we know if a preference was sanitized
by checking its Sanitized bit.
Depends on D141416
Differential Revision: https://phabricator.services.mozilla.com/D141417
To do the correct thing in Preferences::SerializePreferences
(which is used during subprocess startup) we need to know if
the destination process is a web content process or not.
We add parameters to
SharedPreferenceSerializer::SerializeToSharedMemory that let
us figure that out.
In Preferences::SerializePreferences we fix the call to
aShouldSanitizeFn to pass the correct destination.
Depends on D141415
Differential Revision: https://phabricator.services.mozilla.com/D141416
PreferenceUpdate is the IPC message notifying a child process
that a preference has been updated. To correctly decide whether
or not a value should be sanitized in it, we need to know
what type of destination process it is; we add parameters to
Preferences::GetPreference indicating that.
Inside of ToDomPref we call ShouldSanitizePreference to
correctly populate the sanitized bit.
Depends on D141412
Differential Revision: https://phabricator.services.mozilla.com/D141413
This simplifies the number of negations needed,
and makes things easy to understand. I think
anyway; I know that without renaming it I made
several annoying-to-diagnose negation errors...
Depends on D141411
Differential Revision: https://phabricator.services.mozilla.com/D141412
A couple places where it might be a web content process
still pass 'false' - this will be corrected in a later
patch.
Depends on D141410
Differential Revision: https://phabricator.services.mozilla.com/D141411
Before we would stick all prefs into an immutable shared memory
region and clear our HashMap.
Now we will stick all non-sanitized prefs into the immutable
shared memory region, save the sanitized prefs in a list
temporarily, clear the hashmap, and then repopulate the hashmap
with the sanitized prefs.
As a bit of underlying complexity, to do this we must do some
tricks with the Pref Name Arena which is a chunk of memory
dedicated to storing pref names. That goes away (and we want to
wipe it to save space) - so we just need to move the sanitized
pref names to a new arena.
Depends on D141421
Differential Revision: https://phabricator.services.mozilla.com/D141422
We busted browser_preferences_usage.js by looking up a
preference too many times.
The reason we are now exceeding the pref-reading limit for
this pref is that inside ShouldSanitizePreference all of
our calls to Preferences::Something(pref_name) are causing
pref lookups. _Most_ of the time when we are in
ShouldSanitizePreference, we got there from a place that has
the actual pref object; so change the function to take in a
Pref object.
Unfortunately, there is a place we do need to look it up
by name, and that's in Static Pref getters, so we need to
keep that function around (and expose it in Preferences.h)
To minimize code duplication (i.e. not having the exact same
code for ShouldSanitizePreference(Pref) and
ShouldSanitizePreference(PrefWrapper) we do some templating
tricks because even though they expose the same API, they are
not in a class hierarchy where we could just make one function
for a base class.
Depends on D141420
Differential Revision: https://phabricator.services.mozilla.com/D141421
In the following patch we are going to change the signature of
ShouldSanitizePreference to take a Pref object. Pref is only
known to the Preferences compilation unit; so to keep this member
(whose signature will change) we would need to expose the Pref
class. However it will only be a forward declaration, one could
not construct a Pref object in e.g. the gtest.
It is simpler to just remove the member entirely and call
ShouldSanitizePreference unconditionally - the member was only
used for the gtest, and while the gtest will be less robust
because of this change, it will still do some testing.
Depends on D141419
Differential Revision: https://phabricator.services.mozilla.com/D141420
For all subprocesses, if a preference is in the blocklist,
sanitize it. (This preserves the IPC optimization behavior,
kind of. We now generate IPC traffic when we didn't before,
but we omit the value. Values were previously capped at 4 KiB
now they're 0 bytes.)
For Web Content processes, we sanitize a preference if it is
in the blocklist, or if does not have a Default value (i.e.
it is dynamically named). There is an exception list for
dynamically named preferences we know we need though.
In subprocesses, we know if a preference was sanitized
by checking its Sanitized bit.
Depends on D141416
Differential Revision: https://phabricator.services.mozilla.com/D141417
To do the correct thing in Preferences::SerializePreferences
(which is used during subprocess startup) we need to know if
the destination process is a web content process or not.
We add parameters to
SharedPreferenceSerializer::SerializeToSharedMemory that let
us figure that out.
In Preferences::SerializePreferences we fix the call to
aShouldSanitizeFn to pass the correct destination.
Depends on D141415
Differential Revision: https://phabricator.services.mozilla.com/D141416
PreferenceUpdate is the IPC message notifying a child process
that a preference has been updated. To correctly decide whether
or not a value should be sanitized in it, we need to know
what type of destination process it is; we add parameters to
Preferences::GetPreference indicating that.
Inside of ToDomPref we call ShouldSanitizePreference to
correctly populate the sanitized bit.
Depends on D141412
Differential Revision: https://phabricator.services.mozilla.com/D141413
This simplifies the number of negations needed,
and makes things easy to understand. I think
anyway; I know that without renaming it I made
several annoying-to-diagnose negation errors...
Depends on D141411
Differential Revision: https://phabricator.services.mozilla.com/D141412
A couple places where it might be a web content process
still pass 'false' - this will be corrected in a later
patch.
Depends on D141410
Differential Revision: https://phabricator.services.mozilla.com/D141411
Before we would stick all prefs into an immutable shared memory
region and clear our HashMap.
Now we will stick all non-sanitized prefs into the immutable
shared memory region, save the sanitized prefs in a list
temporarily, clear the hashmap, and then repopulate the hashmap
with the sanitized prefs.
As a bit of underlying complexity, to do this we must do some
tricks with the Pref Name Arena which is a chunk of memory
dedicated to storing pref names. That goes away (and we want to
wipe it to save space) - so we just need to move the sanitized
pref names to a new arena.
Depends on D141421
Differential Revision: https://phabricator.services.mozilla.com/D141422
We busted browser_preferences_usage.js by looking up a
preference too many times.
The reason we are now exceeding the pref-reading limit for
this pref is that inside ShouldSanitizePreference all of
our calls to Preferences::Something(pref_name) are causing
pref lookups. _Most_ of the time when we are in
ShouldSanitizePreference, we got there from a place that has
the actual pref object; so change the function to take in a
Pref object.
Unfortunately, there is a place we do need to look it up
by name, and that's in Static Pref getters, so we need to
keep that function around (and expose it in Preferences.h)
To minimize code duplication (i.e. not having the exact same
code for ShouldSanitizePreference(Pref) and
ShouldSanitizePreference(PrefWrapper) we do some templating
tricks because even though they expose the same API, they are
not in a class hierarchy where we could just make one function
for a base class.
Depends on D141420
Differential Revision: https://phabricator.services.mozilla.com/D141421
In the following patch we are going to change the signature of
ShouldSanitizePreference to take a Pref object. Pref is only
known to the Preferences compilation unit; so to keep this member
(whose signature will change) we would need to expose the Pref
class. However it will only be a forward declaration, one could
not construct a Pref object in e.g. the gtest.
It is simpler to just remove the member entirely and call
ShouldSanitizePreference unconditionally - the member was only
used for the gtest, and while the gtest will be less robust
because of this change, it will still do some testing.
Depends on D141419
Differential Revision: https://phabricator.services.mozilla.com/D141420
Tom Ritter
Butkovits Atila
Cristian Tuns