[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [DNSOP] Public Suffix List
Gervase,
The Dan Jay (and later) cookie policy drafts had a dsig in the payload
so that the data collection policy (DCP) asserted in a cookie could be
verified. The xml dsig draft wasn't ready, so we took off that part of
the payload, leaving only the DCP. At the W3C P3P Spec WG meeting in San
Jose a _large_ vendor agreed to implement what had been protoyped in
Mozilla, replacing a no-3rd-party-cookies policy (there's reasonable
policy claims on both sides of that) with parse-the-policy-user-decide
policy (again, there's reasonable ...).
It's not unreasonable to revisit how we know an assertion about a DCP is
true, or provably false, as xml dsig is now mature.
Turning to the list it self, I'm working on proposals (to ICANN) for new
generic TLDs with string lengths greater than four bytes, and the latest
estimate (by ICANN staff) is that they anticipate between 300 and 600
applications in 2009, zero or more of which may be operationalized in
2010. Additionally, a subset of the existing iso3166 code-point
associated registries may elect to apply to add non-ASCII (well,
technically, ACE junk) labels to the root.
My point here is that two of the safe assumptions (byte count < mumble &
( sizeof(rootzone) & compositionof(rootzone) ) are quasi-static) has a
two-year or less shelf-life remaining.
It isn't unreasonable to expect registry operators under contract (to
ICANN) to publish SLD data directly, so you (and others) don't have to
wikipedia (not that wikipedia isn't generally a better source of data),
and you'd probably want that in machine readable form, with an update
mechanism, and it might be useful if that request got incorporated into
the process I mentioned above before it "goes live".
The PROVREG WG added a DCP into EPP, however, the intended scope was
simply to announce the DCP of registry operators to registrars, who may
then communicate the registry's DCP, and their own, towards the eventual
registrant. We didn't provide a mechanism for registrants to announce
the DCPs that they would be implementing from the resources they
obtained by registering domains, or a mechanism for registries to
announce DCPs scoped to a particular namespace.
FYI, the elephant in the room for P3P is we didn't provide a means to
assert linkage to data collected by other means, so data collectors
don't have a means to announce if they do, or don't, link cookie data
with credit-report data obtained by other means.
We did, over the objections of one of the major deterministic personal
profile vendors, now owned by a _large_ search engine operator, make
linked data disclosure manditory through the include/exclude statements.
Eric
Gervase Markham wrote:
> Dear HTTP and DNS Operations WGs,
>
> The following email message will shortly be sent to the technical
> contact for all TLDs. Yngve Pettersen at Opera suggested that I also let
> you both know about it.
>
> The technology in question, including a version of the list, is about to
> ship in Firefox 3, but we'd like to verify and improve the quality of
> the underlying data.
>
> Please let me know if you see any way I can improve the email, the
> explanatory website, or the submission process.
>
> Gerv
>
> <snip>
> Dear Technical Contact,
>
> The Mozilla Project (http://www.mozilla.org/), responsible for the
> Firefox web browser, requests your help.
>
> We are maintaining a list of all "Public Suffixes". A Public Suffix is a
> domain label under which internet users can directly register domains.
> Examples of Public Suffixes are ".net", ".org.uk" and ".pvt.k12.ca.us".
> In other words, the list is an encoding of the "structure" of each
> top-level domain, so a TLD may contain many Public Suffixes. This
> information is used by web browsers for several purposes - for example,
> to make sure they have secure cookie-setting policies. For more details,
> see http://publicsuffix.org/learn/.
>
> We would like your help to make sure, now and in the future, that the
> entries for your TLD(s) are correct. It is in your interest as a
> registry to make sure that this is so. Any errors may either cause your
> customers (domain owners in your TLD) to not be able to set cookies when
> they should, or cause cookie information to be leaked between two
> domains without a trust relationship. Neither of these things is desirable.
>
> Therefore, we are writing to ask your technical team to view the current
> list and, if it is incorrect, to submit updated data. A description of
> the format of the list, and details for sending updates is at:
>
> http://publicsuffix.org/submit/
>
> We also ask you to send updated information whenever you change your
> registration policies in a way which affects the list.
>
> Thanking you in advance,
>
> Gervase Markham
> _______________________________________________
> DNSOP mailing list
> DNSOP at ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>
>
>
_______________________________________________
DNSOP mailing list
DNSOP at ietf.org
https://www.ietf.org/mailman/listinfo/dnsop