Re: ISSUE-239: Link to compliance document

Hi Roy,


There is a 4th alternative:
4. - Absence of a link may mean that no compliance claims are made 
(beyond the signals of a TPE).

E.g. a sign may provide transparency by claiming  "T" for tracking (and 
maybe more info at the well-known resource) without any compliance link. 
I.e. the site says "I am tracking you" (always) and the site (by not 
including a compliance link) does not make any more detailed claims what 
this may mean.

Or did I misunderstand something?

Regards,
matthias

Am 18.12.2013 01:34, schrieb Roy T. Fielding:
> 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.
>
> ....Roy
>
>

Received on Wednesday, 18 December 2013 09:21:41 UTC