Bug 213471

This is used by the DeviceIdHashSaltStorage, but I don't remember what this was for, WebRTC? Alex?

(In reply to Carlos Garcia Campos from comment #1)
> This is used by the DeviceIdHashSaltStorage, but I don't remember what this
> was for, WebRTC? Alex?

Yep, it is for WebRTC, they are used to create the device id's the browser send to identify the mic and the camera in the enumerateDevices function. It avoids fingerprinting creating different ids per origin, but allows the user to configure a default device per origin. More information here:

https://w3c.github.io/mediacapture-main/#enumerating-devices

I think there is some API in WebsiteDataStoreConfiguration to change the directory but I don't remember if there is a way to change that from the glib API. This is the original commit:

https://trac.webkit.org/changeset/239513/webkit

(In reply to Michael Catanzaro from comment #0)
> I noticed I have a
> ~/.var/app/org.gnome.Epiphany.Devel/data/webkitgtk/deviceidhashsalts
> directory. ~/.var/app/org.gnome.Epiphany.Devel/data/webkitgtk/ should not
> exist at all because it indicates that WebKit is improperly saving website
> data outside Epiphany's base data directory (although fortunately the
> directory is empty?. We should fix it to use the configured base data
> directory, and maybe also expose API. (But: what are these really,
> deviceidhashsalts? What are they actually for?)
> 

I agree, I think we should use the configured base data directory, they are removed when cookies are removed so the user has control over them, I don't think we need new API. It is a bug, we probably forgot to add the change of this directory and it is using the default location.

(In reply to Alejandro G. Castro from comment #3)
> (In reply to Michael Catanzaro from comment #0)
> > I noticed I have a
> > ~/.var/app/org.gnome.Epiphany.Devel/data/webkitgtk/deviceidhashsalts
> > directory. ~/.var/app/org.gnome.Epiphany.Devel/data/webkitgtk/ should not
> > exist at all because it indicates that WebKit is improperly saving website
> > data outside Epiphany's base data directory (although fortunately the
> > directory is empty?. We should fix it to use the configured base data
> > directory, and maybe also expose API. (But: what are these really,
> > deviceidhashsalts? What are they actually for?)
> > 
> 
> I agree, I think we should use the configured base data directory, they are
> removed when cookies are removed so the user has control over them, I don't
> think we need new API. It is a bug, we probably forgot to add the change of
> this directory and it is using the default location.

Why are they removed with cookies? It's a website data type, so you can fetch and remove it individually like any other type.

(In reply to Carlos Garcia Campos from comment #4)
>
> [...]
>
> > I agree, I think we should use the configured base data directory, they are
> > removed when cookies are removed so the user has control over them, I don't
> > think we need new API. It is a bug, we probably forgot to add the change of
> > this directory and it is using the default location.
> 
> Why are they removed with cookies? It's a website data type, so you can
> fetch and remove it individually like any other type.

It is a recommendation in the spec of how to handle the security information to do it like cookies. It means, we can add support to remove this specific information for a website, but I think currently we just implemented removing it when cookies are removed, this was a long time ago but if I recall correctly this is the code added:

https://trac.webkit.org/changeset/239513/webkit/trunk/Source/WebKit/UIProcess/API/glib/WebKitWebsiteDataManager.cpp

Maybe the spec's recommendation was intended for browsers that don't expose separate website data types in the user interface.

(In reply to Michael Catanzaro from comment #6)
> Maybe the spec's recommendation was intended for browsers that don't expose
> separate website data types in the user interface.

I think we can choose to expose the data type in the API, but still
recommend in the documentation that regular browsers should clear
it along with cookies—unless they have a compelling reason.

Also FTR, I agree that we don't want to expose an ever-increasing
amount of settings for each single small bit of data. Deriving from
the base directories should be the norm.

These APIs are all deprecated since 253824@main. Don't need to add more.