5 ms·

If someone from Fitbit is reading this: It is asinine that the data from my wearable has to go to my phone, up to the cloud, and back down to my phone for displ

by csours 6y ago

If someone from Fitbit is reading this: It is asinine that the data from my wearable has to go to my phone, up to the cloud, and back down to my phone for display.

bluescrn 6y ago
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.
m463 6y ago
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.
- godshatter 6y ago
  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.
  - lukeschlather 6y ago
    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.
chaostheory 6y ago
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.
- KMag 6y ago
  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.
  - csours 6y ago
    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 https://news.ycombinator.com/item?id=25787066
    - KMag 6y ago
      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.
taneq 6y ago
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.
sulam 6y ago
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.
- csours 6y ago
  Thanks for the explanation! Key escrow is hard, eh?
- 6sup6 6y 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?
  - sulam 6y ago
    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.

by csours 6y ago

If someone from Fitbit is reading this: It is asinine that the data from my wearable has to go to my phone, up to the cloud, and back down to my phone for display.

bluescrn 6y ago

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.

m463 6y ago

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.

godshatter 6y ago
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.
- lukeschlather 6y ago
  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.

chaostheory 6y ago

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.

KMag 6y ago
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.
- csours 6y ago
  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 https://news.ycombinator.com/item?id=25787066
  - KMag 6y ago
    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.

taneq 6y ago

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.

sulam 6y ago

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.

csours 6y ago
Thanks for the explanation! Key escrow is hard, eh?
6sup6 6y 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?
- sulam 6y ago
  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.