Re: ISSUE-239: Link to compliance document

On Dec 16, 2013, at 11:25 AM, Walter van Holst wrote:
> On 16/12/2013 19:52, Shane M Wiley wrote:
>> Walter,
>> I'm in agreement with MAY and would like to discuss moving to MUST as
>> that may be supportable as well for the reasons you've laid out.
>> Would there be legitimate scenarios where a Server would not be able
>> to reliably put forth a compliance regime pointer?  Other than the
>> typical "mid-implementation" scenarios, the only other one I can
>> think of immediately is for markets where there isn't a local
>> compliance option and existing ones may not translate well to that
>> market due to local laws.  For example, for some APAC markets that
>> have local Privacy Laws but no real self-regulatory compliance
>> mechanism, I'm assuming no response here would be acceptable as long
>> as the Server is operating within the bounds of local law.  Fair?
> If I understand your scenarios correctly we're talking about:
> a) mid-implementation, which means that the Server probably doesn't even
> fully know itself how compliant it is at the time of the network
> interaction;
> b) jurisdictions that do not allow for self-regulation but do not have a
> governmental compliance spec available either;
> In scenario a) the logical thing would be to either point to a
> compliance spec that explains that this is mid-implementation and that
> the user cannot expect a different result than with sending DNT:0.

That was my original suggestion as well, but note that the spec still
has a "!" TSV dedicated to being under construction.

> In scenario b) for some reason the Server has reason to believe it
> cannot be fully compliant to local law (which may not even apply to the
> Server, but that is a different matter) and such a scenario should be
> covered in either the compliance spec the URI is pointing to or the
> Server should use a different compliance spec for requests from that
> jurisdiction which again explains that there is no full compliance to
> local laws and why there isn't. I think no response should be sufficient
> in this regard as well, because then the user should be aware that DNT
> is treated in a way that he or she should not have much expectations of.

There are basically three alternatives for what no compliance links
could mean:

  1) the origin server complies to some specific revision of some
     default compliance regime, such as a future W3C specification;

  2) the origin server doesn't claim compliance to anything more
     than providing informational links in the protocol; or,

  3) the origin server's compliance is defined by the policy link,
     which might or might not be unique to that server.

IME, (1) always fails, because even if we had a W3C compliance spec
as a full Rec, it would need updating on a irregular basis, and nobody
in their right mind would claim compliance to either an obsolete spec
or a moving target.  In any case, the bytes saved by having a default
reference is hardly worth the time spent trying to mint a permanent
URI to something that doesn't exist yet.

I don't think we can say that lack of a link means that the site claims
to comply with local laws and regs.  In practice, it is impossible for
a website to do so even when they want to -- there are just too many
localities out there.  What they can do is address lack of compliance
when it is reported, and adhere to regimes that are most likely to
cover all jurisdictional requirements.

The other alternative, that we make the array a MUST for the protocol
so that the representation is invalid if the array isn't present,
doesn't actually provide a useful service to clients.  I know it is
tempting to think that a MUST would mean the server has to comply with
something, but the mere presence of links cannot do that; MUST would
just mean such a server would refer to any empty resource, or more
likely to their own unique privacy policy.

For that reason, I suggest we go with (3) and simply state that the
policy link applies if no links are provided in compliance.
A verifying user agent would be expected to flag that as unlikely
to meet the user's preferences.

> The beauty of Roy's proposal is that it allows for extreme flexibility
> both in the applicable specs, the way Servers treat different network
> interactions and during roll-out of the implementation. At some point
> you can replace the text where the URI is pointing to with a different
> text (I would recommend putting in a timestamp) and with a flip of the
> switch you can go from not really honouring DNT to honouring DNT
> according to a spec you wish to comply to.

Note that the timestamp issues are already specified in the spec via
the tracking status representation's cache requirements.

I do not expect the compliance text to matter as much as the authority.
In other words, I expect that anyone wishing to verify compliance
will have configured a whitelist of acceptable compliance links,
and over time that list will get shorter as folks come to a common
agreement on expected behavior, whether that agreement is
forged by standards, consortia, new regulations, or user demand.

I think the usual market effects will lead to a very small number
of acceptable compliance regimes (if not one, then no more than four)
for the simple reason that creating unique compliance claims will
attract the interest of advocates and regulators.

If that convergence doesn't happen, it won't be because of an
array in the protocol.  The array only gives us the flexibility to
communicate any of the potential outcomes of future work.

> The only downside to this scenario that I can see is that there may
> arise disputes to what compliance spec applied to which network
> interaction, so it probably would be better to include non-normative
> text explaining that it would be recommended to use a URI which is
> descriptive in itself and/or points to a trusted third party that
> performs the role of compliance spec server. And even then we may be
> overengineering things already.

Likewise, that is why there are specific cache-control requirements
for the response -- so that they are defined as applicable to some
current and future window of time and not to any single request.
Such promises could even be monitored by third parties provided
to user agents via other interfaces (e.g., lists or queries).

The current text is the minimum for enabling the communication.
More explanation would be necessary in use cases for verification.
For example, the spec would eventually need to say that the links
are for "cool URIs" that do not change semantics over time, and are
not intended for automated retrieval or dynamic evaluation of a
their representations.


Received on Wednesday, 18 December 2013 00:35:02 UTC