Re: new meta tags to protect code visibility or immuatbility

Hi!

To troll a bit, but current state of CSP not allowing bookmarklets in
many browsers because the spec does not require them to be allowed go
very well against all nice words about priority of constituencies. So
there are exceptions.


Mitar

On Mon, Feb 22, 2016 at 9:36 AM, Brad Hill <hillbrad@gmail.com> wrote:
> Ahmed,
>
>  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.
>
> https://www.w3.org/TR/html-design-principles/#priority-of-constituencies
>
> "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
> https://chrome.google.com/webstore/detail/xkcd-substitutions/jkgogmboalmaijfgfhfepckdgjeopfhk?hl=en
> to experience the web the way they want to.
>
> Sincerely,
>
> Brad Hill
>
> On Wed, Feb 17, 2016 at 1:22 AM Craig Francis <craig.francis@gmail.com>
> wrote:
>>
>> 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



-- 
http://mitar.tnode.com/
https://twitter.com/mitar_m

Received on Monday, 22 February 2016 23:35:28 UTC