> I could also build an entire custom kernel from source, but Rabbit Inc. has chosen to violate the GPL2 license and not make the sources available. Of particular note are their drivers for hall-effect scroll wheel sensing, and camera rotation stepper motor control, which are closed-source and yet statically linked into the GPL'd kernel image. Violations like this are hugely destructive to the free software ecosystem, from which companies like Rabbit Inc. benefit.
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.
> GPL requires you to disclose the license and source code on request
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.
Rabbit will be long out of business before any blowback about the GPL actually reaches them. As for kernel modules, I was under the impression that Linux has a specific exemption to the GPL for those regardless of how they're linked, as long as they don't require any modifications to the kernel itself.
> I was under the impression that Linux has a specific exemption to the GPL for those regardless of how they're linked, as long as they don't require any modifications to the kernel itself.
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.
GPL is tricky at the best of times to enforce. Onyx, makers of Boox, was called out on this years ago (sorry I couldn’t find a single concise source to link to) and hasn’t faced any consequences. I doubt Rabbit will get in trouble for this.
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.
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.
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
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.
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.
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.
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.
If you don't mind sharing, what were some of the first red flags that you noticed in the codebase? Looking at all these jailbreaks and vulnerabilities visible from the outside, I'm sure they only scratch the surface.
I believe the juicy details are "It's a marketing term for getting off-the-shelf LLMs to call out to pre-written browser automation scripts", but I'd love to hear it from the horse's mouth.
Honestly, it's pretty shitty to ask someone for a comment on a friday afternoon and publish on a monday morning pretending that they didn't reply when you likely gave them zero business hours to reply.
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.
I'd take that about as seriously as I would take a threat from the people who made the Juicero, considering the likely imminent insolvency of the company involved.
> However, due to the aforementioned "kamakiri" bootrom exploit, the first link of the chain is irrevocably broken.
> [...]
> But, we don't even need to use an exploit here. Both the brom and Preloader boot stages feature a USB bootloader mode, which in the r1's case will accept unsigned DA ("Download Agent") images over USB, and allow you to execute them from memory (from SRAM in the case of brom, and DRAM in the case of Preloader).
The RabbitOS developers can patch all of this by setting an efuse that instructs the bootrom to block bootloader access over USB. Moto did this a couple years ago with their MediaTek devices that were susceptible to bootrom attacks via this surface. If I remember correctly this efuse was set at the LK stage and was applied in a regular OTA firmware update.
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?
As is, the hardware is still pretty overpriced. If the price drops to <$50 (maybe after they turn off their servers, heh) then I'd agree, it's an alright hardware platform.
Ah, I wish this product could have panned out. I hope it doesn't become a bugbear for future experiments with hardware user interfaces + AI. I'm still of the Bret Victor school of thought that we can do better than just tapping and swiping at glass rectangles.
Sure but your glass rectangle already has all the power and hardware features necessary to provide those other interfaces. Or more conveniently, a smart watch can relay queries to your phone.
I sort of respect Humane for trying something genuinely different, though it doesn't seem to solve any real problems. The Rabbit R1 is just cheap junk.
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.
Readit News
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
> GLP requires you to disclose the (license and source code) on request
> GPL requires to to disclose the license and (source code on request)
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.
Deleted Comment
I would love to have an open-source 10 inch epaper device, but for now I have a note air 3.
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.
(And yes, it is sent periodically regardless of what you're doing, not as part of specific queries)
Deleted Comment
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.
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.
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.
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.
Deleted Comment
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.
> 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.
Deleted Comment
> [...]
> But, we don't even need to use an exploit here. Both the brom and Preloader boot stages feature a USB bootloader mode, which in the r1's case will accept unsigned DA ("Download Agent") images over USB, and allow you to execute them from memory (from SRAM in the case of brom, and DRAM in the case of Preloader).
The RabbitOS developers can patch all of this by setting an efuse that instructs the bootrom to block bootloader access over USB. Moto did this a couple years ago with their MediaTek devices that were susceptible to bootrom attacks via this surface. If I remember correctly this efuse was set at the LK stage and was applied in a regular OTA firmware update.
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 sort of respect Humane for trying something genuinely different, though it doesn't seem to solve any real problems. The Rabbit R1 is just cheap junk.
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.