On 8 Feb 2012, at 10:31, Bronislav Klučka wrote: > > > On 8.2.2012 1:06, Jean-Claude Dufourd wrote: >> On 7/2/12 05:31 , Robin Berjon wrote: >>> The first problem is that of the security model. A lot of smart people have >>> tried to come up with a lot of different solutions here, often involving >>> signatures, policies, intricate user interfaces, etc. I think that's all >>> massively over-engineered. Once you take into account the fact that the >>> number of applications that actually need this level of privilege is only a >>> tiny fraction of the whole, you realise that you can just give up on >>> privilege policies. These are just regular apps: they have unfettered >>> access — period (within the limits of the underlying platform's permissions >>> system naturally). They ought to be harder (and unusual) to install, and >>> maybe should look different, but that's it. We might want to give them >>> strong CSP protection by default to defend against XSS attacks, but that's >>> a detail. >>> >> JCD: I strongly disagree with you there, Robin. I do not see why "installed >> apps" should have more access. "Normal apps" and "installed apps" should >> have the same security model, but "installed apps" may have permanently >> remembered security clearances, and that could be the only difference. >> My proposal is as simplistic as yours, but in the opposite direction. You >> are saying "installed apps" should have all rights, I am saying "installed >> apps" should obey the exact same security as "normal apps". >> In your system, it is dangerous to install an app, but it is very simple. In >> mine, there is no danger, but it is a bit more work. >> Having a difference between installed apps and normal apps is actually >> counter-productive. >> Java tried that for applets, and Java is now gone from the web apps stage. >> Best regards >> JC >> > > Hi > just let me quote from this thread > ------------------------------------------------- > Tim Berners-Lee: > > There of course places where XHR is used and there is no > cross-sitescripting security needed > > 1) in a browser extension > 2) in node.js code trusted apps > > Ian Hickson: > > These aren't the Web, so they're probably out of scope of the CORS and XHR > specs, but Anne can comment if he disagrees. > ------------------------------------------------- > > you are one step ahead, firt we need to define, what we want, whether we want > web platform (remote access to some data and sometimes being able to > manipulate those data with very limited set of APIs) or whether we want > actual multi-platform application framework with browser as run-time > environment, because there is still a lot of missing and there is apparently > disagreement about what should be govern by w3c/whatwg. I'm all for the > second option: full programming environment. But that is the first here (and > with MS extensions to JS APIs in Metro applications...). And without any > distinction between whether the app run locally or whether the UI and data > are accessed remotely or any possible combination of UI and data access > mechanism. > > And the question of granting rights seems to be fairly decided here, > everything potentially dangerous has to be granted by user (e.g. FileSystem > API, GeoLocation), and if UA can provide more granular way of managing data > and rights (not "remove browsing data" and suddenly everything for every page > is gone), we can stick with this principle: HTML, CSS, basic JS is fine... > anything else must be granted.
Right, and so far we haven't had a generic model for how that is done, instead individual specs have had to define it (as in your examples). WebIntents potentially offers a generic model for apps requesting data while keeping the user in the loop, and one that would work both for websites/hosted apps/normal apps and widgets/installed apps/system apps. > > > Brona > > >
