2009/6/2 Jonas Sicking <[email protected]>: > On Tue, Jun 2, 2009 at 7:28 AM, Marcin Hanclik > <[email protected]> wrote: >> Hi Scott, >> >> In BONDI we have discussed the (has/request)Feature() for some time. >> http://bondi.omtp.org/1.0/security/BONDI_Architecture_and_Security_v1.0.pdf, >> section 4.3 >> >> A few points for further discussion: >> 1. feature (at least in BONDI) is an abstract thing, not just one function. >> So hasFeature() is simply optimized checking procedure. If you check for a >> feature and discover that it is available, you may/should/must assume that a >> set of functions is available. Otherwise, you have to check each function >> individually and basically you cannot assume that if one functions is >> available, then the other is as well. >> >> 2. requestFeature() adds dynamism to the Website content. Widgets express >> their dependency statically by <feature>. >> http://bondi.omtp.org/1.0/security/BONDI_Architecture_and_Security_Appendices_v1.0.pdf >> B.2 specifies more details. > > Doesn't the requestFeature() make at least the security benefits of > <feature> moot? In Another thread Marcos stated that one of the > benefits of <feature> was that if a widget gets exploited, the > exploited code couldn't get access to any features that the widget > hadn't enabled using <feature>. However this does not seem to be true > if the exploited code could simply call requestFeature() first, and > then use the feature.
Yes, that was the design. If requestFeature() is introduced, <feature> is basically useless. -- Marcos Caceres http://datadriven.com.au
