I won't be able to make the call, but I've left one comment inline:
On Tue, Mar 6, 2012 at 10:15 PM, ptheriault ptheria...@mozilla.com wrote:
Chris,
Below is a summary of threats and controls for further discussion.
Disclaimer: this is my understanding from various conversations, wiki pages,
On Mon, Mar 5, 2012 at 12:45 PM, Jim Straus jstr...@mozilla.com wrote:
Hello -
I definitely don't like the Android model. We'll have to figure out
exactly how to communicate permissions requests to users. On the other
hand, an appropriately vetted and signed app could be given permissions
DOMMutationEvents :)
Adam
On Tue, Feb 14, 2012 at 2:34 PM, Jesse Ruderman jruder...@gmail.com wrote:
What rarely-used web features are hurting security? What might we
remove if we had data on prevalence?
https://etherpad.mozilla.org/MeasuringBadThings
On Tue, Jul 26, 2011 at 5:19 PM, Daniel Veditz dved...@mozilla.com wrote:
On 7/22/11 7:18 PM, Eli Grey wrote:
CSP needs a way to support object URLs, of which the scheme is
implementation specific (e.g. moz-filedata:{GUID} in Firefox,
blob:{origin}{GUID} in WebKit). How might this be
On Wed, Jun 8, 2011 at 8:40 AM, Christopher Blizzard
blizz...@mozilla.com wrote:
On 6/7/2011 5:52 PM, Adam Barth wrote:
On Tue, Jun 7, 2011 at 5:43 PM, Brian Smithbsm...@mozilla.com wrote:
Adam Barth wrote:
On 5/31/2011 8:24 AM, Brian Smith wrote:
We have also discussed blocking https+ws
On Tue, Jun 7, 2011 at 5:43 PM, Brian Smith bsm...@mozilla.com wrote:
Adam Barth wrote:
On 5/31/2011 8:24 AM, Brian Smith wrote:
We have also discussed blocking https+ws:// content completely in
our
WebSockets implementation, so that all WebSockets on a HTTPS page
must be
wss
On Tue, May 31, 2011 at 10:25 AM, Christopher Blizzard
blizz...@mozilla.com wrote:
On 5/31/2011 8:24 AM, Brian Smith wrote:
We have also discussed blocking https+ws:// content completely in our
WebSockets implementation, so that all WebSockets on a HTTPS page must be
wss://. That way, we
[-dev-tech-crypto]
On Wed, May 18, 2011 at 6:17 AM, Jean-Marc Desperrier jmd...@gmail.com wrote:
Brian Smith wrote:
See https://twitter.com/#!/scarybeasts/status/69138114794360832:
Chrome 13 dev channel now blocks certain types of mixed content by
default (script, CSS, plug-ins). Let me know
On Wed, May 18, 2011 at 12:04 PM, Eddy Nigg eddy_n...@startcom.org wrote:
On 05/18/2011 09:45 PM, From Adam Barth:
We tried aggressively blocking active mixed content by default in the
Chrome Dev channel, but too much broke. We're going to unblock it
again and try to find some middle road
On Fri, Apr 8, 2011 at 4:02 PM, Jean-Marc Desperrier jmd...@free.fr wrote:
On 09/04/2011 00:52, Adam Barth wrote:
- CA locking functionality in HSTS or via CAA
There's significant interest in this feature from chrome-security
as well.
What about EV locking ?
How does a site change
On Sat, Apr 9, 2011 at 10:44 AM, Eddy Nigg eddy_n...@startcom.org wrote:
On 04/09/2011 01:52 AM, From Adam Barth:
There's significant interest in this feature from chrome-security
as well.
There is however a very limited benefit and would only prevent a particular
type of failure
On Fri, Apr 8, 2011 at 3:49 PM, Sid Stamm s...@mozilla.com wrote:
After the few meetings and a couple of hours of discussion in the last
two days, we've made a short list of desired upgrades for NSS/PSM for
the near term. This message should hopefully serve as a summary of the
technical bits
Another option is to store the report-uri information in the
well-known metadata store. Of course, that assumes that the attacker
doesn't control the well-known metadata store...
Adam
On Tue, Jun 8, 2010 at 3:10 PM, Brandon Sterne bste...@mozilla.com wrote:
Hello all,
I want to bring up an
On Sun, Jan 31, 2010 at 4:50 PM, Chris Hills c...@chaz6.com wrote:
On 31/01/2010 18:12, Timothy D. Morgan wrote:
That's handy, but doesn't that mean the website you're accessing will
still use cookies once you're authenticated?
Yes it does :/ But I think it's easier to get sites to implement
On Sat, Nov 28, 2009 at 11:51 PM, Kálmán „KAMI” Szalai
kami...@gmail.com wrote:
Adam Barth írta:
It's important to separate two concerns:
1) Malicious extensions
2) Honest extensions that have vulnerabilities (benign-but-buggy)
I agree that the malicious extension problem is somewhat
On Sun, Nov 29, 2009 at 10:19 AM, chris hofmann chofm...@meer.net wrote:
There is some early thinking about the Jetpack security model at
https://wiki.mozilla.org/Labs/Jetpack/JEP/29#Jetpack_Security_Model
This looks like a great start. A few things you might consider:
1) If the Jetpack is
On Sun, Nov 29, 2009 at 6:34 PM, Devdatta dev.akh...@gmail.com wrote:
3) One of the things we found in our study (which Adrienne has made
public at
http://www.eecs.berkeley.edu/Pubs/TechRpts/2009/EECS-2009-139.pdf)
is that many extensions use nsIFile to store extension-local
persistent
Jetpack is an opportunity to rethink the extension security model.
Ideally, an extension platform would make it easier for developers to
write secure extensions. I'm happy to discuss ideas with folks
off-list.
Adam
On Thu, Nov 26, 2009 at 10:01 AM, Ian G i...@iang.org wrote:
On 26/11/2009
Instead of arguing abstractly about design, I've written up a
(mostly!) complete spec for an alternative CSP design:
https://wiki.mozilla.org/Security/CSP/Strawman
I've purposely gone overboard on the directives, but most of these
directives are based on real feature requests I've received from
On Mon, Oct 26, 2009 at 6:11 PM, Daniel Veditz dved...@mozilla.com wrote:
They have already opted in by adding the CSP header. Once they've
opted-in to our web-as-we-wish-it-were they have to opt-out of the
restrictions that are too onerous for their site.
I understand the seductive power of
On Tue, Oct 27, 2009 at 12:39 PM, Daniel Veditz dved...@mozilla.com wrote:
I don't think we're having a technical argument, and we're not getting
the feedback we need to break the impasse in this limited forum.
I agree that we're not making progress in this discussion.
At a high level, the
On Tue, Oct 27, 2009 at 3:54 PM, Brandon Sterne bste...@mozilla.com wrote:
I couldn't find a comment that summarizes the model you are proposing so
I'll try to recreate your position from memory of our last phone
conversation.
I'll try to find the time to write a complete specification.
I
On Thu, Oct 22, 2009 at 8:58 AM, Mike Ter Louw mter...@uic.edu wrote:
I've added a CSRF straw-man:
https://wiki.mozilla.org/Security/CSP/CSRFModule
This page borrows liberally from XSSModule. Comments are welcome!
Two comments:
1) The attacker goal is very syntactic. It would be better to
On Thu, Oct 22, 2009 at 9:52 AM, Mike Ter Louw mter...@uic.edu wrote:
I agree. It seems anti-csrf (as currently defined) would be most beneficial
for defending against CSRF attacks that don't require any user action beyond
simply viewing the page (e.g., img src=attack).
Maybe we should focus
On Thu, Oct 22, 2009 at 10:15 AM, Mike Ter Louw mter...@uic.edu wrote:
I think this is a good start, and should be an option for sites that don't
want CSP to provide any other CSRF restrictions. I've added an additional
directive to the wiki, but it needs further definition.
I think it might
On Thu, Oct 22, 2009 at 12:36 PM, Mike Ter Louw mter...@uic.edu wrote:
In this case, this boils down to: should CSP directives be threat-centric or
content-type-centric? Alternatively, this may be an example of CSP being
too granular.
I suspect we'll need to experiment with different
See inline.
On Thu, Oct 22, 2009 at 2:22 PM, Brandon Sterne bste...@mozilla.com wrote:
I'd like to take a quick step back before we proceed further with the
modularization discussion. I think it is fine to split CSP into modules,
but with the following caveats:
1. Splitting the modules
On Thu, Oct 22, 2009 at 5:22 PM, Brandon Sterne bste...@mozilla.com wrote:
Take XSS and history stealing for example. Assume these are seperate
modules and each is responsible for mitigating its respective threat.
Presumably the safe history module will prevent a site from being able
to do
On Tue, Oct 20, 2009 at 12:47 PM, Mike Ter Louw mter...@uic.edu wrote:
The threat model of HistoryModule, as currently defined, seems to be
precisely the threat model that would be addressed by a similar module
implementing a per-origin cache partitioning scheme to defeat history timing
On Tue, Oct 20, 2009 at 1:26 PM, Mike Ter Louw mter...@uic.edu wrote:
I'm not sure if hacking at the straw man should occur on the list or on the
wiki. Please let me know if it should go to the wiki.
I've be inclined to discuss feedback on the mailing list where others
can see and comment most
2009/10/20 Adam Barth abarth-mozi...@adambarth.com:
On Tue, Oct 20, 2009 at 12:50 PM, Devdatta dev.akh...@gmail.com wrote:
Regarding , History enumeration -- I don't see why it should be part
of CSP. A separate header - X-Safe-History can be used.
I think one of the goals of CSP is to avoid
On Tue, Oct 20, 2009 at 1:42 PM, Collin Jackson
mozi...@collinjackson.com wrote:
I think we're completely in agreement, except that I don't think
making CSP modular is particularly hard. In fact, I think it makes the
proposal much more approachable because vendors can implement just
BaseModule
On Tue, Oct 20, 2009 at 3:21 PM, Lucas Adamski lu...@mozilla.com wrote:
I've been a firm believer that CSP will evolve over time but that's an
argument for versioning though, not modularity. We are as likely to have to
modify existing behaviors as introduce whole new sets. It's also not a
Thanks Devdatta. One of the nice thing about separating the
clickjacking concerns from the XSS concerns is that developers can
deploy a policy like
X-Content-Security-Policy: frame-ancestors self
without having to make sure that all the setTimeout calls in their web
app use function objects
On Mon, Oct 19, 2009 at 6:43 AM, Johnathan Nightingale
john...@mozilla.com wrote:
Not as limited as you might like. Remember that even apparently
non-dangerous constructs (e.g. background-image, the :visited pseudo class)
can give people power to do surprising things (e.g. internal network ping
Hi dev-security,
On Friday, I spoke with Sid, Brandon, and dveditz about dividing the
Content Security Policy specification into modules targeted at
specific threats. This approach as two main benefits:
1) Different browser vendors can implement CSP incrementally by
deploying the most important
On Sat, Oct 10, 2009 at 1:19 PM, Florian Weimer f...@deneb.enyo.de wrote:
Does this address the lack of enforcement of the EV certificate
security level (i.e. it is usually sufficient to get any
browser-recognized certificate if I want to attack an EV site,
*without* disabling the EV UI)?
37 matches
Mail list logo
