Explicitly require cookies?

[mavgit]

From @bbcrddave on November 24, 2016 14:53

The HTML5.1 spec requires that cookies are supported only if HTTP is implemented, but HTTP is not mandatory in HTML5.1. Do we need to mandate HTTP somewhere in our spec, or should we explicitly require cookie support?

Further, it seems sensible for us to specify, at least informatively, some guidelines for minimum number of cookies per domain and total, and a minimum size per cookie. For example, OIPF [1] suggests at least 20 per domain, 100 total and 4096 bytes per cookie. Is this the kind of thing we expect to specify?

[1] http://www.oipf.tv/docs/OIPF-T1-R2-Specification-Volume5a-Web-Standards-TV-Profile-v2_3-2014-01-24.pdf Section 9.

Copied from original issue: w3c/webmediaapi#9

[mavgit]

@bbcrddave A couple of questions:

1. Since many browsers have an option for users to turn off all cookies, it seems applications have to work without cookies. If so, how does the mandate help applications?

OIPF [1] suggests at least 20 per domain, 100 total and 4096 bytes per cookie.

2. This seems reasonable. Does anyone know whether current web devices, particularly TVs and other non-PCs, support the OIPF cookie level?

[mavgit]

From @jpiesing on December 14, 2016 7:7

@mavgit

Since many browsers have an option for users to turn off all cookies, it seems applications have to work without cookies. If so, how does the mandate help applications?

Alternatively applications assume that only a tiny proportion of users turn off cookies and give a worse user experience for those users.

OIPF [1] suggests at least 20 per domain, 100 total and 4096 bytes per cookie. This seems reasonable. Does anyone know whether current web devices, particularly TVs and other non-PCs, support the OIPF cookie level?

This level should be comfortably (significantly?) exceeded on all devices. It's a minimum level to enable (certification) tests to be written and not challenged.

[mavgit]

@jpiesing said:

This level should be comfortably (significantly?) exceeded on all devices.

My instinct is that this is true. I call for any device makers to speak up if this is not a reasonable requirement. If no complaints, I support adding this requirement.

[mavgit]

Call for consensus: Add the following requirement for cookies:

At least 20 cookies per domain, 100 total and 4096 bytes per cookie

Please comment if you disagree. Silence is taken as consent. We'll apply changes after the upcoming F2F.

[mavgit]

From @tidoust on December 15, 2016 9:38

I note that this is different in nature from referencing specifications. This sets additional parameters, which is something that specs tend to avoid, usually because it is hard to agree on such parameters, even to define limits. For instance, Web Storage sticks to informative prose when it says "A mostly arbitrary limit of five megabytes per origin is suggested. Implementation feedback is welcome and will be used to update this suggestion in the future" (see Disk space section).

I think the spec should be clear in its abstract/introduction that it also sets such parameters when needed.

[mavgit]

From @jpiesing on December 15, 2016 9:54

@tidoust Additional parameters are something that many web video app providers have felt it necessary to specify in their requirements towards device manufacturers. A list I compiled previously can be found here https://github.com/cta-wave/HTML5-api-task-force/issues/1

@mavgit and I had previously debated whether such additional parameters would belong in the web media API specification or a separate document.

[mavgit]

After looking into RFC 6265 in more detail, I am now concerned that parameters in the Web Media APIs spec will redefine the semantics of the referenced specs.

RFC 6265:

6. Implementation Considerations

6.1. Limits

Practical user agent implementations have limits on the number and size of cookies that they can store. General-use user agents SHOULD provide each of the following minimum capabilities:

o At least 4096 bytes per cookie (as measured by the sum of the length of the cookie's name, value, and attributes). o At least 50 cookies per domain. o At least 3000 cookies total.

Servers SHOULD use as few and as small cookies as possible to avoid reaching these implementation limits and to minimize network bandwidth due to the Cookie header being included in every request.

Servers SHOULD gracefully degrade if the user agent fails to return one or more cookies in the Cookie header because the user agent might evict any cookie at any time on orders from the user.

Looking at this, I don't agree we should add the proposed parameters: a. The RFC has a SHOULD requirement for cookies already, and b. The RFC cookie minimum requirements are different than the OIPF minimum requirements above.

I don't think WAVE should be redefining the RFC's section 6.1 minimum requirements with a competing spec, essentially creating a branch from RFC 6265.

I do think WAVE can define cookie tests against the RFC.

[mavgit]

From @poolec on December 16, 2016 0:18

We need requirements that we can rely on and which can be tested. That means that we need some SHALL statements in WAVE.

I'd be happy to align with the RFC by either:

• mandating storage that is consistent with the RFC "SHOULD"s
• mandating a lower level of storage whilst simultaneously saying that the device SHOULD support the higher levels mentioned in the RFC

I would not be happy with only a recommendation.

Storage is such a crucial feature for making player applications work correctly for the user that it is not something we can leave to chance.

[mavgit]

From @poolec on December 16, 2016 2:33

Discussion 15/12/2016: Some concerns about changing a spec by making a SHOULD a SHALL, or pushing beyond what is common practice on desktop. But it is believed that desktop browsers go beyond the recommendations of the RFC. Overall goal is to bring CE devices into the modern web. Next steps: look at minimum supported on the desktop browsers and write a requirement that lies within those.

[mavgit]

From @irajs on December 16, 2016 2:37

See http://browsercookielimits.squawky.net/ for various browsers' limitations.

[mavgit]

From @bbcrddave on January 25, 2017 17:15

Discussion 25/01/17: There was consensus that we should mandate some minimum limit for cookie support, and that the RFC limits seem broadly sensible in order.

Since it is CE devices thought to be lacking in this areas, feedback was requested from TV manufacturers as to whether these limits are reasonable. It was mentioned by one manufacturer that the amount of effort required to get feedback on specific items from engineering teams was significant and this would be just one of many questions around limits, so we should make a proposal.

Next steps: write a requirement mandating at least the limits set by the RFC.

[mavgit]

From @wfoote on February 2, 2017 0:51

Thinking about this further, I now believe the ideas discussed on 01/25 were going to far, in the case of a vertical market.

The RFC was more or less intended for a horizontal market. A browser on a computer with hundreds of GB of hard disk space certainly /should/ have at least 12MB (and probably much more), in order to be able to accommodate 3000 cookies spread across multiple domains. The same doesn't apply for a given browser installation on a CE device supporting a vertical market, where the set of expected domains is very much smaller.

It should be possible to build a WAVE environment that supports a single service, in a vertically-integrated manner. Indeed, a CE device might have multiple such WAVE environments, each firewalled from the others. There are good reasons to consider such separate WAVE environments as a preferred implementation, because it makes for more robust security.

If we were to require that all WAVE environments shall support [enough storage for] 3000 cookies spread across N [a large number] of domains, we make that form of firewalled, vertically-integrated environment more onerous to develop, without good reason.

Perhaps a reasonable way forward is to adopt the RFC limits for a horizontal product, but allow a more reasonable limit for a WAVE environment used in a vertically-integrated service. For example, the limit could be per service. Just to pick a number, I'd think that ten distinct domains would be more than enough for a single service. No strong opinion on the number of cookies per domain, but it wouldn't be in the hundreds.

[mavgit]

From @bbcrddave on February 8, 2017 16:56

08/02: More discussion: there is still feeling that we should not fork the web, and perhaps we should go back to referenced specs and try to change them rather than changing limits in our spec. Other suggested that content providers will be looking for minimum requirements, since some devices will choose not to satisfy those without a MUST statement, and we want to provide a consistent, modern environment for developers.

This formed part of a wider conversation around minimum device capabilities.

Next steps: input requested from the wider CG membership.

[mavgit]

From @boyofgreen on February 8, 2017 17:14

@bbcrddave I think you had a good point about needing to make it a requirement for cookies to work with an app. My perspective is that we should (as mentioned above) require x amount of space to be set up for app data storage suitable for cookies, indexedDB and local storage. Make the requirement on the amount of space they set up, not on the number of cookies that can be supported. Would this work for your bbc type of app? In actuality, I wouldn't see this as belonging in the spec as much as in the implementers guidance portion.

[mavgit]

From @jpiesing on February 8, 2017 17:17

@boyofgreen implementation guidance will be ignored by some unless the words "shall" or "must" appear in which case IMHO it isn't implementation guidance any more. It is also generally not testable.

[mavgit]

From @bbcrddave on March 17, 2017 11:34

It seems we are unable to get consensus on requiring what is recommended in the RFC but there does seem to be consensus for some minimum requirement.

Would people find the OIPF recommendation mention in https://github.com/w3c/webmediaapi/issues/9#issue-191539033 acceptable?

As a reminder, this is 20 per domain, 100 total and 4096 bytes per cookie.

[mavgit]

From @bbcrddave on June 14, 2017 13:23

Since, cookies are explicitly required in HTML5 (see https://github.com/w3c/webmediaapi/issues/10#issuecomment-266959675), the minimum requirement probably belongs in the porting document.

This can be transferred to that repository along with other, and the discussion continued there.