*DRAFT* Move MediaDeviceIDSalt from chrome/ to components/ and use it in Android WebView.

Move MediaDeviceIDSalt from chrome/ to components/ and use it in Android WebView.

This uses a random salt to produce hashed media device IDs.
This makes device IDs harder to track.

BUG=315022

[Guido Urdaneta, 2016-05-16 16:08:28]

guidou@chromium.org changed reviewers:
+ jochen@chromium.org, torne@chromium.org

[Guido Urdaneta, 2016-05-16 16:08:29]

torne@chromium.org: Please review changes in android_webview

jochen@chromium.org: Please review changes in components/ and chrome/

[Guido Urdaneta, 2016-05-16 16:08:46]

Description was changed from

==========
Move MediaDeviceIDSalt frome chrome to components and use it in Android WebView.

This uses a random salt to produce hashed media device IDs.
This makes device IDs harder to track.

BUG=315022
==========

to

==========
Move MediaDeviceIDSalt from chrome/ to components/ and use it in Android
WebView.

This uses a random salt to produce hashed media device IDs.
This makes device IDs harder to track.

BUG=315022
==========

[Torne, 2016-05-16 16:12:50]

Before I review in detail: if this is a thing that all consumers of content
should be doing for user privacy, can it maybe be integrated directly into the
media code instead somehow, so that it's applied to all content embedders
without them doing anything? Or is there some reason why that's not possible?

[Guido Urdaneta, 2016-05-16 16:41:06]

guidou@chromium.org changed reviewers:
- jochen@chromium.org

[Guido Urdaneta, 2016-05-16 16:46:03]

On 2016/05/16 16:12:50, Torne wrote:
> Before I review in detail: if this is a thing that all consumers of content
> should be doing for user privacy, can it maybe be integrated directly into the
> media code instead somehow, so that it's applied to all content embedders
> without them doing anything? Or is there some reason why that's not possible?

I think the reason the default implementation in content uses a fixed salt is to
make it stateless.
If we change it to have a random salt by default, content::ResourceContext will
need to keep that salt as an std::string in its state.
The cost would be to have this extra (empty) string in the state for the chrome
profile implementation, which has to store the salt as preferences.
The other embedders I think would be OK with the new default behavior.
Let's put his on hold while I discuss with the team here if that cost is
acceptable. I'll get back to you if the decision is to proceed with this CL.

[Guido Urdaneta, 2016-05-17 11:51:10]

guidou@chromium.org changed reviewers:
+ tommi@chromium.org
- torne@chromium.org

[Guido Urdaneta, 2016-05-17 11:53:41]

tommi: this is approach 4, as discussed in crbug.com/315022

[Guido Urdaneta, 2016-05-17 14:08:49]

guidou@chromium.org changed reviewers:
+ jochen@chromium.org
- tommi@chromium.org

[Torne, 2016-05-17 18:09:29]

On 2016/05/16 16:46:03, Guido Urdaneta wrote:
> On 2016/05/16 16:12:50, Torne wrote:
> > Before I review in detail: if this is a thing that all consumers of content
> > should be doing for user privacy, can it maybe be integrated directly into
the
> > media code instead somehow, so that it's applied to all content embedders
> > without them doing anything? Or is there some reason why that's not
possible?
> 
> I think the reason the default implementation in content uses a fixed salt is
to
> make it stateless.
> If we change it to have a random salt by default, content::ResourceContext
will
> need to keep that salt as an std::string in its state.
> The cost would be to have this extra (empty) string in the state for the
chrome
> profile implementation, which has to store the salt as preferences.
> The other embedders I think would be OK with the new default behavior.
> Let's put his on hold while I discuss with the team here if that cost is
> acceptable. I'll get back to you if the decision is to proceed with this CL.

OK, thanks. WebView's prefs aren't persistent anyway (we've not yet needed to
persist any prefs and only have a prefstore to satisfy some dependencies that
need one) - not sure if that impacts this decision.

[Guido Urdaneta, 2016-05-18 09:35:22]

guidou@chromium.org changed reviewers:
- jochen@chromium.org

[Guido Urdaneta, 2016-05-18 09:38:26]

On 2016/05/17 18:09:29, Torne wrote:
> On 2016/05/16 16:46:03, Guido Urdaneta wrote:
> > On 2016/05/16 16:12:50, Torne wrote:
> > > Before I review in detail: if this is a thing that all consumers of
content
> > > should be doing for user privacy, can it maybe be integrated directly into
> the
> > > media code instead somehow, so that it's applied to all content embedders
> > > without them doing anything? Or is there some reason why that's not
> possible?
> > 
> > I think the reason the default implementation in content uses a fixed salt
is
> to
> > make it stateless.
> > If we change it to have a random salt by default, content::ResourceContext
> will
> > need to keep that salt as an std::string in its state.
> > The cost would be to have this extra (empty) string in the state for the
> chrome
> > profile implementation, which has to store the salt as preferences.
> > The other embedders I think would be OK with the new default behavior.
> > Let's put his on hold while I discuss with the team here if that cost is
> > acceptable. I'll get back to you if the decision is to proceed with this CL.
> 
> OK, thanks. WebView's prefs aren't persistent anyway (we've not yet needed to
> persist any prefs and only have a prefstore to satisfy some dependencies that
> need one) - not sure if that impacts this decision.

We decided that content/public was not the right place to implement random
salts.
However, since none of the embedders that need random salts can or need to
persist the salt, we will go for a simpler approach.
Closing this in favor of https://codereview.chromium.org/1987643002/