On Fri 2015-01-30 01:50:43 -0500, Yan Zhu wrote:
Say that resource Y is a javascript file that listens for users typing
in password fields and shows them a warning if the password is
weak. The user verifies and loads the HTML page that includes Y but an
attacker then blocks the request to
On Thu, Jan 29, 2015 at 10:50 PM, Yan Zhu y...@yahoo-inc.com wrote:
Say that resource Y is a javascript file that listens for users typing in
password fields and shows them a warning if the password is weak. The user
verifies and loads the HTML page that includes Y but an attacker then
chris palmer wrote:
But other code from the same origin might not be signed, which could
break the security assertion of code signing.
Maybe the code from the downloaded package has to be run from a local origin
like chrome://*.
Paging (future Dr.) Deian Stefan to the ER...
Any thoughts on using COWL for this kind of thing, with a pinned crypto key
as a confinement label to be combined with the regular Origin label?
-Brad
On Thu Jan 29 2015 at 1:43:05 PM Yan Zhu y...@yahoo-inc.com wrote:
chris palmer wrote:
But
But other code from the same origin might not be signed, which could
break the security assertion of code signing.
The unit of signing should be the same as the unit of isolation, i.e.
the origin. Or, the origin should be expanded to include a 4th
element, the signing key(s). I don't know how to
Maybe the code from the downloaded package has to be run from a local origin
like chrome://*.
Doesn't the same issue that Chris raised still exist? You need a unit
of isolation that says only code signed with this public key runs in
this isolation compartment. Chrome extensions have that
Brad Hill hillb...@gmail.com writes:
Paging (future Dr.) Deian Stefan to the ER...
Any thoughts on using COWL for this kind of thing, with a pinned crypto key
as a confinement label to be combined with the regular Origin label?
Thanks for paging me! I've thought about something like
devdatta wrote:
Maybe the code from the downloaded package has to be run from a local origin
like chrome://*.
Doesn't the same issue that Chris raised still exist? You need a unit
of isolation that says only code signed with this public key runs in
this isolation compartment. Chrome
Would it be possible to meet the security goals without assuming that the
response body is part of the package? See [1] for background on why that's
beneficial.. at least for performance side of the story. I'm picturing a
package description where each resource has a SRI token, plus a signature
to
On Thu 2015-01-29 20:14:59 -0500, Yan Zhu wrote:
A signed manifest-like package description that lists the hash and
location of every resource seems fine as long as all the resources are
downloaded and verified before running the app. Perhaps this kills
some of the performance benefits
packaging and complicated signing is routine for most installable web apps
and browser extensions; see
https://developer.mozilla.org/en-US/docs/Signing_a_XPI for instance. Developers
who build those might actually want the process to be less complicated.
Given that the packaging spec lists
On Thursday, January 29, 2015 6:25 PM, Daniel Kahn Gillmor
d...@fifthhorseman.net wrote:
On Thu 2015-01-29 20:14:59 -0500, Yan Zhu wrote:
A signed manifest-like package description that lists the hash and
location of every resource seems fine as long as all the resources are
downloaded and
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
13 matches
Mail list logo
