Bug 197845 – [WPE][GTK] Enable hyperlink auditing

• Component: WebKitGTK
• Status: RESOLVED FIXED

[Michael Catanzaro]

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.

[Michael Catanzaro]

Created attachment 369748 [details]
Patch

[EWS Watchlist]

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

[EWS Watchlist]

Attachment 369748 [details] did not pass style-queue:


ERROR: Source/WebKit/UIProcess/API/glib/WebKitSettings.cpp:782:  Weird number of spaces at line-start.  Are you using a 4-space indent?  [whitespace/indent] [3]
Total errors found: 1 in 4 files


If any of these errors are false positives, please file a bug against check-webkit-style.

There is a problem with the apple position in the
"link-click-analytics-and-privacy" page - the claims are patently
false.

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
page.

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)

[Michael Catanzaro]

Browsers can't block XHR without breaking the web; there's just no way. Your argument doesn't make any sense.

[Michael Catanzaro]

Ping reviewers.

[WebKit Commit Bot]

Comment on attachment 369748 [details]
Patch

Clearing flags on attachment: 369748

Committed r246352: <https://trac.webkit.org/changeset/246352>

[WebKit Commit Bot]

All reviewed patches have been landed.  Closing bug.