[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

Adrian Perez <aperez at igalia.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |aperez at igalia.com

--- Comment #16 from Adrian Perez <aperez at igalia.com> ---
(In reply to Carlos Garcia Campos from comment #14)
> (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.

Wow, this is a mouthful! If nobody is against it, I would prefer to use
“webkit_website_data_manager_set_itp_enabled()”—and that still remains
pretty long =)

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

Do you mean in WebKit{GTK,WPE} or in Epiphany? I would have it enabled by
default on both. For WebKit, as long as ITP can be disabled using the API,
having it enabled by default sounds good to me—it's good to make defaults
lean towards the more secure or privacy-respecting settings, so developers
embedding a WebKitWebView in an application get the “best” settings without
needing additional work. Dunno if Epiphany can have the setting always-on,
but we could have a setting without checkbox in the preferences window and
try it out for a while before taking a final decision.

-- 
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/dad70bc4/attachment-0001.htm>