213471 2020-06-22 10:17:38 -0700 [WPE][GTK] Add API to configure deviceidhashsalts directory to WebKitWebsiteDataManager 2022-09-19 10:31:31 -0700 1 1 1 Unclassified WebKit WebKitGTK WebKit Nightly Build PC Linux RESOLVED WONTFIX https://bugs.webkit.org/show_bug.cgi?id=239521 https://bugs.webkit.org/show_bug.cgi?id=242438 P2 Normal --- 1 mcatanzaro webkit-unassigned alex aperez bugs-noreply cgarcia mcatanzaro rexlsf99 oldest_to_newest 1665086 0 mcatanzaro 2020-06-22 10:17:38 -0700 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. 1665304 1 cgarcia 2020-06-22 23:07:15 -0700 This is used by the DeviceIdHashSaltStorage, but I don't remember what this was for, WebRTC? Alex? 1665307 2 alex 2020-06-22 23:45:52 -0700 (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 1665308 3 alex 2020-06-22 23:50:24 -0700 (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. 1665310 4 cgarcia 2020-06-23 00:14:08 -0700 (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. 1665327 5 alex 2020-06-23 03:58:14 -0700 (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 1665356 6 mcatanzaro 2020-06-23 06:10:03 -0700 Maybe the spec's recommendation was intended for browsers that don't expose separate website data types in the user interface. 1881265 8 aperez 2022-07-07 02:39:34 -0700 (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. 1899529 9 mcatanzaro 2022-09-19 10:31:31 -0700 These APIs are all deprecated since 253824@main. Don't need to add more.