On 10/10/13 16:35, chris hofmann wrote:
> The one idea that is new here is the idea about paying developers for
> fixing vulnerabilities in the code they work on. That could create the
> wrong incentives if not managed and tracked properly, setting up the
> possibility of writing code that's insec
On 10/10/13 11:21, Rob Stradling wrote:
> Gerv, how about asking Google to add NSS to the list of projects that
> are in-scope for this new rewards program?
Good idea.
Gerv
___
dev-security mailing list
dev-security@lists.mozilla.org
https://lists.moz
http://googleonlinesecurity.blogspot.co.uk/2013/10/going-beyond-vulnerability-rewards.html
Google are now paying people, retrospectively, for any patch that
improves the security of OpenSSH, BIND, ISC DHCP, libjpeg,
libjpeg-turbo, libpng, giflib, Chromium, Blink, OpenSSL, zlib and
commonly used co
On 30/09/13 18:35, Igor Bukanov wrote:
> This stops lazy thieves that capture the password or one-time-codes
> for later use while modifying original ones so a banking site would
> reply with a password error page. This way the thieves do not need to
> develop any fake pages etc. However, this is u
On 17/09/13 15:18, a...@google.com wrote:
> On Tuesday, September 17, 2013 4:58:28 AM UTC-4, Gervase Markham
> wrote:
>> Can we work out what those requirements are by studying the
>> pinning configuration for google.com and its subdomains in Chrome?
>
> There are two diff
On 17/09/13 03:52, Brian Smith wrote:
> One thing that is up for debate is what the security/privacy tradeoff
> should be. In particular, the channel ID keypair itself acts like a
> cryptographically strong cookie and could be used for tracking. The
> Chromium team has implemented some measures to
On 17/09/13 03:24, Brian Smith wrote:
> Unfortunately, we heard from Google that it is actually difficult for
> them to send these headers in HTTPS responses from their servers due
> to some special requirements that I am not so familiar with.
Can we work out what those requirements are by studyi
On 11/09/13 17:59, Hanno Schlichting wrote:
> But at this point it seems clear to me, that there's likely no way to
> share any meaningful subset or aggregated version of this data
> publicly at all.
Could you outline the thinking that led you to that conclusion? It
doesn't seem clear to me from t
On 10/09/13 19:05, Chris Peterson wrote:
> Our location service (and stumbler) also collects cell data, so we can
> geolocate with Wi-Fi AP and/or cell data.
Sure. But in the rural areas I am thinking about, cells cover many
square km. The wifi access point has a much smaller range, and therefore
On 10/09/13 10:48, ianG wrote:
> If that is the case, why not flip it around. Instead of trying to
> interpolate the existing data that is broadcast out there, why not write
> a protocol to broadcast the direct location from the wireless access point?
Because only a tiny, tiny fraction of devices
On 09/09/13 22:58, Chris Peterson wrote:
> Google's Location Service prevents people from tracking individual
> access points by requiring requests to include at least 2-3 access
> points that Google knows are near each other. This "proves" the
> requester is near the access points.
Related questi
On 10/09/13 02:13, Brian Smith wrote:
> On Mon, Sep 9, 2013 at 2:58 PM, Chris Peterson wrote:
>> Google's Location Service prevents people from tracking individual access
>> points by requiring requests to include at least 2-3 access points that
>> Google knows are near each other. This "proves" t
On 10/09/13 00:25, R. Jason Cronk wrote:
> Is the data aged?
Not AFAIAA.
> What happens if I move?
The raw database notes that you are now being detected in a new
location. What happens then is up for debate. I'd argue that if your
position was fixed for N months before, and it seems fixed agai
On 10/09/13 08:04, Henri Sivonen wrote:
> 1) Android has a mechanism for detecting when it is connecting to a
> portable AP provided by another Android device. Can we use the same or
> a similar detection mechanism to detect portable APs and filter them
> out?
I suspect actually connecting to the
On 10/09/13 04:14, Brian Smith wrote:
> There is friction in changing SSIDs as it affects every device that
> would connect to that network. There will also probably not be much
> awareness among users of when/why/how to do this or what effect it
> will have. So, I think this is an aspect that s
On 10/09/13 06:05, Chris Peterson wrote:
> The device would scan for nearby APs and send the hash of each AP's MAC
> and SSID to our location server. Our server would not need to worry
> about the hash of hashes pairs because that would only be used for
> published data. The server would return an
On 22/08/13 07:09, Mikko Rantalainen wrote:
> Perhaps I'm not an average user but I would like to be informed about
> changed key in all those cases.
You are definitely not the average user.
>>> 2 year certs if time limit increases security? Why not issue a
>>> new signature every day and be done
On 15/08/13 11:22, Mikko Rantalainen wrote:
> No. The site's public key does not need to be changed to request a
> new certificate.
Technically, no. But there are other occasions on which it does - key
length upgrade, cert private key loss or compromise (or possible
compromise). In the current sy
On 13/08/13 18:11, ianG wrote:
> Badly. Riddled with bad, false and self-serving assumptions. here's
> just one:
>
>"Before we begin, we must understand that
>Security = Encryption * Authentication."
>
> Wrong. That happens to be the SSLv2 security offering, aka C.I.A. for
> co
On 14/08/13 07:09, Mikko Rantalainen wrote:
> I'd say that such a bookmark would be highly probably safe, if that
> bookmark did include fingerprint for the site public key (*not CA key
> fingerprint*) and the browser did verify the fingerprint before
> entering the site.
Except that the bookmark
On 13/08/13 08:44, Mikko Rantalainen wrote:
> I cannot speak for Ian, but I'd guess "neutral" mode means something
> along the lines "use encrypted connection but do not show any
> additional 'secure' UI decorations". That would be suitable for cases
> where site wants to protect the user input and
On 25/07/13 13:18, Nicholas Wilson wrote:
> On 24 July 2013 17:22, Gervase Markham wrote:
>> Have you considered giving the managed servers certs minted from a local
>> company CA, and trusting that root cert in the copies of Firefox? Or
>> does that not work either?
>
&g
On 23/07/13 14:34, Nicholas Wilson wrote:
> created to enable exactly these sorts of use cases, surely! It's clear
> though that the app has to be served over HTTPS. And, it makes
> connections to WebSocket-enabled servers on your local network that
> aren't on the wide internet, so it's infeasible
On 03/07/13 17:41, Boris Zbarsky wrote:
> This is not the case. If a multipart response is sent, we will render
> all the parts one after another.
I know this is true if the MIME type is multipart/x-mixed-replace, but
there are other multipart MIME types. Is it true for them also?
> You can see
On 12/06/13 17:35, Jonathan Kew wrote:
> The proposed WOFF 2.0 format[1], under discussion in the W3C webfonts
> working group, includes the use of the LZMA entropy coder as a
> better-compressing alternative to zlib.
Very related bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=366559
Gerv
___
On 10/05/13 18:54, David Keeler wrote:
> * The only plugin that most users care about is Flash. Adobe stopped
> development for Flash on Android in November of 2011, which is a year
> and a half ago[1].
and it's no longer available for new installations.
> * Popular sites that use plugins ha
On 02/04/13 12:20, Florian Weimer wrote:
> In a corporate setting, intercepting proxies are fairly common, and
> displaying a warning would be annoying to users. (Didn't some browser
> vendor already try that?)
It depends what UI you use. For example, if we had a red padlock... ;-)
Seriously, th
On 27/03/13 16:19, Ian Melven wrote:
> another very common MITM situation is a captive portal on public wireless.
True; I think a warning is entirely appropriate in that situation.
> personally, i'm reluctant to conflate network attacks with private browsing
> mode,
> i believe it's already diff
I wanted to raise a suggestion from John Nagle to the status of a new
thread. John suggested that, in Private Browsing Mode only, Firefox
should inform the user if they make a secure connection using a
certificate which is not one of the default set in NSS's root store.
The logic is that if a user
On 24/03/13 16:43, John Nagle wrote:
> If, in private browsing mode, Mozilla can detect a MITM attack,
> the user should be warned with a high-visibility warning.
Er, if we could detect an MITM attack in any mode, there should be a
high visibility warning. :-)
> This includes any cert in the chai
On 15/11/12 06:21, Johnathan Nightingale wrote:
We've bifurcated this thread in a way that I think is growing
unhelpful. Gavin's commenting in the d.a.f one with a clearer state
of the world, and I don't see a lot of value in having two threads in
different newsgroups for this topic.
You are qu
On 12/11/12 16:45, Johnathan Nightingale wrote:
Every community has conservative elements. They are helpful; they
remind us who we are when we forget. But conservative forces prevent
change (by definition!) and we have important aspects of our code
that need changing. I don't believe that the dis
On 16/10/12 21:14, Dan Veditz wrote:
On 10/15/12 11:36 AM, Gervase Markham wrote:
Can we do a hybrid system, where for whitelisted TLDs we accept
registered domains as found and then apply the algorithm to the rest of
the labels [...]
Hmm. Possible, but certainly more confusing. Ideally, the
On 13/10/12 23:37, Dan Veditz wrote:
I'm only a little concerned about grandfathering. I _am_ concerned that
the whitelisting mechanism supersedes the proposed algorithm and allows
for arbitrary charaters on labels above the level of the domain that the
registrar issues and can vet.
Not arbitra
On 12/10/12 20:59, Justin Dolske wrote:
Seems like it should be fairly simple for NetSol to generate a list of
grandfathered domains. Have they done so and reviewed it?
They tell me that they have, and worked with some domain owners to
transition to new domains.
"As with the introduction of
On 11/10/12 22:05, John Nagle wrote:
I would argue against this exception for ".com" and ".net".
If someone is mounting an attack, it would probably be in those TLDs.
Not if they aren't included.
Discriminating against domain owners in .com or .net because of what
some criminals may or ma
On 05/07/12 16:39, Daniel Veditz wrote:
However, given that it was a .com domain which started all this fuss, I
thought it was worth posting publicly in case anyone had any comments.
Have they revoked all the previously spoofing domains? Have they
audited all their existing domains to make sure
On 20/07/12 09:39, Jan Schejbal wrote:
> Except for 2010, every year since 2008 has had at least one significant
> change to the SSL indicator. This means that each time we finally
> managed to teach users what to look for, that changed.
And what we've ended up with now is an indicator that's real
On 05/07/12 21:12, hillb...@gmail.com wrote:
> May I suggest the following additions?
Hi Brad,
We are basing our algorithm on that in the UTR. Perhaps your feedback is
better directed to Mark Davis, who maintains it?
Or are you saying these restrictions are already in that document, and
we mis
Hi Dan,
Sorry for the delay here.
On 05/07/12 16:39, Daniel Veditz wrote:
> On 7/5/12 1:37 AM, Gervase Markham wrote:
>> Recently, it was decided that a whitelist was not scalable in the face
>> of hundreds of new TLDs, and that we had to come up with a new approach.
>>
As some participants may recall, our IDN TLD whitelist was created in
response to the "payp-cyrillic-a-l.com" incident of 2005.
http://www.shmoo.com/idn/
Since that time, we have whitelisted over 50 TLDs after having inspected
their anti-spoofing policies.
http://www.mozilla.org/projects/securit
On 30/06/12 18:01, secguard...@yandex.com wrote:
>> ** This proxy would strip the last octet out of IP addresses for pings
>
> I'm not an expert here, but would that be sufficient for IPv6?
We should certainly make sure we do enough for IPv6. Although if Google
is using the IP address for geoloca
On 20/06/12 17:34, Zack Weinberg wrote:
> Ugh, you're right; I forgot about /etc/hosts and WINS names.
>
> There might be something clever we can do to detect these, but I'm not
> sure what it would be offhand; the operating system APIs I know about
> are deliberately designed to hide the details
On 19/06/12 17:24, Zack Weinberg wrote:
> I think we do need our own DNS resolver eventually (mostly because
> DNSSEC) but it's not necessary for this. We'd just have to refuse to do
> the DNS query at all for URLs whose hostname component did not contain a
> dot, and/or which was equal to or a su
On 16/06/12 15:46, Zack Weinberg wrote:
> I disagree; this is the place to work out whether it is Mozilla's
> opinion that top-level A records are inappropriate. We have the
> technical ability to refuse to honor such records,
Can you outline how we might do that? Would we need our own DNS
resolv
On 16/06/12 15:46, Zack Weinberg wrote:
> I have remembered the security case for not honoring top-level A
> records: it has to do with abbreviated DNS names used in intranets.
> Suppose http://ai.example.com/ is an internal-use-only server for
> example.com employees, whose computers have all been
On 14/06/12 19:55, John Nagle wrote:
>Top-level A records are already allowed. Try
>
> http://ai/
The CCTLDs have a different arrangement with ICANN from the GTLDs. ICANN
has a lot less control over them. Can you find a GTLD where there is a
top-level A record?
Gerv
__
> Many of the TLDs are from domain speculators who want to resell
> domains, but a sizable fraction are world-famous brands. Those
> will be expected to work as bare words.
I'm really not convinced that's so. Do you have any evidence that people
are expecting that, or can you point to the place i
On 12/06/12 15:39, Kevin Chadwick wrote:
> Leaving aside server/device security which may affect user security and
> also completely anonymised data matching to connection details or
> substitued user ids. An example being homesafe violating the long
> standing and well serving principle of simple
On 11/06/12 21:56, Justin Dolske wrote:
> I'd note a slight concern from our own (Firefox) experience with similar
> things in antivirus software, where new releases of Firefox are
> sometimes blocked because whatever reputation scheme they're using is
> too specific to just the filename/contents.
Hi Sid,
On 08/06/12 23:02, Sid Stamm wrote:
> == System Attributes ==
>
> * List Size: roughly 300 domains and 100 app signers in whitelist (small)
Taking Google's whitelist daily and removing warnings for domains and
signers on the whitelist seems like a fairly obvious win. It reduces
warning f
On 11/06/12 11:11, Henri Sivonen wrote:
> Could privacy be enhanced by having a Mozilla-hosted server bounce a
> TLS connection to Google's API endpoint? That is, Mozilla would see
> the user's IP address but wouldn't see the contents of the TLS
> connection and Google would see the contents of the
On 06/06/12 16:13, Johnathan Nightingale wrote:
>> Until now, this was mostly a curiosity, but if there's a
>> "FACEBOOK" TLD, people are going to scream if it behaves like
>> that.
>
> Yep. That's a problem.
Unless it never works. If we announce we are not going to support this
hijacking of bare
On 04/06/12 19:10, John Nagle wrote:
>Many new TLDs appear to be coming. This may affect how Mozilla
> interprets input in the URL bar, and has security implications.
But to a lesser degree than for Chrome. They use the PSL to determine
what is a URL and what is a search; that may not be scal
Forwarding to NSS and NSPR communities.
Downtime is from 0500-1200 PST (7 hours).
Gerv
Original Message
Subject: Mozilla Scheduled Downtime - 2012/04/26 - 0500-1200 PST
Date: Thu, 26 Apr 2012 03:04:07 +0800
From: Shyam Mani
Organization: Mozilla Corporation
To: dev-plann...@li
On 11/04/12 08:54, Jesse Ruderman wrote:
1) If a site sends an STS header, and the user has any data (cookies,
passwords, etc) that are not https-only, immediately mark that data as
https-only. (This helps if a site uses STS, but the user's privacy
settings cause the password storage to outlive t
On 28/03/12 02:29, John Nagle wrote:
>The CA Browser Forum is tightening up standards.
> The rules on certs change July 12, 2012, and will be much tighter
> thereafter. There will be three levels of certs - "domain control
> only", "organization validated", and "extended validation".
> "Domain
On 22/03/12 20:15, Yvan Boily wrote:
> If we did this, would it be feasible to analyze user input into DOM
> elements and raise warnings if personal data is entered into documents
> loaded from "bad" sites?
I would expect such sites to take the data as soon as it's entered and
spirit it away via
On 16/03/12 14:53, Kevin Chadwick wrote:
If you don't need background data. You can disable that and get no
automatic update checks.
Turning off updates, including security updates, doesn't sound to me
like an awesome solution to the problem of being nagged about them...
"Hey, if you cancel
On 16/03/12 04:27, Lucas Adamski wrote:
Gaia app: consists of a1, b1, c1. A typical local app, with a static
codebase that is installed once, authenticated by a code signature
and prohibited from dynamically loading additional code.
So no remote request for JS? No eval and friends? Do we use CS
On 15/03/12 15:25, Arvind S Raj wrote:
Hello everyone,
I couldn't find a specific mailing list for GSoC related discussion so
thought I'd email the security developers list and ask about this.
Hi Arvind,
There isn't one; here is fine :-)
I came across former ideas of Mozilla in security and
On 27/02/12 16:41, Sid Stamm wrote:
> On 2/27/12 6:30 AM, Stephen Schultze wrote:
>> Hey Sid, can you give an update on this action plan?
>
> Here's what I know:
And this page may also be enlightening with regard to the current
priorities for the security team:
https://wiki.mozilla.org/Security/R
Hi Ben,
On 11/01/12 17:07, Ben Bucksch wrote:
> The majority of discussions here on this list are policy discussions
> that are not specifically about bugs that are still embargoed, but
> either general "what should we do about this whole class of problems" or
> about security bugs that are alread
On 06/09/11 03:48, Devdatta Akhawe wrote:
> I was surprised to note that DigiNotar had a log of all IPs who had
> requested an OCSP lookup for the bad certs. This seems like a very bad
> idea on the OCSP server's part.
Well, the list of IPs has been passed to Google, who are now able to
warn peop
On 30/08/11 17:46, Boris Zbarsky wrote:
> I was looking at our CA root list, and a lot of them seem like
> "specialist" CAs that would only issue certs for a limited range of
> hostnames. Could we formalize this, and have CAs indicate any such
> restrictions as part of their application, then enfo
On 17/08/11 13:21, Jean-Marc Desperrier wrote:
> http://ashkansoltani.org/docs/respawn_redux.html
> http://www.schneier.com/blog/archives/2011/08/new_undeletable.html
> Some interesting precisions by Ashkan there in comments : "clearing the
> cache AND deleting all other forms of storage (HTML5, Fl
s I can remember were:
Sid Stamm
Brian Smith
Lucas Adamski
Chris Hofmann
Kai Engert
Bob Relyea
Gervase Markham
I think there were several other people there, but my memory is failing me.
> I can tell you there are NSS developers who never heard about this until now.
I apologise if we ha
Here's an imcomplete status update; further information from anyone
would be welcome:
On 08/04/11 23:49, Sid Stamm wrote:
> Bucket A:
> - Move to libpkix for all cert validation (bug 479393)
The code is now checked in; bug 651246 tracks flipping the necessary
pref. Brian Smith is working on the d
On 13/04/11 20:15, Stephen Schultze wrote:
On 4/13/11 2:02 PM, Brian Smith wrote:
Gervase Markham wrote:
On 12/04/11 14:22, Stephen Schultze wrote:
On 4/8/11 6:49 PM, Sid Stamm wrote:
- Implement subscription-based blocklisting of certs via
update ping (remove need to ship patch)
Would it
On 13/04/11 18:54, Stephen Schultze wrote:
I don't totally understand your point about addons and graphics drivers.
I guess I'm just not familiar enough with the codebase there.
Sorry. What I meant was, the current plan is to leverage the existing
system where Firefox pings us every day to dow
On 12/04/11 14:22, Stephen Schultze wrote:
On 4/8/11 6:49 PM, Sid Stamm wrote:
- Implement subscription-based blocklisting of certs via update ping
(remove need to ship patch)
Is there a bug for this?
Not that I know of; if there isn't, we need one.
Would this permit blocklisting of CA cer
On 09/04/11 18:05, Adam Barth wrote:
In addition to thinking about orderly transitions to new certificates
(as you mention), there's also the case of disorderly transitions.
For example, what happens if the site's private key gets compromised
and it wishes to move to a new certificate before it p
On 12/03/10 22:45, Nick Kralevich wrote:
To me, it seems valuable to support both X-Content-Security-Policy
and X-Content-Security-Policy-Report-Only, as it allows sites to test new
restrictions without disrupting their current restrictions.
That's a very good point IMO.
Gerv
_
On 26/11/09 20:32, Adam Barth wrote:
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.
Why off-list? This is mozilla.dev.security :-)
On 25/11/09 18:47, Kálmán „KAMI” Szalai wrote:
Today, one of leading IT portal published an article about FIrefox with
this title: "Firefox is not safety because of its extensions".
That's like saying "Windows is not safe because of applications".
Installing an extension is like installing an
On 05/11/09 15:24, Ian G wrote:
> It's not "utter nonsense" it's intellectual property. The claim that
> IANA/ICANN controls the letters '.int' inside a corporation is
> fundamentally based on intellectual property. Also, the notion that the
> internetworking protocols cannot be used internally a
On 05/11/09 18:20, Florian Weimer wrote:
> Okay, then Mozilla has got a significant problem because some CAs
> issue certificates for domains not delegated from the ICANN root.
> These CA roots should not be on Mozilla's root CA list.
Which ones?
Gerv
On 28/10/09 16:23, Gervase Markham wrote:
> On 27/10/09 09:33, Adam Barth wrote:
>> My technical argument is as follows. I think that CSP would be better
>> off with a policy language where each directive was purely subtractive
>> because that design would have a number o
On 27/10/09 09:33, Adam Barth wrote:
> My technical argument is as follows. I think that CSP would be better
> off with a policy language where each directive was purely subtractive
> because that design would have a number of simplifying effects:
CSP's precursor, Content Restrictions
http://www.
On 26/10/09 08:46, Nilesh Kumar wrote:
"Grab a preview build of Minefield
Download a copy of the latest trunk builds of Firefox which have CSP
support. The text you quote should have provided a link.
and load this page to see how CSP
works. For each individual test, a CSP-supporting browser
On 23/10/09 01:50, Daniel Veditz wrote:
blocking inline-script is key to stopping XSS. We added the ability to
turn that bit of CSP off as an interim crutch for complex sites trying
to convert, but if our proof-of-concept site has to rely on it we've
clearly failed and will be setting a bad examp
On 21/10/09 17:25, Sid Stamm wrote:
Additional Directives are not a problem either, unless they're mandatory
for all policies (which is not the case ... yet). I'm still more in
favor of extension via new directives than extension by modifying
existing ones: this seems more obviously backward com
On 20/10/09 21:20, Sid Stamm wrote:
While I agree with your points enumerated above, we should be really
careful about scope creep and stuffing new goals into an old idea. The
original point of CSP was not to provide a global security
infrastructure for web sites, but to provide content restrict
On 15/10/09 22:20, Brandon Sterne wrote:
I think we face a decision:
A) we continue to allow inline styles and make external stylesheet loads
be subject to the "allow" policy, or
B) we disallow inline style and create an opt-in mechanism similar to
the inline-script option [2]
C) We do A, but d
On 14/10/09 05:17, Daniel Veditz wrote:
Like the slashed-lock that indicates mixed mode (and is far too subtle
for my tastes) I expect a lot of users wouldn't even notice, but hope
that enough will to nudge things in the right direction.
Right. The intended effect is on the site owner, not on t
On 12/08/09 00:11, Ian Hickson wrote:
I think in almost all cases, multiple headers will be a sign of an attack
or error, not the sign of cooperation.
OK. I think that's a fair challenge. Can someone come up with a
plausible and specific scenario where multiple headers would be useful?
The o
On 10/08/09 22:56, Sid Stamm wrote:
I tried to find in my notes and email archives how exactly we decided to
move the keywords out, and couldn't find anything specific. Anyway, I
added an "options" directive to the spec[0] that captures this change. I
also added a thread on the wiki discussion pa
On 10/08/09 19:50, Brandon Sterne wrote:
Working examples will be forthcoming as soon as we have Firefox builds
available which contain CSP.
We shouldn't need to wait for working builds to try and work out the
policies, should we? Although perhaps it would be a lot easier if you
could test th
On 30/07/09 18:51, Daniel Veditz wrote:
* Remove external policy files.
I'd be happy to drop those, personally. Some people have expressed
bandwidth concerns that would be solved by a cacheable policy file.
Can we quantify that? At this stage, it's looking like most policies
won't be signi
On 29/07/09 23:23, Ian Hickson wrote:
* Remove external policy files.
I'm not sure how that's a significant simplification; the syntax is
exactly the same just with an extra level of indirection, and if that
makes things too complicated for you, don't use them.
* Remove policies.
Do
On 08/07/09 18:22, Bil Corry wrote:
If the hosting company is providing an interface to add one or more
additional CSP headers, then wouldn't it be just as easy for them to
provide an interface that constructs a single header?
The scenario here is that they have a set policy, which an individua
On 07/07/09 19:18, Sid Stamm wrote:
I personally want to eradicate the META tag
(http://blog.sidstamm.com/2009/06/csp-with-or-without-meta.html). This
should be discussed more in depth to decide if we should remove META
support, if we should support multiple HTTP headers, etc.
My comment:
Why
On 08/07/09 09:02, Daniel Veditz wrote:
The UA approach may be a botch, but it was an attempt at something like
a less-verbose Accept-type header (six bytes in the UA, many more as a
separate header which would have to be sent with every request, with no
servers today actually understanding anyth
Hi Eric,
Some really, really great points here. My thoughts on some of them:
On 06/07/09 01:28, EricLaw wrote:
Server CSP Versioning
Can the server define which version of CSP policies it wants to use,
allowing the client to ignore? I know that backward compatibility is
the goal, but other suc
On 02/07/09 01:20, Jonas Sicking wrote:
I think it should work. Otherwise
myForm.addEventListener("submit", function(event) {
if (!checkform()) {
event.preventDefault();
return false;
}
}, false);
should, according to web searches, make it work in IE too. But Jonas
knows more about this t
On 29/06/09 18:02, Brandon Sterne wrote:
That is clever. Yes, I think you're right that we should enforce a
valid MIME type for the external script files. We probably also want to
whitelist application/json for sites utilizing JSON feeds.
It does make you think, what other brokennesses can we
On 26/06/09 22:42, Bil Corry wrote:
It's been brought up this morning on the WASC Web Security list too:
http://www.webappsec.org/lists/websecurity/archive/2009-06/msg00086.html
The linked blogpost suggests using the page itself as an E4X document to
bypass the restrictions. Dead clev
On 10/04/09 16:46, Brandon Sterne wrote:
I'm not 100% thrilled with the idea either, mostly because parsing the
U-A string could be challenging for some sites. But it does seems to be
the least bad idea I've heard. We can certainly minimize U-A bloat by
making our subproduct something like "CSP
On 08/04/09 23:09, Sid Stamm wrote:
Additionally, knowing the portion of users whose browsers enforce CSP
(and thus are benefiting from the minimal effort put into serving a CSP
header) might be an interesting metric that web admins can present to
their managers. ;)
I don't think you need a CSP
On 08/04/09 21:49, Brandon Sterne wrote:
Defining a new header seems like a non-starter to me. We are going to
be hard-pressed to get one new header standardized, so throwing one away
seems very wasteful.
As I said, I think the possibility of needing a breaking change in
syntax is tiny.
If
1 - 100 of 321 matches
Mail list logo
