Progress Events

chaals: Progress events are
events for showing progress :-)
... Issue about what events must be defined in the spec
itself.
... Justification is that there is a definate pattern that must
be followed when implementing these events.
... Progress events have been implemented by SVG some years ago
(there a bit of a legacy)
... Considering making the events requirement a "SHOULD"
instead of a MUST.
... This text presumably makes it easier to integrate into
other specs.

Hixie: Main concern with the
requirements able to be defined in other specs and the progress
events spec is how do you test this?

shepazu: Can progress events be
implemented outside of a host language?

Hixie: Would like to have a
normative section for what the event objects look like, then a
non-normative section for what other spec authors should
generally follow.

shepazu: Concerned that an
implementer wouldn't implement the non-normative parts.

chaals: With a spec only having
SHOULDs, there's no normative requirement for
implementors!
... Would such an approach make sense?

Hixie: From a UA point of view,
the dispatch of the events section in Progress Events would be
redundant with the definition in a host spec.

chaals: Without a normative
requirement, there's nothing to prevent anyone from completely
ignoring the spec.

Rob: Would it make sense to have
a section for reasons why the Progress events wouldn't be used
as spec'd?

shepazu: Question about what the
different use cases are for when scenarios might employ
progress events.

<shepazu> for example, you
could use progress events for computationally intensive
processes

mjs: Should have a section for
how Progress events should "typically" be used (in a basic
scenario), but to not overconstrain the spec.

chaals: I propose to take the
MUST requirements off of the UA requirements, and change these
to SHOULD, and include examples of when you might not want to
follow the basic pattern.

anne: Don't think it makes sense
to have user agent requirements in this spec.

Hixie: There are conflicting
requirements must / must not depending on the spec.

anne: XHR, AppCache, Media
Elements all specify how these events are to be
dispatched.
... So don't see the point of a common model.

chaals: Rather than having a new
spec author search through the various specs to find the common
pattern, they could go to one place (the Progress Events spec)
to have a template to copy.

Hixie: Great--as long as it's not
normative, I love it.

shepazu: +1

anne: Seems pretty complicated to
a make a generic model.

<Hixie> specifically, what i
thought i understood was that the progress events spec would
have a section that can be copied and pasted into other specs,
that would put requirements in those specs for queueing tasks
to fire events, etc

<Hixie> these requirements
would not be normative at the progress events spec level

anne: No formal objection.

<arun> If it is
non-normative, issues behind objections can probably be
mitigated (e.g. how complicated a general model might be).

<chaals> Proposed resolution:
Remove the User agent requirements and make them informative
for the "default case", provide examples of how a spec would
incorporate the default case and examples of where it would do
something differently

<chaals> RESOLUTION: Remove
the User agent requirements and make them informative for the
"default case", provide examples of how a spec would
incorporate the default case and examples of where it would do
something differently

<MikeSmith> Hixie, so HTML5
has no normative dependency on Progress events currently,
right?

chaals: Issue 107 is largely
redundant if we simplify.
... There is another question: what does the total and loaded
count mean?
... Now is specifies the number of bytes.
... In removing the normative requirement, the "bytes"
requirement could totally go away.
... Makes sense for me to recommend bytes as the default simple
case.

Hixie: So far, the various specs
interpret the values different already {files, bytes,
objects}

chaals: Propose we drop the total
bytes in favor of showing progress of "something".

<MikeSmith> chaals, Ian Fette
and Lachy came in, need to intro himself

shepazu: Please keep existing
text in place for a compare/contrast draft.

chaals: I think this wraps up
what I had to discuss on Progress Events.
... Let's break now, and reconvene at 11. We'll be in Salon 5
meeting with Device API.

<chaals> Scribe: Chaals

<scribe> ScribeNick:
chaals

CORS

AvK: Two open issues raised by
mnot
... one is naming, one is technical. And a missing issue MM is
here to talk about - should we throw it all away...

MM: Suggesting the mechanism
should not present authorising information in a ?? fashion.
It's up to applications to decide what to do

AvK: Also status of origins spec
at IETF, and call for tutorials/use cases.
... let's begin with the big fat guy in the middle of the
room

MM: Objection is that we know
about confused deputy problems. Systems that do authentication
by associating authority on the identity of the requesting
identity creates vulnerabilities.
... CORS links origin of requester from origin header, which
fulfils requirements to make Confused Deputy problems.
... discussion hasn't addressed the objection.
... Not showed that it doesn't apply, doesn't matter, etc.

AR: Can anyone show a sample
attack that demonstrates the nature of the problem?

MM: Tyler Close posted a 3-aparty
interaction where each step is intuitive in CORS< and the
result creates a confused deputy problem.

MJS: My reply was that this came
from using arbitrary URIs rather than recognising that they are
meant to be scoped to a specific subdomain. Don't think that is
created by CORS

MM: What validation should the
second party do to the URIs to ensure control?

MJS: Site 1 has photos, site 2
printing, site 3 has storage.
... photo site wants printer to get things from storage.

MJS: I think that this setup
requires a shared secret, which requires server-server
communication.

TC: 3 servers. 1 has photos, 2 is
a printer, 3 is a storage service

MJS: CORS tries to cut out the
requirement that your servers have to talk to each other in
order to allow the request. Request something from server A,
then you can make a request to server B without having to ping
back to server A and ask that to talk to B

<MikeSmith> somebody who has
a camera should please take a photo of Tyler's diagram

TC: I think you are explaning how
people can use one-time tokens to solve that problem. We don't
think you need to use CORS to do that, and if you do rely on
CORS you are vulnerable to Confused Deputy

<DanC> (what mjs said sounds
like one of the CORS requirements... advancing the
state-of-the-art from having to go thru the origin to get to
(coorperating) 3rd parties)

MM: The key is that post-login
the auth login is not ambient

MJS: Main reason for CORS is to
bootstrap the one-time mechanism - only other known way are
shared secret on server side and require server-server
communication to pass the tokens
... (server can't send its secret via the client, because then
it isn't secret)

Rob: Seems there are
disagreements on what CORS is. You see it as an auth system,
and I don't think that it is - CORS says you can talk to this
guy, but the auth sits on top of that.

MM: You are not an origin...

MJS: You can make a request, but
you can't guarantee that it gets fulfilled

TC: CORS adds a header on origin,
that sites will use (because they are encouraged to) as a
mechanism for auth, and that leads them to be caught by
confused deputy

<DanC> (the security risks
are clear enough to me; have alternative designs that avoid the
risks been offered?)

MJS: Think that there are cases
where CORS will be used, that do not introduce the problem. I
want to see why we will run into problems.

MM: Objection specifically
applies to 3-party scenarios. 2-parties don't create a problem.
But once you create the system, and people apply their 2-party
system to 3-party cases, you *will* end up with problems.

MJS: Classic CSRF problem is that
the 2 parties are a site expecting a form, and the user giving
it, and a 3rd-party making malicious use of the user's
authority.

<DanC> (seems to me all the
relevant arguments are represented in the WG; if you just give
me an issue # so I can tune in later and see what's decided,
I'll happily go do other stuff.)

<ht> +1

<anne> DanC, there is no
issue number

<DanC> yeah, that seems like
a bug

MJS: CORS lets you solve this by
giving a secure mechanism for dealing with the transaction.

<DanC> easy to fix: ISSUE:
confused deputy problem

<anne> DanC, if we agree this
is an issue there's no need for an issue number because we'd
need to do something else

TC: Web browser is on a site that
cmes from the photo manager. all interactions take place on
that page.

<DanC> anne, not at all.

<noahm> Art: I'm seeing some
sentiment that if the Webapps group would open a formal issue
to explore confused deputy, the TAG would consider that a good
step.

TC: user hits a button to print a
photo. a button asks a printer site to print a photo.

<DanC> an issue is just a
promise to make a decision; it doesn't presume which way the
decision will go

TC: Out of band, they made an
agreement that the manager could ship jobs to the printer.

MJS: THe question is whether
there is a sensible way to use CORS that doesn't have a
vulnerability?

CMN: I think the question is
whether there is an obvious way to use CORS that introduces a
security risk

TC: We are objecting to the idea
that the group is baking up a way that people will create
security risks

MJS: I don't think that is an
issue. CORS allows for 2-party transactions to be done that are
secure.

MM: The 2-site model is OK. The
problem is that the assumption that the request reflects only
the requestor's intention, and it is actually formed using
information coming from a third party, a set of decision each
individually sensible will compose to create a 3-party
interaction pattern that we know to be vulnerable.

TC: You say it is unlikely, but
we have seen it played out into cookies. and into clickjacking.
How often do we repeat the pattern before we stop doing it?

TC: The page now sends a request
to the printer page to get the spool file, then we send a
request to the storage page to copy stuff into the printer
spool.
... the user owns lots of sites on the storage site. If the
printer site sends back a request for DontTouchMe, the file
transferred goes into DontTouchMe instead of a spool file.

MM: Intuitive assumption for the
developer is that the URL from teh printer site is a URLthe
printer has access to.
... problem arises because if the storage site checks access
against the origin, it will check against the manager's access,
not the printer's.
... manager would want to make the decision based on whether
the printer has access, but has no way to ask that.

TC: There is an access control
problem. CORS is telling developers to use a solution that
won't work. There are other solutions.

Rob: If manager was only talking
direct to the client, direct to the printer, and direct to the
store, no problem.

AR: The use case can be
shoe-horned into other systems.

MM: Yes, into any situtation
where auth is passed on behalf of the client. If the requestor
can say "I want this if my request source had access" then you
solve the problem.

DS: MM agreed there are ways to
build secure applications with CORS< as well as building
vulnerabilities.

MM: True.

<mjs> oh hey Zakim is
back

MM: Issue is primitives that
compose data. Analogy - LISP was dynamically scoped, and that
was useful in many ways. But there were a set of individual
decisions where you can't know tha they are bad, compose
together to create a problem.

CMN: If you can restrict the
system to 2 servers, can you avoid the problem.

TC: No. You can still make the
problem without the 3rd website.
... e.g. combine the storage and manager here

IH: Why would the manager give
the printer access to tell it to write something over closed
content?

MJS: it seems in the 2-party case
you have to make it needlessly complicated to make the
vulnerability work

TC: If any auth data from site A
came from site B, you create confused authority.

MM: If you are not using anything
that didn't come from *you*, then you are not creating a
vulnerability.

TC: If you can say "don't apply
my authority to anything I didn't make myself" you solve the
problem.

MJS: If making requests to
yourself can have this problem, that already exists. XHR
requests to you implicitly carry auth because you are the only
one that can make a request to yourself.
... so any request using info from a 3rd party exposes
this.

TC: Yes

MJS: Self to self has client
authority

TC: Yes, but we should be trying
to reduce this.

MM: Guest XHR should not present
auth even when it goes back to its own origin.

MJS: So using guestXHR is similar
to formulating requests in a way that you use guestXHR-like
behaviour for requesting things with 3rd party data.

MM: Yes. It is normally possible
to make the mistake. Compat prevents us from retiring existing
mechanisms that allow this, but not introduce new mechanisms
that have the same problem, but a new mechanism that doesn't
have this problem.
... guestXHR is a refolrmulation of CORS that addresses our
security concerns.

<timeless> a/folrm/form/

JS: Do you have an alternate
proposal. If GuestXHR is it, how do you build a website that
uses it nicely?
... imagine websites would be hesitant to ask users to copy
strings from one place to another

TC: A lot of them are possible
that look pretty much like existing things. There are existing
UIs that are inherently vulnerable to clickjacking, but we
could use others which are not vulnerable.

MJS: Think the 2-site mechanism
is the thing we are interested in.

TC: Would like to see the problem
being laid out for existing approach, and I will explain how to
fix it

Rob: Fundamental problem is if
manager can be asked to do something by another party, with the
authority of the user in the middle.
... question is whether CORS encourages that behaviour

[+1]

<tlr> +1 to "are people
encouraged" as the key question

scribe: I am not convinced we are
encouraging this behavious with CORS. Are we making it any more
likely?

<timeless> s/vous/vour/

MM: Problem is not encouraging
lack of checking, problem is creating a demand for checking
that cannot actually be met.
... if authority is carried along then there is no
problem.
... Existence of CORS doesn't force servers to make decisions
based on origin. If servers make the decision based on extra
information carried alongside.

MM: Creates an conditional path.
if it were unconditional there wouldn't be a problem.

AvK: It needs to be
conditional

MM: And therefore it is
inherently an access control problem.

AR: zakim, close the queue
... You have shown a model where Confused Deputy can be
createed. I think there are clear scenarios shown where it
cannot be a problem. There are use cases CORS addresses that
solve badnesses people used in the past.
... there is some case to draw these examples and explain them
as bad design.

TC: Yes. Ditto HTTP auth, but we
saw people actually used it in a way that led to problems, and
we suspect that CORS will be used widely to produce such
problems.

DS: Let's say we keep it as is,
and describe carefully how it should not be used and explain
the problems.
... nobody wants to create insecure interfaces. Can we show
them why not to do A, and why to do B instead, would that
work?

MM: yes...
... point is to enable people to write applications that are
useful and secure, and that requires education, any solution we
have will require that.
... The question is not whether you can make things secure, the
question is whether you can modularise sensible decisions and
then compose them to make problems, you have created a
fail.

DS: There are inherent
composition problems. Can we forestall those in practice?

<mjs> awww

MM: If the token is passed along
with the request, and origin is only used for forensics
(logging who asked for what) then you don't have a problem
because access came from the right token, and you have
forensics to find out where bad requests are coming from, you
are reacting to having allowed inappropriate access, and then
CD is lesser evil.

TLR: Hear the argument a lot that
X is a bad application design decision - and that is true.
Often they are poor decisions under composition. THinking
through, what kind of services will use CORS? We will see
relatively generic services - data bus, message bus, etc. These
may well permit access to other apps, based on a mix of CORS
and maybe others. And those sound like things that will get
composed and therefore lead to composition problems.
... market isn't just working in tight coordination, but people
making building block services, we get into scary teritory. And
I am starting to be convinced by Mark and Tyler's argument - I
think we need to be really careful of it.

CMN: We will wrap here, because
we are not getting to resolution
... will look for more time to do this tomorrow

DS: Can people try to prepare
clear presentations for tomorrow?

AvK: Would be good if they can be
very concrete.

MM: Didn't see in the draft that
a requirement is to avoid server-server communication... is
that an understood requirement?

AvK: Yes...

<scribe> Scribe: Sam

Views

<scribe> ScribeNick:
weinig

anne: there are a bunch of spec
that refer to views
... rendered view/default view
... in reality, all implementations always return the default
views
... we should kill the concept of views

shepazu: inventor of views thinks
it was a bad idea

jonas: mozilla has support but it
is a pain in the buttox

shepazu: does anyone know of any
implementations

jonas: mozilla uses if for print
preview, but it is not accessible from the dom

maciej: there is no way to know
all the of the names of the form controls

tl: can css change things into
form controls

maciej: there is
css-appearance
... there is svg:textarea

anne: that has ranges inside it
if is editable

maciej: 3 cases, 1) if you hit a
text node: the containing node is the text node, the offset is
the offset into the text node
... 2) if you hit a form control, the container is the control,
the offset is the offset in the control

<chaals> SW: With range
ability to get position you can get a bounding box of the
collapsed range

maciej: 3) if you hit an element,
you get the element as the container, the offset is the range
offset

anne: the caretPosition object
should have a range attribute, which is null for form
controls

<chaals> SW: do we want to
make stuff aware of CSS transforms, or add a new set of APIs
that return quads based on 2d transforms except giving
quads?

anne: dean (apple) asked me about
that, people from apple have been asking me about it as
well

maciej: returning the bounding
box seems like the most sensible thing

anne: that is what is done for
svg

maciej: but we should have quad
apis as well
... maybe we only need 3 points, maybe we want 4 for
perspective transforms
... math is hard
... all we really need is a way to take the bounding box and
convert it page space

maciej: we need a way to convert
a point from node to page space (and vice-versa) as well

anne: what is the coordinate
system of the node

chaals: it is the point in the
transformed node

chaals does something with his hands

anne: we should probably try and
move these apis away from the window if we can

<chaals> Proposed RESOLUTION:
Anne will (get help from some clever guy at Apple to) spec up
the ability to get the bounding box, under transformations, and
the bounding box of the transformed quad within the page

<chaals> RESOLUTION: Anne
will (get help from some clever guy at Apple to) spec up the
ability to get the bounding box, under transformations, and the
bounding box of the transformed quad within the page

<chaals> in recess

in recess

<chaals> Scribe: Maciej

<mjs> avk: ISSUE-33 - should
re-entrance be allowed for readystatechange

<chaals> ScribeNick: mjs

ISSUE-33

js: so are you not allowed to
call open? does that throw an exception?

avk: the issue is that IE throws
when certain methods are called in a particular state
... not throwing is generally better

tl: unless there's a really good
reason to throw

js: it appears Firefox never
throws for status but it might throw more often for
statusText
... appears to throw a random number

sw: we added throwing to match
other browsers (the minimum)

js: why did you change, was it
b/c websites complained?

sw: I don't remember, it might
have been to change the spec

*general mumbling*

*awkward silence*

scribe:

avk: what are we going to do -
change and not throw?

js: I'd like to err on the side
of not throwing

RESOLUTION: for
ISSUE-103, don't throw

the other bit for XHR1 was the test suite

^ avk:

avk: it would be nice to have
some help at some point

fo: I've got some notes which I
still owe you on that

jr: do you have mark nottingham's
tests? do they cover different things?

avk: probably

jr: I think he's got things
checking caching

avk: the test suite has quite a
lot of coverage, especially security stuff and resolving
URLs
... there's definitely more things that can be tested

cmn: which things are those

avk: methods probably... http
verbs
... there's a bunch of side effects that are not all covered
yet, e.g. when you invoke open()
... *more technobabble about complicated steps*
... I don't think there's tests for Accept, Accept-Language,
conditional GET

avk: Close 104 for now and
revisit when we have a serialization format
... structured clones can include certain data types beyond
JSON
... such as images and files

mw: used for local storage, and
others

avk: used also in post
message
... waiting until file API to add file upload
... also waiting to append file blobs
... browser would send multipart form-data when you do
send
... similar to raw html forms no
... if we can support this API then we don't need a FileList in
the API
... could be Jeremy Orlow
... append files or strings on formdata object

so that we don't need a method on XHR

avk: its been requested to
serialize an html form and pass it to XHR
... so you can asynchronously upload it
... others requested - blob
... WebKit supports FileList

ar: File is supported in
Mozilla

sw: WebKit also supports a single
File

jonas: do you send the file name
anywhere?

avk: no

sw: no

avk: how would you?

jonas: use some kind of
header

avk: authors can add a
headers

sw: we don't

arun: send a blob and a
hypothetical object

avk: send would be extended to
accept Blob and FormData

<arun> where FormData =
hypothetical object

avk: For FormData, the UA would
set the content-type header if the author did not set it

arun: Is Hixie writing
FormData?

avk: No I will do it - a small
edit

arun: FormData append would
accept a Blob?

avk: It would
... It seems that this would address several requests

arun: It seems to - a requirement
that was not adequately addressed by FileAPI

avk: MS has a proprietary
extension exposed to VBScript called ResponseBody that returns
a byte array or byte stream
... we could use it or rename it to ResponseBlob
... Unless MS cares for it

adrian: we would like to carry on
using it

mjs: It should not be a blob, but
rather a byte array
... Blob offers only async, and if the data is already loaded
then array is better
... should not do another async

jonas: only thing is if you are
loading a big thing, then ua will be forced to keep it in
memory

mjs: if loading something bigger
than address space, then store it

jonas: not looking for large
streams

mjs: ideally ua should download
large files through streaming model
... assuming its a file object stream to a file

avk: and then access the
file
... responseText already loads in to memory

mjs: turn off storing in memory
if its large

avk: need ECMA to figure out a
binary type array
... should not be that hard - like image data

mjs: easy to make
complicated
... if its immutable, then it is easy to use the raw bytes as
backing store
... no thread safety issue even if passed to workers
... immutable is harder to modify
... most APIs make two versions of APIs available - mutable and
not

avk: ImageData is immutable

mjs: backing store is canvas

jonas: byte array building API
might be a good way to mutate ResponseBlob
... look forward to mjs' proposal

avk: response thing and new
things for sending out are new items
... timeout proposal is also new
... ontimeout listener for milliseconds timeout
... if the server doesn't respond, then do the abort thing and
dispatch timeout event
... timeout needs to be sorted out

jonas: almost everyone using XHR
uses it anyway, so provide a convenience function
... MS added it to XDR?

adrian: yes

sam: is it a default or an
attribute?

adrian: attribute

avk: what does it do on
getting?

jonas: its a set only

avk: does such a thing exist?

travis: doing a quick test

jonas: what's a good default
value

travis: or do you timeout at
all

adrian: if not set, it
doesn't
... so the behavior is not changed
... XHR also has the like named attribute

jonas: very inclined to add the
attribute to XHR2 spec

sam: concern - putting in the
hands of the user, what is the stall for the ua?
... 10 ms is OK or 100 is OK?
... in the past any amount was OK

<Travis> Reading IE's timeout
property (before setting) returns -1.

avk: testing in different
conditions, like a slow network, may find odd behavior but the
other person in a good one doesn't

adrian: common use cases are
sites doing click tracking, trying to capture when someone
clicked a link
... OK with losing data when a request is not fired in the
timeout
... here's a request to make and if the request doesn't respond
we give up

avk: better option available -
html5 ping attribute

adrian: there are other issues
being raised, that make the option controversial and this WG is
not the right forum to discuss

avk: not opposed to adding it,
concerned that it will be abused

jonas: in what way?

avk: use sync more

jonas: what will help most is a
test suite guide
... go through the spec and not follow it closely, although
well followed,
... edge cases are where we differ, otherwise everyone is
close

avk: but that makes it look
pretty broken

jonas: not material adding new
features to newer versions to getting bugs fixed

avk: explicit constructor for XO
requests

jonas: that conversation is sort
of CORS-existential one

avk: agreed

jonas: interesting idea to have a
totally anonymous XHR object, both for X-S and S-S request

travis: which is XDR

jonas: but that sends Origin

avk: proposed resolution on
timeouts for XHR2
... to add

nikunj: would we do it to
file?

jonas: not required to follow a
single style in general
... hesitant to draw a connection?

adrian: a case to be made for XHR
things to be repeated elsewhere
... timeout is not one of those things
... network requests cause timeouts to matter
... it seems less likely to need them for files

jonas: much less likely for a
file request to time out

sam: network files time out

adrian: edge case

avk: also need resolution on
FormData

jonas: iffy about that
... seems weird to create a new object for creating an object
only to send to another one

avk: not ugly, can reuse it

sam: websockets may also want to
do it

jonas: really?

everyone: laughing loud

chaals: consensus?

sam: I don't object, not
excited

jonas: it helps to abort a
connection if it takes too long

sam: agreed, but not a strong
enough reason because that might be only one of the ways to do
it

jonas: could use setTimeout
... risk that people may use sync XHR more
... we fired timeouts during syncXHR
... fallback was to wait longer
... not ideal
... some people may never switch away from sync XHR?

adrian: we shipped timeouts
... good idea

chaals: any objections?

sam: risks in either
direction

adrian: also supported for sync
XHR

RESOLUTION: Anne to
put timeout attribute in XHR

avk: Proposal to overload send
for Blob objects
... FormData contains a constructor and accepts either Blob or
DOMString

which serializes as multipart/form-data

sam: support strongly Send Blob
with File
... other one need to see a proposal and remove it if that
looks terrible

RESOLUTION: Copy
and paste this into the proposal on FormData and
Blobs

jonas: like to implement
streaming
... loading something means you are adding something constantly
to the DOMString, using exponential memory. Having some way
where you can store data to the file object or a way to erase
the differential read since last event. Impl can throw the rest
of the data away

avk: can we use server sent
events?

jonas: this is not for that, but
for large files
... its started from server sent events, but different

avk: use cases are required

chaals: good proposal not quite a
finished
... need a meatier proposal

jonas: would do

chaals: how far from XHR?

avk: ask jonas, sam, and
adrian
... if everyone finishes implementation, then we are done

jonas: start writing test
cases

adrian: take it first to LC, then
the test suites will happen before CR

SW: don't know of any specs that
use it. Maybe NodeList could be expressed as an Array
... might not be worth putting Array in v1 if no one is using
it

<annevk> hmm, I think
sequence<> needs to map to an object that has item() and
length; is that the case?

TL: TC-39 is taking interest

<annevk> well, it would be
nice to have a shorthand for NodeList like interfaces

<annevk> not sure if it needs
to be sequence<>

TL: I expressed it to them as an
grammar language, and a binding language
... they took a lot interest in the binding part
... TC-39 expressed interest in owning the JS bindings,
claiming they had more expertize

SW: I think the main value of
webidl is the bindings, not so much the grammar

TL: agreed

AvK: also value for spec
authors

SW: concerned about splitting out
bindings

TL: then they should be able to
participate

SW: most definitely

DS: I'm also concerned about
splitting it. Splitting things in two leads to overhead and
poor coordination... I would be happy to have it worked on
jointly, if we can do that, and public-script-coord should
help

SW: there are things we could
split, like deprecated features

annevk, that's how I roll

MJS: even such a split is
concerning. Similar to how ecmascript leaves host objects
largely undefined

SW: agreed

MJS: explicitly noting that
certain things are deprecated could still be done

TL: do we know what we want to
mark as deprecated

SW: custom deleters

MJS: also catch-alls in
general
... not neccesarily consencus that catchalls are always
bad
... separately, seems to be consensus that array-like accessors
are ok

AvK: what does "deprecated" even
mean?

SW: that a feature shouldn't be
used in new interfaces, but is described for legacy reasons

TL: there is a desire from TC-39:
don't allow bindings to do things that aren't allowed by
ecmascript itself
... want to be able to implement DOM in ecmascript

MJS: if you look at it as a
two-sided converging then it makes sense. I.e. add features to
ES to allow it to do more, and deprecate features from webidl
that ES can't do

TL: want to mark things that will
*never* be part of ES as deprecated

SW: how to we determine what will
never be part of ES?

MJS: It's very hard. Not even
catchalls are for sure never going to be a part of ES

CM: guessing the future is
hard

DS: when do we expect webidl to
progress to LC and beyond
... and all those other fuzzy W3C rules

SW: depends on what people want
from spec
... it's really a tool for spec authors

MJS: changing the spec to use ES5
formalisms is a big change

TL: ES5 has accessors, rewriting
to use those will take work

DS: Robin wanted to publish
sooner rather than later

MJS: there's tradeoffs, there's
many specs that want to use it

SW: I'm not all that familiar
with W3C rules quite yet

DS: This is an unusual spec
... the implementations for this spec are other specs

SW: Also testcases. You can
produce a lot of tests based only on the idl
... Want a tool that given an idl produces tests
... browsers are also implementors

DS: sort of circular dependency.
Won't know that things worked until another spec has used
webidl and that spec got implemented

MJS: we could take a stable spec,
such as DOM Core, and express it using webidl

DS: Cameron did that

SW: would come close, but doesn't
test everything. Might also want to do for example canvas to
test overloading

MJS: should start with dom core
and see what coverage that gets us. But yes, canvas would cover
a lot of nice things

RE: has anyone does a matematical analysis of
webidl? Would that be useful?

SW: don't know. If anyone has
done it, cameron has, he loves math. But don't think he
has
... OMG doesn't define enough things. That's why specs had
bindings sections. But even those aren't enough, and might not
be normative
... changing spec to use ES5 terminology will be a big change,
but not a functional change

NM: is it a requirement for going
to last call

AvK: doesn't make sense to define
things in terms of ES3 if everyone implements ES5

DS: when you make that change,
document how you map old terminology to ES5 terminology

SW: good idea
... not sure about some features in the spec. One is method
overloading

TL: we have default values for
optional arguments
... we use it for XHR

SW: when i started on webkit, we
had hand-written code that implemented the bindings. We still
have a custom IDL

MJS: we currently have one-offs
for all overloads. Would like to use webidl to express and
implement it instead

JS: not sure we can use idl with
overloads directly

MJS: you can use whatever
solution you're currently using
... webidl has optional. Limited by that each argument is
optional. Can't enforce that either 0 or 2 arguments are
provided
... if optional could be in batches, then you could require
that the other arguments must differ in type

JS: errors seem to be
ambigious

MJS: one problem is that anything
that takes a string essentially accepts anything since anything
can be converted to string

VK: one problem is a function
that takes a two ints, or an int and a string. If called with
just one int what do you do?

TL: i think action should be to
clarify the spec and then we can discuss what we want behavior
to be

MJS: in theory you can let the
function just take a bunch of optional "any" arguments, and
describe in prose what's required. However that's likely more
confusing for everyone

JS: I think TC-39 will have
strong opinions on this. I know mark miller did

MJS: not sure i understand MMs
objection
... one issue is that overloads allows overloads to be added in
[supplemental] interfaces. Would not match ES5
implementations

SW: we could forbid overloading
in supplementals
... discussions about XHR...
... if we're gonna do union types then we should consider what
tradeoffs we'd making. I.e. which group are we helping at the
cost of another group
... i'd also like to know how you reference one of the specific
overloads

TL: philosophical argument. Do
you think of it as a single function that can take different
things, or is it separate functions that happen to have the
same name
... problem is that we have a spec that's hard to understand.
Using union types might make it easier for people to understand
it

CM: would like to wrap up

darobin, no union types for you!

SW: we need to figure out
replaceable

TL: I'm also concerned about
mixin's
... TC-39 would like to deprecate callable objects

JS: gecko only has a single
object that's callable, the document.all object

SW: would like to remove
getters/setters without name

TL: remove it

MJS: from javascripts point of
view it doesn't have a behavioural difference

CM: proposed resolution: nuke
it

DS: remove it but put a note that
you did so, so that people can whine

AP: this results in a surrugate
pair being the value
... this problem didn't exist with the old "U+1234" syntax

JS: is this a problem?

AP: it means to get the actual
character value you might need to decode the surrogate pair

(i follow standards)

AP: there are lots of surrogate
characters
... and more with time

DS: maciej wasn't sure that there
are keys that result in a non BMP character
... however there appears there are
... characters "tree stub" and "untidy" are such characters

<mjs> my old suggestion of
"\u1234" was meant to suggest the values should be a string of
the actual character

<mjs> so for example the
identifier when you press lowercase a would be the string
"a"

IH: for people that compare with
a string, then the fact that it's a surrogate pair then this
isn't a problem

DS: complicated in some
situations

IH: when?

DS: when people use lots of
supplementary characters in the script. Maybe

JS: can someone show code that
they are concerned about won't work
... confusion about what is actually suggested...

<chaals> [Do you get "U+1234"
or "æ" or "\u1234" and is there any reason to distinguish the
second and third cases?]

<chaals> Scribe: chaals

RI: You take a character outside
BMP, and your javascript escape is "\1234\5678"

PA: The string that is the
individual character is length 2

<sicking> RI: why move away
from the "U+1234" format?

<sicking> DS: if i'm trying
to limit a form to just one character, i might reject surrogate
pair characters

Sicking: We should go with the
native format for the language. Unfortunately javascript has a
nasty way of dealing with characters outside the BMP. If we
give them in other forms tey will just convert and then go on
anyway. SO trying to work around the behaviour of the language
will frustrate people

<inserted> scribenick:
sicking

JS: my concern is that we're
trying to work around behavior in ES

AP: i just want people to know
what the ramifications are, and that we make it clear in
spec

RE: when pressing "e", i'll get an "e", but if
I press "treestub", i'll get "U+1234". That seems to make i18n
harder

RE: for keys like "F1" we can use a different
field

AvK: the way javascript deals
with i18n should be an orthogonal issue

AP: we should follow the way that
javascript deals with i18n
... even if that isn't perfect

RI: i want to know how this is
expected to be used
... if you just want a label for what was pressed then "U+1234"
syntax seems better
... so trying to understand what the use cases and expected
uses are

DS: comparisons often

<chaals> JS: If the
characters are described as double-escaped bytes, you can still
do comparison with them

<Hixie> '\uFFFF' <
'\u10FFF' => false

<chaals> JS: Does any use
case run up against that painful gap in practice?

DS: range checks might also be
common

TL: in all the cases we describe
now it seems workable to use the current proposal (i.e. the
"treestub" proposal rather than "U+1234"). Would it be ok to go
forward with that and describe how to do the various use
cases

<chaals> IH: I think we are
fine because I don't think we will meet the boundary case

IH: in fact, the "U+1234" syntax
compares even worse for range checks

AvK: I don't think we should try
to work around ES problems

AP: you can maintain that ES is
broken. But what you're doing is developing a key events spec.
I don't see a problem with returning the character that was
pressed.
... if you tie yourself to UTF16, then that could be a
problem.

AI: if i have a ascii page, how
would i use this

AvK: the spec would simply say,
U+1234, without quotes
... that's what other specs do

DS: i was confused, but now i can
see

IH: WebIDL will handle it

DS: will that be clear for
authors

IH: should have a separate
section that describes things for authors. You probably want
that anyway

RESOLUTION: The
return value will be a DOMstring which is the character
produced. We add a note explaining to authors what
happens

<trackbot> Created ACTION-440
- Add clarification for authors of JS where the gotchas are [on
Doug Schepers - due 2009-11-10].

<shepazu> these are unicode
scalar values

<chaals> RATIONALE: WebIDL
makes sure that this comes back in the relevant form for
whatever language you are using

<Hixie> to aid developers we
probably need to make the non-character values (like "F1") be
not length-2

<Hixie> e.g. "[F1]" or "*F1"
or "F-1" or "Function1" or something

<chaals> NL: when I do 秀, how
many events are there?

<chaals> [it took me about a
dozen key presses to make that character]

DS: when you have IME, you have
there's a bunch of composition events'n'stuff
... the whole things is very complicated. Might be best for
people to review the spec

AP: when should we review

CM: over lunch

DS: the sooner the better
... spec should be pretty stable now. Especially with this
latest resolution

<Zakim> annevk, you wanted to
suggest we declare conversion methods out of scope

AvK: I propose we drop the
conversion methods

DS: i would like to keep
them
... we want people to deal with characters, so I think it's in
scope

AvK: ES needs to solve it in a
larger scope

SW: I think the right place to
put it is on the ES String constructor, other languages have it
there
... there are docs on the web that shows how to take a
multibyte character and turn it into a numerical codepoint

CM: as a browser implementor, i
don't see why i should look at a key events spec to see that i
should build conversion functions for strings, or how to do
it
... who would rather move it to ecmascript
... straw poll is taken...

<chaals> [Shepazu objects, no
resolution]

DS: Hixie had requested that some
events be defined in much greater detail, or be removed from
the DOM L3 Events spec

AvK: I can represent hixie
... Problem is that it's very fuzzily defined when certain
events are dispatched

TL: it's not expected that DOM
Events define exactly when the events are fired
... and that the hosting language should define that
... this was also raised with progress events yesterday
... resolution was to define what the event looks like, but let
hosting specs define when they are fired

AvK: mouse events for example can
be just generic events. Don't need to be in DOM Events spec

DS: if there's a risk that hixie
will raise objections, then i'd rather adress the issue sooner
than later

<chaals> JS: Think what we
did with Progress events makes sense - this spec defines what
these things look like more or less, and the individual specs
define how they fit in various specs in detail.

JS: can we leave it explicitly
undefined when certain events are fired, and just define what
the event looks like when fired. And then leave that to hosting
specs to define when to fire events

oh, thanks chaals

JS: though i don't know who would
define mouse events since they seem cross language

AvK: possibly CSSOM could define
mouse events

<annevk> CSSOM View

CM: sounds like a
meta-discussion. Would like to see specific proposals

SW: DOM Events seem like the
wrong place to define when mouse events are fired since it
involves hit testing
... some other spec or specs could define hit testing

CM: still sounds very meta to
me

RESOLUTION:
convertKeyValue will be removed from DOM L3 Events

<chaals> closing
ISSUE-110

if you can't follow that part of this
transcript, I don't blame you

<chaals> in recess

<annevk> (after further
consideration DS withdraw his objection)

<annevk> close ISSUE-110

<trackbot> ISSUE-110 Should
we remove the code-point conversion from the D3E spec?
closed

<Hixie> i'm in i18n but i'd
like to attend the database stuff

<Hixie> so i'll be down when
i can

<chaals> ok. we start at
13.30

<Hixie> just call me Hixie
:-)

<Hixie> or you can call him
the Other Ian

<Hixie> either works :-P

<Dashiva> IIan

<chaals> ageenda+ different
storage systems

<Hixie> i can answer
questions, not sure i have much to say though

<Hixie> i'm happy to have a
quick q&a

<chaals> ok, we'll see if
people have questions and schedule some time if so.

<timeless> ScribeNick:
timeless

<chaals> pablo, did you get
the code?

<scribe> Scribe: timeless

<pcastro> yes, thanks, will
call in in a minute

different storage systems

<arun> pcastro, are you on
the phone as well?

Web DB (sqlite)

Multiple storage systems

chaals: We have a lot of these.
how many are in conflict. how many are competing

<Hixie> IH: none and all
respectively

sicking: Web DB and Web SimpleDB
are competing
... whatever we come up with for Web DB / Web Simple DB will
replace a lot of localStorage

IanF: Are people trying to throw
localStorage out the window or discourage it?

sicking: the way things are
going, localStorage is going to be racy
... even storing the numbers between 1 and 2, you should
probably not use it

chaals: at opera, we implemented
web db
... we looked at web simple db. we found the nikunj one and
simple

<arun> Web DB = The SQLite
One

<arun> WebSimpleDB = The
Nikunj One

chaals: we found Nikunj to be
more to our liking

<pcastro> arun: yes i'm on
the phone as well, trying to follow

chaals: we have implemented WebDB
internally

sicking: we don't have a data
point
... we've had a lot of discussions, primarily with MS and
Oracle
... Oracle stands behind Nikunj
... we've talked to a lot of developers
... the feedback we got is that we really don't want SQL

IanF: We've implemented
WebDB
... we're about to ship it

MJS: We've implemented WebDB and
have been shipping it for some time
... it's shipping in Safari

<annevk> IanF: we're also
interested in the Nikunj One

MJS: the Chrome implementation
shares some but not quite all of the code
... beside shipping it, web sites have versions that target the
iPhone and use it
... we can't easily drop it in the near future for that
reason
... In principal, having a storage mechanism that is more sound
than localStorage
... but more simple than WebDB would be good
... wrt localStorage, the current bits indeed have race
conditions
... but adding APIs could possibly fix it
... SimpleDB / WebDB is probably impossible because of <too
much something>

jorlow: a large percentage of a
lot of the web apps that google is looking at
... would need a large percentage of what is in SimpleDB
... in order to make an extended localStorage usable
... it would be fine to make localStorage do it, but it would
require a lot of SimpleDB

MJS: [lost]

We can make simpleDB do everything
localstorage does

Nikunj: (to MJS) do you want to
keep the API as is or the functionality as is
... the localStorage API is synchronous only

MJS: you would need to do a
superset in order to handle locking

jorlow: Google is not happy with
the various proposals

AB: Microsoft's position is that
WebSimpleDB is what we'd like to see
... we don't think we'll reasonably be able to ship an
interoperable version of WebDB
... trying to arrive at an interoperable version of SQL will be
too hard
... what people want is a ...
... we think that WebDB (?) features is a starting point
... we don't plan to add to localStorage

sicking: the problem with it is
the raciness
... no one working on a multi process browser has safely
handled this

chaals: we're out of time.
... there's a lot of push for Nikunj
... where does that leave WebDB?
... Apple can't stop shipping it
... Google will be shipping it
... Opera has not yet shipped it
... but it's likely we will as people have built on it

sicking: I don't think mozilla
plans to ship it

DS: you could do the same things
with Nikunj as with localStorage
... except storage events

PC: the difference is...
... you get the ability to have a lot more data in it
... in a much more organized way

<annevk> (there's also
sessionStorage, fwiw)

PC: you don't need to learn
another language to get data in/out

chaals: i don't see a
conclusion

sicking: I don't have any plans
to review WebDB

IH: I'd rather not spec WebDB if
people don't want to ship it

DS: I was talking with w3c people
about the confusion
... there are several web storage proposals, and we think that
it clutters developer mind space

IanF: I don't think people are in
disagreement that it's sad
... it's a bit too late

WebDB - sql lite

IanF: let's look at something
else, but let's move on

cwilson: I don't know if anyone
has suggested on the group of killing off WebDB on the list

DS: except the editor

[ laughs of agreement ]

MJS: it sounds like there will be
multiple shipping implementations

cwilson: it seems with multiple
interoperable implementations
... that you can't really call it stillborn

<ifette> s/q+

cwilson: when we started looking
at WebDB
... the reason we liked Nikunj was that it doesn't impose
... but it has the power
... the part that concerned us with WebDB is that it
presupposes SQLite
... we're not really sure

IanF: i don't think anyone
disagrees
... I haven't heard anyone say they don't like Nikunj , i've
heard a lot of interest in it

IH: Proposal
... all the browsers shipping WebDB are WebKit based
... proposal: we move WebDB to WebKit.org, and we kill it as a
deliverable from this group

chaals: I think we're likely to
ship it

IH: I don't want to work on a
spec without 5/5 impls

DS: Is it possible to take what
is speced in WebDB, freeze it,
... take the interface layer, and stick it onto Nikunj ?

[all] : No.

arun: suppose the freezing part
was taken seriously
... is that sufficient, or is there more spec needed to be
written?

IH: well, there's the SQL
part
... we could say that the SQL part is SQLite 3's dialect

<ifette> sam: spoke

Sam: Apple and Google have
expressed an interest in added full text search to the api
we've used

jorlow: that's extremely
important to Google too

[ audience squirmed relating to some
Xsomething api]

IH: most of the people are asking
me to spec Nikunj (?)

chaals: moving along
... proposal: WebDB remains as a deliverable
... we ask IH to do the minimal level to satisfy the
implementors

RESOLUTION:
[above]

<ifette> RESOLUTION: hixie
does minimal work to get this to a point the shipping browsers
are happy with, if he goes nuts we will put up resources to
finish it

WebSimpleDB

chaals: do we really want to talk
about filesystem?

arun: no

ifette: no, except to remember it
exists

<chaals> zakim drop agendum
5

Web Simple (Nikunj) DB (nikunj)

chaals: ack Nikunj

[ Nikunj asks for projection ]

[ chaals asks for intros from lurkers ]

Donald from ETH Zurich

Donald: We've implemented XQuery
that runs in IE and FF, and hopefully soon in
Chrome/Opera/Safari

Ghislain a student of Donald

Dana from Oracle

HTML working group chair

Satoshi

Gondo from Toshiba

Nikunj: there's a new draft,
taking input from others and feedback from the mailing list

<chaals> Magnus, Ericsson

Nikunj: there are some use cases
we don't cover
... JS might want to do boolean expression evaluation
... the language for the expression isn't important
... but the necessary bits to efficiently implement this
... being able to store keys, iterate over keys in the index,
operate over multiple keys at the same time
... I plan to add appendices to help with this (?)
... before the next working draft
... there are some open questions that i haven't addressed in
this spec
... i'd like to lay out things to get feedback for alternate
suggestions
... first, key types
... string/number
... the are fancier things that could be done, supporting
structured clone as a key value

<chaals> [functions that
evaluate to a value can be a key, too]

Nikunj: there are various ways to
make it fancier
... there are multiple ways to address this
... there are three ways to do indexing
... 1. no indexing, the application manages the index
manually
... 2. the index only knows about the store, but the useragent
doesn't maintain that index
... it is only used by the application to look up things
through the index
... 3. in addition to 2, the useragent actually maintains the
index
... option 1 is supported
... option 3 is supported with constraints on the key
path
... option 2 is not supported
... option 3 is a simpler api but more complex
implementation
... there's a contention between reducing the footprint of the
api v. the footprint of the implementation
... there are tradeoffs across different engines
... i've tried to capture an implementation neutral api
... i'm requesting feedback to be categorized, api v.
footprint
... i've received feedback on concurrency
... there are two models for concurrency
... optimistic and pessimistic
... i've tried to avoid mandating an implementation
... implementations will choose based on their needs
... optimistic is better for high performance
... pessimistic is simpler
... in the spec, i've tried to identify conditions that can
offer deadlock free behavior
... i believe the main concern, is that the average user will
not be very good at recovering from
... deadlocks or optimistic concurrency failure
... the approach i've taken is to specify a behavior that is
deadlock free
... and specify two levels of granularity that
... at the database, or an object store

Nikunj: let me start writing it
in an appendix, and then we can move it to another document
later

<Zakim> ifette, you wanted to
ask question aboujt indicies

<ifette> \

Nikunj: two levels of deadlock
free concurrency
... comparing with WebDB
... where we only do database level concurrency

<chaals> scribe: Chaals

Nikunj: and object store
level
... main point is that people have asked for even more
concurrency where possible.
... optimistic concurrency control and management, but there is
a risk of failiures in concurrency management that exposes
programmer to requiring recovery
... proposal is to allow that to programmers through existing
API knowing that can lead to exceptions that need recover
... could be left out, would be easy to implement in any DB
that allows that leel of concurrency. Question for the working
group (and whether people like it)
... Propose to leave it in, as an appendix outside the basic
part so people don't stumble.

IF: Wanted to jump back to
indices. What do the 3 options mean for an app developer with a
lot of data
... assume 20GB database of integers. Which option gives me a
Btree in the user agent, instead of in JS

NM: The btree is in the user
agent. you only pull out the data you are looking to
consume.
... to find out which pieces of data match the two conditions,
you have to do the join yourself.
... People feel that a user agent implementation of that might
be too rigid, and doing it in the app will be almost as
performant.
... Limiting the amount of data you pull out will be easier for
the app than the UA to get right - but this is open to
feedback

IF: Scares me but I need to go
back and get more detail.
... What base index types do you expect all UAs to support?

NM: Use case for me is a boolean
index exression evaluation. Another use case is keyword and
context - fulltext.
... you could create keword/context index, but will not perform
as well as done natively.
... We can include that but it isn't included in the current
draft - or we could put it in a v2. There is also hashindex
which is not specced - we just have btree.

IF: To use this for gmail we have
to be able to do fulltext and we don't think we can do that
performant in JS so we would like native code to do that.
... For v1

NM: In some discussions we can
provide keyword/context, but fulltext incoroprates some more
concepts that can get hairy in different languages. It should
perform aequately with a qiuck index.
... fulltext is probably a bigger spec than websimpleDB.

[clarification of fulltext vs
keyword/context]

IF: If we had a quick index that
might suffice... let's come back

JS: The issue I found most
controversial internally has been the concurrency issue

[ed. Jonas said the unfancy word :P]

JS: In general we aim to avoid
race conditions and deadlocks. sql api uses a simple lock -
touch it once and everything locks until you leave it - no risk
but performance issues.
... I have argued that there are a range of solutions between
the extremes, where we can lock fine-grained without having the
risks. Should we try to find such a solution or say people who
use this need to be smart enough to deal with such lock/race
conditions.

NM: Share your concerns in
dumping deadlock recovery on programmer. THink spec as written
now has more concurrency than usual - offers a model where
readers don't block writers so long as they are not on the same
bit.
... If application doesn't want to choose, we do the safe
thing. If they want to choose they can have deadlock-free
concurrency. Open to hearing of such mechanisms we can offer,
and found 3

IF: 3 options are all guaranteed
to be dealock-free. Is that a hard requirement or could we
offer low-level locking ???

NM: That is possible and is
supported in the spec but doesn't mean that we have to have it.
Have been warned that optional behaviours don't get implemented
or cause introperability problems.

JS: There had been an idea of
allowing a fallback to a locking model, but optional features
generally lead to a race to the bottom. Think we should mandate
that all locking mechanisms are required.

NM: Yes you can add levels of
granularity as well as deadlock free mechanisms

<Zakim> jorlow, you wanted to
full text indexes

JO: Question about joins - sounds
like you took them out to keep the implementation simpler

NM: And keep the API smaller

JO: Main concern was implementing
joins in Javascript.

NM: Spec was originally written
on berkeleyDB which had no way to retrieve object based on key
index. had a way to join dbs but we added a way to lookup an
object from the index and treating the indices, and use of
joins dropped.

JO: So if you have two large
parts of the DB with small verlap, doing that in JS is going to
be inefficient.

IF: Fulltext is an example - like
that.

JO: In Gmail example, if you are
searching for a to and from address you might have zillions of
addresses so it might be a big burden on the system

NM: there is no expectation in
the set that an entire dataset has to go into memory. because
itis btree the two indices are sortedin the same order so it
reduces the amount you need to work over.

JO: If you have 10k items, that's
heavy

NM: Marshalling cost is high

IF: When using the same index
repeatedly, how complex?

NM: if needed it would be an
extrsa feature in the spec

SW: concrete question - a person
coming from SQL API - how different is the code they have to
write, what is the conversion

NM: A user programming against
the API?

SW: Sure

NM: In use cases, we don't expect
people to program against the spec, but use JS libraries. But
we want to make it possible to program against directly.
... if you are using a mapping laer here there will be no real
difference

SW: Is there precedence for
adding a new API mostly for middleware?

Timeless: We added a lot of stuff
to libraries against APIs

AR: It is wise to look at this
API to make simple things simple, but look at allowing
libraries to straddle it.

SW: Not sure that this is simpler
for a simple query, which is the basic use case for a DB

AR: Not sure how much more
simpler it will be to use SQL

<ifette> jonas: most people
use XHR via libraries

JS: XHR is generally used through
libraires - there are direct usage but a lot of Dojo. The other
one is the WebGL, that is meant to be used like that

SW: remains to be seen for
WebGL

AR: Think XHR is a good answer
for Sam's question.

SW: Would like to see simple
examples converted and how easy they are

NM: Those are already in the
front of the spec.

JS: Depends heavily on the SQL
string that you are passing in. Lots of X-table joins will be
harder, looking up simple table stuff is just as simple.

IF: In terms of the world,
Mozilla won't implement WebDB, and we want to get Gmail working
with a DB and there are others who want to get apps working.
Plus or minus some detail, it seems Web Simple Database can do
taht
... I can make my app work with this probably.

AR: Would like to see libraries
that straddle this

DataCache

SW: It would be nice to see a
performance analysis

NM: Yes, we need implementation
experience to do that.
... Bulk of feedback on data caching / http interception seems
like appcache but it uses different terminology.
... people didn't know what they would need to make it
happen.
... Working draft published last week uses same mechanisms as
appcache to describe it. Not identical. The model by which
application ahs access to the cache is similar. There are a few
differences
... appcache doesn't take full headers into account, data cache
does
... When first adding something to the datacache the value was
in a cookie and the ambient auth is matched against the cookie
value without the app specifying stuff for offline auth.
... works as expected for online auth. Means there is ont just
one datacache - ther are different cookies that authorise
different things in the same origin, so different caches.

MM: Browser has several forms of
auth. reason to check cookies seem to apply to http auth as
well.

NM: Yes, that is very valid. In
this ersion we are only dfoing cookie, but no reason why it has
to be that way.
... Since synch is app-controlled there are difference to
appcache. timing is different - has to happen when the app
kicks in. 2nd, data items to be fetched have to be
identified.

see example 4.1.1 in datacache draft

<jorlow> chaals: I can do it
on list

scribe: roughly equivalent to
what you do in app cache. app cache doesn't provide direct
access, but data cache needs that to decide what further stuff
gets synched. Ususally happens in a long-running single
transaction. API provides a way to control synch, or do offline
transactions - instead of doing capture by a URI alone you can
do offline transaction specifying URI and the bits representing
the URI that could be used later in a request made by

the app.

scribe: Understand this raises
concerns and we should discuss. As well as GET and HEAD you can
use PUT POST or DELETE where there is an interceptor registered
on the navigator object similar to protocol handlers.

MJS: You mentioned feedback was
about relation of this to appcache. (I gave some) looking at
the draft it looks like at least two of my most important
points are not addressed. If I ahve both appcache and
datacache, how do they intersect. Your spec doesn't decsribe
taht. Would prefer a single API with union of capabilities.

second CORS

<arun> scribenick: arun

mjs: [May present a short slide
show]

<annevk> hmm, no adam :/

+JeffHodges

<chaals> Jeff Hodges,
Paypal

mjs: Gives a presentation on CORS
that he commits to putting online soon.

mjs: [In the common case, where
you're logged in, and permission is granted, diagram
illustrates CORS]

TC: There's an implicit trust
relationship between the Events site and the Calendar
site.
... The party that could be attacked here -- the Calendar (via
confused deputy) -- could be attacked by Event page. Event page
(Server B) can trigger an inadvertent action on Server A (the
Calendar site)

TLR: Turn Server A into an
AtomPub server. You want to create a resource, you get the
identifier for the resource returned. resource on Site B uses
AtomPub to do something on Server A
... B, the event Page, creates a resource on A. B does not know
in advance what the URI of the event would be. A returns a URI.
B could inadvertently phone home to A and create [error
condition]

MJS: If Server A only responded
with the path part of the URI, there would be no such
vulnerability.

TC: But this may also eliminate
valid use cases!

MM: Let's contrast this with the
same scenario, where you're using a per-resource secret token,
along with the designator. In that case, access is allowed
based on presented authorizing info. When you go to AtomPub
service....

TC: when this slide was
presented, he asserted there was no confused deputy possible in
this scenario. But with little effort, I created a confused
deputy here.

<Hixie> ...by introducing a
new protocol that has a vulnerability

MJS: [slide show continues]
... Server M can't forge Origin in browser, combination of
cookie + Origin identifies request as valid
... Fancier scenarios can have confused deputy. Site A asking
Site B to do something on Site C
... Can also have confused deputy problems without CORS. For
example poorly implemented secret tokens.
... [Diagrams this on paper]
... [ Draws sites A, B, C]
... illustrates a scenario where B,and C have an understanding
with shared tokens.
... It's an isomorphic problem. A only tells B a resource to
act on. B then talks to C. This creates a vulnerability since
what A asks B might not be what B is expecting to do.

TC: THe thing that makes CSRF
prevalent is that the two initial messages between B and C
happen implicitly and automatically.

MJS: CSRF is different. I am
simplifying here by considering only servers.
... With CORS, in my simple scenario, doing the dumbest
possible thing will be safe.

JS: The simplest way to do
authorization on the web today is to use cookies; ergo CSRF
problems common

MJS: Here is my claim on how to
avoid confused deputy problems: don't be a deputy! If you
follow this discipline, purely local to your server, you will
not have a confused deputy problem.

MM: But you will also have a lack
of composability amongst servers!
... I think there might be the issue of "on behalf of." In
Tyler's scenario, the "on behalf of " is not that Tyler made a
request on behalf of the deputy.

MJS: That has to count as on
behalf of.

TC: This means that whenever you
send in a request, you have to make sure it doesn't include
data you got from anyone else.

MJS: It means that if it does, it
is distinguishable from any data from that particular
server.

IH: Or you make sure sanitization
takes place (a la SQL injection)

TLR: If you want to sanitize,
then you must know what the consumer might possibly trigger

MJS: This is not only in your
user agent; it must be programmed in server software.
... You cannot send your shared secret to the client.

MM: This is per request?

MJS: It doesn't have to be per
request. The protocol allows token to be valid for e.g. 1
hour.
... [discusses OAuth; ] Request token is combined with a
particular user; get an authorization token from Site B
(combination of particular user, etc.). Event page has to
redirect, etc.
... [Continues discussion of OAuth] Redirects are part of the
model.

CMN: This is the model used by
"Verfied by Visa" right?
... If this is the same basic schema used by Visa and
MasterCard, then that gives you proof that the (OAuth) model is
used and in circulation.

MJS: I would not claim it is
impossible to implement.
... But it might be hard for the casual site developer.

AR: [Points out that we did this
to improve the world]

TLR: Two frames, + postMessage.
Wouldn't that address this problem?

MJS: So a frame (content that's
meant to be loaded in an iFrame) is a cross-site data API. If
you use it in the kind of way that Tyler Close identified, it
would also have the same Confused Deputy Vulnerability..
... Additionally, it needs client side scripts making requests
to the API.

TLR: The distinction is that
client side code checking origin occurs on the client, as
opposed to the server.

MJS: Our worry is not about
people making the origin check, but in drawing the wrong
conclusion about the implications of the Origin check.

<Hixie> IH: You can have a
dedicated API with a server-provided API or a JS
API

<trackbot> Created ACTION-441
- Respond to Maciej about how to use appcache and data cache
together on a client, and whether there can be an API which is
the union of appcache and datacache [on Nikunj Mehta - due
2009-11-11].

MM: I want to make the proposal
that the GuestXHR proposal can meet all requirements.
Requirements: grant permission once, no manual steps to copy
data between sites, AJAX UI, no server to server, no need for
prior bilateral agreement between servers.

MJS: I'd like to analyze this
like we've analyzed CORS

TC: I'd like to show you a
solution that is more secure, and doesn't use an Origin header,
would that satisfy your concerns?

MJS: I'm interested in seeing
solutions that satisfy the requirement that doesn't introduce
protocol complexities, etc., and I'm interested in
understanding that given that some browsers ship CORS, I'd like
to understand whether the compatibility issues are worth
it.

CMN: I am concerned that we don't
work in vacuums, we work in places where people have products.
I am generally concerned in standards work about shifting goal
posts. One more example, one more thing... I understand that
you might feel that way. Such is the lay of the standards land.
I would like to see
... .... a worked example.

<trackbot> Created ACTION-442
- Make a worked example of how e.g. GuestXHR would meet the
requirements with improved security [on Mark Miller - due
2009-11-11].

MJS: In a standards compliant
format, so that nobody has to live with my company's
proprietary format (Keynote)

CMN: ONe of the things that make
high bars is that we're going to open up our users to abuse.
There comes a time when you turn off services.

MJS: There's a balance between
security and compatibility. If there's a vulnerability where
you break compat by fixing it, I'm sure all browser vendors
would be eager to do it. If there's a vulnerability that's
[mild] e.g. visited links, we may not break compatibility.

TC: A lot has been made of the
existing deployment of CORS. From my study of the specs, there
are significant differences between implementations...

CMN: These are [decisions made]
by implementors based on the perceived cost to them.
... I don't think security is an on and off thing.

<chaals> TC: And therefore I
am wondering if there is significant content in reality.

<chaals> AR: There is
shipping and compatibility, in apps there is really only
geonames, not a great deal of other adoption

DS: people disagree on whether it
is in the charter
... it is not listed as deliverable, but is in scope
... if someone in the WebApps WG disagrees it is in the charter
we have to re-charter in order to do it

RE: we might want to talk to the Device APIs
WG

AR: also include orientation
event in mt

DS: I believe they are orthogonal
so they can be separate

AR: I believe the same group can
do it

CMN: we had an issue in the last
WG that we inherited about multiple devices interacting with a
single device
... sort of similar to mt

JS: I think it is different, not
just in semantics

CMN: write a spec for mt
events
... the spec says it expects to be included in DOM4 Events

AR: I favor separate specs

[bikeshed]

AR: I am willing to co-edit

DS: I like to co-edit

AR: I like to check with OP

[bikeshed on charter]

CMN: are there objections to
adding new events?

RESOLUTION:
specifications for new events are in our charter

CMN: we have proposals for mt,
orientation, gestures, and pen-tablets

<MikeSmith> I believe the
Geolocation WG is also looking at spec related to
Orientation

DS: can we start a wiki page with
a list of required features for tests?

AB: we have two dependencies; Web
IDL and Web Storage

SW: Web IDL will use ECMAScript 5
concepts which is an invasive change
... we want to add tests based on DOM2 IDL converted to Web IDL
so we can test the various concepts in Web IDL
... we can use that to allow specification editors to move
forward with more certainty

JS: I volunteered for some amount
of that testing

CMN: you can move ahead in the
Rec-track process with a dependency on Web IDL but you have to
argue your case

AB: when is there a new
draft?

SW: I'm new to editing so I don't
really know at this point

MJS: the question is how much
editing needs to be done before we want to publish again
... maybe the goal should be to do the ECMAScript 5 conversion
and publish after that

IH: Web Storage will go to Last
Call this month

CMN: we want to move to a model
where Last Call means the Working Group considers the work to
be good

IH: I believe there are no
outstanding issues
... The W3C side will not be blocked by the WHATWG
... I don't perceive major changes to Web Storage
ever

<trackbot> Created ACTION-449
- Send out a pre-LC request for comments for Hixie's specs [on
Arthur Barstow - due 2009-11-11].

CMN: we found someone to edit ???
and agreed to move XMLHttpRequest to Last Call
... Web Database was only going to be done by 3 out of 5
... more interest in WebSimpleDB
... alternate proposal for CORS which needs further discussion;
DOM Events ready
... we did not get into Selectors API 2

AB: news on XBL2?

JS: I'm on temporary project for
a while, but I worked on a quarter for it and will get back to
it