- From: Scott Wilson <scott.bradley.wilson@gmail.com>
- Date: Wed, 8 Feb 2012 13:25:29 +0000
- To: Bronislav Klučka <Bronislav.Klucka@bauglir.com>
- Cc: public-webapps@w3.org
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 > > >
Received on Wednesday, 8 February 2012 13:30:06 UTC