Hi all, Except to define what permissions are in crosswalk, some confirmation mechanism (such as user consent or permission warning) need to make clear prior to usage. We also need define what permissions need user consent or permission warnings during the installation or execution of application.
1. For Tizen, The privileges need user consent such as below. Details can be got from Tizen 2.2 specification A 3.1. Privileges Privilege Level User Consent http://tizen.org/privilege/bluetooth.admin Public Needed http://tizen.org/privilege/location Public Needed 2. For Chrome, the permission warnings is descripted https://developer.chrome.com/extensions/permission_warnings.html. What's your opinion? Best Regards Zhang Xu > -----Original Message----- > From: crosswalk-dev-boun...@lists.crosswalk-project.org > [mailto:crosswalk-dev-boun...@lists.crosswalk-project.org] On Behalf Of > Gustavo Sverzut Barbieri > Sent: Saturday, October 12, 2013 2:18 AM > To: Ketrenos, James P > Cc: crosswalk-dev@lists.crosswalk-project.org > Subject: Re: [Crosswalk-dev] Crosswalk API permissions and requirements > > On Fri, Oct 11, 2013 at 10:43:11AM -0700, Ketrenos, James P wrote: > > A Crosswalk value is "write a Crosswalk app, and it runs on every > > platform Crosswalk supports" --NOT-- "write a Tizen WRT app, or a > > Chromium app, or a Mozilla app, and Crosswalk will run it." > > > > As such, it seems that this discussion has taken wrapping of > > permissions in the opposite direction of the intent for Crosswalk. The > > mapping isn't from CRX => Crosswalk, WGT => Crosswalk, APK => Crosswalk > -- but the reverse. > > While this theory is good, and easier, it's not realistic given that others > exist > while we don't. Take tizen, for instance, to get ourselves in that platform by > default we must support what they do, which includes their format. Once we > have awareness and reasonable application base we may opt to phase out > support for those formats. > > The parser/extractor can be either in Crosswalk binary itself, loading stuff > on > demand and converting on the fly, or take a platform step to convert to our > format. The problem to convert it is to handle stale files on the system and > the > possibility of getting out of sync after updates -- they are all manageable > if done > right, but may be cumbersome to maintain. AFAIR the extra platform step to > convert to crosswalk-native was the desired method by crosswalk developers in > the beginning, so it was already handled in a way or another. > > In practice, with your suggested case, we'll have to develop our own > infrastructure (C++ classes I said). To populate these classes based on an > input > file is where we're diverging. It seems you just want to support one input > file > that is crosswalk-specific. I think with minimum extra effort we can support > all > of them, and I suggest we don't start with our own format, instead we can > start with Tizen's. > > -> How can we decide with path to follow? > > Being strict about the last part, it is incorrect to say "but the reverse". > Since > we're not mapping Crosswalk to CRX either, we're just supporting Crosswalk in > the same environment CRX is supported, as you write below: > > > > The developer writes a Crosswalk application, and Crosswalk utilities > > map those permission requests to the appropriate OS target platform's > > permission scheme so that the Crosswalk application, when installed, > > results in the appropriate platform security controls being configured > > for their application. > > This was clear to me, but thanks to highlight that. Eventually someone didn't > understand that part. > > We should always map the abstract permissions we invent for Crosswalk to > concrete implementation of the runtime platform. Like in Tizen we'll have to > apply all the sandboxing and SMACK rules to the extension process. > > -- > Gustavo Sverzut Barbieri > Intel Open source Technology Center > _______________________________________________ > Crosswalk-dev mailing list > Crosswalk-dev@lists.crosswalk-project.org > https://lists.crosswalk-project.org/mailman/listinfo/crosswalk-dev _______________________________________________ Crosswalk-dev mailing list Crosswalk-dev@lists.crosswalk-project.org https://lists.crosswalk-project.org/mailman/listinfo/crosswalk-dev
