Bug 213471 – [WPE][GTK] Add API to configure deviceidhashsalts directory to WebKitWebsiteDataManager

• Status: RESOLVED
• Resolution: WONTFIX
• Component: WebKitGTK

[Michael Catanzaro]

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?)

We should probably add a warning comment to WebsiteDataStoreGLib.cpp to warn not to add new default storage directories without hooking them up to base data directory in WebKitWebsiteDataManager.cpp.

[Carlos Garcia Campos]

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

[Alejandro G. Castro]

(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

[Alejandro G. Castro]

(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.

[Carlos Garcia Campos]

(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.

[Alejandro G. Castro]

(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

[Michael Catanzaro]

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

[Adrian Perez]

(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.

[Michael Catanzaro]

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