RE: [IndexedDB] Client API state after calling deleteIndex and deleteObjectStore

[Eliot Graff]

> > Jonas,
> >
> > Would it be good enough to document the above examples under the
> deleteIndex and deleteObjectStore APIs, respectively? Or do you believe we
> should add some text to the API descriptions to make this more clear?  In
> addition, I believe we should expand the explanation for when
> NOT_ALLOWED_ERR can be thrown to accommodate this case.
> >
> > Let me know what you prefer?
> 
> It would probably also be the most consistent to ensure that all functions
> that create requests explicitly mention that a NOT_ALLOWED_ERR is thrown if
> the source has been removed. So in the cases where these functions already
> throw NOT_ALLOWED_ERR, adding this additional condition to that
> description would be a good idea.
> 
> Does that answer the question?
> 
> Oh, and yes, expanding the explanation for NOT_ALLOWED_ERR seems like a
> good idea.
> 
> / Jonas
> 

Added additional description for NOT_ALLOWED_ERR (and added the error if not 
already listed) for the following APIs:
IDBDatabase.createObjectStore()
IDBDatabase.deleteObjectStore()
IDBDatabase.setVersion()
IDBDatabase.transaction()
IDBObjectStore.put()
IDBObjectStore.add()
IDBObjectStore.get()
IDBObjectStore.clear()
IDBObjectStore.openCursor()
IDBObjectStore.createIndex()
IDBObjectStore.index()
IDBObjectStore.count()
IDBIndex.openCursor()
IDBIndex.openKeyCursor()
IDBIndex.get()
IDBIndex.getKey()
IDBIndex.count()
IDBTransaction.objectStore()

Also added a sentence to NOT_ALLOWED_ERR description in IDBDatabaseException.

Let me know if there's anything else to do to finish this up.

Thanks,

Eliot

Re: [Bug 13373] New: Privacy: Limit SharedWorker connections to same top-level domain

[Thomas Roessler]

Gack, that's what I get for reading the subject and first paragraph. 
--
Thomas Roessler, W3C(@roessler)







On Jul 26, 2011, at 15:29 , Anne van Kesteren wrote:

> On Tue, 26 Jul 2011 12:25:16 -0700, Thomas Roessler  wrote:
>> I suspect you mean second-level domain (microsoft.com, w3.org) instead of 
>> top-level domain (.com, .net, .org).
> 
> Top-level browsing context seems more likely.
> 
> 
> -- 
> Anne van Kesteren
> http://annevankesteren.nl/
> 

Re: [Bug 13373] New: Privacy: Limit SharedWorker connections to same top-level domain

[Anne van Kesteren]

On Tue, 26 Jul 2011 12:25:16 -0700, Thomas Roessler  wrote:
I suspect you mean second-level domain (microsoft.com, w3.org) instead  
of top-level domain (.com, .net, .org).


Top-level browsing context seems more likely.


--
Anne van Kesteren
http://annevankesteren.nl/

Re: [Bug 13373] New: Privacy: Limit SharedWorker connections to same top-level domain

[Thomas Roessler]

Travis,

I suspect you mean second-level domain (microsoft.com, w3.org) instead of 
top-level domain (.com, .net, .org).

Further, I'll observe that consistency with other, similar security policies 
would be valuable instead of introducing yet another privacy policy.  Adding 
public-web-security to the CC list.

Regards,
--
Thomas Roessler, W3C(@roessler)







On Jul 26, 2011, at 15:18 , bugzi...@jessica.w3.org wrote:

> http://www.w3.org/Bugs/Public/show_bug.cgi?id=13373
> 
>   Summary: Privacy: Limit SharedWorker connections to same
>top-level domain
>   Product: WebAppsWG
>   Version: unspecified
>  Platform: PC
>OS/Version: Windows NT
>Status: NEW
>  Severity: normal
>  Priority: P2
> Component: Web Workers (editor: Ian Hickson)
>AssignedTo: i...@hixie.ch
>ReportedBy: tra...@microsoft.com
> QAContact: member-webapi-...@w3.org
>CC: m...@w3.org, public-webapps@w3.org
> 
> 
> Per privacy discussion [1], Shared Workers should have a privacy clause
> allowing UA's to prevent SharedWorkers from connecting when they detect that a
> user's privacy could be at risk.
> 
> It is recommended that in addition to the existing checks (steps 7.5, 7.6,
> 7.7.1) for making a connection to a SharedWorker [2], another check should be
> added that compares the top-level domain of the candiate shared worker global
> scope's owning document(s) to the top-level document of the script that 
> invoked
> the constructor. If they are the same, then the connection is allowed to
> proceed; otherwise, a new SharedWorkerGlobalScope should be created.
> 
> This addition privacy clause would allow connections for iframes of the same
> domain within a top-level document:
> 
> Top Level Window - http://a.com
> Iframe_one - http://b.com
> iframe_two - http://b.com
> 
> Iframe_one and iframe_two would be allowed to connect... but would disallow
> connections for a different top-level document:
> 
> Top Level Window - http://c.com
> iframe_three - http://b.com
> 
> iframe_three would get a unique shared worker, separate from the one shared by
> iframe_one & iframe_two.
> 
> [1] http://lists.w3.org/Archives/Public/public-webapps/2011AprJun/0293.html
> [2] http://dev.w3.org/html5/workers/#sharedworker
> 
> -- 
> 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 13373] New: Privacy: Limit SharedWorker connections to same top-level domain

[bugzilla]

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

   Summary: Privacy: Limit SharedWorker connections to same
top-level domain
   Product: WebAppsWG
   Version: unspecified
  Platform: PC
OS/Version: Windows NT
Status: NEW
  Severity: normal
  Priority: P2
 Component: Web Workers (editor: Ian Hickson)
AssignedTo: i...@hixie.ch
ReportedBy: tra...@microsoft.com
 QAContact: member-webapi-...@w3.org
CC: m...@w3.org, public-webapps@w3.org


Per privacy discussion [1], Shared Workers should have a privacy clause
allowing UA's to prevent SharedWorkers from connecting when they detect that a
user's privacy could be at risk.

It is recommended that in addition to the existing checks (steps 7.5, 7.6,
7.7.1) for making a connection to a SharedWorker [2], another check should be
added that compares the top-level domain of the candiate shared worker global
scope's owning document(s) to the top-level document of the script that invoked
the constructor. If they are the same, then the connection is allowed to
proceed; otherwise, a new SharedWorkerGlobalScope should be created.

This addition privacy clause would allow connections for iframes of the same
domain within a top-level document:

Top Level Window - http://a.com
 Iframe_one - http://b.com
 iframe_two - http://b.com

Iframe_one and iframe_two would be allowed to connect... but would disallow
connections for a different top-level document:

Top Level Window - http://c.com
 iframe_three - http://b.com

iframe_three would get a unique shared worker, separate from the one shared by
iframe_one & iframe_two.

[1] http://lists.w3.org/Archives/Public/public-webapps/2011AprJun/0293.html
[2] http://dev.w3.org/html5/workers/#sharedworker

-- 
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: More use-cases for mutation events replacement

[Aryeh Gregor]

On Mon, Jul 25, 2011 at 11:12 PM, Sean Hogan  wrote:
> I assume you are referring to the NodeWatch proposal from Microsoft.
>
> 1st draft:
>    http://www.w3.org/2008/webapps/wiki/Selector-based_Mutation_Events
>
> 2nd draft:
>
>  http://www.w3.org/2008/webapps/wiki/MutationReplacement#NodeWatch_.28A_Microsoft_Proposal.29

I wasn't aware of that proposal.  It seems like we came up with the
same basic idea independently.

> I think the utility of this proposal is unnecessarily limited by the
> restriction of one watcher per node.
> Also, it is not clear that handlers would be called before page reflow /
> repaint.

Yeah, those are two immediate problems I see.  Also (based on looking
at the second draft, not the first):

* I'm not sure what the use-case is for a minimum frequency.  If it's
not going to be really really common, it shouldn't be part of the API,
because authors can always fake it with setTimeout() and some globals.
* I don't think we want to return a handle -- don't other APIs let you
unwatch by just passing the same callback you originally passed?  That
makes more sense, IMO.
* It says it throws an INDEX_SIZE_ERR if the minimum frequency is
negative, but it's an unsigned long, so WebIDL already specifies
different behavior if it's negative (it wraps).

Re: CfC: publish Last Call WD of Progress Events; deadline August 2

[Charles McCathieNevile]

On Tue, 26 Jul 2011 16:12:40 +0200, Arthur Barstow   
wrote:


The pre-LC comment period for Progress Events resulted in no comments  
[1]. As such, Anne proposes a new LC be published and this is a CfC to  
do so:


Opera supports publishing.

cheers

--
Charles 'chaals' McCathieNevile  Opera Software, Standards Group
je parle français -- hablo español -- jeg lærer norsk
http://my.opera.com/chaals   Try Opera: http://www.opera.com

Re: Frame embedding: One problem, three possible specs?

[Tobias Gondrom]

Hi all,

sorry for the late answer, a flu and some other duties kept me from 
answering so far.


I agree with Thomas, Adam and David, so please go ahead with the 
webappsecwg charter.


The current plan for #3 is to be adopted in websec (as http headers 
should be done in IETF) and proceed within a few months to RFC. (main 
idea is to progress the adopted X-Frame-Options to standard and enhance 
where necessary).


A conflict with current CSP would be bad, but as Adam said, I agree that 
it might be kept outside of CSP and progress normally in websec.


Kind regards, Tobias


On 12/07/11 20:07, Thomas Roessler wrote:

So, looking at this thread, here's what I suggest for the webappsecwg charter: We keep 
the deliverable in there, but make it very clear that the group should liaise 
particularly closely with websec "and other IETF work around framing policy" 
(or some such), explicitly to avoid conflicting or competing specifications.

That way, if the vision of complementary specs that Brad describes 
materializes, we have the necessary charter coverage, but we're very clear that 
other work is going on and should be respected.

If that's ok with everybody, I'll make the tweak before we send this to the 
membership.

--
Thomas Roessler, W3C   (@roessler)







On Jul 8, 2011, at 01:07 , David Ross wrote:


#3 is a narrowly scoped effort to standardize something that works pretty well 
today in practice (X-FRAME-OPTIONS).  A conflict with CSP would be bad, but per 
Adam it seems like overlap is looking less likely.  So proceeding down the 
current path on #3 sounds good to me.

David Ross
dr...@microsoft.com


-Original Message-
From: Adam Barth [mailto:w...@adambarth.com]
Sent: Thursday, July 07, 2011 3:24 PM
To: Thomas Roessler
Cc: Tobias Gondrom; Arthur Barstow; Brad Hill; Eric Rescorla; Alexey Melnikov; 
David Ross; Anne van Kesteren; Adrian Bateman; Brandon Sterne; Charles 
McCathieNevile; Maciej Stachowiak; Peter Saint-Andre; Michael(tm) Smith; Mark 
Nottingham; Jeff Hodges; public-web-secur...@w3.org; public-webapps@w3.org; 
web...@ietf.org
Subject: Re: Frame embedding: One problem, three possible specs?

My sense from talking with folks is that there isn't a lot of enthusiasm for 
supporting this use case in CSP at the present time.
We're trying to concentrate on a core set of directives for the first 
iteration.  If it helps reduce complexity, you might consider dropping option 
(1) for the time being.

Adam


On Thu, Jul 7, 2011 at 2:11 PM, Thomas Roessler  wrote:

(Warning, this is cross-posted widely. One of the lists is the IETF
websec mailing list, to which the IETF NOTE WELL applies:
http://www.ietf.org/about/note-well.html)


Folks,

there appear to be at least three possible specifications addressing this 
space, with similar but different designs:

1. A proposed deliverable in the WebAppSec group to take up on X-Frame-Options 
and express those in CSP:
  http://www.w3.org/2011/07/appsecwg-charter.html

(We expect that this charter might go to the W3C AC for review as soon
as next week.)

2. The "From-Origin" draft (aka "Cross-Origin Resource Embedding Exclusion") 
currently considered for publication as an FPWD in the Webapps WG:

http://lists.w3.org/Archives/Public/public-webapps/2011JulSep/0088.htm
l

This draft mentions integration into CSP as a possible path forward.

3. draft-gondrom-frame-options, an individual I-D mentioned to websec:
  https://datatracker.ietf.org/doc/draft-gondrom-frame-options/
  http://www.ietf.org/mail-archive/web/websec/current/msg00388.html


How do we go about it?  One path forward might be to just proceed as currently 
planned and coordinate when webappsec starts working.

Another path forward might be to see whether we can agree now on what forum to 
take these things forward in (and what the coordination dance might look like).

Thoughts welcome.

Regards,
--
Thomas Roessler, W3C   (@roessler)

CfC: publish Last Call WD of Progress Events; deadline August 2

[Arthur Barstow]

The pre-LC comment period for Progress Events resulted in no comments 
[1]. As such, Anne proposes a new LC be published and this is a CfC to 
do so:


http://dev.w3.org/2006/webapi/progress/

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 2. Please send all comments to:


public-webapps@w3.org

Assuming there is consensus to publish this LCWD, the tentative  plan is 
to publish the LC on August 4 with a 3-week LC comment period (ending 
August 25).


-Art Barstow

[1] http://lists.w3.org/Archives/Public/public-webapps/2011AprJun/1249.html

Re: [websockets] Making optional extensions mandatory in the API (was RE: Getting WebSockets API to Last Call)

[Arthur Barstow]

On 7/25/11 5:05 PM, ext Aryeh Gregor wrote:

 From the discussion here, it sounds like there are problems with
WebSockets compression as currently defined.


Yes, this is what I have concluded too (and if we are wrong, I would 
appreciate it if someone on the hybi list would please clarify).



If that's the case, it
might be better for the IETF to just drop it from the protocol for now
and leave it for a future version, but that's up to them.


When hybi agrees on this issue, I would appreciate it if someone would 
update 12917  
and/or ping public-webapps.


-AB