[Webkit-unassigned] [Bug 177943] [GTK][WPE] Add API to configure and enable resource load statistics

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=177943

Carlos Garcia Campos <cgarcia at igalia.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |wilander at apple.com,
                   |                            |youennf at gmail.com

--- Comment #9 from Carlos Garcia Campos <cgarcia at igalia.com> ---
(In reply to Michael Catanzaro from comment #8)
> Comment on attachment 396270 [details]
> Patch
> 
> View in context:
> https://bugs.webkit.org/attachment.cgi?id=396270&action=review
> 
> > Source/WebKit/UIProcess/API/glib/WebKitWebsiteDataManager.cpp:735
> > + * webkit_website_data_manager_set_resource_load_statistics_enabled:
> 
> I'm OK with this, but it's important to understand that the
> WebsiteDataStore-level API is a bit misnamed. It controls all of ITP, not
> just resource load statistics.

That's a good point. We could move this to the WebKitCookieManager if it makes more sense. I also wonder about other public API in WebsiteDataStore like isPrevalentResource, setPrevalentResource, clearPrevalentResource, setUseITPDatabase, etc. Are those only for testing? If we are going to expose more API than just enable/disable ITP we might consider adding an ITP manager.

> E.g. this will probably cause third-party
> cookies to be blocked regardless of the WebKitCookieAcceptPolicy(?). It will
> certainly cause Referer headers to be stripped. Etc. A less-misleading name
> might be:
> webkit_website_data_manager_set_intelligent_tracking_prevention_enabled().
> But then it would feel more at home on the WebKitWebContext, rather than
> WebKitWebsiteDataManager. But that would be the wrong place, because
> internally it really is a property of the WebsiteDataStore, not the
> WebProcessPool.

I don't know much about ITP, to be honest.

> Conclusion: *shrug*. Maybe we could keep the current name but document that
> it has additional effects in addition to enabling statistics tracking? I
> don't know, just something to think about.
> 
> I would investigate the impact on cookie policy regardless. We might want to
> use a g_warning() if the WebKitCookiePolicy is inconsistent with ITP?

I don't even know how to test it apart from running layout tests.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20200414/d3115336/attachment-0001.htm>