I think 6 should talk about how the model will handle changes to the
HTML API (say some new element / attribute that allows code execution
or some sort of API to allow data to execute as code)

Cheers
Devdatta

2009/10/29 Brandon Sterne <[email protected]>:
> People generally agree that "content restrictions" are a good idea and
> will be a useful tool for websites.  Various designs have emerged with
> different approaches as to how restrictions should be defined by sites
> and applied by browsers.  I would like to propose a framework with which
> to evaluate and compare the designs to help guide us to a common solution.
>
> The following can be used to determine the costs and benefits of any
> particular model for content restrictions:
>
> 1. How flexible is the model?  How many different use cases does the
> model support?  Does the model allow sites to keep their baseline
> functionality intact?
>
> 2. How easy is the model to implement for web sites? How much
> specialized knowledge is required by admins?
>
> 3. What will the process of developing an appropriate policy look like
> for a given model?
>
> 4. How easy does the model make it for an organization to reason about
> the correctness or optimality of their policy?
>
> 5. How will the model fit into organizations' existing workflows?  For
> example, how easily will organizations who currently perform positive or
> negative testing incorporate the model?
>
> 6. How extensible is the model? How will the model handle future changes
> such as the addition of a new directive, changes in the semantics of an
> existing directive (e.g. script-src now restricts plugins'
> scriptability), or a change in default behavior (inline style now
> blocked by default)?
>
> Please feel free to add any additional criteria that seem appropriate.
>
> Cheers,
> Brandon
>
> _______________________________________________
> dev-security mailing list
> [email protected]
> https://lists.mozilla.org/listinfo/dev-security
>
_______________________________________________
dev-security mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-security

Reply via email to