Reading, and I guess I'll take the time to explain why it works this way. Unfortunately I have to keep it at fairly high level. Long story short, we don't trust the transport mechanisms by which our customer's data gets from their wrist to our backend. As such, we securely encrypt it on the device and that encrypted payload can only be decrypted once it's on our servers. At that point it becomes available to be fetched over secure APIs.

We've considered other ways of doing this that will preserve our requirements to keep customer data private and unable to be tampered with. We will likely make it more flexible in the future, but this is the scheme that has worked since the company was founded, almost 14 years ago.

What about...just providing a desktop app to receive all the data and do all the computation needed? Or the same thing in your phone. What are the exact dangers of these two approaches? And dangers to whom?

Then they would have those keys. Phone security has gotten a lot better in 14 years, but it hasn’t always been great, and desktop security is still not so awesome.

Thanks for the explanation! Key escrow is hard, eh?

This was my major beef with Pebble... which was purchased by FitBit... which is now owned by Google, meaning all that Pebble data is now Google's.

I wanted to switch mine from 12hr to 24hr clock format.

I couldn't do it on the watch itself. I couldn't do it on my phone from the app. The only solution was to log in to fitbit.com in a browser, change a setting there, then re-sync my device via the app.

Sounds like ANY device or peripheral - the data is more valuable that anything else. On acquisition - the exit strategy is to have a pile of data.

I think regulation is the only way to change this because it's a gravy train.

I would pay more for a device that didn't save to the cloud and only saved locally but could still give you nice graphs and whatnot in an old-fashioned desktop program. They can have a website that you can upload to that makes things visible to your friends, as long as it's opt-in only. I wouldn't use it because I wouldn't trust it, though.

This sort of thing is as dead as a doornail, unfortunately.

With Garmin watches you don't have to pair it to a phone or set up Wifi. You can just plug it into your computer and download the data. There exist a number of open source tools. I've only used GPXSee for looking at the GPS data, which actually let me see "correct" swimming distance data where Garmin was using some algorithm that didn't make any sense.

I mostly use the web ui but loading the data into one of the open source offline tools is on my to-do list. There's actually some analytics/reports I want to generate that Garmin doesn't provide, so I might end up doing it purely to write some reports.

(Although the peace of mind I would get knowing that I could pull the plug on my Garmin account whenever I want would be nice.)

Though it isn't perfect. When Garmin had the outage last year I unpaired my phone which actually reset some of the configuration I had done on the watch, which was really annoying.

It is not 'asinine' if you're worried about cost, size, and weight. An all in one device is going to be larger, heavier, and cost more than device that relies on a smart phone.

The GP is complaining about the phone -> server -> phone data path of the wearable -> phone -> server -> phone workflow for generating a nice graph. Presumably they think uploading the data to the server should be optional for backup/social purposes and not a part of just viewing the collected data.

Yes, I understand that and I've given some of the reasons why.

Another reason is that the alternative of syncing your device with a computer doesn't work with most of the population. They either aren't familiar with tech enough or they don't own a computer. The rest get annoyed with the lack of convenience vs automatically uploading everything via your phone's bluetooth

Exactly. And even if it does eventually get uploaded, I might be using my devices not in a data connected area. It's just a lazy architecture.

Edit, may not be entirely laziness: see this response to my question - https://news.ycombinator.com/item?id=25787066

As I remember, my FitBit HR holds less than 10 days' worth of heartbeat data, and can't be uploaded to the phone without the phone having connectivity to FitBit's servers. Also, extracting large amounts of data from the FitBit tends to time out and require a full retry. On more than one occasion, I was on vacation with my wife in a foreign country and only got a local SIM card for her. This resulted in me turning off automatic sync (to avoid battery drain from all the failed attempts). This resulted in me relying on manually sync'ing my FitBit data when I had WiFi, which resulted in my forgetting. This resulted in data loss.

Also, I seem to remember long syncs timing out so many times in a row that I just had to factor-reset my FitBit HR to clear its data buffer. This happened more than once. It really needs an incremental sync.

When I got my FitBit HR, my wife was interested in using my original FitBit. I proceeded to update its firmware right before I gave it to her, but the firmware update seems to have timed out and broken the FitBit. I recovered once with a factory reset, but a second firmware update attempt bricked it.

Honestly, IoT devices need minimal firmware in non-brickable ROM that checksum the firmware in flash before jumping to the firmware in flash. If the checksum fails, then make a light blink and go into a recovery mode that implements a minimal Bluetooth or HTTP firmware update, preferably incremental, requiring minimal state, and recoverable/restartable if that minimal state gets corrupted. Back in the day, I bricked a WRT54G router by using Firefox to upload the firmware instead of Safari or I.E. (It was a known non-deterministic issue, apparently. I'm guessing a corner-case in the router's handling of chunked HTTP encoding.) Not even the trick of shorting two adjacent pins using an x-acto knife could get the recovery TFTP server to come up.

Also, during the first year warranty period, my FitBit HR died twice, presumably due to being splashed so much with salt water during dragon boat race practice. I know it says not to go swimming with it, but you should really avoid excessively splashing it with seawater. When my FitBit HR died a third time shortly after the warranty period, I gave up on FitBit for a while.

Each device should be as capable as possible. There are features not implemented on the wearable, and there are features not implemented on the phone, as someone else pointed out, they could not change a basic setting from the phone or the wearable.

I understand there's a feature set trade off, I don't necessarily want a wearable that connects to the internet itself.

Ok, then it already exists. Buy Apple. The main trade off is price.