W3C Workshop Secure the Web Forward

Attendees

• Arnaud le Hors (IBM)
• Artur Janc (Google)
• Brian Clark (Snyk)
• Daniel Appelquist (Snyk)
• Daniel Huigens (Proton AG)
• Dominique Hazaël-Massieux (W3C)
• Forian Scholz (OWD)
• François Daoust (W3C)
• Gal Weizman (MetaMask)
• Gary O'Neall (Source Auditor Inc., SPDX Technical Workgroup Co-Lead)
• Hadley Beeman (Independent, W3C TAG member)
• Jake Marcinko (PCI Security Standards Council)
• Jan Kowalleck (Independent, OWASP CycloneDX Project Co-Lead)
• Jon Geater (RKVST)
• Paloma Oliveira (Affiliation Sauce Labs)
• Pedro Fortuna (Jscrambler)
• Rachel Yager (W3C Evangelist and Chapter Head)
• Yan Wang (OPPO)
• Zb Tenerowicz (MetaMask)
• ***** (futureLAB)

Workshop introduction

See introduction slides (also available in PDF).

• Context: developers find security aspects challenging according to MDN survey ran in May 2023

Software Bill of Materials for web frontends

See recorded presentation and transcript.

• Web deliverables may be made of various components not under the control of the company developing the deliverable.
• SBOM may be generated by hand, or by tools.
• One of the things that came out of the OpenJS world: do we need browsers to recognize SBOM in some way? Example of warning page for non secure web pages. Should there be an equivalent for pages missing SBOM data?
• Without analysis run on SBOM data, the SBOM is somewhat useless. Especially if the SBOM is made up.
• Software is a significant part of security but it’s not the only one. More complicated than TLS certificates. Not a black-and-white answer to a simple question.
• Some customers care about SBOMs to understand what components get used in applications. This includes regulations or pending regulations (e.g. from CISA/NTIA) that may require SBOMs. What does that mean for web applications?

Establish Standards to Support Web Access to SBOM Data

See recorded presentation and transcript.

• No standard protocol for SBOM discovery and access
• Granularity of SBOM data access is rather coarse
• Lots of duplication of SBOM needed right now
• The closer to the originator, the more accurate SBOM metadata will be
• Proposal in IETF for SBOM Discovery RFC 9472 (a.k.a. Discovering and Retrieving Software Transparency and Vulnerability Information), but less applicable to software in the middle of the supply chain
• Create a protocol for SBOM “Element” discovery?
  • Package managers as a source for truth was discussed at OpenJS World, in particular, NPM in the web dev world
  • Opinionated take on that: build your own SBOM during production processes, because:
    • SBOM in package managers? Probably not the composition of the product you deliver
    • SBOM in package registry? Most certainly not the composition of the product that you deliver!
    • And since I produce my SBOM, I need to share it somehow, or make it accessible (to trusted parties)
• Common SBOM vocabulary is also required. - JSON-LD, RDF…?
• Package managers are often seen as the source for truth by developers, as that’s where they will look into when they bring in a dependency. Package managers could be providing this SBOM data. Tools like Apache could integrate plugins pretty easily but not yet doing that for now.
• Package managers could be the worst place to get an SBOM from for Web applications. You may depend on a build, or not on include the dependency in your web deliverable.
• Chat: Not everything in a Webapp comes from a package manager, so it would be a incomplete by design SBOM source.
• Chat: but in the browser ecosystem, aren't CDNs much like package managers in the offline JS ecosystems?
• To discuss: need to standardize SPDX or integrate it somehow in W3C.
• Much better if standards get used by protocols.

Source Code Transparency

See recorded presentation and transcript.

• Example: WhatsApp built a browser extension to check that source code is signed by third party (Cloudflare)
• For browser code itself, hash of binary may be published through Certificate Transparency
• Subresource Integrity (SRI) can be used but, by definition, does not apply to the main resource
• Idea of Source Code Transparency is to publish a hash of the source code in a transparency log that browsers can check.
• Certificate Transparency could be leveraged.
• “Signed Web Bundle”
• Browser can check - hash of web bundle I’ve received is present in this Source Code Transparency log…
• X.509 extension indicating that Source Code Transparency “should be used” - whenever you load a webapp over https using such a certificate, do this check - gives visibility to security researchers…
• Challenges:
  • Allow updates immediately? Or only after inclusion in the log?
  • Every page (that the user might land on) should be checked
  • What about error responses?
• Q&A
  • Sigstore - could provide a (free) service of a transparency log… Takes a pragmatic approach to ease signature of any kind of artefacts.
  • OmniBOR and GitOID could help

Open Discussion

• There are plenty of opportunities for developers to get things wrong - and this seems to be one of them. Keeping things in sync (e.g. comments in code) is hard; in this case, it's about maintaining a list of ingredients - how would this fit into the regular workflow of developing a Web app? We touched on package managers not necessarily as useful in the context of a Web app; other mechanisms were mentioned (SRI, Web Bundles). How can this simply my life as a developer? Do things right by default rather than by effort?
• Automation is a key topic: making it easier for developers. E.g. about build tools, github hooks
• Every step along the chain should be producing SBOM, that serves as input to the next stage. To bind the delivered resource to source code that may only appear in some upstream stage, that’s needed in any case. Tracing things back to the source is a very positive thing.
• If I get an SBOM, I want to know what’s in it and how sure I am that what’s in it is correct. Bundlers such as webpack do not care where the component comes from. Where was the component sourced from? How to be sure that it had not been tampered with? All information is going to be useful and needed, including the version of the bundler used to build the application from the components. Hard to trust what the SBOM says.
• How to trust SBOMS…
  • Not solved - you have to trust the source…
  • Signatures could help though
  • No universal solution, in flux
• Still a step forward to have some information about the components, and still useful enough that browsers could use the info to look for security vulnerabilities in the reported components that compose an application.
• The Supply Chain Integrity, Transparency, and Trust (scitt) Working Group at IETF is working on this. Big issue is: what question are you trying to answer? SBOM delivered by the same person as code is equivalent to a self-signed cert. SBOMs make it considerably easier for honest sets of actors to act on vulnerabilities.
• Some developers have to go through certification, e.g., those developing payment apps, government apps. They might be more likely to adopt this sort of thing first, which can help set user expectations and drive uptake across the ecosystem.
• The Web needs to remain a platform that can be accessible from a wide range of developers. Build a bank web site. Build your personal web site. Small Web. Big Web. Need to think about complexity when we develop the web platform, and about ways not to increase complexity too much.
• Security audits - an external company does an audit on the source code of the webapp - then that audit is published - helps with trust. Things like SBOMs are a tool for security researchers and auditors - also to help them do the vulnerability checks, rather than sending them to the end user and showing a warning… That (end user warning) sounds risky as sometimes you don’t know if the webapp actually triggers the vulnerability. Also - only webapps that care about their reputation would be affected by that…
• From chat:
  • SBOM in package managers? Probably not the composition of the product you deliver.
  • SBOM in package registry? Definitely not the composition of the product that you deliver!
• Anything we can do as a community to get things embedded into the tools, package managers, devs use, would be useful.
• If you correlate SBOM data with a vulnerability database, you’ll end up with false positives. Vex (vulnerability exchange) could be one …
• Goals of a W3C SBOM approach?
  • Threat model is client-side.
  • Lots of ways to end up with tampered data.
  • There may not be a lot of value to be gained here for end users.
  • Need to agree the benefits/impact for the end user before working on standards
  • Some users will benefit though: end-to-end encryption scenarios, payments apps, etc.
• “Question -If a web application needs to verify an official/confidential document, can it detect the SBOM in the browser to check if the software components and versions are compatible with opening the document? This can prevent unsuitable applications from running.”
  • “the SBOM doesn’t really help with the financial document use case but SCITT does this very nicely, avoiding supply chain tampering, versionitis and so on. This is something my company actually does right now. Not sure how it would translate to a W3C context though”
• “I would encourage also to consider as part of the benefits / value, the perspective of security vendors, that can rely on SBOM data to make their jobs more effective (e.g. less false positives). The ultimate benefit is better security for websites in general (from their supply chains).”
• Lots of verification in financial services. Could SBOM help with verifying confidential info?
• Perspective of security vendors: multiple techniques. Not always perfect, false positives, but being able to rely on SBOM data is a step in the right direction. Lots of benefits.
• Security hand in hand with accessibility - scores - false positives … SBOMs very theoretical right now… Part of my CI build process would be the ideal flow - something integrated not “maybe” not as a plus but really integrated in the flow. Build blocked if insecure…
• “From an end user perspective, they care whether their information is compromised (privacy) - I don't think they distinguish whether the issue is with the software running in the browser or software running on the server. If we make SBOM's easy to access for all software, the software offered up by a site can be evaluated for potential vulnerabilities.”
  • Large companies will end up with tons of information that can hardly be processed.
  • Nice talk from Siemens at FOSDEM on their use of SBOM
• Pushing back on if users don’t care if data leaves the client, goes to the server… even if it’s a “trusted” server… our users do care if data leaves the browser. Having client-side encryption, not sending data to server at all is valuable. Having an SBOM for software running in client specifically - it should be sufficient. Webapp should not trust the server.
• A lot of end users might not be sophisticated enough to care but some definitely do care.
• Software a service profile - duplicating so much information - rather than sending around huge documents with duplicated information, you can traverse over the network.
• Web sites and web applications - if SBOMs are more widely used - what might happen is that SBOMs become a part of SEO… If a website uses [specific libraries] then [search engine of your choice] will downgrade it…
  • This might lead to an increase in cheating about SBOMs, as this probably will be the cheaper approach in most cases than actually fixing the vulnerability
  • Another responsibility: Websites and -apps that are meant to be found via search engines, even smallest and low-budget projects, might get forced to provide SBOMs. As a result, bigger projects have a better chance of getting traffic via search engines, as the smaller ones would be struggling updating their SEO (realizing the problem and financing the effort)
• Regarding “The End User”, for the developer use case it makes sense to have SBOMs with rich info but when it comes to the browser - and the user going to their bank in their browser - they will care about some kind of flag - e.g. with certificates the browser can flag you might not be on safe ground. User might not be able to understand gory details…
• Another thought: Could the information about the technologies used be exploited by hackers?

Attendees

• Arnaud le Hors (IBM)
• Artur Janc (Google)
• Benjamin Sternthal (OpenJS Foundation)
• Brian Clark (Snyk)
• Dan Appelquist (Snyk)
• Dominique Hazaël-Massieux (W3C)
• Florian Scholz (OWD)
• François Daoust (W3C)
• Gal Weizman (MetaMask)
• Gary O'Neall (Source Auditor Inc., SPDX Technical Workgroup Co-Lead)
• Gregory Power (Cary, NC)
• Hadley Beeman (Independent, W3C TAG member)
• Jake Marcinko (PCI Security Standards Council)
• Jan Kowalleck (Independent, OWASP CycloneDX Project Co-Lead)
• Jasvir Nagra (Jscrambler)
• Mathieu Hofman (Agoric)
• Paloma Oliveira (Affiliation Sauce Labs)
• Pedro Fortuna (Jscrambler)
• Rachel Yager (W3C Evangelist and Chapter Head)
• Tobie Langel (UnlockOpen)
• Yan Wang (OPPO)
• ***** (futureLAB)

Applying Hardened Javascript to supply chain security for a proactive approach

See recorded presentation and transcript.

• API or configuration to let applications work in the browser without leaving the comportment
  • Any access to DOM leaks globalThis
  • Selective use of evaluators
  • Same origin realms
• TC39 Compartment proposal has been split into multiple layers. Module virtualization part is developed in a module harmony working group, and likely going to progress fast. Stage 1 for now otherwise but should be able to move fast.
• Interaction with the browser process model?
  • Isolation provided on the level of the language itself
  • The concept of Compartment suggests that you should not provide original references to compartment but proxies them in a way that you can control them better. That remains slightly vague.
• Nowadays, cannot code use scopes to avoid these problems?
  • Demos are available that virtualize all globals already.
  • Future: packages are running with different sets of globals. E.g.: only string concatenation module? No access to fetch.
  • Principle of least authority.
• End-user needs - can we imagine some of the harms to end users in real-world scenarios that might be mitigated by this approach?

JavaScript realms used to bypass and eliminate web apps security tools - A problem with a WIP solution

See recorded presentation and transcript.

• Distinction between build time and run time. Difficult to secure things at build time. How to secure things enough at the build time to have enough protection down the line at runtime?
  • Need integration in the building tools
  • The only place where you see the whole code is at runtime. You should do whatever you can at build time from a supply chain perspective, but this won’t be enough. You have to do it at runtime.

Open Discussion on Hardened JavaScript

• Finding new JS realms is a way to circumvent access to DOM and powerful APIs. Need to have a mechanism to bootstrap realms in a secure way.
• Comparison with previous attempts? Seamless iframes? Past attempts have had mixed results.
  • Attempt made in Snow to capture realms creation is pretty unique for now.
  • Highly difficult to do it through shims though. Browser has the information, not the code. Hard from a security and performance standpoint.
  • The whole “game” is: we need a script from a trusted source to be able to run before any other code in all the realms of our origin. Service Workers provide a mechanism to run things only from a trusted source and outside/independently of windows involved. Web extensions have a mechanism allowing running a script in the context of the page (eg. world:MAIN in chromium) and before anything else runs (document has not been parsed).
• End-user needs? What is an example of the kind of exploits that these approaches shield users from?
  • Example: In-browser crypto wallet. End-user could be negatively affected by software anywhere in its dependency tree. There have been popular packages taken over in the past. User would lose money!
  • Another example: Imagine tools trying to defend web sites from attacks. Runtime analysis code is really good at detecting weird behavior and potential leaks. But the inability to run that analysis throughout all possible scenarios makes that incomplete by definition.
• The security issues are sort of the result of the web platform becoming extremely complex. Need to get back to something that is much simpler from a security perspective. We’re playing catch-up. It should not only be about defending, but also catching up.
• The question of the user need is difficult to address because the user need is to not get affected by large scale or targeted supply chain attacks. The more specific feature description can be formulated in terms of the app developer. The app developer needs the ability to plot the border between the fully trusted code and the code they find helpful and include in their application but should not have to trust it with the whole applications state and powers.
• If you don’t trust your own product, is there really a scenario where this is useful?
  • The goal is not to have to trust components of the product.
  • The real use case is not easily described in terms of end users (apart from “no money stolen”), more in terms of developers having the means to integrate other code in a secure way.
• Preventing user data from being leaked by 3rd party scripts running in the same origin. Problems like web skimming, or other data leaking like data privacy, patient or health data, some of which can lead to other problems like identity theft or account takeover.
  • Users do not want information to be leaked
  • Example: Insurance companies, health information data
  • Benefit for users: application owners can address this work.
• The PCI DSS standard requires two related points. The new PCI DSS v4 eSkimming requirements 4.6.3 and 11.6.1, see jscrambler article on PCI DSS v4.0 Requirements
• Other topic is around the DOM API. Really hard to give the powers to control some part of the rendering without giving away all of it. Endowment.
  • Historic attempt to build a membrane which was working for HTML4. Attempt became increasingly harder to maintain and got abandoned, c.f. the Caja project.
  • Two other possible approaches:
    • Exposing a popular non-standard virtual dom api (react without ref)
    • Adding means to the browser to create a DOM fragment that is not attached to a window / realm (identity discontinuity might be problematic, otherwise it's a simple solution)
• Breaking an application into pieces is a really difficult problem. An application is built by pulling content from a lot of sources. Problem is the extent to which you trust third parties. The proposal gets to the core of this problem, which is good. Isolation and compartments.
• Security improvements brought to the platform come with increasing complexity to developers. Example of Content Security Policy (CSP). Cannot assume that people, who will use any mechanism that we may come up with, will be security experts.
  • CSP point reinforced during a session of WebAppSec meeting at TPAC in Seville.
  • CSP directives limit a lot of parts of the app, e.g., network. Made it difficult to adopt for developers. New proposal does not fall into that trap.
• Developers usually plug a library, take a peak at the readme, and that’s good enough. A sheet that contains a list of required access is something that application stores already do (Android, iOS). In package repositories, there could perhaps be the same experience. And then automate with Compartment.
• Tooling opportunities around package managers, bundlers.
• Also regulations are coming up. Business folks will start to care on top of developers. Having a clearer perspective of where we’re going will be useful not to end up with inadequate regulations that developers cannot meet.
• Critical to get the technology right. Need to look at it through the whole adoption lifecycle and ecosystem chain. Otherwise, we’ll end up in the same CSP situation.
• If the solution we adopt is CSP based, we’ll suffer equally.

Establishing a robust long-term security model for cookies on the web

See recorded presentation and transcript.

• How much breakage if we were moving in the direction described? How big an obstacle would that be?
  • Goal is to break the least amount possible while still getting the security benefits of the new model.
  • Example of top-level navigation using POST. Payment flows could stop working, which would be problematic. Need to be very creative as a result.
• A lot of the security improvements are bolt-on. Additional steps that developers need to take. Would it be worth having another reset mode similar to “use strict” to get the right defaults?
  • Cookies changes simplify the mental model for developers. In the absence of cross-site requests, no need to worry about them?
  • Flag would still be useful
  • Key issue is deployment. New mode would only apply to new content. How to migrate? Ongoing work in WebAppSec WG but slow progress.
• Case of JavaScript served by third-party different based on cookies. Done e.g., for segmentation.
  • Removal of third-party cookies would break that.
  • Still some mechanism to re-enable this, but won’t likely address this use case.
• If we break things, would it make sense to go further, e.g., cookie on first page load only?
  • Difficult question to answer.
  • Room for more APIs. Difficult for browsers to align. Need something that really breaks, e.g. payment flow. If it’s just a more simple breakage, going to be hard.
• Same-site=lax, referred to as cookies apocalypse in certain circles. A bunch of recent hacks involving acquiring profiles with cookies. Are we considering encrypting cookies for local storage and transferring them?
  • There is parallel work on cookie rotation to bind cookies to a particular device. It doesn’t prevent stealing but usage much more difficult. Once you have malware on the user’s device, the malware will just implant itself on the user’s device to steal the cookies.
  • Cookies are not granular enough to make security decision.
• Lots of proposals to the W3C TAG related to disappearance of third-party cookies to re-enable previous use cases? Usually comes with the same tracking issue. Maintaining the status quo spirit is really there. Relentlessly focusing on the specific use case (and the privacy holes it opens) can help.
  • FedCM, CHIPS, Storage Access proposals seem more successful at keeping tracking issues at bay.
• Can you explain how the new model shift will affect third-party apps that serve the paywalls? What should the third-party apps be doing?
  • Really going to depend on where the third party entity is embedded. What functionality it provides, e.g., authentication. Different solutions depending on the use case.
  • Some demos available to show how to re-enable some of the functionality that you might lose with third-party cookies deprecation.
  • Experience of browsing the web without third-party cookies: the web seems to work pretty well without third-party cookies. Federated login? Seems to work.
• How many legitimate third-party applications would break?
  • From a security perspective, the stricter, the better
  • Practically, many things break in many scenarios, including enterprises and real web sites. Long tail of functionality is still going to affect a lot of users, e.g., access to your bank.

Resources for developers about third-party cookie replacement APIs:

• Digging into the Privacy Sandbox
• The Privacy Sandbox

Attendees

• Arnaud le Hors (IBM)
• Benjamin Sternthal (OpenJS Foundation)
• Dan Appelquist (Snyk)
• Dominique Hazaël-Massieux (W3C)
• Edson ?
• Florian Scholz (OWD)
• François Daoust (W3C)
• Gal Weizman (MetaMask)
• Gregory Power (Cary, NC)
• Hadley Beeman (Independent, W3C TAG member)
• Jake Marcinko (PCI Security Standards Council)
• Jan Kowalleck (Independent, OWASP CycloneDX Project Co-Lead)
• Joe Sepi (OpenJS Foundation)
• Paloma Oliveira (Affiliation Sauce Labs)
• Rachel Yager (W3C Evangelist and Chapter Head)
• Shruti Kulkarni (OWASP)
• Tobie Langel (UnlockOpen)
• Will Bamberg (OWD)
• Yan Wang (OPPO)
• Zb Tenerowicz (MetaMask)
• ***** (futureLAB)

Can securing jQuery help secure the Web forward?

See recorded presentation and transcript.

• “1 billion web sites running jQuery - half of that running outdated / unpatched version of jQuery… “
• What are security concerns that cannot be solved by the sandbox?
  • XSS? Or the fact that jQuery may ease bypassing browser sandbox?
  • Lots of data leakage that happens with rendering user input without checks.
• More about older versions of jQuery made it easier to do the wrong things, and how newer versions get things better. Aligning the needs of security with developer experience. An issue with libraries, but also with standards.
• If half of the sites using jQuery are unmaintained, what can we do about it? Probably ties back with supply chain discussion. Lots of XSS and potential new dangers not getting fixed. No automatic updates with front-end libraries.
• What would be the difference between having features built-in in JavaScript vs. doing that as part of a framework? Which layer needs to be improved?
• We have to make a distinction between the breath of deployment and where people actually spend time. Fixing security problems for the 100 most viewed web sites on the planet has a huge impact. There’s a long tail, for sure, but there is a huge concentration, regardless of whether we like it or not. We can look at libraries and frameworks as accelerators for security browser features.

Documentation for web security education

See recorded presentation and transcript.

• Lead a workshop or taskforce?
• Create content outline for the 4 quadrants?
• Do additional surveys? (or user interviews?)
• Thinking about how security best practices can be added to MDN pages where possible - instead of reading about the thing in one place and then how to secure the thing in another place…
  • Two: You actively want to learn about security
  • You implement a thing, and looking at best practices related to that, e.g. a form
• Nothing for the reference quadrant; interesting to map the developer survey concerns to this quadrant model…
• How to protect you as a developer against yourself? That probably requires a tutorial…
• “What are the key security concerns that developers should be aware of?” ← would like to see
• Most people are not security experts and we need to bridge that gap.
• Even a check list “the 5 things you need to be careful about” ← would be a huge improvement
  • Have to think about responsibilities and personas.
• How to link with regulations?
• Debunking scamming techniques. End-user perspective.
• Any initiative to provide documentation other than in written form? Developers are more and more looking into videos. More expensive to produce, for sure.
  • Currently not looked at by OWD

Roadmap planning for a JavaScript security framework

See recorded presentation and transcript.

• “We’re the experts but we have troubles understanding what to do” feeling. That’s part of the problem. We need to be more confident on our abilities.
  • Experience is that software security community uses a lot of terms and acronyms that can be opaque to others. Lots of gatekeeping as well. Quite a learning curve! Need more web developers to think more about security.

Open Discussion

• New #security Slack channel created in W3C’s Slack instance. Will be used to convey workshop news and next steps.
• Compliance, regulatory. How much should we be thinking about letting developers know about existing regulatory aspects?
• Scamming - [documenting the harms that people are subject to by scammers …]
• Certification – information managers need to know about – how it relates to audit… CISA…
  • Folks who are less technical need to be able to ask for these things, have their teams dedicate time on this.
  • Subject matter experts need to make the case.
  • End-user impact that speaks to an audience that cares about them. Different facets of the same problem, so far disconnected but getting more aligned. Useful to document the end-user perspective at the same time as we document the developers perspective (how to use CSP).
• Deliverable: Inform policy makers. That’s a takeaway. EU cookie law was created as a response to cookies that tech community created. Same thing for GDPR. We have the ability to tell the story from an end user perspective, which is something that policy makers are keen on hearing. We have a potentially powerful impact to make.
• About jQuery’s security efforts and outdated versions.
  • Claim about why this happens: several sources that you could get jQuery from. Hosted version or through CDNs. Hosting is used to be in control. Which means that I need to update it myself, e.g., through a package manager. Dependency tracking can tell you whether you have vulnerabilities. People using CDNs have no idea. Version is included in the URL, e.g., 3.7.1. No way to request 3.7, or 3.7 or later to get security updates.
  • Possible solution: allow such queries.
  • jQuery was doing that but backed out of it because it was creating havoc. It requires investment from developers that is bigger. Theoretical idea is great, practically speaking, it does not work.
• Nowadays, developers do not want to do security. But they have to. If they don’t, no one else will.
  • Giving developers the tools that they need is key.
  • “If I don’t parameterize my queries, who will?”
• Developers using IDEs, linters, etc… ← tools that remind you as you code
• Building the assertion libraries…
• On documentation side - show code snippets; if you don’t see the correlation between your line of code and the issue it causes for the end user, it causes a problem…
• Connection with policy makers & managers - great but we should not rely on managers - boot camps and academia - need to teach security.
• Tool for easily scanning your page - one button to scan your page for security issues… OWASP - attack surface tool.
• jQuery problem specifically - what do with the existing problem - at the scale of jQuery’s availability - have a mechanism to forcefully update jQuery - a company that is rolling out a browser or add-on could force update - use SRI - to identify specific vulnerable copy of jQuery - and serve a copy…
  • Some vulnerabilities got fixed in browsers. Not worth updating if browsers no longer have the vulnerabilities.
  • Some vulnerabilities may not affect the page. Forcing update is tough.
• Context of small agencies; developers are rare and expensive, small companies struggle to bringing in enough income to pay developers; most companies don’t invest in keeping stuff up-to-date. If nothing pays for updates, no incentive to make them and problems may arise.
  • Many website-owners do not understand, that code needs maintenance
    • they only demand and pay for work, which results can actually be seen
    • as long as their website works and they are happy with its functionality and its design, they do not see any reason to demand further work on it
    • if there is no demand, there is no supply or interest (results in very low interest in replacing deprecated jQuery versions or the like)
    • Even if a website-owner is interested in keeping a project up-to-date and is willing to invest - there is no way for regular people to check the quality of the maintenance they pay for
    • A further problem is, that occurring problems might also provide an additional source of income: If a website gets hacked, or a spam-attack or another kind of attack takes place, website-owners have an interest in fixing the problems on their website and are ready to pay for updates, cleanups or maybe even for a completely new website.
  • Making security features understandable to regular developers should help not requiring additional work force.
  • Also, developers may be building products for customers that are in a more regulated space that will require a more thorough security practice.
  • If you implement best practices, you’re going to be legally protected in case things go wrong, which helps push towards spending time on security. Creates a push towards adopting best practices, we’re really fast going there. Question is: what best practices are we talking about? Some in the US. Are there in the EU? Groups like people in the workshop can have a lot of impact. Now’s the time!
  • Example of RFI from the federal government for asking about input regarding security practices.
  • CRI in the EU. Already call to define what it actually means

Next Steps

• Very hard to get information from a developer perspective that is both correct, current, and complete. A platform that would provide this knowledge would be valuable. A curriculum.
  • OpenJS plans to develop JavaScript training. Feedback on scope would be useful.
• Collaboration: one required next step would be talking
• Adding “security considerations” as part of standard template for MDN pages - same place in the page for each page;
• Documenting user costs. Implications.
• Documentation can also be used by mentors in schools.
• Need to prioritize things depending on the impact they have on end users. Focus on harm that is being made. Focus on user needs!
• Workshop report will be prepared and circulated. Input welcome! Such reports are always useful.
• Collaboration between communities are always useful.
• Another thought, that arised after the workshop has ended: It would be great, if website- and webapp-owners could also be more included in security-topics:
  • Demand and supply go hand-in-hand, this also applies to the web => not only developers but also website-owners play a role
  • Awareness of the importance and value of maintenance should get spread
  • Tools or services to check the security and the state of maintenance should be available, accessible, easy-to-use, and affordable
    • For checking if maintenance is required or if security-issues must be solved
    • Similar to SEO-analyzing tools