Tracking Protection list updates are not working

RESOLVED INVALID

Status

()

Toolkit
Safe Browsing
P1
critical
RESOLVED INVALID
2 years ago
2 years ago

People

(Reporter: gcp, Unassigned)

Tracking

48 Branch
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

2 years ago
https://bugzilla.mozilla.org/show_bug.cgi?id=1237396#c67

"On my Nightly, I have TP in private browsing enabled, and the strict list. Investigating the profile shows the blocklists were last updated 2016-04-26.

Did we break the feature?"

Also, I switched to "strict" lists a while ago and there's no mozfull-* files in my profile.

Potential regressors, given the timing I'd say bug 1033450.
(Reporter)

Updated

2 years ago
Blocks: 1237396
(Reporter)

Comment 1

2 years ago
Uh actually that's 2016-03-26 :-(
So this is 48 and 49? I think we should request tracking for those releases.
(Reporter)

Comment 3

2 years ago
I'm testing Nightly, trying to find out what's wrong.

My Linux machine does seem to be updating :-/
(Reporter)

Comment 4

2 years ago
Tested a second Windows machine. Switching to the Strict list produces mozfull files. Switching back doesn't seem to update the regular files past 2016-04-29. I'm not sure how often the list receive updates?

I'll have to investigate with logging on the original machine to see what's up.
Priority: -- → P1
(In reply to Gian-Carlo Pascutto [:gcp] from comment #1)
> Uh actually that's 2016-03-26 :-(

The last time we merged changes to the list was on 2016-03-23:

  https://github.com/mozilla-services/shavar-prod-lists/pull/13

So that looks fine to me.
gcp, based on comment 5, do you still think there's a bug?
Flags: needinfo?(gpascutto)
(Reporter)

Comment 7

2 years ago
Alright, that looks good then. Switching list types doesn't cause an update to mozfull*- to happen, though I see 

browser.safebrowsing.provider.mozilla.nextupdatetime=42

being set, corresponding to bug 1214454. That looks like an issue?
Flags: needinfo?(gpascutto)
(In reply to Gian-Carlo Pascutto [:gcp] from comment #7)
> Alright, that looks good then. Switching list types doesn't cause an update
> to mozfull*- to happen, though I see 
> 
> browser.safebrowsing.provider.mozilla.nextupdatetime=42
> 
> being set, corresponding to bug 1214454. That looks like an issue?

Both "1" and "42" are times way in the past so they should both work just fine in terms of forcing an immediate update.

One is more fun than the other of course :)
(Reporter)

Comment 9

2 years ago
>so they should both work just fine in terms of forcing an immediate update.

Right so I still think there's something I need to investigate here, not clear why I wasn't getting mozfull files on this Windows profile.
(Reporter)

Comment 10

2 years ago
I rechecked and my mozfull files are updated 2016-06-06. Don't really understand what went wrong before but no evidence it's broken now.
Status: NEW → RESOLVED
Last Resolved: 2 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.