- From: Anders Rundgren <anders.rundgren.net@gmail.com>
- Date: Mon, 19 Jun 2017 06:15:51 +0200
- To: public-web-nfc@w3.org
On 2017-06-18 14:56, Zoltan Kis via GitHub wrote: >> this use case as well as most of the other listed use cases are really about providing Web based alternatives to native "Apps". > > Actually quite the contrary. This group intended to work on Web-specific use cases of NFC (as a transport/interaction mechanism) rather than providing a generic NFC API for making Web based alternatives to native apps. This is also the reason for departure from the lower level APIs of the former NFC WG. And again, the payment scenarios did no mean to _do_ payments with Web NFC, but rather, do *something else* when an NFC payment is done. > To be fair, the charter corresponds to what you are saying since the charter doesn't mention native Apps. However, for developers of mobile applications the choice between native Apps and Web Apps is very significant since these options have quite different characteristics. Web NFC is constrained by the Web Security Model and therefore only supports a tiny subset of what you can do with native Apps. Due to other limitations imposed by the Web Security Model, I believe developers will find Web NFC of very limited utility. Intel have tried multiple times getting hardware based security into the Web but all these efforts have failed due to the same basic issue. Bridging schemes (like the W3C Web Payments API and Chrome's Native Messaging) OTOH, effectively off-load most of the security/privacy to high-level applications instead of building on a non-granular and static browser security and permission system. "Installable" Web applications having extended capabilities could change this but IMO this is never going to work satisfactory due to the development pace we have today. Anders http://webpki.org/papers/permissions.pdf
Received on Monday, 19 June 2017 04:16:28 UTC