Re: Directory Upload Proposal

I strongly support this proposal. However - if it is possible to upload a directly, it should also be possible to download it, including exporting it from the download / sandbox into the "real" world. I would also like to ask for an opinion on letting the developers choose how they actually want

Re: The futile war between Native and Web

I am not sure about that. Based on the premise that the browser itself doesn't leak data, I think it is possible to make a web site safe. In order to achieve that, we to make sure, that a) the (script) code doesn't misbehave (=CSP); b) the integrity of the (script) code is secured on the server

Re: The futile war between Native and Web

AM, Anders Rundgren wrote: > On 2015-02-16 16:54, Michaela Merz wrote: >> This discussion is (in part) superfluous. Because a lot of people and organizations are using the web even for the most secure applications. Heck - they even send confidential data via plain old e-mail - they would even us

Re: The futile war between Native and Web

This discussion is (in part) superfluous. Because a lot of people and organizations are using the web even for the most secure applications. Heck - they even send confidential data via plain old e-mail - they would even use AOL if that would still be possible - in other words: Most simply don't car

Re: [clipboard] Feature detect Clipboard API support?

AFAIK, you can't trigger a clip board request without human interaction. $('#element).off().on('click',function(e) { var clip = new ClipboardEvent('copy'); clip.clipboardData.setData('text/plain','some data'); clip.preventDefault(); e.target.dispatchEvent(clip); }); This

Re: do not deprecate synchronous XMLHttpRequest

That is good news indeed. And I am glad to help. m. On 02/10/2015 03:02 PM, Jonas Sicking wrote: > On Tue, Feb 10, 2015 at 12:43 PM, Michaela Merz > wrote: >> Blobs are immutable but it would be cool to have blob 'pipes' or >> FIFOs allowing us to stream from tho

Re: do not deprecate synchronous XMLHttpRequest

At least Microsoft didn't put a backdoor in Windows that can divulge > your local IP (within a LAN) to the outside world. They call it WebRTC. > If you want something to complain about there are far more troubling > things than the well intended effort to rid the web of

Re: do not deprecate synchronous XMLHttpRequest

Interesting notion. Thanks for sharing. Reminds me on the days when Microsoft was trying to tell me what's good and what's not good. m. On 02/10/2015 12:10 PM, Florian Bösch wrote: > On Tue, Feb 10, 2015 at 4:24 PM, Glenn Adams > wrote: > > Morality should not be leg

Re: do not deprecate synchronous XMLHttpRequest

in a while loop and don't exit > the loop till it has finished. > > Easier than writing charged emails. Less drain on the soul. > > Sent from my iPhone > >> On Feb 10, 2015, at 8:48 AM, Michaela Merz >> wrote: >> >> No argument in regard to the p

Re: do not deprecate synchronous XMLHttpRequest

No argument in regard to the problems that might arise from using sync calls. But it is IMHO not the job of the browser developers to decide who can use what, when and why. It is up the guys (or gals) coding a web site to select an appropriate AJAX call to get the job done. Once again: Please rem

Re: Violation of mail list policy [Was: Fwd: Re: do not deprecate synchronous XMLHttpRequest]

I do apologize for the unfortunate selection of some words in this posting. It was not my intention to attack, to insult or to offend anybody. Michaela On 02/09/2015 12:53 PM, Arthur Barstow wrote: > Michaela, > > Some of the language you used in [1] is offensive. Per the group's mail list etiq

Re: do not deprecate synchronous XMLHttpRequest

nous calls, that's his prerogative. m. On 02/06/2015 12:50 PM, Florian Bösch wrote: > On Fri, Feb 6, 2015 at 7:38 PM, Michaela Merz mailto:michaela.m...@hermetos.com>> wrote: > > it would be the job of the browser development community to find a way to make such calls

Re: do not deprecate synchronous XMLHttpRequest

sibilities to export and store arbitrary blobs of data into the file system (eg. createObjectURL for any kind of data). Thanks. m. On 02/06/2015 12:30 PM, Ryosuke Niwa wrote: > >> On Feb 6, 2015, at 9:27 AM, Michaela Merz wrote: >> >> Well .. may be some folks should ta

Re: do not deprecate synchronous XMLHttpRequest

comes back, and I'm not why we'd want to block > everything until it does. It sounds unreasonable. There are legitimate > scenarios for blocking the event loop but not when it comes to > fetching data from a server. > > > > > > On Fri, Feb 6, 2015 at 9:27 AM, Mi

Re: do not deprecate synchronous XMLHttpRequest

Well .. may be some folks should take a deep breath and think what they are doing. I am 'just' coding web services and too often I find myself asking: Why did the guys think that this would make sense? Indexeddb is such a case. It might be a clever design, but it's horrible from a coders perspecti

Re: do not deprecate synchronous XMLHttpRequest

I second Gregg's suggestion. It should be up to the developer to decide whether he wants to block or not. On 02/05/2015 08:58 PM, Gregg Tracton wrote: > I disagree with deprecating synchronous XMLHttpRequest: > > 1) it is not upward compatible & so can break numerous sites. > Many websites do no

Re: Security use cases for packaging

Pardon my french, but the whole idea is ridiculous. Web development is fluid and flexible. While I most certainly understand the idea and the need for secured loadable code (AFAIK I brought up this issue about 2 months ago), packaging and complicated signing is counter productive. What about exter

Re: What I am missing

that secrets can be scoped to content with a way to allow nesting without inheritance. This can be kludged on top of iframes, but only at the cost of a lot of engineering effort. On Wed, Nov 19, 2014 at 10:27 AM, Michaela Merz wrote: I don't disagree. But what is wrong with the notion of i

Re: What I am missing

How would an unsigned script be able to exploit functionality from a signed script if it's an either/or case - you have either all scripts signed or no extended features? and: Think about this: a website can be totally safe today and deliver exploits tomorrow without the user even noticing. It

Re: What I am missing

09:41 AM, Anne van Kesteren wrote: On Wed, Nov 19, 2014 at 4:27 PM, Michaela Merz wrote: I don't disagree. But what is wrong with the notion of introducing an _additional_ layer of certification? Adding an additional layer of centralization.

Re: What I am missing

better and more open, transparent and in sync with the spirit of open web to give the control to end user and not making them to relax today on behalf of other signing authorities. On 19-Nov-2014 8:44 pm, "Michaela Merz" <mailto:michaela.m...@hermetos.com>> wrote: Y

Re: What I am missing

09:09 AM, Pradeep Kumar wrote: Even today, browsers ask for permission for geolocation, local storage, camera etc... How it is different from current scenario? On 19-Nov-2014 8:35 pm, "Michaela Merz" <mailto:michaela.m...@hermetos.com>> wrote: That is relevant and a

Re: What I am missing

prohibited. Michaela On 11/19/2014 12:01 AM, Jeffrey Walton wrote: 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.

Re: What I am missing

I am not sure if I understand your question. Browsers can't be code servers at least not today. Michaela On 11/19/2014 08:43 AM, Pradeep Kumar wrote: How the browsers can be code servers? Could you please explain a little more... On 19-Nov-2014 7:51 pm, "Mic

Re: What I am missing

Perfect is the enemy of good. I understand the principles and problems of cryptography. And in the same way we rely on TLS and its security model today we would be able to put some trust into the same architecture for signing script. FYI: Here's how signing works for java applets: You need to get

Re: What I am missing

ative operating system on top of an operating system. Michaela On 11/19/2014 08:33 AM, Jonas Sicking wrote: > 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

Re: What I am missing

ion. You're saying I could with what's available today? Michaela On 11/19/2014 06:34 AM, Florian Bösch wrote: > On Wed, Nov 19, 2014 at 4:26 AM, Michaela Merz > mailto:michaela.m...@hermetos.com>> wrote: > > First: We need signed script code. We are doing a lot

Re: What I am missing

; and that is one of the hardest things to guarantee. > > > On Tue, Nov 18, 2014 at 8:00 PM, Michaela Merz > mailto:michaela.m...@hermetos.com>> wrote: > > > Yes Boris - I know. As long as it doesn't have advantages for the user > or the developer -

Re: What I am missing

n and therefore would help in environments where trust and/or security is important. We use script for much, much more than we did just a year or so ago. Michaela On 11/19/2014 04:40 AM, Boris Zbarsky wrote: > On 11/18/14, 10:26 PM, Michaela Merz wrote: >> First: We need signed script code

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: ZIP archive API?

I second that. Thanks Florian. On 05/03/2013 02:52 PM, Florian Bösch wrote: > I'm interested a JS API that does the following: > > Unpacking: > - Receive an archive from a Dataurl, Blob, URL object, File (as in > filesystem API) or Arraybuffer > - List its content and metadata > - Unpack member