Enable Safe Browsing V4 on Fennec Nightly 58

RESOLVED FIXED in Firefox 58

Status

()

Toolkit
Safe Browsing
P2
normal
RESOLVED FIXED
4 months ago
2 months ago

People

(Reporter: francois, Assigned: francois)

Tracking

(Blocks: 1 bug)

unspecified
mozilla58
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox58 fixed)

Details

(Whiteboard: #sbv4-m10)

MozReview Requests

()

Submitter Diff Changes Open Issues Last Updated
Loading...
Error loading review requests:

Attachments

(1 attachment)

(Assignee)

Description

4 months ago
As tested on https://bugzilla.mozilla.org/show_bug.cgi?id=1392204#c18, the following prefs can now be set on Fennec:

  urlclassifier.malwareTable = goog-harmful-proto,goog-unwanted-proto,test-malware-simple,test-unwanted-simple,test-harmful-simple
  urlclassifier.phishTable = goog-phish-proto,test-phish-simple

These prefs however will need to stay on V2 for Fennec for now because these lists are not available on the V4 server when the platform is set to Android:

  urlclassifier.downloadAllowTable
  urlclassifier.downloadBlockTable
(Assignee)

Comment 1

4 months ago
We are choosing to do this after 57 in order to have a full Nightly cycle of testing for this feature.
(Assignee)

Updated

3 months ago
Assignee: nobody → francois
Status: NEW → ASSIGNED
Comment hidden (mozreview-request)

Comment 3

3 months ago
mozreview-review
Comment on attachment 8912052 [details]
Bug 1394017 - Default to Safe Browsing V4 on Fennec.

https://reviewboard.mozilla.org/r/183434/#review188580

Looks good to me, thanks!
Attachment #8912052 - Flags: review?(dlee) → review+
(Assignee)

Comment 4

3 months ago
Tested locally on Desktop and Fennec.

Comment 5

3 months ago
Pushed by fmarier@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/bca021fc3073
Default to Safe Browsing V4 on Fennec.r=dimi

Updated

3 months ago
Depends on: 1403431
https://hg.mozilla.org/mozilla-central/rev/bca021fc3073
Status: ASSIGNED → RESOLVED
Last Resolved: 3 months ago
status-firefox58: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla58

Comment 7

2 months ago
This bug may have contributed to a sudden change in the Telemetry probe URLCLASSIFIER_VLPS_FALLOCATE_TIME[1] which seems to have occurred in Nightly 20170927[2].
There was a slight increase in file allocation time which might mean a heavier use of variable-length prefix sets... or something?

Is this an improvement? A regression?

Is this intentional? Is this expected?

Is this probe (still) measuring something useful?
[1]: http://alerts.telemetry.mozilla.org/index.html#/detectors/1/metrics/2026/alerts/?from=2017-09-27&to=2017-09-27
[2]: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=7d15bc419c6cd7e9f3b4d41370c3b0e5990c8d1b&tochange=35fbf14b96a633c3f66ea13c1a163a3f3a4219b9
Flags: needinfo?(francois)
(Assignee)

Comment 8

2 months ago
(In reply to Chris H-C :chutten from comment #7)
> This bug may have contributed to a sudden change in the Telemetry probe
> URLCLASSIFIER_VLPS_FALLOCATE_TIME[1] which seems to have occurred in Nightly
> 20170927[2].
> There was a slight increase in file allocation time which might mean a
> heavier use of variable-length prefix sets... or something?

That makes sense. Android devices are most likely slower than desktops at allocating variable prefixes (or anything, really).

Prior to this change, the variable prefixes were only on Desktop.

> Is this an improvement? A regression?
> 
> Is this intentional? Is this expected?

Given the above, I'd say it's expected.

> Is this probe (still) measuring something useful?

Small changes are not very meaningful, but this probe will alert us if we land a bad regression in this part of the code.
Flags: needinfo?(francois)
You need to log in before you can comment on or make changes to this bug.