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

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.

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.

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.

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.

> They could have easily linked to the WiFi page;

The device has an extremely small display and no keyboard. The stock WiFi settings app would not be a good experience.

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.

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.

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.

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".

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.

(And yes, it is sent periodically regardless of what you're doing, not as part of specific queries)

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.

And people are surprised software keeps being slow despite increase in compute resources. This is insane.

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".

Also, if any, an external JSON file should be parsed, not the files themselves.

In my country, no one of these 'self-called engineers' wouldn't even earn a trade/vocational degree. Legally they wouldn't even be engineers.

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.

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.

We’ve squandered almost all of the advancements.

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.

I have no idea which is best. Frankly it seems like there are too many choices.

Probably MessagePack, since it is JSON-like and I've actually heard of it.

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).

There seems to be a common trend of people writing "JSON APIs" thinking that every other part of HTTP is off-limits.

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.

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.

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.

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.

What can/does the Rabbit add to it above what a simple string concatenation would?

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.

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] depending on your point of view. I would encourage people to watch https://www.youtube.com/watch?v=NPOHf20slZg and https://www.youtube.com/watch?v=zLvFc_24vSM and do whatever personal research and make their own minds up

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

1. This is just a tiny fraction of the violations they've done.

2. I trust big corporations to have better data categorization and secure storage.

3. If big corporations misuse data, they are liable to a pretty large class action lawsuit. There's not much recourse in the case of Rabbit.

4. There's no good reason to collect and send cell tower data back to their servers for their use case.

I've worked at mega corps and I do not.

>3. If big corporations misuse data, they are liable to a pretty large class action lawsuit. There's not much recourse in the case of Rabbit.

Not in the US.

>4. There's no good reason to collect and send cell tower data back to their servers for their use case.

There is no reason to collect most of the data mega corps do either.

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.

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.

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.

GPL requires you to disclose the license and source code on request, but Truth Social got away with not disclosing the license until someone realized they were using AGPL code, and only then released the source. I wonder if Rabbit will slip by doing the same.

Not quite; GPL 2.0 requires you to at least disclose the license upon distribution, but actual source code may be provided upon request[1]:

> You may copy and distribute the Program … in object code or executable form … provided that you also do one of the following:

> a) Accompany it with the complete corresponding machine-readable source code …

> b) Accompany it with a written offer … to give any third party … a complete machine-readable copy of the corresponding source code …

> c) [option that only applies to non-commercial distribution]

In practice though, GPL software rights holders can't pursue violations they don't know about, and usually only care about getting violators they do find out about into compliance, rather than seeking damages.

[1]: https://www.gnu.org/licenses/old-licenses/gpl-2.0.html

It's more complicated than that. Linux is using a standard GPL2 without exemptions. There are some vendors that look at the actual definitions of how code that's "derived" from the kernel is what needs to be open sourced, so most of their driver is a closed source blob that includes no headers from the kernel and who's source tree has existed longer than their Linux port. Then they open source a bridge layer as gpl2. They then bank on the idea that no judge or jury is going to rule that the closed source blob "derives from" the kernel.

> As of the end of July 15th, they have not responded.

Their lawyers are considering the options how to sue you.

Given that there was no new security vulnerability, it would have been completely reasonable to ask for a comment at the same time as hitting publish and note that they’d been asked for a comment and as of that time had not responded. Just as long as the post is updated if they do respond.

“Real” news sources do this all the time. There’s a difference between asking for a comment on an issue and responsible disclosure of a previously new vulnerability.

Not as shitty as some of the stuff the article finds of course, but still a completely unnecessary callout that detracts from the message on said stuff a bit.

You are free to think that I didn't give them enough time to respond, since "enough time" is subjective. But the amount of time I did give them was objectively reported.

It's now been the best part of 4 business days, and they still haven't responded, nor indicated an intent to respond. There's no way I was going to let them delay me indefinitely.

2. A weekend is very short time to give comment. If it's on such short notice, you'd generally call them to ask your questions on the phone or swiftly set up written correspondence.

3. One or two weeks, or even more, is a common time schedule for comments from the party being investigated when it comes to investigative journalism.

4. There is probably less than 0% chance that any other investigator would have published the scoop before you.

Nonetheless, I reject the idea that saying "July 12th" instead of "Friday" is lying by omission.

You might disagree, because you might know what situation might prompt such an event, because you're a journalist, which is fine. But also, you're not writing for journalists; you're writing for the general public, such as myself.

Speaking for myself, if the article was written specifically for me, I'd consider such statements to be a blunder on the journalist's part, at best, and a very deliberate literary technique to ellicit a stronger emotional reaction, at worst. You're ofc not writing for me, but maybe you find the feedback interesting nevertheless.

When they write “did not respond to our request” it means they called or emailed and waited a few hours, possibly the next day.

Not really the same as what happened here, but thought it would be interesting to mention it here.

So the act of calling becomes 'the request'. Reminds me of 'but i replied to your email'. Yeah, but you didn't answer the questions in the email.

The software looks garbage and the company doesn’t seem great either at this point.

But if it’s easy enough to run custom apps on (even/especially) in kiosk mode, I could imagine some pretty interesting use cases for this form factor.

Bonus points if you could just slap something together as a PWA too, as then it gets much quicker than programming an ESP32 + battery + screen, and in what looks like s pretty nice self contained unit.

Would be nice, ideally to be able to get it running more secure / without any Google services, something like GrapheneOS.

Having not looked at what’s out there (yet) does anyone know if people are using them in this way for custom single focus apps or have any pointers?

I hope TE chooses their clients better in the future. The guy behind Rabbit is a known grifter.

Genuine request for sources. Whilst i know i could just search the name, i won't. Purely because search is nowadays terrible. However a link to something that further expands on your criticism would be useful.

>On July 12th, I asked Rabbit Inc. if they had any comments to make on the content of this article [...] As of the end of July 15th, they have not responded.

That *was* between zero and two working days, depending on how early on Friday the author asked them for comments and how late on Monday they waited for a response. It might've been better to wait a few more days. I doubt they would've responded even then, but it would've made the case of their incompetence stronger, and given them less ammo for a rebuttal should they choose to make one.

To elaborate, there are no new security disclosures made in this article. The logging issue has already received mainstream media coverage, after they resolved it and published an advisory, and people have been playing with flashing custom roms via mtkclient for months (as referenced in the article).

The only new "accusation" is that they are violating GPL. I informally asked them for GPL sources months ago via their community discord server, and I'm aware of others who have asked more formally.

Asking for their input on the article was a) giving them a courteous heads-up b) a formality c) an opportunity for them to correct me if they thought I said something untrue.

In your article you also wrote that you didn’t bother reporting it at all when you first discovered it. Why did you wait until the article was ready to be published to inform them?

Standard practice is to inform the vendor early and work with them as you write the article. Keeping the issue quiet and then demanding a rushed response when the article as done isn’t helpful to people who actually want the issue fixed before it goes public.

> If they had requested an extension, I may have considered, but they didn't respond at all.

Why would they request an extension when they fixed the issue a day before you tried to contact them? They should have written back and pointed you to the already-released security update, but I can also understand why they aren’t thrilled to engage with someone who is trying to make a mountain out of an issue they had already fixed.

This isn’t even remotely standard practice.

A fair number of people and companies will give the vendor a chance by doing coordinated disclosures this way - but it’s in no way standard practice.

Also when a company has a history of being openly hostile to disclosure attempts and downplaying stuff, the only way to force improvement tends to be “short warning, or even full disclosure”.

I’ve done everything from coordinated to “no warning” disclosures in my career, and at this point I tend to lean more towards “no warning” in situations where a vendor has a history of dismissing concerns or openly being hostile to external researchers.

There's more than one issue here, and you're conflating them. IF the logging issue was non-public and non-resolved at the time I wanted to publish my article, I'd probably have given them longer.

> Why would they request an extension

If they thought 1.5 working days wasn't enough to provide GPL sources, for whatever reason. I don't see how you can argue that 1.5 days is simultaneously too short, and not in need of an extension.

I've read through these comment chains a few times, but I'm having a really hard time finding the "outrage", disingenuous or otherwise. Can you quote the part of the comment that displayed outrage?

>Do you and their security engineers even live in the same time zone?

Reading through this thread, you can find where the OP says that the time zones were accounted for.

AFAIK the OP did not start writing his article until after they resolved it, which they did within 24 hours.

quoting the blogpost now, "firstly because I hadn't fully thought through the impacts at the time" The issue was overlooked by OP up until concerns were voiced by other community members which ultimately got the problem patched within 24h of it being noticed.

You claim "the amount of negative spin in the article left a bad taste in my mouth.", but you seem to be the only one spinning quotes out of context to fit your narrative

No, the article says he did not report it (I don't know what you mean by "within 24 hours") and that he started writing before they fixed the issue. From the article -

> Fortunately for everyone else, the latest RabbitOS update (v0.8.112) addressed this issue while I was midway through writing this article.

From parent comment -

> You claim "the amount of negative spin in the article left a bad taste in my mouth.", but you seem to be the only one spinning quotes out of context to fit your narrative

The second sentence in the post begins with

> Critics unanimously agree that it sucks

And follows up with

> A week or so ago I bought an R1 on eBay for £122 (which is still way more than it's objectively worth). So why did I buy this garbage, in full knowledge of its garbage-ness?

The hostility toward the company is infused in the article.

I don't owe anyone an emotionless regurgitation of facts, it would be incredibly boring.

Vuln was first mentioned in the community server on the 10th of July at 22:21 GMT+2 Rabbit then right on cue, on the 11th of July at 22:00 GMT+2 release the new OTA and patch notes, quickly followed by their security announcement 31 minutes later.

OP was the one who found the existence of these logs which were overlooked at first, until community members realized the contents of these logs and inability to remove them could be harmful

> As of 11 July, we’ve made the following changes:

> Pairing data can no longer be used to read from rabbithole. It can only trigger actions.

> Pairing data is no longer logged to the device.

> We have reduced the amount of log data that gets stored on the device.

> The Factory Reset option is now available via the settings menu. Customers should use this option to erase ALL data from their r1 prior to transferring ownership.

Requesting comments were only a formality to address already voiced concerns

"The promise was simple. Speak into the device and it'll complete tasks for you thanks to Rabbit's “large action models”—call an Uber, reserve dinner plans via OpenTable, play a song through Spotify, or order some food on DoorDash. Just speak and it will handle it, just like if you handed your smartphone to a personal assistant and asked them to do something for you."

I don't understand why an app on the phone wouldn't do that, but maybe I'm not hype enough.

Only Siri would be able to do that on iOS.

Therefore, no third party can “become the platform” on iOS for voice assistants.

But who knows. Maybe EU will force Apple to open up for that at some point, like they forced Apple to open up for third party App Stores on iOS in EU.

I don't understand the pleasure they get from this.

I was going to argue that the actual author of the post is allowed to put whatever title they want on their actual article, but the actual article is titled

> Jailbreaking RabbitOS (The Hard Way)

So... Yeah, actually this submission does seem to go against https://news.ycombinator.com/newsguidelines.html -

> Otherwise please use the original title, unless it is misleading or linkbait; don't editorialize.

He says he didn't bother reporting the issue at first (!) but then later criticizes Rabbit for not responding to his July 12th e-mail in less than 2 business days.

However, Rabbit had already fixed the issue and released a security advisory on July 11th, a day before he finally decided to contact them. You can see their security advisory on their website, dated July 11th ( https://www.rabbit.tech/security-advisory-071124 ) To be fair, the post does bury this at the very end of the article, but it spends most of the opening sections talking about how much it "sucks" and leans heavily on the logging issue and their lack of response before eventually admitting that it was already fixed.

> As of 11 July, we’ve made the following changes:

> Pairing data can no longer be used to read from rabbithole. It can only trigger actions.

> Pairing data is no longer logged to the device.

> We have reduced the amount of log data that gets stored on the device.

> The Factory Reset option is now available via the settings menu. Customers should use this option to erase ALL data from their r1 prior to transferring ownership.

I have been disappointed in its hackability; however, the joy I receive when watching my 10 year old dive into a topic of his choice with this neon orange LLM is worth far more to me than the $200 for my R1. During these summer months I let him stay up late with this as his only glowing screen and he basically uses it like I used Encyclopedia Brittanica, except much more deeply and with more interesting subjects. I think it's a great little piece of purpose-driven hardware.

I dropped my own ChatGPT subscription and use this if I need to do some heavy lifting. I know it won't last forever, but it will last until the company goes bottom-up -- and longer if we get more boottime control through tools like this.

That's not to say AI is wholly bad because of hallucinations but "just swag a guess based on your personal BS detector" is an unrealistic expectation for its use.

I saw somebody say that they really missed the mark by not making it a kid's device.

Edit: nm, I commented before reading other comments. Anyone else confused should read jylam's comment explaining.

You may as well ask "why do people like sports?", people are emotionally invested and that is enough.

To expand on this, this isn't just a truth stretching. They didn't deliver X-1, they delivered rubbish. This isn't a tire that self heals small holes but doesn't live up to the commercial, this isn't another energy drink promising 5 hours of alertness and giving you caffeine jitters. These devices are just garbage, these are like essential oils or magic crystals promising to cure a disease or otherwise perform and simply not. They promised categories of features and faked demos so they knew it couldn't do X when they sold it.

But even worse, this device cannot do anything useful. This can't do A through W, I will grant it Y and Z because it boots and doesn't catch fire.

But even worse, this device tracks way too much and that might be leaked harming you.

There is no coherent way to claim this is not a scam in every sense of the word. And coming from people who committed other scams doesn't make this not one by comparison.

These types of logs are extremely useful for debugging, just by doing that doesn't mean it's doing it for the purpose of selling your data to evil corp.

> These types of logs are extremely useful for debugging, just by doing that doesn't mean it's doing it for the purpose of selling your data to evil corp.

Downvoted because you didn't read the article and just commented something based on the word logs.

Maybe identifying who would buy the next Juicero, Multivitamins and “be your own boss” Multi-level-Marketing scheme?