CSP information in dev console

[Joel Weinberger]

Should we have information about the Content Security Policy (or lack thereof) in the dev console? In particular, palmer@ is reworking the connection info to be in the dev console, so does it make sense to put CSP info there too?

--Joel

[Chris Palmer]

Note that we could either:

* Create a dedicated Security tab in the dev console, which would show
TLS connection parameters, CSP violations, security-related JavaScript
exceptions, et c.; OR

* Put the TLS connection parameters in the Network tab, leave
JavaScript exceptions in the Console tab, put/keep CSP in the Console
tab, et c.

I am not yet sure which I prefer. Any thoughts?

> To unsubscribe from this group and stop receiving emails from it, send an
> email to security-dev...@chromium.org.

[Adrienne Porter Felt]

I like the idea of having a dedicated Security tab.

OTOH I worry that people will look in the console and forget to every look in the security tab.

[Joel Weinberger]

On Tue, Dec 9, 2014 at 3:41 PM, Adrienne Porter Felt <fe...@chromium.org> wrote:

I like the idea of having a dedicated Security tab.

OTOH I worry that people will look in the console and forget to every look in the security tab.

On Tue, Dec 9, 2014 at 3:39 PM, 'Chris Palmer' via Security-dev <securi...@chromium.org> wrote:

Note that we could either:

* Create a dedicated Security tab in the dev console, which would show
TLS connection parameters, CSP violations, security-related JavaScript
exceptions, et c.; OR

Just a clarification that CSP violations appear in the console already like regular error messages. I was thinking something more elaborate, like a clickable view of the actual policy (and maybe even making it editable to play around with). 

[Lucas Garron]

Is there a bug for this? If not, could you create one with whatever ideas you have?

[Joel Weinberger]

On Tue, Dec 9, 2014 at 4:23 PM, Lucas Garron <lga...@google.com> wrote:

Is there a bug for this? If not, could you create one with whatever ideas you have?

Before we do that, I was hoping to brainstorm whether it's a good idea at all (in particular, soliciting outside opinion as to if this would be useful). 

[Lucas Garron]

My instinct with these things is that they're usually to annoying to debug because info isn't available at all.

I've been meaning to read up on the entirety of CSP, because I'm still fuzzy on the details. I thinkI'll go do that right now.

[Devdatta Akhawe]

Hello

I would be curious to learn more about what exactly will be in the
Security tab vs in the normal console. For example, I would be sad if
the fact that CSP blocked something is not in the dev console, because
otherwise developers would be really confused. Similar for mixed
content warnings. If there is a security tab, it is quite possible
that only the security team keeps an eye on it, and for many security
issues it is better that the developer currently working on the
feature sees the issue and fixes it right there. Not to say that a
security tab won't be useful, but I would be curious what would go
there.

I can buy that the TLS connection parameters can be useful and I think
the reason why I agree is that TLS is a site-wide policy. Unlike, CSP
errors which are often in some corner of a page after a particular set
of actions is performed.

Re CSP information: to be honest, the presence/absence of more
information in CSP isn't really that big an issue for CSP deployment.
When the dev console shows an error, it is usually pretty easy to
pinpoint the problem. The harder part is finding all the places that
could break due to CSP. The reporting functionality is *very*
important for this and reducing report noise (due to extensions and
other things) would be extremely helpful. And if we want removal of
"unsafe-inline", the script-sample stuff would be really useful too.

cheers
Dev

On 9 December 2014 at 16:27, 'Lucas Garron' via Security-dev

[Joel Weinberger]

On Tue, Dec 9, 2014 at 7:58 PM, Devdatta Akhawe <dev.a...@gmail.com> wrote:

Hello

I would be curious to learn more about what exactly will be in the
Security tab vs in the normal console. For example, I would be sad if
the fact that CSP blocked something is not in the dev console, because
otherwise developers would be really confused. Similar for mixed
content warnings. If there is a security tab, it is quite possible
that only the security team keeps an eye on it, and for many security
issues it is better that the developer currently working on the
feature sees the issue and fixes it right there. Not to say that a
security tab won't be useful, but I would be curious what would go
there.

I don't think there's any chance of the usual console warnings moving out of the console. The current plan for the security tab is actually to be a replacement for the "connection" tab in page info. We're trying to make the page info space more permissions oriented, and it's kind of out of place to have developer info up there too. We were just brainstorming what other info might make sense in the dev console as well; personally, I was thinking of having a nice, editable version of the site's CSP (while the execution warnings remain in the console; perhaps they could be clickable into the security tab though?). 

I can buy that the TLS connection parameters can be useful and I think
the reason why I agree is that TLS is a site-wide policy. Unlike, CSP
errors which are often in some corner of a page after a particular set
of actions is performed.

Like I said, it's not just about TLS errors; it's about the whole connection info. 

Re CSP information: to be honest, the presence/absence of more
information in CSP isn't really that big an issue for CSP deployment.
When the dev console shows an error, it is usually pretty easy to
pinpoint the problem. The harder part is finding all the places that
could break due to CSP. The reporting functionality is *very*
important for this and reducing report noise (due to extensions and
other things) would be extremely helpful. And if we want removal of
"unsafe-inline", the script-sample stuff would be really useful too.

Good to know! Maybe not worth the effort then :-) 

[craig....@gmail.com]

On Wednesday, 10 December 2014 04:01:37 UTC, Joel Weinberger wrote:
>
> Good to know! Maybe not worth the effort then :-) 

I don't know... I kind of like the idea of showing a nice overview of the security information (and keeping the errors in the console).

I think it might highlight the security features being offered, as I don't think many website developers know CSP even exists.

I also think there must be a better way to show the CSP, rather than finding the plain text header buried in the network tab (or dare I say it, the meta tag)... would be good to remind people of the exceptions (maybe grey out the sources that are not used, so they might be considered for removal... or a gentle reminder that your still using unsafe-inline in red.. or via some other screen-reader friendly way).

Would also be good to highlight the X-Frame-Options header (which I know is going into CSP eventually), X-XSS-Protection, X-Content-Type-Options, Strict-Transport-Security... and perhaps a little less likely, a report to suggest things like "this cookie isn't used by JavaScript, perhaps it could be HTTPOnly, and only on secure connections".

And if you could have TLS information, that would be good as well... I know this might duplicate the information, but having the expiry date in an easy to view location would be nice (it's not too difficult as it is, but I think it could be better).

[Craig Francis]

On Wednesday, 10 December 2014 12:13:43 UTC, Craig Francis wrote:

On Wednesday, 10 December 2014 04:01:37 UTC, Joel Weinberger  wrote:
>
> Good to know! Maybe not worth the effort then :-) 


I don't know... I kind of like the idea of showing a nice overview of the security information (and keeping the errors in the console).

I think it might highlight the security features being offered, as I don't think many website developers know CSP even exists.

Attached are some suggestions of what this security tab could look like.

I have a warning for SRI being used on HTTP (Joel, I know you're concerned about this).

There is information about the HTTPS connection - inspired by ssllabs.com... it could highlight problems like a broken certificate path (e.g. a server not providing a certificate, which then needs to be downloaded separately).

I think the certificate start/end date is much better presented than the current interface - but I will be biased there :-)

There are prompts to educate developers about browser features (OCSP / HSTS), and suggestions for CSP (much easier to read than from the network headers).

And I think there would be a certain element of gamification, where developers may see it as a challenge to get green ticks :-)

Craig

[PhistucK]

I like this idea. This is similar to Audits and this helps shaming you if you (or your users) care a bit. :) The information is presented in a structured and helpful way, with more or less good, actionable suggestions.

☆PhistucK

To unsubscribe from this group and stop receiving emails from it, send an email to security-dev...@chromium.org.

[Craig Francis]

On Sunday, 21 December 2014 20:57:45 UTC, PhistucK wrote:

I like this idea. This is similar to Audits and this helps shaming you if you (or your users) care a bit. :) The information is presented in a structured and helpful way, with more or less good, actionable suggestions.

Thanks PhistucK,

I've created a bit more of an interactive version at...

https://craigfrancis.github.io/dev-security/

Pull requests welcome on the GitHub project...

https://github.com/craigfrancis/dev-security/