We can use this telemetry to track the statistics of using
RemoteSettings to serve Safe Browsing data.
The can help us understand if we can roll out this feature to more users.
Depends on D135990
Differential Revision: https://phabricator.services.mozilla.com/D136107
This patch implements UrlClassifierRemoteSettingsService to get SafeBrowsing data (protocol v2)
from RemoteSettings instead of from the Shavar server. This is only used
by data provided by Mozilla.
To distinguish if the data should be coming from RemoteSettings or
Shavar, We added a custom scheme "moz-sbrs" to denote that the data should be
retrieved from Remote Setting. This is done by changing the value of pref
"browser.safebrowsing.provider.mozilla.updateURL" to something like
"moz-sbrf://tracking-protection-list". (Note that the hostname is not
used at this point).
The goal of this patch is to make the new architecture compatible with
the original Safe Browsing design. So we don't notify Safe Browsing
there is new data available (via "sync" event of RemoteSettings). We still follow
how Safe Browsing periodically checks whether there is a newer version of list.
Note.
This patch changes the flow comparing with how we usualy receive SafeBrowsing response from Shavar.
In Shavar case, the list data response usually comes with
"n:21600\ni:listname1\nu:redirectURL1\ni:listname2\nu:redirectURL2 ..." first.
And then we fetch the data again from the redirectURL for each list.
But in the current implementation, responses don't contain
redirectURL anymore (since we already have the data). So the mocked response
will contain all the data needed in one response.
For example:
"n:21600\ni:listname1\n:chunkdata1\ni:listname2\n:chunkdata2...".
Differential Revision: https://phabricator.services.mozilla.com/D135989
We can use this telemetry to track the statistics of using
RemoteSettings to serve Safe Browsing data.
The can help us understand if we can roll out this feature to more users.
Depends on D135990
Differential Revision: https://phabricator.services.mozilla.com/D136107
This patch implements UrlClassifierRemoteSettingsService to get SafeBrowsing data (protocol v2)
from RemoteSettings instead of from the Shavar server. This is only used
by data provided by Mozilla.
To distinguish if the data should be coming from RemoteSettings or
Shavar, We added a custom scheme "moz-sbrs" to denote that the data should be
retrieved from Remote Setting. This is done by changing the value of pref
"browser.safebrowsing.provider.mozilla.updateURL" to something like
"moz-sbrf://tracking-protection-list". (Note that the hostname is not
used at this point).
The goal of this patch is to make the new architecture compatible with
the original Safe Browsing design. So we don't notify Safe Browsing
there is new data available (via "sync" event of RemoteSettings). We still follow
how Safe Browsing periodically checks whether there is a newer version of list.
Note.
This patch changes the flow comparing with how we usualy receive SafeBrowsing response from Shavar.
In Shavar case, the list data response usually comes with
"n:21600\ni:listname1\nu:redirectURL1\ni:listname2\nu:redirectURL2 ..." first.
And then we fetch the data again from the redirectURL for each list.
But in the current implementation, responses don't contain
redirectURL anymore (since we already have the data). So the mocked response
will contain all the data needed in one response.
For example:
"n:21600\ni:listname1\n:chunkdata1\ni:listname2\n:chunkdata2...".
Differential Revision: https://phabricator.services.mozilla.com/D135989
This patch uses Array.includes instead of exact matching to check
whether the test table is present.
This is to address the problem when there is other safe browsing tables
, the testcase fails because `parts` variable contains all the tables.
Differential Revision: https://phabricator.services.mozilla.com/D146614
Change tests and snippets in documentation to use `Date.now()` instead of an arbitrary number like `42`.
This way, we make sure the packaged dump isn't loaded on top of the tests data. Indeed, since Bug 1718083 we load the packaged dump if it's newer than local data.
Differential Revision: https://phabricator.services.mozilla.com/D145579
Given that we only support samesite lax/strict/none in our storage schema,
it's useful to introduce a default value, as required by the spec.
However, that would it hard to distinguish between none/lax when we switch
the default.
So, instead of doing that we use the peculiarities of our current schema
to our advantage: There's a "sameSite" attribute and a "rawSameSite"
attribute, where the latter is the literal value we received from the
server. With this patch, we'll interpret the "sameSite" attribute
based on the laxByDefault pref. This also has the advantage that various
front-end code (e.g., in DevTools) is always reading the "sameSite"
value of nsICookies.
Differential Revision: https://phabricator.services.mozilla.com/D137460
