Client for Garmin watches

[fabrikant]

I have developed a client for Garmin watches . Anyone can use it for free.
Unfortunately, the client works using an intermediate server. I explained the reasons here
I hope that future API changes will allow me to abandon the intermediate server. Then I will rewrite the client to work independently from the intermediate server and publish the source code.

[Rockhound53]

Hello and first of all thank you for creating this application!

I set everything up, created a playlist.

My server is running via nginx proxy with lets encrypt certificates. I tried API token and username with password, but during sync it always stays at 0% and doesn't retrieve any data.

Any ideas?

thanks

[fabrikant]

You should do the following steps

1. Create a playlist on the ABS server and add books to it
2. Select the created playlist on the Garmin device.
3. Start synchronization
4. Be patient. The percentage increases while downloading media files. But before that, the list of books, the list of files, and covers are downloaded. If the playlist is large, then 0% may be displayed for a long time.

If synchronization still does not work, look at the "Books on the server" list on the Garmin device. Are there any books there? If you tell me the URL of your server, I will check the logs for errors.

[Rockhound53]

Thanks for the feedback. I've now selected the playlist, and now It start to download. Thnx

[Rockhound53]

Is it normal that the download takes so long?

I downloaded a book that was about 800 Mb and it took about 45 minutes.

My upload speed is 30 Mbit/s, so the 800 Mb should be downloaded in a maximum of 5 minutes?

[fabrikant]

Yes, it is normal
Garmin devices are really slow on wifi.

I can't optimize anything. All media is downloaded from your server. No intermediate server is used to download media. A third party developer like me does not have access to the network stack.

I recommend:

1. Sync while charging your Garmin
2. Keep your Garmin as close to your router as possible
3. Scan nearby access points and select the freest channel on your router. The watch can only work on 2.4 GHz
4. If your ABS server and watch are on the same local network, you can set up routes on your router so that traffic does not go outside

In any case, you will not be able to get high speeds when syncing your Garmin watch. In my opinion, the best case scenario is syncing while charging. And yes, syncing starts automatically while charging.

[Vito0912]

I somehow missed that this client uses a proxy (but the app came back up in Discord, so I did it now).
As I do for any project that uses a proxy, I want to give a clear warning before using such clients or apps in general.

This comment is mainly so it can be linked if any app, software, or similar comes up on GitHub, Discord, Reddit, etc., as a reference source. So any point applies to all apps/etc. using a proxy. (Because there have been three different projects that have used a proxy in a realtivly short time.)

Note

Anything below is not saying the provider of the proxy does this, but it is a very high risk, and there is no way to confirm that it is not happening if they decided to do it. This is no rating about the actual product/app/etc. but just an disclaimer.

There are legitimate reasons for using a Proxy, but also think about the risks

By using a proxy, the person providing the server has access to everything you enter, send, and receive. This effectively means that person could have full access to your ABS server if they wanted to, using the account you signed in with. Again this does not mean the devs do it, but they could do it.
Depending on which routes are proxied and what you enter, this could also include usernames and even plain-text passwords.
You trust the person your server address and your passwords (/tokens which should and are considered like passwords)

---

The following is app (Audiobooks Green) specific:
While the app mentions the use of a proxy, it does not explain what this actually means for the user nor what is proxied.

Caution

Additional critical points compared to other projects that have used a proxy before - this app:

• does NOT provide any source code for the app
• does NOT provide any source code for the proxy (also note: even if there was, there is no way of validating)
• does NOT provide any terms of use or data protection page
• does NOT provide any information about where the server is located, which depedning on the country could mean that more things are logged than even given on the status page
• does NOT provide any way to contact them (without having a Garmin account) / hides their contact information
• DOES log informations about "technical" information, which very likley means your ip but does not explain what it means, so it could be anything. As stated there is no information on how they are protected nor how they are used/stored - "Some technical information may be stored in logs, which are automatically cleared as new information accumulates.".

---

Stay safe!

[fabrikant]

I opened the source code
AudiobooksGreen
AudiobooksGreenProxy

[Vito0912]

In return, I've received some shaming from the audiobookshelf community (quite fairly) because the app's operational scheme isn't transparent.

and

Nothing prevents me from stealing your login credentials directly from the Audiobooks Green app, right?

Of course, nothing stops you, but everyone can check it. They can compile it themselves. I personally check every client for such code requests I test. Is it 100% foolproof? Definitely not. But even for closed source apps everyone can see the requests made by an app, and it would be flagged quite easily (also at DNS level). With your proxy approach, there is absolutely no way to verify it. It's a "trust me, brother" statement that cannot be validated. That's the main issue. That you call it "shaming" is crazy.
Also you can extract used endpoints nowadays from the binary.

Also, the "shaming" (which I just call out obvious red flags) is not directly related to the proxy, but you're raising all the red flags. There were other people running proxies, but at least they had servers in a privacy-friendly country (or at least I assume - you still state it nowhere). You don’t mention where the servers are hosted, what exactly is logged, or how data privacy is handle, etc. Nothing?

[fabrikant]

There were other people running proxies, but at least they had servers in a privacy-friendly country (or at least I assume - you still state it nowhere). You don’t mention where the servers are hosted, what exactly is logged, or how data privacy is handle, etc

My servers are located in the European Union (Estonia and the Netherlands).
What does this information mean to you? How does this prevent me from stealing your data?
I also claim that I don't store any user data. But that's just me.
How can you verify it?

But even for closed source apps everyone can see the requests made by an app, and it would be flagged quite easily (also at DNS level).

This is so funny that commenting will only ruin it.

Now seriously. I agree with everything you're saying. And it really doesn't look safe, and it really isn't safe.

But! The problem isn't with my client. The problem is with audiobokshelf's architecture.
Currently, to provide any semblance of security (but it's not security, it's security theater), every third-party client must be open source. And that's not enough. Each user must compile the client themselves from source. And don't use app stores.

In mature systems, this problem has long been solved. The solution is OAuth 2.0 Scopes.
And what is happening now, in our area they call it: Переложить с больной головы на здоровую.

[Vito0912]

You can see edit history. But I decided to remove the comment. I don't want to discuss this really. People should have their own picture and not listen on me. I just gave some red flags, you provided something for them.

So thanks!