[widgets] P&C conformance requirement
IMO, the following conformance requirement needs to be relaxed to a SHOULD. [[ # ta-FDGQBROtzW When acquiring a potential Zip archive that has not been labeled with a media type (e.g., from a file system), a user agent must attempt to process the resource regardless of the file extension (including situations when the file extension is absent) by applying the rule for determining if a potential Zip archive is a Zip archive. If the rule for determining if a potential Zip archive is a Zip archive return true, proceed to Step 2. Otherwise, if an error was returned, the user agent must treat the potential Zip archive as an invalid widget package. ]] In practice widget managers generally just scan the SD card for '*.wgt' files. Imposing a MUST here is overzealous as we should not expect applications or file systems to be checking file type associations at the byte level (unless they really want to). The requirement was originally written to cover the drag-and-drop use case on a desktop computer, and didn't really take into consideration the user experience on a mobile device. No user agents are harmed by relaxing this requirement to a SHOULD; and relaxing it means that a larger number of mobile-device-based user agents can become compliant to P&C. I have made the change in the spec. If anyone has an objection, please let me know by the before the 07 June. Kind regards, Marcos -- Marcos Caceres http://datadriven.com.au
[WARP] error in spec
Quote from WARP: """ Let sub domains be the result of applying the rule for getting a single attribute value to the value of the subdomains attribute. If the value of sub domains is not a valid boolean value, then this element is in error and the user agent MUST ignore this element. """ subdomains has a default value of false so why is ignoring the complete element needed? If only the subdomains is to be ignored, then the steps for processing the config.xml need to be changed to include the default value. -- Marcos Caceres http://datadriven.com.au
[WARP] it's just too strict...
I want to again voice my concerns about WARP's strictness; The following requirement has to be relaxed in the future (v2?): "" If origin is not a valid IRI, if it has components other than scheme and iauthority, if it has no host component, or if it has a iuser info component, then this element is in error and the user agent MUST ignore this element. "" The offending part is "if it has components other than scheme and iauthority". This means that the following URLs are out: http://foo.com/ http://foo.com? http://foo.com# I think this needs to be changed to just extract the "origin" the developer is trying to access. We should be more liberal and forgiving in what we accept in WARP. As I have already pointed out in other emails, Opera already had to relax conformance to the above requirement because it was causing issues for developers. I don't doubt that this will cause more problems in the future. Kind regards, Marcos -- Marcos Caceres http://datadriven.com.au
[widgets] WARP and redirects
Consider this scenario: the widget requests access to www.google.com. On a local level google redirects to .pl or co.in . With WARP, if we checked redirects the local google page would be blocked. It would be impossible for any developer to take care of all those country wide domains in the normal way (and it does not scale). So we would want to allow this. Also in widgets XHRs resulting in 301s are followed and the final content is returned (this wasn't how it worked but was fixed later). For a future version of WARP to work effectively, the spec should give the option of allow for redirects (or should do this automatically): http://x.com"; redirects="true"/> -- Marcos Caceres http://datadriven.com.au
Request for feedback: DOMCrypt API proposal
Hello public-webapps members,
(I wanted to post this proposed draft spec for the DOMCrypt API (
https://wiki.mozilla.org/Privacy/Features/DOMCryptAPISpec/Latest ) to this list
- if there is a more fitting mailing list, please let me know)
I recently posted this draft spec for a crypto API for browsers to the whatwg
(see: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-May/031741.html)
and wanted to get feedback from W3C as well.
Privacy and user control on the web is of utter importance. Tracking,
unauthorized user data aggregation and personal information breaches are
becoming so commonplace you see a new headline almost daily. (It seems).
We need crypto APIs in browsers to allow developers to create more secure
communications tools and web applications that don’t have to implicitly trust
the server, among other use cases.
The DOMCrypt API is a good start, and more feedback and discussion will really
help round out how all of this should work – as well as how it can work in any
browser that will support such an API.
This API will provide each web browser window with a ‘cipher’ property[1] that
facilitates:
asymmetric encryption key pair generation
public key encryption
public key decryption
symmetric encryption
signature generation
signature verification
hashing
easy public key discovery via meta tags or an ‘addressbookentry’ tag
[1] There is a bit of discussion around adding this API to window.navigator or
consolidation within window.crypto
I have created a Firefox extension that implements most of the above, and am
working on an experimental patch that integrates this API into Firefox.
The project originated in an extension I wrote, the home page is here:
http://domcrypt.org
The source code for the extension is here: https://github.com/daviddahl/domcrypt
The Mozilla bugs are here:
https://bugzilla.mozilla.org/show_bug.cgi?id=649154
https://bugzilla.mozilla.org/show_bug.cgi?id=657432
Firefox "feature wiki page":
https://wiki.mozilla.org/Privacy/Features/DOMCryptAPI
You can test the API by installing the extension hosted at domcrypt.org, and
going to http://domcrypt.org
A recent blog post updating all of this is posted here:
http://monocleglobe..wordpress.com/2011/06/01/domcrypt-update-2011-06-01/
The API:
window.cipher = {
// Public Key API
pk: {
set algorithm(algorithm){ },
get algorithm(){ },
// Generate a keypair and then execute the callback function
generateKeypair: function ( function callback( aPublicKey ) { } ) { },
// encrypt a plainText
encrypt: function ( plainText, function callback (cipherMessageObject) ) { }
) { },
// decrypt a cipherMessage
decrypt: function ( cipherMessageObject, function callback ( plainText ) { }
) { },
// sign a message
sign: function ( plainText, function callback ( signature ) { } ) { },
// verify a signature
verify: function ( signature, plainText, function callback ( boolean ) { } )
{ },
// get the JSON cipherAddressbook
get addressbook() {},
// make changes to the addressbook
saveAddressbook: function (JSONObject, function callback ( addresssbook ) {
}) { }
},
// Symmetric Crypto API
sym: {
get algorithm(),
set algorithm(algorithm),
// create a new symmetric key
generateKey: function (function callback ( key ){ }) { },
// encrypt some data
encrypt: function (plainText, key, function callback( cipherText ){ }) { },
// decrypt some data
decrypt: function (cipherText, key, function callback( plainText ) { }) { },
},
// hashing
hash: {
SHA256: function (function callback (hash){}) { }
}
}
Your feedback and criticism will be invaluable.
Best regards,
David Dahl
Firefox Engineer, Mozilla Corp.
Re: [WARP] it's just too strict...
On Thu, 02 Jun 2011 09:40:33 +0200, Marcos Caceres wrote: I want to again voice my concerns about WARP's strictness; The following requirement has to be relaxed in the future (v2?): "" If origin is not a valid IRI, if it has components other than scheme and iauthority, if it has no host component, or if it has a iuser info component, then this element is in error and the user agent MUST ignore this element. "" The offending part is "if it has components other than scheme and iauthority". This means that the following URLs are out: http://foo.com/ http://foo.com? http://foo.com# I think this needs to be changed to just extract the "origin" the developer is trying to access. We should be more liberal and forgiving in what we accept in WARP. Agree. cheers As I have already pointed out in other emails, Opera already had to relax conformance to the above requirement because it was causing issues for developers. I don't doubt that this will cause more problems in the future. Kind regards, Marcos -- Charles 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
CfC: publish a Candidate Recommendation of HTML5 Web Messaging; deadline June 9
The Last Call comment period for the HTML5 Web Messaging spec ended June 1. The status of this spec is: no comments were submitted to public-webapps during the LC comment period; Bugzilla reports this spec has Zarro Boogs [1]; and the changes to the spec since the LC was published appear to not affect an implementation [2] (I encourage others to confirm this). One comment [3] was submitted during the CfC to publish the LC period, and no one responded to this comment. Hixie - would you or someone else in the group please respond to this comment? Nevertheless, I would like the group to proceed with this spec so I propose the spec be published as a Candidate Recommendation (CR) and this is a Call for Consensus to do so: http://dev.w3.org/html5/postmsg/ A test suite has not been agreed by the Working Group, and will not be required for the CR to be published. However, agreeing on a test suite will be part of the work that must be done before this spec can move further than CR. The Editor's Draft does not yet include CR exit criteria. I would expect the criteria to be similar to our previous CRs i.e. to require a thorough test suite and at least two implementations that pass all tests. Given the relatively broad implementation support for this spec (e.g. see [4]), I propose status section state the spec will advance to PR no sooner than 8 weeks after the CR is published. This CfC satisfies: a) the group's requirement to "record the group's decision to request advancement" to CR; and b) "General Requirements for Advancement on the Recommendation Track" as defined in the Process Document: http://www.w3.org/2005/10/Process-20051014/tr.html#transition-reqs Positive response to this CfC is preferred and encouraged and silence will be considered as agreement with the proposal. The deadline for comments is June 9. Please send all comments to: public-webapps@w3.org -Art Barstow [1] http://www.w3.org/Bugs/Public/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&product=WebAppsWG&component=Web+Messaging+%28editor%3A+Ian+Hickson%29&longdesc_type=allwordssubstr&longdesc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=allwordssubstr&status_whiteboard=&keywords_type=allwords&keywords=&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&emailtype1=substring&email1=&emailtype2=substring&email2=&bug_id_type=anyexact&bug_id=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-0=noop&value0-0-0= [2] http://dev.w3.org/cvsweb/html5/postmsg/Overview.html.diff?r1=1.78;r2=1.85;f=h [3] http://lists.w3.org/Archives/Public/public-webapps/2011JanMar/0849.html [4] http://caniuse.com/#search=messaging
Re: Status of URL Interface?
I support WebApps starting some new work, provided there is broad support for it and it doesn't block or slow work we already started. All, especially implementors - what is your level of interest in Adam's URL API? Dom - what's your interest here? F.ex., is this API something DAP or some other group needs? On Jun/1/2011 5:42 PM, ext Adam Barth wrote: I've been implementing bits and pieces in WebKit. If there's interest from other implementors, I'm happy to work on the document in the W3C process. Adam On Wed, Jun 1, 2011 at 9:39 AM, Arthur Barstow wrote: Dom - WebApps' current charter does not directly include this API and I don't think the charter includes any deliverables that could directly rationalize Adam's spec. However, if someone interprets the charter differently, then please speak up. Adam - what is the status and plan for the URL API? -AB On Jun/1/2011 10:55 AM, ext Dominique Hazael-Massieux wrote: Hi, There was discussion some time ago about specifying a URL interface, based I think on the draft proposal at https://docs.google.com/document/edit?id=1r_VTFKApVOaNIkocrg0z-t7lZgzisTuGTXkdzAk4gLU&hl=en&pli=1 Is this something that the Web Apps Working Group is planning to work on? If not, does anyone know the status of this effort? Thanks, Dom
Re: [Bug 12111] spec for Storage object getItem(key) method does not match implementation behavior
Hixie, All - PLH proposed a fix for this bug in comment #5 (use
DOMString instead of any in {get,set}Item).
AFAIU, PLH's proposal matches what has been widely implemented. As such,
it seems like the spec should be updated accordingly.
-AB
On Jun/2/2011 8:31 AM, ext bugzi...@jessica.w3.org wrote:
http://www.w3.org/Bugs/Public/show_bug.cgi?id=12111
--- Comment #5 from Philippe Le Hegaret 2011-06-02 12:31:42 UTC
---
here is how the change should look like I think:
[[
interface Storage {
[...]
getter DOMString getItem(in DOMString key);
setter creator void setItem(in DOMString key, in DOMString value);
[...]
};
[...]
The getItem(key) method must return the current value associated with the given
key. If the given key does not exist in the list associated with the object
then this method must return null.
The setItem(key, value) method must set the value of a given key. If this
raises an exception, then the exception must be thrown and the previous value
associated with the given key is left unchanged.
]]
For forward compatibility purposes, I would not change the types of oldValue
and newValue in the StorageEvent interface. In practice, those will be
DOMString since that's the only thing one can store, but this could change in
the future if we add a getValue and a setValue methods to the Storage interface
with the type any.
Re: [WARP] error in spec
On Thu, Jun 2, 2011 at 9:26 AM, Marcos Caceres wrote: > Quote from WARP: > > """ > Let sub domains be the result of applying the rule for getting a > single attribute value to the value of the subdomains attribute. If > the value of sub domains is not a valid boolean value, then this > element is in error and the user agent MUST ignore this element. > """ > > subdomains has a default value of false so why is ignoring the > complete element needed? If only the subdomains is to be > ignored, then the steps for processing the config.xml need to be > changed to include the default value. > I've removed the following two tests from the test suite until we get this resolved: # ic (download, files) Tests that the UA ignores an access element with an invalid subdomains value. To pass, the remote script must NOT load and PASS must remain displayed. # id (download, files) Tests that the UA ignores an access element with an invalid subdomains value. To pass, the remote script must NOT load and PASS must remain displayed. -- Marcos Caceres http://datadriven.com.au
Re: [WARP] error in spec
On 6/2/11 5:13 PM, Marcos Caceres wrote: On Thu, Jun 2, 2011 at 9:26 AM, Marcos Caceres wrote: Quote from WARP: """ Let sub domains be the result of applying the rule for getting a single attribute value to the value of the subdomains attribute. If the value of sub domains is not a valid boolean value, then this element is in error and the user agent MUST ignore this element. """ subdomains has a default value of false so why is ignoring the complete element needed? If only the subdomains is to be ignored, then the steps for processing the config.xml need to be changed to include the default value. I've removed the following two tests from the test suite until we get this resolved: # ic (download, files) Tests that the UA ignores an access element with an invalid subdomains value. To pass, the remote script must NOT load and PASS must remain displayed. # id (download, files) Tests that the UA ignores an access element with an invalid subdomains value. To pass, the remote script must NOT load and PASS must remain displayed. Proposed fix: [[ 5. If the subdomins attribute is absent, then let sub domains be the value false. Otherwise, or let sub domains be the result of applying the rule for getting a single attribute value to the value of the subdomains attribute. 6. If the value of sub domains is not a valid boolean value, then let sub domains be the value false. ]] I've put that into the editor's draft. I call to republish the spec with the correction ASAP. Kind regards, Marcos
Re: Using ArrayBuffer as payload for binary data to/from Web Workers
On Wed, Jun 1, 2011 at 4:55 PM, Kenneth Russell wrote: > On Tue, May 31, 2011 at 3:35 PM, Ian Hickson wrote: >> On Tue, 31 May 2011, Kenneth Russell wrote: >>> >>> Jonas's suggestion of adding another argument to postMessage, and >>> Gregg's generalization to declare it as an array of objects to be >>> transferred rather than copied, sounds good. >> >> We could change make MessagePort and ArrayBuffer both inherit from a >> [NoInterfaceObject] empty interface, and then make the MessagePort[] >> argument of the various postMessage() methods instead take an array of >> this new interface, and then just have ArrayBuffer and MessagePort both >> define how to be cloned in this way. >> >> If people like this approach I can work with Kenneth on getting the >> wording right in the various specs. > > This sounds good to me; in the interest of moving things forward, are > there any objections? No, this sounded good to the people here at mozilla that I talked with about this. / Jonas
Re: Testing Requirements
Hi Philippe, Just wondering if we have different port support yet on test-w3c.org? Would be nice to at least have 81, 82 or something (any none-standard ports would be fine for me). I need ports to finish off the Widget Access Request Test Suite. Kind regards, Marcos On Fri, Feb 18, 2011 at 9:37 PM, Philippe Le Hegaret wrote: > Doh! I didn't see the message from Mike before answering this one. So, > whatever the message from Mike is good. Apologizes for the extra noise. > > Philippe > > On Fri, 2011-02-18 at 15:32 -0500, Philippe Le Hegaret wrote: >> On Thu, 2011-02-17 at 11:04 +0100, James Graham wrote: >> > On 02/17/2011 09:55 AM, Dominique Hazael-Massieux wrote: >> > >> > > (I see that Art documented most of this in >> > > http://www.w3.org/2008/webapps/wiki/Testing_Requirements but thought >> > > this ought to be confirmed on the list) >> > >> > Is there some way to make put this documentation in some common location >> > rather than having essentially the same facts documented once for HTML, >> > once for WebApps, etc.? >> >> You can use the general wiki for that. I suggest: >> http://www.w3.org/wiki/Testing/Requirements >> >> It's accessible to anyone who has a W3C account. >> >> Btw, Mike reminded recently that we also have a general list for >> discussion on the testing infrastructure requirements: >> http://lists.w3.org/Archives/Public/public-test-infra/ >> >> Philippe >> >> >> >> >> >> > > > > -- Marcos Caceres http://datadriven.com.au
Re: Testing Requirements
On Thu, 2011-06-02 at 17:47 +0200, Marcos Caceres wrote: > Hi Philippe, > Just wondering if we have different port support yet on test-w3c.org? > Would be nice to at least have 81, 82 or something (any none-standard > ports would be fine for me). I need ports to finish off the Widget > Access Request Test Suite. Nope, I don't believe we have that but that should relatively easy to add. How many extra do you need? Philippe
What changes to Web Messaging spec are proposed? [Was: Re: Using ArrayBuffer as payload for binary data to/from Web Workers]
What are the specific change(s) to the Web Messaging spec being proposed: http://dev.w3.org/html5/postmsg/ -AB On Jun/2/2011 11:25 AM, ext Jonas Sicking wrote: On Wed, Jun 1, 2011 at 4:55 PM, Kenneth Russell wrote: On Tue, May 31, 2011 at 3:35 PM, Ian Hickson wrote: On Tue, 31 May 2011, Kenneth Russell wrote: Jonas's suggestion of adding another argument to postMessage, and Gregg's generalization to declare it as an array of objects to be transferred rather than copied, sounds good. We could change make MessagePort and ArrayBuffer both inherit from a [NoInterfaceObject] empty interface, and then make the MessagePort[] argument of the various postMessage() methods instead take an array of this new interface, and then just have ArrayBuffer and MessagePort both define how to be cloned in this way. If people like this approach I can work with Kenneth on getting the wording right in the various specs. This sounds good to me; in the interest of moving things forward, are there any objections? No, this sounded good to the people here at mozilla that I talked with about this. / Jonas
CORS and HTTP headers spoofing
Hello, I was trying to find any information concerning CORS and HTTP headers spoofing. Couldn't find any relevant information though. So if I am able to set Origin header to some custom value, it means that there is no more secure communication between domains as I can pretend to be anyone? Best regardsMargarita Podskrobkoa
Is Progress Events spec ready for Candidate Rec? [Was: Re: RfC: Last Call Working Draft of Progress Events; deadline June 1]
Hi All, The comment period for Progress Events LC ended on June 1 and my take on the status is: no comments were submitted to public-webapps during the LC comment period; there are no open bugs for this spec (Webapps has no related component in Bugzilla and Tracker has 0 bugs); and the ED [ED] has not changed since the LC was published. Given this, the next step should be to publish a Candidate Recommendation. However, AFAIK, Anne is still off-grid and I don't know when he will return. Chaals, All - if there are any reasons to not start a CfC to publish a CR for this spec, please speak up. -AB [ED] http://dev.w3.org/2006/webapi/progress/ On Mar/10/2011 7:33 PM, ext Arthur Barstow wrote: This is a Request for Comments for the March 10 Last Call Working Draft of Progress Events: http://www.w3.org/TR/2011/WD-progress-events-20110310/ If you have any comments, please send them to the following list by 1 June 2011 at the latest: public-webapps@w3.org -Art Barstow
RE: What changes to Web Messaging spec are proposed? [Was: Re: Using ArrayBuffer as payload for binary data to/from Web Workers]
I'm a little concerned about the inherit approach that Ian outlines...
This plan requires all objects that want to opt-in to a new
transfer-of-ownership (or really any special custom behavior for postMessage)
to 1) participate in the special inheritance interface and 2) be isolated from
the primary object graph being passed to the first parameter. For example,
instead of allowing the structured clone algorithm to preserve all my object
relationships as-is, I will have to detach some objects from the graph (to
include in the proposed 2nd parameter to postMessage) and then re-attach them
on the destination side.
Isn't there some way we can flag the objects that want transfer of ownership by
a property or identifier on the objects themselves? That way, they won't have
to be special-cased into a separate list. For example, if the ArrayBuffer added
a property indicating transfer-of-ownership? Or a new configuration option for
postMessage ( { transferOwnership: true } )?
-Original Message-
From: Arthur Barstow [mailto:art.bars...@nokia.com]
Sent: Thursday, June 02, 2011 9:02 AM
To: ext Jonas Sicking; Kenneth Russell; Ian Hickson
Cc: Travis Leithead; g...@google.com; cmar...@apple.com; gl...@zewt.org;
public-webapps@w3.org
Subject: What changes to Web Messaging spec are proposed? [Was: Re: Using
ArrayBuffer as payload for binary data to/from Web Workers]
What are the specific change(s) to the Web Messaging spec being proposed:
http://dev.w3.org/html5/postmsg/
-AB
On Jun/2/2011 11:25 AM, ext Jonas Sicking wrote:
> On Wed, Jun 1, 2011 at 4:55 PM, Kenneth Russell wrote:
>> On Tue, May 31, 2011 at 3:35 PM, Ian Hickson wrote:
>>> On Tue, 31 May 2011, Kenneth Russell wrote:
Jonas's suggestion of adding another argument to postMessage, and
Gregg's generalization to declare it as an array of objects to be
transferred rather than copied, sounds good.
>>> We could change make MessagePort and ArrayBuffer both inherit from a
>>> [NoInterfaceObject] empty interface, and then make the MessagePort[]
>>> argument of the various postMessage() methods instead take an array
>>> of this new interface, and then just have ArrayBuffer and
>>> MessagePort both define how to be cloned in this way.
>>>
>>> If people like this approach I can work with Kenneth on getting the
>>> wording right in the various specs.
>> This sounds good to me; in the interest of moving things forward, are
>> there any objections?
> No, this sounded good to the people here at mozilla that I talked with
> about this.
>
> / Jonas
>
Re: What changes to Web Messaging spec are proposed? [Was: Re: Using ArrayBuffer as payload for binary data to/from Web Workers]
(It would have been better not to fork the thread with a different
subject line...)
On Thu, Jun 2, 2011 at 9:58 AM, Travis Leithead
wrote:
> I'm a little concerned about the inherit approach that Ian outlines...
>
> This plan requires all objects that want to opt-in to a new
> transfer-of-ownership (or really any special custom behavior for postMessage)
> to 1) participate in the special inheritance interface and 2) be isolated
> from the primary object graph being passed to the first parameter. For
> example, instead of allowing the structured clone algorithm to preserve all
> my object relationships as-is, I will have to detach some objects from the
> graph (to include in the proposed 2nd parameter to postMessage) and then
> re-attach them on the destination side.
I realize I misunderstood the proposal. I thought the additional array
of objects was supposed to indicate those in the object graph that
wanted ownership to be transferred. Having to send these objects
separately from the rest of those in the graph is undesirable and in
my opinion unworkable.
> Isn't there some way we can flag the objects that want transfer of ownership
> by a property or identifier on the objects themselves? That way, they won't
> have to be special-cased into a separate list. For example, if the
> ArrayBuffer added a property indicating transfer-of-ownership? Or a new
> configuration option for postMessage ( { transferOwnership: true } )?
A per-object property is undesirable because it forces all types that
want to participate in transfer of ownership to add a new property
specifically for the Web Messaging spec.
I still like the idea of identifying those objects in the graph passed
to postMessage which should be transferred rather than copied, since
it's flexible and should be easy to use. (Though maybe not, if the
object graph is deep and it's difficult to pull out all the objects
you want to transfer?) Adding a flag to postMessage, or adding a new
entry point like transferMessage, also seem fine.
-Ken
> -Original Message-
> From: Arthur Barstow [mailto:art.bars...@nokia.com]
> Sent: Thursday, June 02, 2011 9:02 AM
> To: ext Jonas Sicking; Kenneth Russell; Ian Hickson
> Cc: Travis Leithead; g...@google.com; cmar...@apple.com; gl...@zewt.org;
> public-webapps@w3.org
> Subject: What changes to Web Messaging spec are proposed? [Was: Re: Using
> ArrayBuffer as payload for binary data to/from Web Workers]
>
> What are the specific change(s) to the Web Messaging spec being proposed:
>
> http://dev.w3.org/html5/postmsg/
>
> -AB
>
> On Jun/2/2011 11:25 AM, ext Jonas Sicking wrote:
>> On Wed, Jun 1, 2011 at 4:55 PM, Kenneth Russell wrote:
>>> On Tue, May 31, 2011 at 3:35 PM, Ian Hickson wrote:
On Tue, 31 May 2011, Kenneth Russell wrote:
> Jonas's suggestion of adding another argument to postMessage, and
> Gregg's generalization to declare it as an array of objects to be
> transferred rather than copied, sounds good.
We could change make MessagePort and ArrayBuffer both inherit from a
[NoInterfaceObject] empty interface, and then make the MessagePort[]
argument of the various postMessage() methods instead take an array
of this new interface, and then just have ArrayBuffer and
MessagePort both define how to be cloned in this way.
If people like this approach I can work with Kenneth on getting the
wording right in the various specs.
>>> This sounds good to me; in the interest of moving things forward, are
>>> there any objections?
>> No, this sounded good to the people here at mozilla that I talked with
>> about this.
>>
>> / Jonas
>>
>
>
Re: What changes to Web Messaging spec are proposed? [Was: Re: Using ArrayBuffer as payload for binary data to/from Web Workers]
On Thu, Jun 2, 2011 at 9:58 AM, Travis Leithead
wrote:
>
> This plan requires all objects that want to opt-in to a new
> transfer-of-ownership (or really
> any special custom behavior for postMessage) to 1) participate in the special
> inheritance
> interface and 2) be isolated from the primary object graph being passed to
> the first
> parameter.
I interpreted the proposal differently... This is what I envisioned:
var bufferToTransfer = /* make ArrayBuffer */;
var bufferToCopy = /* make ArrayBuffer */;
var worker = /* make Worker */;
var message = { buf1: bufferToTransfer, buf2: bufferToCopy };
worker.postMessage(message, [bufferToTransfer]);
We'd keep the structure exactly the same, it's just that when we clone
'message' we compare each object value to one of the ones passed in
the transfer array. If the objects match (===) then we'd transfer it
rather than copy it.
Does that sound like what you were hoping for?
-Ben Turner
Re: Using ArrayBuffer as payload for binary data to/from Web Workers
On Thu, Jun 2, 2011 at 8:25 AM, Jonas Sicking wrote: > On Wed, Jun 1, 2011 at 4:55 PM, Kenneth Russell wrote: >> On Tue, May 31, 2011 at 3:35 PM, Ian Hickson wrote: >>> On Tue, 31 May 2011, Kenneth Russell wrote: Jonas's suggestion of adding another argument to postMessage, and Gregg's generalization to declare it as an array of objects to be transferred rather than copied, sounds good. >>> >>> We could change make MessagePort and ArrayBuffer both inherit from a >>> [NoInterfaceObject] empty interface, and then make the MessagePort[] >>> argument of the various postMessage() methods instead take an array of >>> this new interface, and then just have ArrayBuffer and MessagePort both >>> define how to be cloned in this way. >>> >>> If people like this approach I can work with Kenneth on getting the >>> wording right in the various specs. >> >> This sounds good to me; in the interest of moving things forward, are >> there any objections? > > No, this sounded good to the people here at mozilla that I talked with > about this. Apologies but I misunderstood something about this proposal and it no longer seems desirable. I've followed up on the other (forked) thread. -Ken
Re: What changes to Web Messaging spec are proposed? [Was: Re: Using ArrayBuffer as payload for binary data to/from Web Workers]
On Thu, Jun 2, 2011 at 12:58 PM, Travis Leithead
wrote:
> I'm a little concerned about the inherit approach that Ian outlines...
>
> This plan requires all objects that want to opt-in to a new
> transfer-of-ownership (or really any special custom behavior for postMessage)
> to 1) participate in the special inheritance interface and 2) be isolated
> from the primary object graph being passed to the first parameter. For
> example, instead of allowing the structured clone algorithm to preserve all
> my object relationships as-is, I will have to detach some objects from the
> graph (to include in the proposed 2nd parameter to postMessage) and then
> re-attach them on the destination side.
I interpreted (on only a quick reading) his proposal as saying that
the second list is a set of objects which, if included in the first
list, will be transferred rather than cloned. I'd agree that it
doesn't make sense to have a separate, isolated list to transfer;
that's cumbersome.
I assume the proposal was a bit different than I read it, since that's
not how MessagePorts work. I'd imagine it wouldn't be hard for the
list to do both: filter all objects that aren't MessagePorts, use that
set to flag transfers, and the remaining MessagePorts act as they do
now. Sort of ugly, though.
> Isn't there some way we can flag the objects that want transfer of ownership
> by a property or identifier on the objects themselves? That way, they won't
> have to be special-cased into a separate list. For example, if the
> ArrayBuffer added a property indicating transfer-of-ownership? Or a new
> configuration option for postMessage ( { transferOwnership: true } )?
It should be possible to request transfer ownership of some objects in
the tree and not others. Otherwise, adding this feature to other
objects later won't be backwards-compatible, since a tree may contain
transferrable and non-transferrable objects.
--
Glenn Maynard
Re: CORS and HTTP headers spoofing
2011/5/31 Margarita Podskrobko : > Hello, > I was trying to find any information concerning CORS and HTTP headers > spoofing. Couldn't find any relevant information though. So if I am able to > set Origin header to some custom value, it means that there is no more > secure communication between domains as I can pretend to be anyone? How would you set the "Origin" header? / Jonas
Re: What changes to Web Messaging spec are proposed? [Was: Re: Using ArrayBuffer as payload for binary data to/from Web Workers]
On Thu, Jun 2, 2011 at 10:22 AM, ben turner wrote:
> On Thu, Jun 2, 2011 at 9:58 AM, Travis Leithead
> wrote:
>>
>> This plan requires all objects that want to opt-in to a new
>> transfer-of-ownership (or really
>> any special custom behavior for postMessage) to 1) participate in the
>> special inheritance
>> interface and 2) be isolated from the primary object graph being passed to
>> the first
>> parameter.
>
> I interpreted the proposal differently... This is what I envisioned:
>
> var bufferToTransfer = /* make ArrayBuffer */;
> var bufferToCopy = /* make ArrayBuffer */;
> var worker = /* make Worker */;
> var message = { buf1: bufferToTransfer, buf2: bufferToCopy };
> worker.postMessage(message, [bufferToTransfer]);
>
> We'd keep the structure exactly the same, it's just that when we clone
> 'message' we compare each object value to one of the ones passed in
> the transfer array. If the objects match (===) then we'd transfer it
> rather than copy it.
>
> Does that sound like what you were hoping for?
This would work for me. It's also a better design for MessagePorts IMO.
I also don't understand the reason for the requirement to have the
type participate in some specific inheritance chain. All that seems
needed to me is to enumerate the types which can be transferred rather
than copied as obviously transferring normal JS arrays or JS objects
is unlikely to be possible in todays JS implementations.
/ Jonas
Re: Status of URL Interface?
On 6/1/11 5:42 PM, Adam Barth wrote: I've been implementing bits and pieces in WebKit. If there's interest from other implementors, I'm happy to work on the document in the W3C process. I'm definitely interested in seeing this become a rec-track document. Ad-hoc pieces of this live in other specs. For instance, both WHATWG Stream API and FileAPI reference URL.createObjectURL(blob) as defined here: http://dev.w3.org/2006/webapi/FileAPI/#creating-revoking I'd like to see this interface live somewhere more formal than its present incarnation as a Google Doc. -- A*
Re: Testing Requirements
On Thu, Jun 2, 2011 at 5:50 PM, Philippe Le Hegaret wrote: > On Thu, 2011-06-02 at 17:47 +0200, Marcos Caceres wrote: >> Hi Philippe, >> Just wondering if we have different port support yet on test-w3c.org? >> Would be nice to at least have 81, 82 or something (any none-standard >> ports would be fine for me). I need ports to finish off the Widget >> Access Request Test Suite. > > Nope, I don't believe we have that but that should relatively easy to > add. How many extra do you need? Just a few (2 or 3). I think Anne will also appreciate this for the XHR test suite. -- Marcos Caceres http://datadriven.com.au
[Bug 12859] New: An IDL block for window.postMessage is lacking from the W3C spec.
http://www.w3.org/Bugs/Public/show_bug.cgi?id=12859 Summary: An IDL block for window.postMessage is lacking from the W3C spec. 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 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://dev.w3.org/html5/postmsg/ Section: http://www.whatwg.org/specs/web-apps/current-work/complete.html#top Comment: An IDL block for window.postMessage is lacking from the W3C spec. Posted from: 91.181.49.137 User agent: Mozilla/5.0 (X11; Linux i686; rv:7.0a1) Gecko/20110602 Firefox/7.0a1 -- 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: [Bug 12111] spec for Storage object getItem(key) method does not match implementation behavior
On Thu, 2 Jun 2011, Arthur Barstow wrote:
>
> Hixie, All - PLH proposed a fix for this bug in comment #5 (use
> DOMString instead of any in {get,set}Item).
>
> AFAIU, PLH's proposal matches what has been widely implemented. As such,
> it seems like the spec should be updated accordingly.
This isn't a bug, it's a new feature that just hasn't been implemented
yet.
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: Status of URL Interface?
On Thu, 2 Jun 2011, Arun Ranganathan wrote: > On 6/1/11 5:42 PM, Adam Barth wrote: > > I've been implementing bits and pieces in WebKit. If there's interest > > from other implementors, I'm happy to work on the document in the W3C > > process. > > I'm definitely interested in seeing this become a rec-track document. Ad-hoc > pieces of this live in other specs. For instance, both WHATWG Stream API and > FileAPI reference URL.createObjectURL(blob) as defined here: > > http://dev.w3.org/2006/webapi/FileAPI/#creating-revoking > > I'd like to see this interface live somewhere more formal than its > present incarnation as a Google Doc. Hear hear. I'm also interested in Adam's work on URL parsing and resolution; currently the HTML spec has some outdated text on this but it would be great for it to be fixed. I don't mind where this lives though (as an independent spec or in one of the existing specs). -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [Bug 12111] spec for Storage object getItem(key) method does not match implementation behavior
On Thu, 2011-06-02 at 18:38 +, Ian Hickson wrote:
> On Thu, 2 Jun 2011, Arthur Barstow wrote:
> >
> > Hixie, All - PLH proposed a fix for this bug in comment #5 (use
> > DOMString instead of any in {get,set}Item).
> >
> > AFAIU, PLH's proposal matches what has been widely implemented. As such,
> > it seems like the spec should be updated accordingly.
>
> This isn't a bug, it's a new feature that just hasn't been implemented
> yet.
I don't believe that this new feature will get implemented. It's going
to break too many pages on the Web,
Philippe
Re: [Bug 12111] spec for Storage object getItem(key) method does not match implementation behavior
On Thu, 2 Jun 2011, Philippe Le Hegaret wrote:
> On Thu, 2011-06-02 at 18:38 +, Ian Hickson wrote:
> > On Thu, 2 Jun 2011, Arthur Barstow wrote:
> > >
> > > Hixie, All - PLH proposed a fix for this bug in comment #5 (use
> > > DOMString instead of any in {get,set}Item).
> > >
> > > AFAIU, PLH's proposal matches what has been widely implemented. As
> > > such, it seems like the spec should be updated accordingly.
> >
> > This isn't a bug, it's a new feature that just hasn't been implemented
> > yet.
>
> I don't believe that this new feature will get implemented. It's going
> to break too many pages on the Web,
That's the kind of thing implementation feedback will determine.
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: What changes to Web Messaging spec are proposed? [Was: Re: Using ArrayBuffer as payload for binary data to/from Web Workers]
On Thu, 2 Jun 2011, ben turner wrote:
>
> I interpreted the proposal differently... This is what I envisioned:
>
> var bufferToTransfer = /* make ArrayBuffer */;
> var bufferToCopy = /* make ArrayBuffer */;
> var worker = /* make Worker */;
> var message = { buf1: bufferToTransfer, buf2: bufferToCopy };
> worker.postMessage(message, [bufferToTransfer]);
>
> We'd keep the structure exactly the same, it's just that when we clone
> 'message' we compare each object value to one of the ones passed in the
> transfer array. If the objects match (===) then we'd transfer it rather
> than copy it.
>
> Does that sound like what you were hoping for?
That's fine except for breaking compatibility with the current MessagePort
model, which is a pretty big problem.
On Thu, 2 Jun 2011, Jonas Sicking wrote:
>
> I also don't understand the reason for the requirement to have the type
> participate in some specific inheritance chain. All that seems needed to
> me is to enumerate the types which can be transferred rather than copied
> as obviously transferring normal JS arrays or JS objects is unlikely to
> be possible in todays JS implementations.
The idea here was just to have WebIDL do the type-checking instead of me.
The behaviour is black-box indistinguishable.
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [Bug 12111] spec for Storage object getItem(key) method does not match implementation behavior
On Thu, 2011-06-02 at 18:51 +, Ian Hickson wrote: > > I don't believe that this new feature will get implemented. It's going > > to break too many pages on the Web, > > That's the kind of thing implementation feedback will determine. You've got that feedback already. See http://www.w3.org/Bugs/Public/show_bug.cgi?id=12111#c3 Philippe
Re: [Bug 12111] spec for Storage object getItem(key) method does not match implementation behavior
On Jun/2/2011 2:51 PM, ext Ian Hickson wrote:
On Thu, 2 Jun 2011, Philippe Le Hegaret wrote:
On Thu, 2011-06-02 at 18:38 +, Ian Hickson wrote:
On Thu, 2 Jun 2011, Arthur Barstow wrote:
Hixie, All - PLH proposed a fix for this bug in comment #5 (use
DOMString instead of any in {get,set}Item).
AFAIU, PLH's proposal matches what has been widely implemented. As
such, it seems like the spec should be updated accordingly.
This isn't a bug, it's a new feature that just hasn't been implemented
yet.
I don't believe that this new feature will get implemented. It's going
to break too many pages on the Web,
That's the kind of thing implementation feedback will determine.
Or flip this around and spec what is widely implemented today and then
during the Candidate phase, implementors can submit feedback (e.g. if
DOMString doesn't cut it)?
Re: [Bug 12111] spec for Storage object getItem(key) method does not match implementation behavior
On Thu, 2 Jun 2011, Arthur Barstow wrote:
> On Jun/2/2011 2:51 PM, ext Ian Hickson wrote:
> > On Thu, 2 Jun 2011, Philippe Le Hegaret wrote:
> > > On Thu, 2011-06-02 at 18:38 +, Ian Hickson wrote:
> > > > On Thu, 2 Jun 2011, Arthur Barstow wrote:
> > > > > Hixie, All - PLH proposed a fix for this bug in comment #5 (use
> > > > > DOMString instead of any in {get,set}Item).
> > > > >
> > > > > AFAIU, PLH's proposal matches what has been widely implemented. As
> > > > > such, it seems like the spec should be updated accordingly.
> > > > This isn't a bug, it's a new feature that just hasn't been implemented
> > > > yet.
> > > I don't believe that this new feature will get implemented. It's going
> > > to break too many pages on the Web,
> > That's the kind of thing implementation feedback will determine.
>
> Or flip this around and spec what is widely implemented today and then
> during the Candidate phase, implementors can submit feedback (e.g. if
> DOMString doesn't cut it)?
It's always the candidate phase, as far as I'm concerned.
We've already had feedback that just DOMString was insufficent, e.g. it
doesn't let you store Blobs. That's actually why we added cloning in the
first place here. We've also received lots of author feedback to the same
effect. There's plenty of ways we can provide deep-cloning behaviour here
while still being compatible with legacy sites that don't expect it, e.g.
we can stringify primitive (non-reference) types, while still cloning
objects (reference types). However, exactly how this should be done
depends on what the exact constraints are. There's no rush in finding out
what the constraints are; implementors are busy doing lots of other things
at the moment. Eventually, this will bubble to the top and we'll find out,
and then we can update the spec accordingly.
The platform evolves at its own speed. There's nothing gained by rushing it.
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [Bug 12111] spec for Storage object getItem(key) method does not match implementation behavior
On Thu, 2 Jun 2011, Philippe Le Hegaret wrote: > On Thu, 2011-06-02 at 18:51 +, Ian Hickson wrote: > > > I don't believe that this new feature will get implemented. It's going > > > to break too many pages on the Web, > > > > That's the kind of thing implementation feedback will determine. > > You've got that feedback already. See > http://www.w3.org/Bugs/Public/show_bug.cgi?id=12111#c3 That isn't implementor feedback, and it says nothing about the volume of breakage. If Aryeh is the only person affected, then I'm sure he'd agree with me that that means we can change this without worry. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [Bug 12111] spec for Storage object getItem(key) method does not match implementation behavior
On Thu, 2011-06-02 at 19:00 +, Ian Hickson wrote: > On Thu, 2 Jun 2011, Philippe Le Hegaret wrote: > > On Thu, 2011-06-02 at 18:51 +, Ian Hickson wrote: > > > > I don't believe that this new feature will get implemented. It's going > > > > to break too many pages on the Web, > > > > > > That's the kind of thing implementation feedback will determine. > > > > You've got that feedback already. See > > http://www.w3.org/Bugs/Public/show_bug.cgi?id=12111#c3 > > That isn't implementor feedback, and it says nothing about the volume of > breakage. If Aryeh is the only person affected, then I'm sure he'd agree > with me that that means we can change this without worry. For what I'm concerned, I'm more interested in a spec this year that describe what has been working for the past 2 years than a spec that describe what might work in 2 years from now. I wonder if it's possible to work on such spec within the group, I'm willing to help. Philippe
Re: What changes to Web Messaging spec are proposed? [Was: Re: Using ArrayBuffer as payload for binary data to/from Web Workers]
On Thu, Jun 2, 2011 at 11:54 AM, Ian Hickson wrote:
> On Thu, 2 Jun 2011, ben turner wrote:
>>
>> I interpreted the proposal differently... This is what I envisioned:
>>
>> var bufferToTransfer = /* make ArrayBuffer */;
>> var bufferToCopy = /* make ArrayBuffer */;
>> var worker = /* make Worker */;
>> var message = { buf1: bufferToTransfer, buf2: bufferToCopy };
>> worker.postMessage(message, [bufferToTransfer]);
>>
>> We'd keep the structure exactly the same, it's just that when we clone
>> 'message' we compare each object value to one of the ones passed in the
>> transfer array. If the objects match (===) then we'd transfer it rather
>> than copy it.
>>
>> Does that sound like what you were hoping for?
>
> That's fine except for breaking compatibility with the current MessagePort
> model, which is a pretty big problem.
I'll note that Firefox does not support MessagePorts or the ports
argument, so it wouldn't be an backwards incompatible change for us.
I do seem to recall the Chrome does support it though so google would
have to chime in how happy they are about breaking compat here.
I don't know what the status is for Opera and Safari.
/ Jonas
Re: What changes to Web Messaging spec are proposed? [Was: Re: Using ArrayBuffer as payload for binary data to/from Web Workers]
In summary, there is a desire for a mechanism to transfer objects (to allow for potentially better perf) across a MessagePort. The mechanism: - needs to have an intuitive feel for developers, - must preserve backwards compatibility, - should ideally allow the port to function the same regardless of whether the message was cloned or transferred. - should be easy to use. There are three ideas for how to accomplish this: 1. Mixing in the list of objects to be cloned with the ports and use that list to determine what objects in the message should be cloned. This allows a lot of flexibility. It feels odd mixing in a list of objects with the ports when the two have nothing related. It also feels complicated having to add objects in two places (the message and this extra array). 2. Adding another parameter to postMessage "clone"/"transfer" or true/false, etc. It is less flexible than 1. It is very simple and easy to use. It may not be as noticeable when reading the code that this postMessage does a transfer of items. 3. Adding another method transferMessage with the same parameters as postMessage. It is less flexible than 1. It is very simple and easy to use. It may be a pain to keep this in sync with postMessage. It should be very noticeable when reading code. What do you think is the best way to expose this to web developers? dave
Re: What changes to Web Messaging spec are proposed? [Was: Re: Using ArrayBuffer as payload for binary data to/from Web Workers]
On 6/2/11 3:53 PM, David Levin wrote: The mechanism: * needs to have an intuitive feel for developers, * must preserve backwards compatibility, * should ideally allow the port to function the same regardless of whether the message was cloned or transferred. I'm not sure what you mean by that third item... the obvious meaning, which is that clone vs transfer is not black-box observable to the code calling postMessage makes no sense. There are three ideas for how to accomplish this: 4. Having separate arguments (in some order) for the ports and the list of objects to transfer. -Boris
Re: What changes to Web Messaging spec are proposed? [Was: Re: Using ArrayBuffer as payload for binary data to/from Web Workers]
On Thu, Jun 2, 2011 at 12:53 PM, David Levin wrote: > In summary, there is a desire for a mechanism to transfer objects (to allow > for potentially better perf) across a MessagePort. > The mechanism: > > needs to have an intuitive feel for developers, > must preserve backwards compatibility, > should ideally allow the port to function the same regardless of whether the > message was cloned or transferred. > should be easy to use. > > There are three ideas for how to accomplish this: > 1. Mixing in the list of objects to be cloned with the ports and use that > list to determine what objects in the message should be cloned. > > This allows a lot of flexibility. > It feels odd mixing in a list of objects with the ports when the two have > nothing related. > It also feels complicated having to add objects in two places (the message > and this extra array). Another option which was mentioned: 1a) Add another optional argument to postMessage after the array of ports, which would be an array of objects to transfer rather than clone. I think 1a) is the best way to expose the functionality. As Glenn pointed out, for backward and forward compatibility reasons, it's best if the developer explicitly selects the objects to transfer. The desire would be for this change to apply not just to the postMessage method on MessagePort and Worker but also to that on Window. -Ken > 2. Adding another parameter to postMessage "clone"/"transfer" or true/false, > etc. > > It is less flexible than 1. > It is very simple and easy to use. > It may not be as noticeable when reading the code that this postMessage does > a transfer of items. > > 3. Adding another method transferMessage with the same parameters as > postMessage. > > It is less flexible than 1. > It is very simple and easy to use. > It may be a pain to keep this in sync with postMessage. > It should be very noticeable when reading code. > > What do you think is the best way to expose this to web developers? > dave > >
Re: What changes to Web Messaging spec are proposed? [Was: Re: Using ArrayBuffer as payload for binary data to/from Web Workers]
On Thu, Jun 2, 2011 at 1:13 PM, Boris Zbarsky wrote: > On 6/2/11 3:53 PM, David Levin wrote: > >> The mechanism: >> >>* needs to have an intuitive feel for developers, >>* must preserve backwards compatibility, >>* should ideally allow the port to function the same regardless of >> whether the message was cloned or transferred. >> > > I'm not sure what you mean by that third item... the obvious meaning, > which is that clone vs transfer is not black-box observable to the code > calling postMessage makes no sense. The receiver of the message is what I meant to say. My edits lost some of the context. dave > There are three ideas for how to accomplish this: >> > > 4. Having separate arguments (in some order) for the ports and the list of > objects to transfer. > > -Boris > >
Re: What changes to Web Messaging spec are proposed? [Was: Re: Using ArrayBuffer as payload for binary data to/from Web Workers]
On Thu, Jun 2, 2011 at 4:16 PM, Kenneth Russell wrote:
> On Thu, Jun 2, 2011 at 12:53 PM, David Levin wrote:
> The desire would be for this change to apply not just to the
> postMessage method on MessagePort and Worker but also to that on
> Window.
I agree--the postMessage interfaces shouldn't drift apart more than
necessary. Adding another argument to window.postMessage would be
unfortunate, though: that brings it up to four, which is hitting the
limit of a sane, rememberable API.
Alternatively--and this has come up repeatedly of late--allow the
final argument to be an object. If it's an object, it looks like
this:
port.postMessage({frameBuffer: frame}, {transfer: [frame], ports: [port]});
where "transfer" and "port" are both optional. If it's an array, it
behaves as it does now.
This also allows preserving MessagePort error checking: you can still
throw INVALID_STATE_ERR if something other than a MessagePort is
included in ports.
--
Glenn Maynard
Re: What changes to Web Messaging spec are proposed? [Was: Re: Using ArrayBuffer as payload for binary data to/from Web Workers]
On Thu, Jun 2, 2011 at 1:27 PM, Glenn Maynard wrote:
> On Thu, Jun 2, 2011 at 4:16 PM, Kenneth Russell wrote:
> > On Thu, Jun 2, 2011 at 12:53 PM, David Levin wrote:
> > The desire would be for this change to apply not just to the
> > postMessage method on MessagePort and Worker but also to that on
> > Window.
>
> I agree--the postMessage interfaces shouldn't drift apart more than
> necessary. Adding another argument to window.postMessage would be
> unfortunate, though: that brings it up to four, which is hitting the
> limit of a sane, rememberable API.
>
> Alternatively--and this has come up repeatedly of late--allow the
> final argument to be an object. If it's an object, it looks like
> this:
>
> port.postMessage({frameBuffer: frame}, {transfer: [frame], ports: [port]});
>
> where "transfer" and "port" are both optional. If it's an array, it
> behaves as it does now.
>
> This also allows preserving MessagePort error checking: you can still
> throw INVALID_STATE_ERR if something other than a MessagePort is
> included in ports.
>
It feels like this array of objects given to transfer may complicate (and
slow down) both the implementation of this as well as the developer's use of
it.
It also raises questions when I see it. When I list an object there does it
imply that all children are also transfered or do I have to list each of
them explicitly as well?)
Then I wonder what is the use case for this complexity.
Why not something simpler like this?
port.postMessage({frameBuffer: frame}, {transfer: true, ports: [port]});
where you can just say indicate that you want the message transfered.
dave
Re: What changes to Web Messaging spec are proposed? [Was: Re: Using ArrayBuffer as payload for binary data to/from Web Workers]
On Thu, Jun 2, 2011 at 5:01 PM, David Levin wrote:
> It feels like this array of objects given to transfer may complicate (and
> slow down) both the implementation of this as well as the developer's use of
> it.
Even with thousands of objects, creating an array containing them is
quick (and only needs to be done once), and the implementation would
presumably convert it to a set internally for quick lookups. I doubt
most use cases will transfer so many separate objects, though.
(And Ian keeps drilling into our head that implementation complexity
isn't a major concern, though I don't imagine converting a list of
objects to a hash table is complex.)
In the typical cases, this seems both simple for users and fast.
> It also raises questions when I see it. When I list an object there does it
> imply that all children are also transfered or do I have to list each of
> them explicitly as well?)
Objects with children wouldn't support transfer--you don't transfer a
Javascript array or a basic Object this way.
Note that ImageData's ImagePixelData isn't a "child" as far as
structured clone is concerned; only Array and Object are cloned
recursively. If ImageData gains support for transfer, then you
wouldn't include the ImagePixelData in the list; only the ImageData
itself. (DATA_CLONE_ERR should probably be thrown if an item is
marked for transfer that isn't supported by structured clone, to make
errors related to this more obvious.)
> Then I wonder what is the use case for this complexity.
> Why not something simpler like this?
> port.postMessage({frameBuffer: frame}, {transfer: true, ports: [port]});
> where you can just say indicate that you want the message transfered.
Adding transfer support to more types in the future would become
backwards-incompatible.
--
Glenn Maynard
Re: [Bug 12111] spec for Storage object getItem(key) method does not match implementation behavior
On Thu, Jun 2, 2011 at 3:00 PM, Ian Hickson wrote: > That isn't implementor feedback, and it says nothing about the volume of > breakage. If Aryeh is the only person affected, then I'm sure he'd agree > with me that that means we can change this without worry. I do agree, but I don't think the spec should say that it uses the structured clone algorithm unless implementers are interested in changing. At the very least, it should have a note saying that no one implements it as-is, and requesting feedback from implementers on whether it can be changed.
RE: CORS and HTTP headers spoofing
> From: jo...@sicking.cc > Date: Thu, 2 Jun 2011 10:29:04 -0700 > Subject: Re: CORS and HTTP headers spoofing > To: mpodskro...@hotmail.com > CC: public-webapps@w3.org > > 2011/5/31 Margarita Podskrobko : > > Hello, > > I was trying to find any information concerning CORS and HTTP headers > > spoofing. Couldn't find any relevant information though. So if I am able to > > set Origin header to some custom value, it means that there is no more > > secure communication between domains as I can pretend to be anyone? > > How would you set the "Origin" header? > I have figured out at least one unexpected and surprisingly easy way to do it in Firefox. There is a firefox addon available , which lets set Origin header to any value. Addon is available from the following link: https://addons.mozilla.org/en-US/firefox/addon/modify-headers/ I have installed it and tried it with one simple web application. Well, what can I say... It works, and with this addon I can send a cross origin XHR with any value of Origin header. I have read couple of discussions in this mail list concerning security issues of CORS. AFAIU, the main point of CORS is to delegate security enforcement point from client browser(requestor of resource) to server (possessor of resource). The server decides whether to provide requested resource or not, and decision is based on the value of Origin header. And there is no way to check whether Origin header is fake or not. So my understanding is that only servers which allow requests from all origins or servers which completely forbid cross origin requests are in safe situation. All other ones are subjects to attacks, coming from same origin policy violation.Please, correct me if my understanding is inaccurate. Best regardsMargarita Podskrobko
Re: Request for feedback: DOMCrypt API proposal
Why only SHA256? Presumably sha1 and md5 are worth exposing as well.
Also, pk and sym appear to be algorithm agonistic but hash isn't. In
addition to hashing, it would be valuable to expose HMAC modes of the
hash functions.
In the pk API, there doesn't seem to be any way to install a
public/private keypair from another location (e.g., the network).
Also, the encrypt and decrypt functions don't let me specify which
public key I want to use. Consider introducing a keyID concept to let
me refer to keypairs.
What is a cipherAddressbook ?
When I use generateKeypair, how long dose the keypair persist? Is are
their privacy implications?
Finally, this all should be on the crypto object, not on a new cipher object.
Adam
On Wed, Jun 1, 2011 at 3:54 PM, David Dahl wrote:
> Hello public-webapps members,
>
> (I wanted to post this proposed draft spec for the DOMCrypt API (
> https://wiki.mozilla.org/Privacy/Features/DOMCryptAPISpec/Latest ) to this
> list - if there is a more fitting mailing list, please let me know)
>
> I recently posted this draft spec for a crypto API for browsers to the whatwg
> (see:
> http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-May/031741.html) and
> wanted to get feedback from W3C as well.
>
> Privacy and user control on the web is of utter importance. Tracking,
> unauthorized user data aggregation and personal information breaches are
> becoming so commonplace you see a new headline almost daily. (It seems).
>
> We need crypto APIs in browsers to allow developers to create more secure
> communications tools and web applications that don’t have to implicitly trust
> the server, among other use cases.
>
> The DOMCrypt API is a good start, and more feedback and discussion will
> really help round out how all of this should work – as well as how it can
> work in any browser that will support such an API.
>
> This API will provide each web browser window with a ‘cipher’ property[1]
> that facilitates:
>
> asymmetric encryption key pair generation
> public key encryption
> public key decryption
> symmetric encryption
> signature generation
> signature verification
> hashing
> easy public key discovery via meta tags or an ‘addressbookentry’ tag
>
> [1] There is a bit of discussion around adding this API to window.navigator
> or consolidation within window.crypto
>
> I have created a Firefox extension that implements most of the above, and am
> working on an experimental patch that integrates this API into Firefox.
>
> The project originated in an extension I wrote, the home page is here:
> http://domcrypt.org
>
> The source code for the extension is here:
> https://github.com/daviddahl/domcrypt
>
> The Mozilla bugs are here:
>
> https://bugzilla.mozilla.org/show_bug.cgi?id=649154
> https://bugzilla.mozilla.org/show_bug.cgi?id=657432
>
> Firefox "feature wiki page":
> https://wiki.mozilla.org/Privacy/Features/DOMCryptAPI
>
> You can test the API by installing the extension hosted at domcrypt.org, and
> going to http://domcrypt.org
>
> A recent blog post updating all of this is posted here:
> http://monocleglobe..wordpress.com/2011/06/01/domcrypt-update-2011-06-01/
>
> The API:
>
> window.cipher = {
> // Public Key API
> pk: {
> set algorithm(algorithm){ },
> get algorithm(){ },
>
> // Generate a keypair and then execute the callback function
> generateKeypair: function ( function callback( aPublicKey ) { } ) { },
>
> // encrypt a plainText
> encrypt: function ( plainText, function callback (cipherMessageObject) ) {
> } ) { },
>
> // decrypt a cipherMessage
> decrypt: function ( cipherMessageObject, function callback ( plainText ) { }
> ) { },
>
> // sign a message
> sign: function ( plainText, function callback ( signature ) { } ) { },
>
> // verify a signature
> verify: function ( signature, plainText, function callback ( boolean ) { } )
> { },
>
> // get the JSON cipherAddressbook
> get addressbook() {},
>
> // make changes to the addressbook
> saveAddressbook: function (JSONObject, function callback ( addresssbook ) {
> }) { }
> },
>
> // Symmetric Crypto API
> sym: {
> get algorithm(),
> set algorithm(algorithm),
>
> // create a new symmetric key
> generateKey: function (function callback ( key ){ }) { },
>
> // encrypt some data
> encrypt: function (plainText, key, function callback( cipherText ){ }) { },
>
> // decrypt some data
> decrypt: function (cipherText, key, function callback( plainText ) { }) { },
> },
>
> // hashing
> hash: {
> SHA256: function (function callback (hash){}) { }
> }
> }
>
> Your feedback and criticism will be invaluable.
>
> Best regards,
>
> David Dahl
>
> Firefox Engineer, Mozilla Corp.
>
>
>
Re: Request for feedback: DOMCrypt API proposal
This spec is also incredibly vague:
https://wiki.mozilla.org/Privacy/Features/DOMCryptAPISpec/Latest
There's no description of what these functions do. There's no way
this spec can be used to create a second interoperable implementation.
Adam
On Thu, Jun 2, 2011 at 4:19 PM, Adam Barth wrote:
> Why only SHA256? Presumably sha1 and md5 are worth exposing as well.
> Also, pk and sym appear to be algorithm agonistic but hash isn't. In
> addition to hashing, it would be valuable to expose HMAC modes of the
> hash functions.
>
> In the pk API, there doesn't seem to be any way to install a
> public/private keypair from another location (e.g., the network).
> Also, the encrypt and decrypt functions don't let me specify which
> public key I want to use. Consider introducing a keyID concept to let
> me refer to keypairs.
>
> What is a cipherAddressbook ?
>
> When I use generateKeypair, how long dose the keypair persist? Is are
> their privacy implications?
>
> Finally, this all should be on the crypto object, not on a new cipher object.
>
> Adam
>
>
> On Wed, Jun 1, 2011 at 3:54 PM, David Dahl wrote:
>> Hello public-webapps members,
>>
>> (I wanted to post this proposed draft spec for the DOMCrypt API (
>> https://wiki.mozilla.org/Privacy/Features/DOMCryptAPISpec/Latest ) to this
>> list - if there is a more fitting mailing list, please let me know)
>>
>> I recently posted this draft spec for a crypto API for browsers to the
>> whatwg (see:
>> http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-May/031741.html)
>> and wanted to get feedback from W3C as well.
>>
>> Privacy and user control on the web is of utter importance. Tracking,
>> unauthorized user data aggregation and personal information breaches are
>> becoming so commonplace you see a new headline almost daily. (It seems).
>>
>> We need crypto APIs in browsers to allow developers to create more secure
>> communications tools and web applications that don’t have to implicitly
>> trust the server, among other use cases.
>>
>> The DOMCrypt API is a good start, and more feedback and discussion will
>> really help round out how all of this should work – as well as how it can
>> work in any browser that will support such an API.
>>
>> This API will provide each web browser window with a ‘cipher’ property[1]
>> that facilitates:
>>
>> asymmetric encryption key pair generation
>> public key encryption
>> public key decryption
>> symmetric encryption
>> signature generation
>> signature verification
>> hashing
>> easy public key discovery via meta tags or an ‘addressbookentry’ tag
>>
>> [1] There is a bit of discussion around adding this API to window.navigator
>> or consolidation within window.crypto
>>
>> I have created a Firefox extension that implements most of the above, and am
>> working on an experimental patch that integrates this API into Firefox.
>>
>> The project originated in an extension I wrote, the home page is here:
>> http://domcrypt.org
>>
>> The source code for the extension is here:
>> https://github.com/daviddahl/domcrypt
>>
>> The Mozilla bugs are here:
>>
>> https://bugzilla.mozilla.org/show_bug.cgi?id=649154
>> https://bugzilla.mozilla.org/show_bug.cgi?id=657432
>>
>> Firefox "feature wiki page":
>> https://wiki.mozilla.org/Privacy/Features/DOMCryptAPI
>>
>> You can test the API by installing the extension hosted at domcrypt.org, and
>> going to http://domcrypt.org
>>
>> A recent blog post updating all of this is posted here:
>> http://monocleglobe..wordpress.com/2011/06/01/domcrypt-update-2011-06-01/
>>
>> The API:
>>
>> window.cipher = {
>> // Public Key API
>> pk: {
>> set algorithm(algorithm){ },
>> get algorithm(){ },
>>
>> // Generate a keypair and then execute the callback function
>> generateKeypair: function ( function callback( aPublicKey ) { } ) { },
>>
>> // encrypt a plainText
>> encrypt: function ( plainText, function callback (cipherMessageObject) ) {
>> } ) { },
>>
>> // decrypt a cipherMessage
>> decrypt: function ( cipherMessageObject, function callback ( plainText ) {
>> } ) { },
>>
>> // sign a message
>> sign: function ( plainText, function callback ( signature ) { } ) { },
>>
>> // verify a signature
>> verify: function ( signature, plainText, function callback ( boolean ) { }
>> ) { },
>>
>> // get the JSON cipherAddressbook
>> get addressbook() {},
>>
>> // make changes to the addressbook
>> saveAddressbook: function (JSONObject, function callback ( addresssbook ) {
>> }) { }
>> },
>>
>> // Symmetric Crypto API
>> sym: {
>> get algorithm(),
>> set algorithm(algorithm),
>>
>> // create a new symmetric key
>> generateKey: function (function callback ( key ){ }) { },
>>
>> // encrypt some data
>> encrypt: function (plainText, key, function callback( cipherText ){ }) { },
>>
>> // decrypt some data
>> decrypt: function (cipherText, key, function callback( plainText ) { }) {
>> },
>> },
>>
>> // hashing
>> hash: {
>>
Re: What changes to Web Messaging spec are proposed? [Was: Re: Using ArrayBuffer as payload for binary data to/from Web Workers]
On Thu, Jun 2, 2011 at 2:01 PM, David Levin wrote:
>
>
> On Thu, Jun 2, 2011 at 1:27 PM, Glenn Maynard wrote:
>>
>> On Thu, Jun 2, 2011 at 4:16 PM, Kenneth Russell wrote:
>> > On Thu, Jun 2, 2011 at 12:53 PM, David Levin wrote:
>> > The desire would be for this change to apply not just to the
>> > postMessage method on MessagePort and Worker but also to that on
>> > Window.
>>
>> I agree--the postMessage interfaces shouldn't drift apart more than
>> necessary. Adding another argument to window.postMessage would be
>> unfortunate, though: that brings it up to four, which is hitting the
>> limit of a sane, rememberable API.
>>
>> Alternatively--and this has come up repeatedly of late--allow the
>> final argument to be an object. If it's an object, it looks like
>> this:
>>
>> port.postMessage({frameBuffer: frame}, {transfer: [frame], ports:
>> [port]});
>>
>> where "transfer" and "port" are both optional. If it's an array, it
>> behaves as it does now.
>>
>> This also allows preserving MessagePort error checking: you can still
>> throw INVALID_STATE_ERR if something other than a MessagePort is
>> included in ports.
>
>
> It feels like this array of objects given to transfer may complicate (and
> slow down) both the implementation of this as well as the developer's use of
> it.
How so? You basically use the normal API, but if there are any objects
which you'd like to have transfer the ownership of, you additionally
list them in the second argument.
There are two properties of this approach that I like:
1. It means that objects which you'd like to transfer ownership are
not "second class citizens" and can live as part of the normal object
graph that is posted, together with metadata that goes with it (or
even as metadata for other things).
2. The receiving side doesn't need to worry about the difference, all
it gets is the graph of objects that was sent to it.
> It also raises questions when I see it. When I list an object there does it
> imply that all children are also transfered or do I have to list each of
> them explicitly as well?)
None of the objects which allow transferring of ownership has children
so this doesn't appear to be a problem at this time. If it indeed does
turn into a problem, it would seem like a problem no matter what
solution is used, no?
> Then I wonder what is the use case for this complexity.
> Why not something simpler like this?
> port.postMessage({frameBuffer: frame}, {transfer: true, ports: [port]});
> where you can just say indicate that you want the message transfered.
This means that you have to choose between transferring all arrays and
transferring none of them. It also makes it much less explicit which
objects ends up being mutated.
/ Jonas
Re: What changes to Web Messaging spec are proposed? [Was: Re: Using ArrayBuffer as payload for binary data to/from Web Workers]
On Thu, Jun 2, 2011 at 5:30 PM, Glenn Maynard wrote: > On Thu, Jun 2, 2011 at 5:01 PM, David Levin wrote: >> It feels like this array of objects given to transfer may complicate (and >> slow down) both the implementation of this as well as the developer's use of >> it. > > Even with thousands of objects, creating an array containing them is > quick (and only needs to be done once), and the implementation would > presumably convert it to a set internally for quick lookups. I doubt > most use cases will transfer so many separate objects, though. > > (And Ian keeps drilling into our head that implementation complexity > isn't a major concern, though I don't imagine converting a list of > objects to a hash table is complex.) It's spec complexity he was talking about--but anyway, making a hash table or tree from a list doesn't seem complicated; maybe there are other issues. I suppose this could also be done with a per-object flag, eg. arrayBuffer.setCloneTransfer(true), but as it's the postMessage call being modified I'm not sure flagging it on the object itself is clearer. -- Glenn Maynard
Re: CORS and HTTP headers spoofing
2011/6/2 Margarita Podskrobko : > >> From: jo...@sicking.cc >> Date: Thu, 2 Jun 2011 10:29:04 -0700 >> Subject: Re: CORS and HTTP headers spoofing >> To: mpodskro...@hotmail.com >> CC: public-webapps@w3.org >> >> 2011/5/31 Margarita Podskrobko : >> > Hello, >> > I was trying to find any information concerning CORS and HTTP headers >> > spoofing. Couldn't find any relevant information though. So if I am able >> > to >> > set Origin header to some custom value, it means that there is no more >> > secure communication between domains as I can pretend to be anyone? >> >> How would you set the "Origin" header? >> > > I have figured out at least one unexpected and surprisingly easy way to do > it in Firefox. There is a firefox addon available , which lets set Origin > header to any value. Addon is available from the following > link: https://addons.mozilla.org/en-US/firefox/addon/modify-headers/ I have > installed it and tried it with one simple web application. Well, what can I > say... It works, and with this addon I can send a cross origin XHR with any > value of Origin header. So your concern is that the user would install an addon and use that to attack a target site? What type of attack are you concerned that the user would be able to perform? I.e. what type of data are you worried that the user could steal? Or what type of harm are you worried that the user would be able to cause on the website? CORS was mostly written with the intent of protecting the users data which is stored in various web servers. Obviously the user attacking the webserver to steal his or her own data isn't much of a concern. This is why I'm asking the above question. / Jonas
Re: What changes to Web Messaging spec are proposed? [Was: Re: Using ArrayBuffer as payload for binary data to/from Web Workers]
On Thu, Jun 2, 2011 at 4:24 PM, Jonas Sicking wrote:
> On Thu, Jun 2, 2011 at 2:01 PM, David Levin wrote:
> >
> >
> > On Thu, Jun 2, 2011 at 1:27 PM, Glenn Maynard wrote:
> >> port.postMessage({frameBuffer: frame}, {transfer: [frame], ports:
> >> [port]});
>
> There are two properties of this approach that I like:
>
> 1. It means that objects which you'd like to transfer ownership are
> not "second class citizens" and can live as part of the normal object
> graph that is posted, together with metadata that goes with it (or
> even as metadata for other things).
>
> 2. The receiving side doesn't need to worry about the difference, all
> it gets is the graph of objects that was sent to it.
>
Yep, I totally agree with this. All of the current solutions being discussed
satisfy both of these in fact.
>
> > It also raises questions when I see it. When I list an object there does
> it
> > imply that all children are also transfered or do I have to list each of
> > them explicitly as well?)
>
> None of the objects which allow transferring of ownership has children
> so this doesn't appear to be a problem at this time. If it indeed does
> turn into a problem, it would seem like a problem no matter what
> solution is used, no?
>
Not if all objects are transferred.
> > Then I wonder what is the use case for this complexity.
> > Why not something simpler like this?
> > port.postMessage({frameBuffer: frame}, {transfer: true, ports:
> [port]});
> > where you can just say indicate that you want the message transfered.
>
> This means that you have to choose between transferring all arrays and
> transferring none of them.
Yep, why add the complication of picking individual items to transfer
over? (I'm wary of second system syndrome, which I've seen happen many
times in various designs.)
> It also makes it much less explicit which
> objects ends up being mutated.
>
It is all of them.
Here's a simple use case, suppose I create an array of arrays (a 2d array)
which contains ArrayBuffers.Now I want to transfer this as fast as possible
using postMessage.
What does my code look like for each of these apis?
dave
Re: Request for feedback: DOMCrypt API proposal
- Original Message -
From: "Adam Barth"
To: "David Dahl"
Cc: public-webapps@w3.org
Sent: Thursday, June 2, 2011 6:19:24 PM
Subject: Re: Request for feedback: DOMCrypt API proposal
> Why only SHA256? Presumably sha1 and md5 are worth exposing as well.
Also, pk and sym appear to be algorithm agonistic but hash isn't. In
addition to hashing, it would be valuable to expose HMAC modes of the
hash functions.
hash should probably have SHA512 as well, also, I just added an hmac API to the
spec.
> In the pk API, there doesn't seem to be any way to install a
public/private keypair from another location (e.g., the network).
No, there is not. Can you suggest what that API would look like? Importing keys
should be allowed.
> Also, the encrypt and decrypt functions don't let me specify which
public key I want to use. Consider introducing a keyID concept to let
me refer to keypairs.
Hmmm, I updated the wiki today as I forgot to include the pubKey on encrypt().
There should be a setter and getter for specifying the keypair to use.
> What is a cipherAddressbook ?
It is an object literal that you store discovered public keys in - which are
referred to as "addressbook entries". The Addressbook bits of this API will
have to wait for their own spec I think. i was trying to allow for key
discovery and storage in the simplest way possible: a custom tag or meta tag is
published on your blog and your contacts are alerted by the browser during a
visit to the page. The user can then store that 'addressbook entry' (or key)
for later use.
> When I use generateKeypair, how long dose the keypair persist? Is are
their privacy implications?
There is nothing in the spec right now. I should probably use a standard cert
type that declares validity dates.
> Finally, this all should be on the crypto object, not on a new cipher object.
More and more people are saying that.
Thanks,
David
On Wed, Jun 1, 2011 at 3:54 PM, David Dahl wrote:
> Hello public-webapps members,
>
> (I wanted to post this proposed draft spec for the DOMCrypt API (
> https://wiki.mozilla.org/Privacy/Features/DOMCryptAPISpec/Latest ) to this
> list - if there is a more fitting mailing list, please let me know)
>
> I recently posted this draft spec for a crypto API for browsers to the whatwg
> (see:
> http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-May/031741.html) and
> wanted to get feedback from W3C as well.
>
> Privacy and user control on the web is of utter importance. Tracking,
> unauthorized user data aggregation and personal information breaches are
> becoming so commonplace you see a new headline almost daily. (It seems).
>
> We need crypto APIs in browsers to allow developers to create more secure
> communications tools and web applications that don’t have to implicitly trust
> the server, among other use cases.
>
> The DOMCrypt API is a good start, and more feedback and discussion will
> really help round out how all of this should work – as well as how it can
> work in any browser that will support such an API.
>
> This API will provide each web browser window with a ‘cipher’ property[1]
> that facilitates:
>
> asymmetric encryption key pair generation
> public key encryption
> public key decryption
> symmetric encryption
> signature generation
> signature verification
> hashing
> easy public key discovery via meta tags or an ‘addressbookentry’ tag
>
> [1] There is a bit of discussion around adding this API to window.navigator
> or consolidation within window.crypto
>
> I have created a Firefox extension that implements most of the above, and am
> working on an experimental patch that integrates this API into Firefox.
>
> The project originated in an extension I wrote, the home page is here:
> http://domcrypt.org
>
> The source code for the extension is here:
> https://github.com/daviddahl/domcrypt
>
> The Mozilla bugs are here:
>
> https://bugzilla.mozilla.org/show_bug.cgi?id=649154
> https://bugzilla.mozilla.org/show_bug.cgi?id=657432
>
> Firefox "feature wiki page":
> https://wiki.mozilla.org/Privacy/Features/DOMCryptAPI
>
> You can test the API by installing the extension hosted at domcrypt.org, and
> going to http://domcrypt.org
>
> A recent blog post updating all of this is posted here:
> http://monocleglobe..wordpress.com/2011/06/01/domcrypt-update-2011-06-01/
>
> The API:
>
> window.cipher = {
> // Public Key API
> pk: {
> set algorithm(algorithm){ },
> get algorithm(){ },
>
> // Generate a keypair and then execute the callback function
> generateKeypair: function ( function callback( aPublicKey ) { } ) { },
>
> // encrypt a plainText
> encrypt: function ( plainText, function callback (cipherMessageObject) ) {
> } ) { },
>
> // decrypt a cipherMessage
> decrypt: function ( cipherMessageObject, function callback ( plainText ) { }
> ) { },
>
> // sign a message
> sign: function ( plainText, function callback ( signature ) { } ) {
Re: Request for feedback: DOMCrypt API proposal
- Original Message -
From: "Adam Barth"
To: "David Dahl"
Cc: public-webapps@w3.org
Sent: Thursday, June 2, 2011 6:21:24 PM
Subject: Re: Request for feedback: DOMCrypt API proposal
> This spec is also incredibly vague:
>
> https://wiki.mozilla.org/Privacy/Features/DOMCryptAPISpec/Latest
> There's no description of what these functions do. There's no way
this spec can be used to create a second interoperable implementation.
I really need to change the format to WebIDL or something along those lines.
Thanks,
David
On Thu, Jun 2, 2011 at 4:19 PM, Adam Barth wrote:
> Why only SHA256? Presumably sha1 and md5 are worth exposing as well.
> Also, pk and sym appear to be algorithm agonistic but hash isn't. In
> addition to hashing, it would be valuable to expose HMAC modes of the
> hash functions.
>
> In the pk API, there doesn't seem to be any way to install a
> public/private keypair from another location (e.g., the network).
> Also, the encrypt and decrypt functions don't let me specify which
> public key I want to use. Consider introducing a keyID concept to let
> me refer to keypairs.
>
> What is a cipherAddressbook ?
>
> When I use generateKeypair, how long dose the keypair persist? Is are
> their privacy implications?
>
> Finally, this all should be on the crypto object, not on a new cipher object.
>
> Adam
>
>
> On Wed, Jun 1, 2011 at 3:54 PM, David Dahl wrote:
>> Hello public-webapps members,
>>
>> (I wanted to post this proposed draft spec for the DOMCrypt API (
>> https://wiki.mozilla.org/Privacy/Features/DOMCryptAPISpec/Latest ) to this
>> list - if there is a more fitting mailing list, please let me know)
>>
>> I recently posted this draft spec for a crypto API for browsers to the
>> whatwg (see:
>> http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-May/031741.html)
>> and wanted to get feedback from W3C as well.
>>
>> Privacy and user control on the web is of utter importance. Tracking,
>> unauthorized user data aggregation and personal information breaches are
>> becoming so commonplace you see a new headline almost daily. (It seems).
>>
>> We need crypto APIs in browsers to allow developers to create more secure
>> communications tools and web applications that don’t have to implicitly
>> trust the server, among other use cases.
>>
>> The DOMCrypt API is a good start, and more feedback and discussion will
>> really help round out how all of this should work – as well as how it can
>> work in any browser that will support such an API.
>>
>> This API will provide each web browser window with a ‘cipher’ property[1]
>> that facilitates:
>>
>> asymmetric encryption key pair generation
>> public key encryption
>> public key decryption
>> symmetric encryption
>> signature generation
>> signature verification
>> hashing
>> easy public key discovery via meta tags or an ‘addressbookentry’ tag
>>
>> [1] There is a bit of discussion around adding this API to window.navigator
>> or consolidation within window.crypto
>>
>> I have created a Firefox extension that implements most of the above, and am
>> working on an experimental patch that integrates this API into Firefox.
>>
>> The project originated in an extension I wrote, the home page is here:
>> http://domcrypt.org
>>
>> The source code for the extension is here:
>> https://github.com/daviddahl/domcrypt
>>
>> The Mozilla bugs are here:
>>
>> https://bugzilla.mozilla.org/show_bug.cgi?id=649154
>> https://bugzilla.mozilla.org/show_bug.cgi?id=657432
>>
>> Firefox "feature wiki page":
>> https://wiki.mozilla.org/Privacy/Features/DOMCryptAPI
>>
>> You can test the API by installing the extension hosted at domcrypt.org, and
>> going to http://domcrypt.org
>>
>> A recent blog post updating all of this is posted here:
>> http://monocleglobe..wordpress.com/2011/06/01/domcrypt-update-2011-06-01/
>>
>> The API:
>>
>> window.cipher = {
>> // Public Key API
>> pk: {
>> set algorithm(algorithm){ },
>> get algorithm(){ },
>>
>> // Generate a keypair and then execute the callback function
>> generateKeypair: function ( function callback( aPublicKey ) { } ) { },
>>
>> // encrypt a plainText
>> encrypt: function ( plainText, function callback (cipherMessageObject) ) {
>> } ) { },
>>
>> // decrypt a cipherMessage
>> decrypt: function ( cipherMessageObject, function callback ( plainText ) {
>> } ) { },
>>
>> // sign a message
>> sign: function ( plainText, function callback ( signature ) { } ) { },
>>
>> // verify a signature
>> verify: function ( signature, plainText, function callback ( boolean ) { }
>> ) { },
>>
>> // get the JSON cipherAddressbook
>> get addressbook() {},
>>
>> // make changes to the addressbook
>> saveAddressbook: function (JSONObject, function callback ( addresssbook ) {
>> }) { }
>> },
>>
>> // Symmetric Crypto API
>> sym: {
>> get algorithm(),
>> set algorithm(algorithm),
>>
>> // create a new symmetric key
>> generateKey: function (function c
Re: CORS and HTTP headers spoofing
On 6/2/11 6:41 PM, Margarita Podskrobko wrote: I have read couple of discussions in this mail list concerning security issues of CORS. AFAIU, the main point of CORS is to delegate security enforcement point from client browser(requestor of resource) to server (possessor of resource). It's the other way around. It's to delegate the security enforcement to the _browser_. The server responds with the resource and Access-Control-Allow-Origin and the browser uses that information to decide whether to give the data to the origin that asked for it. The Origin header the browser sends is effectively advisory; clearly anyone can always send an HTTP request to a server with a given Origin header (using telnet to port 80, say!). So the server should not be making any assumptions about what the Origin header really means security-wise. So my understanding is that only servers which allow requests from all origins or servers which completely forbid cross origin requests are in safe situation. The client can always send an Origin header claiming the request is same-origin. -Boris
Re: Request for feedback: DOMCrypt API proposal
On Thu, Jun 2, 2011 at 4:46 PM, David Dahl wrote: > - Original Message - > From: "Adam Barth" > To: "David Dahl" > Cc: public-webapps@w3.org > Sent: Thursday, June 2, 2011 6:19:24 PM > Subject: Re: Request for feedback: DOMCrypt API proposal > >> Why only SHA256? Presumably sha1 and md5 are worth exposing as well. > Also, pk and sym appear to be algorithm agonistic but hash isn't. In > addition to hashing, it would be valuable to expose HMAC modes of the > hash functions. > > hash should probably have SHA512 as well, also, I just added an hmac API to > the spec. Really, the API should be algorithm agnostic. We can discuss separately which algorithms to provide. >> In the pk API, there doesn't seem to be any way to install a > public/private keypair from another location (e.g., the network). > > No, there is not. Can you suggest what that API would look like? Importing > keys should be allowed. Something like crypto.pk.importKey(keyBlob) where keyBlob is something like a string containing the keypair in something like PEM format. >> Also, the encrypt and decrypt functions don't let me specify which > public key I want to use. Consider introducing a keyID concept to let > me refer to keypairs. > > Hmmm, I updated the wiki today as I forgot to include the pubKey on > encrypt(). There should be a setter and getter for specifying the keypair to > use. Decrypt needs to take a keypair too (or at least a keyid). As the caller of the API, you want control over which of your secrets are used to decrypt the message! Otherwise, you can get it big trouble if you accidentally decrypt with a powerful key. >> What is a cipherAddressbook ? > > It is an object literal that you store discovered public keys in - which are > referred to as "addressbook entries". The Addressbook bits of this API will > have to wait for their own spec I think. i was trying to allow for key > discovery and storage in the simplest way possible: a custom tag or meta tag > is published on your blog and your contacts are alerted by the browser during > a visit to the page. The user can then store that 'addressbook entry' (or > key) for later use. Oh man. I'd remove this from the spec. That's a whole other can of worms. This API should just be the nuts and bolts of the crypto. >> When I use generateKeypair, how long dose the keypair persist? Is are > their privacy implications? > There is nothing in the spec right now. I should probably use a standard cert > type that declares validity dates. This is a very important question. Also, what sites are allowed to use the generated keypair? One hopes just the origin that generated it. You could also ask for something tighter so that some random XSS in one page won't completely compromise all my keys. You really need to spell all this stuff out in the spec. What you haven now just completely lacks any details about what these functions actually do. >> Finally, this all should be on the crypto object, not on a new cipher object. > > More and more people are saying that. Maybe you should listen to them? On Thu, Jun 2, 2011 at 4:47 PM, David Dahl wrote: >> This spec is also incredibly vague: >> >> https://wiki.mozilla.org/Privacy/Features/DOMCryptAPISpec/Latest > >> There's no description of what these functions do. There's no way > this spec can be used to create a second interoperable implementation. > > I really need to change the format to WebIDL or something along those lines. You should do that, of course, but that's just the first step. You need to actually explain what these functions do in a level of detail such that someone else could implement them in exactly the same way as you have without looking at your implementation. That's what it means to be an standard for the open web. Adam > On Wed, Jun 1, 2011 at 3:54 PM, David Dahl wrote: >> Hello public-webapps members, >> >> (I wanted to post this proposed draft spec for the DOMCrypt API ( >> https://wiki.mozilla.org/Privacy/Features/DOMCryptAPISpec/Latest ) to this >> list - if there is a more fitting mailing list, please let me know) >> >> I recently posted this draft spec for a crypto API for browsers to the >> whatwg (see: >> http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-May/031741.html) >> and wanted to get feedback from W3C as well. >> >> Privacy and user control on the web is of utter importance. Tracking, >> unauthorized user data aggregation and personal information breaches are >> becoming so commonplace you see a new headline almost daily. (It seems). >> >> We need crypto APIs in browsers to allow developers to create more secure >> communications tools and web applications that don’t have to implicitly >> trust the server, among other use cases. >> >> The DOMCrypt API is a good start, and more feedback and discussion will >> really help round out how all of this should work – as well as how it can >> work in any browser that will support such an API. >
Re: What changes to Web Messaging spec are proposed? [Was: Re: Using ArrayBuffer as payload for binary data to/from Web Workers]
On Thu, Jun 2, 2011 at 4:41 PM, David Levin wrote:
>
>
> On Thu, Jun 2, 2011 at 4:24 PM, Jonas Sicking wrote:
>>
>> On Thu, Jun 2, 2011 at 2:01 PM, David Levin wrote:
>> >
>> >
>> > On Thu, Jun 2, 2011 at 1:27 PM, Glenn Maynard wrote:
>> >> port.postMessage({frameBuffer: frame}, {transfer: [frame], ports:
>> >> [port]});
>>
>> There are two properties of this approach that I like:
>>
>> 1. It means that objects which you'd like to transfer ownership are
>> not "second class citizens" and can live as part of the normal object
>> graph that is posted, together with metadata that goes with it (or
>> even as metadata for other things).
>>
>> 2. The receiving side doesn't need to worry about the difference, all
>> it gets is the graph of objects that was sent to it.
>
> Yep, I totally agree with this. All of the current solutions being discussed
> satisfy both of these in fact.
>
>>
>> > It also raises questions when I see it. When I list an object there does
>> > it
>> > imply that all children are also transfered or do I have to list each of
>> > them explicitly as well?)
>>
>> None of the objects which allow transferring of ownership has children
>> so this doesn't appear to be a problem at this time. If it indeed does
>> turn into a problem, it would seem like a problem no matter what
>> solution is used, no?
>
> Not if all objects are transferred.
Define "all objects". Consider something like:
a = { x: myArrayBuffer1, y: myArrayBuffer2 };
worker.postMessage(a, { transfer: true });
In this case the 'a' object is obviously not transferred. Or are you
proposing that it'd be transferred too somehow?
>> > Then I wonder what is the use case for this complexity.
>> > Why not something simpler like this?
>> > port.postMessage({frameBuffer: frame}, {transfer: true, ports:
>> > [port]});
>> > where you can just say indicate that you want the message transfered.
>>
>> This means that you have to choose between transferring all arrays and
>> transferring none of them.
>
> Yep, why add the complication of picking individual items to transfer
> over? (I'm wary of second system syndrome, which I've seen happen many
> times in various designs.)
>
>>
>> It also makes it much less explicit which
>> objects ends up being mutated.
>
> It is all of them.
Sure, but what "all" includes might not be obvious to the web
developer in all cases. For example if you're receiving an object from
some subsystem that you intend to do processing on. You later decide
to do the processing in a thread and throw that object into an array
alongside with some other data. Some of the "other data" you are
throwing in includes some big arrays that you want to avoid copying
and so you choose to use the transfer rather than copy mode.
Now you all of a sudden start modifying the data that you got from the
other subsystem. This is data that you might normally not be even
looking at. The fact that it happened to contain some ArrayBuffers was
just a side effect of that that was the data structures that the other
subsystem uses and was easy for it to return to you.
> Here's a simple use case, suppose I create an array of arrays (a 2d array)
> which contains ArrayBuffers.Now I want to transfer this as fast as possible
> using postMessage.
> What does my code look like for each of these apis?
Your proposal:
w.postMessage(my2darray, {transfer: true});
vs.
w.postMessage(my2darray, Array.concat.apply(Array, my2darray));
Now show me the code needed to send a message which contains one big
buffer from you that you want to transfer, along with some data that
you got from some other piece of code and which you do not want to
modify and which may or may not contain ArrayBuffers.
/ Jonas
Re: Request for feedback: DOMCrypt API proposal
I unfortunately know very little about crypto (at least compared to this crowd), so I can't provide much useful input. But I do have a few comments. >>> What is a cipherAddressbook ? >> >> It is an object literal that you store discovered public keys in - which are >> referred to as "addressbook entries". The Addressbook bits of this API will >> have to wait for their own spec I think. i was trying to allow for key >> discovery and storage in the simplest way possible: a custom tag or meta tag >> is published on your blog and your contacts are alerted by the browser >> during a visit to the page. The user can then store that 'addressbook entry' >> (or key) for later use. > > Oh man. I'd remove this from the spec. That's a whole other can of > worms. This API should just be the nuts and bolts of the crypto. I agree that keychains and the like seems like a can of worms. However something that we'll eventually will need in some form. I suggest that we punt on this feature for now and leave it for version 2. It can always be kept in the prototype using a 'moz' prefix. >>> Finally, this all should be on the crypto object, not on a new cipher >>> object. >> >> More and more people are saying that. > > Maybe you should listen to them? I absolutely agree that this needs to live on the 'crypto' property. Introducing new properties on the window object always carries big risks since it shares namespace with global variables. Hence introducing a new property can break pages that have no intention of using the property. This can be mitigated by making the property replaceable, but that only fixes half the problem so isn't really a solution. In this case we have the extremely rare luxury of having a property already existing which not lives where we want it to live (the window object), but also has a pretty good name. So the final implementation should definitely hang the new API off of this property. For prototyping purposes, it's easy to just call the property 'mozCrypto'. That'll let you use the same APIs that you already are to hook it up. / Jonas
[Bug 10794] [IndexedDB] Clarify createObjectStore/removeObjectStore's tie to the database setVersion was called on
http://www.w3.org/Bugs/Public/show_bug.cgi?id=10794 Eliot Graff changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #2 from Eliot Graff 2011-06-03 06:05:27 UTC --- Added the following sentences: ]] The createObjectStore method is tied to the instance of the database that setVersion was called on and can make changes to that database instance only. The deleteObjectStore method is tied to the instance of the database that setVersion was called on and can make changes to that database instance only. [[ to the following methods: IDBDatabase.createObjectStore IDBDatabase.deleteObjectStore IDBDatabaseSync.createObjectStore IDBDatabaseSync.deleteObjectStore -- 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: What changes to Web Messaging spec are proposed? [Was: Re: Using ArrayBuffer as payload for binary data to/from Web Workers]
On Thu, Jun 2, 2011 at 10:17 PM, Jonas Sicking wrote:
> On Thu, Jun 2, 2011 at 4:41 PM, David Levin wrote:
> >> None of the objects which allow transferring of ownership has children
> >> so this doesn't appear to be a problem at this time. If it indeed does
> >> turn into a problem, it would seem like a problem no matter what
> >> solution is used, no?
> >
> > Not if all objects are transferred.
>
> Define "all objects". Consider something like:
>
> a = { x: myArrayBuffer1, y: myArrayBuffer2 };
> worker.postMessage(a, { transfer: true });
>
> In this case the 'a' object is obviously not transferred. Or are you
> proposing that it'd be transferred too somehow?
>
Well the algorithm could empty 'a'. As far as what happens underneath the
covers that is up to the implementation. (I suspect most javascript engines
today wouldn't allow for actually transferring the memory cross thread.)
>
> > Here's a simple use case, suppose I create an array of arrays (a 2d
> array)
> > which contains ArrayBuffers.Now I want to transfer this as fast as
> possible
> > using postMessage.
> > What does my code look like for each of these apis?
>
> Your proposal:
> w.postMessage(my2darray, {transfer: true});
> vs.
> w.postMessage(my2darray, Array.concat.apply(Array, my2darray));
I thought this would be:
w.postMessage(my2darray, {transfer: Array.concat.apply(Array,
my2darray)});
> Now show me the code needed to send a message which contains one big
> buffer from you that you want to transfer, along with some data that
> you got from some other piece of code and which you do not want to
> modify and which may or may not contain ArrayBuffers.
>
Fair enough. Way more complicated for the "transfer: true" case. :)
The thing that seemed odd to me about this extra array is that it seemed to
make the code more complicated and harder to understand. However, I
understand that folks want to support involved scenarios.
*Let's go with the transfer list.* (I suspect that something like transfer:
true or transfer: "all" would still be possible in the future if it proved
desirable since bools/strings won't be valid there.)
dave
