[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

--- Comment #14 from Carlos Garcia Campos <cgarcia at igalia.com> ---
(In reply to Michael Catanzaro from comment #10)
> (In reply to Carlos Garcia Campos from comment #9) 
> > 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.
> 
> ITP is more than just cookies, though. Besides stripping Referers and
> overriding the cookie policy, it will also wipe localstorage and IndexedDB
> after a certain number of days (one week?) when the domain is "prevalent."
> So WebKitCookieManager doesn't seem to be the right place either. I guess
> WebKitWebsiteDataManager is probably best, but we could give it a different
> name, e.g.
> webkit_website_data_manager_set_intelligent_tracking_prevention_enabled().
> And then just document that this function can enable cookie policy that is
> more restrictive than that set by webkit_cookie_manager_set_accept_policy().

webkit_website_data_manager_set_intelligent_tracking_prevention_enabled() sounds good to me.

> I would not expose [is,set,clear]PrevalentResource or setUseITPDatabase. We
> can always expose more in the future if an application ever wants to use
> them.

Those were just examples, there are a lot of public methods in WebsitedataStore related to ITP and I have no idea what they are for or if they are just there for testing.

> > > 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.
> 
> I could check with my bank's bill pay website... I don't use it because it
> breaks with third-party cookies disabled. So if ITP is enabled and cookie
> policy is set to always accept cookies, the always accept cookies should
> effectively be overridden.
> 
> I also found https://github.com/speedarius/third-party-cookie-tester, but
> that looks like some effort to get set up.
> 
> I wonder how we would expose this in Epiphany's preferences dialog.
> Currently we have a simple tri-state policy: always accept, block third
> party (default), never accept. I guess we could change it to a boolean
> enable ITP or disable ITP setting. Probably Epiphany is not the right
> browser to use if you're interested in disabling cookies entirely, right?

Shouldn't we just enable it unconditionally?

-- 
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/20200415/5c6deeff/attachment.htm>