Re: HTML5's Offline-first Council of Trent
On 2016-03-17 07:12, Richard Maher wrote:
An even more powerful (but also ignored possibility) would be COMBINING the
power
of the Web and App worlds instead of fighting religious wars ("the Web is
great"),
where there are no winners, only lost opportunities.
That's what plugins were for wan't it? And I still cry every night over the
death of Applets :-(
(A single mutliplexed (static) TCP/IP full-duplex connection per user-agent!)
Plugins were deprecated which (IMO) was OK since they had serious security
issues, what's
less satisfactory is removing features without consider some kind of reasonable
replacement.
Several other somewhat related features are currently also subject to
removal/deprecation.
It gets worse...if you are the Web tech leader then you are apparently free
taking
this "shortcut" (some people would rather characterize this as an intelligent
use
of available resources and competences), and get away with it as well:
https://github.com/w3c/webpayments/issues/42#issuecomment-166705416
C'mon Anders, do you blame them?
Well, Google more or less wrote the "Grand Plan" and now they are defecting
from it,
while leaving everybody else with the old (non-working) plan and
_severely_disadvantaged_.
Faced with the intractability, self-interest, and narcissism surrounding
> the IOC^h^h^hW3C Gordian knot, are you really surprised that someone owning
> the implementation will pull out their sword and opt for results over process?
I (naively) thought that maybe _somebody_else_ (with more influence than a
non-member like me), would be interested in taking a closer look at this
powerful capability. I only seek a constructive discussion on what to do now.
Anders
On Thu, Mar 17, 2016 at 1:34 PM, Anders Rundgren <anders.rundgren@gmail.com
<mailto:anders.rundgren@gmail.com>> wrote:
On 2016-03-17 06:00, Richard Maher wrote:
Hi Patrick (Congratulations on today) Technical Point follows: -
On a merit-based resource allocation basis, the two most fundamental,
essential,
> and absolutely necessary HTML5 Web-App feature enhancements are: -
1) Background GPS device/user tracking support
2) Push API 1:M broadcast capability
These are enabling technologies that will catapult HTML5 Web Apps into
the
> Native App heartland and single-handedly alter the development-tool and
deployment
> strategies for Mobile App vendors around the world.
An even more powerful (but also ignored possibility) would be COMBINING the
power
of the Web and App worlds instead of fighting religious wars ("the Web is
great"),
where there are no winners, only lost opportunities.
It gets worse...if you are the Web tech leader then you are apparently free
taking
this "shortcut" (some people would rather characterize this as an
intelligent use
of available resources and competences), and get away with it as well:
https://github.com/w3c/webpayments/issues/42#issuecomment-166705416
Anders
The reason these features do not appear on the W3C horizon is that they
show-case online-first and are anathema to the Offline-First Mafia that is
currently setting the agenda and feathering its own nest.
Technically, I have to admit to having absolutely no idea how a W3C
performance review would be conducted or how ROI on a given contributor's input
could be measured. I am a simple man who just needs a couple more tools in the
box in order to deliver the killer Web Apps my users are begging for.
Where I come from, and certainly from my experience in London finance,
it's all about getting the job done! You can have two heads and be the most
obnoxious Maher in the world but you're paid to do a job and get around the Sir
Humphrey Appleby speed humps on the road the progress in order to do it.
I'm not here to make friends or see how many followers I can get on
Twitter, and I apologize for being the only one without an original selfie of
myself looking wistfully off camera, but I'm motivated by results and not
married to the process.
HTML5 - Web Apps "The journey is *NOT* the destination!
On Wed, Mar 16, 2016 at 5:58 PM, Patrick H. Lauke <re...@splintered.co.uk
<mailto:re...@splintered.co.uk> <mailto:re...@splintered.co.uk
<mailto:re...@splintered.co.uk>>> wrote:
On 16/03/2016 04:46, Richard Maher wrote:
...
Anyway, if the decorum police will agree to stay their
truncheons for a
moment longer and indulge my use of satire, parody, and
metaphor, in
making an extremely valid technical point,
...
Or you could just make your valid technical point, without
resorting to your sarcastic tone which, frankly, is quite grating and is doing
you n
Re: HTML5's Offline-first Council of Trent
On 2016-03-17 06:00, Richard Maher wrote:
Hi Patrick (Congratulations on today) Technical Point follows: -
On a merit-based resource allocation basis, the two most fundamental, essential,
> and absolutely necessary HTML5 Web-App feature enhancements are: -
1) Background GPS device/user tracking support
2) Push API 1:M broadcast capability
These are enabling technologies that will catapult HTML5 Web Apps into the
> Native App heartland and single-handedly alter the development-tool and
deployment
> strategies for Mobile App vendors around the world.
An even more powerful (but also ignored possibility) would be COMBINING the
power
of the Web and App worlds instead of fighting religious wars ("the Web is
great"),
where there are no winners, only lost opportunities.
It gets worse...if you are the Web tech leader then you are apparently free
taking
this "shortcut" (some people would rather characterize this as an intelligent
use
of available resources and competences), and get away with it as well:
https://github.com/w3c/webpayments/issues/42#issuecomment-166705416
Anders
The reason these features do not appear on the W3C horizon is that they
show-case online-first and are anathema to the Offline-First Mafia that is
currently setting the agenda and feathering its own nest.
Technically, I have to admit to having absolutely no idea how a W3C performance
review would be conducted or how ROI on a given contributor's input could be
measured. I am a simple man who just needs a couple more tools in the box in
order to deliver the killer Web Apps my users are begging for.
Where I come from, and certainly from my experience in London finance, it's all
about getting the job done! You can have two heads and be the most obnoxious
Maher in the world but you're paid to do a job and get around the Sir Humphrey
Appleby speed humps on the road the progress in order to do it.
I'm not here to make friends or see how many followers I can get on Twitter,
and I apologize for being the only one without an original selfie of myself
looking wistfully off camera, but I'm motivated by results and not married to
the process.
HTML5 - Web Apps "The journey is *NOT* the destination!
On Wed, Mar 16, 2016 at 5:58 PM, Patrick H. Lauke > wrote:
On 16/03/2016 04:46, Richard Maher wrote:
...
Anyway, if the decorum police will agree to stay their truncheons for a
moment longer and indulge my use of satire, parody, and metaphor, in
making an extremely valid technical point,
...
Or you could just make your valid technical point, without resorting to
your sarcastic tone which, frankly, is quite grating and is doing you no favors
in getting at least some of the readership on this list to even want to engage
in your argument.
P
--
Patrick H. Lauke
www.splintered.co.uk |
https://github.com/patrickhlauke
http://flickr.com/photos/redux/ | http://redux.deviantart.com
twitter: @patrick_h_lauke | skype: patrick_h_lauke
Re: App-to-App interaction APIs - one more time, with feeling
On 2015-10-18 19:09, Aymeric Vitte wrote: Le 17/10/2015 16:19, Anders Rundgren a écrit : Unless you work for a browser vendor or is generally "recognized" for some specialty, nothing seems to be of enough interest to even get briefly evaluated. Right, that's a deficiency of the W3C/WHATWG/whatever specs process, where people well seated in their big companies/org comfortable chairs lack imagination, innovation, are very long to produce anything and just spec for themselves things that become obsolete as soon as they have released it, or things that just never match the reality and general use cases, and they generally disconsider other opinions, although they recognize usually at the end that they messed up, then they respecc it and the loop starts again. Regarding App-to-App interaction I'm personally mainly into the Web-to-Native variant. That's a very poor system, I think you are still in your long never ending quest of seeking for "something in the web that could match what you want to do" but probably it's not that one. Do people here mean that we are going forever to exchange text, images, files, stuff like this only? That's the vision? I can't speak for people here in general but my vision (FWIW) is already fairly well in place: https://test.webpki.org/webpay-merchant Yes, the are some folks who claim that this will eventually be possible doing with "pure" Web tech but maybe the market doesn't care that much about purity? Particularly not if it takes 5-10 years to achieve. Too little too late. One doesn't have to think very hard to realize that Apple and Google won't build wallets for iOS and Android respectively and then build another set for the Web. It would be a very confusing user-experience, poor use of development resources etc. Note: wallets i just one app among many. Anders Can't we share Web Components? Which can be any app with the possibility to interact with it? That's what for example the Web Intents should do, again you should not close the group.
Re: Making progress with items in Web Platform Re: App-to-App interaction APIs - one more time, with feeling
On 2015-10-17 17:58, Chaals McCathie Nevile wrote: Regarding App-to-App interaction I'm personally mainly into the Web-to-Native variant. As I already pointed out to Daniel, this stuff is not in the current scope of the group, and you should work on it in the context of e.g. the Web Incubator Community Group, where it is relevant to their scope. As I wrote, this particular feature is already in Chrome and is now being implemented by Microsoft and Mozilla. Anders chaals, for the chairs. Here the browser vendors have reportedly [1,2] decided to implement Google's Native Messaging API "as is" without any discussions in related W3C forums, something they will surely regret because it has a long list of shortcomings, ranging from a difficult deployment scheme to limited functionality and performance issues, not to mention a highly deficient security model: https://lists.w3.org/Archives/Public/public-webappsec/2015Oct/0071.html That the browsers vendors have gotten major push-backs after removing their previous extension schemes (NPAPI, ActiveX) is obvious, but that doesn't motivate rushing into crude workarounds: http://www.cnet.com/news/google-paves-over-hole-left-by-chrome-plug-in-ban/ Anders 1] https://wiki.mozilla.org/WebExtensions#Additional_APIs 2] http://www.slashgear.com/project-spartan-is-now-edge-and-will-have-chrome-extensions-29381422/ Ccing the authors of [1], [2] and [3] if there is still an interest. at this stage we don't have a deliverable for this work - i.e. the W3C members haven't approved doing something like this in Web Platform working group. Given that people repeatedly attempt to do it, I think the conversation is worth having. Personally I think this is something the Web needs Indeed, that will be more than time to do so, but the current view of the main actors or past specs seems a kind of narrowed and not very imaginative/innovative, I don't think you should close the web intents task force [5] but restart it on new bases. This approach [1] and [2] looks quite good, simple and can cover all cases. I don't know if we can call it a Web Component really for all cases but let's call it as such. In [2] examples the Bio component could be extracted to be passed to the editor for example and/or could be shared on fb, and idem from fb be edited, shared, etc Or let's imagine that I am a 0 in web programming and even Web Components are too complicate for me, I put an empty Google map and edit/customize it via a Google map editor, there is [3] maybe too but anyway the use cases are legions. That's incredible that nobody can see this and that [1] did not get any echo (this comment I especially dedicate it to some people that will recognize themselves about some inappropriate comments, not to say more, they made regarding the subject related to the last paragraph of this post). The Intent service would then be a visible or a silent Web Component discussing with the Intent client using postMessage. Maybe the process could be instanciated with something specific in href (as suggested in [2] again) but an Intent object still looks mandatory. But in case of visible Intent service, the pop-up style looks very ugly and old, something should be modified so it seems to appear in the calling page, then the Intent service needs to have the possibility to become invisible (after login for example). I don't see any technical difficulty to spec and implement this (except maybe how to avoid the horrible pop-up effect) and this covers everything. If that happens the next step is to change our charter. That is an administrative thing that takes a few weeks (largely to ensure we get the IPR protection W3C standards can enjoy, which happens because we spend the time to do the admin with legal processes) if there is some broad-based support. Unfortunately, despite of our efforts and patience, due to the lack of agreement on this matter with the related W3C members, unless people decide to restrict Intents to some trivial edit, share uses of simple images, text, files, which looks quite limited (but surprisingly seems enough for Microsoft, Mozilla and Google) and will necessarily end-up redoing the spec again several years later, the specs will inevitably cross again the path of the patent you know [4], for parts related to the extraction mechanisms that time, which anyway the web will one day implement. [1] https://lists.w3.org/Archives/Public/public-web-intents/2014Oct/0001.html [2] http://dev.mygrid.org.uk/blog/2014/10/you-want-to-do-what-theres-an-app-for-that/ [3] https://lists.w3.org/Archives/Public/public-web-intents/2015Feb/ [4] https://lists.w3.org/Archives/Public/public-webapps/2015AprJun/0911.html [5] https://lists.w3.org/Archives/Public/public-web-intents/2015Oct/.html
Re: App-to-App interaction APIs - one more time, with feeling
On 2015-10-16 18:00, Aymeric Vitte wrote: Well, since I was on the list, I took the liberty of commenting a bit on this. Unless you work for a browser vendor or is generally "recognized" for some specialty, nothing seems to be of enough interest to even get briefly evaluated. Regarding App-to-App interaction I'm personally mainly into the Web-to-Native variant. Here the browser vendors have reportedly [1,2] decided to implement Google's Native Messaging API "as is" without any discussions in related W3C forums, something they will surely regret because it has a long list of shortcomings, ranging from a difficult deployment scheme to limited functionality and performance issues, not to mention a highly deficient security model: https://lists.w3.org/Archives/Public/public-webappsec/2015Oct/0071.html That the browsers vendors have gotten major push-backs after removing their previous extension schemes (NPAPI, ActiveX) is obvious, but that doesn't motivate rushing into crude workarounds: http://www.cnet.com/news/google-paves-over-hole-left-by-chrome-plug-in-ban/ Anders 1] https://wiki.mozilla.org/WebExtensions#Additional_APIs 2] http://www.slashgear.com/project-spartan-is-now-edge-and-will-have-chrome-extensions-29381422/ Ccing the authors of [1], [2] and [3] if there is still an interest. at this stage we don't have a deliverable for this work - i.e. the W3C members haven't approved doing something like this in Web Platform working group. Given that people repeatedly attempt to do it, I think the conversation is worth having. Personally I think this is something the Web needs Indeed, that will be more than time to do so, but the current view of the main actors or past specs seems a kind of narrowed and not very imaginative/innovative, I don't think you should close the web intents task force [5] but restart it on new bases. This approach [1] and [2] looks quite good, simple and can cover all cases. I don't know if we can call it a Web Component really for all cases but let's call it as such. In [2] examples the Bio component could be extracted to be passed to the editor for example and/or could be shared on fb, and idem from fb be edited, shared, etc Or let's imagine that I am a 0 in web programming and even Web Components are too complicate for me, I put an empty Google map and edit/customize it via a Google map editor, there is [3] maybe too but anyway the use cases are legions. That's incredible that nobody can see this and that [1] did not get any echo (this comment I especially dedicate it to some people that will recognize themselves about some inappropriate comments, not to say more, they made regarding the subject related to the last paragraph of this post). The Intent service would then be a visible or a silent Web Component discussing with the Intent client using postMessage. Maybe the process could be instanciated with something specific in href (as suggested in [2] again) but an Intent object still looks mandatory. But in case of visible Intent service, the pop-up style looks very ugly and old, something should be modified so it seems to appear in the calling page, then the Intent service needs to have the possibility to become invisible (after login for example). I don't see any technical difficulty to spec and implement this (except maybe how to avoid the horrible pop-up effect) and this covers everything. If that happens the next step is to change our charter. That is an administrative thing that takes a few weeks (largely to ensure we get the IPR protection W3C standards can enjoy, which happens because we spend the time to do the admin with legal processes) if there is some broad-based support. Unfortunately, despite of our efforts and patience, due to the lack of agreement on this matter with the related W3C members, unless people decide to restrict Intents to some trivial edit, share uses of simple images, text, files, which looks quite limited (but surprisingly seems enough for Microsoft, Mozilla and Google) and will necessarily end-up redoing the spec again several years later, the specs will inevitably cross again the path of the patent you know [4], for parts related to the extraction mechanisms that time, which anyway the web will one day implement. [1] https://lists.w3.org/Archives/Public/public-web-intents/2014Oct/0001.html [2] http://dev.mygrid.org.uk/blog/2014/10/you-want-to-do-what-theres-an-app-for-that/ [3] https://lists.w3.org/Archives/Public/public-web-intents/2015Feb/ [4] https://lists.w3.org/Archives/Public/public-webapps/2015AprJun/0911.html [5] https://lists.w3.org/Archives/Public/public-web-intents/2015Oct/.html
Mozilla/Microsoft support for Native Messaging
https://wiki.mozilla.org/WebExtensions#Additional_APIs http://www.slashgear.com/project-spartan-is-now-edge-and-will-have-chrome-extensions-29381422/ It would be a pity if Mozilla and Microsoft implements support for Chrome's Native Messaging without any discussions on W3C lists. Although Native Messaging is better than nothing, it is in its current shape hardly more than a workaround: http://www.cnet.com/news/google-paves-over-hole-left-by-chrome-plug-in-ban/ Anders
Re: Stability of Widget DigSig
On 2015-05-08 14:32, Frederick Hirsch wrote: no objection, the referenced document is a Recommendation, isn't it? http://www.w3.org/TR/widgets-digsig/ This seems to be a rather theoretical discussion: https://developer.mozilla.org/en-US/Add-ons/SDK/High-Level_APIs/widget Anders regards, Frederick Frederick Hirsch Chair XML Security WG fjhirsch.com @fjhirsch On May 8, 2015, at 7:14 AM, Arthur Barstow art.bars...@gmail.com wrote: [ + Marcos and Frederick ] Hi Andrew, The group stopped working on XML Digital Signature for Widgets several years ago and there is no plan to resume work (except to process errata as required). Marcos, Frederick - this spec's namespace document includes the following statement: [[ http://www.w3.org/ns/widgets-digsig/ Implementers should be aware that this document is not stable. ]] Any objections from you or anyone else to remove this statement? -Thanks, ArtB On 5/7/15 5:55 AM, Andrew Twigger wrote: ATSC and CEA are developing standards that include the ability to download digital signed applications. Their current specifications reference the W3C Recommendation for XML Digital Signature for Widgets (18 April 2013). However, the associated Widgets Digital Signature Namespace (http://www.w3.org/ns/widgets-digsig/) contains a statement that “Implementers should be aware that this document is not stable.” which has raised questions as to the stability and suitability of referencing Widget DigSig. The alternative would be to reference XAdES with the C and T forms to allow for the inclusion of timestamp and certificate revocation information which are not included in Widget DigSig. I would be pleased to receive any information regarding the stability of Widget DigSig and whether referencing XAdES would provide a better alternative. Thank-you, Andrew Twigger
Re: Stability of Widget DigSig
On 2015-05-08 14:50, Arthur Barstow wrote: On 5/8/15 8:47 AM, Anders Rundgren wrote: On 2015-05-08 14:32, Frederick Hirsch wrote: no objection, the referenced document is a Recommendation, isn't it? http://www.w3.org/TR/widgets-digsig/ This seems to be a rather theoretical discussion: https://developer.mozilla.org/en-US/Add-ons/SDK/High-Level_APIs/widget FYI, the usage of widget in widgets-digsig is not at all related to the use of widget in the MDN resource reference above. Just for my understanding, is the W3C Widget TR generally supported then? Anders -AB
Microsoft is considering Chrome's Native Messaging
https://twitter.com/shimonamit/status/571046844488245248 Not very surprising. It is a very good idea even if the current solution in Chrome is a bit of a prototype since it is not the extension (which BTW is redundant) that needs to be vetted and app-stored; it is the native application that does the dirty work. This would IMO be an ideal work-item for WebAppSec. Anders
Proposed W3C CG - The Extended Web
https://www.w3.org/community/blog/2015/04/19/proposed-group-the-extended-web-community-group/ Since the CG description is free from political stuff, I included it here :-) Most of the things exposed in the system-level (native) APIs of Android, iOS, Windows, etc. could indeed be provided in web-browsers. However, the cost and time that this would take as well as the ever-increasing speed of native OS and related hardware developments make this unrealistic except for a rather modest set of well-scoped APIs. It has also proven to be considerably harder dealing with untrusted web-code than originally thought. The Extended Web CG is about *COMBINING the power of the two worlds* which is a bit nicer than the current Platform War (which like regular wars doesn't really make anybody happy). To achieve that, The Extended Web CG is dedicated developing a *secure link* between the Open [untrusted] Web and the Native [trusted] layer, independently of how the latter is expressed. The current idea is building on an *enhanced version* of Chrome's Native Messaging: http://www.cnet.com/news/google-paves-over-hole-left-by-chrome-plug-in-ban/ http://blog.chromium.org/2013/10/connecting-chrome-apps-and-extensions.html The single most important feature of Native Messaging is that it offers *a way for third-parties to innovate* in areas ranging from Secure Web-payments to Streaming Media-services as well as one-of-a-kind vendor-specific solutions like Remote Diagnostics for PCs. FWIW, it seems that the core concept (talking securely with a web-page), could, and with relative ease (fingers crossed...), also include mobile devices connected to a web-page through an NFC/Bluetooth(BLE) combo link: https://cyberphone.github.io/openkeystore/resources/docs/webnfc--web2device-bridge.pdf A defensive publication has recently been submitted for this proposal. Anders Rundgren convener/firestarter https://cyberphone.github.io/openkeystore/resources/docs/web2native-bridge.pdf
Re: [W3C TCP and UDP Socket API]: Status and home for this specification
On 2015-04-02 11:46, Nilsson, Claes1 wrote: Thanks for all replies to my mail below. To address the “security/webapp permission to use the API”- issue I see the following alternatives: 1.Keep as is: This means that the way permission is given to a webapp to use the API is not defined by the TCP and UDP Socket API, only methods to request permission and to check if permission is given are defined and the implementation of the security/permission system depends on the web runtime in which the API is implemented. See section 4 to 8 in the specification: http://www.w3.org/2012/sysapps/tcp-udp-sockets/#security-and-privacy-considerations. As far as I understand this approach would make the API implementable in legacy web runtimes such as FFOS, Chrome Apps and Tizen and in “Webviews” used in by hybrid native-web apps in which the security model is defined by the native environment. Currently the API is not implementable in the normal open web browser but may be in the future? If the web is going to evolve as a capable application environment general solutions on the security issues with exposing more powerful APIs must be solved. That's the #1 problem; this is not recognized as high-priority mission. In fact, the only activity I'm aware of are various efforts locking down browsers even more, leaning web developers in a very disadvantaged position position compared to their App-developing cousins. Anyway, SysApps at least terminated in style :-) WebCrypto.Next with hardware security on the menu OTOH did not :-( https://lists.w3.org/Archives/Public/public-web-security/2015Feb/0034.html Regarding permissions, I remain unconvinced that they address this issue in a reasonable way. An Android App may ask for access to the Internet as well as to Contacts. IMO, this has limited value for the end-user since the App may send your contacts to a server somewhere which probably isn't what you expected or wanted. Obviously we need a model where the code is vetted for DoingTheRightThing(tm). Anders I refer for example to ongoing work in Web Apps Sec WG and TrustPermission CG. SoMC has also experimented with “Trusted Hosted Apps”, https://lists.w3.org/Archives/Public/public-sysapps/2014Sep/att-/SoMC_FFOS_Trusted_Hosted_Apps.pdf. The main issue here is if it is today (as SysApps now is dead) in the scope for W3C to standardize APIs that only are implementable in legacy web runtimes but currently are not implementable in the standard open web browser context, even though it may be implementable in the future assuming an improved security model ? 2.In the specification define a security model based on “same origin”/CORS: This has been discussed on this thread and may be possible. However, the drawback of this approach is that this limits the scope of use cases. For example, discovery of and communication with legacy devices in local networks. 3.In the specification define a security model for example based on https:, content security policies (CSP), a signed manifest and certificate pinning. This may be possible but I feel that such a security model is a general solution and it fells as we then, in an API specification, are defining a part of a web runtime. Alternatives for the future of this API specification: 1.Move to a new CG 2.Move to DAP or Web Apps 3.Stop working on it and make it an informative Working Group Note The decision of course depends on the use cases for this API and the manner in which the use cases are implemented. Do we still need a low level TCP and UDP Socket API to communicate with legacy devices or could we rely on Web Sockets, Web RTC and higher level approaches such as 2^nd screen API? BR Claes *Claes Nilsson* Master Engineer - Web Research Advanced Application Lab, Technology *Sony Mobile Communications* Tel: +46 70 55 66 878 claes1.nils...@sonymobile.com mailto:firstname.lastn...@sonymobile.com sonymobile.com http://sonymobile.com/ Sony logotype_23px height_Email_144dpi *From:*Nilsson, Claes1 *Sent:* den 1 april 2015 11:22 *To:* public-sysa...@w3.org mailto:public-sysa...@w3.org; public-webapps; Device APIs Working Group *Cc:* 'Domenic Denicola'; 'slightly...@chromium.org'; 'yass...@gmail.com' *Subject:* [W3C TCP and UDP Socket API]: Status and home for this specification Hi all, Related to the recent mail thread about the SysApps WG and its deliverables I would like to make a report of the status of the TCP and UDP Socket API, http://www.w3.org/2012/sysapps/tcp-udp-sockets/. Note that this specification is still being worked on. Latest merged PR was March 30. I think it is time for a new Public Working Draft. This API is used to send and receive data over the network using TCP or UDP. Examples of use cases for the API are: * An email client which communicates with SMTP, POP3 and IMAP servers * An irc client which communicates with irc servers * Implementing an ssh app * Communicating with existing consumer
Re: [W3C TCP and UDP Socket API]: Status and home for this specification
On 2015-04-01 16:11, Anne van Kesteren wrote: On Wed, Apr 1, 2015 at 3:58 PM, Nilsson, Claes1 claes1.nils...@sonymobile.com wrote: However, work is ongoing in the Web App Sec WG that may provide basis for a security model for this API. Please read section 4, http://www.w3.org/2012/sysapps/tcp-udp-sockets/#security-and-privacy-considerations I don't see anything there that makes TCP or UDP possible. It has # Explicit trust for the requesting webapp based on the security # system of the web runtime this API is implemented in. but no such thing exists (standardized). Even if there was a technical standard for the web runtime, the distribution and vetting of secure applications would probably not be standard which is why I continue literally jumping up and down pointing in another direction which is based on COMBINING the Open Web with local, more or less proprietary applications which would do the dirty work (like they already do today). Unfortunately it seems that the browser vendors want to lock down everything leaving Web developers in a very disadvantaged position compared to their App-developing cousins. Regarding permissions involving the user, there are huge limitations in the Open Web: http://webpki.org/papers/permissions.pdf Anders
Re: [W3C TCP and UDP Socket API]: Status and home for this specification
On 2015-04-01 20:47, Jonas Sicking wrote: On Wed, Apr 1, 2015 at 7:03 PM, Domenic Denicola d...@domenic.me wrote: From: Boris Zbarsky [mailto:bzbar...@mit.edu] This particular example sets of alarm bells for me because of virtual hosting. Eek! Yeah, OK, I think it's best I refrain from trying to come up with specific examples. Let's forget I said anything... As in, this seems like precisely the sort of thing that one browser might experiment with, another consider an XSS security bug, and then we have content that depends on a particular browser, no? My argument is that it's not materially different from existing permissions APIs. I think it is. In cases like geolocation or notifications, the people writing the spec, and the people implementing the spec, were able to envision a reasonable permissions UI. For the TCP/UDPSocket APIs, no one, to my knowledge, has been able to describe a reasonable UI. Indeed. It seems that this problem is omnipresent for SysApps. Here a real-world example: http://www.sconnect.com/FAQ/#permissionrequest Who would like to get something like that in their face when buying stuff on the web? Anders Basically the spec contains a big magic happens here section. That's always bad in a spec. For example, it'd be bad if the CSS spec said figure out column sizes would make the table look good. The fact that we're talking about permissions doesn't make magic any more ok. Magic is different from leaving UI details up to the browser. / Jonas
Re: Proposal for a Permissions API
On 2015-03-21 22:47, Florian Bösch wrote:
Time to revise this topic. Two data points:
1) Particularly with pointerlock (but also with other permission prompts
that sneak up on the user) I often get the complaint from users along the
lines of I tried your stuff, but it didn't work. or I tried your stuff,
but it asked me to do X, I don't think it works.
2) MRI scans show that user attention dramatically drops when presented with
a security prompt:
http://arstechnica.com/security/2015/03/mris-show-our-brains-shutting-down-when-we-see-security-prompts/
Permission/Security prompts are bad UX. Particularly the kind you need to prompt
the user with along the way. And within that, even worse are the ones that
pop up again and again (like the fullscreen popup).
I agree with this. When skimming
https://webbluetoothcg.github.io/web-bluetooth/use-cases.html
I particularly noted the following lines:
3.2.1 The Bluetooth API must only expose those parts of the general Bluetooth
protocol that present an acceptable risk of exploit
This may lead to:
- Crippled functionality
- User's being confronted with questions they don't understand the consequences
of
like http://www.sconnect.com/FAQ/#permissionrequest
Although efforts making the Open Web more competitive with the Native/Platform
level are
motivated, I'm personally unconvinced that DUPLICATION is the right approach
for system-
level interfaces.
COMBINING these layers seems like a simpler way ahead. FWIW, I have sort of
launched
such a scheme: http://www.ietf.org/mail-archive/web/jose/current/msg05005.html
What's the difference you may [rightfully] wonder? Well, the short version is
that it enables
any numbers of specific (single-purpose) interfaces that does exactly what you
want and at
worst needing a privacy prompt. These interfaces can also be defined (and
implemented!)
by different communities which allows for quicker turnaround which is quite
important if
you are set to compete with the App world.
Anders
On Wed, Oct 1, 2014 at 7:34 PM, Jeffrey Yasskin jyass...@google.com
mailto:jyass...@google.com wrote:
On Wed, Sep 3, 2014 at 3:29 AM, Mounir Lamouri mou...@lamouri.fr
mailto:mou...@lamouri.fr wrote:
On Wed, 3 Sep 2014, at 04:41, Jonas Sicking wrote:
I'm generally supportive of this direction.
I'm not sure that that the PermissionStatus thing is needed. For
example in order to support bluetooth is might be better to make the
call look like:
permissions.has(bluetooth, fitbit).then(...);
That's more Permission than PermissionStatus, right?
What you proposed here would probably be something like that in WebIDL:
Promise has(PermissionName name, any options);
But really, we could make that option bag be a dictionary because it
gives good context about what you are passing like what does fitbit
means here? Is that a black listed device or a white listed one? The one
you want to target?
I agree that it might be unusual to have a required name than might
often be used alone but it makes the API way more javascript-y and self
explanatory. IMO, this call is nicer to read than the one you wrote
above:
permissions.has({ name: 'bluetooth', devices: 'fitbit' });
because I understand what the call is trying to do. In addition, as you
pointed, it gives a lot of flexibility.
Belatedly, I'd like to suggest a slightly different model. Instead of
trying to stuff arbitrary queries into the permissions.has() call,
maybe expose the current permissions as data, and let the application
inspect them using custom code. This is likely to work better for
Bluetooth, since we're planning to have pages request devices by the
Services they expose, not their deviceIds, and a page may want to
check for either an available device exposing some services, or that a
device they've already opened hasn't been revoked.
Getting permission revocation to update a UI correctly is also an
interesting problem. You could expose an event on permission change,
but given that templating frameworks are moving toward
Object.observe() to update themselves in response to model object
changes, that would require developers to write extra code to
propagate the permission changes into their models.
So what if navigator.permissions just _was_ a suitable model object?
Make it, say, a Map from permission-name to an object defined by the
permission's standard, and extend Map to expose enough synthetic
change records that Object.observe(a_map) is useful.
Jeffrey
Access to localhost to be outlawed?
https://code.google.com/p/chromium/issues/detail?id=378566 Since popular services like DropBox and Spotify depend on this non-standardized way of bypassing the browser, I think this strengthens my argument that we really need a standard way to do this. The time for that is now. Anders
Re: [manifest] RE: Manifest for web application; review deadline March 5
On 2015-03-06 10:55, Nilsson, Claes1 wrote: Yes, that covers my first question. I have also seen Anssi’s CSP extension specification. I guess that the approach is to see how far we can get in the TrustPermissions CG on the ideas we experimented with for FFOS, i.e. to find a way to securely open up sensitive APIs to server hosted web sites using a signed manifest and secure transport. This indeed a major concern. Permissions and Trustworthy Code are unfortunately not particularly related. Cheers, Anders Then we have to work on any needed extensions to the Manifest specification. BR Claes *Claes Nilsson* Master Engineer - Web Research Advanced Application Lab, Technology *Sony Mobile Communications* Tel: +46 70 55 66 878 claes1.nils...@sonymobile.com mailto:firstname.lastn...@sonymobile.com sonymobile.com http://sonymobile.com/ Sony logotype_23px height_Email_144dpi *From:*Christiansen, Kenneth R [mailto:kenneth.r.christian...@intel.com] *Sent:* den 6 mars 2015 10:46 *To:* Nilsson, Claes1; 'Kenneth Rohde Christiansen'; Kostiainen, Anssi; Arthur Barstow; public-webapps *Subject:* RE: [manifest] RE: Manifest for web application; review deadline March 5 Yes, indeed. I just didn´t remember the final name. Does that cover your first question? Regarding the second questions, Anssi wrote an extension spec: http://w3c.github.io/manifest-csp/ He can probably comment on that. Kenneth *From:*Nilsson, Claes1 [mailto:claes1.nils...@sonymobile.com] *Sent:* Friday, March 6, 2015 10:39 AM *To:* 'Kenneth Rohde Christiansen'; Arthur Barstow; public-webapps *Subject:* RE: [manifest] RE: Manifest for web application; review deadline March 5 Ok thanks Kenneth. I assume that you refer to the Trust Permissions Community Group, https://www.w3.org/community/trustperms/? BR Claes *Claes Nilsson* Master Engineer - Web Research Advanced Application Lab, Technology *Sony Mobile Communications* Tel: +46 70 55 66 878 claes1.nils...@sonymobile.com mailto:firstname.lastn...@sonymobile.com sonymobile.com http://sonymobile.com/ Sony logotype_23px height_Email_144dpi *From:*Kenneth Rohde Christiansen [mailto:kenneth.christian...@gmail.com] *Sent:* den 6 mars 2015 10:09 *To:* Nilsson, Claes1; Arthur Barstow; public-webapps *Subject:* Re: [manifest] RE: Manifest for web application; review deadline March 5 Hi Claes, The web app manifest spec allows extensions (it has extension points), so we would expect the Permissions WG/CG to come up with a proper way to deal with permissions. If they come to the conclusion that we need some permission field in the manifest, their spec can add that. It is not yet clear at this point that that is the solution that they are aiming at. Cheers, Kenneth On Thu, Mar 5, 2015 at 4:50 PM Nilsson, Claes1 claes1.nils...@sonymobile.com mailto:claes1.nils...@sonymobile.com wrote: Hi, We support that this version of the specification is moved to Candidate status but we have a few comments/questions: In this version 1 we miss: * A permissions field * A content security policy field. This is only included as a way to state allowed origins from which the manifest file itself could be loaded. However, there is, in this first version, no CSP-field defined for the manifest document, allowing restriction of origins the web app could download scripts and other content types from. There is also a draft companion document, http://w3c.github.io/manifest-csp/, defining this CSP-member of the manifest. We consider the above features important for allowing server hosted web apps access to more sensitive APIs and have been experimenting with this for FFOS: https://lists.w3.org/Archives/Public/public-sysapps/2014Sep/att-/SoMC_FFOS_Trusted_Hosted_Apps.pdf. Accordingly we want to discuss these features for the further work on the manifest specification. We also would like to ask the WG if it has been discussed if https: transport should be required for downloading the manifest? Other specifications are moving towards requirement for https:. See for example the discussion https://lists.w3.org/Archives/Public/public-device-apis/2015Feb/0045.html. For the manifest version 1 this may not be critical but if above features are added the transport probably have to be protected. However, once again note that these comments do not prevent that we support that the current version of the manifest is moved to candidate status, I am just taking the opportunity state our views on the further work on the manifest specification. Best regards Claes Nilsson Master Engineer - Web Research Advanced Application Lab, Technology Sony Mobile Communications Tel: +46 70 55 66 878 claes1.nils...@sonymobile.com mailto:claes1.nils...@sonymobile.com sonymobile.com http://sonymobile.com -Original Message- From: Arthur Barstow [mailto:art.bars...@gmail.com mailto:art.bars...@gmail.com] Sent: den 13 februari 2015 01:31 To: public-webapps Subject: RfC:
WebPortable/PlatformProprietary - An Established Concept
HTTPS Client Certificate Authentication is supported by all browsers since almost 20 years back. It exposes a fully standardized interface to Web Applications which simply is an URL. In spite of that it is entirely proprietary with respect to integration in the browser platform with implementations based on PKCS #11, CryptoAPI, JCE, .NET, NSS as well as working with a huge range of secure key-containers like SIM, PIV, TEE, TPM, Soft Keys. This side of the coin has not been standardized since it [provably] wasn't needed. In: https://lists.w3.org/Archives/Public/public-webcrypto-comments/2015Jan/.html Google's Ryan Sleevy writes: What you're looking for is http://blog.chromium.org/2013/10/connecting-chrome-apps-and-extensions.html This scheme could (after Polishing + W3C Standardization), without doubt support the same powerful paradigm as HTTPS Client Certificate Authentication (WebPortable/PlatformProprietary), for virtually any security application you could think of. Cheers, Anders
Re: Staying on Topic [Was: Re: WebPortable/PlatformProprietary - An Established Concept]
On 2015-02-19 15:47, Arthur Barstow wrote: On 2/19/15 9:35 AM, Anders Rundgren wrote: Hi Anders, Hi Art, In the spirit of restricting postings on this list to the group's chartered scope ... http://www.w3.org/2008/webapps/ This work will include both documenting existing APIs such as XMLHttpRequest and developing new APIs in order to enable richer web applications Where are you supposed to propose new APIs? Can such proposal be made by non-W3C members? This was a proposal for using Chrome Native Messaging as the foundation for a new standard. Cheers Anders I don't see a clear and direct connection between your posting [1] and WebApps' chartered scope [2]. If I missed such a connection, please focus your related postings to a specific spec and use the spec's short-name as the Subject: prefix (f.ex. for the Manifest spec use [appmanifest] ...). -Thanks, AB [1] https://lists.w3.org/Archives/Public/public-webapps/2015JanMar/0685.html [2] https://www.w3.org/2008/webapps/wiki/PubStatus
Re: [WebCrypto.Next] Any ideas on how to proceed?
On 2015-02-18 08:59, David Leon Gil wrote: W.r.t. WebCrypto-Next: It would be wonderful to see a few useful algorithms added to the spec: - a modern VOF (e.g., SHAKE256) - a fast hash function (e.g., BLAKE2b) - a sequential-hard KDF (e.g., scrypt) - some non-NSA curves as well as a slightly higher-level interface that makes it less complicated to do things like (cryptographically sound) ECDH without shooting yourself in the foot repeatedly. (I tried with the current API, and I have fewer toes.) There are some other things that would be great to see standardized in this area, but WebCrypto may not be the appropriate WG. This belongs to a WebCrypto maintenance task which is an entirely different topic than the stuff referred to in my posting. Anders On Tue, Feb 17, 2015 at 10:30 PM, Anders Rundgren anders.rundgren@gmail.com wrote: As you probably noted, all proposals related to http://www.w3.org/2012/webcrypto/webcrypto-next-workshop/ were shot down. Are we waiting on something, and if so is the case, exactly what? Is the idea of building on an already semi-established solution like Chrome Native Messaging unacceptable? Or should this disparate community rather standardize on U2F? Another solution (IMO workaround) is using local services supplying Security Services through Redirects, XHR or WebSockets. Since the (in)famous plugins were simply removed without any thoughts of the implications, it seems that the browser vendors currently own this question. Anders
Mozilla on Privileged Hosted Apps
It seems that the web indeed is at a cross-road when it comes to applications that are intended to be on par with native: https://groups.google.com/forum/#!topic/mozilla.dev.webapi/pCY77YAg_i4 The Web2Native Bridge is another take on this matter: https://lists.w3.org/Archives/Public/public-web-intents/2015Feb/.html It has one major advantage over the web solutions and that is that could make whatever API possible to expose on the web (after vetting the application), in addition to not requiring browser vendor involvement when APIs are evolving. Naturally both schemes are usable but something along the lines of the Web2Native Bridge is most urgent because currently Apple Pay-like web payments are infeasible. Anders
[WebCrypto.Next] Any ideas on how to proceed?
As you probably noted, all proposals related to http://www.w3.org/2012/webcrypto/webcrypto-next-workshop/ were shot down. Are we waiting on something, and if so is the case, exactly what? Is the idea of building on an already semi-established solution like Chrome Native Messaging unacceptable? Or should this disparate community rather standardize on U2F? Another solution (IMO workaround) is using local services supplying Security Services through Redirects, XHR or WebSockets. Since the (in)famous plugins were simply removed without any thoughts of the implications, it seems that the browser vendors currently own this question. Anders
Updated: Running trusted code in the untrusted web
Although I still prefer native messaging, here is a more complete proposal for a webish solution: http://webpki.org/papers/trusted-web-apps.pdf Anders On 2015-02-17 06:32, Anders Rundgren wrote: For those who frown at the idea of calling native (trusted) applications from the untrusted web [1], here is a writeup of how you could run trusted web-code inside of a untrusted web-application. Regarding the use-cases, there are many ranging from phone-dialers on support pages to payments [2]. Since you probably do not want to rewrite browsers from scratch, the most logical is building on running trusted code in IFRAMEs so that the existing protection scheme can be reused. The difference with existing IFRAMEs is that the code must be trusted by the platform which also means that it must be fetched from the platform: iframe trustedapp=com.example.PaymentRequest ... /iframe This code should appear to the browser as coming from a virtual domain. The only communication possible is through postMessage(). If the referenced application isn't available in the local cache, the browser should presumably consult the device-specific AppStore. A side-effect of this specification is that trusted web-applications may be device-specific which actually is a plus since it reduces the need to standardize access to the OS and HW layer. That is, there could be a new class of standardized trusted web-applications where only the invoke/postMessage part is standardized! Cheers, Anders Rundgren 1] https://lists.w3.org/Archives/Public/public-web-intents/2015Feb/.html 2] Although not entirely compliant with the above, the following demo https://mobilepki.org/WebCryptoPlusPlus does the same thing from a user's perfective.
Re: The futile war between Native and Web
On 2015-02-16 16:54, Michaela Merz wrote: This discussion is (in part) superfluous. Because a lot of people and organizations are using the web even for the most secure applications. Heck - they even send confidential data via plain old e-mail - they would even use AOL if that would still be possible - in other words: Most simply don't care. The web is THE universal applicable platform for .. well .. everything. So - it's the job of the browser vendors in cooperation with the web-developers to provide an environment that is up to the task. And I strongly believe that a safe and secure JavaScript environment is achievable as long as the browsers do their part (strict isolation between tabs would be such a thing). On paper it is doable, in reality it is not. You would anyway end-up with proprietary AppStores with granted Apps and then I don't really see the point insisting on using web-technology anymore. General code-signing like used in Windows application doesn't help, it is just one OK button more to click before running. Anders I am aware of the old notion, that JavaScript crypto is not safe. But I say it *can*' be. CSP is a huge leap forward to make the browser a safe place for the handling of confidential data. Michaela On 02/16/2015 03:40 AM, Anders Rundgren wrote: On 2015-02-16 09:34, Anne van Kesteren wrote: On Sun, Feb 15, 2015 at 10:59 PM, Jeffrey Walton noloa...@gmail.com wrote: 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. What would you suggest instead? 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), ... So you would like physical storage on disk to be segmented by eTLD+1 or some such? As for the certificate issues, did you file bugs? I think there definitely is interest in making the web suitable for this over time. It would help if the requirements were documented somewhere. There are no universal and agreed-upon requirements for dealing with client-certificates which is why this has been carried out in the past through proprietary plugins. These have now been outlawed (for good reasons), but no replacement has been considered. There were some efforts recently http://www.w3.org/2012/webcrypto/webcrypto-next-workshop/ which though were rejected by Mozilla, Google and Facebook. And there we are...which I suggest a short-cut: https://lists.w3.org/Archives/Public/public-web-intents/2015Feb/.html which initially was pointed out by Ryan Sleevy: https://lists.w3.org/Archives/Public/public-webcrypto-comments/2015Jan/.html Anders
Re: The futile war between Native and Web
On 2015-02-16 17:27, Michaela Merz wrote: Well - there is no direct pathway between the browser and the chip card terminal. And .. of course can the user manipulate all of Javascript client-side, eg. patch variables to his liking. But that is true (though harder) for any code that runs client side. The card terminal could provide a rest api that would allow a browser to post the amount to be paid into the terminal. That would be a very safe solution - not only in regard to web, but in regard to any communications with the card terminal as there would be now vulnerable code on the client. On the web there is no card terminal so it has to be emulated by client code. Who is supposed to sign this code? How is it invoked by a web merchant? How it is distributed? So my discussion has nothing to do about vulnerability of JS. Anyway, I think we will soon see that Apple simply calls their Apple Pay App from the web because it preserves all the goodies as is. Why is simple and practical wrong? Anders mm. On 02/16/2015 10:19 AM, Anders Rundgren wrote: On 2015-02-16 16:54, Michaela Merz wrote: This discussion is (in part) superfluous. Because a lot of people and organizations are using the web even for the most secure applications. Heck - they even send confidential data via plain old e-mail - they would even use AOL if that would still be possible - in other words: Most simply don't care. The web is THE universal applicable platform for .. well .. everything. So - it's the job of the browser vendors in cooperation with the web-developers to provide an environment that is up to the task. And I strongly believe that a safe and secure JavaScript environment is achievable as long as the browsers do their part (strict isolation between tabs would be such a thing). On paper it is doable, in reality it is not. You would anyway end-up with proprietary AppStores with granted Apps and then I don't really see the point insisting on using web-technology anymore. General code-signing like used in Windows application doesn't help, it is just one OK button more to click before running. Anders I am aware of the old notion, that JavaScript crypto is not safe. But I say it *can*' be. CSP is a huge leap forward to make the browser a safe place for the handling of confidential data. Michaela On 02/16/2015 03:40 AM, Anders Rundgren wrote: On 2015-02-16 09:34, Anne van Kesteren wrote: On Sun, Feb 15, 2015 at 10:59 PM, Jeffrey Walton noloa...@gmail.com wrote: 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. What would you suggest instead? 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), ... So you would like physical storage on disk to be segmented by eTLD+1 or some such? As for the certificate issues, did you file bugs? I think there definitely is interest in making the web suitable for this over time. It would help if the requirements were documented somewhere. There are no universal and agreed-upon requirements for dealing with client-certificates which is why this has been carried out in the past through proprietary plugins. These have now been outlawed (for good reasons), but no replacement has been considered. There were some efforts recently http://www.w3.org/2012/webcrypto/webcrypto-next-workshop/ which though were rejected by Mozilla, Google and Facebook. And there we are...which I suggest a short-cut: https://lists.w3.org/Archives/Public/public-web-intents/2015Feb/.html which initially was pointed out by Ryan Sleevy: https://lists.w3.org/Archives/Public/public-webcrypto-comments/2015Jan/.html Anders
Re: The futile war between Native and Web
On 2015-02-16 18:07, Anne van Kesteren wrote: On Mon, Feb 16, 2015 at 5:53 PM, Anders Rundgren anders.rundgren@gmail.com wrote: Anyway, I think we will soon see that Apple simply calls their Apple Pay App from the web because it preserves all the goodies as is. Why is simple and practical wrong? Is anyone saying that's wrong? What's wrong is the comparison between native and web. Well, I have provided a concrete solution for combining native (running trusted code) and web (running untrusted code) which I originally got from Google and is already in practical use. If somebody has a better solution there's huge community out there who is waiting. Anders Apple Pay could not have been created through the App Store model either. It's a feature of iOS coupled with the hardware found in the latest iPhone. If we get browsers that operate at the OS level they could deliver similar features. If they don't operate at the OS level they could integrate with what the OS provides. Either way this is something that requires new APIs and UX, whether native or web.
Running trusted code in the untrusted web - A writeup
For those who frown at the idea of calling native (trusted) applications from the untrusted web [1], here is a writeup of how you could run trusted web-code inside of a untrusted web-application. Regarding the use-cases, there are many ranging from phone-dialers on support pages to payments [2]. Since you probably do not want to rewrite browsers from scratch, the most logical is building on running trusted code in IFRAMEs so that the existing protection scheme can be reused. The difference with existing IFRAMEs is that the code must be trusted by the platform which also means that it must be fetched from the platform: iframe trustedapp=com.example.PaymentRequest ... /iframe This code should appear to the browser as coming from a virtual domain. The only communication possible is through postMessage(). If the referenced application isn't available in the local cache, the browser should presumably consult the device-specific AppStore. A side-effect of this specification is that trusted web-applications may be device-specific which actually is a plus since it reduces the need to standardize access to the OS and HW layer. That is, there could be a new class of standardized trusted web-applications where only the invoke/postMessage part is standardized! Cheers, Anders Rundgren 1] https://lists.w3.org/Archives/Public/public-web-intents/2015Feb/.html 2] Although not entirely compliant with the above, the following demo https://mobilepki.org/WebCryptoPlusPlus does the same thing from a user's perfective.
Re: The futile war between Native and Web
On 2015-02-16 09:34, Anne van Kesteren wrote: On Sun, Feb 15, 2015 at 10:59 PM, Jeffrey Walton noloa...@gmail.com wrote: 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. What would you suggest instead? 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), ... So you would like physical storage on disk to be segmented by eTLD+1 or some such? As for the certificate issues, did you file bugs? I think there definitely is interest in making the web suitable for this over time. It would help if the requirements were documented somewhere. There are no universal and agreed-upon requirements for dealing with client-certificates which is why this has been carried out in the past through proprietary plugins. These have now been outlawed (for good reasons), but no replacement has been considered. There were some efforts recently http://www.w3.org/2012/webcrypto/webcrypto-next-workshop/ which though were rejected by Mozilla, Google and Facebook. And there we are...which I suggest a short-cut: https://lists.w3.org/Archives/Public/public-web-intents/2015Feb/.html which initially was pointed out by Ryan Sleevy: https://lists.w3.org/Archives/Public/public-webcrypto-comments/2015Jan/.html Anders
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: [coord] Is there still a need for WebApps + SysApps meeting at TPAC?
On 2013-10-31 16:04, Nilsson, Claes1 wrote: I want to say that we are interested in implementing the JSON manifest and also to discuss additions to the manifest. Content security policies have already been mentioned and we are looking at something similar to http://developer.chrome.com/extensions/contentSecurityPolicy.html, which allows inclusion of content security policies to support secure hosted apps by defining schemes (https:) that are allowed to use for whitelisting secure origins from which scripts should be accepted. http://developer.chrome.com/extensions/manifest.html The definition of the signature seems to be missing here. If JSON still is the choice, JWS (http://tools.ietf.org/html/draft-ietf-jose-json-web-signature-17) or JCS (https://openkeystore.googlecode.com/svn/resources/trunk/docs/JSON-Clear-Text-Signature-Scheme.pdf) are the two hottest candidates. Cheers Anders I would also like to better understand what a meta tag solution would mean. However, as the manifest specification editor Marcos unfortunately is not able to participate in TPAC I am not sure on the most efficient way to discuss the manifest, a joint SysApps-WebApps session with Marcos calling in or a mailing list discussion. My main point is to stress our interest in the manifest specification and additions to it. BR Claes -Original Message- From: Marcos Caceres [mailto:w...@marcosc.com] Sent: den 31 oktober 2013 15:20 To: Arthur Barstow Cc: public-webapps; public-sysa...@w3.org Subject: Re: [coord] Is there still a need for WebApps + SysApps meeting at TPAC? On Thursday, October 31, 2013 at 12:51 PM, Arthur Barstow wrote: [ My apologies in advance for cross-posting but I think it's needed for this coordination topic. ] Hi All, Last June, the Chairs of WebApps and SysApps agreed to allocate a time slot @ TPAC Shenzhen for a joint meeting from 16:00-17:00 on Monday November 11 [1]. The one topic currently identified for that slot is the Manifest spec. Marcos - would you please summarize the overall `state` of the Manifest spec (f.ex. the status, next steps, blockers, and such)? I would also like to know if you think there are some related issues that could potentially benefit from some meeting time, or if we can use the list server instead. I’m trying to figure out (or get agreement amongst those interested in implementing) if we should have a JSON manifest or go with the meta tag solution (or both) - this is a blocker. Current steps are for me to investigate the solutions and usage on teh Webs. No significant work has been done on the spec since it moved over to WebApps. I don’t mind if we do it on the list. But if others want me to dial in to discuss, I’m ok to do that. All - are there any other topics to discuss? Not from me. -- Marcos Caceres
Re: Web Sigining in Action
I think a problem is that it is unclear where a certain issue belong. IMO all of the stuff I wrote about belong to the app-area but some people think it is about security only. XML protocols in browsers is an app, at least as I see it. Anders - Original Message - From: Marcos Caceres marc...@opera.com To: Anders Rundgren anders.rundg...@telia.com Cc: channy cha...@gmail.com; WebApps HG public-webapps@w3.org; Jungshik Shin jungs...@google.com; Gen Kanai g...@mozilla.com; Ian Hickson i...@hixie.ch; Thomas Roessler t...@w3.org Sent: Tuesday, March 24, 2009 22:24 Subject: Re: Web Sigining in Action On Tue, Mar 24, 2009 at 9:37 PM, Anders Rundgren anders.rundg...@telia.com wrote: Hi Everybody, There are simply TONS of issues related to usage of certificates in conjunction with a browser. If you want, you can take a peek at the current thread client certficates unusable? in mozilla-dev :-) I personally find it annoying that there are maybe some 100M USB memory sticks in circulation that could have been a wonderful container for keys but unfortunately it never happened. Well, a few US compaines tried to create proprietary solutions with SanDisk but (of course) they all failed. Who want to *pay* for a card driver? It is really something that you would like the OS to have from the beginning! What does this have to do with Web Signing you may wonder? Well, IMO we need to take this in a step-wise fashion and if we can't even get the keyring´right, it seems that the rest will be of secondary interest. That doesn't say I'm not interested in Web Signing, I have just put it on the back-burner in favor of key storage and execution. The absence of a useful keygen standard is a disaster. Will the browser- vendors be able to address this issue? I don't expect that. Regarding Web Signing a large groups of banks have turned to MSFT to get this solved. I think they are overly optimistic about MSFT's capability and interest in this area but it is a good thing that they are trying at least :-) Based on 13 years of experience with eID, I believe most of the web standards in this are will not come from standardization forums because they have proved to good for really general purpose stuff, but much less successful for applications like Web Sign and keygen. A scheme like my current KeyGen2 would not take less than 3 years to standardize and the result would probably be not be very useful anyway. Why? Because there are too many choices and people cannot work under such premisses. Whatever keygen or WebSign we will get, it will most certainly be an open source effort rather than a standard. What W3C could/should standardize is a way to get XML protocols running in a browser and leave the content parts to other groups. IETF's KEYPROV will fail as hard as XKMS did if we ignore the browser connection all the time. I see. thanks for the history. However, what, if anything, should our working group do? I don't see anything that is in scope or anything directed at any one of our specifications. If we are screwing something up somewhere, then please be clear as to where and we will do our best to fix it. Kind regards, Marcos -- Marcos Caceres http://datadriven.com.au
