On Nov 20, 4:37 pm, bsterne [EMAIL PROTECTED] wrote:
On Nov 17, 2:19 pm, Bil Corry [EMAIL PROTECTED] wrote:
(1) Something that appears to be missing from the spec is a way for
the browser to advertise to the server that it will support Content
Security Policy, possibly with the CSP version
On Nov 22, 2:03 pm, Lucas Adamski [EMAIL PROTECTED] wrote:
Yes, my understanding is that Access Control is actually intended as a
generic cross-site server policy mechanism, and XHR is just its first
implementation.
Anne confirmed that it's not intended to be XHR-only, however it's not
Gervase Markham wrote on 12/3/2008 4:56 PM:
bsterne wrote:
I think what Lucas is saying is that servers won't send policy to
clients who don't announce that they support CSP.
To save 60 bytes in a header?
No, so that in the event CSPv2 is incompatible with CSPv1, it won't require two
Gervase Markham wrote on 12/12/2008 11:23 AM:
Bil Corry wrote:
There's a group of us working on creating a spec for HTTPOnly cookies.
This isn't being done by WHAT-WG, then?
If you have an active interest in participating, our list is here:
http://groups.google.com/group/ietf
Justin Dolske wrote on 1/4/2009 9:48 PM:
The update check, which happens over SSL, includes a hash in the reply.
When the update is then downloaded (without SSL), the data is checked
against the hash from the update check. If the data was tampered with,
the hash won't match and the bad update
Sid Stamm wrote on 1/12/2009 12:52 PM:
Or do we want phone-home features for CSP so the browser will
automatically tell a site when its policy is violated?
It already has this feature, see #6:
http://people.mozilla.org/~bsterne/content-security-policy/details.html
- Bil
Gervase Markham wrote on 4/7/2009 6:07 AM:
On 07/04/09 07:36, Daniel Veditz wrote:
Maybe this does point out the need for some kind of version number in
the header, so future browsers can take appropriate action when
encountering an old header. For example, assuming none for any newly
added
Brandon Sterne wrote on 4/7/2009 12:02 PM:
I looked at each of the HTTP Header Field Definitions and my preference
for communicating the CSP version is to add a product token [1] to the
User-Agent [2] string. This would add only a few bytes to the U-A and
it saves us the trouble of having to
Gervase Markham wrote on 4/8/2009 2:07 PM:
On 07/04/09 18:02, Brandon Sterne wrote:
I'm actually against making it easy for servers to detect if CSP is
supported, because if we make it particularly easy, content authors will
start relying on it as their only defence rather than using it as a
Boris Zbarsky wrote on 5/16/2009 8:21 PM:
Why haven't browsers (such as FireFox) isolated tabs/windows from
each other such that I cannot simply replicate a logged-in user by
simply pasting into another FF tab?
For what it's worth, some sites do in fact prevent this (not sure which
Serge van den Boom wrote on 6/23/2009 3:48 PM:
On 2009-06-23, Bil Corry b...@corry.biz wrote:
Serge van den Boom wrote on 6/23/2009 8:13 AM:
However, by injecting an X-Content-Security-Policy header with the
policy-uri set to the vulnerable URL, the web client can be tricked into
visiting
Sid Stamm wrote on 6/26/2009 11:44 AM:
Some discussion about CSP has recently popped up on the mozilla wiki:
https://wiki.mozilla.org/Talk:Security/CSP/Spec
I'm posting the link here in case anyone interested hasn't seen it yet.
Comments are welcomed (both here and there).
It's been
One option is to meet in the middle: by default the meta tag is disabled, but
the hosting provider can enable it via the X-Content-Security-Policy header;
that way those who want the risk of it can still choose to use it.
Otherwise, +1 for removing meta tag support.
- Bil
Brandon Sterne
FunkyRes wrote on 7/1/2009 5:43 AM:
A library of function examples that do things cross platform in a
fully CSP compliant way would be a godsend, and IMHO preferable to
taking the easy way out and loosening up the enforcement.
I personally use jQuery to abstract the cross-platform issues:
Ian Hickson wrote on 7/16/2009 5:51 AM:
I think that this complexity, combined with the tendency for authors to
rely on features they think are solvign their problems, would actually
lead to authors writing policy files in what would externally appear to be
a random fashion, changing them
Daniel Veditz wrote on 7/23/2009 10:32 AM:
Sid has updated the Content Security Policy spec to address some of the
issues discussed here. https://wiki.mozilla.org/Security/CSP/Spec
Under Policy Refinements with a Multiply-Specified Header there is a
misspelling of X-Content-SecurityPolicy.
Sid Stamm wrote on 7/23/2009 11:41 AM:
On 7/23/09 9:36 AM, Bil Corry wrote:
And that section conflicts with what is said earlier in the document,
specifically:
When multiple instances of the X-Content-SecurityPolicy HTTP header are
present in an HTTP response, the intersection
In [1], it's mentioned that:
Furthermore, as a security measure, prefetching of embedded link hostnames is
not done from documents loaded over https. If you want to allow it in that
context too, just set the preference network.dns.disablePrefetchFromHTTPS to
true.
Can someone explain the
Wan-Teh Chang wrote on 7/23/2009 9:29 PM:
On Thu, Jul 23, 2009 at 7:10 PM, Bil Corryb...@corry.biz wrote:
Can someone explain the security concerns with DNS prefetching from a HTTPS
site?
The concern is privacy. Prefetching DNS for host names referenced
in an HTTPS page leaks some info
Johnathan Nightingale wrote on 7/24/2009 9:26 AM:
On regular http connections, this kind of disclosure is obviously
inevitable since the page contents themselves are visible to
eavesdroppers, but when the connection is over https, there is a
reasonable expectation of some privacy, so we try
Jean-Marc Desperrier wrote on 7/24/2009 1:09 PM:
The most serious attack seem to me to be than the attacker can know
*when* exactly you read any given mail.
I hadn't thought of that, but I do now see that as a reason to turn it off
entirely for any messaging application. You're right, it
Gervase Markham wrote on 11/5/2009 2:00 AM:
On 05/11/09 04:58, Bil Corry wrote:
You may want to consider registering a /.well-known/ path for this,
which it seems perfectly suited for:
http://tools.ietf.org/html/draft-nottingham-site-meta
That draft seems like a let's make the best
Some time ago on the HTML5 list[1], I brought up the problem that there wasn't
a straightforward way for a server to determine when the user had closed all
windows/tabs. We eventually came up with the idea of using a rel
extension[2] to specify a logout feature[3]; the browser pings the server
Justin Dolske wrote on 11/24/2009 10:33 PM:
On 11/24/09 12:16 AM, Bil Corry wrote:
We eventually came up with the idea of using a rel extension[2] to
specify a logout feature[3]; the browser pings the server when all
related windows/tabs are closed.
I'm not sure if the when all related
/Security_best_practices_in_extensions
https://addons.mozilla.org/en-US/developers/docs/policies
https://addons.mozilla.org/en-US/developers/docs/policies/reviews
-Sid
On 2/7/10 10:02 AM, Bil Corry wrote:
Eddy Nigg wrote on 2/6/2010 7:04 AM:
Isn't it about time that extensions and applications get signed with
verified
Axel Dahmen wrote on 2/28/2010 5:28 AM:
I've read through the CSP specs
(https://wiki.mozilla.org/Security/CSP/Spec#Source_Expression_List) and the
Talk (https://wiki.mozilla.org/Talk:Security/CSP/Spec)...
What I'm missing is a statement about allowing CSP directives in HTML
meta
tags.
Perhaps I've been hanging around the IETF lists too long, but shouldn't all of
the MUST not in the CSP spec really be MUST NOT?
http://www.ietf.org/rfc/rfc2119.txt
- Bil
___
dev-security mailing list
dev-security@lists.mozilla.org
Sid Stamm wrote on 6/25/2010 12:17 PM:
Once it is an app tab, any links directing the user off the site
will open in a new standard tab, so that the user won't be switching
top-level document domains in the app tab.
A couple of years back, I had a similar idea I called pinned tabs [1], but
On Mon, Oct 8, 2018 at 3:23 PM R0b0t1 wrote:
> If they did ban him with no warning for proposing a feature(?) then I
> think it is worth mentioning. There have been other very strange
> executive decisions that I think need discussed as well, mostly
> related to how ads are served in Firefox,
Hi Mark,
Wow, there's a lot to unpack in this email thread.
I'm not clear what you're asking for, I think you want community support to
add back in your warning banners regarding referrer privacy issues. If so,
please send a new email to the community asking for opinions about adding a
warning
30 matches
Mail list logo
