Meeting minutes
<Mek> https://
<wbamberg> https://
Slideset: https://
<estelle> Secure Web Application Guidelines
wbamberg: this relates to a recently launched SWAG CG (Secure Web App Guidelines)
… giving an update on some of the recent discussions happening there
… I'm a Technical doc writer and hope to make documentation useful to developers
… will open up a discussion on what other security topics may be worth our collective attention
… I work for Open Web Docs, an open collective of technical writer that document the Web mostly on MDN and maintain open web data
<DKA> Open Web Docs: https://
<estelle> https://
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
… what security related features should we be aware of that have low level of awareness/adoption?
<fscholz> Results of said survey https://
<wbamberg> security features: w3c-cg/
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
<estelle> Suggested article/guide: "Do you need a CSP?"
wbamberg: the 101 addresses some of them
David_Google: : 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
Estelle: as a developer, I want to know if I need a CSP before I adopt it in framework
Oliver_Google: I work in the Web Extensions CG where we have a number of similar considerations
… extensions have specific security features; some extensions can weaken the security of the default Web experience
… e.g. some web extensions remove the X-Frame prevention for their own use
… extensions come with a default CSP that can be weakened but only to some extent
Estelle: any pointer?
Rob: there is already some documentation on CSP on MDN; it has good & bad examples, may be lacking guidance
<r> Examples of documentation in extensions: https://
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
<jbroman> dom: targeting framework developers is very different from targeting other developers
<jbroman> ... do we need to address the broader range of developers? we need a community understanding of the audience
estelle: but framework developers would still need documentation
Aaron: +1 we need both documentation for all , and easy to use tools
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
… and in this case, this is is not a default, I need at least to know if it matters
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
Jeremy: the nonce example is interesting: the nonce-based CSP is very pervasive with impact throughout the deployment
… it would be useful for developers to know how to find the releavant framework information on this particular point
rdcronin (Google): 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()
… has there been any reasearch
<r> Another example of CSP guidance in extensions: https://
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
@@@: lots of developers lookign for classes and certifications - they would also be a good target audience
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
wbamberg: that's part of the 2nd goal highlighted on slide 8
rdcronin: meeting the developers where they happen to be feels important
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
fscholz: research has shown two types of developers: action-oriented developers (try and iterate) vs concept-based developers (taking a more holistic/theoretical apprach)
<jbroman> dom: I wonder if there would be value in mapping in more detail the developer journey in a security context
<jbroman> ... one idea is that documentation is part of a broader set of support that developers need
<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
<jbroman> ... if you can test it, it changes the discussion significantly
<jbroman> ... testing itself requires a lot of documentation
<jbroman> ... looking through the whole journey, not just with a narrow focus on reading documentation might be useful
<jbroman> ... also to calibrate the type of documentation you might be encountering
David: lighthouse include security guidance as part of performance audits
wbamberg: re including annotations in BCD - I think BCD should only concern compat
… but having a way to structure information about this sounds like a good idea
Rob: having structured information would help with surfacing it
fscholz: some APIs require specific security setting, e.g. sharedarraybuffer require cross origin isolation
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
… how do we prioritize the work that we're doing to address the security issues are actually facing the Web?
fscholz: we don't have e.g. on MDN a mapping of threats to end users with the underlying mitigation
jbroman: there is a long list of things MDN suggest doing
… I wonder if it's worth deemphasizing things that are less necessary, e.G. since most browsers now have a good default referrer policy, the value of specifying it is no longer critical
<jbroman> dom: this reminds me of Baseline
<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
<jbroman> ... hint that developers should feel safe to use it
<jbroman> ... this is a specific projection to this topic
<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"
<jbroman> ... one of the big challenge from my narrow experience in security is knowing where to start and where to finish
<jbroman> ... getting a clear sense of what is biggest bang for the buck
<jbroman> ... if you're mainly targeting recent browsers, extra material might be detrimental to the impact we want to have
past: re third-party library, is it about highlighting "good" libraries or should it focus on the threats from supply chain attacks?
DKA: supply chain would be part of evaluating libraries/frameworks from a security perspective
… 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
wbamberg: if you expect developers to use frameworks and give them good indication (e.g. use X or Y to do authentication)
… vs "to do X, think about security before making a selection"
DKA: this isn't only about big monolithic frameworks, but also libraries to achieve specific functions
<jbroman> dom: to relate this to the developer journey
<jbroman> ... the security work that you need to do when choosing dependencies
<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
<jbroman> ... guiding developers on that reflection would be really important
<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
fscholz: in the A11Y, there is WCAG
… the security world doesn't have the equivalent
… are we trying to come up with the security equivalent of WCAG?
… WCAG is also used in the regulatory context
… I wonder if the need for guidelines e.g. in the context of the EU CRA will arise as well
DKA: in OpenSSF, we're arguing for the use of Software Bill of Materials (SBOMs)
… which the EU CRA is providing guidance on
… which can impact procurement down the line
… I don't think we should aim at being regulatory guidelines, but at being able to guide developers
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
<jbroman> dom: a structural issue is that some of you have high level security expertise and understanding of changing priorities
<jbroman> ... but to what extent does that understanding easily reach us when we need to write the documentation
<jbroman> ... to know, e.g., that Referrer-Policy might not need to be as prominent
<jbroman> ... awareness of such changes is not obvious
fscholz: main motivation for the SWAG WG to connect these expertises
MikeW: guidance changes over time as new capabilities are brought to bear or as we brought new features to the platform
… the threats and the category of attacks against which we want to defend are stable
… teaching about these threats is a useful way to guide developers against these threats
… developers only need to care about CSP because of the risk posed by injection attacks
<DKA> +1
MikeW: educating developers about these threats before or more than the mitigations
… understanding the core concept for security perspective is a good anchoring to guide for specific countering these threats
… WebAppSec put out a note with a threat model laying out scenarios - only useful if people understand this is a problem they have
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
dom: in terms of next steps, SWAG CG is the place to be
jbroman: for instance, MDN lists CORP as required - but without more clarity on the underlying threat and how it applies to my resources
<mkwst5> Some links: https://
DKA: I don't think we plan to overlap with the threat modelling CG; Simone is involved in both groups
<ddworken> Also https://