@maxrolon Thanks for this.

The only problem I can imagine would be if rawCookie.match(/secure/i) ended up adding 'secure' to cookies where it shouldn't - eg: because 'secure' is a common english word.

Could you match more accurately? for example by checking if it's the last item in the string or something?

given the size of the Browsersync user-base and hence the possibility of breakage, another option would be for me to introduce a callback handler as an option that gives direct access to the cookie after processing.

Yea for sure, that's a good call out. My primarily concern there is that the current solution will fundamentally not work with SameSite=None cookies as browsers gradually update their rejection of insecure SiteSite=None cookies. Perhaps we can update the code to be acutely specific to this use case and add some tests to support it?

Related to this feature I believe: https://chromestatus.com/feature/5633521622188032

@maxrolon yes sounds good to me, would you like to attempt to do so? Parts of the codebase are many, many years old, but there's a good testing setup that you'd be able to work in a TDD way

@maxrolon I would also like to offer my time/help if you get stuck

@shakyShane Thanks! I don't think it is gonna be too crazy to implement, just need to carve out a couple hours. Happy to take this on

@shakyShane Add a more specific statement and added a test for this use case, let me know if you have any other ideas to improve this update.