RE: Trusted shims and polyfills

Hi there,

 

Thanks for the proposal, but I believe there’s not really such notion of “trusted” polyfills. Anybody disabling JavaScript on today’s web will face a lot of issues already, I don’t think the use of prolyfills will make it so much worse.

 

Interestingly, Microsoft did develop such “trusted downloads” feature in Internet Explorer (called SmartScreen) to avoid to display the “are you sure you want to open this file” dialog for trusted or broadly-downloaded files. This implies digital signature or, indeed, hashing of known files. 

 

There’s nothing preventing the team at NoScript to implement such notion of “trusted script” or “trusted script providers” by collecting data on which scripts are “manually authorized” by its users and by building a “trusted scripts” database that would be pre-authorized to run.

 

However, I don’t see how we could help to build something like that, we’ve no workforce to maintain a “secure store” of p(r)olyfills, and we’re missing the security experts, too.

 

 


De : Fred Andrews
Envoyé : ‎11‎ ‎décembre‎ ‎2012 ‎02‎:‎01
À : public-nextweb@w3.org
Objet : Trusted shims and polyfills



Could the group please consider the possibility of trusted shims and polyfills so that even extensions such as noscript might still allow trusted polyfills to be used and that browsers might implement a mode between JS-enabled and JS-disabled that allows only trusted polyfills.  There is a great need to experiment with interactive declarative extensions for users wanting to work with JS-disabled and the work of this group might be able to help.  For example, the topic of interactive menus has come up again recently on the WHATWG list and I think it would help the development of the web if content authors could experiment with designs.

One option might be for the UA to store a hash for the resources to identify them.

It might be expected that a polyfill is common code among many webpages, and could the group consider methods to avoid redundant storage of such resources, and also how they could work well offline.  Could a polyfill be loaded and managed as a browser extension, with a meta tag declaring the need for the polyfill?

With a lot of experimentation going on, there is bound to be some conflict, such as extensions that want to use the same attribute or element name.  Perhaps some thought could be given to ways this group could help manage such conflict - guidelines, etc.

cheers
Fred