Hey Adam,
I thought it might make sense to let the user specify a private key file
(e.g. an RSA-key) that is in the browsers KeyChain.
Would that make sense to have it implemented in the DOMCryptAPI?
Otherwise I can't see many use cases, because I think encryption on a high
OSI layer just
My sense is that the Mozilla folks want to start with the simple
building blocks first and then work up to more complicated things like
interacting with OS key stores and smart card readers.
DOMCrypt is also useful for protecting data at rest, which isn't
something you can do with TLS. For
Well, I think that makes sense... But not for me. I have the opinion that
cloud-hosted keys aren't keys anymore - right?
I mean, man-in-the-middle attacks are the 100% use case when it comes to
encryption due to buggy DNS-protocol that can't be updated.
I also think that this is kinda
These sorts of questions are probably better discussed on the whatwg
mailing list (where there is currently a thread about DOMCrypt)
because they're general questions about the use cases and features set
of the API and not about WebKit's implementation (or
non-implementation) of the API.
Thanks
Hello,
Just a small heads up on the multimedia support for the Qt port. At
the last webkit summit I've heard some Google folks a bit confused
about our multimedia story and I'm sure others are so here is the
story :
We had a first Phonon backend, abandoned and really far from feature
completion
I think we should let the spec mature a bit before diving in.
-Sam
On Jul 26, 2011, at 10:53 PM, Adam Barth wrote:
Hi webkit-dev,
As some of you are probably aware, Mozilla is experimenting with
exposing some basic cryptographic primitives to web applications:
-- Forwarded message --
From: Ryosuke Niwa ryosuke.n...@gmail.com
Date: Jul 27, 2011 10:32 AM
Subject: Re: [New DOM property] selectionDirection on HTMLInputElement and
HTMLTextAreaElement
To: Ryosuke Niwa rn...@webkit.org
Cc: Aryeh Gregor simetrical+...@gmail.com, WebKit
Hi,
When the Timer is fired for SMILTimeContainer to update animations, the
elapsed time is calculated based on the client's currentTime().
That elapsed time is passed into updateAnimations and is used most of the
way down.
In some cases during the update though, SMILTimeContainer::elapsed() is
On Jul 27, 2011, at 11:14 AM, Scott Graham wrote:
Hi,
When the Timer is fired for SMILTimeContainer to update animations, the
elapsed time is calculated based on the client's currentTime().
That elapsed time is passed into updateAnimations and is used most of the way
down.
In some
On Wed, Jul 27, 2011 at 12:15 PM, Simon Fraser simon.fra...@apple.comwrote:
On Jul 27, 2011, at 11:14 AM, Scott Graham wrote:
Does anyone disagree that all updates should use the same elapsed time
during the update? Or, in other words, is there any reason to re-get the
current wallclock time
Perhaps related to this thread, shouldn't we be basing SVG animations off of
the same animation scheduler that drives requestAnimationFrame and soon CSS
animations (https://bugs.webkit.org/show_bug.cgi?id=64591)? It seems less
than ideal to use a Timer.
-Darin
On Wed, Jul 27, 2011 at 11:14 AM,
11 matches
Mail list logo
