W3C Standartizes DRM, EFF Resigns

World Wide Web Consortium (W3C) has recently voted in favor the DRM standard.  Electronic Frontier Foundation (EFF) has been fighting against it, now lost, and resigned from the W3C.  Read more:

It is a tragedy that we will be doing that without our friends at the W3C, and with the world believing that the pioneers and creators of the web no longer care about these matters.

Effective today, EFF is resigning from the W3C.

Thank you,

Cory Doctorow
Advisory Committee Representative to the W3C for the Electronic Frontier Foundation

Wow!  This is big.  And bad.  Like breaking bad.

DRM will die one day.  But it looks like it will take a few more years, court cases, and such to help it go into the ground.  We could haven spent all this effort on something much more useful and productive.

BeEF – Browser Exploitation Framework

BeEF is a browser exploitation framework.

BeEF is short for The Browser Exploitation Framework. It is a penetration testing tool that focuses on the web browser.

Amid growing concerns about web-borne attacks against clients, including mobile clients, BeEF allows the professional penetration tester to assess the actual security posture of a target environment by using client-side attack vectors. Unlike other security frameworks, BeEF looks past the hardened network perimeter and client system, and examines exploitability within the context of the one open door: the web browser. BeEF will hook one or more web browsers and use them as beachheads for launching directed command modules and further attacks against the system from within the browser context.

On React and WordPress

I have a great deal of respect for Automattic in general and Matt Mullenweg in particular.  They have done an amazing job with WordPress, which is now used by more than a quarter of all websites.  But they are also a great example of how companies can work in the Open Source software space.

It’s not all just business.  Automattic raises the ethics bar quite high.  And today there is an excellent example of how they do it.  Check out this blog post by Matt on why WordPress will be moving away from the React JavaScript framework developed by Facebook:

I think Facebook’s clause is actually clearer than many other approaches companies could take, and Facebook has been one of the better open source contributors out there. But we have a lot of problems to tackle, and convincing the world that Facebook’s patent clause is fine isn’t ours to take on. It’s their fight.

Respect!

PHP limit on maximum form fields

We had an interesting issue to debug at work today.  One of the screens in our application features a form with a whole lot of checkboxes.  It’s in the access control module, where the administrator of the system can manage user permissions for each module of the system.  Here’s the screenshot just to give you an idea.

This is not the pretties user interface (yet), but it sort of works.  Every module can be expanded or collapsed, and inside each modules all checkboxes can be checked and unchecked easily.

The problem that we had wasn’t user interface related.  It was something else.  The number of modules and permission checkboxes varies from system to system.  This is based on each particular system setup.  Now, on some of these systems, it was reported that some permissions are not being saved.

The problem is not new, but it was slowly escalating with more and more clients reporting it.  So, today we dived into it and found the cause of it.   Since PHP 5.3.9 there is a new runtime configuration setting: max_input_vars, with default value of 1.000:

max_input_varsinteger

How many input variables may be accepted (limit is applied to $_GET, $_POST and $_COOKIE superglobal separately). Use of this directive mitigates the possibility of denial of service attacks which use hash collisions. If there are more input variables than specified by this directive, an E_WARNING is issued, and further input variables are truncated from the request.

So, on the systems, where the form contains more than a thousand checkboxes, PHP was only bringing in the first thousand and skipping the rest, causing not all permissions being saved properly.

Increasing the value in runtime configuration is one way to solve it.  But since we have a rather dynamic system and don’t always control the runtime configuration (client hosting), we opted for a different solution.  As per this StackOverflow thread, it’s a much more future-proof solution to combine the values into a single field.  Either simple concatenate, or JSON-encode the values on form submit, and send them all as a single field value.  Then just split or JSON-decode on the server before processing and you are done.

P.S.: The extra bit that made the troubleshooting so much more difficult was that for some reason we were not seeing the PHP warning in logs.