Re: Privacy HR requested for JSON-LD 1.1 Syntax, API and Framing

Hi Robert,

Thank you for the clarifications, I’m grateful for you taking the time.

The situation seems unique. I’m not aware of many other examples of W3C specs defining interfaces / APIs that are not intended to be implemented by vendors, or even quite what the role of such a standard would be in this context.  My understanding of Web IDL is that  [“define(s) interfaces for Web APIs”][1], and so I’m kinda lost how to evaluate a web standard API that’s not meant to be implemented by web browsers.

I don’t mean that as any kind of criticism, just that I’m unfamiliar with this situation and how to evaluate it.  Can others on PING share their experience / understanding?

Independent of the above concern though, if the API is explicitly _not_ designed to be implemented by browsers, and is supposed to be operating on data describing the relationship between data, and not between the browser’s current user, it would be good to specify that requests initiated through the API _must not_ have any user describing state (referer, cookies, origin, etc).  Would there be any conflict / problem / loss in doing so?

Refs
---
1: https://heycam.github.io/webidl/

Pete Snyder
{pes,psnyder}@brave.com
Brave Software
Privacy Researcher

> On Jul 19, 2019, at 2:23 PM, Robert Sanderson <azaroth42@gmail.com> wrote:
> 
> 
> Dear Pete, all,
> 
> Please find below the WG's responses to the questions.  Any errors are certainly mine in the summarization of the discussion.
> 
>  • The API is intended to be used by javascript applications running in the browser only, rather than by the browser itself. It provides structured data to the application to process and act upon, rather than performing any function or service. There isn't a model for how a data block in a web page interacts with the HTML or DOM, nor are we chartered to work on this.
> 
>  • The endpoints are only interacted with via Fetch, XHR or similar existing browser-side APIs available to page-level javascript. Thus the information sent to the endpoint is exactly the same as for any API available via HTTP. For the document loader, the expectation is that the code will perform an HTTP GET request for the document. We only describe the behavior of a conforming product once that document has been retrieved.
> 
>  • As the specification is for use within the application layer, rather than the browser directly, there isn't an intent for browsers to implement this natively. However, it is our understanding that Google have implemented a JSON-LD processor in Lighthouse (https://developers.google.com/web/tools/lighthouse/), which powers the Audits panel of the devtools package in Chrome. There are multiple implementations of the specification outside of browser-space, in multiple languages.
> 
>  • The context URL is simply more JSON data ... or actually meta-data, as it describes how a conforming processor should transform the instance data into the RDF data model. As such, it uses the same methods as above, and as are already implemented by browser, with the existing privacy considerations.
> 
> 
> Hope that helps fill in the gaps!
> 
> Rob
> 
> 
> 
> On Fri, Jul 19, 2019 at 8:55 AM Robert Sanderson <azaroth42@gmail.com> wrote:
> 
> Thanks Pete!
> 
> We'll discuss in our call this morning, and I'll collate the answers.
> 
> Rob
> 
> 
> On Mon, Jul 15, 2019 at 11:17 AM Pete Snyder <psnyder@brave.com> wrote:
> Hi Robert,
> 
> Thanks for reaching out on this.  I the three documents you sent over a couple of close reads, but I still am not clear on a couple of privacy-relevant issues.  I was hoping you could clarify the following issues.  If it’d be better to discuss too, we could also schedule a call with all of PING, but that would have to wait until the next PING call (in ~2.5 weeks) and I imagine you’d like to move faster than that :)
> 
> 1) I don’t see a point where the described API touches the Web API.  How is this intended to be used by applications running in the browser?
> 
> 2) What privacy relevant information is sent with calls to the [documentLoader](https://www.w3.org/TR/json-ld11-api/#dom-jsonldoptions-documentloader) end point?  Cookies or similar?  If so, pulled from what origin (and single or double keyed), etc?  In general more explanation of how this interacts with the browser is needed.
> 
> 3) If this is intended to be implanted in browsers, have any vendors implemented it?  Generally W3C prefers at least two independent implementations of functionality before standardizing / recommending.
> 
> 4) How does the contextUrl interact with other URL / origin specific privacy features in the browser (same origin policy, CORS, etc?)
> 
> Thanks much!
> 
> 
> Pete Snyder
> {pes,psnyder}@brave.com
> Brave Software
> Privacy Researcher
> 
> > On Jun 19, 2019, at 1:11 PM, Robert Sanderson <azaroth42@gmail.com> wrote:
> > 
> > 
> > Dear Privacy folks,
> > 
> > The JSON-LD WG hopes to move to CR about the time of TPAC or shortly thereafter.  Our working drafts are stabilizing but not 100% complete at this time.
> > 
> > We would very much like to schedule a privacy review with you. We would anticipate sending one chair and one editor to the call, likely myself (Rob Sanderson) and Gregg Kellogg.
> > 
> > Our TR-track specs are:
> >   * https://www.w3.org/TR/json-ld11/
> >   * https://www.w3.org/TR/json-ld11-api/ 
> >   * https://www.w3.org/TR/json-ld11-framing/
> > 
> > Many thanks!
> > 
> > Rob
> > 
> > -- 
> > Rob Sanderson
> > Semantic Architect
> > The Getty Trust
> > Los Angeles, CA 90049
> 
> 
> 
> -- 
> Rob Sanderson
> Semantic Architect
> The Getty Trust
> Los Angeles, CA 90049
> 
> 
> -- 
> Rob Sanderson
> Semantic Architect
> The Getty Trust
> Los Angeles, CA 90049

Received on Friday, 19 July 2019 22:21:51 UTC