The futile war between Native and Web
In theory browsers can support any kind of platform-related function, right? In practice this has proved to be wrong although the reasons vary from lack of standards for the platform feature to support, to security and trust-models models involving other parties than the user and the site connected to. In addition, the concept of trusted web code still doesn't exist and personally I doubt that it will be here anytime soon, if ever. Permissions do not address code trustability either. Yet another difficulty is that the browser vendors and the market occasionally have diverging interests and priorities, leaving the latter lot in a very unfavorable situation w.r.t. innovation. To avoid TL;DR. A browser can do things the native level cannot but this is equally applicable the other way round so an obvious solution is burying the hatchet and rather try to figure out how these great systems could work in concert! Here is a concrete suggestion: https://lists.w3.org/Archives/Public/public-web-intents/2015Feb/.html Sincerely, Anders Rundgren WebPKI.org
Re: The futile war between Native and Web
In practice this has proved to be wrong although the reasons vary from lack of standards for the platform feature to support, I find there are two problems with browser based apps. First is the security model, and second is anemic security opportunities. For the first point, Pinning with Overrides (tools.ietf.org/html/draft-ietf-websec-key-pinning) is a perfect example of the wrong security model. The organizations I work with did not drink the Web 2.0 koolaide, its its not acceptable to them that an adversary can so easily break the secure channel. For the second point, and as a security architect, I regularly reject browser-based apps that operate on medium and high value data because we can't place the security controls needed to handle the data. The browser based apps are fine for low value data. An example of the lack of security controls is device provisioning and client authentication. We don't have protected or isolated storage, browsers can't safely persist provisioning shared secrets, secret material is extractable (even if marked non-extractable), browsers can't handle client certificates, browsers are more than happy to cough up a secret to any server with a certificate or public key (even the wrong ones), ... For medium and high value data, that usually leaves hybrid and native apps. With a high value data and a native app, there's usually non-trivial residual risk that usually forces the app into risk acceptance. Yet another difficulty is that the browser vendors and the market occasionally have diverging interests and priorities, leaving the latter lot in a very unfavorable situation w.r.t. innovation. Guys like me don't have a dog in that fight. We don't care about the bells and whistles. We just want to place security controls commensurate with the data sensitivity level. Jeff On Sun, Feb 15, 2015 at 6:19 AM, Anders Rundgren anders.rundgren@gmail.com wrote: In theory browsers can support any kind of platform-related function, right? In practice this has proved to be wrong although the reasons vary from lack of standards for the platform feature to support, to security and trust-models models involving other parties than the user and the site connected to. In addition, the concept of trusted web code still doesn't exist and personally I doubt that it will be here anytime soon, if ever. Permissions do not address code trustability either. Yet another difficulty is that the browser vendors and the market occasionally have diverging interests and priorities, leaving the latter lot in a very unfavorable situation w.r.t. innovation. To avoid TL;DR. A browser can do things the native level cannot but this is equally applicable the other way round so an obvious solution is burying the hatchet and rather try to figure out how these great systems could work in concert! Here is a concrete suggestion: https://lists.w3.org/Archives/Public/public-web-intents/2015Feb/.html
[Bug 28031] New: Does the destination insertion points include Shadow IP without older trees?
https://www.w3.org/Bugs/Public/show_bug.cgi?id=28031 Bug ID: 28031 Summary: Does the destination insertion points include Shadow IP without older trees? Product: WebAppsWG Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P2 Component: Component Model Assignee: dglaz...@chromium.org Reporter: kojii...@gmail.com QA Contact: public-webapps-bugzi...@w3.org CC: m...@w3.org, public-webapps@w3.org From comment 150 of bug 23887. Consider a tree: A SR SIP B The question is does B's destination insertion points[1] include the SIP? The argument to include is that 3.3 Shadow Insertion Points[2] defines such SIP as a valid shadow insertion points. The argument not to include is that the definition of destination insertion points in 3.4 Distribution Results[1] says: destination insertion points, which consists of insertion points to where the node is distributed But the sentence looks a bit confusing regardless of this issue, because a node is distributed only to the final destination point, so the destination insertion points being a list of node *is* distributed looks inaccurate. So two suggestions here: 1. Fix the 3.4 wording from is to may be. It's inaccurate anyway. 2. Discuss whether such SIP should be included, and if we conclude not to, change the definition of 3.3 Shadow Insertion Points[2]. Note that this issue can affect more than event path, such as Element.getDestinationInsertionPoints[3]. [1] http://w3c.github.io/webcomponents/spec/shadow/#dfn-destination-insertion-points [2] http://w3c.github.io/webcomponents/spec/shadow/#shadow-insertion-points [3] http://w3c.github.io/webcomponents/spec/shadow/#extensions-to-element-interface -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 28031] Does the destination insertion points include Shadow IP without older trees?
https://www.w3.org/Bugs/Public/show_bug.cgi?id=28031 Hayato Ito hay...@chromium.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WONTFIX --- Comment #1 from Hayato Ito hay...@chromium.org --- But the sentence looks a bit confusing regardless of this issue, because a node is distributed only to the final destination point I'm afraid that's the root cause of your confusing. A node can be distributed to multiple insertion points. The final destination point is just one of that. I think the spec is clear for that. -- You are receiving this mail because: You are on the CC list for the bug.
