Infoset feedback: Privacy policies

[laudrain]

From Feedback from Edge

In 3.2 Infoset requirements:
Privacy policies: Why a web publication would need a privacy policy and not a regular web page (web sites usually have privacy policies, not individual pages)? What if I copy a web publication, do I copy the privacy policy with it?

[laudrain]

A WP is defined as a "collection of resources".
A sigle Web page may be a WP, and that's why WP is really minimal, but it is not the general case.
As a "collection of ressources" with potentially interaction with its reader, a privacy policies as one of these included resources is RECOMMENDED.

[BCWalters]

A WP is a collection of resources, but from a publishing and aggregation point of view, it seems conceptually much closer to a single web page than most web sites. If we look at any journal or newspaper, it seems unlikely that we'd want to have a unique privacy policy for each article. Each page likely has a link to a privacy policy, but one associated with the site, not the article.

Rephrasing the feedback a bit, is there a real need to associate a privacy policy with a WP at the metadata level instead of inside the content like any web page? Even if that's desirable, is it important enough to add complexity to the spec, user agents and the production toolset?

[dauwhe]

Perhaps a link relationship from the entry page is the appropriate method?

[BCWalters]

That's at least conceptually reusable by web pages in general which is a plus. The downside is that it's not exposed by browsers today despite being published in 2013. I don't know the history here, but I suspect that leaving content creators to include explicit visible links in pages was "good enough", so adding a more explicit privacy policy reference didn't catch on. See also P3P.

[laudrain]

Be a link relationship in the entry page or an item in the JSON manifest, it would belong to the infoset.

More globally, it might be expected that a Web Publication will allow more for the reader than a simple sequence of textual html pages. In that case, it will be closer to a Web site than a single Web page.

Nowadays, privacy policies seem to be good practices and IMO should be recommended for WP.

[mattgarrish]

If we look at any journal or newspaper, it seems unlikely that we'd want to have a unique privacy policy for each article. Each page likely has a link to a privacy policy, but one associated with the site, not the article.

All web publications published by an organization could certainly refer to one generic privacy policy that covers them all. The definition doesn't require a unique policy for each one.

But like I've said elsewhere, relying on the user agent to expose important information is generally a bad idea, especially without mandating it be exposed and how. My feeling again is this should be provided on the entry page (i.e., best practice).

[iherman]

Perhaps a link relationship from the entry page is the appropriate method?

You may think I am picking, bu I think that, from a standard point of view this is not really correct. A link and the meta element in an HTML file are metadata of sort that apply on the HTML file itself. It is not meant to express metadata on files "outside" that HTML file. Obviously, syntactically it would be possible, the HTML file would be 'valid', but I think it would not be correct.

[HadrienGardeur]

I fully agree with @iherman, in general all infoset items should be tied to the manifest IMO if they're about the publication rather than a specific resource of the publication.

For the privacy policy this could be expressed as:

• either using a generic link element (that's the RWPM approach)
• or as a dedicated element (that's the WAM approach)

There's also a related issue at #163

[BCWalters]

Let me try one more time...why do we think this needs to be in the infoset at all for a web publication? Privacy policies are super-important, but they haven't become part of a generic object model for web pages. Some might argue that that's bad, but I think that's it's probably a good thing. It let's content creators present those policies in a way that's appropriate for the web page, and it ensures that privacy policies can be treated equally across browsers.

Adding something like this to the infoset has a high overall cost and risk to fragmentation in implementations. User agents need to create some kind of specific UI to get to the privacy policy. If some user agents don't do that (regardless of whether the spec says it's required...implementers of specs aren't perfect), content authors will still need to add links to privacy policies inside of content if necessary. Tools--either authoring tools or conversion tools--may or may not support privacy policies.

Maybe there's something I'm missing here, but I just don't see the benefit of including this outweighing the cost.

[iherman]

@BCWalters I understand what you say. I guess we have a tension that is, I believe, more general than the privacy policy issue: do we want to allow various types of infoset items to appear in the HTML landing page of a WP with a validity for the whole WP, or not (or is that the only allowed place for an infoset item!). Privacy policy is only one example: as a simpler example, one could argue that having the <title> of the WP landing page should be enough and we should not put such element in the infoset.

This approach of course works well if the WP consists of a single HTML page and lots of other, non-HTML files (a typical case for scholarly publishing), and I would be perfectly fine doing it for that case. However, for a WP consisting of several document, I have already expressed my reservations in #181 (comment).

Clearly, my reservations is a matter of spec purity, your approach is based on pragmatism. Both make sense. However, we should not decide on this issue in isolation: it is a matter of general approach for the WG whether we make use of the various meta or link elements in the landing page as encoding of infoset items even in cases when the WP consists of several HTML files.

[iherman]

This issue was discussed in a meeting.

• No actions or resolutions

View the transcript

Infoset feedbacks
Wendy Reid: Infoset feedback : Accessibility compliance information
… We’ve expunged Infoset. So close 178, 179, 180, 181?
… Close 178…181 — all infoset related.
Wendy Reid: #178
Wendy Reid: #179
Wendy Reid: #180
Wendy Reid: #181