[Bug 27752] Deficiencies in Location setting API

bugzilla-daemon at freedesktop.org bugzilla-daemon at freedesktop.org
Wed Aug 4 17:03:44 CEST 2010


https://bugs.freedesktop.org/show_bug.cgi?id=27752

Simon McVittie <simon.mcvittie at collabora.co.uk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |NEW

--- Comment #7 from Simon McVittie <simon.mcvittie at collabora.co.uk> 2010-08-04 08:03:43 PDT ---
This is much messier than I'd realised, if you go beyond Gabble's relatively
simple implementation.

(In reply to comment #0)
> * Clients can't tell when LocationAccessControl has changed.

Not actually our bug. In XMPP, you can only tell what the access control model
is by doing a network round-trip (for a Data Form... everyone's favourite data
structure), and you can't tell when it changed.

Possibly we could redefine LocationAccessControl to mean "what the access
control would be if you called SetLocation right now", and introduce a
RequestLocationAccessControl which waits for the round-trip, and sets LAC as a
side-effect.

> * I'm not sure that having separate setters for the access control type
>   and the location is the right model; since geolocation is such
>   sensitive information, we should perhaps set the access control and
>   the location at the same time?

Unfortunately, there's a race (potentially revealing old or new location to
people you didn't intend to receive it) unless you do this:

* set location to nothing
* [1] fetch configuration form
* wait for reply to [1]
* [2] fill in and submit configuration form
* wait for reply to [2], if you care about the possibility that you could
reveal your location because it failed
* set location to new value

Since we only implement Location in Gabble, we should probably make the spec
follow the underlying protocol.

>   In particular, the first SetLocation on a Connection is specified to set the
>   access control to an empty whitelist if possible (though I don't know whether
>   Gabble actually does this)

Gabble behaves as though XMPP only supported the default "presence" access
control model. If another of our resources sets the access control to something
more permissive, we'll never know.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.



More information about the telepathy-bugs mailing list