Re: Reminder - trust & permissions meeting 3-4 September, Paris

Hi Dave,

On 16 Jul 2014, at 12:18, Dave Raggett <dsr@w3.org> wrote:

> p.s. I've added a link to the draft white paper I am writing surveying native, hybrid and web based platforms and invite your comments and corrections, see:
> 
>   http://www.w3.org/2014/05/wp-trust-permissions/Overview.html

Thanks for the nice draft white paper. I suggest the paper focuses on the most popular platforms and frameworks (because this allows us to gather real-world feedback more easily), and discusses only those emerging projects that employ novel approaches to addressing trust and permissions (as they may bring new data to the discussion).

Here are some comments and pointers, broken down by the top-level sections:

* Native Platforms

I believe the reason for Windows Runtime disabling some Web APIs is mainly due to security (document.write, innerHTML etc.) or UI/UX (alert, close etc.) reasons, and not due to the standards-compliant mode being used by the rendering engine. This is actually rather similar to how Chrome Apps [1] disable some APIs that are exposed to Chrome the browser by default.

This seems to suggest APIs should be designed in such a way they can be gated behind e.g. a promise.

* Cross Platform Frameworks

This section could be limited to frameworks that provide new input relevant to the problem statement (how to "approach the challenge of addressing trust, especially for capabilities requiring elevated permissions”).

Or perhaps the most prominent projects from this section (PhoneGap ...) could be even integrated into the next section. Some of the material in this section could be also moved to an Appendix section.

* Web-based Platforms

I’d look into Chrome Apps as well in this section, unless it is considered too similar to Firefox OS so that there’s no new information re permissions and trust problem space. I recall seeing articles on porting from one to another, suggesting that’s rather trivial for *trivial* apps. I guess when we get to nasty edge cases and more complex apps, the portability between the two becomes a real issue, as usual.

I’d also consider dropping WAC 2.0 for the reasons Marcos mentioned unless new information re user consent resurfaces.  My recollection is the system was basically Widgets + XML DigSig + WAC APIs with modal session prompts unless the widget was signed.

Re Cloudberry, the relevant tidbit is (from the article): "permission-based security model that restricts the use of device-specific functionality (such as device APIs) to only those applications from trusted domains”. AFAIK there very little publicly available information on the project, so the usefulness of this project in the context of this white paper is questionable given very limited public data.

To answer your open questions in the Tizen section, see [2] for features and privileges. Tizen runtime and system URLs are enums used by certain Tizen APIs such as System Information, and as such, not relevant to this paper. 

Settings are proprietary config.xml extensions, some of which are now being standardized in the W3C Manifest spec (e.g. orientation).

* Future Directions

I think the "Permissions UI & Necessary API” [3] thread had some input and ideas to add to the observations (or, perhaps you already combed through the thread?).

Another recent thread that may have input to this paper is "Proposal: Prefer secure origins for powerful new web platform features” [4].

Generally I feel that as long as we’re involving the user in the process -- and I think we should — input from UI/UX and usability experts would be very welcome too re these problems. Sometimes conducting user studies with mockups and prototypes is very helpful.

Thanks,

-Anssi

[1] https://developer.chrome.com/apps/app_deprecated
[2] https://developer.tizen.org/dev-guide/2.2.1/org.tizen.web.appprogramming/html/app_dev_process/editing_api_features.htm
[3] http://lists.w3.org/Archives/Public/public-sysapps/2014May/0004.html
[4] http://lists.w3.org/Archives/Public/public-webappsec/2014Jun/0222.html

Received on Wednesday, 6 August 2014 14:23:09 UTC