<scribe> scribe: larry

<Yves> trackbot, start telcon

<scribe> scribenick: larry

<trackbot> Date: 16 December 2010

approval of minutes?

RESOLUTION: minutes of 2 Dec approved

call on 23 December?

noah: inclination to cancel, go through agenda today & see

IETF/W3C Privacy Workshop

action-506?

<trackbot> ACTION-506 -- Noah Mendelsohn to noah to bring proposed W3C Actions

<trackbot> http://www.w3.org/2001/tag/group/track/actions/506

noah: 2-day workshop, primarily IETF workshop, with help from W3C. Perhaps 35 attendees, wide variety of views.

<noah> * Fingerprinting implications relating to W3C technologies <==== Want user agent to run in non-fingerprintable mode -- TOR guys want this TOR guy would like to collaborate

noah: toward end, create set of actions for IETF and W3C; TAG reps

Larry: Is this a W3C issue, vs. HTTP/IETF issue?

<Yves> fingerprinting is also part of browser behaviour, not only http, but font installed, plugins etc...

Larry: "fingerprinting" would also apply to non-W3C specs, Java, HTML, PDF

Noah: W3C should be proactive in addressing these issues, whether or not they are only W3C specs

peters: there are several examples of this in CSS, list of installed fonts, etc.

noah: referer in HTTP spec

<Yves> fingerprinting is part of the "eternal cookie" discussion

noah: last thing was non-browser user agents

Larry: Just to be clear, i'm not arguing W3C shouldn't work on this stuff, more that W3C might have to increase scope to work on it

<noah> Privacy workshop papers: http://www.iab.org/about/workshops/privacy/Privacy_Workshop_Papers.zip

(discussion of how W3C could address some of these issues)

<Zakim> ht, you wanted to ask how much, if at all, Hal Abelson's perspective was represented

ht: summarizing, "Thinking of privacy as a subbranch of security was the wrong way to think about it -- what you want is accountability"

(discussion of borderline between security or privacy)

<Yves> well, you may want both

noah: this was a major axis of the discussion

<Yves> send not-exact data to protect privacy, and accountabiity on the other side

<jar> TAMI = transparent accountable datamining initiative http://dig.csail.mit.edu/TAMI/

ht: compare "here are some things that are private" vs. "here are parts of my public persona that are usable for what"
... the higher level question of "what do we mean by privacy?" -- doesn't seem to have been on the agenda.

<jar> Weitzner, Abelson, Berners-Lee, Feigenbaum, Hendler, Sussman, Information Accountability

noah: "I need to warn you that when you do certain things that others will be able to do certain things"

(discussion of warning user vs. preventing misuse)

noah: when we get the official list... pick up this discusison next time... decide how to proceed?

<ht> I believe this is now public: http://www.w3.org/2010/policy-ws/slides/09-Abelson-MIT.pdf

Larry: asking Noah's gut feeling: is this just a TAG action item, vs. for others in W3C?

noah: perhaps we should treat it as we treat security

<Zakim> Larry, you wanted to talk about defining "privacy"

noah: surprised there was not implicit consensus about definition of privacy... compared to security, where people have a at least some common ideas of what the problem framework is
... example: let's say the browsers give a list of fonts; some intuition that using order of font names on disk might improve fingerprinting chances, vs. alphabetizing fonts

ashok: what actions might have been taken?

noah: TLR is outside contact for W3C

<noah> ACTION: Dan with Noah to suggest next steps for TAG on privacy [recorded in http://www.w3.org/2010/12/16-tagmem-irc]

<trackbot> Created ACTION-507 - With Noah to suggest next steps for TAG on privacy [on Daniel Appelquist - due 2010-12-23].

<noah> ACTION-507 Due 2011-01-03

<trackbot> ACTION-507 With Noah to suggest next steps for TAG on privacy due date now 2011-01-03

HashInURI

<noah> http://www.w3.org/2001/tag/2010/11/HashInURI

<noah> http://lists.w3.org/Archives/Public/www-tag/2010Dec/0016.html

<Ashok> Comments from Yves and Tim ... I can handle them.

<Ashok> Yves: The Google maps params have several parts with map, zoom, etc.

<Ashok> ... URI is server-side identification

<Zakim> noah, you wanted to respond to Yves on zoom level being identification information

<Ashok> noah: In a map store, didfferent types of maps are different documents

<Ashok> ... google maps is a documenty app ... the URIs identify different maps

<Yves> there are also lots of overlays options, is each display option a new map? I agree that it is the case for scale and type (sat/terrain)

(Larry pastes http://www2.parc.com/istl/projects/www94/mapviewer.html )

<Ashok> Noah: Some AJAX apps identify a document

<Ashok> ... the Google maps URI identify a document

<Zakim> Larry, you wanted to talk about documents, parc map browser, URIs as constructed vs. discovered

<noah> That's Xerox PARC, I presume?

<Ashok> Larry: Every URI in this app did identify a distinct document

<noah> Noah: so what I think is interesting, is this is an AJAX app that feels like a REST app; I can email you the URI for any map document (zoom level, etc.), you deref the link and you barely know it's AJAX, you get what looks the the representation. I think that's very nice.

<noah> LM: There are other design patterns, in which AJAX apps can keep their state in all sorts of non-URI based ways. But, we want the apps to "imitate the old behavior"

<Ashok> Larry: We want apps to imitate the older archaic behaviour ... creating URI that poin to documents

(Larry quotes from '94 paper "Most World-Wide Web information servers provide simple browsing access to collections of static text or hypertext files. This paper describes some interactive World-Wide Web servers that produce information displays and documents dynamically rather than just providing access to static files.")

noah: doesn't break nearly as much as video...
... people send down javascript with URIs, if you ran it in a non-JS environment, it would just do the wrong thing
... there are examples of javascript sites where the fragment identifiers which have no meaning outside of that particular app

Yves: video example, the player is a 'heavy thing', because it is using the fragment identifier to identify video stream & location, maybe there are multiple versions of player

<Ashok> Yves: In CNN case you can cache the player and change the string after the #

<Yves> http://lists.w3.org/Archives/Public/www-tag/2010Nov/0105.html

ashok: (going over other items in email)

<noah> Ashok: Yves raises the case where the HTML contains the same fragment as the client

noah: we need the specs to match recommended practice; we need to say "dont' do that" or get specs changed

<jar> same as rdfa issue, noah.

noah: situation: I do HTTP request, what comes back is text/html. text/html MIME type defines fragment identifier. But these URIs don't work like the spec says they should.

<Yves> I would note that there is a onhashchange event...

Larry: Sounds like this is a bug in the HTML spec.

<noah> noah: so, we either need to discourage this sort of behavior, or change the specs. Not sure which is better course.

HTML spec defines text/html MIME type and should define authoritative behavior of handling of fragment identifiers

<noah> noah: tend to feel that what the AJAX apps are doing should be discouraged if it conflicts with the normative specs as they now exist

<jar> http://www.w3.org/TR/html5/iana.html#text-html

larry: either browsers need to change behavior to match spec, or spec needs to change behavior to match browsers. The latter seems to be the sentiment of community.

<jar> HTML5 draft text/html registration says nothing about fragment ids at all

<jar> oops... not so...

<Yves> jar, see http://dev.w3.org/html5/spec/Overview.html#scroll-to-fragid (but not in the text/html reg)

<jar> "Fragment identifiers used with text/html resources refer to the indicated part of the document."

noah: this could be handled with new media type, text/html-with-javascript, that wouldn't break webarch

<noah> noah: but of course it would break all of our deployed code that expects text/html

jar: we have a lot of problems with fragment identifiers ... pointing out similar issue with RDFa specs, and also with content negotiation
... WebArch wants consistency

<Zakim> Larry, you wanted to suggest action

<noah> Larry: I think problems with fragids are separable. I'm not as uncomfortable with conneg, which I think was resolved.

<noah> Larry: I think this is an issue with a single document, labeled text/html, for which URIs resolve differently according to whether javascript is turned on.

<noah> Larry: we can resolve separately for each media type, and should push back to the owners of the respective specs.

<Zakim> noah, you wanted to respond to Larry

JAR pointed to the place in the spec which doesn't match behavior of software that claims to implement the spec

<noah> LM: Document doesn't match behavior. Fix one or the other.

<noah> Noah: There is in either RFC 3986 or RFC 2616 the statement that the Content-type identified media type registration determines the interpretation. I think it's a TAG question whether that still holds.

<noah> YL: It's the same for all media types the allow embedding of program logic that manipulates URIs.

Larry: PDF embeds scripting but this isn't a problem for application/pdf
... I proposed an action
... RFC 3887 defines fragment identifiers for application/pdf, there is scripting in PDF but PDF doesn't pass fragIDs to scripts so this isn't an issue with it. I think this is an HTML issue. Maybe it's also an SVG issue, but it's the individual media type definitions and implementations that are the problem.

noah: discussing Ashok's draft, that ?xxxx is identified as server-side identification and #xxxx as client side identification. That what goes on the forward & back queue

<Yves> jar, yes, and it also has implication on caching

noah: (argument that ? is also used client-side)

<Yves> and agree with Noah that ? is not only used server-side

<Zakim> Larry, you wanted to note i proposed an action

noah: want to tell that story, can't if Ashok's document identifies ...

<Zakim> jar, you wanted to suggest that # has to do with resolution relative to content, not server/client

<noah> Exactly, but with one exception. It is true, as I said in my email, that fragids aren't sent to the server.

<noah> Otherwise, they're as you say.

<noah> Clients and servers can mess with ?.

noah: these are a lot more symmetric with respect to client/server... in only one case with a fragid... ....

(scribe missed details of Noah's remarks, hope details will be forthcoming)

<jar> A#B means B as interpreted relative to what document A says. nothing to do with client vs. server

Ashok: I will think about this and will work on revised draft

Larry: +1 to jar

<jar> in some future protocol succeeding HTTP, one might have the #B transmitted to some "server"

<Yves> jar, this was my comment about sub-resource/view as well

<noah> LM: There are other media types with active content that don't have this problem, so this is a problem with certain scriptable media types. Should be resolved per-type.

<noah> . ACTION: Larry to draft proposed bug report regarding interpretation of fragid in HTML-based AJAX apps Due: 2011-01-03

<noah> JAR: Ashok, do you want to talk about the RDFa situation?

<noah> Ashok: Tell me more, but yes.

<noah> JAR: In my pending review action, we'll get to it.

<noah> ACTION: Larry to draft proposed bug report regarding interpretation of fragid in HTML-based AJAX apps Due: 2011-01-03 [recorded in http://www.w3.org/2010/12/16-tagmem-irc]

<trackbot> Created ACTION-508 - Draft proposed bug report regarding interpretation of fragid in HTML-based AJAX apps Due: 2011-01-03 [on Larry Masinter - due 2010-12-23].

<noah> ACTION-500 Due 2011-01-03

<trackbot> ACTION-500 Coordinate with Alexey about a possible presentation introducing IETF to TAG work on Web Apps & report to TAG due date now 2011-01-03

<noah> ACTION-508 Due 2011-01-03

<trackbot> ACTION-508 Draft proposed bug report regarding interpretation of fragid in HTML-based AJAX apps Due: 2011-01-03 due date now 2011-01-03

<noah> Calls on the 23rd and the 30th are hereby cancelled

<noah> We are adjourned

<Ashok> zakim pointer

<Ashok> Thanks, Jonathan :-)