Re: Eddystone->Web Bluetooth upgrade and Allowed Services

For a BLE device advertising a URL via Eddystone, and then that URL
connecting to the device, I don't think there is a risk. That's why I put
option 3 on the table. It's very similar to connecting to a cross-origin
server via websockets, where the server also opts into allowing the
connection. The biggest difference here is that we'd allow the grant to
follow redirects, which isn't true for websockets or other CORS-like grants.

We'd go with option 2 if the above argument isn't convincing. Then we need
to be able to show UI for suspicious services in the future, and in general
we need a user gesture to show UI so that users aren't surprised by it.

Jeffrey

On Mon, Apr 4, 2016 at 10:55 AM, Scott Jenson <scottj@google.com> wrote:
>
> If nefarious devices aren't a risk, could you enumerate what the risk is?
> Sorry, I somehow missed it.
>
> I'm a bit confused about this level of safety. If I were to connect to a
> device using websockets (assuming it's on the internet) I would have none
> of this user gesture protection. I would just connect and be done with it.
> Why is using BLE as a transport vs HTTP as a transport considered to be so
> much riskier?
>
> Scott
>
>
>   Scott Jenson   |   Chrome UX  | scottj@google.com | +1 650 265-7174
>
> On Mon, Apr 4, 2016 at 8:58 AM, Jeffrey Yasskin <jyasskin@chromium.org>
> wrote:
>>
>> On Mon, Apr 4, 2016 at 7:28 AM, Scott Jenson <scottj@google.com> wrote:
>> > On Mon, Apr 4, 2016 at 1:50 AM, François Beaufort 🇫🇷
>> > <fbeaufort@google.com> wrote:
>> >>>
>> >>> Assume that if a device advertises a particular URL, then the device
>> is
>> >>> designed to work with that site, and the user doesn't need to see the
>> >>> requested services. Other sites would still need to declare the
>> services
>> >>> they're going to use.
>> >>>
>> >>> This seems scary but pretty cool in terms of UX.
>> >
>> >
>> > I worry when we say 'seems scary' as it sometimes encourages us into
>> extra
>> > careful corners when it really isn't necessary. However, I agree, we
>> have to
>> > be very careful so I appreciate the concern.
>> >
>> > Obviously I like this approach because the UX is clean but just as
>> > importantly so is the implementation. Anything that passes information
>> > between different OS services is complex and, from a security point of
>> view,
>> > can be compromised.
>> >
>> > While the following points aren't perfect, they tell a pretty compelling
>> > story:
>> >
>> > Only devices that want to use this service 'opt in' by broadcasting a
>> URL
>> > The user must pick the device manually (it doesn't auto connect behind
>> the
>> > user's back)
>> > HTTPS prevents hijacking of the website
>> >
>> > For good devices that are playing nice, this is a great flow as
>> everything
>> > should work as expected and the user doesn't have to agree to obscure
>> > permissions requests.
>> >
>> > This does leave nefarious devices to consider,
>>
>> I don't think nefarious devices are a risk here: a nefarious device
>> cooperating with a website can smuggle arbitrary data through a
>> totally benign-looking standardized service UUID like the Battery
>> Service, so we're not going to be able to show the user anything
>> helpful anyway.
>>
>> > but I like the other option
>> > mentioned above which was an API call that declares what services the
>> web
>> > page will use. The vast majority of time, it'll be custom things unique
>> to
>> > the device (so just pass it through) or well known values (heart rate).
>> Even
>> > if this call did very little in V1 but enforce access to those
>> > characteristics, it gives us 'future proofing' in that the system could
>> then
>> > block the app or prompt the user if the system is worried they were
>> verging
>> > into dangerous territory.
>> >
>> > What I like most about this characteristic screening call is that it is
>> > completely invisible to the user 99% of the time when they are using
>> > expected, compliant devices. However, it gives us complete control over
>> > which services are used. More importantly, it gives us a single point of
>> > control (the browser) vs two (OS and Browser) which seems extremely
>> hard to
>> > pull off properly.
>>
>> Mhmm. The thing that worries me about the device.requestMoreServices()
>> call is that because it could show clickjackable UI, we have to
>> require a user gesture, which is going to put an extra click between
>> selecting the device, and letting the web page use it.
>>
>> Jeffrey
>
>