I ❤️ the intention behind this and I think it will benefit the project going forward to have more eyes on proposals. Definitely don't want to sweep your legendary effort of maintaining this under the rug without kudos though.

We're using this gem internally quite heavily (and it's only going to get more use going forward!) so I'm happy to help out where I can - especially with beta testing and new features. If you want collaborators, I'm happy to put my hand up.

I suppose I should have some criteria for adding collaborators. I've never done this before 🐒

• A refactor that can be classified as "more than trivial" would be a nice bar for entry. Past commits included.
  • Cleaning up the way that supported CSP directives are managed across browsers
  • Managing the header cache better (related to ☝️ )
  • The SecureHeaders::Configuration class has gotten a little unwieldy and bleeds concerns
• Implementing #256 (highly requested feature, lots of refactoring opportunities here)
• A demonstration that you're using the more advanced features of the gem (nonces, hashes, named overrides, per-action/generally dynamic policies).
• Demonstration of previous work managing open source projects. Not as a blocker, but as a bonus. This was my first open source project of any significance.

I'll be looking at implementing our CSP within the next couple of months so I'll be feeding our findings back into this as much as possible. My biggest focus is going to be around testing/using functionality like #256 since we will be gradually rolling out our CSP to the user base.

I'm still on board with this approach so I'll push what I can back upstream based on our journey and it's findings.

@jacobbednarz btw I have a WIP PR open for #256: #281

i'm following with great interest 😄

I work a lot with this gem and love it. Would like to help out where I can also. If you want code reviews for PRs, definitely send them over.

Thanks for the interest @jborrey. I think refactoring the ugly parts would be very welcome. I'm not really interested in refactoring myself since it's current state works for every app I'm responsible for. The API is proven and battle-worn.

Based on contributions alone, I think @stve should be the first collaborator if they choose to accept. What say you Steve? We can make reviews a required step.

If someone were to write a shim to shoehorn secure_headers into the preferred API proposed in rails/rails#15777 (HAI @connorshea), they'd be an immediate 3rd contributor.

Based on interest and issue comments, I think @jacobbednarz would be next up.

I want 3 people on this project. I want to back my way out of being the owner here.

Mostly, I want rails to have a default CSP and API. I want this project to turn into a wrapper of something else for non-rails apps. I don't want to turn my back on non-rails apps, but hey, this was basically a rails-only thing for many years.

thanks @oreoshake!

I think it's a very important project, especially considering Rails less than hearty welcome when you proposed merging secure_headers a few weeks ago. Personally, I've been itching to fix up some things from the cookie work - it is working fine there's just a few spots in the code i've been wanting to shore up. I've had some other ideas on improvements as well

I'm happy to continue as a regular contributor but if you want someone to review PRs and comment I would be glad to join as a collaborator as well. I don't have a ton of time for OSS these days (and admittedly some of my other projects where I am a collaborator have suffered from that over the last few years). But I have taken a particular interest in secure_headers.

I'd fully support adding a few more collaborators. In the time i've been tracking this project I've definitely seen a high level of engagement from both @jacobbednarz and @connorshea and I'd give my 👍 on both.

@oreoshake thanks for your work on this project. Sorry for digging up a dead issue but I was curious reading through this thread... from rails/rails#27583 the main blocking complaint I saw for merging this project into Rails was its license. Since the alternative is a lingering API redesign on a 3-year-old patch, I'm curious if the license issue might yield more easily. It looks like twitter has other projects using the MIT license (see https://github.com/twitter/typeahead.js).

The only named copyright-holder on this project is Twitter, Inc. Do you still work there and if so are you able to re-license under MIT?

(Merging this into Rails would be a great way to add a lot more collaborators)

👋 hi @bpo. I no longer work for twitter but I but I'm still in touch with those that run the program. I can see about changing the license.

We shall see #315

License has been updated to MIT.