Comment 41 for bug 44062

Go forth and blacklist, there's probably a reasonable enough set we can agree
are invalid. I despair at the Japanese list, though, and quake in fear something
like it catches on world-wide. Does any browser, except maybe Opera with their
DNS check, support the japanese exclusions correctly?

But what are the perf and footprint hits?

In the long run, though, it would be better to provide tools to let sites look
after themselves. No matter where we draw the line you're always going to be
able to find a case where A.legit can cause mischief for B.legit's cookies, but
other X .legit and Y.legit do purposefully share cookies.

my associative array idea might not fly, it's legit to have two cookies of the
same name set at different domains and/or paths. Order is important, too, so a
site can grab the one set at the closest level. On the other hand, every case I
can think of wants only the one we present first, maybe we'd get thanks for
simplifying the process :-). Might have to go with a plain array where .name is
one of the object properties. Or as long as the .toString() presents the
current list with duplicates maybe that's good enough and the associative array
works.

If we extend cookie details to document.cookie we should also do something with
cookie headers (like rfc2109?) so server apps can likewise protect themselves.
The proposed syntax is as good as any I suppose, but will easily double the
amount of cookie information being sent down the pipe with each request. Are
"old" servers really likely to handle cookies with the name $domain fine as
asserted in the spec? Seems like that might give grief to perl programs if
misused in just the right ways.