Fitting something "fatbeacon" like into the network stack

[samgiles]

I've been playing with "fatbeacon"s in our Project Magnet app for Mozilla and it struck me as not very "web", what I mean by that is, there's no HTTP request, and it doesn't really fit in with the rest of the web platform. Which got me thinking about idealistic use cases, what if we could use this technology to fulfill an HTTP request?

Imagine installing the underground train company's progressive web app, they have a service worker that makes requests to '/api/disruptions' to get a list of all the disruptions currently happening. When offline, this fails, and the app falls back into an offline state displaying the last known good data.

What if, when in range of a "fatbeacon" underground, the request is fulfilled by the data from this beacon? I'm not sure how this might work in practice - but I could have a go at implementing this perhaps.

Any thoughts?

[scottjenson]

Happy to have you explore this further. That's exactly what we were hoping for. The whole point of the fatbeacon experiment was to get around the issue of having no data.

Being web based, of course we'd like to use HTTP but we couldn't think of a good way to do this over a BLE GATT service. There may need be HTTP-over-GATT protocols and if so, that also might be worth looking into.

What did you have in mind. I have to admit, I'm not really clear what direction you're thinking of trying.

Scott

[scottjenson]

Any more thoughts on this? Is there a more 'web-ish' way to do fat beacon over BT?

[adriancretu]

Just my 2 cents... A HTTP-like behavior implies a browser doing a request to a "host" (beacon). So how do you define a beacon to represent itself as a host, and how do we trust it? Same problems like the ones encountered in the decades of DNS issues and SSL root certificates (and revocations), but this time offline.

My point is, to use beacons as a data source (on top of WebBluetooth or whatever) a different scheme is needed, like eddystone://<UID>/resource which would be identical to HTTP in all respects. Let's say a browser would serve this request by looking if there's a beacon with that UID around, and doing the GATT thing to get the result (or return it from a cache). Maybe throw in a little authentication by using a public certificate somehow, to avoid spoofing.

If all this sounds a bit like IPFS, it's because it does.

[scottjenson]

Interesting. Do you think it would make sense to just do IPFS over GATT? I'd rather use a standard with legs than invent something new. The FatBeacon approach was just a first pass, general exploration.

[adriancretu]

The core issue of webifying is emulation of a raw socket over GATT before anything higher level. Existent HTTP libraries could then support the new protocol by just swapping the socket implementation. So everything else can stay exactly the same (even ssl). The beacon could advertise its own URL (ok, technically a UID with a new flag) and relative resources would be supported by default, so HTML stays the same also. I can imagine the hard part would be on the beacon acting as a http server.

[scottjenson]

I can't disagree with this in principle of course. But this is a very low power, very low bandwidth device. I worry that emulating a high bandwidth, low latency HTTP connection is likely to create as many problems as it solves (most web pages will load very lowly over it) There is not question that packing the web page up into a single package is extreme, I don't want to defend it very strongly.

In addition, I've spent the last 3 months implementing the Eddystone + GATT spec in mbed and the software stack is very far from full linux, and the device is very VERY far from a Raspberry Pi. It's been a very eye opening experience for me as to how low power these beacons are (in every way).

It would be extremely unwise to say 'never' in computing, things are advancing fast enough that beacons will easily be RPi in both HW and SW layers in a few years. I guess I wanted to walk before running. This simple fatbeacon would be just a first step. Once we get a standardized HTTP layer over BLE, that would be the next step.

[adriancretu]

Should we expect any more development on this? I can imagine the use-cases to load offline an extremely miniaturized web-app from a BLE device and communicate with it further via WebBluetooth to extract more data.

[scottjenson]

We're certainly still interested in it. The key thing we uncovered by this experiment was the security issues of opening up a beacon we can't vet through a PWS. Of course, the Web Sandbox makes this reasonably safe but there are more than a few people that are a bit worried about the potential for misuse.

We're exploring ways of making this more secure within the Chrome team. I'm curious if there are any other ideas out there that others might know about?

The other issue is simply size. Limiting an entire page to 40-100k is a big limit (Keep in mind that BLE transfer rates will likely vary from 4-20k/sec with most being on the lower side) Nothing you can't get around of course but it limits the upside (for example, you'd hardly be able to use many image/graphics) We're interested in feedback from folks that feel this limitation is workable. What we've heard so far is that this is promising but to be honest, we're not getting a strong positive feedback. If we've misread the enthusiasm, please correct us!

For what it's worth, I'm still VERY bullish on this. We're just uncovered quite a bit that needs more discussion before we feel we should forge ahead.

[adriancretu]

Maybe you can white-list "safe" beacon without ever needing a web call. A beacon advertising example.com/item/42 can pass the PWS check if it can sign the URL and some random data with its private key (of a public certificate signed by Google's Proximity API). Of course, example.com can turn evil or be compromised, but this is out of scope. The main point is being able to directly load up a tiny bootstrapper (even if it's only 1 KB), sand-boxing is fine.

Estimote launched something for storing offline data on beacons themselves, so there is interest on this.

[scottjenson]

Interesting idea to have it broadcast a public URL for the PWS. However, we'd need to make sure the cert for the URL is the same as the local package. One of the benefits of fatBeacon was that it could work without internet at all. In that case, maybe just a local signed package would be enough...

[adriancretu]

If Google is the CA that signs the beacon certs, there's no need for internet. You would only need to have the public, trusted, root certificate of Google CA. The reason to separate these from server SSL certs is that I wouldn't put my domain's private SSL key into an actual beacon that someone may tear apart... (even in encrypted password-protected form, who knows what can happen)