IRC log of webapps on 2009-11-02

Timestamps are in UTC.

17:04:06 [RRSAgent]
RRSAgent has joined #webapps
17:04:06 [RRSAgent]
logging to
17:04:12 [Travis]
scribe: Travis
17:04:17 [Travis]
scribeNick: Travis
17:04:21 [Marcos]
Marcos has joined #webapps
17:04:35 [adrianba]
adrianba has joined #webapps
17:04:49 [Travis]
Topic: Introductions for Persons present at the WebApps TPAC Meeting
17:04:53 [mmielke]
mmielke has joined #webapps
17:05:05 [myakura]
myakura has joined #webapps
17:06:14 [evlakat]
evlakat has joined #webapps
17:06:45 [MikeSmith]
MikeSmith has joined #webapps
17:06:58 [ArtB]
ArtB has joined #webapps
17:09:28 [chaals]
Present: Chaals, Anne van Kesteren, SamW, Travis, Adrian, Satoshi, Frank, Maciej, Mike™, Rob, Marcus, Gondo, Vagner, Erik, Vladimir, Shigeo, Mark, Doug
17:09:32 [Vagner-br]
Vagner-br has joined #webapps
17:09:32 [chaals]
Chair: Chaals
17:09:40 [fo]
fo has joined #webapps
17:09:51 [MikeSmith]
17:10:20 [timeless]
timeless has left #webapps
17:10:43 [pererik]
17:11:13 [chaals]
Present+ Kai
17:11:27 [chaals]
17:11:34 [MikeSmith]
RRSAgent, make minutes
17:11:34 [RRSAgent]
I have made the request to generate MikeSmith
17:11:37 [shepazu]
17:12:00 [Travis]
Topic: Progress Events
17:12:01 [Kai]
Kai has joined #webapps
17:17:01 [Travis]
chaals: Any additional items to add to the agenda?
17:17:42 [chaals]
Present+ PaulC, Sam, JohnG, Jeremy
17:18:14 [Travis]
chaals: Spec has been stalled for some time...
17:18:14 [plh-webapps]
plh-webapps has joined #webapps
17:18:59 [chaals]
Present+ Nikunj
17:19:04 [chaals]
Topic: Progress events
17:19:14 [chaals]
--> Editor's draft
17:20:06 [johnnyg]
johnnyg has joined #webapps
17:20:48 [Travis]
chaals: Progress events are events for showing progress :-)
17:21:45 [JonathanJ]
JonathanJ has joined #webapps
17:21:51 [smaug]
smaug has joined #webapps
17:22:20 [Travis]
... Issue about what events must be defined in the spec itself.
17:23:01 [Travis]
... Justification is that there is a definate pattern that must be followed when implementing these events.
17:23:39 [Travis]
... Progress events have been implemented by SVG some years ago (there a bit of a legacy)
17:24:13 [Travis]
... Considering making the events requirement a "SHOULD" instead of a MUST.
17:24:40 [Travis]
... This text presumably makes it easier to integrate into other specs.
17:25:47 [Travis]
Hixie: Main concern with the requirements able to be defined in other specs and the progress events spec is how do you test this?
17:26:52 [Travis]
shepazu: Can progress events be implemented outside of a host language?
17:28:08 [Travis]
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.
17:28:39 [Travis]
shepazu: Concerned that an implementer wouldn't implement the non-normative parts.
17:29:11 [Travis]
chaals: With a spec only having SHOULDs, there's no normative requirement for implementors!
17:29:24 [Travis]
... Would such an approach make sense?
17:29:38 [arun]
arun has joined #webapps
17:30:02 [Travis]
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.
17:33:09 [Travis]
chaals: Without a normative requirement, there's nothing to prevent anyone from completely ignoring the spec.
17:35:08 [Travis]
Rob: Would it make sense to have a section for reasons why the Progress events wouldn't be used as spec'd?
17:36:23 [Travis]
shepazu: Question about what the different use cases are for when scenarios might employ progress events.
17:36:49 [smaug]
smaug has joined #webapps
17:37:32 [eric_uhrhane]
eric_uhrhane has joined #webapps
17:37:34 [shepazu]
for example, you could use progress events for computationally intensive progress
17:37:50 [shepazu]
17:38:25 [Travis]
mjs: Should have a section for how Progress events should "typically" be used (in a basic scenario), but to not overconstrain the spec.
17:39:44 [Travis]
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.
17:40:22 [Travis]
anne: Don't think it makes sense to have user agent requirements in this spec.
17:40:51 [Travis]
Hixie: There are conflicting requirements must / must not depending on the spec.
17:41:30 [Travis]
anne: XHR, AppCache, Media Elements all specify how these events are to be dispatched.
17:41:38 [Travis]
... So don't see the point of a common model.
17:43:07 [Travis]
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.
17:43:22 [Travis]
Hixie: Great--as long as it's not normative, I love it.
17:43:30 [Travis]
shepazu: +1
17:43:59 [Travis]
anne: Seems pretty complicated to a make a generic model.
17:44:03 [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
17:44:13 [Hixie]
these requirements would not be normative at the progress events spec level
17:44:41 [Travis]
anne: No formal objection.
17:45:34 [arun]
If it is non-normative, issues behind objections can probably be mitigated (e.g. how complicated a general model might be).
17:45:50 [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
17:46:23 [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
17:46:58 [MikeSmith]
Hixie, so HTML5 has not normative dependency on Progress events currently, right?
17:47:01 [johnnyg]
johnnyg has joined #webapps
17:47:13 [MikeSmith]
s/has not/has not/
17:47:17 [MikeSmith]
s/has not/has no/
17:47:24 [anne]
anne has left #webapps
17:47:24 [Travis]
chaals: Issue 105
17:47:27 [weinig]
17:47:27 [Hixie]
it has one for appcache
17:47:58 [anne]
anne has joined #webapps
17:49:20 [mmielke]
mmielke has joined #webapps
17:49:26 [Travis]
... Use cases for my "email scenario" and the Media streaming events were different.
17:51:17 [Travis]
... Was my addition of the attribute for tracking different transactions useful?
17:51:41 [Travis]
Hixie: The model you describe (with sub-transactions showing progress) leads to horrific UI.
17:51:50 [Travis]
chaals: Yes, but I like that UI.
17:52:52 [smaug__]
smaug__ has joined #webapps
17:53:01 [arve]
arve has joined #webapps
17:53:20 [MikeSmith]
"The default action of these events must be, if the user agent shows caching progress, the display of some sort of user interface indicating to the user that a file is being downloaded in preparation for updating the application. [PROGRESS]"
17:53:21 [Travis]
shepazu: In the multiple items case, could I make a progress bar that handled X different items downloading at once and consolidate them?
17:56:02 [Travis]
Rob: Might want to make this very simple and keep the progress as percentages only.
17:56:20 [Travis]
chaals: On percentages: this can get tricky when you don't know how much data you're going to get.
17:58:22 [Travis]
MichaelNan: In favor of simplifying the progress events.
18:01:05 [johnnyg]
johnnyg has joined #webapps
18:01:25 [timeless_mbp]
timeless_mbp has joined #webapps
18:01:44 [Travis]
weinig: May not need to define in the Progress Events for sub items, but leave it up to hosting specs to provide a means to define how unique progress events are tracked.
18:03:53 [tlr]
tlr has joined #webapps
18:04:12 [Travis]
chaals: The purpose of the two extra attributes was to allow the data for sub items to be tracked.
18:05:51 [Travis]
weinig: For the non-simple cases, an informative section describing how to handle these might be easier.
18:06:26 [Travis]
Hixie: Could look to XHR's upload concept.
18:07:34 [anne]
18:07:47 [Travis]
Action: weinig to write up sample on what the multi-file progress informative text might look like.
18:07:47 [trackbot]
Created ACTION-431 - Write up sample on what the multi-file progress informative text might look like. [on Samuel Weinig - due 2009-11-09].
18:09:13 [Travis]
chaals: Issue 107 is largely redundant if we simplify.
18:10:11 [Travis]
chaals: There is another question: what does the total and loaded count mean?
18:10:19 [Travis]
... Now is specifies the number of bytes.
18:10:56 [Travis]
... In removing the normative requirement, the "bytes" requirement could totally go away.
18:11:13 [Travis]
... Makes sense for me to recommend bytes as the default simple case.
18:11:45 [Travis]
Hixie: So far, the various specs interpret the values different already {files, bytes, objects}
18:15:33 [Travis]
chaals: Propose we drop the total bytes in favor of showing progress of "something".
18:15:51 [MikeSmith]
chaals, Ian Fette and Lachy came in, need to intro himself
18:16:27 [Lachy]
Lachy has joined #webapps
18:16:43 [Lachy]
Lachy has joined #webapps
18:17:40 [mmani]
mmani has joined #webapps
18:18:12 [Travis]
shepazu: Please keep existing text in place for a compare/contrast draft.
18:19:32 [Travis]
chaals: I think this wraps up what I had to discuss on Progress Events.
18:23:38 [Lachy]
Lachy has joined #webapps
18:23:41 [Travis]
chaals: Let's break now, and reconvene at 11. We'll be in Salon 5 meeting with Device API.
18:23:50 [Travis]
Travis has left #webapps
18:29:33 [Lachy]
Lachy has joined #webapps
18:40:16 [johnnyg]
johnnyg has joined #webapps
18:54:19 [johnnyg]
johnnyg has joined #webapps
19:01:15 [tlr_]
tlr_ has joined #webapps
19:02:46 [arun]
arun has joined #webapps
19:03:20 [darobin]
darobin has joined #webapps
19:05:07 [johnnyg]
johnnyg has joined #webapps
19:06:19 [mjs]
mjs has joined #webapps
19:06:35 [weinig]
weinig has joined #webapps
19:06:51 [shiki]
shiki has joined #webapps
19:07:19 [pererik]
pererik has joined #webapps
19:07:51 [jorlow]
jorlow has joined #webapps
19:08:02 [Vladimir]
Vladimir has joined #webapps
19:08:43 [shepazu]
shepazu has joined #webapps
19:10:03 [jorlow]
jorlow has joined #webapps
19:10:13 [sicking]
sicking has joined #webapps
19:10:14 [chaals]
rrsagent, make logs public
19:10:19 [chaals]
rrsagent, draft minutes
19:10:19 [RRSAgent]
I have made the request to generate chaals
19:10:33 [chaals]
rrsagent, this meeting crosses midnight
19:10:33 [RRSAgent]
I'm logging. I don't understand 'this meeting crosses midnight', chaals. Try /msg RRSAgent help
19:11:14 [chaals]
rrsagent, this meeting spans midnight
19:11:33 [jorlow_]
jorlow_ has joined #webapps
19:13:31 [Zakim]
Zakim has left #webapps
19:14:40 [Vagner-br]
Vagner-br has joined #webapps
19:22:38 [tlr__]
tlr__ has joined #webapps
19:22:59 [Marcos]
Marcos has joined #webapps
19:24:49 [tlr]
tlr has joined #webapps
19:43:03 [gsnedders]
gsnedders has joined #webapps
19:47:04 [Vagner-br]
Vagner-br has left #webapps
19:48:10 [mmielke]
mmielke has joined #webapps
NEWTON_VAGNER_DIN has joined #webapps
20:04:32 [mmani]
mmani has joined #webapps
20:05:02 [smaug]
smaug has joined #webapps
20:07:41 [Hixie]
Hixie has joined #webapps
20:09:50 [JonathanJ]
JonathanJ has joined #webapps
20:25:36 [timeless_mbp]
timeless_mbp has joined #webapps
20:29:15 [pererik]
pererik has joined #webapps
20:51:21 [Marcos]
Marcos has joined #webapps
20:51:45 [jorlow_]
jorlow_ has joined #webapps
20:52:12 [Marcos]
Marcos has joined #webapps
21:38:50 [timeless_mbp]
timeless_mbp has joined #webapps
21:46:00 [Marcos]
Marcos has joined #webapps
21:46:15 [shiki]
shiki has joined #webapps
21:48:30 [shepazu]
shepazu has joined #webapps
21:50:36 [weinig]
weinig has joined #webapps
21:51:39 [pererik]
pererik has joined #webapps
21:53:28 [mjs]
mjs has joined #webapps
NEWTON_VAGNER_DIN has joined #webapps
21:59:13 [sicking]
sicking has joined #webapps
22:00:57 [ArtB]
ArtB has joined #webapps
22:01:36 [pererik]
pererik has joined #webapps
22:01:50 [darobin]
darobin has joined #webapps
22:01:55 [plh]
plh has joined #webapps
22:02:08 [Vladimir]
Vladimir has joined #webapps
22:02:09 [ArtB]
ArtB has changed the topic to: WebApps agenda Nov 2:
22:02:33 [chaals]
chaals has joined #webapps
22:02:40 [ArtB]
RRSAgent, pointer
22:02:40 [RRSAgent]
22:03:13 [ArtB]
RRSAgent, make minutes
22:03:13 [RRSAgent]
I have made the request to generate ArtB
22:03:23 [chaals]
Scribe: Chaals
22:03:33 [chaals]
ScribeNick: chaals
22:03:40 [chaals]
Topic: CORS
22:04:44 [Marcos]
Marcos has joined #webapps
22:05:11 [ArtB]
Present+ ArtB
22:05:27 [timeless_mbp]
timeless_mbp has joined #webapps
22:05:55 [chaals]
AvK: Two open issues raised by mnot
22:06:20 [chaals]
... one is naming, one is technical. And a missing issue MM is here to talk about - should we throw it all away...
22:06:57 [chaals]
MM: Suggesting the mechanism should not present authorising information in a ?? fashion. It's up to applications to decide what to do
22:07:03 [DanC]
DanC has joined #webapps
22:07:14 [chaals]
AvK: Also status of origins spec at IETF, and call for tutorials/use cases.
22:07:20 [Magnus]
Magnus has joined #webapps
22:07:34 [chaals]
... let's begin with the big fat guy in the middle of the room
22:08:54 [chaals]
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.
22:09:27 [chaals]
... CORS links origin of requester from origin header, which fulfils requirements to make Confused Deputy problems.
22:09:39 [chaals]
... discussion hasn't addressed the objection.
22:09:54 [chaals]
... Not showed that it doesn't apply, doesn't matter, etc.
22:09:55 [arun]
q+ to ask about a sample attack...
22:10:15 [chaals]
ack arun
22:10:24 [mjs]
22:10:26 [tlr]
tlr has joined #webapps
22:10:32 [shepazu]
q+ tyler
22:10:48 [chaals]
AR: Can anyone show a sample attack that demonstrates the nature of the problem?
22:11:15 [chaals]
MM: Tyler Close posted a 3-aparty interaction where each step is intuitive in CORS< and the result creates a confused deputy problem.
22:11:20 [chaals]
ack mjs
22:11:20 [adrianba]
adrianba has joined #webapps
22:11:28 [jorlow]
jorlow has joined #webapps
22:11:51 [chaals]
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
22:12:05 [chaals]
MM: What validation should the second party do to the URIs to ensure control?
22:12:22 [chaals]
MJS: Site 1 has photos, site 2 printing, site 3 has storage.
22:12:35 [chaals]
... photo site wants printer to get things from storage.
22:12:42 [Hixie] is Tyler's example
22:12:42 [anne]
example from Tyler:
22:12:49 [chaals]
... etc.
22:12:52 [shepazu]
22:13:19 [ht]
ht has joined #webapps
22:13:20 [chaals]
... Right approach: Printing site creates one-time store, passes that, and the photo site uses a different API to pass it to the photo site.
22:13:38 [chaals]
TC: That is right, but you don't need CORS to do it
NEWTON_VAGNER_DIN has joined #webapps
22:13:54 [chaals]
MJS: How do you do it without server-server comms which is a goal of CORS
22:14:02 [ht]
ArtB -- TAG is coming, unless you say no. . .
22:14:10 [MikeSmith]
chaals, some TAG members will be joining in a minute
22:14:19 [soonho]
soonho has joined #webapps
22:14:42 [arun]
This is Tyler's Email:
22:15:18 [Qiuling]
Qiuling has joined #webapps
22:15:42 [chaals]
TC: We know in principle that using client authentication is vulnerable to CD. We have experienced this on the web - csrf, clickjacking.
22:15:57 [chaals]
... CORS proposes another way to use client auth on the web.
22:16:03 [shepazu]
q+ to ask if we are worried about malicious or accidental problems
22:16:15 [chaals]
22:16:26 [ArtB]
ArtB has joined #webapps
22:16:32 [Zakim]
Zakim has joined #webapps
22:16:53 [chaals]
DS: It seemed that the attacks are not malicious, but accidental. Ambient authority gets wrong access.
22:17:30 [chaals]
MM: My sense was that it is not accidental. The program issuing a command could, I think maliciously, "mis"direct information
22:18:05 [chaals]
DS: Think we could distinguish accidental cases (things people get wrong) from malicious attacks - the latter are ways people can hack you, the other is something that doesn't give malicious access.
22:18:17 [chaals]
MJS: CSRF lets people set up malicious attack
22:18:31 [chaals]
MM: I am happy that if we can solve the malicious cases we are fine.
22:18:56 [chaals]
TC explains his email example with a drawing.
22:19:04 [shepazu]
original confused deputy description:
22:20:14 [chaals]
MJS: I think that this setup requires a shared secret, which requires server-server communication.
22:20:23 [chaals]
Present+ TAG
22:22:07 [DanC]
DanC has joined #webapps
22:22:25 [johnnyg]
johnnyg has joined #webapps
22:22:41 [MikeSmith]
22:22:42 [mmielke]
mmielke has joined #webapps
22:22:46 [noahm]
noahm has joined #Webapps
22:23:12 [DanC]
RRSAgent, poinger?
22:23:12 [RRSAgent]
I'm logging. Sorry, nothing found for 'poinger'
22:23:14 [DanC]
RRSAgent, pointer?
22:23:14 [RRSAgent]
22:23:29 [chaals]
TC: 3 servers. 1 has photos, 2 is a printer, 3 is a storage service
22:23:33 [htt]
htt has joined #webapps
22:23:35 [Marcos]
Marcos has joined #webapps
22:23:40 [mmielke]
mmielke has joined #webapps
22:24:20 [chaals]
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
22:24:37 [MikeSmith]
somebody who has a camera should please take a photo of Tyler's diagram
22:25:23 [chaals]
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
22:25:39 [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)
22:25:42 [chaals]
MM: The key is that post-login the auth login is not ambient
22:25:45 [shepazu]
q+ rob
22:26:15 [chaals]
MJS: Main reason for CORS is to bootstrap the one-time mechanism - only other known ways are shared secret on server side and require server-server communication to pass the tokens
22:26:23 [chaals]
22:26:59 [chaals]
... (server can't send its secret via the client, because then it isn't secret)
22:27:22 [JonathanJ]
JonathanJ has joined #webapps
22:27:35 [chaals]
DS: Is the data otherwise secure?
22:27:39 [chaals]
TC: Yes.
22:28:01 [DanC]
(can't quite tell if that requirement is in or not. maybe it's in the use cases.)
22:28:04 [chaals]
ack rob
22:28:36 [chaals]
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.
22:28:49 [mmani]
mmani has joined #webapps
22:28:56 [chaals]
MM: You are not an origin...
22:29:10 [chaals]
MJS: You can make a request, but you can't guarantee that it gets fulfilled
22:29:29 [MikeSmith]
22:29:30 [timeless_mbp]
timeless_mbp has joined #webapps
22:30:14 [chaals]
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
22:31:37 [DanC]
(the security risks are clear enough to me; have alternative designs that avoid the risks been offered?)
22:32:10 [chaals]
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.
22:32:57 [chaals]
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.
22:33:40 [chaals]
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.
22:33:44 [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.)
22:33:54 [ht]
22:34:19 [anne]
DanC, there is no issue number
22:34:27 [DanC]
yeah, that seems like a bug
22:34:28 [chaals]
... CORS lets you solve this by giving a secure mechanism for dealing with the transaction.
22:34:28 [shepazu]
q+ raman
22:34:32 [Marcos]
Marcos has joined #webapps
22:34:43 [DanC]
easy to fix: ISSUE: confused deputy problem
22:34:50 [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
22:34:59 [chaals]
TC: Web browser is on a site that cmes from the photo manager. all interactions take place on that page.
22:35:13 [DanC]
anne, not at all.
22:35:41 [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.
22:35:42 [chaals]
... user hits a button to print a photo. a button asks a printer site to print a photo.
22:35:44 [DanC]
an issue is just a promise to make a decision; it doesn't presume which way the decision will go
22:36:34 [chaals]
ACTION: chaals to raise an issue for this question
22:36:34 [trackbot]
Created ACTION-432 - Raise an issue for this question [on Charles McCathieNevile - due 2009-11-09].
22:36:54 [MikeSmith]
22:36:54 [trackbot]
ACTION-432 -- Charles McCathieNevile to raise an issue for this question -- due 2009-11-09 -- OPEN
22:36:54 [trackbot]
22:37:00 [anne]
DanC, fair enough
22:37:09 [anne]
close ACTION-432
22:37:09 [trackbot]
ACTION-432 Raise an issue for this question closed
22:37:18 [Kai]
Kai has joined #webapps
22:37:26 [DanC]
:) issue-108. thanks.
22:37:28 [MikeSmith]
ht, I will change that now
22:38:01 [chaals]
IH: How does the manager authorise printing?
22:38:07 [ht]
22:38:22 [chaals]
TC: Out of band, they made an agreement that the manager could ship jobs to the printer.
22:38:29 [arun]
arun has joined #webapps
22:40:17 [chaals]
MJS: THe question is whether there is a sensible way to use CORS that doesn't have a vulnerability?
22:40:36 [chaals]
CMN: I think the question is whether there is an obvious way to use CORS that introduces a security risk
22:40:56 [chaals]
TC: We are objecting to the idea that the group is baking up a way that people will create security risks
22:41:14 [chaals]
MJS: I don't think that is an issue. CORS allows for 2-party transactions to be done that are secure.
22:42:22 [chaals]
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.
22:43:31 [noahm]
noahm has joined #Webapps
22:43:33 [chaals]
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?
22:44:06 [chaals]
[back to the example]
22:44:21 [MikeSmith]
22:44:21 [trackbot]
ISSUE-108 -- confused deputy problem -- RAISED
22:44:21 [trackbot]
22:44:41 [chaals]
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.
22:44:55 [DanC]
DanC has joined #webapps
22:45:54 [MikeSmith]
RRSAgent, make minutes
22:45:54 [RRSAgent]
I have made the request to generate MikeSmith
22:46:06 [chaals]
... 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.
22:46:32 [chaals]
MM: Intuitive assumption for the developer is that the URL from teh printer site is a URLthe printer has access to.
22:46:59 [chaals]
... problem arises because if the storage site checks access against the origin, it will check against the manager's access, not the printer's.
22:47:14 [chaals]
... manager would want to make the decision based on whether the printer has access, but has no way to ask that.
22:47:55 [chaals]
TC: There is an access control problem. CORS is telling developers to use a solution that won't work. There are other solutions.
22:48:19 [chaals]
Rob: If manager was only talking direct to the client, direct to the printer, and direct to the store, no problem.
22:48:48 [chaals]
AR: The use case can be shoe-horned into other systems.
22:49:23 [chaals]
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.
22:49:41 [chaals]
DS: MM agreed there are ways to build secure applications with CORS< as well as building vulnerabilities.
22:49:47 [chaals]
MM: True.
22:49:53 [chaals]
22:50:01 [chaals]
q- raman
22:50:16 [chaals]
q+ Tyler
22:50:52 [mjs]
oh hey Zakim is back
22:50:55 [mjs]
22:51:11 [chaals]
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.
22:52:32 [chaals]
CMN: If you can restrict the system to 2 servers, can you avoid the problem.
22:52:45 [chaals]
TC: No. You can still make the problem without the 3rd website.
22:53:06 [chaals]
... e.g. combine the storage and manager here
22:53:27 [chaals]
IH: Why would the manager give the printer access to tell it to write something over closed content?
22:53:47 [sicking]
22:53:49 [chaals]
MJS: it seems in the 2-party case you have to make it needlessly complicated to make the vulnerability work
22:53:51 [chaals]
ack chaals
22:54:12 [mjs]
q+ rob
22:54:14 [chaals]
TC: If any auth data from site A came from site B, you create confused authority.
22:54:45 [chaals]
MM: If you are not using anything that didn't come from *you*, then you are not creating a vulnerability.
22:55:21 [arun]
22:55:30 [chaals]
ack ty
22:56:13 [chaals]
TC: If you can say "don't apply my authority to anything I didn't make myself" you solve the problem.
22:56:15 [chaals]
ack mj
22:56:50 [chaals]
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.
22:57:08 [chaals]
... so any request using info from a 3rd party exposes this.
22:57:13 [chaals]
TC: Yes
22:57:21 [chaals]
MJS: Self to self has client authority
22:57:31 [chaals]
TC: Yes, but we should be trying to reduce this.
22:57:58 [chaals]
MM: Guest XHR should not present auth even when it goes back to its own origin.
22:58:07 [MikeSmith]
Present+ timeless
22:58:49 [chaals]
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.
22:59:04 [timeless]
timeless has joined #webapps
22:59:24 [chaals]
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.
22:59:45 [MikeSmith]
22:59:52 [chaals]
... guestXHR is a refolrmulation of CORS that addresses our security concerns.
23:00:08 [timeless]
23:00:23 [chaals]
JS: Do you have an alternate proposal. If GuestXHR is it, how do you build a website that uses it nicely?
23:00:40 [chaals]
... imagine websites would be hesitatnt to ask users to copy strings from one place to another
23:00:52 [timeless]
23:01:11 [chaals]
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.
23:01:40 [chaals]
MJS: Think the 2-site mechanism is the thing we are interested in.
23:02:07 [chaals]
ack sicking
23:03:17 [chaals]
TC: Would like to see the problem being laid out for existing approach, and I will explain how to fix it
23:03:34 [chaals]
ACTION: jonas write a very concrete example of a problem
23:03:34 [trackbot]
Created ACTION-433 - Write a very concrete example of a problem [on Jonas Sicking - due 2009-11-09].
23:03:47 [chaals]
ACTION: Tyler to explain how to do it with guestXHR in a nice UI
23:03:47 [trackbot]
Sorry, couldn't find user - Tyler
23:04:00 [ArtB]
mjs' example:
23:04:25 [chaals]
ack rob
23:05:07 [chaals]
Rob: Fundamental problem is if manager can be asked to do something by another party, with the authority of the user in the middle.
23:05:15 [chaals]
... question is whether CORS encourages that behaviour
23:05:18 [chaals]
23:05:34 [tlr]
+1 to "are people encouraged" as the key question
23:05:48 [chaals]
... I am not convinced we are encouraging this behavious with CORS. Are we making it any more likely?
23:05:54 [timeless]
23:06:05 [chaals]
MM: Problem is not encouraging lack of checking, problem is creating a demand for checking that cannot actually be met.
23:06:19 [chaals]
... if authority is carried along then there is no problem.
23:06:56 [chaals]
... Existence of CORS doesn't force servers to make decisions based on origin. If servers make the decision based on extra information carried alongside.
23:07:21 [chaals]
Rob: CORS doesn't create the vulnerability, it creates a communication path.
23:07:41 [chaals]
MM: Creates an conditional path. if it were unconditional there wouldn't be a problem.
23:07:46 [chaals]
AvK: It needs to be conditional
23:07:55 [chaals]
MM: And therefore it is inherently an access control problem.
23:08:21 [chaals]
AR: zakim, close the queue
23:08:28 [chaals]
zakim, close the queue
23:08:28 [Zakim]
ok, chaals, the speaker queue is closed
23:08:30 [Kangchan]
Kangchan has joined #webapps
23:08:48 [tlr]
23:09:13 [Kangchan]
Kangchan has left #webapps
23:09:15 [chaals]
AR: 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.
23:09:28 [chaals]
... there is some case to draw these examples and explain them as bad design.
23:09:53 [chaals]
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.
23:10:13 [chaals]
DS: Let's say we keep it as is, and describe carefully how it should not be used and explain the problems.
23:10:32 [chaals]
... nobody wants to create insecure interfaces. Can we show them why not to do A, and why to do B instead, would that work?
23:10:49 [chaals]
zakim, open queue
23:10:49 [Zakim]
ok, chaals, the speaker queue is open
23:10:52 [chaals]
q+ tlr
23:10:55 [chaals]
zakim, close queue
23:10:55 [Zakim]
ok, chaals, the speaker queue is closed
23:10:59 [arun]
ack arun
23:11:01 [chaals]
MM: yes...
23:11:23 [chaals]
... point is to enable people to write applications that are useful and secure, and that requires education, any solution we have will require that.
23:12:16 [chaals]
... 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.
23:12:33 [chaals]
DS: There are inherent composition problems. Can we forestall those in practice?
23:13:48 [mjs]
23:13:59 [mjs]
23:14:10 [chaals]
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.
23:16:24 [chaals]
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.
23:17:06 [chaals]
... 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.
23:18:26 [chaals]
CMN: We will wrap here, because we are not getting to resolution
23:18:40 [chaals]
... will look for more time to do this tomorrow
23:19:01 [chaals]
DS: Can people try to prepare clear presentations for tomorrow?
23:19:13 [chaals]
AvK: Would be good if they can be very concrete.
23:19:34 [chaals]
MM: Didn't see in the draft that a requirement is to avoid server-server communication... is that an understood requirement?
23:19:39 [chaals]
AvK: Yes...
23:20:54 [mmani]
mmani has joined #webapps
23:27:06 [Marcos]
Marcos has joined #webapps
23:27:17 [johnnyg]
johnnyg has joined #webapps
23:35:36 [ArtB]
ArtB has joined #webapps
23:35:41 [darobin]
darobin has joined #webapps
23:37:13 [Magnus]
Magnus has joined #webapps
23:39:03 [Magnus]
Magnus has left #webapps
23:39:11 [weinig]
weinig has joined #webapps
23:39:15 [Kai]
Kai has joined #webapps
23:39:55 [chaals]
Scribe: Sam
23:39:59 [chaals]
Topic: Views
23:40:15 [chaals]
ScribeNick: weinig
23:41:02 [weinig]
anne: there are a bunch of spec that refer to views
23:41:15 [weinig]
anne: rendered view/default view
23:41:29 [weinig]
anne: in reality, all implementations always return the default views
23:41:36 [weinig]
anne: we should kill the concept of views
23:41:50 [weinig]
shepazu: inventor of views thinks it was a bad idea
23:42:09 [weinig]
jonas: mozilla has support but it is a pain in the buttox
23:42:36 [weinig]
shepazu: does anyone know of any implementations
23:43:01 [weinig]
jonas: mozilla uses if for print preview, but it is not accessible from the dom
23:44:08 [weinig]
maciej: concept of views seems unnecessary, but there APIs we need to keep (AbstractView, etc)
23:44:37 [weinig]
maciej: getComputedStyle
23:44:53 [weinig]
anne: we should keep the APIs, but get rid of the concept
23:45:26 [weinig]
anne: offsetLeft, etc, will all be relative to the one true view now
23:45:49 [weinig]
shepazu: I agree completely
23:48:09 [chaals]
[discussion of details about which specs and how we organise them]
23:48:56 [weinig]
maciej: UI events need a view
23:49:44 [weinig]
RESOLUTION: Remove concept of views
23:50:22 [weinig]
MikeSmith: what about DOM Level 2?
23:50:38 [weinig]
chaals: we should issue an erratum
23:51:00 [weinig]
Paul: we can issue a note on the existing spec
23:51:21 [weinig]
Paul: for the TR page
23:51:54 [weinig]
chaals: we want to point out that there is an "untruth" in the DOM Level 2 spec which people are reading
23:52:42 [chaals]
SW: I implemented some stuff in CSSOM for fun, and we found that CaretRangeForPoint is less useful than we would like
23:52:51 [chaals]
23:53:21 [chaals]
... one of the constraints is that it is only over what would be editable. For areas that look/are selectable, they don't necessarily have a DOM range.
23:53:36 [chaals]
... Use case was dictionary popup - want to know what word you are over.
23:53:42 [chaals]
DS: Ditto in IMEs
23:54:12 [chaals]
AvK: Maciej proposed to change to CaretPositionFrom Point, which is an offset integer from the current node (number of characters...)
23:55:18 [weinig]
chaals: in the case where the parent is an element, it can be an awkward API
23:55:25 [dom]
dom has joined #webapps
23:55:29 [chaals]
23:55:32 [weinig]
23:55:33 [timeless]
ACTION: ArtB to notify Widgets WG that they have 2 weeks to review WARP
23:55:33 [trackbot]
Created ACTION-434 - Notify Widgets WG that they have 2 weeks to review WARP [on Arthur Barstow - due 2009-11-09].
23:55:53 [pererik]
pererik has joined #webapps
23:56:18 [weinig]
maciej: there is no way to know all the of the names of the form controls
23:56:50 [weinig]
tl: can css change things into form controls
23:57:04 [weinig]
maciej: there is css-appearance
23:57:15 [weinig]
maciej: there is svg:textarea
23:57:33 [weinig]
anne: that has ranges inside it if is editable
23:59:16 [weinig]
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
23:59:29 [johnnyg_]
johnnyg_ has joined #webapps
23:59:52 [weinig]
maciej: 2) if you hit a form control, the container is the control, the offset is the offset in the control
00:00:37 [chaals]
SW: With range ability to get position you can get a bounding box of the collapsed range
00:01:01 [weinig]
maciej: 3) if you hit an element, you get the element as the container, the offset is the range offset
00:01:35 [weinig]
anne: the caretPosition object should have a range attribute, which is null for form controls
00:03:16 [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?
00:03:50 [weinig]
anne: dean (apple) asked me about that, people from apple have been asking me about it as well
00:05:05 [weinig]
maciej: returning the bounding box seems like the most sensible thing
00:05:23 [weinig]
jonas: that is what is done for svg
00:05:40 [weinig]
maciej: but we should have quad apis as well
00:05:59 [weinig]
maciej: maybe we only need 3 points, maybe we want 4 for perspective transforms
00:06:09 [weinig]
maciej: math is hard
00:06:18 [Nikunj]
Nikunj has joined #webapps
00:06:39 [weinig]
00:06:42 [johnnyg]
johnnyg has joined #webapps
00:07:36 [Marcos]
Marcos has joined #webapps
00:08:16 [Travis]
Travis has joined #webapps
00:08:55 [weinig]
maciej: all we really need is a way to take the bounding box and convert it page space
00:09:16 [anne]
00:09:53 [tlr]
tlr has joined #webapps
00:09:58 [weinig]
maciej: we need a way to convert a point from node to page space (and vice-versa) as well
00:10:08 [weinig]
anne: what is the coordinate system of the node
00:10:22 [weinig]
chaals: it is the point in the transformed node
00:10:29 [weinig]
chaals does something with his hands
00:10:46 [chaals]
zakim, open queue
00:10:46 [Zakim]
ok, chaals, the speaker queue is open
00:11:09 [Nikunj1]
Nikunj1 has joined #webapps
00:11:40 [weinig]
anne: we should probably try and move these apis away from the window if we can
00:12:07 [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
00:12:22 [arve]
arve has joined #webapps
00:13:06 [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
00:13:27 [chaals]
00:13:29 [weinig]
00:13:54 [chaals]
s/adjourned/in recess/
00:13:59 [chaals]
s/adjourned/in recess/
00:22:59 [soonho]
soonho has joined #webapps
00:23:00 [Marcos]
Marcos has joined #webapps
00:33:33 [timeless_mbp]
timeless_mbp has joined #webapps
00:34:12 [Kai]
Kai has joined #webapps
00:38:32 [Nikunj]
Nikunj has joined #webapps
00:40:57 [Marcos]
Marcos has joined #webapps
00:40:59 [ArtB]
ArtB has joined #webapps
00:52:52 [shepazu]
shepazu has joined #webapps
00:54:26 [soonho]
soonho has left #webapps
00:58:01 [shepazu]
shepazu has joined #webapps
01:01:35 [chaals]
Scribe: Maciej
01:01:38 [mjs]
avk: ISSUE-33 - should re-entrance be allowed for readystatechange
01:01:45 [chaals]
ScribeNick: mjs
01:01:50 [mjs]
01:02:14 [mjs]
js: so are you not allowed to call open? does that throw an exception?
01:02:18 [mjs]
avk: in IE yes
01:02:19 [shepazu]
trackbot, start telcon
01:02:21 [trackbot]
RRSAgent, make logs public
01:02:23 [trackbot]
Zakim, this will be WAPP
01:02:23 [Zakim]
I do not see a conference matching that name scheduled within the next hour, trackbot
01:02:24 [trackbot]
Meeting: Web Applications Working Group Teleconference
01:02:24 [trackbot]
Date: 02 November 2009
01:02:43 [shepazu]
01:02:43 [trackbot]
ISSUE-33 -- Shoulld re-entrance be allowed foronreadystatechange? -- OPEN
01:02:43 [trackbot]
01:02:44 [mjs]
tl: if you open from a readystatechange handler on the same object?
01:02:48 [mjs]
js: yes:
01:02:53 [mjs]
tl: I don't know what IE does
01:03:35 [mjs]
avk: other browsers allow it, and restricting it would be weird
01:03:46 [mjs]
tl; sounds like it's a synchronous event allowing re-entrancy
01:04:02 [mjs]
js: my recollection is it was more a concern with later readystates like 3 or 4
01:04:31 [mjs]
js: I know we just allow anything anywhere, I don't remember what IE does
01:05:19 [mjs]
ACTION: travis To research what IE does for readystate re-entry (for ISSUE-33)
01:05:19 [trackbot]
Created ACTION-436 - Research what IE does for readystate re-entry (for ISSUE-33) [on Travis Leithead - due 2009-11-10].
01:05:40 [mjs]
sw: I think readystatechange is async
01:05:43 [mjs]
js: not always
01:07:03 [mjs]
avk: (explains details)
01:09:14 [mjs]
01:09:33 [mjs]
01:09:33 [trackbot]
ISSUE-103 -- accessing status/statusText/getResponseHeader()/getAllResponseHeaders() -- RAISED
01:09:33 [trackbot]
01:09:49 [mjs]
avk: the issue is that IE throws when certain methods are called in a particular state
01:11:43 [mjs]
avk: not throwing is generally better
01:11:51 [mjs]
tl: unless there's a really good reason to throw
01:13:44 [mjs]
js: it appears Firefox never throws for status but it might throw more often for statusText
01:13:57 [mjs]
js: appears to throw a random number
01:15:07 [mjs]
sw: we added throwing to match other browsers (the minimum)
01:15:23 [mjs]
js: why did you change, was it b/c websites complained?
01:15:54 [mjs]
sw: I don't remember, it might have been to change the spec
01:16:10 [mjs]
*general mumbling*
01:16:17 [mjs]
*awkward silence*
01:16:26 [mjs]
01:17:34 [mjs]
avk: what are we going to do - change and not throw?
01:18:29 [mjs]
js: I'd like to err on the side of not throwing
01:19:12 [mjs]
RESOLUTION: for ISSUE-103, don't throw
01:19:39 [mjs]
the other bit for XHR1 was the test suite
01:19:43 [mjs]
^ avk:
01:19:50 [mjs]
avk: it would be nice to have some help at some point
01:19:58 [mjs]
fo: I've got some notes which I still owe you on that
01:20:10 [mjs]
jr: do you have mark nottingham's tests? do they cover different things?
01:20:16 [mjs]
avk: probably
01:20:21 [mjs]
jr: I think he's got things checking caching
01:21:10 [mjs]
avk: the test suite has quite a lot of coverage, especially security stuff and resolving URLs
01:21:17 [mjs]
avk: there's definitely more things that can be tested
01:21:22 [mjs]
cmn: which things are those
01:21:33 [mjs]
avk: methods probably... http verbs
01:21:52 [mjs]
avk: there's a bunch of side effects that are not all covered yet, e.g. when you invoke open()
01:22:02 [mjs]
avk: *more technobabble about complicated steps*
01:22:23 [mjs]
avk: I don't think there's tests for Accept, Accept-Language, conditional GET
01:23:47 [mjs]
mjs: are the tests in cvs?
01:23:50 [anne]
01:23:51 [mjs]
avk: not currently
01:23:53 [anne]
01:24:39 [mjs]
avk: I don't really like working on tests
01:24:50 [mjs]
ds: Anne, what's your job title?
01:24:54 [mjs]
avk: I work on specs!
01:25:34 [mjs]
cmn: any volunteers to write tests?
01:25:59 [johnnyg]
johnnyg has joined #webapps
01:26:03 [mjs]
Scribe: Nikunj
01:26:18 [Nikunj]
avk: Starting on XHR2
01:26:22 [chaals]
Topic: XHR2
01:26:34 [Nikunj]
Issue 104?
01:26:50 [Nikunj]
No serialization defined for structured clones
01:27:04 [Nikunj]
avk: Use multi-part MIME for structured clones
01:27:10 [Nikunj]
ack: may be JSON support at some time
01:27:20 [sicking]
01:27:20 [trackbot]
ISSUE-104 -- supporting structured clones -- RAISED
01:27:20 [trackbot]
01:27:23 [Nikunj]
01:28:02 [Nikunj]
avk: Close 104 for now and revisit when we have a serialization format
01:28:17 [Nikunj]
avk: structured clones can include certain data types beyond JSON
01:28:25 [Nikunj]
avk: such as images and files
01:28:48 [Nikunj]
mw: used for local storage, and others
01:28:59 [Nikunj]
avk: used also in post message
01:29:31 [Nikunj]
avk: waiting until file API to add file upload
01:29:46 [Nikunj]
avk: also waiting to append file blobs
01:29:58 [Nikunj]
avk: browser would send multipart form-data when you do send
01:30:05 [Nikunj]
avk: similar to raw html forms no
01:30:20 [Nikunj]
avk: if we can support this API then we don't need a FileList in the API
01:30:30 [Nikunj]
avk: could be Jeremy Orlow
01:31:40 [Nikunj]
avk: append files or strings on formdata object
01:31:50 [Nikunj]
so that we don't need a method on XHR
01:32:18 [Nikunj]
avk: its been requested to serialize an html form and pass it to XHR
01:32:29 [Nikunj]
avk: so you can asynchronously upload it
01:32:38 [Nikunj]
avk: others requested - blob
01:32:49 [Nikunj]
avk: WebKit supports FileList
01:33:04 [Nikunj]
ar: File is supported in Mozilla
01:33:16 [Nikunj]
sw: WebKit also supports a single File
01:33:25 [Nikunj]
jonas: do you send the file name anywhere?
01:33:30 [Nikunj]
avk: no
01:33:32 [Nikunj]
sw: no
01:33:36 [Nikunj]
avk: how would you?
01:33:42 [Nikunj]
jonas: use some kind of header
01:33:48 [Nikunj]
avk: authors can add a headers
01:33:54 [Nikunj]
sw: we don't
01:34:10 [Nikunj]
arun: send a blob and a hypothetical object
01:34:36 [Nikunj]
avk: send would be extended to accept Blob and FormData
01:34:42 [arun]
where FormData = hypothetical object
01:34:53 [Nikunj]
avk: For FormData, the UA would set the content-type header if the author did not set it
01:35:17 [Nikunj]
arun: Is Hixie writing FormData?
01:35:25 [Nikunj]
avk: No I will do it - a small edit
01:35:40 [Nikunj]
arun: FormData append would accept a Blob?
01:35:43 [Nikunj]
avk: It would
01:36:02 [Nikunj]
avk: It seems that this would address several requests
01:36:17 [Nikunj]
arun: It seems to - a requirement that was not adequately addressed by FileAPI
01:36:53 [Nikunj]
avk: MS has a proprietary extension exposed to VBScript called ResponseBody that returns a byte array or byte stream
01:37:04 [Nikunj]
avk: we could use it or rename it to ResponseBlob
01:37:10 [Nikunj]
avk: Unless MS cares for it
01:37:18 [Nikunj]
adrian: we would like to carry on using it
01:37:31 [Nikunj]
mjs: It should not be a blob, but rather a byte array
01:37:59 [Nikunj]
mjs: Blob offers only async, and if the data is already loaded then array is better
01:38:06 [Nikunj]
mjs: should not do another async
01:38:22 [Nikunj]
jonas: only thing is if you are loading a big thing, then ua will be forced to keep it in memory
01:38:36 [Nikunj]
mjs: if loading something bigger than address space, then store it
01:38:49 [Nikunj]
jonas: not looking for large streams
01:39:42 [Nikunj]
mjs: ideally ua should download large files through streaming model
01:39:57 [Nikunj]
mjs: assuming its a file object stream to a file
01:40:09 [Nikunj]
avk: and then access the file
01:40:18 [Nikunj]
avk: responseText already loads in to memory
01:40:28 [Nikunj]
mjs: turn off storing in memory if its large
01:40:46 [Nikunj]
avk: need ECMA to figure out a binary type array
01:40:54 [Nikunj]
avk: should not be that hard - like image data
01:41:00 [Nikunj]
mjs: easy to make complicated
01:41:19 [Nikunj]
mjs: if its immutable, then it is easy to use the raw bytes as backing store
01:41:30 [Nikunj]
mjs: no thread safety issue even if passed to workers
01:41:42 [Nikunj]
mjs: immutable is harder to modify
01:41:59 [Nikunj]
mjs: most APIs make two versions of APIs available - mutable and not
01:42:06 [Nikunj]
avk: ImageData is immutable
01:42:13 [Nikunj]
mjs: backing store is canvas
01:42:40 [Nikunj]
jonas: byte array building API might be a good way to mutate ResponseBlob
01:42:49 [Nikunj]
jonas: look forward to mjs' proposal
01:43:09 [Nikunj]
avk: response thing and new things for sending out are new items
01:43:27 [Nikunj]
avk: timeout proposal is also new
01:43:36 [Nikunj]
avk: ontimeout listener for milliseconds timeout
01:43:49 [Nikunj]
avk: if the server doesn't respond, then do the abort thing and dispatch timeout event
01:43:55 [Nikunj]
avk: timeout needs to be sorted out
01:44:20 [Nikunj]
jonas: two arguments - sync XHR doesn't allow timeout
01:44:32 [Nikunj]
jonas: not allowing timeout doesn't preclude users from using it
01:44:39 [Nikunj]
avk: use workers
01:44:53 [Nikunj]
jonas: provide timeouts so that user experience is slightly better
01:44:59 [Nikunj]
avk: are you providing them?
01:45:01 [Nikunj]
jonas: yes
01:45:14 [Nikunj]
avk: timeouts are something that you should certainly have
01:45:27 [Nikunj]
jonas: almost everyone using XHR uses it anyway, so provide a convenience function
01:45:38 [Nikunj]
jonas: MS added it to XDR?
01:45:41 [Nikunj]
adrian: yes
01:45:48 [Nikunj]
sam: is it a default or an attribute?
01:45:53 [Nikunj]
adrian: attribute
01:45:59 [Nikunj]
avk: what does it do on getting?
01:46:08 [Nikunj]
jonas: its a set only
01:46:14 [Nikunj]
avk: does such a thing exist?
01:46:27 [Nikunj]
travis: doing a quick test
01:46:32 [Nikunj]
jonas: what's a good default value
01:46:39 [Nikunj]
travis: or do you timeout at all
01:46:52 [Nikunj]
adrian: if not set, it doesn't
01:46:59 [Nikunj]
adrian: so the behavior is not changed
01:47:13 [Nikunj]
adrian: XHR also has the like named attribute
01:47:34 [Nikunj]
jonas: very inclined to add the attribute to XHR2 spec
01:47:54 [Travis]
Travis has joined #webapps
01:48:01 [Nikunj]
sam: concern - putting in the hands of the user, what is the stall for the ua?
01:48:08 [Nikunj]
sam: 10 ms is OK or 100 is OK?
01:48:14 [Nikunj]
sam: in the past any amount was OK
01:48:20 [Travis]
Reading IE's timeout property (before setting) returns -1.
01:49:13 [Nikunj]
avk: testing in different conditions, like a slow network, may find odd behavior but the other person in a good one doesn't
01:49:40 [Nikunj]
adrian: common use cases are sites doing click tracking, trying to capture when someone clicked a link
01:50:01 [Nikunj]
adrian: OK with losing data when a request is not fired in the timeout
01:50:20 [Nikunj]
adrian: here's a request to make and if the request doesn't respond we give up
01:50:36 [Nikunj]
avk: better option available - html5 ping attribute
01:51:11 [Nikunj]
adrian: there are other issues being raised, that make the option controversial and this WG is not the right forum to discuss
01:51:22 [Nikunj]
avk: not opposed to adding it, concerned that it will be abused
01:51:27 [Nikunj]
jonas: in what way?
01:51:31 [Nikunj]
avk: use sync more
01:51:48 [Nikunj]
jonas: what will help most is a test suite guide
01:52:02 [Nikunj]
jonas: go through the spec and not follow it closely, although well followed,
01:52:14 [Nikunj]
jonas: edge cases are where we differ, otherwise everyone is close
01:52:22 [Nikunj]
avk: but that makes it look pretty broken
01:52:41 [Nikunj]
jonas: not material adding new features to newer versions to getting bugs fixed
01:53:14 [Nikunj]
avk: explicit constructor for XO requests
01:53:24 [Nikunj]
jonas: that conversation is sort of CORS-existential one
01:53:28 [Nikunj]
avk: agreed
01:53:56 [Nikunj]
jonas: interesting idea to have a totally anonymous XHR object, both for X-S and S-S request
01:54:20 [Nikunj]
travis: which is XDR
01:54:25 [Nikunj]
jonas: but that sends Origin
01:55:16 [Nikunj]
avk: proposed resolution on timeouts for XHR2
01:55:26 [Nikunj]
avk: to add
01:56:12 [Nikunj]
nikunj: would we do it to file?
01:56:17 [ArtB]
ArtB has joined #webapps
01:56:21 [Nikunj]
jonas: not required to follow a single style in general
01:56:29 [Nikunj]
jonas: hesitant to draw a connection?
01:56:45 [Nikunj]
adrian: a case to be made for XHR things to be repeated elsewhere
01:56:51 [Nikunj]
adrian: timeout is not one of those things
01:57:03 [Nikunj]
adrian: network requests cause timeouts to matter
01:57:25 [Nikunj]
adrian: it seems less likely to need them for files
01:57:34 [Nikunj]
jonas: much less likely for a file request to time out
01:57:47 [Nikunj]
sam: network files time out
01:57:50 [Nikunj]
adrian: edge case
01:58:08 [Nikunj]
avk: also need resolution on FormData
01:58:17 [Nikunj]
jonas: iffy about that
01:58:36 [Nikunj]
jonas: seems weird to create a new object for creating an object only to send to another one
01:58:42 [Nikunj]
avk: not ugly, can reuse it
01:58:49 [Nikunj]
sam: websockets may also want to do it
01:58:52 [Nikunj]
jonas: really?
01:58:58 [Nikunj]
everyone: laughing loud
01:59:13 [Nikunj]
chaals: consensus?
01:59:23 [Nikunj]
sam: I don't object, not excited
01:59:33 [Nikunj]
jonas: it helps to abort a connection if it takes too long
01:59:46 [Nikunj]
sam: agreed, but not a strong enough reason because that might be only one of the ways to do it
01:59:56 [Nikunj]
jonas: could use setTimeout
02:00:08 [Nikunj]
jonas: risk that people may use sync XHR more
02:00:18 [Nikunj]
jonas: we fired timeouts during syncXHR
02:00:24 [Nikunj]
jonas: fallback was to wait longer
02:00:30 [Nikunj]
jonas: not ideal
02:00:46 [Nikunj]
jonas: some people may never switch away from sync XHR?
02:00:59 [Nikunj]
adrian: we shipped timeouts
02:01:21 [Nikunj]
adrian: good idea
02:01:40 [Nikunj]
chaals: any objections?
02:01:47 [Nikunj]
sam: risks in either direction
02:02:04 [Nikunj]
adrian: also supported for sync XHR
02:02:14 [Nikunj]
RESOLUTION: Anne to put timeout attribute in XHR
02:02:34 [Nikunj]
avk: Proposal to overload send for Blob objects
02:02:49 [Nikunj]
avk: FormData contains a constructor and accepts either Blob or DOMString
02:03:02 [Nikunj]
which serializes as multipart/form-data
02:03:17 [Nikunj]
sam: support strongly Send Blob with File
02:03:32 [Nikunj]
sam: other one need to see a proposal and remove it if that looks terrible
02:03:40 [Nikunj]
jonas: feels same way
02:03:40 [anne]
02:04:12 [Nikunj]
RESOLUTION: Copy and paste this into the proposal on FormData and Blobs
02:04:47 [Nikunj]
jonas: like to implement streaming
02:05:58 [Nikunj]
jonas: 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
02:06:06 [Nikunj]
avk: can we use server sent events?
02:06:17 [Nikunj]
jonas: this is not for that, but for large files
02:06:34 [Nikunj]
jonas: its started from server sent events, but different
02:06:42 [Nikunj]
avk: use cases are required
02:06:55 [Nikunj]
chaals: good proposal not quite a finished
02:07:25 [Nikunj]
chaals: need a meatier proposal
02:07:28 [Nikunj]
jonas: would do
02:07:37 [Nikunj]
chaals: how far from XHR?
02:07:53 [Nikunj]
avk: ask jonas, sam, and adrian
02:08:03 [Nikunj]
avk: if everyone finishes implementation, then we are done
02:08:19 [Nikunj]
jonas: start writing test cases
02:08:34 [Nikunj]
adrian: take it first to LC, then the test suites will happen before CR
02:08:57 [Nikunj]
avk: ISSUE-33 needs to be resolved first
02:09:10 [Nikunj]
travis: it is already re-entrant
02:09:15 [Nikunj]
chaals: so we can close the issue?
02:09:35 [Nikunj]
jonas: can we go to LC?
02:09:42 [Nikunj]
chaals: we need a formal vote
02:09:49 [Nikunj]
avk: need to edit the spec first
02:10:18 [Nikunj]
RESOLUTION: Close ISSUE-33 because everyone is re-entrant
02:10:47 [Nikunj]
chaals: should we take anne's draft to LC?
02:11:01 [Nikunj]
avk: this is the third LC
02:11:15 [Nikunj]
chaals: RESOLUTION: XHR goes to Last Call
02:11:40 [Nikunj]
chaals: meeting is adjourned
02:13:32 [chaals]
rrsagent, draft minutes
02:13:32 [RRSAgent]
I have made the request to generate chaals
02:13:35 [jorlow]
jorlow has joined #webapps
02:17:22 [Marcos]
Marcos has joined #webapps
02:19:02 [shiki]
shiki has left #webapps
02:20:54 [anne]
anne has left #webapps
03:16:20 [Zakim]
Zakim has left #webapps
03:19:07 [Nikunj]
Nikunj has joined #webapps
03:38:42 [mmielke]
mmielke has joined #webapps
03:44:02 [arun]
arun has joined #webapps
03:52:08 [mmielke]
mmielke has joined #webapps
03:59:09 [sicking]
sicking has joined #webapps
04:01:42 [jorlow]
jorlow has joined #webapps
04:07:24 [jorlow]
jorlow has joined #webapps
04:31:39 [Nikunj]
Nikunj has joined #webapps
04:42:49 [jorlow_]
jorlow_ has joined #webapps
04:43:19 [mjs]
mjs has joined #webapps
05:27:50 [jorlow]
jorlow has joined #webapps
05:53:30 [jorlow_]
jorlow_ has joined #webapps
06:07:47 [johnnyg]
johnnyg has joined #webapps
06:37:54 [Marcos]
Marcos has joined #webapps
06:42:57 [DanC]
DanC has joined #webapps
06:50:42 [timeless_mbp]
timeless_mbp has joined #webapps
06:58:56 [hober]
hober has joined #webapps
07:11:25 [shepazu]
shepazu has joined #webapps
07:25:38 [arve]
arve has joined #webapps
07:28:16 [weinig]
weinig has joined #webapps
07:35:08 [Marcos]
Marcos has joined #webapps
08:25:44 [Nikunj1]
Nikunj1 has joined #webapps
08:59:26 [Nikunj]
Nikunj has joined #webapps
12:04:14 [smaug_]
smaug_ has joined #webapps
12:58:34 [arun]
arun has joined #webapps
13:32:02 [annevk]
annevk has joined #webapps
14:50:54 [ArtB]
ArtB has joined #webapps
15:00:48 [aroben]
aroben has joined #webapps
15:02:29 [johnnyg]
johnnyg has joined #webapps
15:09:28 [Nikunj]
Nikunj has joined #webapps
15:11:05 [noahm]
noahm has joined #Webapps
15:27:05 [shepazu]
shepazu has joined #webapps
15:28:45 [mmielke]
mmielke has joined #webapps
15:51:51 [Marcos]
Marcos has joined #webapps
16:09:29 [Marcos]
Marcos has joined #webapps
16:10:20 [tlr]
tlr has joined #webapps
16:24:57 [weinig]
weinig has joined #webapps
16:31:25 [ArtB]
ArtB has joined #webapps
16:34:06 [dom]
dom has left #webapps
16:35:39 [AdamB]
AdamB has joined #webapps
16:37:00 [soonho]
soonho has joined #webapps
16:37:13 [soonho]
soonho has left #webapps
16:37:27 [darobin]
darobin has joined #webapps
16:47:03 [mmielke]
mmielke has joined #webapps
16:48:14 [shiki]
shiki has joined #webapps
16:49:21 [shiki]
shiki has joined #webapps
16:53:17 [AdamB]
AdamB has joined #webapps
16:53:33 [pererik]
pererik has joined #webapps
16:57:15 [timeless_mbp]
timeless_mbp has joined #webapps
16:58:07 [AdamB]
AdamB has left #webapps
16:59:28 [arve]
arve has joined #webapps
17:00:32 [chaals]
chaals has joined #webapps
17:00:49 [Zakim]
Zakim has joined #webapps
17:03:09 [ArtB]
ArtB has joined #webapps
17:03:30 [JonathanJ]
JonathanJ has joined #webapps
17:05:34 [Nikunj]
Nikunj has joined #webapps
17:06:08 [VagnerW3CBrasil]
VagnerW3CBrasil has joined #webapps
17:09:00 [sicking]
sicking has joined #webapps
17:09:23 [Marcos]
Marcos has joined #webapps
17:09:38 [sicking]
17:09:41 [Kai]
Kai has joined #webapps
17:09:43 [sicking]
scribe:s icking
17:09:49 [sicking]
scribe: sicking
17:10:04 [tlr]
tlr has joined #webapps
17:10:18 [weinig]
[The spec we will discussing is available at]
17:10:34 [Vladimir]
Vladimir has joined #webapps
17:11:10 [annevk]
annevk has joined #webapps
17:11:54 [Lachy]
Lachy has joined #webapps
17:11:59 [sicking]
topic: WebIDL yo
17:13:10 [sicking]
AR: Arun
17:13:47 [chaals]
Present: Chaals, Sam, Per Erik, Vladimir, Satoshi, Shiki, Arun, Nikunj, Anne, Rob, Lachlan, Jonas, Travis, Adrian,
17:14:39 [sicking]
SW: introduction about webidl
17:15:02 [Travis]
Travis has joined #webapps
17:16:35 [weinig]
17:16:40 [sicking]
AR: there's some things that are still left loose, we should define those stricter
17:16:52 [sicking]
SW: ok, got specific issues?
17:17:04 [sicking]
AR: how are exceptions done?
17:17:18 [sicking]
AR: missing primitives like ByteArray
17:17:30 [sicking]
SW: have to check spec re exceptions
17:17:45 [sicking]
SW: re bytearray, it's a question of scope
17:18:35 [sicking]
SW: spec already big. Contains gramar, some basic primitives like getters/setters/stringifyers, also some types and extended attributes
17:18:48 [sicking]
SW: sequences would be useful
17:19:24 [sicking]
JS: need to define what exactly a seqnece is
17:19:53 [sicking]
SW: sequence is a JS array, array is a host object
17:19:53 [howard]
howard has joined #webapps
17:19:55 [weinig]
17:20:05 [shepazu]
shepazu has joined #webapps
17:20:33 [sicking]
SW: NodeList seems to map closer to array
17:20:57 [sicking]
JS: NodeList is readonly, so can't be a simple JS-array
17:21:33 [sicking]
NM: is anyone actually using Array?
17:21:53 [sicking]
17:22:42 [sicking]
SW: don't know of any specs that use it. Maybe NodeList could be expressed as an Array
17:23:11 [sicking]
SW: might not be worth putting Array in v1 if no one is using it
17:23:31 [howard]
howard has joined #webapps
17:23:41 [annevk]
hmm, I think sequence<> needs to map to an object that has item() and length; is that the case?
17:24:15 [sicking]
TL: TC-39 is taking interest
17:24:16 [MikeSmith]
MikeSmith has joined #webapps
17:24:17 [annevk]
well, it would be nice to have a shorthand for NodeList like interfaces
17:24:23 [howard]
howard has left #webapps
17:24:24 [annevk]
not sure if it needs to be sequence<>
17:24:37 [sicking]
TL: I expressed it to them as an grammar language, and a binding language
17:25:05 [sicking]
TL: they took a lot interest in the binding part
17:25:49 [sicking]
TL: TC-39 expressed interest in owning the JS bindings, claiming they had more expertize
17:26:04 [Lachy]
Lachy has joined #webapps
17:26:09 [sicking]
SW: I think the main value of webidl is the bindings, not so much the grammar
17:26:16 [sicking]
TL: agreed
17:26:28 [sicking]
AvK: also value for spec authors
17:26:50 [sicking]
SW: concerned about splitting out bindings
17:27:00 [sicking]
TL: then they should be able to participate
17:27:05 [sicking]
SW: most definitely
17:27:27 [Vladimir]
Vladimir has joined #webapps
17:28:02 [sicking]
DS: I'm also concerned about splitting it. Splitting things in two leads to overhead and poor coordination
17:28:02 [chaals]
Present+ Maciej
17:28:09 [chaals]
Present+ Doug
17:28:24 [sicking]
Present+ Sicking
17:28:43 [MikeSmith]
RRSAgent, make minutes
17:28:43 [RRSAgent]
I have made the request to generate MikeSmith
17:28:44 [sicking]
SW: there are things we could split, like deprecated features
17:29:00 [arun]
arun has joined #webapps
17:29:02 [mjs]
mjs has joined #webapps
17:29:04 [sicking]
annevk, that's how I roll
17:29:27 [shepazu]
s/coordination/coordination... I would be happy to have it worked on jointly, if we can do that, and public-script-coord should help
17:29:53 [sicking]
MJS: even such a split is concerning. Similar to how ecmascript leaves host objects largely undefined
17:29:57 [sicking]
SW: agreed
17:30:05 [MikeSmith]
Present+ MikeSmith
17:30:21 [sicking]
MJS: explicitly noting that certain things are deprecated could still be done
17:30:45 [annevk]
Present+ Julian
17:30:53 [sicking]
TL: do we know what we want to mark as deprecated
17:31:05 [sicking]
SW: custom deleters
17:31:18 [sicking]
MJS: also catch-alls in general
17:31:44 [sicking]
MJS: not neccesarily consencus that catchalls are always bad
17:32:14 [sicking]
MJS: separately, seems to be consensus that array-like accessors are ok
17:32:28 [sicking]
AvK: what does "deprecated" even mean?
17:32:50 [sicking]
SW: that a feature shouldn't be used in new interfaces, but is described for legacy reasons
17:33:01 [Nikunj]
Nikunj has joined #webapps
17:33:45 [sicking]
MJS: multiple inheritance might not be needed by existing browsers
17:33:57 [sicking]
MJS: however SVG uses it
17:34:29 [sicking]
MJS: browsers don't seem to implement SVGs stuff as real multiple inheritance. Simply implemented as separate interfaces
17:35:05 [sicking]
TL: there is a desire from TC-39: don't allow bindings to do things that aren't allowed by ecmascript itself
17:35:22 [sicking]
TL: want to be able to implement DOM in ecmascript
17:36:29 [sicking]
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
17:37:51 [sicking]
TL: want to mark things that will *never* be part of ES as deprecated
17:38:03 [sicking]
SW: how to we determine what will never be part of ES?
17:38:22 [sicking]
MJS: It's very hard. Not even catchalls are for sure never going to be a part of ES
17:38:37 [sicking]
CM: guessing the future is hard
17:39:14 [sicking]
DS: when do we expect webidl to progress to LC and beyond
17:39:29 [sicking]
DS: and all those other fuzzy W3C rules
17:39:34 [Lachy]
Lachy has joined #webapps
17:39:50 [sicking]
SW: depends on what people want from spec
17:40:03 [sicking]
SW: it's really a tool for spec authors
17:40:52 [sicking]
MJS: changing the spec to use ES5 formalisms is a big change
17:41:07 [sicking]
TL: ES5 has accessors, rewriting to use those will take work
17:41:43 [sicking]
DS: Robin wanted to publish sooner rather than later
17:42:23 [sicking]
MJS: there's tradeoffs, there's many specs that want to use it
17:43:11 [sicking]
SW: I'm not all that familiar with W3C rules quite yet
17:43:17 [sicking]
DS: This is an unusual spec
17:43:49 [sicking]
DS: the implementations for this spec are other specs
17:44:17 [sicking]
SW: Also testcases. You can produce a lot of tests based only on the idl
17:44:33 [sicking]
SW: Want a tool that given an idl produces tests
17:45:04 [sicking]
SW: browsers are also implementors
17:45:52 [sicking]
DS: sort of circular dependency. Won't know that things worked until another spec has used webidl and that spec got implemented
17:46:51 [sicking]
MJS: we could take a stable spec, such as DOM Core, and express it using webidl
17:47:03 [sicking]
DS: Cameron did that
17:47:30 [sicking]
SW: would come close, but doesn't test everything. Might also want to do for example canvas to test overloading
17:48:21 [sicking]
MJS: should start with dom core and see what coverage that gets us. But yes, canvas would cover a lot of nice things
17:48:48 [sicking]
RE: has anyone does a matematical analysis of webidl? Would that be useful?
17:49:08 [sicking]
SW: don't know. If anyone has done it, cameron has, he loves math. But don't think he has
17:50:24 [sicking]
SW: OMG doesn't define enough things. That's why specs had bindings sections. But even those aren't enough, and might not be normative
17:51:57 [sicking]
SW: changing spec to use ES5 terminology will be a big change, but not a functional change
17:52:35 [sicking]
NM: is it a requirement for going to last call
17:52:54 [sicking]
AvK: doesn't make sense to define things in terms of ES3 if everyone implements ES5
17:53:59 [sicking]
DS: when you make that change, document how you map old terminology to ES5 terminology
17:54:15 [sicking]
SW: good idea
17:54:38 [sicking]
SW: not sure about some features in the spec. One is method overloading
17:54:46 [weinig]
17:55:06 [sicking]
TL: hard to have an opinion, cause it's hard to understapnd spec
17:55:20 [sicking]
SW: that's part of the problem
17:56:15 [sicking]
AvK: canvas and XHR uses overloading, though in different ways
17:56:49 [sicking]
TL: we have default values for optional arguments
17:57:01 [sicking]
TL: we use it for XHR
17:58:09 [sicking]
SW: when i started on webkit, we had hand-written code that implemented the bindings. We still have a custom IDL
17:58:58 [sicking]
MJS: we currently have one-offs for all overloads. Would like to use webidl to express and implement it instead
18:00:49 [sicking]
JS: not sure we can use idl with overloads directly
18:01:02 [sicking]
MJS: you can use whatever solution you're currently using
18:01:57 [sicking]
MJS: webidl has optional. Limited by that each argument is optional. Can't enforce that either 0 or 2 arguments are provided
18:02:39 [sicking]
MJS: if optional could be in batches, then you could require that the other arguments must differ in type
18:03:14 [sicking]
JS: errors seem to be ambigious
18:05:03 [sicking]
MJS: one problem is that anything that takes a string essentially accepts anything since anything can be converted to string
18:06:12 [sicking]
VD: 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?
18:06:35 [Lachy]
Lachy has joined #webapps
18:07:18 [sicking]
TL: i think action should be to clarify the spec and then we can discuss what we want behavior to be
18:08:30 [sicking]
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
18:08:46 [sicking]
18:09:38 [sicking]
JS: I think TC-39 will have strong opinions on this. I know mark miller did
18:09:50 [sicking]
MJS: not sure i understand MMs objection
18:11:56 [sicking]
MJS: one issue is that overloads allows overloads to be added in [supplemental] interfaces. Would not match ES5 implementations
18:12:18 [sicking]
SW: we could forbid overloading in supplementals
18:14:30 [sicking]
...discussions about XHR...
18:16:11 [sicking]
SW: 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
18:16:31 [sicking]
SW: i'd also like to know how you reference one of the specific overloads
18:17:26 [sicking]
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
18:18:04 [sicking]
TL: problem is that we have a spec that's hard to understand. Using union types might make it easier for people to understand it
18:18:55 [sicking]
CM: would like to wrap up
18:19:12 [sicking]
darobin, no union types for you!
18:19:45 [sicking]
SW: we need to figure out replaceable
18:20:00 [sicking]
TL: I'm also concerned about mixin's
18:21:00 [sicking]
TL: TC-39 would like to deprecate callable objects
18:22:08 [sicking]
JS: gecko only has a single object that's callable, the document.all object
18:22:21 [sicking]
SW: would like to remove getters/setters without name
18:23:10 [sicking]
TL: remove it
18:24:07 [sicking]
MJS: from javascripts point of view it doesn't have a behavioural difference
18:24:25 [sicking]
CM: proposed resolution: nuke it
18:24:54 [sicking]
DS: remove it but put a note that you did so, so that people can whine
18:25:23 [sicking]
RESOLUTION: remove unnamed getters/setters
18:26:35 [Travis]
Action: weinig to clarify method overloading section and make it readable
18:26:35 [trackbot]
Created ACTION-439 - Clarify method overloading section and make it readable [on Samuel Weinig - due 2009-11-10].
18:27:41 [sicking]
SW: not sure if supplemental should be an extended attribute or some other type of syntax. Should take it later due to out of time
18:27:47 [sicking]
TL: I don't care
18:28:39 [chaals]
しき:should be core
18:28:39 [sicking]
SO: i'd prefer a separate syntax
18:28:53 [sicking]
hands off my editing!
18:28:59 [sicking]
18:31:01 [sicking]
SW: who volunteers to provide tests?
18:31:36 [sicking]
SO: i do!
18:32:12 [sicking]
s/who volunteers to provide tests/who volunteers to provide DOM L2 based tests/
18:32:33 [chaals]
s/provide/fish out and expand on heycam's/
18:33:34 [MikeSmith]
18:33:38 [sicking]
JS: I'll do the DOM 2 ones
18:34:10 [MikeSmith]
RRSAgent, make minutes
18:34:10 [RRSAgent]
I have made the request to generate MikeSmith
18:34:22 [sicking]
s/SO: i do!//
18:34:43 [sicking]
SO: I'll do C++ tests
18:34:48 [MikeSmith]
18:35:01 [Lachy]
18:35:14 [sicking]
Topic: Selectors
18:35:15 [Lachy]
18:35:18 [MikeSmith]
RRSAgent, make minutes
18:35:18 [RRSAgent]
I have made the request to generate MikeSmith
18:35:31 [sicking]
LH: i need to finish up test suite
18:35:59 [sicking]
LH: spec is ready for CR, can do tests in parallel
18:36:14 [sicking]
TL: namespace resolvers still out?
18:36:32 [sicking]
LH: yes, may potentially be in selectors L2
18:37:34 [Lachy]
18:37:39 [sicking]
18:39:27 [root]
root has joined #webapps
18:51:39 [smaug_]
smaug_ has joined #webapps
18:58:06 [markusm]
markusm has joined #webapps
19:05:45 [chaals]
Topic: DOM 3 Events
19:06:07 [mjs]
mjs has joined #webapps
19:09:00 [ArtB]
ArtB has joined #webapps
19:10:06 [gsnedders]
gsnedders has joined #webapps
19:11:31 [Hixie]
19:11:51 [mjs]
won't be there (but thanks)
19:12:04 [chaals]
Present+ Ishida, Addison, NorbertL
19:12:22 [chaals]
Present+ Hixie
19:12:38 [sicking]
Scribe: Sicking
19:13:22 [ArtB]
ArtB has changed the topic to: WebApps agenda Nov 3:
19:13:38 [chaals]
Present+ Mike™
19:13:46 [sicking]
DS: suggestion to make key values, instead of being "\\u1234", to be "\u1234". I.e. be the actual character
19:13:47 [darobin]
darobin has joined #webapps
19:13:57 [JonathanJ]
JonathanJ has joined #webapps
19:14:22 [shepazu]
19:14:50 [sicking]
AP: this results in a surrugate pair being the value
19:14:58 [shepazu]
19:15:03 [sicking]
AP: this problem didn't exist with the old "U+1234" syntax
19:16:19 [sicking]
JS: is this a problem?
19:16:36 [sicking]
AP: it means to get the actual character value you might need to decode the surrugate pair
19:16:47 [sicking]
19:16:51 [sicking]
(i follow standards)
19:17:27 [sicking]
AP: there are lots of surrogate characters
19:17:36 [sicking]
AP: and more with time
19:18:19 [sicking]
DS: maciej wasn't sure that there are keys that result in a non BMP character
19:18:26 [sicking]
DS: however there appears there are
19:18:55 [sicking]
DS: characters "tree stub" and "untidy" are such characters
19:19:15 [mjs]
my old suggestion of "\u1234" was meant to suggest the values should be a string of the actual character
19:19:44 [mjs]
so for example the identifier when you press lowercase a would be the string "a"
19:19:47 [Marcos]
Marcos has joined #webapps
19:20:02 [sicking]
IH: for people that compare with a string, then the fact that it's a surrogate pair then this isn't a problem
19:20:17 [sicking]
DS: complicated in some situations
19:20:19 [sicking]
IH: when?
19:20:38 [sicking]
DS: when people use lots of supplementary characters in the script. Maybe
19:20:59 [sicking]
JS: can someone show code that they are concerned about won't work
19:21:24 [VagnerW3CBrasil]
VagnerW3CBrasil has joined #webapps
19:23:08 [sicking]
...confusion about what is actually suggested...
19:25:07 [chaals]
[Do you get "U+1234" or "æ" or "\u1234" and is there any reason to distinguish the second and third cases?]
19:28:13 [chaals]
Scribe: chaals
19:28:48 [chaals]
RI: You take a character outside BMP, and your javascript escape is "\1234\5678"
19:29:09 [chaals]
PA: The string that is the individual character is length 2
19:29:58 [sicking]
RI: why move away from the "U+1234" format?
19:31:27 [Zakim]
Zakim has left #webapps
19:31:28 [MikeSmith]
RRSAgent, make minutes
19:31:28 [RRSAgent]
I have made the request to generate MikeSmith
19:31:39 [Zakim]
Zakim has joined #webapps
19:31:46 [chaals]
q+ sicking
19:32:03 [tlr]
tlr has joined #webapps
19:32:27 [chaals]
q+ rob
19:32:40 [sicking]
DS: if i'm trying to limit a form to just one character, i might reject surrogate pair characters
19:33:15 [weinig]
19:33:18 [annevk]
19:33:48 [weinig]
19:33:59 [shepazu]
q+ r12a
19:34:11 [chaals]
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
19:34:24 [sicking]
JS: my concern is that we're trying to work around behavior in ES
19:34:40 [Kai]
Kai has joined #webapps
19:34:47 [chaals]
ack si
19:34:52 [chaals]
ack rob
19:34:53 [sicking]
AP: i just want people to know what the ramifications are, and that we make it clear in spec
19:36:54 [MikeSmith]
19:37:09 [sicking]
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
19:37:45 [sicking]
RE: for keys like "F1" we can use a different field
19:37:46 [chaals]
ack annevk
19:38:15 [sicking]
AvK: the way javascript deals with i18n should be an orthogonal issue
19:39:08 [shepazu]
19:39:13 [sicking]
AP: we should follow the way that javascript deals with i18n
19:39:19 [chaals]
ack r12
19:39:23 [sicking]
AP: even if that isn't perfect
19:40:07 [sicking]
RI: i want to know how this is expected to be used
19:40:38 [sicking]
RI: if you just want a label for what was pressed then "U+1234" syntax seems better
19:40:55 [chaals]
ack she
19:41:05 [sicking]
RI: so trying to understand what the use cases and expected uses are
19:41:19 [sicking]
DS: comparisons often
19:42:49 [chaals]
JS: If the characters are described as double-escaped bytes, you can still do comparison with them
19:43:09 [Hixie]
'\uFFFF' < '\u10FFF' => false
19:44:07 [fsasaki]
fsasaki has joined #webapps
19:44:55 [chaals]
Present+ Felix
19:45:12 [chaals]
JS: Does any use case run up against that painful gap in practice?
19:45:23 [sicking]
DS: range checks might also be common
19:46:40 [sicking]
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
19:47:51 [chaals]
IH: I think we are fine because I don't think we will meet the boundary case
19:47:55 [myakura]
myakura has joined #webapps
19:47:55 [chaals]
q+ anne
19:48:10 [shepazu]
19:48:10 [chaals]
ack anne
19:48:51 [sicking]
IH: in fact, the "U+1234" syntax compares even worse for range checks
19:49:31 [sicking]
AvK: I don't think we should try to work around ES problems
19:50:23 [chaals]
q+ addison
19:50:35 [chaals]
ack she
19:50:39 [chaals]
ack add
19:52:07 [sicking]
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.
19:52:22 [Hixie]
19:52:33 [sicking]
AP: if you tie yourself to UTF16, then that could be a problem.
19:52:38 [chaals]
ack hi
19:54:00 [sicking]
AI: if i have a ascii page, how would i use this
19:54:10 [pcastro]
pcastro has joined #webapps
19:55:27 [sicking]
AvK: the spec would simply say, U+1234, without quotes
19:55:36 [sicking]
AvK: that's what other specs do
19:56:13 [sicking]
DS: i was confused, but now i can see
19:56:51 [sicking]
IH: WebIDL will handle it
19:57:00 [sicking]
DS: will that be clear for authors
19:57:15 [sicking]
IH: should have a separate section that describes things for authors. You probably want that anyway
19:57:23 [sicking]
DS: i would like to express a resolution
19:57:47 [sicking]
s/DS: i would like to express a resolution//
19:58:55 [sicking]
RESOLUTION: the value will be a character. WebIDL will clarify how this is mapped to ES
20:00:24 [chaals]
s/RESOLUTION: the value will be a character. WebIDL will clarify how this is mapped to ES/RESOLUTION: The return value will be a DOMstring which is the character produced. We add a note explaining to authors what happens/
20:00:40 [shepazu]
action: shepazu to add clarification for authors of JS where the gotchas are
20:00:40 [trackbot]
Created ACTION-440 - Add clarification for authors of JS where the gotchas are [on Doug Schepers - due 2009-11-10].
20:00:42 [shepazu]
these are unicode scalar values
20:00:54 [tlr]
tlr has joined #webapps
20:00:56 [chaals]
RATIONALE: WebIDL makes sure that this comes back in the relevant form for whatever language you are using
20:01:14 [Hixie]
to aid developers we probably need to make the non-character values (like "F1") be not length-2
20:01:49 [Hixie]
e.g. "[F1]" or "*F1" or "F-1" or "Function1" or something
20:01:54 [MikeSmith]
20:02:33 [chaals]
NL: when I do 秀, how many events are there?
20:02:59 [annevk]
20:03:00 [chaals]
[it took me about a dozen key presses to make that character]
20:03:03 [annevk]
20:03:24 [annevk]
q+ to suggest we declare conversion methods out of scope
20:03:33 [sicking]
DS: when you have IME, you have there's a bunch of composition events'n'stuff
20:05:08 [sicking]
DS: the whole things is very complicated. Might be best for people to review the spec
20:05:27 [sicking]
AP: when should we review
20:05:37 [sicking]
CM: over lunch
20:05:43 [sicking]
DS: the sooner the better
20:05:58 [MikeSmith]
q+ to mention that i18n group is having IRI discussion from 1pm to 3pm
20:06:04 [sicking]
DS: spec should be pretty stable now. Especially with this latest resolution
20:06:16 [chaals]
ack ann
20:06:16 [Zakim]
annevk, you wanted to suggest we declare conversion methods out of scope
20:06:27 [sicking]
AvK: I propose we drop the conversion methods
20:07:00 [sicking]
DS: i would like to keep them
20:08:57 [chaals]
q+ sam
20:09:08 [sicking]
DS: we want people to deal with characters, so I think it's in scope
20:09:15 [MikeSmith]
q- later
20:09:28 [tlr_]
tlr_ has joined #webapps
20:09:42 [chaals]
q+ chaals
20:09:42 [sicking]
AvK: ES needs to solve it in a larger scope
20:09:47 [chaals]
ack sa
20:09:55 [chaals]
q- cha
20:10:17 [pcastro]
pcastro has left #webapps
20:10:20 [sicking]
SW: I think the right place to put it is on the ES String constructor, other languages have it there
20:11:15 [sicking]
SW: there are docs on the web that shows how to take a multibyte character and turn it into a numerical codepoint
20:11:15 [chaals]
q+ chaals
20:11:18 [sicking]
DS: the code is HUGE
20:11:24 [MikeSmith]
q- later
20:11:24 [sicking]
SW: no it's not
20:11:28 [sicking]
DS: yes it is
20:11:32 [sicking]
SW: no it's not
20:11:37 [chaals]
[it is 15 lines]
20:11:51 [shepazu]
20:12:28 [sicking]
DS: lets continue discussion later
20:13:47 [MikeSmith]
20:13:53 [MikeSmith]
ack chaals
20:14:08 [tlr]
tlr has joined #webapps
20:14:15 [sicking]
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
20:15:03 [sicking]
CM: who would rather move it to ecmascript
20:15:15 [sicking]
...straw poll is taken...
20:15:24 [chaals]
[Shepazu objects, no resolution]
20:18:01 [sicking]
DS: Hixie had requested that some events be defined in much greater detail, or be removed from the DOM L3 Events spec
20:18:13 [sicking]
AvK: I can represent hixie
20:18:37 [sicking]
AvK: Problem is that it's very fuzzily defined when certain events are dispatched
20:19:54 [sicking]
TL: it's not expected that DOM Events define exactly when the events are fired
20:20:10 [sicking]
TL: and that the hosting language should define that
20:20:16 [sicking]
20:20:49 [sicking]
TL: this was also raised with progress events yesterday
20:21:09 [sicking]
TL: resolution was to define what the event looks like, but let hosting specs define when they are fired
20:21:14 [weinig]
20:22:08 [sicking]
AvK: mouse events for example can be just generic events. Don't need to be in DOM Events spec
20:22:40 [arun]
20:22:53 [chaals]
ack si
20:22:56 [sicking]
DS: if there's a risk that hixie will raise objections, then i'd rather adress the issue sooner than later
20:23:58 [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.
20:24:31 [sicking]
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
20:24:39 [sicking]
oh, thanks chaals
20:24:53 [arve]
arve has joined #webapps
20:24:56 [sicking]
JS: though i don't know who would define mouse events since they seem cross language
20:25:11 [sicking]
AvK: possibly CSSOM could define mouse events
20:25:31 [annevk]
20:26:05 [sicking]
CM: sounds like a meta-discussion. Would like to see specific proposals
20:26:07 [chaals]
ack wei
20:27:02 [sicking]
SW: DOM Events seem like the wrong place to define when mouse events are fired since it involves hit testing
20:27:13 [sicking]
SW: some other spec or specs could define hit testing
20:27:29 [sicking]
CM: still sounds very meta to me
20:27:50 [arve]
arve has joined #webapps
20:28:40 [sicking]
RESOLUTION: convertKeyValue will be removed from DOM L3 Events
20:29:03 [chaals]
closing ISSUE-110
20:29:04 [sicking]
if you can't follow that part of this transcript, I don't blame you
20:29:06 [chaals]
in recess
20:29:07 [annevk]
(after further consideration DS withdraw his objection)
20:30:01 [annevk]
close ISSUE-110
20:30:01 [trackbot]
ISSUE-110 Should we remove the code-point conversion from the D3E spec? closed
20:35:47 [Marcos]
Marcos has joined #webapps
21:02:00 [Hixie]
i'm in i18n but i'd like to attend the database stuff
21:02:11 [Hixie]
so i'll be down when i can
21:08:33 [Nikunj]
Nikunj has joined #webapps
21:10:39 [MikeSmith]
MikeSmith has joined #webapps
21:12:24 [chaals]
ok. we start at 13.30
21:13:20 [Hixie]
just call me Hixie :-)
21:13:31 [Hixie]
or you can call him the Other Ian
21:13:33 [Hixie]
either works :-P
21:14:25 [Dashiva]
21:14:28 [tlr]
tlr has joined #webapps
21:15:10 [Marcos]
Marcos has joined #webapps
21:15:36 [chaals]
ageenda+ different storage systems
21:15:48 [chaals]
agenda+ different storage systems
21:15:52 [markusm]
markusm has joined #webapps
21:16:02 [chaals]
agenda+ Web DB (sqlite)
21:16:21 [chaals]
agenda+ WebSimpleDB
21:16:28 [chaals]
agenda+ datacache
21:17:37 [chaals]
zakim, allow this agendum 15 minutes
21:17:37 [Zakim]
I do not know what agendum has been taken up, chaals
21:18:37 [Hixie]
i can answer questions, not sure i have much to say though
21:19:07 [Hixie]
i'm happy to have a quick q&a
21:19:27 [chaals]
ok, we'll see if people have questions and schedule some time if so.
21:20:36 [Kai]
Kai has joined #webapps
21:21:35 [mjs]
mjs has joined #webapps
21:27:43 [Lachy]
Lachy has joined #webapps
21:28:29 [sicking]
sicking has joined #webapps
21:32:02 [annevk]
annevk has joined #webapps
21:32:08 [weinig]
weinig has joined #webapps
21:32:28 [shiki]
shiki has joined #webapps
21:32:58 [shepazu]
shepazu has joined #webapps
21:35:30 [chaals]
zakim, room for 4 for 90 minutes?
21:35:31 [Zakim]
ok, chaals; conference Team_(webapps)21:35Z scheduled with code 26631 (CONF1) for 90 minutes until 2305Z
21:36:08 [jorlow]
jorlow has joined #webapps
21:36:36 [Vladimir]
Vladimir has joined #webapps
21:36:54 [michaeln]
michaeln has joined #webapps
21:38:05 [Zakim]
Team_(webapps)21:35Z has now started
21:38:12 [Zakim]
21:38:28 [chaals]
zakim, widgets is really apis-db-stuff
21:38:28 [Zakim]
+apis-db-stuff; got it
21:38:41 [pcastro]
pcastro has joined #webapps
21:39:47 [adrianba]
adrianba has joined #webapps
21:40:04 [timeless]
ScribeNick: timeless
21:40:07 [chaals]
pablo, did you get the code?
21:40:07 [timeless]
Scribe: timeless
21:40:23 [pcastro]
yes, thanks, will call in in a minute
21:40:30 [chaals]
zakim, next agendum
21:40:30 [Zakim]
agendum 1. "different storage systems" taken up [from chaals]
21:40:38 [chaals]
zakim, agenda?
21:40:38 [Zakim]
I see 4 items remaining on the agenda:
21:40:39 [Zakim]
1. different storage systems [from chaals]
21:40:40 [Zakim]
2. Web DB (sqlite) [from chaals]
21:40:40 [Zakim]
3. WebSimpleDB [from chaals]
21:40:41 [Zakim]
4. datacache [from chaals]
21:40:43 [pererik]
pererik has joined #webapps
21:40:45 [timeless]
Topic: different storage systems
21:41:42 [Zakim]
+ +1.206.369.aaaa
21:41:43 [chaals]
agenda+ filesystem
21:41:45 [eric_uhrhane]
eric_uhrhane has joined #webapps
21:41:58 [chaals]
zakim, aaaa is Chris
21:41:58 [Zakim]
+Chris; got it
21:42:21 [Zakim]
21:42:33 [ifette]
ifette has joined #webapps
21:42:49 [Zakim]
21:42:59 [ifette]
Zakim, who's here?
21:42:59 [Zakim]
On the phone I see apis-db-stuff, Chris
21:43:01 [Zakim]
On IRC I see ifette, eric_uhrhane, pererik, adrianba, pcastro, michaeln, Vladimir, jorlow, shepazu, shiki, weinig, annevk, sicking, Lachy, mjs, Kai, markusm, tlr, MikeSmith,
21:43:05 [Zakim]
... Nikunj, arve, Zakim, JonathanJ, root, arun, chaals, timeless, aroben, hober, timely, Hixie, smaug, RRSAgent, karl, Dashiva, krijnh, fearphage, gavin_, gsnedders|work, inimino,
21:43:07 [Zakim]
... trackbot
21:43:49 [arun]
pcastro, are you on the phone as well?
21:43:53 [ifette]
Zakim, next agendum
21:43:53 [Zakim]
agendum 2. "Web DB (sqlite)" taken up [from chaals]
21:44:08 [chaals]
Topic: Multiple storage systems
21:44:15 [chaals]
zakim, allow this agendum 15 minutes
21:44:15 [Zakim]
ok, chaals
21:44:45 [timeless]
chaals: We have a lot of these. how many are in conflict. how many are competing
21:44:56 [Hixie]
IH: none and all respectively
21:44:58 [timeless]
sicking: Web DB and Web SimpleDB are competing
21:45:18 [timeless]
sicking: whatever we come up with for Web DB / Web Simple DB will replace a lot of localStorage
21:45:21 [Zakim]
21:45:38 [timeless]
IanF: Are people trying to throw localStorage out the window or discourage it?
21:45:51 [timeless]
sicking: the way things are going, localStorage is going to be racy
21:46:05 [timeless]
... even storing the numbers between 1 and 2, you should probably not use it
21:46:39 [timeless]
chaals: at opera, we implemented web db
21:46:50 [timeless]
... we looked at web simple db. we found web db nice and simple
21:47:29 [arun]
Web DB = The SQLite One
21:47:37 [arun]
WebSimpleDB = The Nikunj One
21:47:54 [chaals]
s/web db nice/the nikunj one/
21:48:02 [timeless]
chaals: we found Nikunj to be more to our liking
21:48:08 [pcastro]
arun: yes i'm on the phone as well, trying to follow
21:48:29 [timeless]
chaals: we have implemented Nikunj internally
21:49:15 [ifette]
21:49:25 [Travis]
Travis has joined #webapps
21:49:37 [timeless]
sicking: we don't have a data point
21:49:48 [timeless]
... we've had a lot of discussions, primarily with MS and Oracle
21:50:02 [timeless]
... Oracle stands behind Nikunj
21:50:08 [timeless]
... we've talked to a lot of developers
21:50:15 [timeless]
... the feedback we got is that we really don't want SQL
21:50:54 [timeless]
IanF: We've implemented WebDB
21:51:04 [timeless]
... we're about to ship it
21:51:23 [timeless]
MJS: We've implemented WebDB and have been shipping it for some time
21:51:27 [timeless]
... it's shipping in Safari
21:51:33 [annevk]
IanF: we're also interested in the Nikunj One
21:51:38 [timeless]
... the Chrome implementation shares some but not quite all of the code
21:51:53 [timeless]
... beside shipping it, web sites have versions that target the iPhone and use it
21:52:03 [timeless]
... we can't easily drop it in the near future for that reason
21:52:15 [timeless]
... In principal, having a storage mechanism that is more sound than localStorage
21:52:28 [timeless]
... but more simple than WebDB would be good
21:52:45 [timeless]
... wrt localStorage, the current bits indeed have race conditions
21:52:53 [timeless]
... but adding APIs could possibly fix it
21:53:14 [timeless]
... SimpleDB / WebDB is probably impossible because of <too much something>
21:53:37 [timeless]
jorlow: a large percentage of a lot of the web apps that google is looking at
21:53:44 [timeless]
... would need a large percentage of what is in SimpleDB
21:53:51 [timeless]
... in order to make an extended localStorage usable
21:54:10 [adrianba]
21:54:16 [timeless]
... it would be fine to make localStorage do it, but it would require a lot of SimpleDB
21:54:23 [timeless]
MJS: [lost]
21:54:37 [timeless]
Nikunj: [lost]
21:54:57 [timeless]
Nikunj: (to MJS) do you want to keep the API as is or the functionality as is
21:55:08 [timeless]
... the localStorage API is synchronous only
21:55:09 [chaals]
s/Nikunj: [lost]/We can make simpleDB do everything localstorage does/
21:55:23 [timeless]
MJS: you would need to do a superset in order to handle locking
21:55:29 [chaals]
21:55:33 [timeless]
jorlow: Google is not happy with the various proposals
21:55:34 [chaals]
ack adrianba
21:56:03 [timeless]
AB: Microsoft's position is that WebSimpleDB is what we'd like to see
21:56:19 [timeless]
... we don't think we'll reasonably be able to ship an interoperable version of WebDB
21:56:32 [timeless]
... trying to arrive at an interoperable version of SQL will be too hard
21:56:48 [timeless]
... what people want is a ...
21:56:51 [Marcos]
Marcos has joined #webapps
21:57:03 [timeless]
... we think that WebDB (?) features is a starting point
21:57:22 [timeless]
... we don't plan to add to localStorage
21:57:38 [timeless]
jorlow: so you don't plan to change localStorage
21:57:44 [timeless]
AB: localStorage won't go away
21:57:54 [timeless]
... but we don't intend to extend it
21:58:17 [jorlow]
s/plan to change localStorage/enhance localStorage...for example, implement the storage mutex/
21:58:25 [timeless]
... we don't think that people will be able to benefit from making it more complicated (?)
21:58:48 [timeless]
sicking: I haven't thought about the idea of extending localStorage
21:59:01 [timeless]
... before i form a strong opinion, i'd like to see a proposal, but it seems hard
21:59:16 [timeless]
PC: [?]
21:59:16 [Zakim]
chaals, agendum 2 was to have been concluded at this time
21:59:32 [timeless]
michaeln: SimpleDB doesn't overlap with localStorage
21:59:40 [timeless]
... there are no events in SimpleDB
21:59:53 [timeless]
MJS: so it isn't a superset of (localStorage) functionality
22:00:00 [chaals]
PC: Don't see that it is interesting to try and extend localstorage
22:00:01 [timeless]
sicking: there's always value in having less features
22:00:25 [timeless]
MJS: localStorage is rather nascent, but it seems rather unfortunate that we're discussing orphaning it
22:00:31 [pcastro]
yes, i agree, extending localStorage to cover the functionality of SimpleDB is the same as introducing a new simpledb API, given the delta...
22:00:35 [timeless]
sicking: I agree, but i haven't seen any workable proposals
22:00:51 [timeless]
PC: localStorage is useful for simple tasks
22:01:01 [timeless]
... for registry keys (preferences) in windows apis
22:01:11 [timeless]
sicking: the problem with it is the raciness
22:01:22 [timeless]
... no one working on a multi process browser has safely handled this
22:01:27 [timeless]
chaals: we're out of time.
22:01:38 [timeless]
... there's a lot of push for Nikunj
22:01:43 [timeless]
... where does that leave WebDB?
22:01:48 [timeless]
... Apple can't stop shipping it
22:01:52 [timeless]
... Google will be shipping it
22:02:00 [timeless]
... Opera has not yet shipped it
22:02:09 [timeless]
... but it's likely we will as people have built on it
22:02:15 [timeless]
sicking: I don't think mozilla plans to ship it
22:02:53 [timeless]
DS: you could do the same things with Nikunj as with localStorage
22:02:57 [timeless]
... except storage events
22:03:13 [timeless]
cwilson: the difference is...
22:03:21 [timeless]
... you get the ability to have a lot more data in it
22:03:27 [timeless]
... in a much more organized way
22:03:38 [annevk]
(there's also sessionStorage, fwiw)
22:03:44 [chaals]
22:03:48 [timeless]
... you don't need to learn another language to get data in/out
22:03:57 [timeless]
chaals: i don't see a conclusion
22:04:03 [VagnerW3CBrasil]
VagnerW3CBrasil has joined #webapps
22:04:10 [timeless]
sicking: I don't have any plans to review WebDB
22:04:15 [darobin]
darobin has joined #webapps
22:04:24 [timeless]
IH: I'd rather not spec WebDB if people don't want to ship it
22:04:26 [chaals]
22:04:40 [timeless]
DS: I was talking with w3c people about the confusion
22:04:53 [timeless]
... there are several web storage proposals, and we think that it clutters developer mind space
22:04:57 [arun]
22:05:11 [timeless]
IanF: I don't think people are in disagreement that it's sad
22:05:16 [timeless]
... it's a bit too late
22:05:17 [chaals]
Topic: WebDB - sql lite
22:05:22 [timeless]
... let's look at something else, but let's move on
22:05:39 [timeless]
cwilson: I don't know if anyone has suggested on the group of killing off WebDB on the list
22:05:45 [timeless]
DS: except the editor
22:05:49 [timeless]
[ laughs of agreement ]
22:05:57 [timeless]
MJS: it sounds like there will be multiple shipping implementations
22:06:10 [timeless]
cwilson: it seems with multiple interoperable implementations
22:06:15 [timeless]
... that you can't really call it stillborn
22:06:22 [ifette]
22:06:25 [ifette]
22:06:27 [timeless]
... when we started looking at WebDB
22:06:38 [timeless]
... the reason we liked Nikunj was that it doesn't impose
22:06:45 [timeless]
... but it has the power
22:07:08 [timeless]
... the part that concerned us with WebDB is that it presupposes SQLite
22:07:13 [timeless]
... we're not really sure
22:07:22 [timeless]
IanF: i don't think anyone disagrees
22:07:40 [ifette]
22:07:42 [timeless]
... I haven't heard anyone say they don't like Nikunj , i've heard a lot of interest in it
22:07:52 [timeless]
IH: Proposal
22:08:03 [timeless]
... all the browsers shipping WebDB are WebKit based
22:08:19 [timeless]
... proposal: we move WebDB to, and we kill it as a deliverable from this group
22:08:27 [timeless]
chaals: I think we're likely to ship it
22:08:31 [shepazu]
22:08:31 [Marcos]
Marcos has joined #webapps
22:08:37 [chaals]
ack cha
22:08:39 [timeless]
IH: I don't want to work on a spec without 5/5 impls
22:08:53 [timeless]
DS: Is it possible to take what is speced in WebDB, freeze it,
22:09:03 [timeless]
... take the interface layer, and stick it onto Nikunj ?
22:09:08 [timeless]
[all] : No.
22:09:18 [chaals]
ack arun
22:09:20 [chaals]
22:09:30 [timeless]
arun: suppose the freezing part was taken seriously
22:09:38 [timeless]
... is that sufficient, or is there more spec needed to be written?
22:09:43 [timeless]
IH: well, there's the SQL part
22:09:53 [chaals]
q+ sam
22:09:54 [timeless]
... we could say that the SQL part is SQLite 3's dialect
22:09:59 [ifette]
q+ sam
22:10:03 [chaals]
ack she
22:10:06 [chaals]
ack sam
22:10:23 [pcastro]
22:10:32 [ifette]
sam: spoke
22:10:55 [timeless]
Sam: Apple and Google have expressed an interest in added full text search to the api we've used
22:11:05 [timeless]
jorlow: that's extremely important to Google too
22:11:13 [pcastro]
22:11:19 [timeless]
[ audience squirmed relating to some Xsomething api]
22:11:39 [chaals]
ack me
22:11:48 [timeless]
IH: most of the people are asking me to spec Nikunj (?)
22:12:15 [timeless]
chaals: moving along
22:12:28 [timeless]
... proposal: WebDB remains as a deliverable
22:12:46 [pcastro]
22:12:51 [timeless]
... we ask IH to do the minimal level to satisfy the implementors
22:12:56 [timeless]
RESOLVED: [above]
22:13:10 [chaals]
zakim, next agendum
22:13:10 [Zakim]
I see a speaker queue remaining and respectfully decline to close this agendum, chaals
22:13:24 [chaals]
22:13:27 [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
22:13:31 [chaals]
q- pablo
22:13:38 [JonathanJ]
JonathanJ has joined #webapps
22:13:44 [arun]
ack pcastro
22:13:47 [chaals]
zakim, next agendum
22:13:47 [Zakim]
agendum 3. "WebSimpleDB" taken up [from chaals]
22:14:10 [timeless]
chaals: do we really want to talk about filesystem?
22:14:14 [timeless]
arun: no
22:14:23 [timeless]
ianf: no, except to remember it exists
22:14:23 [chaals]
zakim drop agendum 5
22:14:29 [chaals]
zakim, drop agendum 5
22:14:29 [Zakim]
agendum 5, filesystem, dropped
22:14:52 [ifette]
22:14:53 [chaals]
Topic: Web Simple DB
22:15:04 [ifette]
s/DB/DB (nikunj)
22:15:08 [chaals]
s/DB/(Nikunj) DB/
22:15:31 [timeless]
chaals: ack Nikunj
22:15:42 [timeless]
[ Nikunj asks for projection ]
22:15:57 [ifette]
Zakim, allow this agendum 30 minutes
22:15:57 [Zakim]
ok, ifette
22:16:21 [timeless]
[ chaals asks for intros from lurkers ]
22:16:34 [timeless]
Donald from ETH Zurich
22:16:55 [timeless]
Donald: We've implemented XQuery that runs in IE and FF, and hopefully soon in Chrome/Opera/Safari
22:16:59 [gsnedders]
gsnedders has joined #webapps
22:17:23 [timeless]
Ghislain a student of Donald
22:17:35 [timeless]
Dana from Oracle
22:17:50 [timeless]
HTML working group chair
22:18:27 [timeless]
22:18:41 [timeless]
[?] from Toshiba
22:19:33 [timeless]
22:19:39 [timeless]
Nikunj: there's a new draft, taking input from others and feedback from the mailing list
22:19:43 [chaals]
Magnus, Ericsson
22:19:58 [timeless]
Nikunj: there are some use cases we don't cover
22:20:06 [timeless]
... JS might want to do boolean expression evaluation
22:20:23 [timeless]
... the language for the expression isn't important
22:20:35 [timeless]
... but the necessary bits to efficiently implement this
22:20:56 [timeless]
... being able to store keys, iterate over keys in the index, operate over multiple keys at the same time
22:21:17 [timeless]
Nikunj: I plan to add appendices to help with this (?)
22:21:22 [timeless]
... before the next working draft
22:21:34 [timeless]
... there are some open questions that i haven't addressed in this spec
22:21:47 [timeless]
... i'd like to lay out things to get feedback for alternate suggestions
22:22:11 [timeless]
Nikunj: first, key types
22:22:20 [timeless]
... string/number
22:22:38 [timeless]
... the are fancier things that could be done, supporting structured clone as a key value
22:22:47 [chaals]
[functions that evaluate to a value can be a key, too]
22:22:48 [timeless]
... there are various ways to make it fancier
22:23:02 [chaals]
22:23:16 [chaals]
q+ ifette
22:23:25 [timeless]
Nikunj: there are multiple ways to address this
22:23:32 [MikeSmith]
RRSAgent, make minutes
22:23:32 [RRSAgent]
I have made the request to generate MikeSmith
22:24:08 [timeless]
Nikunj: there are three ways to do indexing
22:24:18 [timeless]
... 1. no indexing, the application manages the index manually
22:24:29 [timeless]
... 2. the index only knows about the store, but the useragent doesn't maintain that index
22:24:40 [timeless]
... it is only used by the application to look up things through the index
22:24:51 [timeless]
... 3. in addition to 2, the useragent actually maintains the index
22:25:02 [timeless]
Nikunj: option 1 is supported
22:25:13 [timeless]
... option 3 is supported with constraints on the key path
22:25:16 [ifette]
q+ to ask question aboujt indicies
22:25:18 [timeless]
... option 2 is not supported
22:25:32 [timeless]
... option 3 is a simpler api but more complex implementation
22:25:50 [timeless]
... there's a contention between reducing the footprint of the api v. the footprint of the implementation
22:26:02 [timeless]
... there are tradeoffs across different engines
22:26:28 [timeless]
... i've tried to capture an implementation neutral api
22:26:42 [timeless]
... i'm requesting feedback to be categorized, api v. footprint
22:26:52 [timeless]
... i've received feedback on concurrency
22:27:10 [timeless]
... there are two models for concurrency
22:27:19 [timeless]
... optimistic and pessimistic
22:27:23 [timeless]
... i've tried to avoid mandating an implementation
22:27:30 [timeless]
... implementations will choose based on their needs
22:27:44 [timeless]
... optimistic is better for high performance
22:27:55 [timeless]
... pessimistic is simpler
22:28:08 [timeless]
... in the spec, i've tried to identify conditions that can offer deadlock free behavior
22:28:23 [timeless]
... i believe the main concern, is that the average user will not be very good at recovering from
22:28:33 [timeless]
... deadlocks or optimistic concurrency failure
22:28:46 [timeless]
... the approach i've taken is to specify a behavior that is deadlock free
22:29:06 [timeless]
... and specify two levels of granularity that
22:29:13 [timeless]
... at the database, or an object store
22:29:26 [timeless]
ArtB: could you document this in a blog?
22:29:33 [timeless]
Nikunj: Object Store = Table
22:29:42 [timeless]
DS: better in a requirements document than a blog
22:29:44 [chaals]
--> editor's draft
22:29:50 [ifette]
22:30:01 [timeless]
Nikunj: let me start writing it in an appendix, and then we can move it to another document later
22:30:03 [timeless]
q+ sicking
22:30:05 [chaals]
ack ifette
22:30:05 [Zakim]
ifette, you wanted to ask question aboujt indicies
22:30:12 [ifette]
q= ifette,sicking
22:30:19 [ifette]
22:30:19 [ifette]
22:30:23 [timeless]
Nikunj: two levels of deadlock free concurrency
22:30:26 [timeless]
... comparing with WebDB
22:30:33 [timeless]
... where we only do database level concurrency
22:30:49 [chaals]
scribe: Chaals
22:30:59 [chaals]
... and object storage level
22:31:06 [chaals]
22:31:15 [jorlow]
q+ to full text indexes
22:31:17 [chaals]
... main pont is that people have asked for even more concurrency where possible.
22:31:31 [timeless]
22:31:41 [chaals]
... optimistic concurrency control and management, but there is a risk of failiures in concurrency management that exposes programmer to requiring recovery
22:32:03 [chaals]
... proposal is to allow that to programmers through exiting API knowing that can lead to exceptions that need recover
22:32:15 [timeless]
22:32:28 [chaals]
... 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)
22:32:36 [ifette]
22:32:48 [chaals]
... Propose to leave it in, as an appendix outside the basic part so people don't stumble.
22:32:56 [timeless]
ack ifette
22:33:10 [chaals]
IF: Wanted to jump back to indices. What do the 3 options mean for an app developer with a lot of data
22:33:36 [chaals]
... assume 20GB database of integers. Which option gives me a Btree in the user agent, instead of in JS
22:33:52 [chaals]
NM: The btree is in the user agent. you only pull out the data you are looking to consume.
22:34:09 [chaals]
... to find out which pieces of data match the two conditions, you have to do the join yourself.
22:34:29 [chaals]
... People feel that a user agent implementation of that might be too rigid, and doing it in the app will be almost as performant.
22:34:49 [chaals]
... 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
22:34:57 [chaals]
IF: Scares me but I need to go back and get more detail.
22:35:10 [chaals]
... What base index types do you expect all UAs to support?
22:35:38 [chaals]
NM: Use case for me is a boolean index exression evaluation. Another use case is keyword and context - fulltext.
22:36:03 [chaals]
... you could create keword/context index, but will not perform as well as done natively.
22:36:29 [chaals]
... 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.
22:36:49 [chaals]
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.
22:36:56 [chaals]
... For v1
22:37:34 [chaals]
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.
22:37:46 [chaals]
... fulltext is probably a bigger spec than websimpleDB.
22:38:01 [chaals]
[clarification of fulltext vs keyword/context]
22:38:24 [timeless]
22:38:25 [chaals]
IF: If we had a quick index that might suffice... let's come back
22:38:28 [chaals]
ack sic
22:38:48 [chaals]
JS: The issue I found most controversial internally has been the concurrency issue
22:38:50 [tlr_]
tlr_ has joined #webapps
22:38:56 [chaals]
[ed. Jonas said the unfancy word :P]
22:39:29 [chaals]
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.
22:40:15 [chaals]
... 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.
22:41:04 [chaals]
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.
22:41:42 [chaals]
... 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
22:42:13 [chaals]
IF: 3 options are all guaranteed to be dealock-free. Is that a hard requirement or could we offer low-level locking ???
22:42:46 [chaals]
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.
22:43:22 [chaals]
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.
22:43:34 [MikeSmith]
i/JS: my concern is that/scribenick: sicking
22:43:40 [timeless]
22:43:40 [MikeSmith]
RRSAgent, make minutes
22:43:40 [RRSAgent]
I have made the request to generate MikeSmith
22:43:41 [chaals]
NM: Yes you can add levels of granularity as well as deadlock free mechanisms
22:43:45 [timeless]
ack j
22:43:45 [Zakim]
jorlow, you wanted to full text indexes
22:43:58 [chaals]
JO: Question about joins - sounds like you took them out to keep the implementation simpler
22:44:07 [chaals]
NM: And keep the API smaller
22:44:20 [chaals]
JO: Main concern was implementing joins in Javascript.
22:45:19 [chaals]
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.
22:45:45 [chaals]
JO: So if you have two large parts of the DB with small verlap, doing that in JS is going to be inefficient.
22:45:56 [chaals]
IF: Fulltext is an example - like that.
22:45:58 [Zakim]
ifette, agendum 3 was to have been concluded at this time
22:46:15 [ifette]
Zakim, thank you for the oh so curteous reminder
22:46:15 [Zakim]
I don't understand you, ifette
22:46:22 [chaals]
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
22:46:24 [ifette]
Zakim, who's your daddy?
22:46:24 [Zakim]
Ralph is taking good care of me but you all are my family, ifette
22:46:59 [chaals]
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.
22:47:12 [chaals]
JO: If you have 10k items, that's heavy
22:47:20 [chaals]
NM: Marshalling cost is high
22:47:56 [chaals]
IF: When using the same index repeatedly, how complex?
22:48:07 [weinig]
22:48:08 [chaals]
NM: if needed it would be an extrsa feature in the spec
22:48:46 [chaals]
SW: concrete question - a person coming from SQL API - how different is the code they have to write, what is the conversion
22:48:54 [chaals]
NM: A user programming against the API?
22:48:57 [chaals]
SW: Sure
22:49:26 [chaals]
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.
22:49:30 [arun]
22:49:33 [arun]
22:49:39 [chaals]
... if you are using a mapping laer here there will be no real difference
22:49:53 [chaals]
SW: Is there precedence for adding a new API mostly for middleware?
22:50:33 [chaals]
Timeless: We added a lot of stuff to libraries against APIs
22:50:52 [chaals]
AR: It is wise to look at this API to make simple things simple, but look at allowing libraries to straddle it.
22:51:03 [ifette]
22:51:05 [chaals]
SW: Not sure that this is simpler for a simple query, which is the basic use case for a DB
22:51:08 [chaals]
ack we
22:51:35 [chaals]
AR: Not sure how much more simpler it will be to use SQL
22:51:56 [ifette]
jonas: most people use XHR via libraries
22:52:02 [chaals]
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
22:52:12 [Lachy]
Lachy has joined #webapps
22:52:14 [chaals]
SW: remains to be seen for WebGL
22:52:25 [chaals]
AR: Think XHR is a good answer for Sam's question.
22:52:37 [chaals]
SW: Would like to see simple examples converted and how easy they are
22:52:45 [chaals]
NM: Those are already in the front of the spec.
22:53:09 [chaals]
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.
22:53:10 [ifette]
22:53:25 [arun]
ack arun
22:53:32 [chaals]
ack if
22:54:12 [chaals]
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
22:54:16 [chaals]
[bike shedding]
22:54:27 [arun]
22:54:27 [chaals]
... I can make my app work with this.
22:54:39 [ifette]
s/this/this probably/
22:54:50 [chaals]
AR: Would like to see libraries that straddle this
22:55:06 [chaals]
Topic: DataCache
22:55:16 [chaals]
s/[bike shedding]//
22:55:31 [chaals]
SW: It would be nice to see a performance analysis
22:55:57 [chaals]
NM: Yes, we need implementation experience to do that.
22:56:25 [Magnus]
Magnus has joined #webapps
22:56:39 [chaals]
NM: Bulk of feedback on data caching / http interception seems like appcache but it uses different terminology.
22:56:51 [chaals]
... people didn't know what they would need to make it happen.
22:57:33 [jorlow]
q+ to ask about why this isn't layered on AppCache
22:57:33 [chaals]
... 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
22:57:38 [arun]
ack arun
22:57:45 [chaals]
... appcache doesn't take full headers into account, data cache does
22:58:20 [chaals]
... 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.
22:58:51 [chaals]
... 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.
22:59:16 [chaals]
MM: Browser has several forms of auth. reason to check cookies seem to apply to http auth as well.
22:59:33 [chaals]
NM: Yes, that is very valid. In this ersion we are only dfoing cookie, but no reason why it has to be that way.
23:00:07 [chaals]
... 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.
23:00:29 [chaals]
see example 4.1.1 in datacache draft
23:00:49 [jorlow]
chaals: I can do it on list
23:01:55 [chaals]
... 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
23:01:55 [chaals]
the app.
23:02:27 [mjs]
23:02:43 [chaals]
... 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.
23:03:13 [jorlow]
23:03:18 [timeless]
ack mjs
23:04:15 [chaals]
MJS: You mentioned ffedback 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.
23:04:31 [arun]
23:06:08 [Zakim]
23:07:08 [pcastro]
pcastro has left #webapps
23:07:39 [Zakim]
23:12:39 [Zakim]
disconnecting the lone participant, apis-db-stuff, in Team_(webapps)21:35Z
23:12:42 [Zakim]
Team_(webapps)21:35Z has ended
23:12:45 [Zakim]
Attendees were apis-db-stuff, +1.206.369.aaaa, Chris, [Microsoft]
23:15:37 [tlr]
tlr has joined #webapps
23:16:10 [chaals]
Topic: second CORS
23:17:28 [pererik]
pererik has joined #webapps
23:20:50 [annevk]
annevk has joined #webapps
23:21:59 [arun]
scribenick: arun
23:22:40 [chaals]
q+ mjs
23:22:49 [arun]
mjs: [May present a short slide show]
23:24:12 [chaals]
ack mj
23:24:20 [annevk]
hmm, no adam :/
23:24:22 [chaals]
rrsagent, draft minutes
23:24:22 [RRSAgent]
I have made the request to generate chaals
23:24:42 [arun]
23:24:43 [chaals]
Jeff Hodges, Paypal
23:25:19 [arun]
mjs: Gives a presentation on CORS that he commits to putting online soon.
23:27:24 [MikeSmith]
MikeSmith has joined #webapps
23:27:46 [chaals]
Present+ Marcos
23:30:13 [shiki]
shiki has joined #webapps
23:30:38 [tlr]
tlr has joined #webapps
23:30:39 [arun]
MM: [Points out that "secret token" addresses issues in Origin]
23:34:39 [chaals]
Present+ Benoit
23:35:52 [chaals]
MJS: In access grant (CORS case) you need to add origin check or token (as normal) to protect against CSRF.
23:38:06 [arun]
mjs: [In the common case, where you're logged in, and permission is granted, diagram illustrates CORS]
23:38:40 [hodges]
hodges has joined #webapps
23:38:53 [arun]
TC: There's an implicit trust relationship between the Events site and the Calendar site.
23:39:50 [arun]
TC: 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)
23:41:02 [arun]
TLR: Turn Server A into an AtomPub server. You want to create a resource, you get the identifier for the resource returned. A page on B uses AtomPub to do something on Server A
23:41:19 [arun]
s/A page on B/resource on Site B
23:42:33 [arun]
TLR: 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]
23:42:54 [arun]
MJS: If Server A only responded with the path part of the URI, there would be no such vulnerability.
23:43:06 [arun]
TC: But this may also eliminate valid use cases!
23:43:46 [arun]
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....
23:44:25 [arun]
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.
23:44:40 [Hixie] introducing a new protocol that has a vulnerability
23:44:53 [arun]
MJS: [slide show continues]
23:45:33 [arun]
MJS: Server M can't forge Origin in browser, combination of cookie + Origin identifies request as valid
23:45:57 [arun]
MJS: Fancier scenarios can have confused deputy. Site A asking Site B to do something on Site C
23:46:31 [arun]
MJS: Can also have confused deputy problems without CORS. For example poorly implemented secret tokens.
23:47:02 [arun]
MJS: [Diagrams this on paper]
23:47:37 [arun]
MJS: [ Draws sites A, B, C]
23:48:17 [arun]
MJS: illustrates a scenario where B,and C have an understanding with shared tokens.
23:48:58 [arun]
MJS: 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.
23:49:26 [arun]
TC: THe thing that makes CSRF prevalent is that the two initial messages between B and C happen implicitly and automatically.
23:49:46 [arun]
MJS: CSRF is different. I am simplifying here by considering only servers.
23:50:13 [arun]
MJS: With CORS, in my simple scenario, doing the dumbest possible thing will be safe.
23:50:30 [arun]
JS: The simplest way to do authorization on the web today is to use cookies; ergo CSRF problems common
23:51:02 [arun]
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.
23:51:19 [arun]
MM: But you will also have a lack of composability amongst servers!
23:51:55 [arun]
MM: 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.
23:52:06 [arun]
MJS: That has to count as on behalf of.
23:52:33 [arun]
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.
23:52:50 [arun]
MJS: It means that if it does, it is distinguishable from any data from that particular server.
23:53:02 [arun]
IH: Or you make sure sanitization takes place (a la SQL injection)
23:53:19 [arun]
TLR: If you want to sanitize, then you must know what the consumer might possibly trigger
23:53:26 [arun]
MJS: [slideshow continues]
23:54:13 [arun]
MJS: [gives the example of GMail / Linked In where LinkedIn asks for GMail passwords]
23:54:26 [arun]
MM: They would prefer to do something else.
23:54:40 [arun]
MJS: What are non - CORS solutions that could work?
23:54:59 [arun]
MJS: OAuth could work, generally requires server to server communication. Bilateral agreement (shared secret)
23:55:13 [arun]
MJS: [Diagrams an OAuth scenario]
23:55:40 [arun]
MJS: [It is a complex diagram]
23:55:46 [arun]
JH: [Has a better diagram]
23:55:58 [arun]
MJS: This is not only in your user agent; it must be programmed in server software.
23:56:06 [arun]
MJS: You cannot send your shared secret to the client.
23:56:12 [arun]
MM: This is per request?
23:56:26 [arun]
MJS: It doesn't have to be per request. The protocol allows token to be valid for e.g. 1 hour.
23:57:41 [arun]
MJS: [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.
23:57:49 [Marcos]
Marcos has joined #webapps
23:58:10 [arun]
MJS: [Continues discussion of OAuth] Redirects are part of the model.
23:58:15 [JeffH]
23:58:49 [arun]
MJS: [ Discussion of OAuth model] Flaws: server to server communication is mandatory. And it's hard to implement correctly.
23:59:13 [chaals]
23:59:22 [arun]
MJS: Discusses why CORS is an improvement of what is done today.
23:59:55 [arun]
RE: Also worth discussing is JSONP, which is horrendously evil.
23:59:58 [arun]
00:00:23 [arun]
JS: Asks Microsoft -- have you disabled Cookies for cross-site script requests?
00:00:31 [arun]
AB: [Responds yes]
00:00:49 [chaals]
00:00:50 [arun]
MJS: That fixes vulnerability on the site serving the script....
00:01:12 [arun]
MJS: I hope to have brought folks up to speed [slide show].
00:01:16 [MikeSmith]
some other OAuth diagrams:
00:01:54 [arun]
CMN: This is the model used by "Verfied by Visa" right?
00:02:28 [arun]
CMN: 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.
00:02:38 [arun]
MJS: I would not claim it is impossible to implement.
00:02:45 [arun]
MJS: But it might be hard for the casual site developer.
00:02:53 [chaals]
q+ tlr
00:02:56 [chaals]
ack chaals
00:02:59 [Hixie]
00:03:05 [chaals]
q+ markM
00:03:13 [Hixie]
00:03:50 [chaals]
ack tlr
00:03:50 [arun]
AR: [Points out that we did this to improve the world]
00:04:12 [arun]
TLR: Two frames, + postMessage. Wouldn't that address this problem?
00:04:51 [arun]
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 mechanism.
00:05:03 [arun]
s/same mechanism/ same Confused Deputy Vulnerability.
00:05:16 [chaals]
q+ tyler
00:05:17 [arun]
MJS: Additionally, it needs client side scripts making requests to the API.
00:05:35 [arun]
TLR: The distinction is that client side code checking origin occurs on the client, as opposed to the server.
00:05:53 [arun]
MJS: Our worry is not about people making the origin check, but in drawing the wrong conclusion about the origin check.
00:07:00 [arun]
s/about the origin check/about the implications of the Origin check
00:07:16 [Hixie]
IH: You can have a dedicated API with a server-provided API or a JS API
00:07:43 [chaals]
ACTION: Nikunj to 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
00:07:43 [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].
00:07:45 [arun]
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.
00:08:01 [darobin]
darobin has joined #webapps
00:08:12 [arun]
MJS: I'd like to analyze this like we've analyzed CORS
00:08:35 [arun]
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?
00:09:25 [arun]
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.
00:10:22 [arun]
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
00:10:31 [arun]
CMN: .... a worked example.
00:11:05 [arun]
MJS: I shall send it to the list.
00:11:25 [chaals]
ACTION: Mark to make a worked example of how e.g. GuestXHR would meet the requirements with improved security
00:11:26 [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].
00:11:29 [arun]
MJS: In a standards compliant format, so that nobody has to live with my company's proprietary format (Keynote)
00:12:00 [arun]
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.
00:12:24 [Kai]
Kai has joined #webapps
00:12:43 [arun]
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 it.
00:12:53 [chaals]
00:12:56 [arun]
s/we may not break it/we may not break compatibility
00:12:58 [chaals]
ack mar
00:13:33 [arun]
TC: A lot has been made of the existing deployment of CORS. From my study of the specs, there are significant differences between implementations...
00:13:36 [arun]
00:14:00 [arun]
CMN: These are [decisions made] by implementors based on the perceived cost to them.
00:14:00 [MikeSmith]
RRSAgent, make minutes
00:14:00 [RRSAgent]
I have made the request to generate MikeSmith
00:14:05 [arun]
00:14:14 [arun]
CMN: I don't think security is an on and off thing.
00:15:37 [chaals]
TC: And therefore I am wondering if there is significant content in reality.
00:16:16 [chaals]
AR: There is shipping and compatibility, in apps tehre is erally only geonames, nota great deal of other adoption
00:16:24 [arun]
00:16:27 [chaals]
00:16:34 [chaals]
00:16:39 [arun]
00:16:41 [arun]
00:16:48 [chaals]
s/nota/not a/
00:17:03 [arun]
The URL above shows content working in safari and firefox
00:17:56 [Marcos]
Marcos has joined #webapps
00:19:27 [arun]
[General discussion on TC39/WebIDL]
00:25:18 [JonathanJ]
JonathanJ has joined #webapps
00:30:50 [tlr]
tlr has joined #webapps
00:38:01 [chaals]
Topic: Multi-touch events
00:38:03 [annevk]
scribe: annevk
00:38:13 [weinig]
weinig has joined #webapps
00:38:53 [annevk]
AR: Safari is shipping multi-touch (mt), Firefox will be soon
00:39:11 [annevk]
AR: there are patent risks, but I think we should wait for the exclusion period and see what happens
00:40:01 [annevk]
AR: I think the charter allows for mt
00:40:30 [chaals]
00:40:36 [chaals]
00:40:40 [annevk]
DS: people disagree on whether it is in the charter
00:40:51 [chaals]
q- tyle
00:40:55 [chaals]
q- arun
00:40:58 [annevk]
DS: it is not listed as deliverable, but is in scope
00:41:39 [annevk]
DS: if someone in the WebApps WG disagrees it is in the charter we have to re-charter in order to do it
00:42:08 [annevk]
RI: we might want to talk to the Device APIs WG
00:42:16 [chaals]
00:42:40 [annevk]
AR: also include orientation event in mt
00:42:53 [annevk]
DS: I believe they are orthogonal so they can be separate
00:42:59 [annevk]
AR: I believe the same group can do it
00:44:21 [annevk]
CMN: we had an issue in the last WG that we inherited about multiple devices interacting with a single device
00:44:32 [annevk]
CMN: sort of similar to mt
00:44:33 [Travis]
Travis has joined #webapps
00:44:42 [annevk]
JS: I think it is different, not just in semantics
00:45:25 [annevk]
CMN: write a spec for mt events
00:45:42 [annevk]
CMN: the spec says it expects to be included in DOM4 Events
00:46:05 [annevk]
AR: I favor separate specs
00:46:39 [annevk]
00:47:00 [annevk]
AR: I am willing to co-edit
00:47:05 [Marcos]
Marcos has joined #webapps
00:47:37 [annevk]
DS: I like to co-edit
00:47:51 [annevk]
AR: I like to check with OP
00:48:04 [ArtB]
ArtB has joined #webapps
00:48:19 [ArtB]
RRSAgent, pointer?
00:48:19 [RRSAgent]
00:49:10 [annevk]
[bikeshed on charter]
00:49:59 [annevk]
CMN: are there objections to adding new events?
00:50:17 [annevk]
RESOLUTION: specifications for new events are in our charter
00:50:46 [annevk]
CMN: we have proposals for mt, orientation, gestures, and pen-tablets
00:51:06 [MikeSmith]
I believe the Geolocation WG is also looking at spec related to Orientation
00:51:07 [annevk]
CMN: we have volunteers; DS and AR
00:51:42 [annevk]
[group overlap bikeshed]
00:52:40 [annevk]
RESOLUTION: DS and AR edit multi-touch, orientation, gestures, and pen-tablets event specifications
00:53:13 [annevk]
[pen-tablet bikeshed]
00:54:12 [annevk]
SO: joystick etc. events?
00:54:16 [annevk]
CMN: if you have proposals
00:54:32 [annevk]
Topic: joint meeting with widget fanboys
00:55:06 [ArtB]
00:55:18 [ArtB]
00:55:19 [annevk]
AB: editors please fix if there are mistakes
00:55:24 [shepazu]
s/event specifications/events specification/
00:56:34 [annevk]
MC: I wonder how XMLHttpRequest and CORS are going to be tested
00:56:50 [annevk]
SW: You can use one domain with two different ports
00:57:15 [annevk]
DS: we can ask the systems team
00:57:48 [chaals]
send mail to
00:58:45 [annevk]
DS: can we start a wiki page with a list of required features for tests?
00:59:18 [pererik]
pererik has joined #webapps
00:59:45 [annevk]
AB: we have two dependencies; Web IDL and Web Storage
01:00:07 [annevk]
SW: Web IDL will use ECMAScript 5 concepts which is an invasive change
01:00:39 [annevk]
SW: we want to add tests based on DOM2 IDL converted to Web IDL so we can test the various concepts in Web IDL
01:01:14 [annevk]
SW: we can use that to allow specification editors to move forward with more certainty
01:01:23 [annevk]
JS: I volunteered for some amount of that testing
01:02:12 [annevk]
CMN: you can move ahead in the Rec-track process with a dependency but you have to argue your case
01:02:28 [annevk]
s/dependency/dependency on Web IDL/
01:02:45 [annevk]
AB: when is there a new draft?
01:02:58 [annevk]
SW: I'm new to editing so I don't really know at this point
01:03:22 [annevk]
MJS: the question is how much editing needs to be done before we want to publish again
01:04:02 [annevk]
MJS: maybe the goal should be to do the ECMAScript 5 conversion and publish after that
01:04:35 [annevk]
IH: Web Storage will go to Last Call this month
01:04:58 [Nikunj]
Nikunj has joined #webapps
01:05:21 [annevk]
CMN: we want to move to a model where Last Call means the Working Group considers the work to be good
01:06:13 [annevk]
IH: I believe there are no outstanding issues
01:06:29 [annevk]
IH: The W3C side will not be blocked by the WHATWG
01:06:38 [annevk]
IH: I don't perceive major changes to Web Storage ever
01:07:27 [ArtB]
ACTION: barstow send out a pre-LC request for comments for Hixie's specs
01:07:27 [trackbot]
Created ACTION-449 - Send out a pre-LC request for comments for Hixie's specs [on Arthur Barstow - due 2009-11-11].
01:07:35 [annevk]
CMN: we found someone to edit ??? and agreed to move XMLHttpRequest to Last Call
01:08:02 [annevk]
CMN: Web Database was only going to be done by 3 out of 5
01:08:16 [annevk]
CMN: more interest in WebSimpleDB
01:10:20 [annevk]
CMN: alternate proposal for CORS which needs further discussion; DOM Events ready
01:11:01 [annevk]
CMN: we did not get into Selectors API 2
01:11:16 [annevk]
AB: news on XBL2?
01:11:48 [annevk]
JS: I'm on temporary project for a while, but I worked on a quarter for it and will get back to it
01:12:23 [ArtB]
ACTION: barstow start a CfC to publish FPWD of File API
01:12:23 [trackbot]
Created ACTION-450 - Start a CfC to publish FPWD of File API [on Arthur Barstow - due 2009-11-11].
01:12:48 [annevk]
[thanks bikeshed]
01:13:03 [annevk]
01:16:38 [markusm]
markusm has joined #webapps
01:18:21 [shiki]
shiki has joined #webapps
01:29:48 [pererik]
pererik has joined #webapps
01:31:44 [shiki]
shiki has joined #webapps
01:34:54 [timeless_mbp]
timeless_mbp has joined #webapps
01:34:59 [Marcos]
Marcos has joined #webapps
01:48:51 [tlr_]
tlr_ has joined #webapps
01:50:33 [annevk]
annevk has joined #webapps
01:50:50 [Marcos]
Marcos has joined #webapps
01:56:12 [tlr_]
tlr_ has joined #webapps
01:56:54 [Marcos]
Marcos has joined #webapps
02:00:04 [tlr_]
tlr_ has joined #webapps
02:02:39 [weinig]
weinig has joined #webapps
02:04:56 [tlr_]
tlr_ has joined #webapps
02:05:25 [MikeSmith]
RRSAgent, make minutes
02:05:25 [RRSAgent]
I have made the request to generate MikeSmith
02:06:25 [annevk]
MikeSmith, you wanna join us to the mall?
02:06:37 [annevk]
MikeSmith, Lachlan and Marcos are also coming, not sure who else
02:08:25 [Marcos]
Marcos has joined #webapps
02:08:31 [MikeSmith]
annevk: I'm got to be at the AC meeting, but can catch up with you guys later
02:08:45 [MikeSmith]
what's at the mall?
02:08:53 [tlr_]
tlr_ has joined #webapps
02:20:00 [tlr_]
tlr_ has joined #webapps
02:37:58 [Nikunj]
Nikunj has joined #webapps
03:43:02 [annevk]
we're not at the mall
03:45:11 [annevk]
03:45:11 [annevk]
you're gone
03:49:54 [sicking]
sicking has joined #webapps
04:43:56 [jorlow]
jorlow has joined #webapps
05:33:51 [timeless_mbp]
timeless_mbp has joined #webapps
06:10:58 [Marcos]
Marcos has joined #webapps
06:13:30 [Lachy]
Lachy has joined #webapps
06:44:02 [weinig]
weinig has joined #webapps
08:56:55 [gsnedders]
gsnedders has joined #webapps
09:43:09 [arve]
arve has joined #webapps
10:01:08 [shepazu]
shepazu has joined #webapps
11:05:46 [timely]
timely has joined #webapps
11:13:31 [mjs]
mjs has joined #webapps
11:20:12 [karl]
karl has joined #webapps
13:19:43 [arun]
arun has joined #webapps
13:23:23 [ArtB]
ArtB has joined #webapps
13:23:36 [ArtB]
RRSAgent, pointer?
13:23:36 [RRSAgent]
14:27:06 [arve]
arve has joined #webapps
14:49:11 [aroben]
aroben has joined #webapps
14:55:08 [annevk]
annevk has joined #webapps
15:28:10 [myakura]
myakura has joined #webapps
15:34:13 [Nikunj]
Nikunj has joined #webapps
15:38:20 [timely]
timely has joined #webapps
16:16:42 [arun]
arun has joined #webapps
16:31:58 [Marcos]
Marcos has joined #webapps
16:44:53 [JonathanJ]
JonathanJ has joined #webapps
16:44:56 [Kai]
Kai has joined #webapps
16:46:12 [MikeSmith]
MikeSmith has joined #webapps
16:46:41 [shepazu]
shepazu has joined #webapps
16:47:05 [Marcos]
Marcos has joined #webapps
16:47:39 [weinig]
weinig has joined #webapps
16:48:46 [chaals]
chaals has joined #webapps
16:49:10 [chaals]
chaals has left #webapps
16:51:54 [ArtB]
ArtB has joined #webapps
16:52:16 [shiki]
shiki has joined #webapps
16:52:41 [darobin]
darobin has joined #webapps
16:53:09 [tlr]
tlr has joined #webapps
16:58:38 [ArtB]
ArtB has changed the topic to: WebApps WG; this channel is logged:
17:00:21 [annevk]
annevk has joined #webapps
17:04:36 [Nikunj]
Nikunj has joined #webapps
17:08:53 [Nikunj]
Nikunj has joined #webapps
17:13:07 [Lachy]
Lachy has joined #webapps
17:13:58 [myakura]
myakura has joined #webapps
17:14:56 [Nikunj]
Nikunj has joined #webapps
17:20:28 [timeless_mbp]
timeless_mbp has joined #webapps
17:28:44 [Nikunj]
Nikunj has joined #webapps
17:53:51 [Nikunj]
Nikunj has joined #webapps
18:04:38 [ifette]
ifette has joined #webapps
18:21:57 [JonathanJ]
JonathanJ has left #webapps
18:22:13 [krijnh]
krijnh has joined #webapps
18:22:14 [Nikunj]
Nikunj has joined #webapps
18:31:49 [Marcos]
Marcos has joined #webapps
18:34:01 [shiki]
shiki has joined #webapps
18:35:59 [annevk]
annevk has joined #webapps
18:36:52 [darobin]
darobin has joined #webapps
18:37:21 [Lachy]
Lachy has joined #webapps
18:38:38 [weinig]
weinig has joined #webapps
18:39:09 [Kai]
Kai has joined #webapps
18:54:13 [JonathanJ]
JonathanJ has joined #webapps
18:54:45 [ArtB]
ArtB has joined #webapps
19:04:04 [weinig_]
weinig_ has joined #webapps
19:11:27 [gsnedders]
gsnedders has joined #webapps
19:11:32 [Nikunj]
Nikunj has joined #webapps
19:49:23 [Lachy]
Lachy has joined #webapps
20:23:38 [krijnh]
krijnh has joined #webapps
20:28:59 [Lachy]
Lachy has joined #webapps
20:34:35 [Marcos]
Marcos has joined #webapps
20:54:54 [Nikunj]
Nikunj has joined #webapps
20:56:31 [Nikunj]
Nikunj has left #webapps
20:59:40 [Lachy]
Lachy has joined #webapps
21:00:01 [Marcos]
Marcos has joined #webapps
21:06:23 [Lachy]
Lachy has joined #webapps
21:14:43 [Kai]
Kai has joined #webapps
21:22:59 [darobin]
darobin has joined #webapps
21:24:46 [Nikunj]
Nikunj has joined #webapps
21:28:53 [Lachy]
Lachy has joined #webapps
21:29:07 [Nikunj]
Nikunj has left #webapps
21:29:08 [gsnedders]
gsnedders has joined #webapps
21:29:17 [Lachy]
Lachy has joined #webapps
21:29:18 [shiki]
shiki has joined #webapps
21:31:12 [myakura]
myakura has joined #webapps
21:32:28 [annevk]
annevk has joined #webapps
21:35:45 [tlr]
tlr has joined #webapps
21:37:57 [JonathanJ]
JonathanJ has joined #webapps
21:38:33 [arun]
arun has joined #webapps
21:41:36 [ArtB]
ArtB has joined #webapps
21:53:34 [chaals]
chaals has joined #webapps
21:53:34 [Lachy]
Lachy has joined #webapps
22:04:24 [ArtB]
ArtB has joined #webapps
22:05:25 [Lachy]
Lachy has joined #webapps
22:29:35 [Lachy]
Lachy has joined #webapps
22:30:46 [phenny]
phenny has joined #webapps
22:34:23 [Marcos]
Marcos has joined #webapps
22:44:19 [shiki]
shiki has joined #webapps
23:04:16 [weinig]
weinig has joined #webapps
23:25:37 [mjs]
mjs has joined #webapps
23:27:19 [JonathanJ]
JonathanJ has joined #webapps
23:30:44 [gsnedders]
gsnedders has joined #webapps
23:31:38 [sicking]
sicking has joined #webapps
23:40:19 [weinig]
weinig has joined #webapps
23:44:04 [Marcos]
Marcos has joined #webapps
23:51:27 [mjs]
mjs has joined #webapps
00:03:27 [Lachy]
Lachy has joined #webapps
00:05:09 [darobin]
darobin has joined #webapps
00:05:23 [Kai]
Kai has joined #webapps
00:07:27 [annevk]
annevk has joined #webapps
00:08:25 [ArtB]
ArtB has joined #webapps
00:10:03 [tlr]
tlr has joined #webapps
00:11:04 [arun]
arun has joined #webapps
00:18:52 [phenny]
phenny has joined #webapps
00:22:19 [Marcos]
Marcos has joined #webapps
00:28:34 [phenny]
phenny has joined #webapps
00:30:23 [phenny]
phenny has joined #webapps
00:31:26 [phenny]
phenny has joined #webapps
00:51:06 [phenny]
phenny has joined #webapps
00:51:48 [phenny]
phenny has joined #webapps
01:02:18 [shiki]
shiki has joined #webapps
01:11:08 [Nikunj]
Nikunj has joined #webapps
01:13:23 [Nikunj]
Nikunj has left #webapps
01:14:20 [phenny]
phenny has joined #webapps
01:15:39 [mjs]
mjs has joined #webapps
01:34:35 [Marcos]
Marcos has joined #webapps
01:40:20 [weinig]
weinig has joined #webapps
01:41:19 [MikeSmith]
01:41:19 [trackbot]
ACTION-442 Make a worked example of how e.g. GuestXHR would meet the requirements with improved security notes added
01:44:19 [arun]
arun has joined #webapps
01:46:07 [shiki]
shiki has joined #webapps
01:46:24 [darobin]
darobin has joined #webapps
02:04:47 [Marcos]
Marcos has joined #webapps
02:39:26 [Lachy]
Lachy has joined #webapps
02:44:27 [Lachy]
Lachy has joined #webapps
03:01:29 [mjs_]
mjs_ has joined #webapps
03:03:53 [gsnedders]
gsnedders has joined #webapps
03:31:16 [Nikunj]
Nikunj has joined #webapps
03:59:57 [Nikunj]
Nikunj has joined #webapps
04:00:11 [mjs]
mjs has joined #webapps
04:00:48 [Nikunj]
Nikunj has left #webapps
04:21:51 [timeless_mbp]
timeless_mbp has joined #webapps
04:24:34 [Nikunj1]
Nikunj1 has joined #webapps
04:40:07 [Nikunj]
Nikunj has joined #webapps
04:49:57 [Nikunj]
Nikunj has joined #webapps
05:34:13 [Nikunj]
Nikunj has joined #webapps
05:48:49 [Nikunj]
Nikunj has joined #webapps
06:23:57 [Nikunj]
Nikunj has left #webapps
06:46:49 [weinig]
weinig has joined #webapps
06:53:46 [timeless_mbp]
timeless_mbp has joined #webapps
07:35:33 [annevk]
annevk has joined #webapps
08:16:22 [timeless_mbp]
timeless_mbp has joined #webapps
08:26:05 [arve]
arve has joined #webapps
09:31:09 [shiki]
shiki has joined #webapps
09:45:26 [fearphage] does this match your expectations of support? the tests are _REALLY_ basic. any suggestions would be appreciated
10:10:44 [Nikunj]
Nikunj has joined #webapps
10:10:50 [Nikunj]
Nikunj has left #webapps
10:59:15 [inimino]
inimino has joined #webapps
11:06:56 [krijnh]
krijnh has joined #webapps
12:58:19 [weinig_]
weinig_ has joined #webapps
13:39:04 [krijnh]
krijnh has joined #webapps
13:47:17 [smaug_]
smaug_ has joined #webapps
14:56:46 [aroben]
aroben has joined #webapps
15:22:22 [Nikunj]
Nikunj has joined #webapps
15:23:19 [arun]
arun has joined #webapps
15:58:46 [mjs]
mjs has joined #webapps
16:26:57 [annevk]
annevk has joined #webapps
16:36:46 [tlr]
tlr has joined #webapps
16:38:43 [myakura]
myakura has joined #webapps
16:42:46 [Lachy]
Lachy has joined #webapps
16:44:40 [Lachy]
Lachy has joined #webapps
16:44:47 [darobin]
darobin has joined #webapps
16:46:03 [Lachy]
Lachy has joined #webapps
16:57:03 [Nikunj]
Nikunj has joined #webapps
17:00:06 [ArtB]
ArtB has joined #webapps
17:02:36 [MikeSmith]
MikeSmith has joined #webapps
17:04:07 [shepazu]
shepazu has joined #webapps
17:05:51 [weinig]
weinig has joined #webapps
17:06:15 [Nikunj]
Nikunj has left #webapps
17:07:05 [JonathanJ]
JonathanJ has joined #webapps
17:14:13 [JonathanJ]
JonathanJ has left #webapps
17:19:47 [Lachy]
Lachy has joined #webapps
17:39:15 [mjs]
mjs has joined #webapps
17:41:52 [shiki]
shiki has joined #webapps
17:54:30 [timeless_mbp]
timeless_mbp has joined #webapps
17:55:32 [inimino]
inimino has joined #webapps
18:13:47 [Lachy]
Lachy has joined #webapps
18:18:27 [Lachy]
Lachy has joined #webapps
18:18:54 [ifette]
ifette has joined #webapps
18:31:07 [weinig]
weinig has joined #webapps
18:56:15 [myakura]
myakura has joined #webapps
19:01:00 [Nikunj]
Nikunj has joined #webapps
19:07:00 [michaeln]
michaeln has joined #webapps
19:07:41 [weinig]
weinig has joined #webapps
19:30:24 [darobin]
darobin has joined #webapps
19:30:56 [tlr]
tlr has joined #webapps
20:13:19 [shepazu]
shepazu has joined #webapps
20:20:29 [karl]
karl has joined #webapps
20:26:27 [tlr]
tlr has joined #webapps
20:38:16 [sicking]
sicking has joined #webapps
20:41:07 [mjs]
mjs has joined #webapps
20:53:16 [sicking]
sicking has joined #webapps
21:03:08 [gsnedders]
gsnedders has joined #webapps
21:09:09 [Nikunj]
Nikunj has joined #webapps
21:27:39 [timeless_mbp]
timeless_mbp has joined #webapps
21:29:49 [shepazu]
shepazu has joined #webapps
21:37:35 [myakura]
myakura has joined #webapps
21:46:00 [shiki]
shiki has joined #webapps
21:49:49 [Lachy]
Lachy has joined #webapps
21:51:53 [shiki]
shiki has joined #webapps
21:53:03 [darobin]
darobin has joined #webapps
21:55:39 [Lachy]
Lachy has joined #webapps
21:59:21 [shiki_]
shiki_ has joined #webapps
22:00:09 [Lachy]
Lachy has joined #webapps
22:09:17 [mjs]
mjs has joined #webapps
22:13:22 [weinig]
weinig has joined #webapps
22:16:04 [azunix]
azunix has joined #webapps
22:23:55 [annevk]
Hixie, not all events are async
22:24:17 [annevk]
i.e. I think .click() is not
22:24:40 [annevk]
or the event dispatched after a sync send()
22:24:43 [annevk]
on XHR
22:36:00 [gsnedders]
gsnedders has joined #webapps
23:18:58 [sicking]
sicking has joined #webapps
23:36:31 [weinig]
weinig has joined #webapps
23:50:56 [Lachy]
Lachy has joined #webapps
00:00:40 [weinig]
weinig has joined #webapps
00:04:08 [shiki]
shiki has joined #webapps
00:06:04 [darobin]
darobin has joined #webapps
00:17:44 [sicking]
sicking has joined #webapps
00:34:19 [tlr]
tlr has joined #webapps
01:09:06 [mjs]
mjs has joined #webapps
01:09:12 [weinig]
weinig has joined #webapps
01:30:35 [shiki]
shiki has joined #webapps
01:56:44 [Nikunj]
Nikunj has joined #webapps
02:34:05 [Nikunj]
Nikunj has joined #webapps
04:14:44 [Nikunj]
Nikunj has joined #webapps
04:40:29 [weinig]
weinig has joined #webapps
05:14:31 [Nikunj]
Nikunj has joined #webapps
05:42:34 [mjs]
mjs has joined #webapps
06:04:35 [weinig]
weinig has joined #webapps