15:03:46 <RRSAgent> RRSAgent has joined #mdn-security
15:03:50 <RRSAgent> logging to https://www.w3.org/2024/09/25-mdn-security-irc
15:03:50 <tpac-breakout-bot> RRSAgent, do not leave
15:03:51 <tpac-breakout-bot> RRSAgent, make logs public
15:03:52 <tpac-breakout-bot> Meeting: What security guidance should we give web developers?
15:03:52 <tpac-breakout-bot> Chair: wbamberg, Daniel Appelquist
15:03:52 <tpac-breakout-bot> Agenda: https://github.com/w3c/tpac2024-breakouts/issues/96
15:03:52 <Zakim> Zakim has joined #mdn-security
15:03:53 <tpac-breakout-bot> Zakim, clear agenda
15:03:53 <Zakim> agenda cleared
15:03:53 <tpac-breakout-bot> Zakim, agenda+ Pick a scribe
15:03:54 <Zakim> agendum 1 added
15:03:54 <tpac-breakout-bot> Zakim, agenda+ Reminders: code of conduct, health policies, recorded session policy
15:03:56 <Zakim> agendum 2 added
15:03:56 <tpac-breakout-bot> Zakim, agenda+ Goal of this session
15:03:56 <Zakim> agendum 3 added
15:03:56 <tpac-breakout-bot> Zakim, agenda+ Discussion
15:03:56 <Zakim> agendum 4 added
15:03:57 <tpac-breakout-bot> Zakim, agenda+ Next steps / where discussion continues
15:03:57 <Zakim> agendum 5 added
15:03:57 <tpac-breakout-bot> tpac-breakout-bot has left #mdn-security
20:06:40 <wbamberg> wbamberg has joined #mdn-security
20:13:47 <dom> dom has joined #mdn-security
20:14:32 <Mek> Mek has joined #mdn-security
20:15:10 <fscholz> fscholz has joined #mdn-security
20:15:29 <past> past has joined #mdn-security
20:15:41 <DKA> DKA has joined #mdn-security
20:16:13 <Mek> https://wbamberg.github.io/web-security-w3c-breakouts-september-2024/Templates/Overview.html
20:16:25 <estelle> estelle has joined #mdn-security
20:16:29 <wbamberg> https://wbamberg.github.io/web-security-w3c-breakouts-september-2024/Templates/Overview.html
20:16:39 <dom> Slideset: https://wbamberg.github.io/web-security-w3c-breakouts-september-2024/Templates/Overview.html
20:17:30 <estelle> Secure Web Application Guidelines
20:17:48 <dom> wbamberg: this relates to a recently launched SWAG CG (Secure Web App Guidelines)
20:18:06 <jbroman> jbroman has joined #mdn-security
20:18:11 <dom> ... giving an update on some of the recent discussions happening there
20:18:26 <dom> ... I'm a Technical doc writer and hope to make documentation useful to developers
20:18:58 <dom> ... will open up a discussion on what other security topics may be worth our collective attention
20:19:18 <dom> ... I work for Open Web Docs, an open collective of technical writer that document the Web mostly on MDN and maintain open web data
20:19:20 <dom> [slide 2]
20:19:22 <DKA> Open Web Docs: https://openwebdocs.org
20:19:45 <r> r has joined #mdn-security
20:19:54 <dom> Present+ wbamberg, DKA, fscholz, estelle, Dom
20:20:47 <dom> [slide 3]
20:22:08 <dom> [slide 4]
20:23:06 <aaronshim> aaronshim has joined #mdn-security
20:23:16 <estelle> https://developer.mozilla.org/en-US/docs/Web/Security/Practical_implementation_guides
20:23:22 <dom> [slide 5]
20:23:33 <Em> Em has joined #mdn-security
20:23:33 <dom> RRSAgent, draft minutes
20:23:34 <RRSAgent> I have made the request to generate https://www.w3.org/2024/09/25-mdn-security-minutes.html dom
20:24:56 <dom> [slide 6]
20:26:21 <dom> [slide 7]
20:28:00 <dom> [slide 8]
20:29:16 <dom> DKA: it also emerged from the dev research we did in preparation for the workshop last year was that developers don't have information about the security features available to them
20:29:32 <dom> ... what security related features should we be aware of that have low level of awareness/adoption?
20:29:38 <fscholz> Results of said survey https://github.com/web-platform-dx/developer-research/blob/main/mdn-short-surveys/2023-05-15-security-dx/interpretation.md
20:29:59 <mkwst> mkwst has joined #mdn-security
20:30:37 <wbamberg> security features: https://github.com/w3c-cg/swag/issues/2
20:32:20 <dom> dom: any thought about how to address the different subaudiences of security needs? different type of developers will have different level of resources/control and risks of attacks
20:33:15 <estelle> Suggested article/guide: "Do you need a CSP?"
20:33:35 <dom> wbamberg: the 101 addresses some of them
20:34:23 <dom> @@@: CSP is very hard for the average developers to use CSP documentation to make a determination; ideally, they would get out of the box by default in frameworks/libraries
20:34:51 <dom> Estelle: as a developer, I want to know if I need a CSP before I adopt it in framework
20:34:59 <dom> s/@@@/David_Google:/
20:35:21 <dom> Oliver_Google: I work in the Web Extensions CG where we have a number of similar considerations
20:35:41 <dom> ... extensions have specific security features; some extensions can weaken the security of the default Web experience
20:35:48 <anusha0> anusha0 has joined #mdn-security
20:36:01 <dom> ... e.g. some web extensions remove the X-Frame prevention for their own use
20:36:26 <dom> ... extensions come with a default CSP that can be weakened but only to some extent
20:36:31 <dom> Estelle: any pointer?
20:37:00 <dom> Rob: there is already some documentation on CSP on MDN; it has good & bad examples, may be lacking guidance
20:37:12 <DKA> q?
20:37:14 <ddworken> ddworken has joined #mdn-security
20:37:28 <Em> Em has joined #mdn-security
20:38:36 <r> Examples of documentation in extensions: https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/manifest.json/content_security_policy
20:38:39 <dom> AaronShim_Google: re developers understanding the feature before opting-in - a number of features get provided by default by frameworks without requiring developers opting in; with frameworks abstracting away the complexity for their end users
20:39:20 <jbroman> dom: targeting framework developers is very different from targeting other developers
20:39:52 <jbroman> ... do we need to address the broader range of developers? we need a community understanding of the audience
20:39:57 <dom> estelle: but framework developers would still need documentation
20:40:25 <dom> Aaron: +1 we need both documentation for all , and easy to use tools
20:41:11 <dom> wbamberg: for instance, openwebdocs.org could use netlify one-click CSP nonce - but I don't know what's gonna break -  I as a developer need at least to understand the impact
20:41:22 <dom> ... and in this case, this is is not a default, I need at least to know if it matters
20:41:54 <dom> David: the not-on-by-default is part of the challenge - it increases the need for documentation if developers need to get to that level of understanding
20:42:22 <dom> Jeremy: the nonce example is interesting: the nonce-based CSP is very pervasive with impact throughout the deployment
20:42:40 <dom> ... it would be useful for developers to know how to find the releavant framework information on this particular point
20:43:25 <dom> @@@: do we know how often developers are learning of the difference pieces? through tooling? documentation? there may be an opportunity to improve the path to documentation, e.g. via the developer console()
20:43:33 <jbroman> s/@@@/rdcronin (Google)/
20:43:38 <dom> ... has there been any reasearch
20:43:41 <r> Another example of CSP guidance in extensions: https://developer.chrome.com/docs/extensions/reference/manifest/content-security-policy
20:44:11 <estelle> q+ (comment)
20:44:22 <dom> Aaron: adding a data point: I don't how users find that documentation; but there are papers highlighting how hard it is to deploy CSP and trusted types
20:44:51 <dom> @@@: lots of developers lookign for classes and certifications - they would also be a good target audience
20:45:13 <oliverdunk> oliverdunk has joined #mdn-security
20:45:36 <dom> estelle: looking at OWASP cheatsheet - if a feature has a particular intersection with e.g. CSP, it would be good to have a dedicated section in the relevant page
20:46:11 <dom> wbamberg: that's part of the 2nd goal highlighted on slide 8
20:47:29 <dom> rdcronin: meeting the developers where they happen to be feels important
20:48:15 <estelle> estelle has joined #mdn-security
20:48:47 <dom> Rob: BCD has information; would it be relevant to flag some of the features as having security considerations? e.g. to help with surfacing in editors/IDEs
20:49:26 <dom> fscholz: research has shown two types of developers: action-oriented developers (try and iterate) vs concept-based developers (taking a more holistic/theoretical apprach)
20:50:10 <wbamberg> q+
20:50:21 <jbroman> dom: I wonder if there would be value in mapping in more detail the developer journey in a security context
20:50:33 <jbroman> ... one idea is that documentation is part of a broader set of support that developers need
20:51:12 <jbroman> ... in particular, if we are clear about what developers need at what time in their journey -- here we are talking about current development patterns -- part of what makes CSP challenging is what it will break
20:51:19 <jbroman> ... if you can test it, it changes the discussion significantly
20:51:24 <jbroman> ... testing itself requires a lot of documentation
20:51:49 <jbroman> ... looking through the whole journey, not just with a narrow focus on reading documentation might be useful
20:51:57 <jbroman> ... also to calibrate the type of documentation you might be encountering
20:52:46 <dom> David: lighthouse include security guidance as part of performance audits
20:53:15 <dom> wbamberg: re including annotations in BCD - I think BCD should only concern compat
20:53:30 <dom> ... but having a way to structure information about this sounds like a good idea
20:53:50 <dom> Rob: having structured information would help with surfacing it
20:53:57 <DKA> q+
20:54:08 <DKA> ack wb
20:54:23 <dom> fscholz: some APIs require specific security setting, e.g. sharedarraybuffer require cross origin isolation
20:54:49 <dom> ack comment
20:54:52 <dom> ack DKA
20:54:55 <dom> q- (comment)
20:55:26 <dom> DKA: the end result we're driving for is a more secure web - people less subject to security problems when they use the web; fewer people have their info stolen, or get malware
20:56:17 <dom> ... how do we prioritize the work that we're doing to address the security issues are actually facing the Web?
20:56:38 <jbroman> q+ on deprioritizing older things?
20:56:46 <dom> fscholz: we don't have e.g. on MDN a mapping of threats to end users with the underlying mitigation
20:56:56 <past> q+
20:57:11 <dom> RRSAgent, draft minutes
20:57:12 <RRSAgent> I have made the request to generate https://www.w3.org/2024/09/25-mdn-security-minutes.html dom
20:57:29 <dom> jbroman: there is a long list of things MDN suggest doing
20:57:42 <dom> ... I wonder if it's worth deemphasizing things that are less necessary
20:58:36 <jbroman> dom: this reminds me of Baseline
20:58:52 <jbroman> ... it is a definition from WebDX CG of features that have been interoperable across major browsers for enough time to be considered widely available
20:58:57 <jbroman> ... hint that developers should feel safe to use it
20:59:07 <jbroman> ... this is a specific projection to this topic
20:59:39 <jbroman> ... conversely, if something has market share outside of the baseline in terms of relevance, maybe indeed it shouldn't be highlighted, or should be made less "required", or in a "security considerations for old browsers"
20:59:52 <jbroman> ... one of the big challenge from my narrow experience in security is knowing where to start and where to finish
21:00:01 <jbroman> ... getting a clear sense of what is biggest bang for the buck
21:00:17 <jbroman> ... if you're mainly targeting recent browsers, extra material might be detrimental to the impact we want to have
21:00:34 <jbroman> q?
21:00:35 <dom> s/less necessary/less necessary, e.G. since most browsers now have a good default referrer policy, the value of specifying it is no longer critical
21:00:38 <jbroman> q- jbroman
21:00:40 <jbroman> ack past
21:01:27 <dom> past: re third-party library, is it about highlighting "good" libraries or should it focus on the threats from supply chain attacks?
21:01:52 <dom> DKA: supply chain would be part of evaluating libraries/frameworks from a security perspective
21:02:28 <dom> ... there is a gap between the common pracitce in open source in focusing in supply chain security and the Web community has a much more fuzzy approach to this
21:03:13 <dom> wbamberg: if you expect developers to use frameworks and give them good indication (e.g. use X or Y to do authentication)
21:03:31 <dom> ... vs "to do X, think about security before making a selection"
21:04:29 <dom> DKA: this isn't only about big monolithic frameworks,  but also libraries to achieve specific functions
21:04:39 <jbroman> dom: to relate this to the developer journey
21:04:53 <jbroman> ... the security work that you need to do when choosing dependencies
21:05:36 <jbroman> ... making sure that you give guidance -- down the line it probably impacts using SRI, CDN, etc -- but before that, telling them: how do you assess whether you library is going to be compatible with your CSP? is it doing something that is consistent with your security policies in the broad sense
21:05:43 <hadleybeeman> hadleybeeman has joined #mdn-security
21:05:46 <jbroman> ... guiding developers on that reflection would be really important
21:06:07 <jbroman> ... mapping it out through the lifecycle of a project -- it's not just a one-time thing you do, but needs to be considered each time you add a dependency, etc
21:06:19 <dom> q?
21:06:47 <dom> fscholz: in the A11Y, there is WCAG
21:06:55 <dom> ... the security world doesn't have the equivalent
21:07:05 <dom> ... are we trying to come up with the security equivalent of WCAG?
21:07:35 <dom> ... WCAG is also used in the regulatory context
21:08:02 <dom> ... I wonder if the need for guidelines e.g. in the context of the EU CRA will arise as well
21:08:19 <dom> DKA: in OpenSSF, we're arguing for the use of SBOMs
21:08:28 <dom> ... which the EU CRA is providing guidance on
21:08:48 <dom> s/SBOMs/Software Bill of Materials (SBOMs)
21:09:14 <dom> ... which can impact procurement down the line
21:09:21 <wbamberg> q+
21:09:51 <dom> ... I don't think we should aim at being regulatory guidelines, but at being able to guide developers
21:09:57 <estelle> estelle has joined #mdn-security
21:10:01 <DKA> DKA has joined #mdn-security
21:10:39 <dom> Emilie_MS: I'm interested in ensuring not just creation of documentation, but maintenance, since these are fast moving spaces and guidance needs to evolve
21:11:26 <jbroman> dom: a structural issue is that some of you have high level security expertise and understanding of changing priorities
21:11:37 <jbroman> ... but to what extent does that understanding easily reach us when we need to write the documentation
21:11:52 <jbroman> ... to know, e.g., that Referrer-Policy might not need to be as prominent
21:11:57 <jbroman> ... awareness of such changes is not obvious
21:12:20 <dom> fscholz: main motivation for the SWAG WG to connect these expertises
21:13:01 <dom> MikeW: guidance changes over time as new capabilities are brought to bear or as we brought new features to the platform
21:13:20 <dom> ... the threats and the category of attacks against which we want to defend are stable
21:13:31 <dom> ... teaching about these threats is a useful way to guide developers against these threats
21:13:55 <dom> ... developers only need to care about CSP because of the risk posed by injection attacks
21:14:01 <jbroman> q+ re kinds of threats, corp
21:14:05 <DKA> +1
21:14:20 <dom> ... educating developers about these threats before or more than the mitigations
21:14:49 <dom> ... understanding the core concept for security perspective is a good anchoring to guide for specific countering these threats
21:15:26 <dom> ... WebAppSec put out a note with a threat model laying out scenarios - only useful if people understand this is a problem they have
21:16:32 <dom> DKA: one of the challenges is developing the right level of guidance on these threats; if it gets too complicated it becomes impossible for developers to ingest
21:16:45 <dom> q?
21:17:33 <dom> dom: in terms of next steps, SWAG CG is the place to be
21:18:38 <mkwst5> mkwst5 has joined #mdn-security
21:18:46 <dom> jbroman: for instance, MDN lists CORP as required - but without more clarity on the underlying threat and how it applies to my resources
21:18:56 <mkwst5> Some links: https://resourcepolicy.fyi/, https://www.w3.org/TR/post-spectre-webdev/
21:19:23 <dom> DKA/ I don't think we plan to overlap with the threat modelling CG; Simone is involved in both groups
21:19:47 <dom> s|/|:
21:19:50 <jbroman> q?
21:19:51 <dom> RRSAgent, draft minutes
21:19:52 <RRSAgent> I have made the request to generate https://www.w3.org/2024/09/25-mdn-security-minutes.html dom
21:19:58 <jbroman> q- jbroman
21:19:58 <ddworken> Also https://arturjanc.com/coi-threat-model.pdf
21:32:24 <past> past has left #mdn-security
21:40:12 <dom> RRSAgent, draft minutes
21:40:13 <RRSAgent> I have made the request to generate https://www.w3.org/2024/09/25-mdn-security-minutes.html dom
21:40:23 <dom> dom has left #mdn-security
21:50:40 <jbroman> jbroman has left #mdn-security