(In reply to James Willcox (:snorp) (firstname.lastname@example.org) (he/him) from comment #7)
(In reply to :ehsan akhgari from comment #6)
My suggestion for how to handle this is a model like this:
- We change the
getUniqueDomainsVisitedInPast24Hours() API on both desktop/GV to return a promise that resolves to the number of unique domains visited in the past 24 hours.
- On desktop we'll return
result is the number we're returning today.
- On GV, we'll call back into the embedder asking them to calculate this number, and when it's available we'll resolve the promise with that.
- We'll make sure
Document::AutomaticStorageAccessCanBeGranted() is asynchronous in the parent process. It is already asynchronous in the content process so that should be quite easy.
How does this setup sound?
This is the proposal I'm responding to below, in which
getUniqueDomainsVisitedInPast24Hours() is delegated to the app.
As in the GV embedder? That wasn't really what I had in mind when designing the Gecko side of this to be honest. I was thinking (perhaps naively) that GV (and not its embedder) would implement that part.
I think we need to have a high bar for exposing things like this in the public API. If we don't, we'll end up with an utterly massive surface that is hard to both maintain and use. In my opinion, due to the highly specific nature and overall utility of this new API, this doesn't pass the bar. We can use a slightly different heuristic, if necessary. If we end up prompting people more often than desktop I think that is probably acceptable, but there may be some other mitigations we can employ as well.
Public to whom, GV embedders or to Gecko? This paragraph confuses me quite a lot.
By "public", I'm talking about the GeckoView API exposed to applications.
I understand now. I think both of us agree that nothing here (except for the prompting part) should ideally be exposed to the GV embedder.
I definitely didn't intend to suggest
nsIBrowserUsage or anything under the hood from its implementation should be a public GV API.
But you proposed exactly this by delegating the implementation of
getUniqueDomainsVisitedInPast24Hours() to the application. I guess I'm not understanding something correctly.
I did no such thing. :-) I suggested delegating the implementation of
getUniqueDomainsVisitedInPast24Hours() to GeckoView. In comment 1, Chris said that GV doesn't keep browsing history and then closed the bug with the same suggestion that you made again in comment 4 (for Gecko to ask the GV embedder app to figure out whether or not to show a prompt for the storage access API and for the embedder to be responsible for implementing the heuristic, including computing the number of unique domains visited in the past 24 hours, and I reopened the bug because I don't think that is a good solution for the reasons I have stated before.
I am now editing the summary of this bug to clarify without any ambiguity what this bug is talking about. At least on my side, I am not proposing involving the embedder application in the prompting procedure in any way before Gecko decides to prompt. If GV on its own cannot determine "how many domains were visited in the past 24 hours" perhaps we can figure out how to adapt the heuristic for Gecko embedders that do not access to history or something like that.
My goal in designing this was to ensure that the public GV API would only be the prompting API where the prompt would be dealt with very similarly to other prompt that GV shows, so that embedders do not need to care about any of this complexity. The problem mentioned in comment 1 (GV not maintaining history) for example could be alleviated by returning 0 or some such from
getUniqueDomainsVisitedInPast24Hours(). I don't think all of the possibilities here have been enumerated at all...
If GV can get by with implementing a stub
nsIBrowserUsage that can just always return 0 for
getUniqueDomainsVisitedInPast24Hours(), then that's fine with me.
Great, that's probably a fine solution here.
To clarify why this is, the prompting heuristic looks at 1% of the number of the domains visited in the past 24 hours, with a minimum cap of 5 domains, in order to prevent prompts from showing up before a tracker is about to obtain tracking power over a significant portion of the user's cross-site browsing activity (that is, we do not want to allow automatic access grants over 1% of the domains). We have the
dom.storage_access.max_concurrent_auto_grants which establishes the minimum cap here (set to 5 by default) so if we return 0 here the minimum cap would always take effect. That would only become inaccurate if the user has browsed more than 500 top-level eTLD's in the past 24 hours, which should be a very unlikely scenario on mobile anyway.
But reading this I'm fairly convinced that we are probably talking about two (or more?) different things here, and to be honest I'm not really sure which specific idea you're rejecting in the last paragraph, so I'm a bit lost as to where to take this discussion. So far the suggestions here (having different prompting heuristics on mobile, having embedders involved in the prompting heuristics) are all explicit design non-goals as far as I'm concerned.
May I suggest perhaps at some point myself and whoever is going to work on this plus maybe you, Chris and other folks who are needed to get together to discuss this over before settling on really drastic resolutions here?
Yeah I'm happy to talk further about this. Clearly there's some kind of misunderstanding on my end.
I think now we are both on the same page. I'm going to submit a patch based on this discussion now...