Re: [FileAPI] Blob.URN?
On Wed, Mar 31, 2010 at 3:01 PM, Eric Uhrhane wrote: > On Wed, Mar 31, 2010 at 2:40 PM, Jonas Sicking wrote: >> On Wed, Mar 31, 2010 at 1:55 AM, Robin Berjon wrote: >>> On Mar 31, 2010, at 01:56 , Darin Fisher wrote: The only way to get a FileWriter at the moment is from >>> type="saveas">. What is desired is a way to simulate the load of a resource with Content-Disposition: attachment that would trigger the browser's download manager. >>> >>> I don't think that is a good solution for this, for one >>> it falls back to a text input control, which is less than ideal. I think >>> that the File Writer should trigger downloads on an API call since that >>> doesn't introduce security issues that aren't already there. I'll make a >>> proposal for that. >> >> Why not simply allow FileWriters be instantiated using: >> >> x = new FileWriter; >> >> And then make every call to .write open up the save as dialog. > > You wouldn't want to prompt on every write; developers might want to > append a chunk at a time. > You could prompt on creation, if you didn't mind that being a synchronous > call. > > The reason I made an html element be the way of getting a FileWriter > was to make the normal usage pattern not involve modal dialogs popping > up in front of the user unprompted. With an inpput control, they can > choose when to interact with it, rather than having a speedbump shoved > in front of them. So we could allow FileWriter to be created directly in addition to using . When instantiated directly any call to .write will bring up a save-as dialog. This is useful for the cases where Darin and others wanted to use content-disposition to bring up the save-as dialog. On a separate note, I have no idea how to create UI that makes the user understand what they grant when selecting a file destination using . I.e. that they are granting the web page continuous writing (but not reading?) capabilities to the specific file location. / Jonas
Re: [FileAPI] Blob.URN?
On Wed, Mar 31, 2010 at 2:40 PM, Jonas Sicking wrote: > On Wed, Mar 31, 2010 at 1:55 AM, Robin Berjon wrote: >> On Mar 31, 2010, at 01:56 , Darin Fisher wrote: >>> The only way to get a FileWriter at the moment is from >> type="saveas">. What is desired is a way to simulate the load of a >>> resource with Content-Disposition: attachment that would trigger the >>> browser's download manager. >> >> I don't think that is a good solution for this, for one >> it falls back to a text input control, which is less than ideal. I think >> that the File Writer should trigger downloads on an API call since that >> doesn't introduce security issues that aren't already there. I'll make a >> proposal for that. > > Why not simply allow FileWriters be instantiated using: > > x = new FileWriter; > > And then make every call to .write open up the save as dialog. You wouldn't want to prompt on every write; developers might want to append a chunk at a time. You could prompt on creation, if you didn't mind that being a synchronous call. The reason I made an html element be the way of getting a FileWriter was to make the normal usage pattern not involve modal dialogs popping up in front of the user unprompted. With an inpput control, they can choose when to interact with it, rather than having a speedbump shoved in front of them.
Re: [FileAPI] Blob.URN?
On Wed, Mar 31, 2010 at 1:55 AM, Robin Berjon wrote: > On Mar 31, 2010, at 01:56 , Darin Fisher wrote: >> The only way to get a FileWriter at the moment is from > type="saveas">. What is desired is a way to simulate the load of a resource >> with Content-Disposition: attachment that would trigger the browser's >> download manager. > > I don't think that is a good solution for this, for one > it falls back to a text input control, which is less than ideal. I think that > the File Writer should trigger downloads on an API call since that doesn't > introduce security issues that aren't already there. I'll make a proposal for > that. Why not simply allow FileWriters be instantiated using: x = new FileWriter; And then make every call to .write open up the save as dialog. / Jonas
Re: [IndexedDB] Exceptions on IndexedDatabaseRequest.open
On 3/31/2010 6:42 AM, Jeremy Orlow wrote: I don't see any reason to special case this one method with synchronous properties. "If the name parameter is not valid" or any other error, I think it should be returned via an error callback just like everywhere else. I agree. Cheers, Shawn smime.p7s Description: S/MIME Cryptographic Signature
Re: [FileAPI] Blob.URN?
On Mar 31, 2010, at 16:58 , Tab Atkins Jr. wrote: > On Wed, Mar 31, 2010 at 1:55 AM, Robin Berjon wrote: >> On Mar 31, 2010, at 01:56 , Darin Fisher wrote: >>> The only way to get a FileWriter at the moment is from >> type="saveas">. What is desired is a way to simulate the load of a >>> resource with Content-Disposition: attachment that would trigger the >>> browser's download manager. >> >> I don't think that is a good solution for this, for one >> it falls back to a text input control, which is less than ideal. I think >> that the File Writer should trigger downloads on an API call since that >> doesn't introduce security issues that aren't already there. I'll make a >> proposal for that. > > Better fallback could be achieved with . Well, that gives you a button that does nothing. It's better in the same sense that if you want to get to the moon, a car is better than a kick scooter. You can already redirect to malicious.exe. You can also already build malicious.zip directly in script and prompt for download (like http://jszip.stuartk.co.uk/ does). A saveAs() method that works through the download UI changes nothing security-wise, unless I'm missing something. I'm going to flag the entry point issue in the draft, and DAP has decided to release a FPWD of it (because most of it is still very useful to look at separately from this issue). -- Robin Berjon - http://berjon.com/
Re: [FileAPI] Blob.URN?
On Wed, Mar 31, 2010 at 1:55 AM, Robin Berjon wrote: > On Mar 31, 2010, at 01:56 , Darin Fisher wrote: >> The only way to get a FileWriter at the moment is from > type="saveas">. What is desired is a way to simulate the load of a resource >> with Content-Disposition: attachment that would trigger the browser's >> download manager. > > I don't think that is a good solution for this, for one > it falls back to a text input control, which is less than ideal. I think that > the File Writer should trigger downloads on an API call since that doesn't > introduce security issues that aren't already there. I'll make a proposal for > that. Better fallback could be achieved with . ~TJ
[IndexedDB] Exceptions on IndexedDatabaseRequest.open
What is the purpose of allowing IndexedDatabaseRequest ( http://dev.w3.org/2006/webapi/WebSimpleDB/#idl-def-IndexedDatabaseRequest) to raise an exception? The only mention of it in the spec is that it raises a NON_TRANSIENT_ERR "if the name parameter is not valid". But it's not mentioned in http://dev.w3.org/2006/webapi/WebSimpleDB/#dfn-steps-for-opening-a-database or anywhere else as far as I can tell. I don't see any reason to special case this one method with synchronous properties. "If the name parameter is not valid" or any other error, I think it should be returned via an error callback just like everywhere else. J
Re: Widget Signature Issue and Proposed Resolution
Based on some feedback I have a revision to the Normative change (same
intent) and also a clarification that might be helpful:
(A) Revised Proposal
Disallow all Transforms except for a single canonicalization
transform that is required for every ds:Reference that needs XML
content canonicalization.
Specifically, this would result in the following changes to the
Widget Signature specification [1]:
(1) Normative change:
(a) Section 7.1 Common Constraints for Signature Generation and
Validation
Change 3c from "The ds:Reference MUST NOT have any ds:Transform
elements." to
A ds:Reference to any XML content MUST have a ds:Transform element
child that specifies the canonicalization method.
Canonical XML 1.1 MUST be specified as the Canonicalization Algorithm
for this transform.
Sectjon 7.2, add
Every ds:Reference to XML content MUST have exactly one ds:Transform
element to specify the canonicalization method. Canonical XML 1.1 MUST
be specified as the Canonicalization Algorithm.
Note that this specifically means that a ds:Reference to the ds:Object
element and the ds:Reference to config.xml will each require a
ds:Transform element to specify canonicalization method.
Section 7.3, add after the third paragraph ("If a ds:KeyInfo element
is present") the following new paragraph:
When validating a Widget Signature, a validator MUST be able to
process a ds:Reference that has a ds:Transform specifying the
canonicalization method. The validator MUST be able to process a
ds:Reference that specifies Canonical XML 1.1 as a canonicalization
method. The validator SHOULD also be able to process XML content with
a ds:Reference that does not include a ds:Transform by using the
default Canonical XML 1.0 canonicalization method.
(2) Non-normative change:
1.4 Example, (formatting appropriately and renumbering lines)
Change
to
http://www.w3.org/2006/12/xml-
c14n11"/>
Change
to
http://www.w3.org/2006/12/xml-
c14n11"/>
--
(B) Clarificationn
There are two different places in XML Signature where XML
canonicalization applies, hence leading to possible confusion.
First, there is the canonicalization of SignedInfo. This is
determined by the CanonicalizationMethod of SignedInfo. This only
applies to the canonicalization of SignedInfo itself, however
http://www.w3.org/2008/xmlsec/Drafts/xmldsig-core-11/Overview.htm#sec-CanonicalizationMethod
Second, there is the canonicalization of XML referenced using a
ds:Reference, for example both the ds:Object element and the
config.xml in the Widget Signature case.
In each case the content obtained from the URI for the ds:Reference
requires canonicalization unless already an octet stream, so by
default canonicalization is used to convert the XML to an octet
stream. If no transform is specified, then the default 1.0
canonicalization algorithm is used. This has two problems - it isn't
obvious that canonicalization was done at all and this might become
an interop problem, and Canonical XML 1.0 is used instead of 1.1
(that fixes known issues with xml:id). By putting an explicit
Transform within each ds:Reference element it makes this all clear.
There is no mechanism in XML Signature to specify how all ds:Reference
elements to XML are to be canonicalized - it is specified individually
for each Reference, and in XML Signature 1.1 and earlier this is done
by specifying a transform, as noted in this example 2.1 from XML
Signature 1.1:
[s05] http://www.w3.org/TR/2000/REC-xhtml1-2126/";>
[s06]
[s07] http://www.w3.org/2006/12/xml-c14n11"/>
[s08]
[s09] http://www.w3.org/2001/04/
xmlenc#sha256"/>
[s10] dGhpcyBpcyBub3QgYSBzaWduYXR1cmUK...
[s11]
http://www.w3.org/2008/xmlsec/Drafts/xmldsig-core-11/Overview.htm#sec-o-Simple
regards, Frederick
Frederick Hirsch
Nokia
On Mar 29, 2010, at 4:16 PM, Hirsch Frederick (Nokia-CIC/Boston) wrote:
ISSUE: Widget Signature : Not specifying Canonicalization algorithm
explicitly
Detail: The current Widget Signature specification does not allow the
use of XML Signature Transforms, however the only means to explicitly
specify the Canonicalization method to use to use a transform (in
XML Signature 1.1 and earlier). Using the default may be
problematical if organizations are not able to confirm the default in
use, or because a different algorithm is required (for example with
an Id on ds:Object Canonical XML 1.1 should be used, but the default
is Canonical XML 1.0)
PROPOSAL:
Disallow all Transforms except for a single canonicalization
transform that is required for every ds:Reference that needs XML
content canonicalization.
Specifically, this would result in the following changes to the
Widget Signature specification [1]:
(1) Normative change:
Section 7.1 Common Constraints for Signature Generation and Validation
Change 3c from "The ds:Reference MUST NOT have any ds:Transform
elements." to
[widgets] Draft agenda for 1 April 2010 voice conf
Below is the draft agenda for the April 1 Widgets Voice Conference (VC).
Inputs and discussion before the VC on all of the agenda topics via
public-webapps is encouraged (as it can result in a shortened
meeting). Please address Open/Raised Issues and Open Actions before
the meeting:
http://www.w3.org/2008/webapps/track/products/8
Minutes from the last VC:
http://www.w3.org/2010/03/18-wam-minutes.html
-Regards, Art Barstow
Agenda:
1. Review and tweak agenda
2. Announcements
3. Packaging and Configuration spec
http://dev.w3.org/2006/waf/widgets/
a. and dir attr comments:
http://lists.w3.org/Archives/Public/public-webapps/2010JanMar/
0936.html
b. Next step
4. Digital Signature spec
http://dev.w3.org/2006/waf/widgets-digsig/
a. Canonical XML bug
http://lists.w3.org/Archives/Public/public-webapps/2010JanMar/
0953.html
5. Widget Interface spec
http://dev.w3.org/2006/waf/widgets-api/
a. Issue #116 - Need to flesh out the security considerations for the
openURL method in the Widget Interface spec
http://www.w3.org/2008/webapps/track/issues/116
b. Interop plans: who is going to participate?
http://dev.w3.org/2006/waf/widgets-api/imp-report/
6. Access Requests Policy (WARP) spec
http://dev.w3.org/2006/waf/widgets-access/
a. Test suite status
http://dev.w3.org/cvsweb/2006/waf/widgets-access/test-suite/
7. URI Scheme spec
http://dev.w3.org/cvsweb/2006/waf/widgets-uri/
a. ACTION-510
http://www.w3.org/2008/webapps/track/actions/510
8. View Modes Media Features spec:
http://dev.w3.org/2006/waf/widgets-vmmf/
Minutes from short discussion on March 18:
http://www.w3.org/2010/03/18-wam-minutes.html#item06
a. Comments from CSSWG:
http://lists.w3.org/Archives/Public/public-webapps/2010JanMar/
0804.html
b. Comments from Daniel Glazman:
http://lists.w3.org/Archives/Public/public-webapps/2010JanMar/
0800.html
c. Comments from Brad Kemper:
http://lists.w3.org/Archives/Public/public-webapps/2010JanMar/
0803.html
d. Height and width attribute (raised by Marcos):
http://lists.w3.org/Archives/Public/public-webapps/2010JanMar/
0847.html
9. View Modes Interfaces spec:
http://dev.w3.org/2006/waf/widgets-vm/vm-interfaces.src.html
a. Relationship between VM-I spec and CSSOM spec
VM-I: http://dev.w3.org/2006/waf/widgets-vm/vm-interfaces.src.html
CSSOM: http://dev.w3.org/csswg/cssom-view/
Thread: http://lists.w3.org/Archives/Public/public-webapps/
2010JanMar/0933.html
10. AOB
Logistics:
Time: 22:00 Tokyo; 16:00 Helsinki; 15:00 Paris; 14:00 London; 09:00
Boston; 06:00 Seattle
Duration: 90 minutes max
Zakim Bridge:+1.617.761.6200, +33.4.89.06.34.99 or +44.117.370.6152
PIN: 9231 ("WAF1");
IRC: channel = #wam; irc://irc.w3.org:6665 ; http://cgi.w3.org/
member-bin/irc/irc.cgi
Confidentiality of minutes: Public
Re: [FileAPI] Blob.URN?
On Mar 31, 2010, at 01:56 , Darin Fisher wrote: > The only way to get a FileWriter at the moment is from . > What is desired is a way to simulate the load of a resource with > Content-Disposition: attachment that would trigger the browser's download > manager. I don't think that is a good solution for this, for one it falls back to a text input control, which is less than ideal. I think that the File Writer should trigger downloads on an API call since that doesn't introduce security issues that aren't already there. I'll make a proposal for that. -- Robin Berjon - http://berjon.com/
