Bug 197845 - [WPE][GTK] Enable hyperlink auditing
Summary: [WPE][GTK] Enable hyperlink auditing
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebKitGTK (show other bugs)
Version: WebKit Nightly Build
Hardware: PC Linux
: P2 Normal
Assignee: Michael Catanzaro
Depends on:
Reported: 2019-05-13 11:03 PDT by Michael Catanzaro
Modified: 2019-06-12 07:50 PDT (History)
8 users (show)

See Also:

Patch (3.40 KB, patch)
2019-05-13 11:07 PDT, Michael Catanzaro
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Michael Catanzaro 2019-05-13 11:03:48 PDT
WebKitSettings::enable-hyperlink-auditing is enabled by default in WebPreferences.yaml but disabled by default in WebKitSettings.cpp. We should probably turn it on.

See https://webkit.org/blog/8821/link-click-analytics-and-privacy/ for why having this off probably slows down web content, and why this is not a privacy risk.
Comment 1 Michael Catanzaro 2019-05-13 11:07:14 PDT
Created attachment 369748 [details]
Comment 2 EWS Watchlist 2019-05-13 11:09:58 PDT
Thanks for the patch. If this patch contains new public API please make sure it follows the guidelines for new WebKit2 GTK+ API. See http://trac.webkit.org/wiki/WebKitGTK/AddingNewWebKit2API
Comment 3 EWS Watchlist 2019-05-13 11:10:09 PDT Comment hidden (spam)
Comment 4 enometh 2019-05-13 18:47:29 PDT
There is a problem with the apple position in the
"link-click-analytics-and-privacy" page - the claims are patently

The page is apologetics from apple for removing the ability to block
pings from safari - as they have apparently removed this switch there. The
goal is tomake all ping requests and violations reporting non-optional, thereby
removing the mechanism from the browser user to "do anything about it
to protect himself"

Any communication from the browser to a server that cannot be
controlled by the user of the browser is a privacy risk.  This should
be self-evident. It is this basic truth that is under attack on that

The argument for XHR sync and user-experience to motivate this policy
change is bogus for the simple reason that they can be blocked. XHRs
can be blocked by the user because they go through documented
mechanisms which are exposed to the user via the webprocess.

If there is no XHR being sent there is no loss of "user experience" as
no tracking is sent from the user at all - and there is no loss of
either privacy or user experience.

Pings and beacons and reporting technology that address "user
experience" are only addressing the issue of how to send tracking and
privacy-leaking information from the user without the user ever
knowing it and without the user being able to do anything about it.

The only way to disable tracking and protect privacy is to expose the
user to a mechanism.  This particular technology is significant
because all the browser manufacturers are acting in concert to remove
the mechanisms from the user to protect himself.

It is a shame that all opensource browser development has been
dishonestly subverted to remove functionality and control from the
user all the while under a false narrative. (For example epiphany is
advertised as an independent browser focussing on privacy and
security. But everytime unsuspecting user uses epiphany it tries to
fingerprint the user with his ip on  firefox and google servers)
Comment 5 Michael Catanzaro 2019-05-14 05:29:10 PDT
Browsers can't block XHR without breaking the web; there's just no way. Your argument doesn't make any sense.
Comment 6 Michael Catanzaro 2019-06-06 06:27:14 PDT
Ping reviewers.
Comment 7 WebKit Commit Bot 2019-06-12 07:50:22 PDT
Comment on attachment 369748 [details]

Clearing flags on attachment: 369748

Committed r246352: <https://trac.webkit.org/changeset/246352>
Comment 8 WebKit Commit Bot 2019-06-12 07:50:23 PDT
All reviewed patches have been landed.  Closing bug.