Should explicitly maintain way to fake cookie behavior

[joelweinberger]

Some developers explicitly fake document.cookie behavior, for example in iframe sandboxes, such that their code can remain blissfully unaware that they do not have direct access to cookies. For example, they may set getters and setters for document.cookie to then postMessage to another context that has actual cookie access. This is notably even possible for cookie-averse documents.

It seems that, which this API, this type of faking should still be possible, but I'd love to see it as an explicit goal.

[annevk]

How would it impact the API?

[joelweinberger]

I'm not sure that it would; I just wanted to make it explicit that it should be a goal to allow this to continue. Talking @bsittler offline, it sounds like in the immediate future, he's building a polyfill for the API, so that, by definition, would mean it can be faked, and that's great!

I guess I'm requesting a note once the spec is written up that this is a goal of the API?

[annevk]

It seems like a weird goal to have. Once the API is in place, writing a shim that proxies to it will always be possible somehow.

[domenic]

Yeah, I agree this should not constrain the design space, and definitely should not be something included in the spec.

[bsittler]

This API is currently designed:

• using Promises ⇔ async functions,
• using neither opaque nor nontransferable data types,
• with no thread-blocking operations,
• with no strong transactional guarantees,
• with no guarantees of predictable realtime performance,
• with no explicit object sealing or other API-level tamper-resistance,
• with no custom getters/setters,
• with no explicit timing guarantees about when exactly changes made through this API will take effect and
• with no explicit coherency guarantees about read operations in the presence of overlapping reads or writes.

I believe that so long as these continue to hold, a polyfill, replacement or shim using postMessage and exposing a CookieStore across execution contexts (e.g. to a sandboxed IFRAME) will be possible without great effort.

I also believe that most of this API's behavior should be implementable as a polyfill atop document.cookie for document contexts where that API already exists. There are limits to this, though: some document.cookie operations silently fail in ways not currently easily detectable or predictable by scripts and so a native implementation of the async cookies API would reject the operation but a document.cookie-based polyfill would incorrectly treat the operation as resolved instead. Also, any document.cookie-based polyfill introduces blocking pauses in the script context's event loop - this is generally undesirable for performance reasons and is one of the motivations for the new API.

[bsittler]

I think I like the idea of at least mentioning this in the explainer as it has come up in several different discussions of the proposed API so far. Please take a look at https://github.com/bsittler/async-cookies-api/pull/23 if you are interested in the wording, and also mention here or on the pull request any reasons this is a horrible idea and/or not worth the bytes consumed by the explanation ;)

[domenic]

As I said earlier, I don't believe this should constrain the design space or be mentioned in this repo. I am especially against requiring that this be polyfill able on top of document.cookie. so put me in the "horrible idea" camp.

[bsittler]

I believe the proposed wording does not make polyfill-ability a goal or requirement, it merely points out that it is possible (and why) and also explains that some fidelity is lost if the polyfill is atop document.cookie

On Aug 3, 2016 17:32, "Domenic Denicola" notifications@github.com wrote:

As I said earlier, I don't believe this should constrain the design space or be mentioned in this repo. I am especially against requiring that this be polyfill able on top of document.cookie. so put me in the "horrible idea" camp.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/bsittler/async-cookies-api/issues/22#issuecomment-237416706, or mute the thread https://github.com/notifications/unsubscribe-auth/AAD3R9cYxdctksi5t_Yy7ML_b8vKdkc1ks5qcTMagaJpZM4JX2W0 .

[annevk]

None of that is really the material for a standard though. (Explaining the differences with respect to some other API is, but not in terms of a polyfill.)

[bsittler]

I view the lack of fidelity in a polyfill as another argument for adding a native implementation of this API rather than leaving it as a higher-level capability app developers/authors would be expected to implement themselves in terms of existing primitives.

On Thu, Aug 4, 2016, 00:02 Anne van Kesteren notifications@github.com wrote:

None of that is really the material for a standard though. (Explaining the differences with respect to some other API is, but not in terms of a polyfill.)

— You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub https://github.com/bsittler/async-cookies-api/issues/22#issuecomment-237469774, or mute the thread https://github.com/notifications/unsubscribe-auth/AAD3RzpUBUvGr2S6DGFLqH_NRTUStuesks5qcY5lgaJpZM4JX2W0 .

[bsittler]

Rewrote discussion of this non-goal in https://github.com/bsittler/async-cookies-api/pull/23 - please take a look and let me know what you think.

[bsittler]

I'll go ahead and merge the new language in its current form given the absence of further comments, but I'm happy to modify the explainer further if you have changes you would like to see.

[bsittler]

Please re-open if the current explainer wording is not satisfactory