W3C home > Mailing lists > Public > public-webappsec@w3.org > February 2016

Re: new meta tags to protect code visibility or immuatbility

From: Brad Hill <hillbrad@gmail.com>
Date: Mon, 22 Feb 2016 17:36:48 +0000
Message-ID: <CAEeYn8jFg4QGm1LWVUNkuvvsm3tGTEjV8JfmZ6frvo1E26Xpvw@mail.gmail.com>
To: Craig Francis <craig.francis@gmail.com>, Ahmed Saleh <ahmedzs@live.ca>
Cc: "public-webappsec@w3.org" <public-webappsec@w3.org>

 These kinds of proposals come up fairly regularly.  Aside from the
considerable technical difficulties in doing anything effective in this
space, we generally consider them to be a violation of the HTML Priority of
Constituencies which is part of our charter.


"In case of conflict, consider users over authors over implementors over
specifiers over theoretical purity. In other words costs or difficulties to
the user should be given more weight than costs to authors; which in turn
should be given more weight than costs to implementors; which should be
given more weight than costs to authors of the spec itself, which should be
given more weight than those proposing changes for theoretical reasons
alone. Of course, it is preferred to make things better for multiple
constituencies at once."

The right of users to be in control of their browsing experience and their
own computer outweighs the desire of authors to control what users can see
and how they can interact with it.  This protects important rights, for
example, the ability of a blind user to use a screen reader, or the right
to automatically translate content, or just do silly stuff like
experience the web the way they want to.


Brad Hill

On Wed, Feb 17, 2016 at 1:22 AM Craig Francis <craig.francis@gmail.com>

> On 16 Feb 2016, at 14:45, Ahmed Saleh <ahmedzs@live.ca> wrote:
> > Code security is crucial for web development applications. I propose the
> addition of <meta immutable> and <meta protected> to achieve that. The
> first one will prevent data from being mutated by browser plugins or agents
> while the final one will protect code from being exposed to user. These
> mechanisms can help developers protect their code.
> Hi Ahmed,
> I'm just a developer, not part of the W3C, but thought I'd share my views
> on this...
> Marking a page as "immutable" is not going to happen, as plugins
> (extensions) have complete control over the page. I personally don't like
> this happening on my websites, because I have to develop some very secure
> websites, and get annoyed when the users have extensions that inject random
> adverts onto every page (plus all kinds of other messy/insecure
> JavaScript). However I have to accept that the user is (kind of) making
> that decision, and they should be able to do whatever they like... from
> blocking adverts (or "malvertising"), stopping all animations on the page,
> changing the font (e.g. using Open Dyslexic), etc, etc.
> As to "protected", I'm not sure what you are after with this one. If you
> want to stop the user from being able to look at the source code, well that
> isn't going to happen. Trying to enforce those restrictions will only
> create a false sense of security for you (the developer), as anyone could
> run a browser that ignores it, modify their browser to ignore it, or simply
> see/modify the resources being passed over the network (although this might
> require some HTTPS proxying, but that is still possible).
> That said, I do know where you are coming from, and in some ways I would
> like these features myself, but fortunately the web does not work like that.
> Craig
Received on Monday, 22 February 2016 17:37:27 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:54:54 UTC