On Fri, Sep 7, 2018 at 2:32 PM Tom Ritter <t...@mozilla.com> wrote: > On Fri, Sep 7, 2018 at 12:54 PM, Ehsan Akhgari <ehsan.akhg...@gmail.com> > wrote: > >> In our implementation, once the Storage Access API grants storage >> access, all newly created third-party iframes of the same origin will >> have >> storage access for a period of time (currently defined at 30 days) >> without >> calling requestStorageAccess() again, whereas in WebKit’s >> implementation >> they’d need to reaffirm their access by calling the API again. >> >> ... >> >> In our implementation, we phase out the granted storage access >> permissions after a number of days passed, whereas in WebKit’s >> implementation they phase out the permissions after a number of days of >> browser usage passed. >> > > > These two were confusing to me. AIUI: >
First thing to note, the expiry mechanism is completely independent of when and how we choose to grant storage access, in case it helps clarify things. > The first one is solely about having to call the requestStorageAccess() > API again. It sounds like you're saying we give a 30 day grace window while > safari expires things immediately; but that's not what you mean. It's > solely about whether the javascript code needs to call > requestStorageAccess() (even if it will be granted without a prompt) or if > it doesn't need to call it. > That's right. It's also about the initial navigation of the document having storage access (before the document has a chance to call any JS APIs) which matters for HTTP layer cookies. > In Safari, you have to (even though it won't prompt), but in FF you won't > have to. In your pseudocode, I guess it works either way, but... what was > the reasoning for doing it this way instead of a pure Promise-based > approach? > What do you mean by "this way instead of a pure Promise-based approach"? If you mean why we chose to grant this access when it has previously granted before the page calls the API again, the short answer is for more web compatibility. One thing that I should explain here is that we also have a couple of heuristics that try to detect when the user interacts with a third-party widget in certain ways and grant this storage access automatically. These are designed to catch scenarios such as logins using things like social widgets, commenting widgets and the like. We'd like to treat the storage access permissions the same, no matter whether they've been granted automatically or programmatically through calling this API. The web compatibility are mostly about the former scenario. > In the second one: > Day 0: I do the thing, grant the access > Day 15: I sleep all day and don't use my browser > Day 30: Firefox expires permission > Day 31: Safari expires permission > > It's solely about the difference between counting Day 15 towards 30 days. > Right. I should also add that this isn't something that we particularly like in the current implementation, and may consider improving on it in the future. It's more a by-product of how our permission manager backend works. Cheers, -- Ehsan _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
