[Bug 13949] Fantastic geocities.com reference in the section on Cross-directory attacks!

[bugzilla]

http://www.w3.org/Bugs/Public/show_bug.cgi?id=13949

Anne  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||ann...@opera.com
 Resolution||WORKSFORME

--- Comment #1 from Anne  2011-08-30 06:43:00 UTC ---
Agreed.

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

Re: [selectors-api] Return an Array instead of a static NodeList

[Cameron McCormack]

On 30/08/11 4:40 AM, Aryeh Gregor wrote:

Oh, right.  I misunderstood you.  Yes, obviously we wouldn't expose
things like .push or .pop on NodeList, since they wouldn't make sense.
  But we should expose things like .forEach, etc.  Any reason not to?


I should point out that on platform array objects (i.e., the JS objects 
you get from IDL T[] types, and not JS Array objects) can be designated 
as read only but they always have Array.prototype in their prototype 
chain.  push/pop/etc. will just fail or do nothing, depending on whether 
the caller is in strict mode.

[Bug 13967] New: Webkit implementation does not use the second argument 'targetOrigin',

[bugzilla]

http://www.w3.org/Bugs/Public/show_bug.cgi?id=13967

   Summary: Webkit implementation does not use the second argument
'targetOrigin',
   Product: WebAppsWG
   Version: unspecified
  Platform: Other
   URL: http://www.whatwg.org/specs/web-apps/current-work/#int
roduction-15
OS/Version: other
Status: NEW
  Severity: normal
  Priority: P3
 Component: Web Messaging (editor: Ian Hickson)
AssignedTo: i...@hixie.ch
ReportedBy: contribu...@whatwg.org
 QAContact: member-webapi-...@w3.org
CC: m...@w3.org, public-webapps@w3.org


Specification:
http://www.whatwg.org/specs/web-apps/current-work/complete/web-messaging.html
Multipage: http://www.whatwg.org/C#introduction-15
Complete: http://www.whatwg.org/c#introduction-15

Comment:
Webkit implementation does not use the second argument 'targetOrigin',

Posted from: 24.6.123.36
User agent: Mozilla/5.0 (Windows NT 6.1) AppleWebKit/535.2 (KHTML, like Gecko)
Chrome/15.0.862.0 Safari/535.2

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

Re: Reference to the HTML specification

[Philippe Le Hegaret]

On Tue, 2011-08-16 at 23:59 +0200, Anne van Kesteren wrote:
> On Thu, 04 Aug 2011 17:47:53 +0200, Philippe Le Hegaret  wrote:
> > Several documents in the WebApps Working Group are linking to HTML, more
> > specifically to the WHATWG HTML specification. An example of those is
> > Progress Events. This is done for no reason than political as far as I
> > can tell.
> 
> They used to link to both, but that changed because I changed publishing  
> tools.
> 
> Now you want us to link solely to the W3C version I thought of a problem.  
> The dependency chain for WHATWG HTML becomes WHATWG HTML -> XMLHttpRequest  
> -> W3C HTML. That makes little sense I think.
> 
> Can we change it back to linking to both the W3C and WHATWG version?

But, the WHATWG HTML links to the editor's drafts and does not link to
the TR one. While documents on the REC-track should link to other
documents on the REC tracks, this doesn't apply to editor's draft, which
have no special status anyway. So, you can link to both versions in the
editor's draft if you prefer.

Philippe

Re: Some way to change an element's name would be useful

[Dimitri Glazkov]

Document.renameNode seems cool. Aside from the awkward user data
event, it matches perfectly the needs of the Component Model (updated
to reference it here:
http://wiki.whatwg.org/wiki/Component_Model#Performance).

I am curious why no one had implemented this. We should dust it off,
add a normal event to it, and set it sail.

:DG<

On Mon, Aug 29, 2011 at 2:07 PM, Boris Zbarsky  wrote:
> On 8/29/11 4:53 PM, Robin Berjon wrote:
>>
>> On Aug 29, 2011, at 21:40 , Boris Zbarsky wrote:
>>>
>>> On 8/29/11 3:33 PM, Robin Berjon wrote:

 For completeness, I'm guessing that namespaces would be supported as
 well?

 Element renameElement(DOMString newName);
 Element renameElement(DOMString newNS, DOMString newName);
>>>
>>> Shades of
>>> http://www.w3.org/TR/DOM-Level-3-Core/core.html#Document3-renameNode
>>
>> Yeah, but my recollection is that renameNode() is in the list of DOM
>> things that are so hopelessly fuzzy that you probably don't want to touch
>> them if you plan on being interoperable. Rereading the description after not
>> having touched it in years certainly reinforces that feeling.
>
> Sure.  I wasn't exactly endorsing it; just pointing to previous attempts to
> spec such a thing in case they would be useful.
>
> -Boris
>
>

Re: Some way to change an element's name would be useful

[Boris Zbarsky]

On 8/29/11 4:53 PM, Robin Berjon wrote:

On Aug 29, 2011, at 21:40 , Boris Zbarsky wrote:

On 8/29/11 3:33 PM, Robin Berjon wrote:

For completeness, I'm guessing that namespaces would be supported as well?

Element renameElement(DOMString newName);
Element renameElement(DOMString newNS, DOMString newName);


Shades of http://www.w3.org/TR/DOM-Level-3-Core/core.html#Document3-renameNode


Yeah, but my recollection is that renameNode() is in the list of DOM things 
that are so hopelessly fuzzy that you probably don't want to touch them if you 
plan on being interoperable. Rereading the description after not having touched 
it in years certainly reinforces that feeling.


Sure.  I wasn't exactly endorsing it; just pointing to previous attempts 
to spec such a thing in case they would be useful.


-Boris

Re: Some way to change an element's name would be useful

[Robin Berjon]

On Aug 29, 2011, at 21:40 , Boris Zbarsky wrote:
> On 8/29/11 3:33 PM, Robin Berjon wrote:
>> For completeness, I'm guessing that namespaces would be supported as well?
>> 
>> Element renameElement(DOMString newName);
>> Element renameElement(DOMString newNS, DOMString newName);
> 
> Shades of http://www.w3.org/TR/DOM-Level-3-Core/core.html#Document3-renameNode

Yeah, but my recollection is that renameNode() is in the list of DOM things 
that are so hopelessly fuzzy that you probably don't want to touch them if you 
plan on being interoperable. Rereading the description after not having touched 
it in years certainly reinforces that feeling.

-- 
Robin Berjon - http://berjon.com/ - @robinberjon

Re: Some way to change an element's name would be useful

[Glenn Maynard]

On Mon, Aug 29, 2011 at 4:29 PM, Aryeh Gregor  wrote:

> On Mon, Aug 29, 2011 at 3:40 PM, Boris Zbarsky  wrote:
> > Shades of
> > http://www.w3.org/TR/DOM-Level-3-Core/core.html#Document3-renameNode
>
> That has some good catches I hadn't thought of -- it preserves event
> handlers and custom JS attributes too.
>

The behavior of sometimes working in-place and sometimes replacing the
element is very evil, though.  It should always replace the element.

-- 
Glenn Maynard

Re: Some way to change an element's name would be useful

[Aryeh Gregor]

On Mon, Aug 29, 2011 at 3:40 PM, Boris Zbarsky  wrote:
> Shades of
> http://www.w3.org/TR/DOM-Level-3-Core/core.html#Document3-renameNode

That has some good catches I hadn't thought of -- it preserves event
handlers and custom JS attributes too.

Re: Some way to change an element's name would be useful

[Boris Zbarsky]

On 8/29/11 3:33 PM, Robin Berjon wrote:

For completeness, I'm guessing that namespaces would be supported as well?

Element renameElement(DOMString newName);
Element renameElement(DOMString newNS, DOMString newName);


Shades of 
http://www.w3.org/TR/DOM-Level-3-Core/core.html#Document3-renameNode


-Boris

Re: Some way to change an element's name would be useful

[Robin Berjon]

On Aug 29, 2011, at 20:57 , Aryeh Gregor wrote:
> We can't actually change the tag name of the node in place, because
> then it will have to implement a different interface in general.  But
> we could have a setTagName() method that creates a new Element with
> the given tag name, moves the children, copies the attributes, puts it
> in the right place, fixes up the Ranges, then returns the
> newly-created Element.  Does this seem reasonable to anyone, or is it
> too confusing that the object will be different?

I've often had a need for this, and I agree that it would be useful. It 
certainly is confusing that it returns a different object but maybe we can 
alleviate that problem somewhat with a different method? Not to bikeshed, but 
setTagName() sounds like you're setting a property of a given object, which 
makes the object change confusing. Perhaps something like renameElement() would 
be clearer? Or getRenamedElement()?

For completeness, I'm guessing that namespaces would be supported as well?

Element renameElement(DOMString newName);
Element renameElement(DOMString newNS, DOMString newName);

-- 
Robin Berjon - http://berjon.com/ - @robinberjon

Some way to change an element's name would be useful

[Aryeh Gregor]

In editing, it's common to want to change an element's name.  For
instance, document.execCommand("formatblock", false, "h1") will change
the current line's wrapper to an .  Unbolding  should
produce .  My editing spec defines an algorithm for this
 which
is used in a bunch of places.

The thing is, one requirement for editing is that you want to preserve
the user's selection.  Real-world use-case: some editors want to
produce  instead of  for bold.  One way to do this is to
let the browser create  tags via the bold command, then iterate
through them all and change them to .  But this will involve
removing the  element from the DOM, and if the selection was inside
it, it will now be collapsed outside it.  There's no way for the
author to avoid this except manually saving and restoring the
selection with fixups.  And that won't work either for ranges other
than the selection.

We can't actually change the tag name of the node in place, because
then it will have to implement a different interface in general.  But
we could have a setTagName() method that creates a new Element with
the given tag name, moves the children, copies the attributes, puts it
in the right place, fixes up the Ranges, then returns the
newly-created Element.  Does this seem reasonable to anyone, or is it
too confusing that the object will be different?

[Bug 13957] New: Remove special handling for WebKit class on blockquote

[bugzilla]

http://www.w3.org/Bugs/Public/show_bug.cgi?id=13957

   Summary: Remove special handling for WebKit class on blockquote
   Product: WebAppsWG
   Version: unspecified
  Platform: All
OS/Version: All
Status: NEW
  Severity: normal
  Priority: P2
 Component: HTML Editing APIs
AssignedTo: a...@aryeh.name
ReportedBy: a...@aryeh.name
 QAContact: sideshowbarker+html-editing-...@gmail.com
CC: m...@w3.org, public-webapps@w3.org


The definition of "simple indentation element" allows it to have a class, for
compat with WebKit's automatically-added webkit-indent-blockquote class.  Now
that WebKit no longer produces that class, we should scrap the special case.

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

[Bug 13956] New: Port tests to a form usable by browsers

[bugzilla]

http://www.w3.org/Bugs/Public/show_bug.cgi?id=13956

   Summary: Port tests to a form usable by browsers
   Product: WebAppsWG
   Version: unspecified
  Platform: All
OS/Version: All
Status: NEW
  Severity: enhancement
  Priority: P2
 Component: HTML Editing APIs
AssignedTo: a...@aryeh.name
ReportedBy: a...@aryeh.name
 QAContact: sideshowbarker+html-editing-...@gmail.com
CC: m...@w3.org, public-webapps@w3.org




-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

[Bug 13955] New: Add more notes!

[bugzilla]

http://www.w3.org/Bugs/Public/show_bug.cgi?id=13955

   Summary: Add more notes!
   Product: WebAppsWG
   Version: unspecified
  Platform: All
OS/Version: All
Status: NEW
  Severity: enhancement
  Priority: P2
 Component: HTML Editing APIs
AssignedTo: a...@aryeh.name
ReportedBy: a...@aryeh.name
 QAContact: sideshowbarker+html-editing-...@gmail.com
CC: m...@w3.org, public-webapps@w3.org


Some things in comments should really be moved to notes, too.

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

[Bug 13954] New: Define DOM mutation operations that automatically check for editability

[bugzilla]

http://www.w3.org/Bugs/Public/show_bug.cgi?id=13954

   Summary: Define DOM mutation operations that automatically
check for editability
   Product: WebAppsWG
   Version: unspecified
  Platform: All
OS/Version: All
Status: NEW
  Severity: normal
  Priority: P2
 Component: HTML Editing APIs
AssignedTo: a...@aryeh.name
ReportedBy: a...@aryeh.name
 QAContact: sideshowbarker+html-editing-...@gmail.com
CC: m...@w3.org, public-webapps@w3.org


Currently I do lots of DOM operations where I first check whether the nodes are
editable/editing hosts/etc.  This should be moved to some kind of wrapper, so
that all DOM mutations in the spec are invoking some subroutine that does the
checks.  I'll still need to do editability checks elsewhere, but this will make
them more idiot-proof.

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

[Bug 13953] New: Investigate the user-modify CSS property

[bugzilla]

http://www.w3.org/Bugs/Public/show_bug.cgi?id=13953

   Summary: Investigate the user-modify CSS property
   Product: WebAppsWG
   Version: unspecified
  Platform: All
OS/Version: All
Status: NEW
  Severity: enhancement
  Priority: P2
 Component: HTML Editing APIs
AssignedTo: a...@aryeh.name
ReportedBy: a...@aryeh.name
 QAContact: sideshowbarker+html-editing-...@gmail.com
CC: m...@w3.org, public-webapps@w3.org


Gecko and WebKit both have "user-modify" CSS properties -- -moz-user-modify and
-webkit-user-modify.  I need to investigate these and see if they make sense to
spec in some form.  There are apparently extra values too, including write-only
in Gecko and read-write-plaintext-only in WebKit.

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

[Bug 13952] New: Specify selection change events

[bugzilla]

http://www.w3.org/Bugs/Public/show_bug.cgi?id=13952

   Summary: Specify selection change events
   Product: WebAppsWG
   Version: unspecified
  Platform: All
OS/Version: All
Status: NEW
  Severity: enhancement
  Priority: P2
 Component: DOM Range
AssignedTo: dave.n...@w3.org
ReportedBy: a...@aryeh.name
 QAContact: member-webapi-...@w3.org
CC: m...@w3.org, public-webapps@w3.org


There are some events already here, but AFAIK not specced: selectstart, things
like that?  This needs to be researched.  Ryosuke suggested that we should add
properties to the events that tell you what sort of user action prompted the
selection change, if any.  Presumably those should be based on the
Selection.modify keywords.

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

[Bug 13951] New: Should be able to treat an image with caption as a unit

[bugzilla]

http://www.w3.org/Bugs/Public/show_bug.cgi?id=13951

   Summary: Should be able to treat an image with caption as a
unit
   Product: WebAppsWG
   Version: unspecified
  Platform: All
OS/Version: All
Status: NEW
  Severity: enhancement
  Priority: P2
 Component: HTML Editing APIs
AssignedTo: a...@aryeh.name
ReportedBy: a...@aryeh.name
 QAContact: sideshowbarker+html-editing-...@gmail.com
CC: m...@w3.org, public-webapps@w3.org


In Word or whatever, you can give captions to images, and drag around the whole
image-with-caption, resize it together with the image, etc.  I'm thinking that
special-casing  and  makes a lot of sense here.  This is a
future project, though.

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

[Bug 13950] New: Specify that links etc. aren't focusable/don't work in editable areas

[bugzilla]

http://www.w3.org/Bugs/Public/show_bug.cgi?id=13950

   Summary: Specify that links etc. aren't focusable/don't work in
editable areas
   Product: WebAppsWG
   Version: unspecified
  Platform: All
OS/Version: All
Status: NEW
  Severity: normal
  Priority: P2
 Component: HTML Editing APIs
AssignedTo: a...@aryeh.name
ReportedBy: a...@aryeh.name
 QAContact: sideshowbarker+html-editing-...@gmail.com
CC: m...@w3.org, public-webapps@w3.org


What exactly doesn't work?  Links and form controls shouldn't work, at least. 
Probably media elements should.  I'll test and see.

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

Re: Request for participation in W3C widgets standard

[Arthur Barstow]

Hi Ronny - to formally participate in the Web Applications WG, your 
company must first join the W3C and information about that process can 
be found in [1].


Re W3C widgets, I consider the v1 specs functionally complete with the 
exception of the Widget Update specs. See [2] for the status of the 
group's widget specs.


The WG does have a "Widgets Embedding" spec in its charter. There hasn't 
been any formal  work done on that spec although there is a wiki to 
gather links to related resources [3].


-Art Barstow

[1] http://www.w3.org/Consortium/membership
[2] http://www.w3.org/2008/webapps/wiki/PubStatus#Widget_Specifications
[3] http://www.w3.org/2008/webapps/wiki/WidgetEmbedding

On 8/25/11 4:37 PM, ext Ronny A Pena wrote:

Hello W3C,

My company is looking to become an active participant in the W3C 
widgets standard. We are a portal software company and we have a 
widget standard that is similar to this standard and OpenSocial 
Gadgets. We would like to participate as allowed by W3C in the 
requirements definition and standard definition. Also, We would love 
to be listed a user agent that is looking to support this standard in 
our 5.0 release. Please let me know what the process is for active 
participation.


Regards,
--
*Ronny A Pena
*/Senior Solution Architect

/Backbase / Customer Experience Solutions
T / 917-566-5222
E / ro...@backbase.com 
W / www.backbase.com 
349 5th Ave, New York, NY 10016

Click here to register for our Webinar Series 

Re: how to organize the DOM specs [Was: CfC: publish new WD of DOM Core]

[Aryeh Gregor]

On Fri, Aug 26, 2011 at 12:48 AM, Jonas Sicking  wrote:
> The point is that if it's just a chapter in a larger spec, how do I
> know that there isn't other important information in the larger spec
> that I have to read in order to get a understanding of the full
> feature.

The same applies if it's a standalone spec.  Microdata is an example
of a spec with so many dependencies on HTML5 that having it in its own
spec is kind of silly:

http://dev.w3.org/html5/md/Overview.html#dependencies

A lot of features just aren't orthogonal.  DOM mutation events are a
great example of something that's tightly coupled to DOM operations,
such that everything DOM-related needs to account for them, and it
makes little sense to have them in a separate spec from DOM Core.
Things like Traversal and Range could be in separate specs, but
they're related enough and short enough that having them in Core also
makes sense to me, and I think we should just go with whatever the
editor finds most convenient.  If they delay LC or we want them to
progress faster for patent policy reasons, that's a separate story.

I do think the HTML5 spec is ridiculously large and could use with
being split up into several mostly independent chunks.  A spec
shouldn't be so large that you don't want to close the tab because it
takes too long to reopen.  But it also shouldn't be so small that you
have to keep a dozen different tabs open to figure out anything
nontrivial.  CSS3 specs are far too small.  I think DOM Core is
currently in a reasonable middle ground where it's still fair to add
more material to it if it's relevant, just not an excessive amount
more.

> I'm not talking about authors, I'm talking about browser vendors. As
> someone looking to implement a spec, I'm very interested in knowing
> which parts of the spec has consensus and which ones doesn't.

This is a separate issue.  New features and old features have to go in
the same drafts regardless, for sanity's sake.  If we want to mark
them up clearly, we have to do this whether they're in a big spec or a
small spec.

[Bug 13949] New: Fantastic geocities.com reference in the section on Cross-directory attacks!

[bugzilla]

http://www.w3.org/Bugs/Public/show_bug.cgi?id=13949

   Summary: Fantastic geocities.com reference in the section on
Cross-directory attacks!
   Product: WebAppsWG
   Version: unspecified
  Platform: Other
   URL: http://www.whatwg.org/specs/web-apps/current-work/#top
OS/Version: other
Status: NEW
  Severity: normal
  Priority: P3
 Component: Web Storage (editor: Ian Hickson)
AssignedTo: i...@hixie.ch
ReportedBy: contribu...@whatwg.org
 QAContact: member-webapi-...@w3.org
CC: i...@hixie.ch, m...@w3.org, public-webapps@w3.org


Specification: http://dev.w3.org/html5/webstorage/
Multipage: http://www.whatwg.org/C#top
Complete: http://www.whatwg.org/c#top

Comment:
Fantastic geocities.com reference in the section on Cross-directory attacks!

Posted from: 170.171.1.5
User agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.8)
Gecko/20100722 Firefox/3.6.8

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

Re: [selectors-api] Return an Array instead of a static NodeList

[Aryeh Gregor]

On Thu, Aug 25, 2011 at 7:17 PM, Jonas Sicking  wrote:
> .push and .pop are generic and work on anything that looks like an
> Array. However they don't work on NodeList because NodeList isn't
> mutable.
>
> . . .
>
> None of these are *mutable* functions.

Oh, right.  I misunderstood you.  Yes, obviously we wouldn't expose
things like .push or .pop on NodeList, since they wouldn't make sense.
 But we should expose things like .forEach, etc.  Any reason not to?

Re: HTTP, websockets, and redirects

[Arthur Barstow]

Hi Brian, All - I just checked Bugzilla and besides the two editorial 
type bugs (12510 and 13700), bug 13777 was filed against the Web Sockets 
API on August 15:


  http://www.w3.org/Bugs/Public/show_bug.cgi?id=13777

Currently, there have been no followup comments on 13777 and I think it 
should be addressed before the LC is published.


-Art Barstow


On 8/25/11 2:31 PM, ext Brian Raymor wrote:

On Wed, Aug 10, 2011 at 9:01 AM, Arthur Barstow<  art.bars...@nokia.com>   
wrote:

Hi All,

Bugzilla now reports only 2 bugs for the Web Socket API [WSAPI] and I
would characterize them both as editorial [Bugs]. As such, the
redirect issue Thomas originally reported in this thread (see [Head])
appears to be the only substantive issue blocking WSAPI Last Call.

As Art notes, the remaining bugs for the WebSocket API [WSAPI] can be 
characterized as editorial bugs.

Microsoft has no objections to the requirement to fail non-101 responses such 
as redirects. If there are no further concerns in the working group related to 
this issue, then the current WebSocket API looks feature complete. I recommend 
that we publish a Last Call working draft and define a timetable to reach 
Candidate Recommendation.


If anyone wants to continue discussing this redirect issue for WSAPI,
I recommend using e-mail (additionally, it may be useful to also
create a new bug in Bugzilla).

As I understand it, the HyBi WG plans to freeze the Web Socket
Protocol spec "real soon now" (~August 19?).

-Art Barstow

[WSAPI] http://dev.w3.org/html5/websockets/
[Head]
http://lists.w3.org/Archives/Public/public-webapps/2011JulSep/0474.ht
ml
[Bugs]
http://www.w3.org/Bugs/Public/buglist.cgi?query_format=advanced&short
_de sc_type=allwordssubstr&short_desc=&product=WebAppsWG&component=We
bSocket+API+%28editor%3A+Ian+Hickson%29&longdesc_type=allwordssubstr&
longdesc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_white
boar
d_type=allwordssubstr&status_whiteboard=&keywords_type=allwords&keywo
r ds=&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&emailt
ype1=substring&email1=&emailtype2=substring&email2=&bug_id_type=anyex
act&bug_id=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=d
oit&order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-
0=noop&value0-0-0=


On 7/27/11 8:12 PM, ext Adam Barth wrote:

On Mon, Jul 25, 2011 at 3:52 PM, Gabriel Montenegro
wrote:

Thanks Adam,

By discussed on some  mailing list, do you mean a *W3C* mailing list?

A quick search turned up this message:

"But I'm totally fine with punting on this for the future and just
disallowing redirects on an API level for now."

http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2011-March/031079.
html

I started that thread at Greg Wilkins' recommendation:

"This is essentially an API issue for the browser websocket object."

http://www.ietf.org/mail-archive/web/hybi/current/msg06954.html


Also, allowing the users to handle these explicitly implies that
the API does

not mandate dropping the connection. Currently, the API does not have
this flexibility, nor does it allow other uses of non-101 codes, like
for authentication. I understand the potential risks with redirects
in browsers, and I thought at one moment we were going to augment the
security considerations with your help for additional guidance. If
websec has already worked on similar language in some draft that we
could reuse that would be great, or, similarly, if we could work with you on 
that text.

We can always add support for explicitly following redirects in the
future.  If we were to automatically follow them today, we'd never
be able to remove that behavior by default.

Adam



-Original Message-
From: Adam Barth [mailto:w...@adambarth.com]
Sent: Sunday, July 24, 2011 13:35
To: Thomas Roessler
Cc: public-ietf-...@w3.org; WebApps WG; Salvatore Loreto; Gabriel
Montenegro; Art Barstow; François Daoust; Eric Rescorla; Harald
Alvestrand; Tobias Gondrom
Subject: Re: HTTP, websockets, and redirects

This issue was discussed on some mailing list a while back (I
forget which).  The consensus seemed to be that redirects are the
source of a large number of security vulnerabilities in HTTP and
we'd like users of the WebSocket API to handle them explicitly.

I'm not sure I understand your question regarding WebRTC, but the
general answer to that class of questions is that WebRTC relies,
in large part, on ICE to be secure against cross-protocol and
voicehammer

attacks.

Adam


On Sun, Jul 24, 2011 at 6:52 AM, Thomas Roesslerwrote:

The hybi WG is concerned about the following clause in the
websocket API

spec:

When the user agent validates the server's response during the
"establish a

WebSocket connection" algorithm, if the status code received from
the server is not 101 (e.g. it is a redirect), the user agent
must fail the

websocket connection.

http://dev.w3.org/html5/websockets/

Discussion with the WG chairs:

- this looks like a conservative attempt to lock down redirects
in

Re: [whatwg] window.cipher HTML crypto API draft spec

[Channy Yun]

Hi, all.

I proposed *Web Crypto API community group* in
http://www.w3.org/community/groups/proposed/
If you're interested in this issue, please join us and let's discuss
together.

I thinks there are various oppotunites around WebCrypto API[1] or
DOMCryptAPI[2] etc.

[1] http://html5.creation.net/webcrypto-api/
[2] https://wiki.mozilla.org/Privacy/Features/DOMCryptAPISpec/Latest

Channy
-
http://www.linkedin.com/in/channy

* Biomedical Knowledge Engineering Laboratory http://bike.snu.ac.kr
* Daum Developers Network & Affiliates http://dna.daum.net



2011년 5월 25일 오전 6:13, Jungshik Shin (신정식, 申政湜) 님의 말:

> Thank you for the reply, David.
>
> It's my mistake to send it without subscribing to the list. To avoid
> further splitting the thread, I'm including below my original email here for
> others to see (and to be archived).
>
> BTW, while doing so, I'm adding a pointer to a chromium bug with some more
> background on PKI and digital signing (in Korea and elsewhere) :
> http://crbug.com/73226  (David has already found it and added a comment
> there :-)).
>
> Jungshik
>
> 2011/5/24 Ian Fette (イアンフェッティ) 
>
> I personally find this to be a very interesting and potentially useful
>> proposals. One of the problems that we / the web face is a legal requirement
>> faced by many Asian banks (esp. Korea) to digitally sign all transactions.
>> To meet this requirement, they use ActiveX controls, as the platform doesn't
>> really give them the primitives they need. This seems like it should give
>> them what they need, but I would be very interested in knowing whether
>> there's more that would be needed or whether this would actually suffice.
>>
>>
> The situation in Korea got a bit "better" recently in the sense that some
> banks (or government agencies) now have a Firefox extension (with an xpcom
> plugin), an npapi plugin, a Safari extension (on Mac OS only), and a Java
> applet in addition to ActiveX controls (I can do online banking on Linux and
> Mac ! :-)) . Obviously, this 'proliferation' of browser "plugins" is far
> from ideal and it'd be great if there's a standard set of API to do what
> these 'browser plugins' do.
>
>
>
>> It would be good if we can figure out whether this is sufficient for e.g.
>> Korean banking requirements, and if not, what else would be necessary. Does
>> anyone have contacts with the relevant industry groups?
>>
>>
> Earlier in the thread, JeffH mentioned the following. The first two threads
> in his list  are relevant to on-line banking/e-commerce/government service
> access in Korea and elsewhere.
>
> While that's sorta interesting, there's various use cases that've been
> mentioned in various places that the above proposed API doesn't necessarily
> address..
> Web Sigining in Action
> http://lists.w3.org/Archives/Public/public-webapps/2009JanMar/0898.html
> Re: Web Sigining in Action
> http://lists.w3.org/Archives/Public/public-webapps/2009JanMar/0953.html
> JS crypto? (and ensuing thread)
> http://lists.w3.org/Archives/Public/public-webapps/2010AprJun/0605.html
> Re: Hash functions (and ensuing thread)
> http://lists.w3.org/Archives/Public/public-webapps/2010OctDec/1041.html
>
>
> It looks like what David proposed seems to be a good start, but I'm afraid
> it's not sufficient yet to replace various browser-plugins/add-ons used for
> digital sigining and certificate management (as is done in Korea). For
> instance, Channy Yun (who's the leader of Mozilla Koran user group: I'm
> copying to him) has the following proposal.
>
> http://html5.creation.net/webcrypto-api/
>
> It covers the generation of cert request, cert import, smart card event
> handling (apparently, in China, smartcards are widely used for on-line
> banking) in addition to signing text. 'keygen' (codified in html5) appears
> to cover some of needs for cert request and cert issuance, but does not go
> all the way (to be useful).
>
> I also wonder what David's proposal has to do with another Mozilla effort
> in the area : https://wiki.mozilla.org/Labs/Secret
>
> Jungshik
>
> 2011/5/24 David Dahl 
>
>>
>> - Original Message -
>> From: "Jungshik Shin (신정식, 申政湜)" 
>> To: "Ian Fette" 
>> Cc: "David Dahl" , "WHATWG Proposals" <
>> wha...@lists.whatwg.org>, cha...@gmail.com
>> Sent: Tuesday, May 24, 2011 2:36:01 PM
>> Subject: Re: [whatwg] window.cipher HTML crypto API draft spec
>>
>> Great insight into the situation in Korea, thanks!
>>
>> > It looks like what David proposed seems to be a good start, but I'm
>> afraid
>>  it's not sufficient yet to replace various browser-plugins/add-ons used
>> for
>>  digital sigining and certificate management (as is done in Korea). For
>>  instance, Channy Yun (who's the leader of Mozilla Koran user group: I'm
>>  copying to him) has the following proposal.
>>
>> > http://html5.creation.net/webcrypto-api/
>>
>> Thank you for the link. I need to read all of these ideas and specs.
>>
>> > It covers the generation of cert request, cert import, smart card event

Reminder: RfC: LCWD of Progress Events; deadline September 1

[Arthur Barstow]

On 8/9/11 1:34 PM, ext Arthur Barstow wrote:

On August 9, WebApps published LCWD #2 of the Progress Events spec:

  http://www.w3.org/TR/2011/WD-progress-events-20110809/

The comment deadline is September 1. Please send all comments to:

   public-webapps@w3.org

-AB

Re: CfC: publish LCWD of Server-sent Events spec; deadline August 17

[Arthur Barstow]

Since this CfC was started, 6 new bugs have been filed against this spec 
[1]. As such, an LC will not be published until these bugs are addressed.


[1] 
http://www.w3.org/Bugs/Public/buglist.cgi?product=WebAppsWG&component=Server-Sent%20Events%20%28editor%3A%20Ian%20Hickson%29&resolution=---


On 8/10/11 10:24 AM, ext Arthur Barstow wrote:
Given Hixie's recent set of bug fixes, the Server-sent Events spec now 
has zero bugs. As such, it appears this spec is ready to proceed on 
the Recommendation track and this is a Call for Consensus to publish a 
new LCWD of this spec using the following ED as the basis:


http://dev.w3.org/html5/eventsource/

This CfC satisfies the group's requirement to "record the group's 
decision to request advancement" for this LCWD.


Note the Process Document states the following regarding the 
significance/meaning of a LCWD:


[[
http://www.w3.org/2005/10/Process-20051014/tr.html#last-call

Purpose: A Working Group's Last Call announcement is a signal that:

* the Working Group believes that it has satisfied its relevant 
technical requirements (e.g., of the charter or requirements document) 
in the Working Draft;


* the Working Group believes that it has satisfied significant 
dependencies with other groups;


* other groups SHOULD review the document to confirm that these 
dependencies have been satisfied. In general, a Last Call announcement 
is also a signal that the Working Group is planning to advance the 
technical report to later maturity levels.

]]

Positive response to this CfC is preferred and encouraged and silence 
will be assumed to mean agreement with the proposal. The deadline for 
comments is August 17. Please send all comments to:


public-webapps@w3.org

-ArtB

Re: CfC: publish LCWD of Web Workers; deadline August 17

[Arthur Barstow]

Bug 13772 was filed after the CfC started and since it appears to be an 
editorial bug, I will work towards a LC publication on September 1 with 
a 3-week review period.


Bug 13373 had some discussion after the CfC ended. However, it is 
currently resolved as WONTFIX and as such will not block the LC publication.


On 8/10/11 7:35 AM, ext Arthur Barstow wrote:
Given Hixie's recent set of bug fixes, the Web Workers spec now has 
zero bugs. As such, it appears this spec is ready to proceed on the 
Recommendation track and this is a Call for Consensus to publish a new 
LCWD of this spec using the following ED as the basis:


  http://dev.w3.org/html5/workers/

This CfC satisfies the group's requirement to "record the group's 
decision to request advancement" for this LCWD.


Note the Process Document states the following regarding the 
significance/meaning of a LCWD:


[[
http://www.w3.org/2005/10/Process-20051014/tr.html#last-call

Purpose: A Working Group's Last Call announcement is a signal that:

* the Working Group believes that it has satisfied its relevant 
technical requirements (e.g., of the charter or requirements document) 
in the Working Draft;


* the Working Group believes that it has satisfied significant 
dependencies with other groups;


* other groups SHOULD review the document to confirm that these 
dependencies have been satisfied. In general, a Last Call announcement 
is also a signal that the Working Group is planning to advance the 
technical report to later maturity levels.

]]

Positive response to this CfC is preferred and encouraged and silence 
will be assumed to mean agreement with the proposal. The deadline for 
comments is August 17. Please send all comments to:


public-webapps@w3.org

-ArtB

Re: CfC: publish LCWD of Web Storage; deadline August 17

[Arthur Barstow]

Given no objections to this CfC and no subsequent bug activity, I will 
work towards a LC publication on September 1 with a 3-week review period.


On 8/10/11 7:33 AM, ext Arthur Barstow wrote:
Given Hixie's recent set of bug fixes, the Web Storage spec now has 
zero bugs. As such, it appears this spec is ready to proceed on the 
Recommendation track and this is a Call for Consensus to publish a new 
LCWD of this spec using the following ED as the basis:


http://dev.w3.org/html5/webstorage/

This CfC satisfies the group's requirement to "record the group's 
decision to request advancement" for this LCWD.


Note the Process Document states the following regarding the 
significance/meaning of a LCWD:


[[
http://www.w3.org/2005/10/Process-20051014/tr.html#last-call

Purpose: A Working Group's Last Call announcement is a signal that:

* the Working Group believes that it has satisfied its relevant 
technical requirements (e.g., of the charter or requirements document) 
in the Working Draft;


* the Working Group believes that it has satisfied significant 
dependencies with other groups;


* other groups SHOULD review the document to confirm that these 
dependencies have been satisfied. In general, a Last Call announcement 
is also a signal that the Working Group is planning to advance the 
technical report to later maturity levels.

]]

Positive response to this CfC is preferred and encouraged and silence 
will be assumed to mean agreement with the proposal. The deadline for 
comments is August 17. Please send all comments to:


public-webapps@w3.org

-ArtB