Day1

<gmandyam> Agenda: https://www.w3.org/2008/geolocation/wiki/2014-10-F2F#Tuesday.2C_October_28_.28Geolocation.29

<richt> ScribeNick: richt

DeviceOrientation - Quaternion Enhancement

<gmandyam> 1st presentation: https://www.w3.org/2008/geolocation/wiki/images/9/9a/DeviceOrientation_Quarternion.pdf

[Giri explains Euler Angles]

We used Euler angles because they are easy to communicate.

However, Euler angles have some inherent problems. In particular Gimbal Lock.

gmandyam: Developers convert Euler angles to their own representations e.g. Quaternions and Rotation Matrices
... Study by richt shows there has been a lot of inconsisitency in implementations.
... Each implementation has been using different coordinate frames as a device rotates.

Slides presented by gmandyam @ https://www.w3.org/2008/geolocation/wiki/images/9/9a/DeviceOrientation_Quarternion.pdf

richt: I put my concerns on adding Quaternions on the mailing list @ http://lists.w3.org/Archives/Public/public-geolocation/2014Aug/0021.html

tim: There was a proposal to add Quaternions to the W3C Geometry API which may be better than defining our own 'OrientaitonQuaternion' interface.

[Group is discussing not adding Quaternions to DeviceOrientationEvent interface and whether a new API surface would allow us to provide quaternions/matrices + transformation functions in a better way.]

gmandyam: Let's record this discussion. The information in these slides is not something we can move forward on (Quaternions in DeviceOrientationEvent interface)
... We need more implementer feedback.

<scribe> scribenick: gmandyam

It was decided that quarternions would not be added to the DeviceOrientationEvent at this time. This issue will be taken back to the mailing list.

Phil Archer from the W3C introduced the proposed W3C Working Group focused on spatial data representation.

The Working Group charter is being co-developed with the OGC (Open Geospatial Consortium)

<phila> Original charter

<phila> A slightly amended version of that charter is likely to be going to AC review in the enar future (not confirmed yet)

ScribeNick gmandyam

Rich Tibbett from Opera presented on absolute vs relative measurements for DeviceOrientation: https://www.w3.org/2008/geolocation/wiki/images/e/e0/Device_Orientation_%27alpha%27_Calibration-_Implementation_Status_and_Challenges.pdf

richt: 4 years ago, the work started on the DeviceOrienation API.
... The work hasn't really been revisited since then, despite the fact that there is variability in the data provided by different implementations.
... This presentation will focus on DeviceOrientationEvent.alpha calibration.
... alpha is the amt. of rotation around the z-axis.
... In 2010, Apple implemented this and said that they would not use magnetometer data. They are using gyroscope/acceloremeter, and their measurements are not absolute (e.g. true North referenced)

Apple's measurement is relative to when the API is "started"; at this time alpha is zero

gmandyam: What happens when a second web page is opened? Does alpha reiniitialize?

mounir: From a developer standpoint, it is probably not important.

richt: World or game-based frames are possible to derive on any platform, but it is difficult.
... absolute == undefined on iOS. There are also different warm-up periods for compass readings on different platforms. alpha values can drift over time and are subject to magnetometer.

rucht: Google Cardboard Magnetic Button is an example of the problems of magnetic interference issue.

richt: Proposal: eliminate inconsistency; choose between either relative or absolute orientation. Do not allow both to be supported.
... Proposal: get rid of magnetometer, i.e. only allow relative orientation events
... All browsers will then have the same game-based reference frame.
... Proposal (cont.): Have a separate magnetometer API.

Sensor fusion is not always done at the high-level OS (e.g. Android) level. It would be non-trivial to eliminate magnetometer from fused sensor orientation implementations.

mounir: Let us make a new API to allow for real-world and game-based reference plane. It is too problematic to change the existing DeviceOrientation API.

gmandyam: Sensor fusion is not always done at the high-level OS (e.g. Android) level. It would be non-trivial to eliminate magnetometer from fused sensor orientation implementations.

richt: Eliminating magnetometer in the sensor fusion will commonalize Android and iOS.

mounir: But the proposal requires Blink to implement webkitCompassHeading if the developer wants absolute orientation.

Tim: Sensor fusion happens at the HW level. Also, AR apps require absolute positioning.
... The iOS method seems to require JS processing for sensor fusion (i.e. adding magnetometer data back to the orientation value)

mounir: we need other implementors feedback. Can we at least reach out to Mozilla?

richt: Mozilla has proposed a magnetometer API in the past.
... It was proposed in DAP.It did not go anywhere.

gmandyam: Are developers not aware of the difference between iOS and Android?

richt: No they are not. They are not including the simple JS transformation necessary to transform from an absolute alpha to a relative alpha.

gmandyam: Conclusion - we cannot act on this proposal right now. Chair will solicit call-for-comments on mailing list. Mounir Lamouri will reach out to Mozilla to see if they have interest.

[ Break until 3:30 PM ]

Moving on to next topic: DeviceOrientation and ScreenOrientation alignment

Tim Volodine (Google) presenting: https://www.w3.org/2008/geolocation/wiki/images/e/e0/Device_Orientation_%27alpha%27_Calibration-_Implementation_Status_and_Challenges.pdf

<richt> scribenick: richt

[Tim Volodine presents slides above. 'Exposing Sensors in JS. Case Study: screen-adjusted device orientation']

marcos: these are eventing abstractions. generally, we could consider stream abstractions.
... perhaps consider these as streams.
... rather than 'events'.
... sensor initialization takes time. e.g. we need to set up the sensor and need to use e.g. IPC calls for that.

mounir: first Sensor API, you have 'null' value. Second approach when the Promise resolve you always have data (never 'null'.)

marcos: There are hundreds of ways to model these things.

mounir: The difference between the versions is whether we want to initialize async. How we want to resolve those objects (as Promises, callbacks, synchronously return a container object).

<gmandyam> My interpretation is that we don't want to poll a sensor.ready attribute, so navigator.getSensor().then() .. is preferable

tim: you can have connect/disconnect very often but how do you expose the objects. Promises seems like a good way to go. With a synchronous return object we need to throw errors.

richt: FWIW, we have similar discussions like this before in W3C (see: http://dev.w3.org/2009/dap/system-info/Overview.html).
... It may be that we cannot agree on a generic model and that may be fine.

marcos: wonder whether we should provide sugary methods in browsers or whether we should leave them up to web developers.

richt: perhaps there is a high learning curve to that.

discussion about web developers always requesting a high 'frequency'. "Give me the best data I can get".

richt: could sampling frequency be adaptive. to e.g. match frame rate?

richt: Would be nice to sync requestAnimationFrame and sampling frequency of DeviceOrientation data

christine: is a solution to privacy to limit sensor frequency?

richt: there are known attack vectors at high frequency (e.g. at 200Hz it has been shown that you can detect and record speech (!))

christine: we could use sensors frequency that has less of a privacy impact.

mounir: we will not send data if the page is not visible. Perhaps that is good enough security here as it doesn't update if the web app is not visible.

tim: screen orientation is an issue. Perhaps we should expose screen-adjusted values for device orientation.

Last word: check out https://github.com/richtr/Full-Tilt !!

<npdoty> +1 sensor design pattern

<gmandyam> Conclusion: gmandyam to follow up with DAP WG Chair (fjh) on possibility of forming a joint TF to look at sensor API

<timeless> scribe: timeless

Permissions

[ Break for 5 minutes ]

schuki: webmob is Web and Mobile IG
... not to argue about web/what is "Mobile"
... marcosc__ and I are cochairs

<schuki> timeless:

marcosc__: we have a problem with permissioning on the web
... we have the "info bar problem"
... a stack of bars
... ideally you could complete a task
... in iOS, when you want a permission
... and you only get one shot at getting permissions
... you basically sell the user on getting a permission
... then you sell geolocation

<npdoty> the "only one shot" thing seems to be the distinguishing factor there

marcosc__: what's nice here about this is that you've introduced "why" you're going to use something
... in an app specific way
... the browser can do the dumb popup
... then for geolocation
... it has a place for app specified text
... if you reject, it's integrated in settings, so you can go there to undo
... it would be nice to be able to do this on the web as well
... my fear about this text is that you could totally lie

mounir: "Heyday uses your location to journal places you go. It's completely private and secure."

gmandyam: it's a closed ecosystem

marcosc__: in firefoxos, we have permissions which we check in the store
... our perspective is that the Store has a better chance of understanding the permission

npdoty: i've been asking for this for a number of years
... people lie on websites

<richt> this all looks similar to https://medium.com/@mulligan/the-right-way-to-ask-users-for-ios-permissions-96fa4eb54f2c

npdoty: this is a way to encourage app developers to provide the best information at the right time

mounir: the google.com would love to know if they have permission for geolocation

marcosc__: should we enhance v1 of this api
... we could add the property
... or look at mounir's proposal

mounir: requestPermission/revokePermission/hasPermission
... Mozilla feedback was just hasPermission

marcosc__: alternatively, perhaps a pattern

mounir: i think it's a bad idea

<Zakim> npdoty, you wanted to say not all the UI (iOS has explanation strings, for example) and to note the concern about finding the permission is already granted and to

npdoty: "have i ever explained to the user permissions"
... if you prompt when you want permissions
... that's the pattern we're trying to enforce

mounir: people spend very little time on Google.com
... so they can't spend time explaining the geolocation prompt
... in Hangouts
... it uses Camera, Microphone
... you're proposing a cookie in your walk through
... what people do today is hacks with timeouts
... and then show messages
... this is pretty broken

npdoty: say we have hasPermission
... you'd still have some small doorhanger
... you'd know they're coming
... it sounds like what you want to indicate is
... for a while we had modal dialogs
... but no one is going to miss them
... the feedback we got was "we don't want these things to be modal"
... because we wanted the website to continue
... and we didn't want to force the users into it
... but it sounds like if we don't have this, then nothing

mounir: a camera app w/ no permissions is useless

marcos: that's only 80% true
... w/ Camera+ you could get the permission again

mounir: on a web browser, you can't

marcos: there's a UC for a permission api to ask for access to this

npdoty: the reason companies have switched to it
... apple made it hard to get back
... developer calculations showed that their return was really low

marcos: on firefox, what we have is awful
... the Chrome desktop UI is much nicer
... this may save us to falling to an Android model
... kenneth suggested only showing the ones that have been touched

richt: what about a trigger to get to permissions

mounir: people in this room can't solve this

[ screen shows Chrome w/ Permissions changing doorhanger open ]

mounir: you can make developers' lives so hard
... go to nytimes, you give geolocation, every ad knows where you are

[ http://en.wikipedia.org/wiki/On_the_Internet,_nobody_knows_you're_a_dog ]

gmandyam: summarize something to the ML?

marcos: i could prototype this in Mozilla Nightly

<gmandyam> Conclusion - recommend that MWIG post recommendations on Geolocation permissioning and browser chrome to Geo mailing list to continue discussion.

npdoty: the reason ads don't ask for location

[End of Day1]

---

Day2

<kaz> scribenick: gmandyam

Geofencing

Intros and overview of agenda ...

Marijn presented the Chromium team's proposal on low power geofencing ...

Proposal requires service worker registration ...

Martin: this would require a persistent grant for geolocation
... there may be a requirement for a consent grant every time an event is delivered to the service worker

gmandyam: it was raised at the recent trust & permissions unconference that notifications be standardized

cwilson: will not be possible to standardize among browser vendors
... is geofencing really useful in a main page, or only a service worker? Google has been under the assumption that it is only useful in a service worker.

Martin: FF OS can create background pages that is not identical to service workers

cwilson: Chrome apps has something as well, but we would like to transition to service workers

Ravi: primary use case is something in the background; what about foreground apps?

Martin: that may not be achievable goal given the way service workers are structured. The main question is whether the main page can get access to the events.

Marijn: It is possible with the proposal. Geofencing events are part of the service worker global scope.

Martin: Why not simply surface the events directly to the webpage (onenter, onleave)
... There is disagreement as to whether it is possible to use events in the main page.
... The assertion is that there is no way to ensure that the event handlers are propertly installed when the service worker is installed

Marijn: There is an open issue as to whether to expose the service worker registration in the service worker itself

cwilson: Service Worker is the background solution that is being standardized. The use case for having geofencing events surfaced to the main page is weak.

gmandyam: Confirmed that Geo WG can define extensions to ServiceWorkerGlobalScope independent of Web Apps WG

Martin: Worst case event propagation time could be 750 ms if the browser is shut down when the event occurs

<cwilso> ServiceWorker-only proposal: http://cwilso.github.io/geolocation-api/simplified_geofence.txt

npdoty: Why is there not consideration for main page geofencing?

cwilson: The assumption is that geofencing apps are long-lived, and the weight of installing a service worker is not that high.

Martin: None of this avoids the requirement that the user provide a persistent geolocation permision grant
... To refine npdoty's question, does a background process require a special permission grant?

gmandyam: Qualcomm experimented with persistent workers in the context of the old Android browser, but a technical concern was how to provide the proper UI so that end users can be aware of the active workers and can manage them ...
... Can we assume browser vendors will eventually provide a "management UI" to end users for svcs. workers?

cwilson: Eventually browser vendors will have to do it.

npdoty: It is much easier to explain to new web developers the current Geoloc. API in the context of the main page.

cwilson: If you are actively observing a geolocation app for breach events, then you can use a map app with geofencing implemented in JS

<npdoty> is there a performance difference between watchPosition and geofencing?

gmandyam: Conclusion - we will not expose geofencing events to the main page; they will only be exposed in svc. worker. The svcs. worker is responsible for exposing geofencing events to main page via e.g. web messaging.

Martin: We should eliminate polygonal regions as the implementations don't support.
... the user shouldn't register region ID's; they should be assigned by the implementation. The ID's would have to be persisted by the implementation.

cwilson: Problem is that the developer has to keep track of the region id's.
... If the ID is an optional argument, then the UA will provide a unique ID.

martin: We need to state that region ID is unique either within origin or within service worker

<mt> Promise registerRegion({ type: "circle", name: "myfence", center: { latitude: 123, longitude: -1000 }, radius: -1 }))

<mt> dictionary GeofenceRegionInit { DOMString type; DOMString name = ""; GeolocationPointInit center; double radius; };

<mt> dictionary GeolocationPointInit { double latitude; double longitude; };

<mt> interface GeofenceRegion { readonly attribute DOMString id; readonly attribute DOMString name; readonly attribute GeolocationRegion region; Promise unregister(); };

<mt> Note also that GeofenceEvent needs to be an extendable event.

<mt> And I'm suggesting that we add a Position (or GeolocationPosition) to that event.

<mt> Since we don't otherwise have access to the geolocation API at that point.

gmandyam: Power considerations seem to be taken care of in the underlying HW implementation already
... We will take it to the list to solicit more input as to whether accuracy options should be considered when regions are registered

<npdoty> for the minutes, I'm suggesting less an accuracy option and more the boolean option for whether the app needs the position returned (versus just an event that the region has been entered)

<scribe> ACTION: gmandyam to solicit input on mailing list about adding accuracy options to geofencing/register regions [recorded in http://www.w3.org/2014/10/27-28-geolocation-minutes.html#action01]

<trackbot> Created ACTION-109 - Solicit input on mailing list about adding accuracy options to geofencing/register regions [on Giridhar Mandyam - due 2014-11-04].

<scribe> ACTION: cwilso to create a pull request on the Geolocation GH repo for the agreed upon version of the service worker spec [recorded in http://www.w3.org/2014/10/27-28-geolocation-minutes.html#action02]

<trackbot> Error finding 'cwilso'. You can review and register nicknames at .

<scribe> ACTION: cwilson to create a pull request on the Geolocation GH repo for the agreed upon version of the service worker spec [recorded in http://www.w3.org/2014/10/27-28-geolocation-minutes.html#action03]

<trackbot> Error finding 'cwilson'. You can review and register nicknames at .

Martin: suggest changing registerRegion() to registerCircularRegion()

<npdoty> pending our boolean option proposal

npdoy has proposed that the position can be optionally returned by the implementation as part of the event based on privacy considerations. How the implementation determines the privacy considerations is TBD.

<npdoty> implementations don't need to determine any privacy consideration

<npdoty> this is just a flag to make it easier for developers to ask for the minimum of what they need

<scribe> ACTION: ChrisWilson to look into developing text around privacy considerations in returning position as part of the service worker event [recorded in http://www.w3.org/2014/10/27-28-geolocation-minutes.html#action04]

<trackbot> Error finding 'ChrisWilson'. You can review and register nicknames at .

<npdoty> ACTION: Wilson to look into developing text around privacy considerations in returning position as part of the service worker event [recorded in http://www.w3.org/2014/10/27-28-geolocation-minutes.html#action05]

<trackbot> Error finding 'Wilson'. You can review and register nicknames at .

[ Break until 11 AM ]

Concluded geofencing discussion; moving on to authenticated origins

Slides are at https://www.w3.org/2008/geolocation/wiki/images/1/12/Geolocation_-_Trusted_Origin.pdf

<kaz> scribenick: kaz

Authenticated origin

gmandyam: Web crypt
... Web app security group is working
... trust by the browser
... requires TLS connection for encryption
... quick encryption is available
... potential survey
... device/sensor APIs might have potential issue on security
... media capture as well
... need authenticated origins
... question for the group
... should authenticated origins be requried?

<cwilso> trackbot, users?

<trackbot> Sorry, cwilso, I don't understand 'trackbot, users?'. Please refer to for help.

gmandyam: if mandated...
... existing geo apps that don't come from authenticated origins wil break
... all the connections need TLS connections?
... proposed way forward
... go ahead to solicit opinions in open call on public-geo for authenticated origins
... the web developer has to be aware if the connection is TLS-based
... don't want to revise geo v1 spec about this
... instead place requirement in geo v2 spec

npdoty: discussion happening in quite a few groups
... what is important is the thread model
... unsecure channel could be also used but there is an integrity issue
... question of breaking
... different levels of breaking
... e.g., browsers can let users know "http will be turned off"

ravi: should browsers show that kind of warning?

npdoty: yes

gmandyam: pop-up dialog, etc.

npdoty: e.g., this particular resource has been loaded using HTTP

gmandyam: we can place requirement for v2 spec
... don't want to reopen v1 for this

npdoty: would see the possibility of errata and PER

gmandyam: there is an errata page already
... any other comments?

(nothing)

gmandyam: so would open the discussion on the geo list

<npdoty> Geolocation is currently at Recommendation: http://www.w3.org/TR/geolocation-API/

chris: should this be done by geo wg?
... need coordination with other groups?

kaz: we can talk about this on wednesday as a breakout session

npdoty: will put this

<npdoty> https://www.w3.org/wiki/TPAC2014/SessionIdeas#Responses_to_Pervasive_Monitoring_and_Secure_Origins

<scribe> ACTION: giri to open discussion on authenticated origins on the geo list [recorded in http://www.w3.org/2014/10/27-28-geolocation-minutes.html#action06]

<trackbot> Error finding 'giri'. You can review and register nicknames at .

<gmandyam> scribe: gmandyam

<scribe> ACTION: gmandyam to post open call on public-geo regarding authenticated origins [recorded in http://www.w3.org/2014/10/27-28-geolocation-minutes.html#action07]

<trackbot> Created ACTION-110 - Post open call on public-geo regarding authenticated origins [on Giridhar Mandyam - due 2014-11-04].

Vehicular extension to Geolocation API

<stakagi> http://www.w3.org/2014/10/Question+Proposal_to_the_Geolocation_WG.pdf

Kaz Ashimura presented KDDI's proposal on vehicular extensions to Geolocation API

Kaz: The original proposer from KDDI could not be here in person
... Background - there are some discussions within Automotive BG on how to use geolocation API
... Concern is when the automobile does not have geolocation information from outside the car if the geolocation API is implemented as part of the vehicle infrastructure
... Correction - the concern is when the smartphone in the car cannot determine location - can it derive from the vehicle's geolocation?
... There has been discussion on public-geo claiming that the implementation can leverage outside sources of location when enableHighAccuracy is set
... 3 options suggestied: a) Adding DeviceOptions attribute to geoloc API, b) add new accuracy level, or c) add guidance on how to interpret enableHighAccuracy, i.e. to allow outside sources

Kaz's personal preference is option c) - adding informative text to enableHighAccuracy

Kaz: There is a concern how to enforce an authenticated origin policy when the location source is external (e.g. how does the vehicle trust the smartphone)

gmandyam: Ubiquity of this feature is several years away. Most vehicles do not offer standardized interfaces for smart phones (including BT)

<kaz> ACTION: hirabayashi to post this proposal to the geo list to see the opinions of other group participants [recorded in http://www.w3.org/2014/10/27-28-geolocation-minutes.html#action08]

<trackbot> Created ACTION-111 - Post this proposal to the geo list to see the opinions of other group participants [on Tatsuhiko Hirabayashi - due 2014-11-04].

<gmandyam> ACTION: gmandyam to solicit call for comments on Opera (richt) proposal for screen-adjusted orientation values for DeviceOrientation

<trackbot> Created ACTION-112 - Solicit call for comments on opera (richt) proposal for screen-adjusted orientation values for deviceorientation [on Giridhar Mandyam - due 2014-11-04].

<cwilso> ACTION: cwilso to create a pull request on the Geolocation GH repo for the agreed upon version of the service worker spec [recorded in http://www.w3.org/2014/10/27-28-geolocation-minutes.html#action09]

<trackbot> Created ACTION-113 - Create a pull request on the geolocation gh repo for the agreed upon version of the service worker spec [on Chris Wilson - due 2014-11-04].

<Mek> cwilso: I forked/edited your simplified_geofence.txt file a bit with what I think is mostly what we discussed, and sent you a pull request ( http://mkruisselbrink.github.io/geolocation-api/simplified_geofence.txt)

<kaz> (time for group photos)

<kaz> [ adjourned ]