See also: IRC log
<inserted> Web Bluetooth API: Grumpy goes flying
<inserted> Web Bluetooth Samples
<inserted> BLE Peripheral Simulator
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
<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
<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
<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?
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
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
<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
<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
<anssik> https://www.w3.org/community/web-nfc/
<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
This is scribe.perl Revision: 1.140 of Date: 2014-11-06 18:16:30 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: i|Some links|-> https://www.youtube.com/watch?v=tRMcMDIyIGQ Web Bluetooth API: Grumpy goes flying Succeeded: i|Some links|-> https://googlechrome.github.io/samples/web-bluetooth/ Web Bluetooth Samples Succeeded: s/characteristic/descriptor/ Succeeded: s/youre/your/ Succeeded: i|Some links|-> https://play.google.com/store/apps/details?id=io.github.webbluetoothcg.bletestperipheral https://play.google.com/store/apps/details?id=io.github.webbluetoothcg.bletestperipheral Succeeded: s|Some links: https://www.youtube.com/watch?v=tRMcMDIyIGQ, https://googlechrome.github.io/samples/web-bluetooth/, https://play.google.com/store/apps/details?id=io.github.webbluetoothcg.bletestperipheral|| Succeeded: s|https://play.google.com/store/apps/details?id=io.github.webbluetoothcg.bletestperipheral|BLE Peripheral Simulator| Succeeded: i|[ Spec ]|topic: Web Bluetooth specification Succeeded: i|[ Spec ]|-> https://webbluetoothcg.github.io/web-bluetooth/ Web Bluetooth Succeeded: i|[ Security ]|topic: Web Bluetooth security Succeeded: i|[ Security ]|-> https://webbluetoothcg.github.io/web-bluetooth/#security-and-privacy Security and privacy considerations Succeeded: i|[ Security ]|topic: Web Bluetooth Attacks on devices Succeeded: s/topic: Web Bluetooth Attacks on devices// Succeeded: i|[ Attacks ]|topic: Web Bluetooth Attacks on devices Succeeded: i|[ Attacks ]|-> https://webbluetoothcg.github.io/web-bluetooth/#attacks-on-devices Attacks on devices Succeeded: s/mision/mission/ Succeeded: s/100ft/100m/ Succeeded: s/... but two probably couldn// Succeeded: s/sever/server/ Succeeded: s/chair: jyasskin/chair: jyasskin, anssik/ Succeeded: s/MyFair/MiFare/ Succeeded: s/on this/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./ Succeeded: s/write i/write it/ Succeeded: s/+q/q+/ Succeeded: s/jyasskin/kenneth/ Succeeded: s/.../dom:/ Succeeded: s/anssik/riju/ Succeeded: s/..../.../ No ScribeNick specified. Guessing ScribeNick: timeless Inferring Scribes: timeless Present: Kenneth_Christiansen timeless jyasskin anssik dom kenneth_ aalfar riju jonathanj jungkee jocelyn mfoltzgoogle ShaneM Dan Appelquist Ari_Keranen brsun zkis shalamov Agenda: https://www.w3.org/wiki/TPAC/2015/ad-hoc-meetings#Web_Bluetooth_and_Web_NFC Got date from IRC log name: 26 Oct 2015 Guessing minutes URL: http://www.w3.org/2015/10/26-web-bluetooth-minutes.html People with action items:[End of scribe.perl diagnostic output]