On Tue, Nov 18, 2014 at 5:45 AM, Domenic Denicola d...@domenic.me wrote:
That would be very sad. There are many servers that will not accept chunked
upload (for example Amazon S3).
The only way I could imagine us doing this is by setting the
Content-Length header value through an option (not
From: annevankeste...@gmail.com [mailto:annevankeste...@gmail.com] On Behalf Of
Anne van Kesteren
The only way I could imagine us doing this is by setting the Content-Length
header value through an option (not through Headers) and by having the
browser enforce the specified length somehow.
On Tue, Nov 18, 2014 at 10:34 AM, Domenic Denicola d...@domenic.me wrote:
I still think we should just allow the developer full control over the
Content-Length header if they've taken full control over the contents of the
request body (by writing to its stream asynchronously and piecemeal).
How about padding the remaining bytes forcefully with e.g. 0x20 if the
WritableStream doesn't provide enough bytes to us?
Takeshi
On Tue, Nov 18, 2014 at 7:01 PM, Anne van Kesteren ann...@annevk.nl wrote:
On Tue, Nov 18, 2014 at 10:34 AM, Domenic Denicola d...@domenic.me wrote:
I still think
On Tue, Nov 18, 2014 at 12:50 PM, Takeshi Yoshino tyosh...@google.com wrote:
How about padding the remaining bytes forcefully with e.g. 0x20 if the
WritableStream doesn't provide enough bytes to us?
How would that work? At some point when the browser decides it wants
to terminate the fetch
On 10/29/14 9:54 PM, Sam Ruby wrote:
I am willing to help with this effort.
Thanks for this information [1] and sorry for the delayed reply.
Given URL is a joint deliverable between WebApps and TAG, perhaps it
would be helpful if you were a co-Editor. Are you interested in that role?
From: annevankeste...@gmail.com [mailto:annevankeste...@gmail.com] On Behalf Of
Anne van Kesteren
On Tue, Nov 18, 2014 at 12:50 PM, Takeshi Yoshino tyosh...@google.com wrote:
How about padding the remaining bytes forcefully with e.g. 0x20 if the
WritableStream doesn't provide enough bytes to
I think there are several different scenarios under consideration.
1. The author says Content-Length 100, writes 50 bytes, then closes the
stream.
Depends on what exactly closing the stream does:
(1) Closing the stream includes closing the the TCP connection = the
body of the HTTP message
On 11/7/14 11:46 AM, Arthur Barstow wrote:
this is a Call for Consensus to:
a) Publish a gutted WG Note of the spec (see [Draft-Note])
FYI, this WG Note has been published
http://www.w3.org/TR/2014/NOTE-XMLHttpRequest2-20141118/.
technical content (as WebApps did recently
with [e.g.])
d) gut the ED [ED] of all technical content (note: this hasn't been
done yet but I will do so if/when this CfC passes)
FYI, the WG Note was published
http://www.w3.org/TR/2014/NOTE-fullscreen-20141118/.
On 11/18/2014 09:51 AM, Arthur Barstow wrote:
On 10/29/14 9:54 PM, Sam Ruby wrote:
I am willing to help with this effort.
Thanks for this information [1] and sorry for the delayed reply.
Given URL is a joint deliverable between WebApps and TAG, perhaps it
would be helpful if you were a
On 11/18/14 3:02 PM, Sam Ruby wrote:
On 11/18/2014 09:51 AM, Arthur Barstow wrote:
Given URL is a joint deliverable between WebApps and TAG, perhaps it
would be helpful if you were a co-Editor. Are you interested in that
role?
Yes.
OK, PubStatus updated accordingly.
-Thanks, AB
On 11/18/2014 03:08 PM, Arthur Barstow wrote:
On 11/18/14 3:02 PM, Sam Ruby wrote:
On 11/18/2014 09:51 AM, Arthur Barstow wrote:
Given URL is a joint deliverable between WebApps and TAG, perhaps it
would be helpful if you were a co-Editor. Are you interested in that
role?
Yes.
OK,
https://www.w3.org/Bugs/Public/show_bug.cgi?id=24338
Arun a...@mozilla.com changed:
What|Removed |Added
Status|NEW |RESOLVED
On Sun, Nov 16, 2014 at 8:30 PM, Robert O'Callahan rob...@ocallahan.org
wrote:
On Sun, Nov 16, 2014 at 5:35 PM, Dimitri Glazkov dglaz...@google.com
wrote:
On Wed, Nov 12, 2014 at 8:44 PM, Robert O'Callahan rob...@ocallahan.org
wrote:
On Wed, Nov 12, 2014 at 12:36 PM, Dimitri Glazkov
https://www.w3.org/Bugs/Public/show_bug.cgi?id=25038
Hayato Ito hay...@chromium.org changed:
What|Removed |Added
Status|NEW |RESOLVED
https://www.w3.org/Bugs/Public/show_bug.cgi?id=25562
Hayato Ito hay...@chromium.org changed:
What|Removed |Added
Status|NEW |RESOLVED
Allowing this script to run may open you to all kinds of malicious attacks
by 3rd parties not associated with the party whom you're trusting.
If I give App XYZ super power to do anything, and XYZ gets
compromised/hacked then I'll be open to all sorts of attacks.
It's not an issue of party A
On Wed, Nov 19, 2014 at 4:26 AM, Michaela Merz michaela.m...@hermetos.com
wrote:
First: We need signed script code. We are doing a lot of stuff with
script - we could safely do even more, if we would be able to safely
deliver script that has some kind of a trust model.
TLS exists.
I am
Well .. it would be a all scripts signed or no script signed kind of
a deal. You can download malicious code everywhere - not only as
scripts. Signed code doesn't protect against malicious or bad code. It
only guarantees that the code is actually from the the certificate owner
.. and has not been
On Wed, Nov 19, 2014 at 5:00 AM, Michaela Merz michaela.m...@hermetos.com
wrote:
If signed code would allow
special features - like true fullscreen
https://developer.mozilla.org/en-US/docs/Web/Guide/API/DOM/Using_full_screen_mode
or direct file access
TLS doesn't protect you against code that has been altered server side -
without the signers consent. It would alert the user, if unsigned
updates would be made available.
Ajax downloads still require a download link (with the bloburl) to be
displayed requiring an additional click. User clicks
https://www.w3.org/Bugs/Public/show_bug.cgi?id=26815
Hayato Ito hay...@chromium.org changed:
What|Removed |Added
Status|NEW |RESOLVED
On Wed, Nov 19, 2014 at 12:35 AM, Michaela Merz
michaela.m...@hermetos.com wrote:
Well .. it would be a all scripts signed or no script signed kind of a
deal. You can download malicious code everywhere - not only as scripts.
Signed code doesn't protect against malicious or bad code. It only
Signed code doesn't protect against malicious or bad code. It only
guarantees that the code is actually from the the certificate owner
if I trust you and allow your signed script the permissions it asks for and
you can't guarantee that it would be used by some malicious 3rd party site
to hack
On Wed, Nov 19, 2014 at 6:35 AM, Michaela Merz michaela.m...@hermetos.com
wrote:
Well .. it would be a all scripts signed or no script signed kind of
a deal. You can download malicious code everywhere - not only as scripts.
Signed code doesn't protect against malicious or bad code. It only
There are some models that are a bit better than trust by royalty
(app-stores) and trust by hirarchy (TLS). One of them is trust flowing
along flow limited edges in a graph (as in Advogato). This model however
isn't free from fault, as when a highly trusted entity gets compromised,
there's no
So there is no way for an unsigned script to exploit security holes in a
signed script?
Funny you mention crypto currencies as an idea to get inspiration
from...Trust but verify is detached from that... a browser can monitor
what the signed scripts are doing and if it detects a potentially
On Wed, Nov 19, 2014 at 7:54 AM, Marc Fawzi marc.fa...@gmail.com wrote:
So there is no way for an unsigned script to exploit security holes in a
signed script?
Of course there's a way. But by the same token, there's a way a signed
script can exploit security holes in another signed script.
On Tue, Nov 18, 2014 at 7:40 PM, Boris Zbarsky bzbar...@mit.edu wrote:
On 11/18/14, 10:26 PM, Michaela Merz wrote:
First: We need signed script code.
For what it's worth, Gecko supported this for a while. See
http://www-archive.mozilla.org/projects/security/components/signed-scripts.html.
On Tue, Nov 18, 2014 at 9:38 PM, Florian Bösch pya...@gmail.com wrote:
or direct file access
http://www.html5rocks.com/en/tutorials/file/filesystem/
This is no more direct file access than IndexedDB is. IndexedDB also
allow you to store File objects, but also doesn't allow you to access
things
31 matches
Mail list logo
