Analytics mode

[privacycg]

Analytics mode

[othermaciej]

Can you give some examples of the kinds of APIs you’re thinking of?

[pes10k]

Sure! The two off the top of my head (Im sure they're more, will keep braining)

1. Everything behind Reporting API (some of it should just not be in the platform, but some seems like it could be useful to include w/ consent, like out-of-memory reports, CSP reports, maybe intervention reports)
2. WebRTC stats API

[othermaciej]

For some APIs like this, we've argued that the feature should be provided by developer tools, not as part of the web platform. But it's argued that they are needed in the field for telemetry purposes. Do you think Debug Mode will overcome such objections?

[pes10k]

I think a debug mode would allow us to split the knot. I am 100% certain that some parties will want every bit of info they can get, for a variety of purposes, but I think an explicit "debug" mode:

(i) is something users could actually understand
(ii) could actually help unbreak sites and help developers
(iii) wouldn't harm the privacy of the platform (e.g web w/ the defaults checked)

So yes, I think having a "on in debug mode" would flip the majority in a number of standards conversations

[pes10k]

Other APIs that would make sense here is basically everything that hangs of performance.*

[othermaciej]

Yeah, performance.* is exactly where I’m not sure we can get agreement, because the stated use case is gathering of field data across the whole user population, not lab testing or debugging an individual user’s problem.

(There might be solutions to mass telemetry that don’t leak individual user data, but asking lots of users to turn on debug mode probably wouldn’t cut it.)

[pes10k]

For my two cents, gathering of field data across the whole user population (w/o user consent or knowledge) should explicitly be a thing PrivacyCG / PING works to prevent. Turning every browser on the web into your debugging agent is not user-serving, and is tangled up w/ all sorts of privacy harm.

If we had a debugging mode though, we could at least have a standard way that automation, consenting users, etc could all interact with these features

[othermaciej]

Hmm. I'm thinking about how this is usually done for native apps or operating systems. Usually there is a one-time user choice to opt in or out of analytics. I could imagine a similar one-time user choice that gates websites access to all performance APIs and similar things. Or browsers could choose to make it a per-site preference.

An opt-in analytics/telemetry mode might be a different thing than a debug mode, if some web platform features truly exist for the purpose of web developers debugging live, rather than analyze broad field data.

[pes10k]

I don’t have strong feelings about whether it should be one toggle or two, as long as: 1) either / both are opt in 2) we can keep wide spread data collection out of the common path 3) we can enable cases where the data is highly useful

…

On Feb 22, 2020, at 12:53, Maciej Stachowiak ***@***.***> wrote:  Hmm. I'm thinking about how this is usually done for native apps or operating systems. Usually there is a one-time user choice to opt in or out of analytics. I could imagine a similar one-time user choice that gates websites access to all performance APIs and similar things. Or browsers could choose to make it a per-site preference. An opt-in analytics/telemetry mode might be a different thing than a debug mode, if some web platform features truly exist for the purpose of web developers debugging live, rather than analyze broad field data. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.

[TanviHacks]

@pes10k @othermaciej - Would you like time on the teleconference this week to discuss this proposal?

[pes10k]

Sure, i think that'd be fine. I think conversation could be very brief top fwiw

[jameshartig]

We use performance.entries to collect script timing data from a small (random) percent of traffic in order to understand real-world performance of our platform. I think a way for a user to opt-out (or opt-in) of telemetry, like other platforms, makes sense. Additionally, if there's a particular issue in a particular region we might temporarily increase the percent in that region to gather more useful statistics for aiding in debugging or root cause analysis.

Getting rid of this access completely would be detrimental to us but I think there are definitely ways we could make it more privacy-respecting. Would it be acceptable to somehow force telemetry to be crossorigin=anonymous or maybe a different way (HTTP Header or similar) to opt-into getting a set of performance metrics sampling in a privacy-respecting way. We don't care about other entries and how they perform, only our own.

[erik-anderson]

@pes10k is this an area you think folks would like to come back to? There are various APIs that might interact with such an idea; are there any that are actively looking for such a mode?

[pes10k]

I still think this would be a good and useful feature on the Web, but I am not aware of any implementor interest. I can think of a number of features that could hook into it (Reporting API, Resource Timing, Performance API, etc) but the groups authoring those specs do not seem interested either for the most part (though, I believe Yoav expressed they might be open to discussing more at one point, my memory could be wrong…)

Anyway, all that is to say, i still think this would be a good feature for PrivacyCG, but would probably be more successful thought of as coming from PrivacyCG/WG and applied to other specs, than originating from other specs. If other vendors or PrivacyCG members feel similarly though, Id be very happy to work on this