- From: <noah_mendelsohn@us.ibm.com>
- Date: Mon, 10 Aug 2009 16:46:43 -0400
- To: www-tag@w3.org
- Cc: public-tag-announce@w3.org
A text-only copy of the minutes from the first day of the TAG's F2F
meeting in June, 2009 is attached.
Noah
[1] http://www.w3.org/2001/tag/2009/06/23-minutes.html
--------------------------------------
Noah Mendelsohn
IBM Corporation
One Rogers Street
Cambridge, MA 02142
1-617-693-4036
--------------------------------------
[1]W3C
[1] http://www.w3.org/
- DRAFT -
TAG f2f
23 Jun 2009
[2]Agenda
[2] http://www.w3.org/2001/tag/2009/06/23-agenda
See also: [3]IRC log
[3] http://www.w3.org/2009/06/23-tagmem-irc
Attendees
Present
Tim Berners-Lee, Dan Connolly, John Kemp, Ashok Malhotra,
Larry Masinter, Noah Mendelsohn, Jonathan Rees, Henry S.
Thompson
Regrets
Chair
Noah Mendelsohn
Scribe
Henry S. Thompson, John Kemp
Contents
* [4]Topics
1. [5]Admin
2. [6]W3C Work on APIs
3. [7]Language Versioning and HTML
4. [8]Web Application State Management
5. [9]Javascript Security
* [10]Summary of Action Items
_________________________________________________________
<ht> ScribeNick: ht
<scribe> Scribe: Henry S. Thompson
Admin
NM: Scribe duty: Tu: HST, JK; We: TBL, LM; Th: AM, ???
<scribe> Agenda: [11]http://www.w3.org/2001/tag/2009/06/23-agenda
[11] http://www.w3.org/2001/tag/2009/06/23-agenda
NM: [intro to meeting, see
[12]http://www.w3.org/2001/tag/2009/06/23-agenda#F2FReview]
[12] http://www.w3.org/2001/tag/2009/06/23-agenda#F2FReview
LM: Swap first two Thursday morning a.m. sessions?
NM: Yes
[Language Versioning vs. HTTP Semantics]
W3C Work on APIs
[13]http://www.w3.org/2001/tag/2009/06/23-agenda#APIs
[13] http://www.w3.org/2001/tag/2009/06/23-agenda#APIs
NM: W3C is on the verge of taking on standardization of APIs
<masinter> w3c is in the middle of standardiation of APIs
NM: Some folks asked whether W3C should be doing this
... and maybe the TAG should contribute to this discussion
<noah> ac2 n6ah
LM: WebArch and our findings mostly/entirely are concerned with
static stuff
... so this at least appears to be a delta
JK: W3C has some API-type standards already, e.g. the DOM, but the
TAG has not said anything about it/them
LM: Wrt the current chartering decision, we don't have a role to
play in the decision as such
... but if/when they do, we need to consider whether there are arch.
issues there, which is now officially part of "The Web" as the
Consortium addresses it, which the TAG ought to address
NM: So the TAG ought to line up its investments with areas of
interest to the W3C
... What would that mean wrt e.g. device APIs
LM: We should examine our current findings to see whether they
can/should be adapted to cover APIs, and
... as we do new stuff, we should keep APIs in mind
TBL: Yes, obviously -- W3C does APIs, the TAG should include this in
their remit
... The WebApps platform is more and more important, and clearly
APIs are important there
... So, yes, definitely they're in scope
... Going on to say WebArch 2: The Web as a Computing Platform --
I'm not sure
AM: What direction to we provide to WGs/Chairs -- should it be
different? How do API standards get tested? How ensure they are
valid/representative? Is this different for APIs?
NM: Consider drawing a circle within the <canvas> TAG -- the rule of
least power clearly relevant here: contrast sending JS which says
"draw a circle" vs. sending an SVG circle tag
... The JS that comes over the Web is clearly in scope, less so the
kind of local scripting which e.g. manages my desktop
LM: I had a long discussion about <canvas>+JS vs. SVG -- declarative
vs. imperative
<Zakim> noah, you wanted to talk about rule of least power and
canvas tag
LM: For many delivery mechanism, imperative mechanisms are
inappropriate, e.g. in HTML-marked-up mail
... But for other contexts, e.g. a drawing program within a Web
page, imperative is much more appropriate
... Convenience and performance weigh heavily in this case
NM: RoLP is a bit like 'SHOULD' -- there's a tradeoff -- you get
convenience and performance, you lose transparency
TBL: Little declarative languages emerge in this context
... and sometimes get standardized
JR: Contrasting SVG with JS - you start with a weak==declarative
language [HTML], and build out by decorating with JS, there's a kind
of graceful degradation, whereas with JS, [if you start it] with you
are stuck from the beginning, there's no way to move the other way,
from the strong==imperative language to something weaker
<jar> (unless you make javascript safe, by changing it a little bit)
NM: We don't want to just rehash the RoLP, but do we need to call it
to people's attention?
<noah> Yes, and the question is, what else if anything should we do
to "helP" the community that's investing in APIs at W3C?
LM: I don't think people care much about LoRP, insofar as they think
of the Web as entirely made up of servers and browsers
<jar> (re my parenthetical comment, larry is pointing out that even
a safe javascript is not that useful, since it's not declarative)
LM: but once you start _analyzing_ pages, or you need/want graceful
degradation, you have no chance with an imperative language
... So API evolution/degradation/extension that we have the most to
say, wrt both balancing declarative vs. imperative, but also given
an imperative API, the versioning/extensibility should be taken
seriously, and we can help here
TBL: So, yes, endorse LoRP, but when we've got APIs, yes, more to be
said as well: e.g. modularity
... So, given that JS modules don't have a packaging system == a URI
as a name, there's a problem
... A good web-addressable JS package system would be a great thing
... relates to trust
JR: [scribe missed]
JK: What about WebIDL -- allows some declarative statement of
dependencies?
NM: There's no import or anything required to use <canvas> -- either
it works or it doesn't
DC: CSS selectors are a better example
<jar> - I wanted to draw connection to "self-describing web"
finding. Can one go to an HTML page containing javascript, and learn
*without running the code* what its dependencies are? (this question
may be simple ignorance) i.e. can you nose-follow effectively
without execution? - because this might help with extensibility and
graceful degradation.
NM: Some of these are built-in, sometimes you need to try to import
a JS library
<DanC_lap> (my "are a better example" is a response to a pattern
timbl observed that went by too fast for the scribe or something)
NM: and sometimes you can use one as a fallback for the other
... Self-describing Web applies to this case as well, as far as I
can see
... JS interactions are as normatively specified as anything else
JR: But you can't (easily) tell what any given JS will do except by
running it
<masinter> wonder if AWWW has enough 'roles' for participants in the
web, including authoring, analysis, search engines, proxies,
translation gateways, etc... because these are important agents for
programs written in JavaScript
TBL: Consider the case where a small module pulls in Google Maps,
which has its own module structure and conventions
JR: I don't think you can even tell if that happens
JK: You can check dependencies without running the code
<masinter> and authoring tools
TBL: Not inside Google Maps, because they do their own
... There is no standard way of declaring, or therefore of
detecting, JS dependencies on the Web
... So if you try to combine Yahoo Calendar and Google Maps you get
into trouble
... You can't do a JS import from inside JS
JK: So they cheat, pushing a <script source=...> tag
<johnk> Tim said "cheat", not I ;)
<DanC_lap> (raman showed me an import technique that doesn't use
<script> insertion. I didn't study it well enough to remember the
details.)
LM: The problem only arises when you have agents that want to
interact with e.g. script-containing pages _without_ just running
them
... AWWW doesn't say enough (anything?) about agents like this:
spiders, dependency checkers, ...
HST: Tool to download a page and everything it needs to run locally
w/o web access
AM: [scribe missed]
NM: TBL, are you asking if the TAG should take on the
standardisation of dependency declaration for JS?
LM: There's a lot out there already, we don't have to originate this
work
... You can't tell what a program will do w/o running it, but you
can make some of it, e.g. dependencies,
available/accessible/declarative
... So e.g. our programmers have to adhere to conventions so that
raw strings are never used as such, they have to be indirected so
that localization can happen systematically
DC: Two JS issues, modularity and same-origin
... ECMAscript WG has passed on modularity, I think
... but that is really in other people's hands
... Wrt same-origin, the best source for this at the moment is
Wikipedia
... we probably should lift what there is about that from the HTML5
spec., just as we lifted some things from the HTTP spec
TBL: HST was skeptical otr about the possibility that JS would be
made safe
JR: I put my comments in IRC above wrt JS/safety, and then retracted
them a bit following LM's comments
LM: Maybe something of the scope of the old QA activity, focussed on
declarative languages, might be necessary
... Is the QA precedent hopeful?
... If this pblm is too big about the TAG. . .
NM: Trying to see which way we go, I heard TBL say that maybe AWWW2
might be WebApps
... That's broader than just APIs, involves e.g. TV's draft,
security, etc.
... I heard LM say that AWWW didn't talk enough about [other] agents
... JS packaging came up, with the suggestion that we not do the
work ourselves
... Finally, the suggestion that same-origin deserves to be pulled
up to the Arch level
JR: We could issue as it were a Call for Proposals: We don't yet
know what it would mean for us to have Arch. Principles for WebApps,
but we know they would have to address the following requirements
... There's a difference between saying "We don't know how to do
this" and "This is out of scope"
... Saying "Either this is out of scope, or we have to do it" --
there is a third position, which is "We care about this, please you
do it"
TBL: AWWW v. 1 varied hugely in granularity - it's OK to say both
"WebApps are really important, be careful" and "Here's a very
specific recommendation wrt APIs: ..."
... compare "Use URIs" and "Don't use GET unless it's really a GET"
... So, e.g. "The modularity/packaging situation wrt JS really needs
to be improved" and some very specific detailed recommendation
... So we could draw up a ToC, with very variable depth
NM: So maybe will have a session at this meeting to explore a ToC
LM: I heard JR say we could try a document which was _not_ a
finding, but a tabulation of the issues, and our understanding of
them, and why they are important
... I think such a document would be very helpful, and we could do
it quite quickly
... with a goal primarily of raising awareness
NM: Scoped to Web Applications?
LM: No, scoped to APIs
<johnk> I will note though that there is a "widget packaging"
specification, which might be considered a solution to "javascript
packaging"
HST: I would prefer the broader scope, if possible: we have a
situation in which the browser is the _de facto_ distributed web-app
delivery platform, but it wasn't designed for it, and we need a
better one
NM: Procedural point -- do we need to track JS packaging? Is there
something we want to tell the community in this area in the short
term
JK: Is the Widget Packaging work relevant?
LM: I don't think so
TBL: Does it give URIs for package components?
<masinter> it might be relevant but it's a different use of the word
'packaging'
JK: No, but people have suggested it should
<masinter> yes the "widget:" URI scheme is a proposals
<johnk> and there were other proposals which didn't involve a new
scheme
<johnk> widget URI scheme is _not_ global in scope
LM: I think we should engage in discussing the issues, before we
decide where to go with them
<johnk> IIRC, Stuart worked on this quite a bit
JK, yes, he did
AM: Thinking about how we publish the AWWW2 ToC
<masinter> suggest TAG note "Architectural Issues for APIs in the
Web Architecture"
<masinter> and that we try to publish a note in 3 months
<masinter> start with APIs and if we have more to say about other
parts of APIs
NM: So, back to the ToC -- scope this to APIs, or more broadly to
the web-app platform
<masinter> and that 'answers' aren't out of scope, but problems
first
HST: I'm happy to follow LM's suggestion and enumerate problems we
see, and decide the scope later, bottom-up
<Ashok> +1
<masinter> i'm happy to add other issues that relate to APIs but are
part of web applications
NM: There are things on the table which are important, which go
beyond APIs, but which are in this general space, about getting the
Web right for applications in general
LM: I don't want to rule webapps out of scope from the start, but I
want to be able to declare victory when we have a reasonable set of
problems outlined
<masinter> in fact, we could scope it by time rather than by
breadth: "Some Architectural Issues" and we declare success when we
have N months into it
LM: What about XAML and FSG (for Flex, at Adobe) which are hybrids,
there's a markup language which looks declarative, but which is
implemented by API calls
NM: The XAML stuff provides for declarative access to only a subset
of the API
TBL: Possible TOC:
... Declarative:Procedural::....
... APIS: Good Practices, ....
... Modules & Dependencies
... Security: Trust boundaries, Cross-site, Same-origin
... Client-side#URIs
DC: Geopriv?
AM: Don't we need an action to get this started?
NM: We'll come back to that in another session
... AM, any followup wrt geopriv?
<noah> I think we should add PRIVACY to the Possible TOC above
AM: We could ask the GeoLoc WG (W3C) to add some some explicit
discussion of privacy
TBL: How would that be different from the IETF work to date?
NM: Do we know enough to ask this question in a way which actually
provokes something specific?
<masinter> proposal: be clear that scope of privacy and security
issues is not limited to use cases that API is designed for, but
rather all applications which might reasonably use the API
NM: Someone prepared to take an action to draft input to the GeoLoc
WG?
TBL: Need to be willing to spend face time with the editors/chairs
LM: I'm heading to the IETF meeting in July, I will be happy to
liaise with the IETF GeoPriv there
DC: We could pbly talk with Matt Womer and Philippe Le Hegaret here
today
<masinter> with whoever is there
ACTION to Dan to propose concrete steps wrt GeoPriv after consultion
with W3C members/staff
<trackbot> Sorry, couldn't find user - to
trackbot, status?
ACTION Dan to propose concrete steps wrt GeoPriv after consultion
with W3C members/staff
<trackbot> Created ACTION-275 - Propose concrete steps wrt GeoPriv
after consultion with W3C members/staff [on Dan Connolly - due
2009-06-30].
ACTION Larry to take GeoPriv discussion with IETF forward in person
in July
<trackbot> Created ACTION-276 - Take GeoPriv discussion with IETF
forward in person in July [on Larry Masinter - due 2009-06-30].
[break]
Language Versioning and HTML
[14]http://www.w3.org/2001/tag/2009/06/23-agenda#naming
[14] http://www.w3.org/2001/tag/2009/06/23-agenda#naming
NM: We have both strategic and technical questions before us
... Our goal is to have a positive impact on the HTML WG
... I have doubts about whether we can achieve that
... Before we dive in, and we can mix the meta- and the base-level
discussion, but I don't want to proceed w/o _any_ thought to where
we're headed
... I'll leave it to LM to decide whether to drive forward a bit
technically before looking to how to sell the results
LM: The default action in the HTML5 WG will be that there will be no
version indicator
... some people, including Michael Champion, are uncomfortable with
that
... So we could come up with a TAG finding, qualifying WebArch, as
to what situations don't need or even want VIs
... and why HTML5 is one such
... That would help the WG
<DanC_lap> "A data format specification SHOULD provide for version
information." -- [15]http://www.w3.org/TR/webarch/#versioning
[15] http://www.w3.org/TR/webarch/#versioning
NM: I produced a blog entry which went some way in that direction
(see
[16]http://www.w3.org/QA/2007/12/version_identifiers_reconsider.html
)
[16] http://www.w3.org/QA/2007/12/version_identifiers_reconsider.html
LM: I think we are making some progress on understanding the
problem, going beyond the blog post, I think
<DanC_lap> note D Baron's essay
[17]http://lists.w3.org/Archives/Public/public-html/2007Apr/0279.htm
l
[17]
http://lists.w3.org/Archives/Public/public-html/2007Apr/0279.html
DC: Some things I found helpful in moving towards accepting the WG
default position: current HTML version indicators are rarely correct
... David Baron's essay suggests VIs are counterproductive -- it
tells the story of how MSW version 8 has a complete version 7
implementation inside it
... MS can afford to do that, but most folk can't
<Zakim> johnk, you wanted to ask about what we call a "version
indicator"
JK: By VI you mean what? An explicit statement of version, or
anything which allows some agent to detect difference in versions?
DC: A specific flag that changes the interpretation of the entire
document
JK: Entire?
DC: In principle, yes
<DanC_lap> DC: I read
[18]http://www.w3.org/2001/tag/doc/versioning-html/versioning-html-2
0090611.html looking for Baron's argument and didn't find it
[18]
http://www.w3.org/2001/tag/doc/versioning-html/versioning-html-20090611.html
LM: Where are we?
... JR and I wrote a document
NM: One design point -- all features have a permanent and
never-to-be-changed meaning
... at whatever point they are introduced
... In that case, I claim version indicators are redundant
... OTOH, in other cases there may be changes in interpretation
between versions
<masinter> version indicators are only redundant. They may be
useful, but they're not necessary. if you assume web agents are only
browsers and (hand-coded) web pages
<masinter> authoring tools and validators can use version
indicators, for example
NM: In this case version indicators are necessary
<masinter> would like to go through document
<masinter> further, not entirely in control of every aspect
TBL: HTML is generated by people who pull stuff together -- if they
can't get their act together to match start and end tags, they
certainly won't match the whole document to what is essentially the
top of the doc
... NM, your dichotomy is too clean -- in general, evolution isn't
that nice, things change by accident, or to fix bugs in a previous
version
... A single-dimensional VI can almost never achieve accuracy
LM: I'd like to focus on the document, but first
... VIs are only redundant if you look only at hand-authored content
and browsers
... Authoring tools are assisted, and do their job better, if they
have a version target
... They're helpful in content management, as a signal of intended
target
... There's a whole economy of production, consumption, analysis,
etc.
act next
TBL: Not just _people_ scribbling, but pulling stuff from RSS feeds,
DM systems pulling bits from store and script, etc.
<DanC_lap> (DM systems? I think maybe CM systems)
<DanC_lap> (ah... document management)
<masinter> document management vs content management
TBL: so even in cases w/o a single human author have consistency
pblms
<masinter> i've tried to be careful between "version indicator" and
"doctype"; certainly doctype has weaknesses
<Zakim> ht, you wanted to be precise about 'redundant'
HST: I think there is a sense in which what NM said was true,
because tautological, but that doesn't make LM's point invalid
NM: I heard LM say that the VI is advice, or a statement of intent,
not just a summary of an otherwise-determinable fact
... Let's look at
[19]http://w3.org/2001/tag/doc/versioning-html/versioning-html-20090
611.html
[19]
http://w3.org/2001/tag/doc/versioning-html/versioning-html-20090611.html
LM: This isn't scoped to the "Is there a DOCTYPE in HTML5", but it
bears on that question
... It's about what we mean by words like 'language' and 'version'
... Guidelines to groups on how to write extensible languages
<DanC_lap> (editorial comment: in-your-face URIs are ugly; they're
sometimes necessary in constrained environments, but this document
is written in HTML, where you can just use normal links)
LM: A language is an agreement of a community on meaning, wrt
strings (and maybe syntax)
... I'm uttering [a text], and we have an agreement on what it means
... We're dealing with a community in which many different agents
(authors, browsers) have there own precise definition of a language
in those terms
... A standard is then an attempt to coordinate all those languages
into something expressed in a language specification,
... so that all the parties can use the language to communicate
JR: Yes, I think my attempt to confine the definition of 'language'
to appeal only to consumers is probably wrong
NM: I still, going all the way back to our discussions in Edinburgh
[in 2005?], that 'language' has an important nature independent of
producers _and_ consumers
TBL: But it was there that we _introduced_ the dependence on
producers and consumers
NM: We started with the question "per some language specification,
is this text in the language or not?"
LM: We end up distinguishing between a language, which is an
agreement, and a language specification, which is an attempt to
record that agreement
<DanC_lap> (editorial comment: I don't like up-front Terminology
sections. I prefer to see the terms introduced in context. put a
glossary/index at the end if you like0
<DanC_lap> 0
<DanC_lap> )
LM: This allows us to distinguish between "What the spec. says" and
"What was implemented"
... regardless of which comes first -- a spec. can be an
after-the-fact attempt to record an agreement which is instantiated
in implementations, or it can be a proposal which may or may not be
consistently adopted and then implemented
NM: Reasons for language change
... How do languages change? The kind of promises we should make
about the future can be informed by an analysis of what kind of
changes have happened in the past
... Incompatible changes happen, for good reasons
... This section is incomplete
DC: It would be good to remember the players: a lot of authors, even
more readers, few implementors. . .
I would add, per LM, quite a few non-human consumers
[LM continues to summarize the document]
<DanC_lap> note D Baron's essay
[20]http://lists.w3.org/Archives/Public/public-html/2007Apr/0279.htm
l
[20]
http://lists.w3.org/Archives/Public/public-html/2007Apr/0279.html
LM: There is this bizarre reciprocal heuristic behaviour -- servers
are trying to detect what they're serving to, browsers are trying to
detect what language they are about to render, and the situation has
gotten recursive, i.e. spoofed user agent strings in order to
provoke particular kinds of content
<DanC_lap> jar, that's the one
LM: User-agent string and request headers are related to VIs
JR: And content negotiation
NM: The UA string indirectly indicates the language the client is
expecting to render
... The server responds not with explicit VIs, but variants that are
intended to be tuned to the 'version' requested
<johnk_> User-agent header is an implementation version indicator
<johnk_> (not a language version indicator)
TBL: Note that if HTML5 at the moment is using DOCTYPE as part of
its heuristic, that's perhaps an indication that version indicators
would be useful in the future as well
<raman> calling zakim
we're just dialing in
We're working through Larry and Jonathan's document:
[21]http://w3.org/2001/tag/doc/versioning-html/versioning-html-20090
611.html
[21]
http://w3.org/2001/tag/doc/versioning-html/versioning-html-20090611.html
<DanC_lap> (construction noise)
JR: Wrt Motivation of Implementors of Agents section, this is about
the Must Understand rule
... RDFa has been called dangerous to put into HTML, because it
can't be checked automatically
... and since it's not meant for human eyes, it can be ignored by
browsers
NM: OK, so not the same as the SOAP mustUnderstand flag
JR: I'm working to the criticism that RDFa violates the 'no
invisible metadata' HTML5 design principle
DC: Not documented as a design principle, but yes
<DanC_lap> (zeroing in on it
[22]http://microformats.org/wiki/invisible-data-considered-harmful )
[22] http://microformats.org/wiki/invisible-data-considered-harmful
NM: The concern is that the user never sees this stuff, so can't be
sensitive to its significance
DC: The worry is, among other things, that invisible data rots, it
isn't maintained because no-one notices if it's stale/wrong
JR: But this is an ecology, there are multiple audiences
... Why isn't this a critique of comments? (which end up being
re-purposed for automatic consumption)
<DanC_lap> (which section did LMM pick just now?)
LM: If this were to become a Finding, we have some recommendations
to add -- there are placeholders in case we decide to do so
... I don't accept the "HTML is unique" argument for ignoring all
background/precedent
... Ignore what you don't understand is not really an option for
imperative languages
HST disagrees -- the "debugging a blank sheet of paper" approach to
LISP programming depends on the fact that a function which names but
does not use at runtime uba or udf is not broken
LM: Moving on to JR's formalism
... Needs to be up-leveled to deal with communities of consumers and
producers
JR: Sure, like statistical thermodynamics -- you have to _start_
with two-particle interaction, and then take it up-level
... ref. is John Maynard Smith (application of game theory to study
of animal behavior)
q
HST thinks there's something odd when the consumers are by
construction _identical_. . . Not sure what impact on modelling this
might have
NM: Adjourned for lunch, back 1315EDT or thereabouts
TV, are you there?
<raman> here
<raman> calling
stand by
<johnk> ScribeNick: johnk
<scribe> Scribe: John Kemp
<raman> on zakim
<raman> all by myself
<ht> noah having trouble keying
Web Application State Management
[23]http://www.w3.org/2001/tag/2009/06/23-agenda#webAppState
[23] http://www.w3.org/2001/tag/2009/06/23-agenda#webAppState
NM: (summarizes morning's discussion)
... we might add a section to AWWW focused on web as application
platform
... which might have implications for this topic ( web app state)
TVR: discussion of changing URL -> URI - where are we?
... what should I edit?
HT: The "URI" version
TVR: (discusses the logistics of the document)
<DanC_lap> technical stuff first, please
TVR: should we tackle logistics or tech details first?
DC: tech first
TVR: we decided to make this public draft, engaging W3C process and
raising related issues
NM: summarizes issue raised about W3C patent process, and suggests
we solve in email
ACTION Noah to ensure any issue is resolved with Art
<trackbot> Created ACTION-277 - Ensure any issue is resolved with
Art [on Noah Mendelsohn - due 2009-06-30].
TVR: move on to technical issues
... we do not yet have "deep" recommendations, simply a list of ways
people are using client-side # URIs
<noah> Noah note to self: Action 277 is to make sure we are
addressing Art's concerns with the basis on which TAG members
participate and disclose patents. To be picked up late July.
<DanC_lap> action-277: Noah note to self: Action 277 is to make sure
we are addressing Art's concerns with the basis on which TAG members
participate and disclose patents. To be picked up late July.
<trackbot> ACTION-277 Ensure any issue is resolved with Art notes
added
TVR: write down the different usages to identify conflicts between
different methods
<masinter> thought on this: update the URI specification to redefine
"fragment" after # to be 'parameters sent to interpreter' rather
than 'fragment'
<masinter> or else redefine 'fragment' for HTML only
TVR: "push state"
<DanC_lap> how is "push state" spelled? I can't find it
TVR: this is in a more recent draft
... than the one in the agenda
<raman>
[24]http://www.whatwg.org/specs/web-apps/current-work/multipage/hist
ory.html#dom-history-pushstate
[24]
http://www.whatwg.org/specs/web-apps/current-work/multipage/history.html#dom-history-pushstate
TVR: in a browser you have window, which has document which has a
URI
... browser back and forward can page from one URL doucment to the
other
... world more complicated now
... overall state is now more than a URI
... "state" object where window.history contains these state objects
<jar> like form fields?
TVR: so what does this have to do with HashinURL?
... pushState( state, title, url)
... then history list is states with/without URL and vice-versa
... what is your window.location then?
... URL + this state object referenced as a JSON object in the URI
fragment
NM: are we going anywhere with this document?
... we currently say "here is what's happening"
... should we go beyond that?
... and then, do we have comments on pushState?
... so.... work backwards through that list
<DanC_lap> pushState is sort of obviously good as far as
standardizing a pattern that is in lots of JS libs, right?
LMM: not sure I understand the issue
... is it role of fragment ID of indicating state, or about this use
of state?
NM: relates to metadata in URI finding
... one case where this state is private to your browser session
TVR: these URIs do show up in browser address bar
NM: so they can leak out
... one position is that these are private
... how should we tell the story about the relationship between the
server and client in this case?
<raman> GMail is a better example
NM: (gives Google Maps example)
<noah>
[25]http://www.w3.org/2001/tag/doc/metaDataInURI-31.html#forms
[25] http://www.w3.org/2001/tag/doc/metaDataInURI-31.html#forms
NM: address bar doesn't change, but can use 'link' URI to paste to
email etc.
... server sent client a big pile of JS
... metadata finding, server sent client a form
... in both cases, server allows client to mint URIs
... if something comes from resource authority, then we can assume
it knows how to deal with URIs minted by the client
... sees a parallel here
... resource owner assigns meaning to all URIs and has encoded that
knowledge into JS sent to client
... we could make this connection explicit between these two
findings
AM: If I zoomed into the same spot to Google Maps in my browser,
would I see the same thing?
NM: not necessarily, but it is still "server consistent"
TVR: there are secondary requests with secondary arguments encoded
as '#' parameters
NM: isn't that different than what I explained?
TVR: Gmail has notions of thread ID and message ID which can be used
to get back the same message/thread
NM: this is like the Maps case, where these ids can be mailed/pasted
<DanC_lap> "identification is orthogonal to access control" --
bookmark that thought for later ;-)
TVR: there are security implications with passing these state ids
around
NM: this is discussed in the metadata in URIs finding
<Zakim> noah, you wanted to talk about HTML forms and metadata in
URI finding
LMM: the frag id is being used to pass parameters to the UA
... is this a property of the HTML MIME type?
... since HTMLis the authority for that MIME type
... in XHTML case would this delegate to the XML document?
NM: I'm synthesizing an HTML doc from a bunch of different
files/places, and creating a DOM
LMM: fragment identifier is a property of the representation
retrieved of the resource accessed
... should there be an update to what fragment identifiers mean,
such as in HTML case?
... how to do give an identifier to an application in a particular
state?
<DanC_lap> (hmm... does the HTML 5 spec cover this mime
type/fragment stuff? are there plans to? looking it up...)
LMM: how can you construct identifiers which can identify an
application in a particular state?
NM: see this as a set of "virtual documents" - not been in a
monolithic application
... should be a discussion about the set of URIs for the virtual
document
LMM: transition from Web 1 to Web 2 was about transition from
virtual documents linked together to one where application state is
the thing transferred
TBL: agree with both of you
LMM: identifier is not just for a resource, but for a resource state
TBL: people are looking at a place (on a map) - not a state of a map
... that is what is invariant
<DanC_lap> (yes, there seem to plans to...
[26]http://www.w3.org/html/wg/tracker/issues/53 ISSUE-53
mediatypereg Need to update media type registrations State: RAISED)
[26] http://www.w3.org/html/wg/tracker/issues/53
NM: we can agree that both of these views are coherent
... document/resource-oriented view is a good model that bridges
this web 1.0/2.0 gap
LMM: model is less descriptive of what is going on
... when I sent you a URI of Google Maps pointing at Cambridge, I'm
also sending you a link to an application which has the ability to
zoom to that place on a larger map
NM: true, but not so different from resource-oriented view
AM: describe the link to metadata in URI again?
NM: main question is "what right do I have to guess what URIs are
appropriate here?"
... resource owner chooses
... we tell the story of HTML forms
... two cases:- form itself came from resource authority, so you can
assume that URIs delivered are consistent according to the owner
... second is that "all bets are off" otherwise
TVR: what are you suggesting?
NM: point to metadata in URI from Has in URI and draw the parallels
LMM: what problem are we trying to solve here?
DC: people that might be using two conflicting JS libraries
... they mostly don't "bump into each other"
TBL: looking at DCs FOAF page - URI of "you"
... inside tabulator, nowhere to see the #
... RDF has "used" the #
... could propose an "extended URI" scheme
... ##
NM: I'd like to see the Google Maps method explained - showing this
usage of the 'link' allowing me to send/email a URI
... showing people how to do this "on the web"
... is good
... equivalent of using cookies to represent state (URI alone is not
useful)
... navigation in these apps is often done quite privately
LMM: OpenAJAX Alliance works on good practice statements for AJAX
apps
... would our advice fit into their domain, for example?
... is this advice on building web 2.0 applications?
TBL: architectural principal is that user should "have a history"
(to browse)
HT: there are some interesting ways in which web 2.0 "breaks the
Web"
... much less content that you see is being indexed than it was 5
years ago, because content is synthesized depending on things more
than the URI + original representation
... crawlers don't see all the things they need to see (forms,
cookies etc.)
... crawlers get stuck in "tarpit" when they attempt to explore such
spaces
<DanC_lap> (hark to alexa vs the original calculator web site...)
<DanC_lap> (oops; altavista, not alexa)
HT: image we have of webarch is that servers represent hierarchical
file systems
<Zakim> ht, you wanted to remark on non-Browser agents
HT: if this document could bring this issue to the foreground and
draw attention to tradeoffs
LMM: this issue is an important instance of a larger problem
... happy to deal with large problems by dealing with single
instances, but need to be sure we can address the broad issue with
this example
<raman> simple answer to Larry's "why are we doing this" -- because
someone on the TAGis motivated to work on it
NM: there are new idioms for building apps, and I think it's a good
thing to write down these issues and tradeoffs
<raman> we could say that that shouldn't be how the TAGworks, which
is a fine thing to do, but in my experience, people only work on
things that motivate them:-)
NM: do we need another session?
TVR: I don't think so
NM: so, where should we go with this?
TVR: if content doesn't change it should turn into a note
AM: would rather consider this in the context of AWWW for web
applications
LMM: would publish this as a note describing the issue, and noting
it as part of a bigger effort
TVR: happy with the idea of publishing this as a note, and as part
of a larger effort
NM: where to draw the line?
<DanC_lap> (I heard TVR say he's happy provided the larger effort
happens)
TVR: (says a lot of stuff I didn't hear well enough)
NM: what would you do to get more comments?
TVR: not sure
... worried that our work is dropping off the radar
NM: make no decision right now (on what to do next)
... try looking at the web arch for web applications first
LMM: would like to see a more specific proposal
TVR: will do no further work without further input
... what about cases beyond HTML+Javascript?
NM: thinks TVR is talking about how these parameters are used in
things such as Adobe Air
LMM: describes media type registration for PDF and its use of #
TBL: what happened timbl to plaintext # line numbers?
LMM: desire to have "more robust" pointers than line numbers
... for web apps, how you do pointers to app state that survive app
updates is interesting
... HTML frag ids are robust in that way
... as you move to other media, the issue of robustness of such
pointers is important
NM: would like to see links to the metadata in URI finding, but
other than that, put it aside for now
... look at larger issue (web app arch) and revisit
... this issue in that context
... (break)
<timbl>
data:text/plain;Text%20plain%20fragids%20are%20like%20L0%20%28same%2
0as%20L0-L1%29%20or%20L0C0-L3C6%20with%20obvious%20meanings.
Javascript Security
[27]http://www.w3.org/2001/tag/2009/06/23-agenda#security
[27] http://www.w3.org/2001/tag/2009/06/23-agenda#security
JAR: how to relate the various security issues discussed?
... discussion of Origin header and related risks
... Javascript security related to DC
... relationship to web architecture of JS security
... wrote
[28]http://www.w3.org/2001/tag/doc/resource-protection/20090615
[28] http://www.w3.org/2001/tag/doc/resource-protection/20090615
<raman> could you call in to zakim?
JAR: Cross-origin requests fall into confused deputy problem
dialling in
JAR: traditional ACL model doesn't work in situations where there
are more than two parties involved in security
... risks when you separate the credentials from the name
... that is why this is a "forgery" (forging the link between the
name and the credentials)
NM: is this typically a cookie problem?
JAR: whatever ambient credentials held with the site
... could be IP address, client cert or other ambient creds
HT: scenario is by whatever means I am looking at page served by
attacker, with link to legitimate page which when clicked will send
user's creds to the legitimate site
(discussion about examples of this issue)
JAR: reiterates the three items at the beginning of this topic
... defense against confused deputy attack is to keep creds closely
linked to the name
jk: one way is to make the creds and name the same
JAR: can use nonce for example (provide unguessable name)
... secure ECMAscript packages credentials into the object
... you can then put potentially hostile code into a container
... link to web arch is regarding naming
... Tyler (Close)'s solution is to put the creds in the URI
... in JS you'd pass that URI around as part of a JS object
AM: if you have an object with these things in it, there are no
methods to extract the credentials?
JAR: if creds are hashed together with the URI, then even if
attacker can get access, it cannot change the link between the name
and the creds
NM: so URI can be more than a name?
... if you're encouraging people to use URIs which cant be
bookmarked, that's not good for webarch
<Zakim> DanC_lap, you wanted to share some thoughts on
[29]http://waterken.sourceforge.net/web-key/
[29] http://waterken.sourceforge.net/web-key/
DC: saw Tyler's papers, and have met him
... lots of discussion that acl is orthogonal to naming
TBL: we talk about the difference between authn and authz
<raman> off to lunch in 4 mins.
<raman> back in 45 mins or so
<DanC_lap> DC: I think there's room to acknowledge capability style
URIs as well as URIs that you can mail around without giving access
<DanC_lap> Tyler's "Mashing with permission"
[30]http://waterken.sourceforge.net/web-key/ is an extensive
critique of 3.5.2. Linking and access control
[31]http://www.w3.org/TR/webarch/#id-access
[30] http://waterken.sourceforge.net/web-key/
[31] http://www.w3.org/TR/webarch/#id-access
<Zakim> johnk_, you wanted to talk about multiple identities
JK: which credentials are carried in these references?
<Zakim> noah, you wanted to ask about URIS as capabilities
JAR: you could encode multiple sets into a reference
DC: there is a style where URI is a capability
... Tyler's analysis is that leaking of URIs is less of a problem
than phishing+cross-site request forgery
NM: so, advice in 2.7 of Metadata in URIs is still good advice?
JAR/DC: no, Tyler et al say this is bad advice!
LMM: advice is good for some situations, bad for others
TBL: appropriate to say that there are two patterns of use - 1) ACL
is done orthogonally to URI metadata (metadata MAY be public)
... and another, where URI must be completely secret
HT: you are fooling yourself if you think URIs won't get out into
the wild
(missed TBL third case) - secret information in URI, as noted in 2.7
of metadata in URI spec.
TBL: (describes tripIt 'send to' case)
NM: there is a story about if I use HTTP, then URIs will appear in
several places
... and with HTTPS, fewer places
TBL: re-open the metadata in URLs finding, explain capability
use-case
[32]http://www.w3.org/TR/access-control/ Cross-origin Resource
Sharing
[32] http://www.w3.org/TR/access-control/
JAR: there is conflict between CORS and this capability approach
... Tyler and Mark Miller asking for GuestXHR feature support in
CORS
... to have a way to issue a request such that request is stripped
of all credentials
NM: Guest approach only useful with Caja-like approach?
JAR: you could also build your own sandbox
NM: don't think the metadata in URI finding should deal with all the
work on this issue
JAR: mnot sent email regarding an issue with CORS -
[33]http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/06
43.html
... concern that this WD is a threat to the use of URIs - causing
people to switch from REST mode to SOAP-like methodology
[33]
http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0643.html
LMM: Origin header has been deployed
JAR: Comments are i) CORS has impact on Web Arch (see above line
about REST/SOAP) ii) ACLs won't solve all the issues
... if you accept the capabilities approach, then CORS seems
antithetical
LMM: process issue is that orgs which build security infrastructure
for the Internet should review this document (CORS)
... responsibility of WGs to get this review
NM: we could comment on this draft
HT: TAG exists because of need to provide web-arch related comments
early enough in WG spec. process
... there is precedent for director to hold some specs. to a higher
bar when exiting CR
... so, we have an obligation to say something to the WG - that is
the role of the TAG
NM: is it about what we (TAG) think, or lack of implementations by
particular groups (such as server vendors)?
LMM: the Origin header didn't seem to have significant support from
server vendors
... risk when deploying something insufficient for solving the
problem, is that it becomes a distraction from solving the actual
problem
... particularly a problem for security-related issues
NM: not sure about the concrete steps
AM: we've said that URIs are public and can be sent around, and now
we're saying... maybe not
DC: we should send a comment to CORS regarding CR exit criteria
LMM: I believe the counter-arguments against the CORS approach are
credible and reasonable
... but would prefer we get the involvement of security experts in
order to resolve the conflict
... and would require the involvement of server vendors
NM: strawman - we write a note saying we have reviewed these specs,
and have been made aware of possible shortcomings
... we feel these concerns should be convincingly addressed
<ht> The current state of play:
[34]http://news.netcraft.com/archives/web_server_survey.html
[34] http://news.netcraft.com/archives/web_server_survey.html
NM: TAG may do more research, but would prefer the WG confer with
security experts, but also note that acceptance by server vendors
might resolve these concerns
Action to ht to draft a message to webapps chairs relaying TAG
concerns around CORS
<trackbot> Sorry, couldn't find user - to
<scribe> ACTION: ht to draft a message to webapps chairs relaying
TAG concerns around CORS [recorded in
[35]http://www.w3.org/2009/06/23-tagmem-minutes.html#action01]
[35] http://www.w3.org/2009/06/23-tagmem-minutes.html#action01
<scribe> ACTION: Henry to draft a message to webapps chairs relaying
TAG concerns around CORS [recorded in
[36]http://www.w3.org/2009/06/23-tagmem-minutes.html#action02]
[36] http://www.w3.org/2009/06/23-tagmem-minutes.html#action02
<DanC_lap> trackbot, status
<scribe> ACTION: Jonathan to draft changes to 2.7 of Metadata in
URIs to cover the "Google Calendar" case [recorded in
[37]http://www.w3.org/2009/06/23-tagmem-minutes.html#action03]
[37] http://www.w3.org/2009/06/23-tagmem-minutes.html#action03
<trackbot> Created ACTION-278 - Draft changes to 2.7 of Metadata in
URIs to cover the "Google Calendar" case [on Jonathan Rees - due
2009-06-30].
<scribe> ACTION: Henry to draft a message to webapps chairs relaying
TAG concerns around CORS [recorded in
[38]http://www.w3.org/2009/06/23-tagmem-minutes.html#action04]
[38] http://www.w3.org/2009/06/23-tagmem-minutes.html#action04
<trackbot> Created ACTION-279 - Draft a message to webapps chairs
relaying TAG concerns around CORS [on Henry S. Thompson - due
2009-06-30].
<DanC_lap> action-278 due 7 july
<trackbot> ACTION-278 Draft changes to 2.7 of Metadata in URIs to
cover the "Google Calendar" case due date now 7 july
<noah>
[39]http://lists.w3.org/Archives/Public/ietf-http-wg/2009JanMar/0037
.html
[39]
http://lists.w3.org/Archives/Public/ietf-http-wg/2009JanMar/0037.html
<noah> Raman, I'm not sure if you're lurking, but shortly we will be
discussing scheduling of future meetings, etc.
<raman> calling zakim
JAR: notes Roy's email on this subject
[40]http://lists.w3.org/Archives/Public/ietf-http-wg/2009JanMar/0037
.html
[40]
http://lists.w3.org/Archives/Public/ietf-http-wg/2009JanMar/0037.html
<jar> You can have CSRF even with completely static content.
<noah> Warning, just as we were about to wrap, Dan asked to talk
about more security, and I agreed.
DC: (draws 2x2 table) with CSRF cases for GET and POST
1. attacker hosts JS, which is executed by consumer which sends a
GET to bank
2. is 1. with POST, and JS
second column has no javascript
3. (no JS, GET) attacker is malicious, bank is negligent (executes a
GET with side-effects - img tag calls the GET and hides the
side-effect without user input)
4. POST with no JS, and user is asked to click something to same
effect as 3.
DC: without negligent system entities, are there still attacks of
these forms?
TBL: A POST is a commitment by a user, and should be presented as
such
I think we should document the examples in this table, and possibly
derive advice to users and servers which wish to mitigate such
attacks
<DanC_lap> s/without negligent system entities/without allowing GET
scripts to POST/
<DanC_lap> close ACTION-274
<trackbot> ACTION-274 See if I can reconstruct a discussion with tlr
where present course and speed will lead to GET-based links becoming
regarded as unsafe closed
NM: propose we document this table, first as an email
<DanC_lap> ACTION: DanC (with John K) to enumerate some CSRF
scenarios discussed in Jun in Cambridge [recorded in
[41]http://www.w3.org/2009/06/23-tagmem-minutes.html#action05]
[41] http://www.w3.org/2009/06/23-tagmem-minutes.html#action05
<trackbot> Created ACTION-280 - (with John K) to enumerate some CSRF
scenarios discussed in Jun in Cambridge [on Dan Connolly - due
2009-06-30].
JAR: what about my note on resource protection?
<DanC_lap> +1 TAG blog. good to acknowledge the criticism of
"addressing is orthogonal to access control" pattern
<DanC_lap> (capture a sound-bite from noah: "how GET becomes
unsafe")
(discussion about blog post vs notes/findings)
LMM: first inclination is to blog it in TAG blog
NM: ADJOURN
Summary of Action Items
[NEW] ACTION: DanC (with John K) to enumerate some CSRF scenarios
discussed in Jun in Cambridge [recorded in
[42]http://www.w3.org/2009/06/23-tagmem-minutes.html#action05]
[NEW] ACTION: Henry to draft a message to webapps chairs relaying
TAG concerns around CORS [recorded in
[43]http://www.w3.org/2009/06/23-tagmem-minutes.html#action02]
[NEW] ACTION: Henry to draft a message to webapps chairs relaying
TAG concerns around CORS [recorded in
[44]http://www.w3.org/2009/06/23-tagmem-minutes.html#action04]
[NEW] ACTION: ht to draft a message to webapps chairs relaying TAG
concerns around CORS [recorded in
[45]http://www.w3.org/2009/06/23-tagmem-minutes.html#action01]
[NEW] ACTION: Jonathan to draft changes to 2.7 of Metadata in URIs
to cover the "Google Calendar" case [recorded in
[46]http://www.w3.org/2009/06/23-tagmem-minutes.html#action03]
[42] http://www.w3.org/2009/06/23-tagmem-minutes.html#action05
[43] http://www.w3.org/2009/06/23-tagmem-minutes.html#action02
[44] http://www.w3.org/2009/06/23-tagmem-minutes.html#action04
[45] http://www.w3.org/2009/06/23-tagmem-minutes.html#action01
[46] http://www.w3.org/2009/06/23-tagmem-minutes.html#action03
[End of minutes]
_________________________________________________________
Minutes formatted by David Booth's [47]scribe.perl version 1.135
([48]CVS log)
$Date: 2009/07/21 19:39:15 $
[47] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
[48] http://dev.w3.org/cvsweb/2002/scribe/
Received on Monday, 10 August 2009 20:45:13 UTC