Web Bluetooth and Web NFC -- 26 Oct 2015

Web Bluetooth

<inserted> Web Bluetooth API: Grumpy goes flying

jyasskin: for Bluetooth, I wanted to talk about the spec and show what we have in Google Android
... get everything aired, make sure everyone is on the same page

Web Bluetooth specification

<inserted> Web Bluetooth

[ Spec ]

jyasskin: it goes through the security issues,
... talks about how you can access and discover devices

[ Security ]

jyasskin: first question that everyone should ask when we offer to give Web Sites access to devices is "how to make that safe"
... the first thing is to give the user a chooser to let users choose what devices to have access to
... gets user attention, and gives much more limited scope
... we also only allow this API for https: content

Web Bluetooth Attacks on devices

<inserted> Attacks on devices

[ Attacks ]

jyasskin: we worry about web pages getting access to sensitive data
... we worry about web pages attacking sensitive devices
... we only allow access to the GATT protocol
... Bluetooth is divided into Classic (2.1/3) and LE (4+)
... there's a new protocol for LE called GATT: Generic Attribute Profile
... we in Chrome only initially support BT LE (4+)

<dom> dom: so there is nothing in the spec that prevents it to work on classic bluetooth as long as it's on top of GATT

<anssik> https://webbluetoothcg.github.io/web-bluetooth/#gatt-interaction

jyasskin: if people want me to cover GATT, I can do that now
... the reason GATT expands to GATT is it's Generic + ATTribute
... GATT defines a hierarchy of Services, Characteristics, Descriptors
... each device has a list of Services
... any semantic thing will be a service
... I don't think any devices have "included services"
... a characteristic has a bytestream value and a list of descriptors
... characteristics could be "heartbeat measurement", "latitude", "longitude"
... there's a descriptor for subscribing
... Services, Included Services, Characterstics, and Descriptors all four have UUID types identifying them
... one of the Descriptor types is the method for subscribing to notifications
... we expose the notion of subscribing to notifications, rather than the descriptor

Web Bluetooth security

<inserted> Security and privacy considerations

[ Security ]

jyasskin: because most GATTs are short values, it's easier to write a parser
... we expect there will be fewer attacks
... every Bluetooth device is open to the air
... everyone can attack it

<JonathanJ> https://developer.bluetooth.org/gatt/Pages/GATT-Specification-Documents.aspx

Josh_Soref: is it true that they're hardened or is it hand waiving?

jyasskin: it's hand waiving
... it's possible to identify devices
... each device has an address, either immutable, or changeable
... to avoid identifying devices, we don't expose the device address
... it's still possible for a device to leak its identity

dom: a device could be part of the attack?

Josh_Soref: or it could be poorly implemented and leak itself

QQQ: can you connect to a specific device by ID?

jyasskin: no, the user has to choose the device from the picker
... you could forcibly filter by criteria
... this mitigates a piece of the privacy risk (by not exposing MAC addresses)

[ Discovery ]

jyasskin: you call requestDevice(/* filters */)
... currently the spec only provides filters by UUID
... looking at devices, many don't advertise services
... some only provide names
... we're also looking at manufacturer name
... so the filter will soon include those two fields

dom: does that increase the fingerprinting surface?

jyasskin: it does
... manufacturing name is key-value pairs
... all iBeacons broadcast the same name in Apple's namespace
... and none of this is particular devices

Travis: what's the end result?

jyasskin: the browser will filter nearby devices to matching devices and then show the user a list of nearby matching devices

Josh_Soref: does the UI favor/highlight paired devices?

jyasskin: not today
... let me show you Google Chrome Dev with its select
... any M device supports this
... I can walk around
... here I'm saying get battery service, and it shows a list of devices that are nearby
... right now, we show paired + discovered (thus a device will be shown twice)

Josh_Soref: do users really understand that pairing fully exposes everything?

jyasskin: we're trusting that users will understand that pairing is dangerous

dka: the model is origin limited per device, right?

jyasskin: yes

dka: e.g. individually pairing Skype.com vs. Hangouts would be distinct pairings?

jyasskin: ys

Josh_Soref: but if I pair Skype.com and then use Outlook.com it might work?

jyasskin: it currently only allows top level windows
... but we need to look at iframes

anssik: how did Geolocation solve this?

dom: they didn't
... I did a review
... none deferred based on top level or not

anssik: I think it's a good idea to take a decision, or limit to top level
... perhaps we could ask TAG

jyasskin: there's a proposal for a top level attribute

anssik: it's used for full-screen

dka: is there an issue?
... I could open an issue in our repo to comment on this issue

<dom> https://github.com/WebBluetoothCG/web-bluetooth/issues/57 ?

jungkees: isn't this the space where secure-contexts come in

<dom> https://github.com/WebBluetoothCG/web-bluetooth/issues/57 mentions iframe at least

jungkees: don't allow anything in non-secure contexts

jyasskin: we're talking about more restrictions on top of that
... it already has to be a secure-context

mfoltzgoogle: in some of these device apis, it's challenging for there to be a human readable description
... what is there for human readable?

jyasskin: we've punted on service descriptions, since it requires a registry of names

mfoltzgoogle: does BTLE have a registry?

jyasskin: no
... if they did, we'd use it
... for device names, we use the device name
... some don't even have names at all
... we could use the BT MAC
... we could specify that the device name is empty
... there's also an escape hatch in the spec to allow the UA to show non matching devices
... Chrome currently doesn't

dom: does that have security implications?

Josh_Soref: the user there has to choose to shoot themselves in their foot?

dom: if you promise people money

jyasskin: if the web site wants the user to pick a particular device, they can filter for that device
... if the user picks a device that doesn't have a matching service, they'll find the service isn't present
... the expected service won't be there, a rejected promise, and the page won't work

dom: does it require a user interaction?

jyasskin: i'm using can-show-a-popup from HTML

dom: does that allow easily to repair with the same device?

jyasskin: i have an issue to find the devices you've selected in the past
... the security model is, if you pair w/ a device, it's yours until you unpair it
... there's no way to get those devices

dom: for users, you'd have a per-origin-id

jyasskin: and you'd get a list of devices you've been paired

Josh_Soref: I'd favor having the UA manage the memory instead of the App

jyasskin: our security people asked users what they expect
... users expect permission pairing to last forever
... a demo we have is a set of juggling balls
... we're currently missing the api to request multiple
... and there's no way to know if you've already paired one
... i think the web site should be able to present its own UI
... and the UA should be able to identify which ones you've paired
... the web page could call it multiple times

anssik: for enumerateDevice()

dom: with enumerateDevices() you get the full list of available devices on the platform, with an ID for getUserMedia()
... depending on the browser, typically, in chrome, once you're granted access to a microphone on an https origin, that applies to all microphones for that origin

Travis: are uuids hard coded into devices

jyasskin: yes, service uuids are kind of protocols, so uuids identify protocols
... uuid is what it's called in Bluetooth, everyone expects it to be that

[ BluetoothGATTService ]

jyasskin: someone suggested that UUID uuid should be `type`
... if we were designing from scratch, we would do this

Travis: we should be designing for the future

Josh_Soref: WebGL made mistakes like this, can we avoid this?

Travis: for the record, WebGL 2 is redesigning for this

mfoltzgoogle: how feasible would it be to add origin lists for devices?

jyasskin: I've gone to the BT SIG and tried to start that conversation
... i'm confident we should do that through them rather than starting here
... they weren't very receptive
... it's not clear that they were very receptive
... not clear if we haven't explained it well, and not sure if they understand
... basic idea would be to allow device to advertise which origins which origins it's willing to talk to it
... and tell it which origin is talking to it
... and if multiple tabs spoke to it, we'd have to switch modes with it
... useful for the web model
... safe enough to do that as an opt in thing
... always have to deal w/ devices that don't advertise that service
... safe enough to allow devices to talk to that
... and then as we talk to devices, some manufacturers will talk to SIG
... also useful for native devices
... you pair devices to phone, but you have multiple native apps, some safer than others

dom: what's your relationship w/ sig?

jyasskin: Google is part of the sig
... the CG isn't

dom: a few years ago, we had a call with the sig

jyasskin: i don't know
... I don't know if the CG could be part of the sig

dom: thinking a liaison between W3C and BT SIG

dka: i could see where that would be useful
... get people in BT SIG talking about work going on here
... what's going on w/ W3C API

jyasskin: it would be useful to have an official liaison
... BT SIG has an Internet WG, for a router for GATT traffic, totally insecure
... it would help them to have communication w/ web people, help us to have communication w/ them
... i don't have the bandwidth to be that

dom: part of a broader conversation
... about Web BT CG wants to move forward
... I don't think W3C could offer a Liaison for a CG

<Zakim> dom, you wanted to ask about re-pairing

Josh_Soref: I'm concerned, I buy a product, I expect to be able to use my device w/ an app of my choice, not just the broken one from my vendor

jyasskin: we'd like to support CORS

dom: there are discussions on a hardware WG to access SE
... the question of SE has whether should only connect to some origin
... if the hardware guys align with the web origin model

jyasskin: we've been talking with Ryan Slevi
... main argument for more access to BT than hardware is that BT is exposed to random radio waves
... with BT LE, a lot of people aren't pairing
... fitbit doesn't do BT pairing, they have their own encryption system
... I haven't done the survey to make this rigorous
... manufacturers are doing security w/o relying on pairing

dom: i thought encryption in LE was quite weak

jyasskin: in 4.2 it gets better, in 4.0 it's quite weak
... another reason manufacturers are routing around it

[ BluetoothDevice ]

jyasskin: a BT Device has properties, vendor, ...
... some are redundant with particular gat service
... we have a gatt server: connnectGatt()
... perhaps in some cases you don't need that (advertising?)

[ BluetoothGATTRemoteServer ]

jyasskin: this has a list of services
... you query one at a time, or get all of a set

[ BluetoothGATTService ]

dom: when you gain access to a device, you get access to all services

jyasskin: when you call requestDevice(), you're limited to the services you asked for

dom: then why were you ...

jyasskin: we're thinking TAG

Josh_Soref: IANA?

jyasskin: the people writing the spec will probably end up designing the registry
... it's tricky, there's reason to lie on the registry

dom: that's a way to access?

jyasskin: currently we have a blacklist of services, it's in github
... we'd prefer a whitelist
... but we'd have to be pretty permissive to let people add themselves
... risk that an attacker adds a service to the whitelist
... no good way of vetting

<anssik> https://github.com/WebBluetoothCG/registries/blob/master/gatt_blacklist.txt

dom: you're importing this into Google Chrome?

jyasskin: not yet, we plan to update dynamically
... get that recognized in all browsers fairly quickly

Josh_Soref: how do you defend against attackers who block content?

jyasskin: we need them to have clean access to the web fairly regularly
... if you're not able to update your browser periodically, the attacker can exploit your browser

mfoltzgoogle: the UC in your example of pairing your wearable/heartbeat device
... seems like a good fit for ServiceWorker
... you don't support Transferable

jyasskin: we don't have the permission model for permission access to background

mfoltzgoogle: i'm confused

jyasskin: users expect that things are accessible while they're using an app
... that's not true on Android

dom: it's better on iOS?

jyasskin: yes, iOS changed, it will ask you later if you "were aware that it was getting your info in the background"

anssik: do you want to go over issues?

jyasskin: i think the free-form discussion has been good
... I can also show a video

<jyasskin> https://www.youtube.com/watch?v=tRMcMDIyIGQ

dka: Physical Web?

Web Bluetooth General Roadmap

jyasskin: you can't implement the physical web scanner in the current api
... I filed a TAG issue ... the notion of a referring device
... both NFC and Bluetooth and USB could open a web page in response to a device
... if the user has chosen to open a web page, they shouldn't get a redundant device
... there should be a way to say "here's the device that opened you"
... initially we could have a Navigator.requestingDevice...
... user clicks the device in their list, web page opens, and can communicate with the device

dka: interesting

jyasskin: roadmap...
... scanning
... - being able to figure out what devices are nearby, we have an idea for how to do that permission
... - upgrading from scanned to permission
... background -- from a ServiceWorker
... acting as a Bluetooth peripheral, possibly over the classic protocol

Josh_Soref: why do you care about Classic v. LE

jyasskin: sorry, I meant:
... acting as a Bluetooth peripheral
... separately: acting as a Bluetooth classic peripheral
... we'll do these after we do the easier pieces

dka: the issue around physical web, i didn't understand that flow
... is that part of the normal ideas?
... my understanding was you'd have a BTLE advertising a URL
... once you start a thing, you open a url, you're done w/ the device
... but you're imagining the web page to maintain a connection to the device

jyasskin: yes
... imagine the happy meal toy
... a turtle w/ a couple of LEDs and can play a bit of audio
... it advertises a physical web url
... it has BT but not Cell/WiFi
... the web page has "be happy"/"be sad"/"be green"
... you control your happy meal toy from your phone

dom: the assumption is that clicking the url gives you permission to interact with the device

jyasskin: security is that clicking it has established something to communicate with it
... but it's a physical web device, it's granting its concent

Josh_Soref: what's the range of physical web

jyasskin: 100m
... range is pretty far

Josh_Soref: i'm worried about devices

jyasskin: you can build the antenna and attack

shayne: are devices identical?

jyasskin: it's possible to make several chips that are truely identical
... but two probably couldn't coexist near eachother

jocelyn: you mentioned act as a server

jyasskin: you guys have that
... there's advertise and act as a server
... a physical web beacon only needs to advertise, it doesn't need to serve

dom: for standardization
... have you made any progress on moving to a WG?

jyasskin: i don't think anyone objects to moving to a WG
... we're about to have a second implementation
... Chrome isn't finished
... I think we'd be totally happy going to a WG

dom: DAP is rechartering
... I guess you'd rather be in Web Platform

jyasskin: I think so

dom: Web Platform just rechartered

jyasskin: we should get on their queue for getting in

Travis: they have a process for pulling things in, and the charter is only one year

jyasskin: I'm not the whole CG, but I think a lot of it is here
... does anyone think we should stay as a CG?

dka: I'd hope to see implementations out there
... I'd hate to see people slowing down their implementation based on "oh wait, it'll be a WG, we should wait for LC"

anssik: I think we should be able to Fast Track, it's better than FPWD

dom: moving to WG is better than being effective CR

dka: the controversy around the TPAC App
... giving everyone connected with this, some additional justification for making this happen
... remove technical barriers

jyasskin: I think they want the scanning api

dka: features like these are what people in native app community point to
... we don't have this, we don't have that
... message needs to be, we have this or it's coming

jyasskin: I don't think moving to a WG is going to slow anything down

Josh_Soref: people mentioned beacons

jyasskin: a subsequent version of this standard should support scanning for beacons

dka: Chrome on Android and iOS can scan/notify you about physical web beacons
... that's different from advertising beacons

mfoltzgoogle: for physical web UC, do you anticipate the platform to discover, and then launch a web app prepared w/ this
... if you support that w/ presentation api, your api changes, from scanning to allow UA to present a Promise

jyasskin: hook in this API is navigator.bluetooth.requestingDevice
... tells you what caused your page to load, like "referrer"
... no need for an event

dom: do you have that in presentation API?

mfoltzgoogle: presentation doesn't, but it has an event "your page is connected to a presentation"

anssik: it's a boolean
... you have screens, or you don't
... a precheck
... join our meeting Th/Fr to discuss more

mfoltzgoogle: a web developer to use this has to have pretty intimate knowledge of exact attributes exposed by a service
... is it consistent enough across manufacturers, do you expect people to use it directly or wrap?

jyasskin: i think both, I think people will use libraries to abstract it
... our developer relations person has built web components that abstract it
... there will be libraries
... when two manufacturers expose the same data with different services
... requestDevice() allows that, you can allow a list of services or'd

JonathanJ3: do you need anything for 4.2?

jyasskin: we don't think there's anything extra you need?
... there's the beginning of a stream for tethering, we're not doing that yet
... the rest would be underneath

Web NFC

anssik: plan was to go through TAG feedback
... valuable concrete proposals
... thanks Travis for the feedback
... we can start w/ a quick overview of the spec
... only a handful of people have seen the spec

Web NFC Spec

<anssik> https://w3c.github.io/web-nfc/

kenneth_: idea is to expose NFC functionality to web developers
... in a web friendly fashion
... not doing everything you can do w/ NFC
... we looked at NDEF
... write tag (image, json, text), and read that back
... basic UC

anssik: does everyone here know what NFC is?

kenneth_: first spec ver is reading/writing data to passive tags
... then passing (one off) data to another phone

[ Demo ]

anssik: there was a NFC UC demod by riju reading/writing tags
... another is pushing data between active devices (mobile devices)
... another is handover to another wireless connection type
... nfc->BT/WiFi
... payment

kenneth_: we haven't looked at those UCs

dom: the api doesn't cover that

kenneth_: the api covers reading, writing, pushing data to a peer

[ NFCSecure ]

kenneth_: when we started looking at WebNFC, the idea was that it should be easy to use, and not have prompts
... when we looked at NFC, we said that it should write the domain and path

dom: there have been a number of discussions on whether origin should be complete
... i wonder if by doing this here, you're hitting one of the reasons

kenneth_: by using the path, when you listen to message, you give a path with wildcards

anssik: host on w3c.github.io
... you have per directory/per path separation

kenneth_: NFC is inherently not very secure
... like writing on a piece of paper and putting it in their home
... if someone writes it w/ web, they could read+write it w/ native app
... if you want to make it secure, you have to use certificates or similar on top of it

[ NFCAPI ]

anssik: navigator.nfc (being discussed)
... .requestAdapter()
... we got feedback on that

Josh_Soref: i'd object to that name

anssik: NFCAdapter

kenneth_: .watch() -- subscribe to what you want to listen for
... .pushMessage() where you send to a tag
... they're all Promise based
... there's also a cancel, because Promises don't have cancelable yet

anssik: url,
... there's kind + type, those aren't very clear

dom: limited to your domain

kenneth_: if you want to opt into reading non origin bound (legacy), you can

anssik: NFCRecord

Travis: is there a practical limit on tags?

kenneth_: some 4MB, some 50k
... it would reject a promise if it doesn't fit

anssik: NFCRecord is what's recorded in the tag

kenneth_: there's something called "MiFare" (Phillips)
... the 4 types are basically company specific

<zkis> MiFare

dom: it gives you a range

Travis: no reason to have an api to ask for space available

kenneth_: to access some of the storage on some of these types
... there are extra protocols
... we haven't looked at exposing that
... from what i've heard, it's very complex

anssik: we're abstracting all that out

dom: isn't that an interop nightmare?

anssik: if you target the types defined in NFC forum
... I think we're missing that normative reference to the NFC spec
... we wanted to set the bar based on what's out there
... common ground based on available implementations

riju: the demo for this app was 137bytes, using nfc-type-2

dom: why do you need the promise for watch?

kenneth_: the reason is for how to deal w/ permissions and exceptions

anssik: return something, and user rejects ? -- permission

kenneth_: well "UAs 'could' implement a permission prompt"

anssik: `obtain watch permission`

jyasskin: we've had disagreement between sicking and slightlyoff on this: sicking thinks the spec should call out everywhere the UA might show a dialog; slightlyoff thinks we should use Promises on more things so UAs can start showing dialogs in the future if we realize we need more prompts.

anssik: for forward compatibility reasons, we want to return a Promise
... even if it isn't really necessary today

mfoltzgoogle: NFCMessage encapsulates multiple records instead of an NFCMessage?

anssik: that was TAG Feedback

mfoltzgoogle: this seems fairly different from other apis

<zkis> NFCMessage is multiple records

mfoltzgoogle: perhaps Streams API?

anssik: I think Streams developed after this API was developed
... we decided we wouldn't make progress if we blocked on Streams
... we should revisit Streams

kenneth_: what's the status of streams in chrome?

<zkis> streams would not be fit here, since developers likely want to control NFC record structure

jyasskin: i don't know

TAG feedback on NFC

<anssik> https://github.com/w3ctag/spec-reviews/blob/master/2015/10/nfc-feedback.md

anssik: we opened issues for each one

<anssik> https://github.com/w3c/web-nfc/issues

anssik: thanks Travis
... we're booked until 6pm

dom: Meetup presentations start at 7pm, demos between 6pm and 7pm

Travis: you've talked about some of this in your introduction
... you can scroll to General Thoughts
... I didn't know anything about NFC before jumping into this
... I thought the spec was very good, well designed, integrated a lot of relatively new specs, surprising
... it felt like a WD
... kudos
... helpful to see the level of depth into the protocol level of NFC
... clear that the authors knew what they were talking about
... level of depth to allow a web based api to interoperate w/ a native hardware device that spoke NFC
... but it started to look like a foreign language very quickly w/ the NDEF records
... took a while to build a mental model
... high level, it's reading/writing strings
... there are two UCs here
... 1. interoperate w/ a Tag written via non web app
... so you need access to some of these lower level primitives
... 2. I have a string and want to write it
... could we make the simple things simple and the hard things possible
... I liked bringing the origin into the possible
... I want to do the simple thing, it's there, it just works
... security model made a lot of sense

kenneth_: with the default arguments, it should be possible to do simple things
... you shouldn't need to know what the mime types are
... maybe we could improve that by having better examples

anssik: we should highlight the preferred examples
... maybe in web context, this technology would be used differently from native

Travis: thinking about XHR
... it lets you do simple things, send text, get responses, you can do advanced things (working w/ headers), but you don't have to know HTTP headers

kenneth_: you can do that...

dom: is an NFCRecord like a blob?

anssik: we use `nointerface`
... we should make sure we optimize for the common UC
... e.g. giving default types

Travis: do you need to type out JSON v. Text?
... there's a JSON parser in the platform

dom: does JSON need to be typed somewhere?

kenneth_: the original idea was postMessage
... and serializing

Travis: that could work

<zkis> If we want to support developers controlling the structure of NDEF records, we do need to expose this. You can write Text in many different ways.

dom: who came up w/ the types?

kenneth_: we didn't want to use the NFC types

Travis: HTML defined the structured clone algorithm
... in indexedDB, you write stuff in, and you get the stuff out
... it seems like yours could be another client to that

kenneth_: it was my original idea
... I think annevk and zkis

<zkis> but then goodbye to the simple API - would we trust libraries for doing all NFC specific stuff?

kenneth_: if you want to interoperate w/ a native app

dom: would that work w/ the web origin?

kenneth_: the web origin would be ignored by native

Travis: also, Transferable isn't interoperable
... but JSON is standardized enough

kenneth_: cloning isn't standardized

Josh_Soref: perhaps you should record in the spec why you didn't go that way, so people don't need to ask again

riju: originally we thought we'd use an object
... but some wanted to only want to watch a url

<zkis> we could have a separate md on rationale, just like Web Bluetooth

riju: but if you use an object, you have to extract the data again

kenneth_: with a small tutorial, it's quite simple, people will figure it out

Travis: "filtering" in general
... what value does that bring to someone coming in and looking at a tag
... how do I know what to look for if i've never seen it before

kenneth_: filtering is more for the case
... like, us at intel, we have a lot of paths, and we don't control all of them
... I could say "i don't want to see stuff I don't understand"

Travis: this isn't me communicating w/ the tag
... it's me interoperating w/ my laptop, and I have a host of information there, and I want to scope it down

<zkis> filtering helps you to implement more efficiently an interaction system using NFC, when you know how you want to use NFC

kenneth_: only what you were writing

dom: I have 10 NFC tags in front of me, and only one of them has data I wrote
... browser only bother me when there's a tag I wrote

Travis: ok, that makes sense

Josh_Soref: you're missing the example of two apps from the same site

riju: filtering based on data (json)

kenneth_: originally, it was just URL, I don't remember when it got added

Josh_Soref: you're missing the prose explaining that you have 3 NFC tags on a table, with three different kinds of data, and an app that only wants to know about a tag if it has a certain kind of data

Travis: kind was a media type

kenneth_: the names came from annevk

riju: it was mediaType before

anssik: one kind is used in MediaTrack

kenneth_: `kind` came from annevk

Travis: conflict of TAG members

jyasskin: this could navigator.nfc.requestWatch() / navigator.nfc.requestPush()
... nfc doesn't give the right hook for permission

Travis: geolocation does have a namespace

dom: for Media, we have navigator.mediaDevices.{}

<zkis> see https://github.com/w3c/web-nfc/issues/67

kenneth: the reason we have an adapter is for development purposes

jyasskin: the same problem shows up in Bluetooth also
... you could have two Radios
... there's one interface, it uses both radios to accomplish the action
... if in the future, we should be able to add a way to enumerate

anssik: I plus one that approach
... we should optimize for the assumption which adapter
... isn't important

kenneth_: but it needs to be a promise

anssik: and they are a promise

[ anssik explains how to fix the spec ]

dom: don't i need to know which adapter

jyasskin: it should listen on both radios
... and it should try to write on both
... it should stop successfully once one successfully writes
... top level publishes to all
... and maybe later an advanced api

<zkis> wait, this is not how NFC works

dom: I agree to make things simple, as simple as they should be

Josh_Soref: it doesn't matter. UAs and hardware can do this

<jyasskin> zkis: Which piece doesn't work with NFC?

anssik: people seem to be interested in getting rid of the adapter abstraction
... zkis could you follow the discussion on irc?
... could you explain why the adapter abstraction is needed?
... what is the UC/limit?

zkis: the notion of representing the physical entity is important
... you may have an internal NFC adapter, and one via USB, you may want to choose which one to use
... you could have a default, trusted on the platform
... but it would be good to know which you're using

anssik: the proposal is to merge these together
... from jyasskin to use all the radios
... at the same time
... if you're watching, the user doesn't care which is closest to the tag(s)
... and in writing, the one that is faster does the operation
... making the api simpler for the common UC, where you only have one radio

zkis: I'm not sure you can physically touch the tags at the same time
... usually you could do what jyasskin is asking

jyasskin: are you worried about the race condition?

zkis: there's no such race
... there's some range for NFC, based on the adapter
... but I was talking about two tags, one per adapter

jyasskin: you have some race with which took affect first, most of the time it won't happen
... we shouldn't complicate the API for the common case

dom: first to succeed, if one

jyasskin: two tags, two adapters, what happens?
... it picks one
... watch could only resolve once
... push, it could push both

kenneth_: you might get both pushes

jyasskin: yes, but the user asked for it

Travis: in my feedback, I don't propose merging that way
... I was just saying that you choose the adapter, which if it were sync ...
... it seemed one step too far removed

anssik: so, rename method, and move it one level up

Josh_Soref: does it kill the model to let the UA know that there are tags present?

jyasskin: I don't think the API allows the UA to know that, it just allows you to publish

kenneth_: I don't think it's a problem
... I'd be ok with that

anssik: I'm not hearing full consensus in the room

dom: i'm unconvinced

<zkis> navigator.requestNFC() would be fine, returning a Promise<NFC>

anssik: the proposal from Travis was well received
... we may need to keep this open

<anssik> https://github.com/w3c/web-nfc/issues/66

kenneth_: can we get you guys go to the issue?
... and comment

dom: +1 on navigator.requestNFC over nfc.requestAdapter()

mfoltzgoogle: I compared the UC doc w/ the spec
... i was hard to see how the user bootstrapped something
... in the museum UC, I wasn't sure how I bootstrapped
... do I need to have an app?

<anssik> https://w3c.github.io/web-nfc/use-cases.html#reading-generic-information-in-a-museum

mfoltzgoogle: does the app open itself?
... if the UA sees a tag and there's a tab elsewhere for it, do i foreground that tab?
... similarly for P2P
... the spec doesn't include more about what prompts to include
... but maybe more text about what prompting could happen in those UCs

kenneth_: we haven't looked at the bootstrapping
... we could probably bootstrap w/ URLs
... need to think about it more and write some spec text

zkis: most phones have default behavior for tag types
... usual action is open browser
... we could open that page
... maximal from this
... this interferes w/ the basic behavior on the tag

dom: by default a url on a tag results in opening the url

Josh_Soref: could you have a .requestedTag ?

mfoltzgoogle: if the Android platform does a good job on that, it could
... a platform dependent feature

kenneth_: very interesting to explore

Travis: when you call .pushMessage()
... the api takes a list of NFCRecords
... ok, if that was asked already...

mfoltzgoogle: it seemed like you had an NFCMessage object, or use a Stream<NFCRecord>

kenneth_: this makes it easier from JS

Travis: in some cases you need a record, but taking a `string or Sequence<...>`

riju: a few asked about pushMessage for Tags v. Peers

Travis: two very separate scenarios
... you could have at most two thing in flight
... is it an expanding set of things?

dom: why does the method need the target?

zkis: "it has a history"
... in native APIs, we have very different ways to communicate to tags v. peers

anssik: and you can't look at the environment

zkis: that works for tags, but not for peers

Travis: "that's all you need"

zkis: you have to know in advance what you're touching

jyasskin: if the api didn't distinguish between tags and peers
... calling write wrote to the next thing you're near
... and calling read read from the next thing you're near

dom: the developer doesn't seem to care

riju: for push target, was there a default "any"

anssik: we used to have "any" as a target
... zkis, why did it lose that?

jyasskin: i think the was spec didn't have the notion that you had two pushes and had contradictions
... to make the distinctions he removed any
... but if we collapse the two, it just works

kenneth_: it comes from the fact that on android, we have an api "whenever a tag comes near my device: write this"
... but they're both async, if you want to write two
... but is that a valid UC?

anssik: I'm struggling a bit still
... why does a web developer deciding

kenneth_: I could promise-write
... push target for a device, send some kind of data
... push target for a tag, write something differently
... maybe i have timeouts

anssik: developers want to push different things

dom: in most cases you'd want to write to either a tag or device
... very few cases where you care
... that you want to make a distinction is unclear

anssik: I haven't heard a UC for this

Josh_Soref: me neither

anssik: we want to hear a good UC for two pushes in flight w/ long timeout, one for peer, one for tag
... if there's a strong UC for that, then ok
... I'll take an ACTION to either find a UC or ask for this to be collapsed
... by removing the target option entirely
... I see more people in this room who aren't part of this group
... you can join here

Joining NFC CG

<anssik> https://www.w3.org/community/web-nfc/

NFC Implementation Status

<anssik> https://github.com/w3c/web-nfc/

anssik: thanks Travis for coming here to give feedback to the group
... and thanks for your work in the TAG on doing reviews

kenneth_: would you be interested in implementing this?
... who should I talk to?

Travis: you could talk to me, I think we have some C# exposure, but not to the web

<jyasskin> Shameless pitch for the Web Bluetooth CG too: https://www.w3.org/community/web-bluetooth

anssik: I spoke w/ paul adden about NFC

dom: any plan for WG migration?

anssik: yes, I thought there'd be an effort
... and thanks Josh_Soref for scribing

- DRAFT -

Web Bluetooth and Web NFC

26 Oct 2015

Attendees

Contents