https://www.w3.org/Bugs/Public/show_bug.cgi?id=27366
Bug ID: 27366
Summary: Define how shadow DOM should be handled when host is
adopted to a new document
Product: WebAppsWG
Version: unspecified
Hardware: PC
Thank you Jonas. I was actually thinking about the security model of
FirefoxOS or Android apps. We write powerful webapps nowadays. And
with webapps I mean regular web pages with a lot of script/html5
functionality. The browsers are fast enough to do a variety of things:
from running a linux
On 11/7/14 10:28 AM, Arthur Barstow wrote:
During WebApps' October 27 meeting, the participants agreed to stop
work on the UI Events spec and to publish it as a WG Note (see
[Mins]). As such, this is a formal Call for Consensus (CfC) to:
a) Stop work on this spec
b) Publish a gutted WG Note
On Wed, Nov 19, 2014 at 3:20 PM, Arthur Barstow art.bars...@gmail.com wrote:
Although there appears to be agreement that work on the [uievents] spec
should stop, the various replies raise sufficient questions that I consider
this CfC (as written) as failed.
Travis, Gary - would you please
On 11/19/14 9:35 AM, Anne van Kesteren wrote:
On Wed, Nov 19, 2014 at 3:20 PM, Arthur Barstow art.bars...@gmail.com wrote:
Although there appears to be agreement that work on the [uievents] spec
should stop, the various replies raise sufficient questions that I consider
this CfC (as written) as
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...@hermetos.com wrote:
Thank you Jonas. I was actually thinking about the security model of
FirefoxOS or Android apps. We write powerful webapps nowadays. And
with
+1
On 19-Nov-2014 8:07 pm, Anne van Kesteren ann...@annevk.nl wrote:
On Wed, Nov 19, 2014 at 3:20 PM, Arthur Barstow art.bars...@gmail.com
wrote:
Although there appears to be agreement that work on the [uievents] spec
should stop, the various replies raise sufficient questions that I
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
That is relevant and also not so. Because Java applets silently grant
access to a out of sandbox functionality if signed. This is not what I
am proposing. I am suggesting a model in which the sandbox model remains
intact and users need to explicitly agree to access that would otherwise
be
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 michaela.m...@hermetos.com wrote:
That is relevant and also not so. Because Java applets silently grant
access to a out of
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.
--
https://annevankesteren.nl/
First: You don't have to sign your code. Second: We rely on
centralization for TLS as well. Third: Third-party verification can be
done within the community itself
(https://www.eff.org/deeplinks/2014/11/certificate-authority-encrypt-entire-web)
.
Michaela
On 11/19/2014 09:41 AM, Anne van
Browser signature checking gives you nothing that CSP doesn't as far
as the security of pages composed from a mixture of content from
different providers.
As Florian points out, signing only establishes provenance, not any
interesting security properties.
I can always write a page that runs an
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't establish any trust, or security.
Yup, that's
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
Yes - it establishes provenance and protects against unauthorized
manipulation. CSP is only as good as the content it protects. If the
content has been manipulated server side - e.g. by unauthorized access -
CSP is worthless.
Michaela
On 11/19/2014 10:03 AM, ☻Mike Samuel wrote:
Browser
17 matches
Mail list logo
