Dan: I like their explainer. This is about telemetry

Sangwhan: to some extent

Dan: tread carefully.. talking about information that could be used to expose personal data

Sangwhan: how many states are available? Spreadsheet..

Dan: 128 entries..

Sangwhan: would this potentially leak information about if the user is using an extension that in anyway modifies the document? I don't think they call that out. In the vanilla browser setup it would not lead any extra information about the user. I guess it might... no it won't. To the origin it won't. If there's an extension that modifies the website or runs any extra scripts on the website that will trigger.. potentailly leak some information about a particular user. One extra bit of entropy to identify the user. I don't know if that's serious but they should call that out.

Dan: I don't think they have privacy and security considerations... They've answered our questions but that's not the considerations section. Where's the actual spec?

Sangwhan: I think this is early.

Dan: so in their response to the s&p questionnaire they've said yes it has a privacy considerations section now, but I think they just mean they have answered our questionnaire. The kind of potential privacy risk Sangwhan is talking about is something that should fit into a privacy considerations section which still appears to be missing.

Sangwhan: do we require that..?

Dan: they have said they have one. Does look like something where it's sent back to the server out of band to aid the developer. We had a whole discussion about telemetry in the PrivacyTF as well and the fact that ideally browsers should be asking maybe as a first time use asking users are you okay with this browser enabling websites to gather telemetry in order to aid the development of the websites? That's something most applications ask. And we should give users an opportunity to answer no if they don't want telemetry to be shared. This would seem to fit under that category. This is something in the proposed privacy principles.. feels like it fits in the same category. I can leave a comment.

Sangwhan: imagine normally not restored would not happen but you have an extension that messes with the scripting context of the website, eg. tamper monkey, which will trigger not restored to happen for a reason. That will correlate the user with extra information. Invalidates some of their s&p responses, I wonder if they're aware of this.

hi @rubberyuzu thanks for this. We're picking it up now and discussing in the context of other bfcache-related reviews. One thing that came to my attention: since this is telemetry there should probably be additional scrutiny about the privacy-related aspects of this proposal. You've indicated that there's a privacy & security section but I think we'd like to see more detail here. 

From @cynthia : If there's an extension that modifies the website or runs any extra scripts on the website that will trigger a potential leak of some information about the user. 

Sangwhan: what I saw as a potential issue - same for everybody - info is already available to website. If you have extensions involved that can change the bfcache.notresotred reason. That has the potential to leak what kind of extension this user has. They did address... I think it's OK that websites know that an extension triggered it - they won't know what extension.

Dan: in the priv tf we're talking about telemetry and what kind of consent browsers should have from users before allowing telemetry-gathering APIs to function... we should be tracking functions that are about collecting telemetry.

Sangwhan: telemetry should be a permission - an origin-level permission..?

Amy: framing it as "TAG finding on deprecation of 3rd party cookies" - express suppport for deprecation and then concern for preserving the bad parts of current status quo... and also champion work to preserve non-tracking use cases like single sign on etc

Dan: can we close this based on the fact that they've updated their explainer?

Sangwhan: I'm Ok - they will haev to figure out how to actually implement this... What I triued to flag here is that there are a bunch of reasons why bfcache cannot kick in - this allows develoeprs to tap into that info so they can correct their mistakes. This is info the devs will be able to get access to - if they look at debug logs. Not particularly risky - but what might be risky is if you have extensions that disable bfcache as a side-effect then that info might leak - about which extensions the user has installed.. Their updated explainer addresses this concern. I'd be OK closing this one.

Dan: In privacy TF - talking about telemetry... we might want to mention that.

Sangwhan: I thought there might be privacy issues but I don't think so - if you exclude the extensions discussion. I think info this particularly exposes is not risky.

Dan: 👍

Sangwhan to close with resolution satisfied