WAC 2.0 and POWDER

Update

A new version of the WAC specification was published on . Disappointingly for me I received no feedback from anyone connected with this spec, despite my replying directly to Bryan Sullivan, and I see that the new spec contains all the same errors as the previous version. I will make new efforts to contact Bryan and others in WAC.

Meanwhile I've been looking at the section on Privacy Considerations for API Usage which has further examples of POWDER usage. This is really good and the example is much more conformant with the spec (no xml attributes on the descriptions). One of the things that section talks about is including multiple IRI sets in a DR. And then it gives an example that includes this:

<dr>
  <!--accelerometer data is sent to the network to domain example.com-->
  <iriset>
    <includeresources>http://wacapps.net/api/accelerometer</includeresources>
  </iriset>
  <iriset>
    <includeresources>example.com/myapp</includeresources>
  </iriset>
  <descriptorset>
    <wac:nt>1</wac:nt>
  </descriptorset>
</dr>

The main problem here is, as I noted in my original comments, that the absence of http:// at the beginning of example.com/myapp is not correct since the includeResources element takes a white space separated list of absolute IRIs. We can not only correct that but we can also simplify the markup by putting both the IRIs in the one element thus:

<dr>
  <!--accelerometer data is sent to the network to domain example.com-->
  <iriset>
    <includeresources>http://wacapps.net/api/accelerometer http://example.com/myapp</includeresources>
  </iriset>
  <descriptorset>
    <wac:nt>1</wac:nt>
  </descriptorset>
</dr>

In other words, there's no need to define multiple IRI sets here, it can be a single IRI set that includes exactly two resources.

WAC stylised lettering for logo W3C POWDER logo

I've been aware for a while that WAC has been planning to use POWDER in its new specification, obviously something I'm happy to hear about. The editor of the core specification, AT&T's Bryan Sullivan (who I've met before through W3C Mobile Web Best Practices work) contacted me to seek my input on how they're planning to use POWDER.

I replied to Bryan by e-mail but I'm not a member of the relevant mailing list and I'm not sure if there is a public archive so here's the bulk of the exchange, if only so I'm able to find it again!

On 25/02/2011 06:43, SULLIVAN, BRYAN L (ATTSI) wrote: 
[..]
> We have intended to make Security and Privacy a key differentiator for
> WAC (like we did with OMTP in BONDI
> <http://bondi.omtp.org/1.1/apis/bondi.html>  ) since the beginning of the
> project. Looking at the POWDER work you led, we decided it was the best
> framework in which to fulfill our modest objectives for in WAC 2.0 for
> content categorization and API/network usage disclosure for privacy
> protection purposes. We really are only using a small fraction of the
> spec, and I hope we are using that correctly. You can see what we have
> defined at http://specs.wacapps.net/wac2_0/feb2011/index.html in the
> Widget Security and Privacy
> <http://specs.wacapps.net/wac2_0/feb2011/core/widget-security-privacy.html>  chapter sections:
>
> 3.7. Description Resources
> <http://specs.wacapps.net/wac2_0/feb2011/core/widget-security-privacy.html#toc-security-description-resources>

Reading through the doc I offer the following observations and comments (feel free to pass these on publicly if you feel it appropriate).

Although POWDER documents are written in XML, and can be processed as XML, the underlying aim of the protocol is to make it easy to generate RDF triples at run time (so you can describe all the resources whose URIs match a set of criteria in one go). In the WAC case, that's not what you're doing - you're associating a bunch of descriptors with a single specific resource. In the example given, you provide descriptors for wrtcompliance.wacapps.net/WAC2_SP2691.wgt

That's a relative URI which may or may not be what you mean, but if you ask a POWDER processor to describe wrtcompliance.wacapps.net/WAC2_SP2691.wgt (i.e. give that as the Candidate Resource) it will assume you mean http://wrtcompliance.wacapps.net/WAC2_SP2691.wgt and try and describe that. The processor I wrote [1] does that but does not prepend values for the <includeresources> element. As a consequence, it returns a "not known" response since there is no exact match.

I would argue, from the spec, that this is the correct behaviour but Andrea Perego's Powder Processor [2] does add http:// to both the candidate URI and the value of <includeresources> and so does find a match (I put a copy of your example POWDER doc at [3] to test all this - please note that I corrected the POWDER namespace by adding '#'). What it returns is XML in the RDF namespace but it's not valid RDF/XML as you've used attributes to carry the context information. Again, perfectly valid XML, but not valid RDF/XML.

Now, I recognise, of course, that this may not matter to WAC. I'm probably going on about semantics and triples in an environment where such things are seen as irrelevant, but I would argue that WAC needs to either:

  1. note in the spec that the usage of POWDER is not conformant;
  2. or

  3. I could offer a conformant treatment of the same example? Let me know if you'd like me to do this, but, just quickly it would end up more like:
<descriptorset>
  <displayicon src="http://wacapps.net/icon.png"/>
  <wac:aa rdf:resource="http://wacapps.net/vocab#age6" />
  <wac:nu rdf:resource="http://wacapps.net/vocab#level1" />
  <wac:nuContext rdf:resource="http://wacapps.net/vocab#xa" />
  …
</descriptorset>

The xa attribute is specifically associated with nudity via the nuContext property. This is still valid XML and can be processed as such, but it is also valid RDF.

This has a strong advantage, not just for the RDF heads, but because it makes the use extensible and flexible. As it stands, you have a separate spec that requires the use of a prescribed list of elements and attributes. A conformant use of POWDER allows the use exactly as you wish as well as other uses that may go beyond child protection, privacy etc.

>
> 3.8.1 Privacy Considerations for API Usage
> <http://specs.wacapps.net/wac2_0/feb2011/core/widget-security-privacy.html#toc-security-privacy-api>

A quick glance at this suggests the same issues apply.

I guess it comes down to whether you want to, as you say, define a POWDER extension (one that breaks the spec) or define a descriptive vocabulary for safety and security that can be used within the spec.

>
> This spec is now in a public review period. I am not sure if we have
> fully considered the lessons in the ICRAfail paper, but I think in WAC
> we are paralleling some of the things you had planned for ICRA as
> solutions to the problems it encountered, e.g.:
>
> 1)  WAC will host the description resource documents for WAC-distributed
> applications. We do not expect Web servers to do anything.

Good.

>
> 2)  The description resource documents will be validated through app
> testing during the ingestion process.

Good.

>
> 3)  Where possible, generation and update (as needed) of the description
> resource documents will be automated through developer tools and tools
> used by the WAC developer warehouse platform.

Good.

>
> 4)  The Web user-agents (initially widget engines, but in upcoming
> releases also browsers) have specific requirements on what they must
> present (but not specifically how) to the user, and obtaining consent
> per the disclosures.

So you have the whole thing from data generation to user agent. Again, good. What worries me is the lack of flexibility. POWDER is a generic platform for carrying descriptions of any kind. It is not, indeed we went out of our way to emphasise that it is not, a privacy, safety, keep the bad stuff from the kids platform - although it can certainly be used for that.

One of the problems that PICS faced was that it was seen as a one-use technology - and a technology whose single aim could be achieved by other means. Suppose someone doesn't provide the metadata or a user agent doesn't implement the POWDER side of things? OK, the implementation will not be conformant with WAC, but how important is that going to be? Really, does it matter enough for people to want to implement this?

If the provision of metadata can provide good information that makes it easy to discover the widget and what it can do as well as the privacy and safety stuff, so much the better. If you can build tools that mix the RDF coming from the POWDER description of a widget with other data, that might provide more exposure for the widget?

RDF and POWDER allow anyone to say anything about anything. That's important. By locking a vocabulary into a technology that has been so constrained as to make it non-conformant (essentially treating POWDER purely as XML), you're in danger not only of repeating the ICRA/PICS scenario but also P3P.

I want to update the ICRAfail doc and improve it but essentially, the question people asked about labelling was 'why bother?' They need a positive answer to that.

Finally, can I suggest one addition to your descriptive vocabulary. You need something that covers the idea that "although this widget does not contain any measurable sex, nudity, violence etc. it is intended for an adult audience." This was included in the final ICRA vocabulary that was published but never implemented following use cases such as a Web site that discussed the works of Jane Austen and sometimes decoded Austen's euphemisms for the 'shocking behaviour most unbecoming of a lady" etc. Also, there was a Web site for Manchester sex workers, not a porn site, but a site where sex workers could find useful info. You need some sort of cover-all term. Film classifiers sometimes talk about 'adult themes' for this. Well, some research by the British Board of Film Classification showed that many teenagers thought 'adult themes' meant things like paying your mortgage or doing the ironing, i.e. 'being an adult!'

>
>
> We know this is only a start, but we want to keep it as simple as
> possible for now, and if it suffices, we will keep it that simple.

Simplicity is always good, yes. And I'm not arguing that WAC needs a full implementation of POWDER. It clearly doesn't. But I do think that with minor modifications the simplicity can be retained without losing flexibility.

[1] http://kwz.me/kE
[2] http://dawsec.dicom.uninsubria.it/andrea/ppp/#sec-demonstrator
[3] http://philarcher.org/powder_examples/wac_3_7.xml

If there's a publicly archived version of this, I'd like to link to it. Also, I'll publish any comments received on this.