IMHO more than marketing it is important not to lose/disrupt customers and people that has been using wicket for MANY years. Even less when 9.x has been waiting to be released for quite some time. e.g. for my current customer I've been keeping a branch of application that is 9.x. A few months ago there was a tlak that 9,x will be out sooner than later, I haven't updated that branch for a while now. I'm afraid is some disruptives changes are rolled out now this will discourage people to migrate. I haven't been following development of CSP in detail, but if there exists the risk that this will brake existing applications, at this stage of releasing 9.x, I would say leave it for 10.x
On Tue, Jan 21, 2020 at 10:10 PM Emond Papegaaij <emond.papega...@gmail.com> wrote: > In my opinion marketing is very important, but I think it is more > important to have this option enabled on as many applications as > possible. Enabling this by default will give this a much wider reach > than just having it available. Most importantly, it will be enabled on > new applications, guiding the developer into making a more secure > application. If it is not enabled by default, I doubt many developers > will enable it on their new application. For that you have to look > into the guide, see that it's available and then enable it. > > For existing applications, I think many will either disable it or at > least configure CSP to be less strict. But still, if this triggers > just a few to make their application work with CSP, I'd consider that > a win. > > IMHO as developers of a popular web framework it is our duty to work > on a secure internet and push these features actively. > > Emond > > On Tue, Jan 21, 2020 at 3:07 PM Andrea Del Bene <an.delb...@gmail.com> > wrote: > > > > I agree with the marketable value of CSP but I don't think it will lose > > appeal if we make it disabled by default. As I said, I agree to > eventually > > enable it by default, but I don't think the time is ripe yet. > > > > On Tue, Jan 21, 2020 at 2:27 PM Martijn Dashorst < > martijn.dasho...@gmail.com> > > wrote: > > > > > Not sure if enabling it by default is a bad thing when you can, as per > > > migration guide, disable it with one statement in your > > > WebApplication#init(). > > > > > > Also, when looking at marketable features, having CSP, and enabled by > > > default, is something that publications will take notice of. Just like > > > being Jakarta EE prepared: > > > > > > "Deliver Secure Future Proof Web Applications with Apache Wicket 9 > > > > > > Apache Wicket 9 delivers Content Security Policy (CSP) protection > > > out-of-the-box, protecting web applications against a variety of web > > > based attack vectors. CSP is a cross-browser technology that prevents > > > several attacks on web applications by limiting the .... > > > > > > With the adoption of the Jakarta EE standards, Apache Wicket 9 is one > > > of the first Java frameworks prepared for the new future of enterprise > > > Java. <insert blurb about licensing etc> > > > " > > > > > > Martijn > > > > > > On Tue, Jan 21, 2020 at 2:00 PM Andrea Del Bene <an.delb...@gmail.com> > > > wrote: > > > > > > > > IMHO forcing users to adopt a new potential breaking feature is a > > > > mistake. We should wait for a wider interest in CSP to enable it by > > > > default. Don't get me wrong, I'm not underestimating the importance > of > > > > this feature which is a fantastic tool to ensure security. > Nonetheless, > > > > I believe that forcing users to comply with it will only have the > effect > > > > of upsetting them. > > > > > > > > On 1/21/20 1:27 PM, Emond Papegaaij wrote: > > > > > On Tue, Jan 21, 2020 at 12:36 PM Martin Grigorov < > mgrigo...@apache.org> > > > wrote: > > > > >> On Mon, Jan 13, 2020 at 11:15 PM Emond Papegaaij < > > > emond.papega...@gmail.com> > > > > >> wrote: > > > > >> > > > > >>> I've discussed this with our unit manager, and got permission to > > > > >>> donate our CSP code to Wicket. I think a strong, out of the box > CSP > > > is > > > > >>> a killer feature to have for Wicket 9. Not many frameworks can > match > > > > >>> this. For this, I would like to continue working on the following > > > > >>> parts: > > > > >>> * Remove all inline styling and JS from Wicket. I will need some > help > > > > >>> with this, especially the Form related code. > > > > >>> * Make sure all examples work find with a strong CSP enabled > > > > >>> * Add the CSP code to Wicket and provide several presets (strong, > > > > >>> unsafeJsAndStyling, reportOnly, disabled) > > > > >>> * Enable CSP with the strong preset by default > > > > >>> > > > > >> I think this will break all applications which migrate from > earlier > > > version. > > > > >> I like that Wicket will be more secure by default but > > > > >> 1) most people do not really care about CSP (yet) > > > > >> 2) last time when I tested CSP it was behaving differently on > > > different > > > > >> browsers. I hope it is better now since only Firefox is not based > on > > > > >> Chromium. According to https://caniuse.com/#search=csp IE11 > might be > > > > >> problematic. > > > > >> > > > > >> Whatever we choose as default we should document how to switch it > on > > > and > > > > >> off. > > > > >> The user guide needs to be updated! > > > > >> > > > > > Yes, enabling a strict CSP will probably break all existing > > > > > applications on upgrade. But the upgrade will do that anyway (I > had to > > > > > fix quite a few compilation errors to get my app starting again). > We > > > > > do have to document this in the migration guide. Switching to an > > > > > unsafe CSP or disabling it entirely is just one line of code. > That's a > > > > > lot less work than fixing the compilation errors. I hope enabling > CSP > > > > > by default will make more people aware of this browser feature. At > > > > > Topicus we intent to fix our applications to work with the strict > CSP, > > > > > probably not directly after migrating to 9, but Wicket 9 is a good > > > > > push in this direction. > > > > > > > > > > It is true that support is lacking for some browsers. A browser > that > > > > > does not support CSP at all (like IE11) is not hindered by it > either. > > > > > It becomes more problematic when a browser does not support the > > > > > directives used (like strict-dynamic). This might cause issues and > we > > > > > need to test that and change the CSP to make sure it works in those > > > > > browsers as well. IMHO as a framework it is our job to set an > example > > > > > and show how we think this is done best. When a user thinks the > gained > > > > > security is not worth the pain, he/she can disable it and hope for > the > > > > > best. > > > > > > > > > > Best regards, > > > > > Emond > > > > > > > > > >>> I've already started the work on the 'csp' branch. On this > branch, > > > > >>> I've also migrated all but the servlet API to the jakarta > namespace. > > > > >>> > > > > >>> Best regards, > > > > >>> Emond > > > > >>> > > > > >>> On Sun, Jan 12, 2020 at 8:18 PM Emond Papegaaij > > > > >>> <emond.papega...@gmail.com> wrote: > > > > >>>> Searching through our Jira, I've found WICKET-6687, filed by > Andrew. > > > > >>>> He already pinpointed several places that break with a strict > CSP > > > > >>>> enabled. I'm going to convert that bug into a task (we do not > have > > > > >>>> epic) and create new bugs for all issues in that ticket. That > should > > > > >>>> make it easier to track progress. > > > > >>>> > > > > >>>> Best regards, > > > > >>>> Emond > > > > >>>> > > > > >>>> On Sat, Jan 11, 2020 at 10:31 PM Emond Papegaaij > > > > >>>> <emond.papega...@gmail.com> wrote: > > > > >>>>> Hi all, > > > > >>>>> > > > > >>>>> For the past few days I've been experimenting with the new CSP > > > > >>>>> features in Wicket 9. I really want to thank Andrew, Sven and > > > Martin > > > > >>>>> for the great work you guys did in making this possible. I'm > > > getting > > > > >>>>> very close to running my application with a very tight and > secure > > > CSP. > > > > >>>>> Unfortunately, some parts of Wicket still use inline styling > and > > > > >>>>> scripting. So far I've found the following two issues: > > > > >>>>> > > > > >>>>> * hidden components with setOutputMarkupPlaceholderTag(true) > have > > > > >>> display:none > > > > >>>>> * Forms render inline styling and javascript in some cases to > > > improve > > > > >>>>> submit handling > > > > >>>>> > > > > >>>>> I think we should try to fix these before Wicket 9 is > released. I > > > will > > > > >>>>> continue to debug our application to see if there are more > places. > > > > >>>>> > > > > >>>>> At Topicus we wrote a IRequestCycleListener that applies the > CSP > > > > >>>>> automatically to every request via HTTP headers. The API makes > it > > > easy > > > > >>>>> to configure the CSP. I've added support for the nonce as > well. It > > > > >>>>> uses a new nonce for every request, which should be more secure > > > than a > > > > >>>>> nonce bound to a session. I'll discuss with my employee next > week > > > if > > > > >>>>> we can donate this code to Wicket. > > > > >>>>> > > > > >>>>> Best regards, > > > > >>>>> Emond > > > > > > > > > > > > -- > > > Become a Wicket expert, learn from the best: http://wicketinaction.com > > > > > > > > > -- > > Andrea Del Bene. > > Apache Wicket committer. > -- Regards - Ernesto Reinaldo Barreiro
