StorageAccessTypes members have a rather esoteric design

[annevk]

In particular it's rather unclear why createObjectURL and revokeObjectURL are separated and named after their methods.

It's also unclear why getDirectory is named after its method, rather than its storage type.

It's also not entirely clear to me it's worth restricting access to estimate. It seems that should just work, but only for the storage types you have access to.

[aamuley]

would new StorageAccessTypes storageBucket (replacing getDirectory/estimate) and blobUrlStore (replacing creake/revokeObjectURL) work then? We could adjust the handle to have a `Promise<StorageBucket> storageBucket() method? Open to naming suggestions as well.

@cfredric pointed out the larger reasoning for estimate being included is performance based off of privacycg/storage-access#102 (comment) so it feels worthwhile to keep that as is

[annevk]

getDirectory is the API front for what is known as File System, so fileSystem would seem appropriate, but I'm not actually sure how it's exposed in quota and such today. That might well influence the name we pick.

From the comment you pointed to I can't figure out why estimate has to be opt-in. It's certainly an argument for synchronous APIs, but estimate is not one of those. Could you clarify? Though if @asutherland is willing to weigh in on this issue in general that would also be good.

For blob: URLs I'd go with blobURL or perhaps objectURL as they can also be used for MediaSomething. @mkruisselbrink might also have opinions on this.

[aamuley]

Ahh yeah you are right, I definitely misconstrued another conversation we had. I'll let other folks weigh in about estimate being included

[cfredric]

The point I was trying to make offline was that the reasoning for making sites request individual storage types separately, rather than all of them unconditionally, was performance-related. A site that only needs access to the unpartitioned BroadcastChannel doesn't need to pay the cost of setting up unpartitioned localStorage, e.g.

So, I was arguing that there's no privacy/security reason to say "estimate() should only account for the storages that the site has requested". If there's a performance/convenience reason to design it that way, that's fine; I'll defer to others who know the intended semantics of estimate() better than I do.

[asutherland]

Replying to #41 (comment)

From the comment you pointed to I can't figure out why estimate has to be opt-in. It's certainly an argument for synchronous APIs, but estimate is not one of those. Could you clarify? Though if @asutherland is willing to weigh in on this issue in general that would also be good.

In my previous comments where I suggested LocalStorage and SessionStorage be opt-in in the original proposal issue privacycg/storage-access#102 I really only was proposing that those synchronous APIs be opt-in because they have a lot of significant costs. I strongly feel:

• Only localStorage and sessionStorage should be opt-in.
• All other storage APIs should be automatically present. There should be no need to have them on StorageAccessTypes.
• There should be no all. It feels like this was only added because all the other storage APIs were individually enumerated, but given how burdensome that would be to developers, I would expect they would use all and defeat the purpose of making localStorage and sessionStorage opt-in.

In terms of estimate(), I think we're de-facto exposing the underlying storage bucket and we should be exposing the same numbers you'd get if you used navigator.storage.estimate() from an unpartitioned top-level window, etc.

[johannhof]

@annevk @asutherland we think this would benefit from a sync discussion, would you be able to make it to the next Privacy CG call for that?

[asutherland]

I can join. If someone can provide some pointers to how we went from the minimal input dictionary proposal to the current approach, I'd appreciate it so I can familiarize myself because I have not been following the spec actively, just specific issues like that one where the discussion was happening.

[johannhof]

You mean why we'd like to change the method names, i.e. #31?

[asutherland]

I don't understand how we got to having a dictionary entry in StorageAccessTypes for every method in StorageAccessHandle plus all. I'm sure there's a rationale and I saw in the notes for today's meeting that there was some concern about bike-shedding so I want to make sure I understand the rationale.

In regards to #31 I've commented on the PR at #37 (comment) where I indicated I'm positive on the method name changes.

[johannhof]

cc @arichiv

Ah, sorry, that makes sense.

I believe that the rationale is that there was reasonable feedback that localStorage should be optional and we felt that the most consistent way to do this would be to make everything optional, but Ari might remember this better than me.

I understand your concern in #41 (comment), specifically on all having potentially adverse perfomance outcomes when the developer didn't want to use localStorage. Ari, do you have any thoughts on this, and do you know if we have metrics on usage of SAA parameters?

[arichiv]

If you open https://chromestatus.com/metrics/feature/popularity, filter by name, and search for StorageAccessAPI_requestStorageAccess_BeyondCookies_* it looks like all is the most common, then localStorage, then BroadcastChannel when it comes to rSA args for initialization. When it comes to data accessed after handle return, I assume cookies (not listed) are # 1, then localStorage, then sessionStorage, then BroadcastChannel.

Put another way, of the 0.0115% of page loads that use rSA handle return API 80% use local storage and 65% use session storage. 83% are initializing everything, while 17% are being more specific.

[annevk]

FWIW, the design @asutherland outlines where you only opt-in to the known bad synchronous APIs and get everything else "for free" makes sense to me. I guess it's an open question whether "all" can remain unsupported by other browsers and eventually removed.

[asutherland]

Thanks for the data! I found some additional context at the blink-dev intent to ship and the mozilla standards-position issue on SAA for non-cookie storage. It seems like I missed when the semantics of "all" were further defined; in particular, I think I was most surprised here that all the async or sufficiently async storage APIs were defaulting to false. Also, I don't think I appreciated how long ago Chrome shipped this.

Given the data it seems like sites really like LocalStorage (which isn't a huge surprise) and adoption of "all" is quite high, which makes sense given how StorageAccessTypes is currently defined.

Something we could do that hopefully would be compatible with existing use and reduce the spec complexity and need for changes to StorageAccessTypes going forward as new storage APIs are added is to change StorageAccessTypes to:

dictionary StorageAccessTypes {
  /* all is a convenience enabler for cookies, sessionStorage, and localStorage.
     All other storage APIs on StorageAccessHandle are always exposed
     regardless of this setting. */
  boolean all = false;
  boolean cookies = false;
  boolean sessionStorage = false;
  boolean localStorage = false;
};

all would be defined to cover cookies, sessionStorage, and localStorage, but all other storage APIs on StorageAccessHandle would always be there. StorageAccessHandle would still need updates as new storage APIs are defined, but perhaps that could be somewhat unified with buckets in the future.