On Thu, Jan 29, 2015 at 10:50 PM, 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
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 f
On Thursday, January 29, 2015 6:25 PM, Daniel Kahn Gillmor
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 verified before
"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 i
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
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 moti
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". C
Brad Hill 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 this---providing
som
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
> 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 mo
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 wrote:
> chris palmer wrote:
>
> > But other code from t
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://*.
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 a
Hi all, looking over the W3C TAG packaging draft [1], I would like to see
security through package signing as a use case for packaging.
A hypothetical scenario using Google/Yahoo's End to End email encryption
project:
1. User goes to https://cryptomail.yahoo.com/app.pack for the first time. The
14 matches
Mail list logo