Your precise GPS locations (which are also sent to their servers).
Your WiFi network name.
The IDs of nearby cell towers (even with no SIM card inserted, also sent to their servers).
Your internet-facing IP address.
The user token used by the device to authenticate with Rabbit's back-end API.
Base64-encoded MP3s of everything the Rabbit has ever spoken to you (and the text transcript thereof).
> Your precise GPS locations (which are also sent to their servers). ... The IDs of nearby cell towers (even with no SIM card inserted, also sent to their servers).
Is this sent to the server all the time? Or just with requests? It shouldn't come as a surprise to anyone that a device designed to respond to questions like "What's a good restaurant near me?" is also sending location context with requests.
If they're sending a constant stream of location all the time for no reason, that would be concerning.
> Your WiFi network name. ... Your internet-facing IP address. The user token used by the device to authenticate with Rabbit's back-end API.
A device must store WiFi network names to reconnect to them. An IP address showing up in local logs isn't really surprising either.
Storing the user access token on the device is also a necessity for reconnecting without logging back in every time you turn it on. The fact that it's stored directly in logs isn't a good practice, but when those logs are stored on the same storage as the db or config file that contains them, it's also not really a new issue by itself. If they were uploading logs directly to their servers, that would be an issue of course.
That’s a weak excuse IMO. Firstly, the WiFi logic is probably entirely handled by Android, so the app doesn’t have to do anything with that. And that also doesn’t explain the WiFi names in logs. Or are they parsing their own logs to determine which WiFi to connect to? If it’s some structured data or a database, I would get it, but they surely aren’t logging something to reconnect to the mentioned WiFi names later.
> Firstly, the WiFi logic is probably entirely handled by Android, so the app doesn’t have to do anything with that.
The app handles the process of connecting to a WiFi network.
It doesn't have a standard Android interface. The only interface is through the Rabbit app, so by definition the app must also handle WiFi at some point.
The already released an update to reduce logging before this blog was posted.
I'm not defending their initial over-logging as a good security choice, but I do think it's being greatly exaggerated in this comment section. If you could access the device's storage, you could access the WiFi network name, period. The fact that it's in the logs, not just the config files/db, doesn't raise the severity of any vulnerabilities.
Sure, the app includes a UI to select a WiFi. That’s not what we were talking about though, right? You made the point that the System needs to store known access points, but that is probably still handled by the OS. The app only queries available access points and tells the OS to connect to one if the user clicks on it.
Also, logging WiFi connections theoretically does raise the severity of vulnerabilities because it stores metadata you wouldn’t have if you only store all access points you ever connected to. If you have an access point called „tabledance gentleman’s club guest“ in your access point list, I know you probably went there once. If you’ve been married for a year and I see that you still connect to it every Saturday evening, that’s a lot more sensitive.
> It doesn't have a standard Android interface. The only interface is through the Rabbit app, so by definition the app must also handle WiFi at some point.
Per the article, this is a new development. It originally shipped with the Settings app, albeit hidden. They could have easily linked to the WiFi page; I have a hotspot which does just that but overall obscures the Settings page away.
If they're not paying you, they certainly should be.
Accusations of shilling for a company is not only uncalled for, in my eyes it greatly weakens your argument because I will have to assume that all you have left are ad hominems. Let your arguments stand on their own and leave the insinuations out of it.
I don't care about ad hominems. But we have to outgrow calling someone a shill just because they apply some critical thinking rather than jumping on a bandwagon.
It's basically saying that someone shouldn't care how weak your claims are because it's a business you're wrong about.
It doesn't work against people who care about the truth.
It's perfectly possible to mix valid points and yelling at people in the subway, but it's still quite useful for one's attention to assume that those who do the latter aren't likely to be making an honest effort at the former.
Way over the top commentary from you, I was already shaking my head before this round.
It was unkind of you to write up an elaborate accusation just because you felt frustrated.
There's one very obvious reason why they they don't use the Android Settings app: it's built for displays at least 2x as tall. (some of the dozens more in [1])
Additionally, a major point of frustration for you seems to be a perceived refusal to admit there's no reason to send WiFi info to the server. TFA doesn't claim they are. Just logged locally in files.
Note everyone along the way clearly said "this is bad and I don't like it" along with facts they were trying to communicate --- its really annoying to have to add those disclaimers because people might be on edge, I can't imagine how frustrating it was to add them and still get the personal attack.
source: I have no love for Rabbit. I left Google in October to found an AI startup. At Google, I worked on Android for several years.
[1] it's unskinned, has a bunch of unnecessary settings, would complicate it with legacy nonsense in what was sold as simplification of legacy nonsense, and they're using something that makes it the face of the device (setting their APK as launcher? kiosk mode?). I can't think of a single OEM that says "hey just go to the settings app to set up wifi".
Where do you see that they're sending it to their servers? The article doesn't say that WiFi names were sent to the servers.
> You're also going out of your way to defend Rabbit in this thread, with several multi-paragraph posts rebutting the same things. If they're not paying you, they certainly should be.
No, I'm just correcting misinformation in this comment section. Some people are apparently only here to pile on Rabbit regardless of the truth, but the rest of us are actually curious about the facts of the situation.
WiFi SSID, along with the signal strength is used to precisely locate a person down to ~ a meter. Commercial GPS capabilities don't have that level of precision, but when you combined with WiFi information, you can.
> so the app doesn’t have to do anything with that
It's probably useful for knowing roughly where you are, and location is used for context. For example, you're connected to your home wifi so when you ask for the weather it can use that location quickly without looking up your location from an IP location service. I'm not saying it's a good idea, but I do see how it could be useful... not to mention locking GPS satellites more quickly.
They do have reasonable grounds to say they need to send location data to their servers (although there is no setting to turn off geolocation), but there was no excuse for the local logging.
(And yes, it is sent periodically regardless of what you're doing, not as part of specific queries)
Welcome to the world where everyone is wasting time and space on JSON encoding rather than using some sensible serialization protocol that can handle raw bytes.
Wrong hill to die on IMO. I'm saving myself and others a lot of work by using a format that every modern language understands, without any external dependencies. It matters to me because I do a lot of integrations and if every service used their own bespoke format I would go mad.
And the wire size is not that be - first, because most messages are small anyway (unless somebody is doing something stupid like sending files via json), and second, because HTTP compression is there and it works great for text formats like JSON.
So, you're adding overhead of compression, decompression, parsing and serializing JSON at every step. All likely backed by a language where computing length of a string is O(n).
And people are surprised software keeps being slow despite increase in compute resources. This is insane.
There is an alternate universe where you comment how insane it is engineers waste time on trying to understand the nuances of every single bespoke byte encoding/decoding technique used between services. JSON is just fine for most tasks, otherwise the world would be in flames right now
We have much more compact and widespread generally available formats out there with libraries for many languages. Want unbounded JSON but more compact? msgpack or bson. Want stuff more efficiently packed based on the message structure? Use protobuf.
Yes, there is a little more effort needed for the engineers there. But ya know, if the inputs and outputs of a thing are actually DOCUMENTED and the schemas are available, it's not some massive reverse engineering feat :P
(Okay, maybe you're stuck doing something in a niche environment where handy protocol/format libraries aren't available to you; MATLAB for Microcontrollers or something. But if you're there, you're probably having fun dealing with all the nuances of implementing an efficient and safe recursive unicode text serialiser/serialiser for a format line JSON anyway :P)
Also if you're going the fairly standard route of "web API over HTTP", the protocols give us way more options readily available for much more efficient streaming of binary data.
It's not "wasting time" to teach devs that there are better ways of doing stuff. base64 encoding mp3s into JSON strings strikes me as "junior dev given 2 weeks to quickly implement something without somebody there to review and suggest alternative ways of doing stuff".
> msgpack or bson. Want stuff more efficiently packed based on the message structure? Use protobuf
Everything you listed is an external dependency in Javascript/Python, base64 is baked in, everyone gets it, everyone's done it.
If you want better interchange you should be pushing it to be included along b64 at the language level not trying to get every dev to include extra dependencies at either side of the exchange.
> If you want better interchange you should be pushing it to be included along b64 at the language level not trying to get every dev to include extra dependencies at either side of the exchange.
Oh, absolutely. JavaScript Object Notation became a defacto standard purely because js could parse it natively. Then `json` was adopted as part of the standard python libraries, within PHP, etc... Once upon a time, even stuff like base64 encoding/decoding required someone to write the code for it. Agreed, it requires pushing to get useful stuff into "batteries included" stdlibs.
We're using JavaScript Object Notation because.... Isn't the name quite telling? :-)
I mean the world is kind of in flames, if planes were as unreliable as most software is we'd have a hundred falling out of the skies every day. But the only reason it isn't worse, and I can't remember who the quote is from, is that the real Moore's law is the fact that talented hardware engineers keep improving hardware more quickly than software is getting slower.
There's an alternative world where everyone is performance oriented and those Rabbit devices don't run for five hours but for five days on modern batteries. Let's be real the thing is basically a Tamagochi, it should cost 50 bucks and run on chips from 2010.
> unless somebody is doing something stupid like sending files via json
But that’s exactly the complaint the GP was making here: That mp3s are being base64 encoded rather than using a transmission protocol that handles raw bytes.
So despite your counter argument, you actually agree with the GP.
Without any explicit admission of guilt on my part; what are some good options here? Protobuf is cool but I really don't want to mess with a special compiler and all that.
The responses you got I think literally answer your question but probably aren't what you're going to reach for any kind of HTTP based thing. Your go-to should probably be multipart/form-data. It's well supported in every language and HTTP library and you can send both JSON and the file in the same payload.
There seems to be a common trend of people writing "JSON APIs" thinking that every other part of HTTP is off-limits.
It’s not even an HTTP invention, it’s RFC2046 MIME from 1996. RFC2388 standardised its use in HTTP in 1998.
The elegant thing about MIME is it allows multiple encodings and cross-references, so you can have your HTML and the images displayed in the HTML both optimally encoded in the same document, which was handy back in the time when HTML emails were taking off and marketing insisted that the fancy image signature they designed had to show every time, even when the person was reading the email offline…
Of course back then we had to encode the image in base64 anyway because of non-8-bit-clean email servers. But I digress and will go back to my rocking chair.
Avro has some really cool features like inbuilt schemas, schema versioning and migration (e.g. deprecating or renaming fields) but you pay for them with more overhead than MessagePack.
Protocol Buffers have schemas too (though versioning and ensuring compatibility is quite messy and requires understanding internals). And it has less overhead than MesssagePack.
I'm not sure what Avro is doing, but as a rule schema enables you to have less overhead, rather than more. The main advantage of MessagePack over schema-based formats is that it's dead-simple and mostly compatible with JSON. Schema-based formats usually need either a code generator or maintaining an annotated version of your data classes and making sure they match the schema.
(Of course, with JSON or MessagePack you might still end up using a serialization library and something like JSON Schema).
Oh, as I understand it Avro's schemas aren't just "built in" as in supported as a first-class part of the protocol, but rather that each message includes with it the schema needed to interpret it. This adds overhead to every message (it's still a binary protocol, though) but crucially it avoids a whole category of hassles around schema distribution and updating.
I just can't get over Cabo's choice to put 65 (yes 65) Bit fixed sized ints in the wire format and to top it off by making it ones complement (the sign bit is part of the type and the longest fixed sized ints are 64 bit range)...
Certainly not by accident. It takes intentional effort to collect any data, let alone data like this where you have to really scrape. This is in my opinion exactly what the tech industry is all about these days. I generally favor a light touch with regulation, but the US desperately needs some privacy laws because this industry is absolutely out of control
Problem is if our congress were to make laws they would make tough on terrorist laws to compel collection and storage of data for the good guys to get the bad guys easier.
We all seem to forget that the patriot act passed 99 to 1. Whereupon…
We promptly got rid of the 1.
We have bad leaders. Look at our Presidential candidates. We won’t get better outcomes until that condition changes.
I'd generally say that disclosure should be enough (and is currently insufficient in the US outside of California), but I am weary that much of your life now involves "Pay us with Venmo" or "Customer service via Twitter," such that one cannot really opt-out without paying a significant cost.
It’s not all bad: Venmo gives you payment/fraud protection; Twitter is a public forum so at least if anything goes wrong you’ll be a viral star of some kind.
I draw the line at companies/orgs using Discord for anything.
Have you tried reading Tweets while not signed-in in the last year? Twitter is not a public forum any more. And it shows that these companies will alter the deal whenever it happens to serve their interests.
Those are local log files on the device. The post says the subset of information sent to the server is smaller.
Uploading location data with requests is a feature of the device. It's supposed to take your location into account so you can ask it questions like "What's the weather forecast?"
The article is sparse on when the information is sent to the servers. If location data is being sent with requests, that's hardly a surprise.
> Uploading location data with requests is a feature of the device. It's supposed to take your location into account so you can ask it questions like "What's the weather forecast?"
No. The whole product is an abstraction to different software interfaces. If it sends data, it should sent it to the weather API, not to Rabbit servers nor even log it, because the information is relevant only at that moment.
Even if they route all traffic through their backend, their should log only errors. There is really no reason to store the location history on OS level.
> If it sends data, it should sent it to the weather API,
That's not how the device works. The weather and location data are both context inputs to an LLM. The LLM produces the response and sends it to the device. The LLM runs on the server, not the device.
You can't have the device connect to a separate weather API unless you send keys to the device, which would require per-user access credentials (good luck finding a 3rd party provider happy to do that). It would also increase the number of round trips, which increases response delay, which is one of the primary complaints about the device.
I am far from an expert on LLMs and have never used the Rabbit, but wouldn't it be silly to have the llm produce the weather? Wouldn't that mean it must have the information in either the context window (or the training set, but that seems pretty unlikely to be current), meaning it already had to be gathered from an external source and wouldn't need to be sent to the LLM anyway?
What can/does the Rabbit add to it above what a simple string concatenation would?
The point of these products is to use a natural language interface to accept freeform questions and produce intuitive and potentially complex responses.
Weather was just an example. You can't predict every combination of weather related questions that someone might want to ask and force those into predetermined response strings.
The idea is to be able to ask things like "What days this week are best for having an afternoon picnic?" and get a reasonable answer back.
If your goal is to hide as much of your personal information as possible from 3rd parties, you're not in the target audience for these products. Nothing wrong with that, it's just targeted at a different demographic of people.
As I understand it, you can think of Rabbit's "stack" as a prompt to a standard llm (I think they just used openAI but I could be wrong) to understand what you want, and then a bunch of (brittle) selenium scripts to go call various websites to do the thing.
The llm is there to understand that you've said "what's the weather?" not, say "call me an uber", and then to collate the responses from potentially several calls to websites and produce a natural language response.
There is a layer of upsell/hustle/scam[1] on top of that where they said they had a "large action model" which learned your preferences and understood how all these websites worked sematically so the actions would be robust etc and a bunch of other stuff which turned out not to be true.
1) IF you wanted a device like this to work seamlessly and magically, it needs to constantly be listening/seeing/sending location. Local inference is where this will actually work, and I don't understand who'd want to give this company money to buy something Apple will make a much better version of in 5 years, but if you do - this is the way to do it
2) We can't hate megacorps and then expect startups to make good products without data. Rabbit would need this data for any chance of creating something better in the future
I'm doing the classic comment before reading the article thing, but I have to say there's a big difference between it sending that information when a request is made and hoovering it all continuously. especially if the data being collected isn't detailed anywhere.
They're already on a better path with App Intents. Way more solid idea than having AI train how to click buttons on a UI that might change every now and then.
A lot of these seems to be "device you trust to use your information to provide services also logs that information for troubleshooting purposes." If you're going to pretend that's troubling you should at least articulate why it's troubling because most of this isn't troubling.
Hey so - they made a shitty half baked product (the first paragraph of the article has the sources), spent a lot of money on PR, and harvested any data they could - so it's troubling.
With all these circumstances it's you who have to defend it - as I see it the real product here is your data.
It's just sad that people can get away with such schemes and it's more sad that law enforcement will let them do it as long as they get access to the data, see recent changes to Google Timeline.
As per GDPR it is the data collector who has to reason why he needs that data, not the user who has to defend his privacy. The collector has to clearly articulate what is collected, how it is used and who processes said data. And the user has to accept that s before the collector can do anything.
While I understand that the US is not the EU and there is no GDPR, I firmly believe the GDPR enforces good rules in favour of the consumer. Hence, any company that does differently - albeit legal - acts morally despicable. Americans should follow that thought more, than very often put that burden of defense unto the people.
My first thought when reading this wasn't even about privacy concerns, but that the battery drain is partially explained by GPS being on all the time, especially on such a small device with a small battery.
I would expect logs to include your IP address. Logging every single utterance as an mp3 seems rather excessive, and logging the access token is just lousy security.
Having to specify the very niche OS that you had to install using your technical knowledge, an OS most people on the planet have never heard about or most likely will ever hear about, didn't make you question if this would be considered "normal"?
I'd guess that to 90% of the people on the planet, any linux desktop distro would not even be a "normal" computer ("operating system", if they even know what that means).
Bruh you installed a niche OS on your phone and are now claiming that it is "normal". Normal when it comes to cell phones is android, iOS. Hell even BlackBerry is more normal than Ubuntu touch
My partner knows french but never speaks french on a regular basis because we met and started dating in another spanish, so spanish tends to be our default language. Whenever for some reason we speak french for a significant amount of time she starts seeing ads in french about french brands on the web and social media apps while all her devices are in spanish and we are living in Spain.
Same when we talk a lot about a particular subject. We found out she starts seeing ads quickly on related stuff.
I am not sure if it comes from android directly, her social media apps or both but something is definitely listening and analysing audio.
Which leads me to think that all FAANG and social medias companies should be sued to death because they actually ask permission to the owner of the device to get and treat personal data, but never to the people who meet them. Especially in the case of amazon echos and google home devices. A number of times when people invited me at home I raised the subject that they never warned me they had a privacy aspiring device set up at home before letting me in and I was met with puzzled looks.
I have seen so many claims like this one, yet never any evidence of this sort of thing actually happening. I tend to believe this is a combination of confirmation bias and "side-channel" information like googling related things, or pattern recognition on the ad server's ML side (e.g. if you visit the amazon toilet paper section once a month, and after almost a month you start talking about toilet paper, getting served toilet paper ads might seem suspicious, but it really isn't).
Is there any actual information about this somewhere? With the insane breach of privacy policies and laws this would be, I would think many researchers would have looked into this by now.
No evidence I’ve ever seen, and people have looked at the communications pretty extensively. I think it’s hust a very compelling conspiracy theory born out of the “whatever you pay attentiom to seems to happen more” principle. My s/o became obsessed with the idea that Tesla cars are hugely dominant, and if you ask her Tesla probably has 90% market share, just because that’s all she sees.
Your precise GPS locations (which are also sent to their servers). Your WiFi network name. The IDs of nearby cell towers (even with no SIM card inserted, also sent to their servers). Your internet-facing IP address. The user token used by the device to authenticate with Rabbit's back-end API. Base64-encoded MP3s of everything the Rabbit has ever spoken to you (and the text transcript thereof).
Nasty :0