While we already have bugs filed on Event Telemetry for addons, we need to re-check if that planning is complete & up-to-date.

I have the plan for Q2 laid out here: https://docs.google.com/document/d/1riRfomU_EJfsekKveRwzArKH5sqfr4U6RHf1hwzdoMA/ Next is clearing the last open questions and re-checking bugs, filing new ones where needed.

Mossop, Mathieu, your names were mentioned for Kinto client integration and clock skew. From what gather, "services.blocklist.clock_skew_seconds" is something that i could hang client logic off? https://dxr.mozilla.org/mozilla-central/search?q=blocklist+clock_skew_seconds&redirect=true Is that true? And what are the constraints? - From when on can i expect this to be set? - How often is it updated? - What precision can i expect from it? (A precision in the day range would be sufficient here). - Can we get a relatively stable clock from it? Or do we only have the clock skew data? Short context: I want to be able to expire Telemetry probes on the Firefox client automatically by date, but client clocks are not reliable enough for that. If there is a sufficiently reliable client clock solution, i could compare expiry dates for Telemetry probes against it.

Hi! This clock skew is indeed something that is updated when the blocklists are updated. AFAIK it is used for certificates expiration. :mgoodwin was the original author :) > could hang client logic off? Yes, I believe so. Mark could confirm. > And what are the constraints? Apart from the fact that it has no value on empty profiles, and it's very low update frequency, I don't see many more specific constraints. > - From when on can i expect this to be set? It will be set after the first blocklist service notify(). I don't have the exact information about when it is triggered for the first time. > - How often is it updated? It is updated along with the blocklist service notify(): AFAIK every 24H > - What precision can i expect from it? (A precision in the day range would be sufficient here). It's the difference between settings server time and local time in seconds. > - Can we get a relatively stable clock from it? Or do we only have the clock skew data? We only store the difference in that preference. You could build a clock on top of it I guess. I hope I gave you some insights. Let's see if Mark has more details to share :)

So Matt's covered all of the important points. The update frequency is probably less of an issue than the fact that it's not hugely accurate; due to CDN constraints, the skew value could be out by a few hours. That said, it's still fine for use in (coarse) expiry calculations and the like. (In reply to Mathieu Leplatre (:leplatrem) from comment #3) > > could hang client logic off? > > Yes, I believe so. Mark could confirm. Yes. We are doing just that.

Thanks Mathieu & Mark! I'm tracking the clock-specific part out to bug 1367366.