1589494 - make webrequest urlclassification a part of the public api

Status: RESOLVED FIXED

(WebExtensions :: Request Handling, task, P3)

Description

[Shane Caraveo (:mixedpuppy)]

It's currently only available to privileged extensions, but I don't see a reason to leave it that way. Creating a new bug to resolve any issues remaining in that regard.

Docs are in bug 1547140 comment 22

Comment 1

[Philipp Kewisch [:Fallen][📱📆]]

Sounds good to me, lets make it public!

Comment 2

[Shane Caraveo (:mixedpuppy)]

Attachment: Bug 1589494 make webrequest urlclassification non-privileged

Comment 3

[Shane Caraveo (:mixedpuppy)]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=f452e1f9b79f7d1f1f3003f219674b3def64e168

Comment 4

[Shane Caraveo (:mixedpuppy)]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=5ce88da3ed04e67e770052e22b207bac6aa5fb5b

Comment 5

[Shane Caraveo (:mixedpuppy)]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=59386d7de80ec0ed866d6a16cd7bce2e7bd33bab

Comment 6

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/4bfd86187dd6
make webrequest urlclassification non-privileged r=rpl

Comment 7

[Daniel Varga [:dvarga]]

https://hg.mozilla.org/mozilla-central/rev/4bfd86187dd6

Comment 8

[Miruna Curtean]

Hello,

If this ticket requires manual testing please provide the steps to reproduce/test. Otherwise, the "qe verify -" flag should be set.
Thank you

Comment 9

[Richard Bloor]

I'm currently hitting an issue with timeouts when updating MDN pages, however, the updated documentation for this change is available on https://wiki.developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/webRequest/onAuthRequired and a PR for updating the compatibility data here: https://github.com/mdn/browser-compat-data/pull/5757
Please let me know if I need to make any changes and I will finish duplicating the documentation across the events when I can.

Comment 10

[Shane Caraveo (:mixedpuppy)]

Will that make it to every webRequest/on* page?

For the first part where it says "The type of tracking associated with the request, if with the request has been classified" we might want to mention that this is the classification that Firefox Tracking Protection creates for each request.

Comment 11

[Richard Bloor]

Thanks for the feedback, I added the note about Firefox Tracking Protection. I also managed to get past the timeouts and all the pages are updated. Please let me know if I can clear the dev-doc-needed.

Comment 12

[Shane Caraveo (:mixedpuppy)]

I missed this:

"socialtracking, socialtracking_facebook, socialtracking_linkedin, socialtracking_twitter: similar to the tracking categories but more specific to social tracking. The major social networks have their own flag."

We don't expose the network specific flags.

Otherwise looks good to me.

Comment 13

[Richard Bloor]

Sorry, to clarify you mean it should read "socialtracking: similar to the tracking categories but more specific to social tracking."

Comment 14

[Richard Bloor]

I've noted that the schema doesn't list socialtracking:

      {
        "id": "UrlClassificationFlags",
        "type": "string",
        "enum": ["fingerprinting", "fingerprinting_content", "cryptomining", "cryptomining_content",
                 "tracking", "tracking_ad", "tracking_analytics", "tracking_social", "tracking_content",
                 "any_basic_tracking", "any_strict_tracking", "any_social_tracking"],
        "description": "Tracking flags that match our internal tracking classification"
      },

so I'll remove all reference to socialtracking, however, is "any_social_tracking: a meta flag that combines any social tracking flags." OK as presumably it's only a "meta" flag for tracking_social.

Comment 15

[Shane Caraveo (:mixedpuppy)]

(In reply to Richard Bloor from comment #14)

I've noted that the schema
so I'll remove all reference to socialtracking, however, is "any_social_tracking: a meta flag that combines any social tracking flags." OK as presumably it's only a "meta" flag for tracking_social.

yes.