Re: What I am missing

It gives you at least a sandboxed file system, which is about all you can offer without a central authority to make infallible decisions, decisions you'd pay for to get. On Wed, Nov 19, 2014 at 8:35 AM, Jonas Sicking wrote: > On Tue, Nov 18, 2014 at 9:38 PM, Florian Bösch wrote: > >> or direct

Re: What I am missing

On Tue, Nov 18, 2014 at 9:38 PM, Florian Bösch 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 like your

Re: What I am missing

On Tue, Nov 18, 2014 at 7:40 PM, Boris Zbarsky 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 > . > In pra

Re: What I am missing

On Wed, Nov 19, 2014 at 7:54 AM, Marc Fawzi 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. Signing itself doesn

Re: What I am missing

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 malic

Re: What I am missing

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 quick

Re: What I am missing

On Wed, Nov 19, 2014 at 6:35 AM, Michaela Merz 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 > guarantees that the

Re: What I am missing

<< 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 hac

Re: What I am missing

On Wed, Nov 19, 2014 at 12:35 AM, Michaela Merz 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 > guarantees that the c

[Bug 26815] [Shadow]:

https://www.w3.org/Bugs/Public/show_bug.cgi?id=26815 Hayato Ito changed: What|Removed |Added Status|NEW |RESOLVED Resolution|---

Re: What I am missing

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 do

Re: What I am missing

On Wed, Nov 19, 2014 at 5:00 AM, Michaela Merz 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 http://www.html5rocks.com/en/tutorials/file/filesystem/

Re: What I am missing

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 be

Re: What I am missing

On Wed, Nov 19, 2014 at 4:26 AM, Michaela Merz 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 thinking about > signed JA

Re: What I am missing

"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 tru

[Bug 25562] [Shadow]: Inert HTML elements normative text is not focused enough

https://www.w3.org/Bugs/Public/show_bug.cgi?id=25562 Hayato Ito changed: What|Removed |Added Status|NEW |RESOLVED CC|

[Bug 25038] [Shadow]: Non-normative text about selection should be removed

https://www.w3.org/Bugs/Public/show_bug.cgi?id=25038 Hayato Ito changed: What|Removed |Added Status|NEW |RESOLVED CC|

Re: What I am missing

Yes Boris - I know. As long as it doesn't have advantages for the user or the developer - why bother with it? If signed code would allow special features - like true fullscreen or direct file access - it would make sense. Signed code would make script much more resistant to manipulation and there

Re: What I am missing

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 . In practice, people didn't really use it, and it made the security mo

What I am missing

Hi there: Though I am not part of the browser developing community, I am doing web development since before the days of Marc Andreessen - when we had neither script or even text flowing around images. So you may understand how much I I enjoy what you are doing and that I can't wait for new functi

Re: Bringing APIs for experimental hardware/software to the Web

On Sun, Nov 16, 2014 at 8:30 PM, Robert O'Callahan wrote: > On Sun, Nov 16, 2014 at 5:35 PM, Dimitri Glazkov > wrote: > >> On Wed, Nov 12, 2014 at 8:44 PM, Robert O'Callahan >> wrote: >> >>> On Wed, Nov 12, 2014 at 12:36 PM, Dimitri Glazkov >>> wrote: >>> Nevertheless, I am optimistic. I

[Bug 24338] Spec should have Fetch for Blob URLs

https://www.w3.org/Bugs/Public/show_bug.cgi?id=24338 Arun changed: What|Removed |Added Status|NEW |RESOLVED Resolution|---

Re: PSA: Sam Ruby is co-Editor of URL spec

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, PubStatus

PSA: Sam Ruby is co-Editor of URL spec

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

Re: [url] follow-ups from the TPAC F2F Meeting

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 co-Edi

Re: CfC: publish a WG Note of Fullscreen; deadline November 14

WG Note of all 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/>.

Re: CfC: publish WG Note of XHR Level 2; deadline November 14

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/>.

Re: =[xhr]

> 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 me

RE: =[xhr]

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 wrote: >> How about padding the remaining bytes forcefully with e.g. 0x20 if the >> WritableStream doesn't provide enough bytes to us? > > How wo

IndieUI Teleconference Agenda; 19 November at 22:00Z for 60 minutes

Cross-posting as is now usual ... What: IndieUI Task Force Teleconference When: Wednesday 19 November 2:00 PMSan Francisco -- U.S. Pacific Time (PST: UTC -8) 4:00 PMAustin -- U.S. Central Time(CST: UTC -6) 5:00 PMBoston -- U

Re: [url] follow-ups from the TPAC F2F Meeting

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 co-Edi

[Bug 27359] New: [Shadow]: Need to define interaction with directionality

https://www.w3.org/Bugs/Public/show_bug.cgi?id=27359 Bug ID: 27359 Summary: [Shadow]: Need to define interaction with directionality Product: WebAppsWG Version: unspecified Hardware: PC OS: All S

Re: [url] follow-ups from the TPAC F2F Meeting

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? Regard

Re: =[xhr]

On Tue, Nov 18, 2014 at 12:50 PM, Takeshi Yoshino 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 (e.g. due to timeout,

Re: =[xhr]

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 wrote: > On Tue, Nov 18, 2014 at 10:34 AM, Domenic Denicola wrote: > > I still think we should just allow the dev

Re: =[xhr]

On Tue, Nov 18, 2014 at 10:34 AM, Domenic Denicola 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). It > gives no

RE: =[xhr]

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

Re: =[xhr]

On Tue, Nov 18, 2014 at 5:45 AM, Domenic Denicola 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 through Headers