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 members to
, 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
http://www-archive.mozilla.org/projects/security/components/signed-scripts.html.
In practice
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
michaela.m...@hermetos.com mailto:michaela.m...@hermetos.com wrote:
First: We need signed script code. We are doing a lot of stuff with
script
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 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
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
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, Michaela Merz michaela.m
be prohibited.
Michaela
On 11/19/2014 12:01 AM, Jeffrey Walton wrote:
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
Kesteren wrote:
On Wed, Nov 19, 2014 at 4:27 PM, Michaela Merz
michaela.m...@hermetos.com 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.
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
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
michaela.m...@hermetos.com wrote:
I don't disagree. But what is wrong
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
michaela.m...@hermetos.com wrote:
Well .. may be some folks should take a deep breath
, 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 michaela.m...@hermetos.com
mailto:michaela.m...@hermetos.com wrote:
it would be the job of the browser development community to find a
way to make such calls less
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 not
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
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, Michaela Merz
michaela.m...@hermetos.com mailto:michaela.m...@hermetos.com wrote:
Well .. may be some folks should take a deep
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);
});
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
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 michaela.m...@hermetos.com
wrote:
No argument in regard to the problems that might arise from using sync
calls
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 use AOL if that would
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
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
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
michaela.m...@hermetos.com wrote:
Blobs are immutable but it would be cool to have blob 'pipes' or
FIFOs allowing us to stream from those pipes
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
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
24 matches
Mail list logo
