Jailbreaking RabbitOS(da.vidbuchanan.co.uk)
da.vidbuchanan.co.uk
Jailbreaking RabbitOS
https://www.da.vidbuchanan.co.uk/blog/r1-jailbreak.html
295 comments
So this is the Juicero of AI assistants.
Juicero was beautifully (over)engineered and worked as advertised. They just thought people would be willing to pay exorbitant amounts of money for a machine that can only juice proprietary bags of pre chopped fruit blends from the company. Everything worked exactly like it was supposed to. It was just the actual business model that was ridiculous.
i'm not sure it really worked as advertised, the machine didn't appreciably create more juice than just squeezing the bag yourself by hand, and the bags weren't really "fresh squeezed juice" because it was largely already in a liquid state and only required sqeezing to get the last bit out of the bag.
No this is more like your juicero press having no functional parts except a pipe going to the Juicero HQ where they mix together juices from different juice providers and then pump it to your Juicero with a 5 minute delay
Shamelessly resubmitting my own article with a slightly more attention-grabbing title ;)
Great write up! Thanks for putting so much work into this investigation and report.
> Shamelessly resubmitting my own..
If everyone shamelessly resubmitted their own stuff.....a.k.a "please don't delete and repost"
See also the "don't linkbait; don't editorialize" rule in relation to titles. ;-)
If everyone shamelessly resubmitted their own stuff.....a.k.a "please don't delete and repost"
See also the "don't linkbait; don't editorialize" rule in relation to titles. ;-)
> See also the "don't linkbait; don't editorialize" rule in relation to titles
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.
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.
If it's a problem then I'll just edit the original article. The current title (on HN) is objective and accurate, and I received feedback that the original title buries the lede(s)
That seems sensible. Ignoring for a moment the HN guidelines, I agree that the new title is just a better description (I read it... either previously here or from lobsters, but yeah the actual content was good).
Even if it’s not an issue, the title you chose now is simply more information dense as well. It’s all around better.
Thanks for the read :)
Thanks for the read :)
Rules aside I can see why title iteration can be good, i saw the original and didnt click it, but im glad i did this time
HN has actually a page entirely dedicated to posts that went overlooked and are therefore invited to resubmit
https://news.ycombinator.com/invited
https://news.ycombinator.com/invited
there's also https://news.ycombinator.com/pool, though I'm not sure what the difference
edit: https://news.ycombinator.com/item?id=26998308 explains it
edit: https://news.ycombinator.com/item?id=26998308 explains it
The rules are "don't delete and repost", not "don't repost" (and this isn't just me rules-lawyering, I believe it's the intended interpretation)
HN explicitly allows reposts:
>Are reposts ok?
>If a story has not had significant attention in the last year or so, a small number of reposts is ok. Otherwise we bury reposts as duplicates.
>Please don't delete and repost the same story. Deletion is for things that shouldn't have been submitted in the first place.
https://news.ycombinator.com/newsfaq.html
>Are reposts ok?
>If a story has not had significant attention in the last year or so, a small number of reposts is ok. Otherwise we bury reposts as duplicates.
>Please don't delete and repost the same story. Deletion is for things that shouldn't have been submitted in the first place.
https://news.ycombinator.com/newsfaq.html
Good call. Thank you for sharing, it’s really quite fascinating.
I really appreciate your writing style for the article. It could have been dry, but instead it kept me engaged.
[deleted]
It was surprisingly (or not) hard to find what this "Rabbit R1" device was (despite the `I assume by now that most people have heard of the Rabbit R1.`), so here is a paste from Wired:
"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.
"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.
You really have to watch the Steve Jobs-esque announcement video to understand what they were promising with this device, and understand how utterly it failed to deliver on those promises.
https://www.youtube.com/watch?v=22wlLy7hKP4
https://www.youtube.com/watch?v=22wlLy7hKP4
Are you sure it wasn't always meant to just be a preorder + data harvesting scam?
One thing brought up by the article is that for all their other sketchiness, they do provide a constant stream of software updates for existing devices. That makes it unlikely it was a pre-order scam.
Oh wow, that's wild.
It's like a cuckoo that has evolved to mimic Steve Jobs, just enough to feed on VC and beta product dollars. I'm sure it'll take off out of the nest, fat and happy, once its brood parasitism is complete.
It's like a cuckoo that has evolved to mimic Steve Jobs, just enough to feed on VC and beta product dollars. I'm sure it'll take off out of the nest, fat and happy, once its brood parasitism is complete.
On iOS the “problem” for a third-party app is that there is no mechanic by which it could always listen to your mic, and trigger actions based on keywords.
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.
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.
Oh good, now everyone can spy on me, not just Apple.
If the product was truly revolutionary, users wouldn't mind opening an app to talk to it.
The whole point of the product is not having to open apps...
[deleted]
[deleted]
Yeah, I tried a web search and after a lot of stuff about the South Sydney Rabbitohs, I found this review of Rabbit R1:
https://www.theverge.com/2024/5/2/24147159/rabbit-r1-review-...
They don't seem impressed.
https://www.theverge.com/2024/5/2/24147159/rabbit-r1-review-...
They don't seem impressed.
Honestly I don't understand how they got customers in the first place, the idea is so bad for a start that it really shows people are knowlingly buying stuff with the sole purpose of producing e-waste.
I don't understand the pleasure they get from this.
I don't understand the pleasure they get from this.
What's so bad about the idea? I like the idea, this is not well executed but I am looking forward Apple making something like it - maybe by just improving the WatchOS.
That is the thing, it is only really interesting if it is software incorporated into an existing wearable or a smartphone.
It's interesting if it replaces a wearable or smartphone, too.
Well from the very start you knew it wouldn't.
> logs include:
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
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
Nobody would collect all this by accident, especially when considering the purpose of the product…
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
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.
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.
"pray I don't alter it further"
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.
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.
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?"
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.
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.
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?
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.
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.
Ah thank you, that does make sense! I appreciate the context you've been able to add (both here and elsewhere in the thread).
> wouldn't it be silly to have the llm produce the weather?
Typically the LLM queries external tools as appropriate and then incorporates the result into the response.
Typically the LLM queries external tools as appropriate and then incorporates the result into the response.
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] 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
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
Seems like that is indeed the case. But that does not explain the need for logging.
However, in these days weather APIs are the ones you can actually query without API keys.
See, for example. https://www.weather.gov/documentation/services-web-api
There is a forecast for you:
`curl -X GET "https://api.weather.gov/gridpoints/TOP/31,80/forecast" \ -H "Accept: application/geo+json" `
All the third-party APIs for weather just try to artificially monetize them, because under the hood the information is typically governmental funded.
See, for example, https://news.ycombinator.com/item?id=40589172
However, in these days weather APIs are the ones you can actually query without API keys.
See, for example. https://www.weather.gov/documentation/services-web-api
There is a forecast for you:
`curl -X GET "https://api.weather.gov/gridpoints/TOP/31,80/forecast" \ -H "Accept: application/geo+json" `
All the third-party APIs for weather just try to artificially monetize them, because under the hood the information is typically governmental funded.
See, for example, https://news.ycombinator.com/item?id=40589172
Not specifically related to your point, but government provided weather APIs might not be a thing in the US in the future: https://www.theatlantic.com/science/archive/2024/07/noaa-pro...
Most likely they were collecting it all to make debugging easier.
> 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.
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.
Regarding storage of WiFi names:
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.
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.
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.
> 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.
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.
The article also explains that the log issue was fixed a week before this article was posted, but it’s buried at the bottom.
> 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.
> 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.
mynameisvlad(3)
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.
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.
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.
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)
(And yes, it is sent periodically regardless of what you're doing, not as part of specific queries)
[deleted]
The logs are not the appropriate place to store any of this information, and the article is discussing these things as having been found in the logs.
If you have Android, run adb logcat, and note its persistent :3
Logcat is persistent? I thought it used a fairly small rolling buffer.
Persistent and rolling, ex. adb bugreport is sufficient enough to get details of something an hour ago
[deleted]
Base64 encoded MP3s? That's just ridiculous. All you get by base64 encoding them is 33% more data used.
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.
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.
Common alternatives are Apache Avro, MessagePack, FlatBuffers, and Thrift.
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 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.
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).
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.
CBOR could also be a good fit
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)...
Not familiar with this at all, but I assume it's so that one type can encode and store mixed lists of 64-bit signed and unsigned integers.
HTTP multi-part. It’s a decades-solved problem and works with whatever the current request compression scheme is (gzip, brotli, etc).
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.
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.
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.
There seems to be a common trend of people writing "JSON APIs" thinking that every other part of HTTP is off-limits.
If you're looking for the simplest possible replacements, MessagePack (for data in transit) and SQLite (for data at rest) are worth considering
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.
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.
> unless somebody is doing something stupid like sending files via json
Like mp3s?
Like mp3s?
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.
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
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.
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.
> it should cost 50 bucks and run on chips from 2010.
If we're really honest it should run on Tamagotchi-era hardware.
If we're really honest it should run on Tamagotchi-era hardware.
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".
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.
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? :-)
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? :-)
MP3 tags are not there just to being pretty.
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.
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.
Use Cap'n'proto and get encoding efficiency and a convenient dev experience. It continually amazes me that devs choose to live in a world of pain.
CBOR is basically JSON but with binary keys and values
> 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.
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.
They will not understand your point. It is a kind of invincible ignorance, a little like how rich kids can’t understand why anyone has to budget.
We’ve squandered almost all of the advancements.
We’ve squandered almost all of the advancements.
I get what your saying but it’s what everyone uses. At this point it’s like saying write assembly instead of C.
Hopefully people come around but I doubt it.
Hopefully people come around but I doubt it.
It wouldn't surprise me if Google is doing the exact same for every Android phone in existence already... but more discretely.
How else would they be able to tell you how busy a location is when you pull it up in Google Maps?
This one works with Wifi SSID lists I believe. No need for audio.
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.
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.
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.
Most of these dont seem like a big deal
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) 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
On one hand I agree. Big corporations are doing this too. On the other hand:
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.
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.
>2. I trust big corporations to have better data categorization and secure storage.
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.
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.
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.
Apple will make a much better version? On what evidence?
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.
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.
Aren't most of these collected by normal mobile phones anyway?
No, my Ubuntu Touch device doesn't send my location anywhere and it's a normal smartphone.
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
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).
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).
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.
or maybe the burden of proof is on you to articulate why is isn't troubling. it helps to read the article too.
nah, you can't just claim something is troubling without saying why. asking someone to prove a negative has never been a part of logical thinking.
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.
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.
>so it's troubling.
How so?
How so?
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.
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 saw this first thing in the morning and was wondering why you were giving them a nastiness score of zero
lol! I worked at Rabbit and left after reading through the codebase and being gaslit by the execs
Well? Aren't you going to spill some juicy details about the supposed "large action model"?
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.
This is what coffeezilla said on his channel after speaking to devs at Rabbit
[deleted]
When I saw the browser/app automation “RAG” thingy in the first presentation I was instantly suspicious. I’m sure the AI is hard enough (that I don’t know) but I do know that everyone is fighting against automation and scraping, so it’s an arms race that’s very difficult to win. Simulating human behavior isn’t enough (sometimes being human isn’t even enough either).
For instance, I know that a fintech company (big name) had deployed a physical android phone fleet to sign in to banks on behalf of users, around 8 years ago. That’s because the bank had used extensive fingerprinting tech to lock out any automation.
It’s sad, but the world is much less interoperable than it used to be. That’s not Rabbits fault, but obviously lying about it is.
For instance, I know that a fintech company (big name) had deployed a physical android phone fleet to sign in to banks on behalf of users, around 8 years ago. That’s because the bank had used extensive fingerprinting tech to lock out any automation.
It’s sad, but the world is much less interoperable than it used to be. That’s not Rabbits fault, but obviously lying about it is.
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.
Sounds like you hopped a bullet.
pmdr(8)
Cool write up!
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?
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.
I don't have any interest in this product or sympathy for its manufacturer, but:
>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.
>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.
Nobody's defending Rabbit here, but that's chickenshit journalism, and it happens too often.
Since when is an individual's personal blog "journalism", and therefore expected to live up to that standard?
I take it as a compliment!
It might not be "journalism", but I think it's pretty reasonable to wait a week for responses before dropping serious accusations It's not exactly a onerous requirement to meet.
Reasonable? Sure.
Expected and therefore commented that it's chickenshit when it doesn't happen? Yeah, no. If this were a reputable news outlet, that expectation would be reasonable.
Expected and therefore commented that it's chickenshit when it doesn't happen? Yeah, no. If this were a reputable news outlet, that expectation would be reasonable.
I think it's entirely reasonable to report what you find when you find it, and update later with responses received.
Most of what's mentioned in the article is not any new allegations. Rabbit has been berated for their GPL violations for over a month now and the excessive logging was rectified before he even sent in a request for comment.
Requesting comments were only a formality to address already voiced concerns
Requesting comments were only a formality to address already voiced concerns
It’s also pretty reasonable to respect the GPL when you financially benefit from it, yet here we are.
No no no, Rabbits mistakes are honest small mistakes from a great company! But this author, man of pure evil, hasn't waited long enough for my favourite bunny company to cover up their lies :(
>Since when is an individual's personal blog "journalism", and therefore expected to live up to that standard?
If the author is going to pretend to be a journalist of a security researcher, I see no problem holding their work to the ethical standards expected from those sorts of people.
If the author is going to pretend to be a journalist of a security researcher, I see no problem holding their work to the ethical standards expected from those sorts of people.
>I could write a whole other article about how hostile and dismissive they've been to researchers
Please do.
Please do.
It was 1.5 working days, and there are other factors not mentioned in this article which meant they were lucky to get that (I could write a whole other article about how hostile and dismissive they've been to researchers). If they had requested an extension, I may have considered, but they didn't respond at all.
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.
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.
> It was 1.5 working days, and there are other factors not mentioned in this article which meant they were lucky to get that
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.
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.
> first discovered it
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.
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.
Your outrage sounds disingenuous. 1.5 days is definitely not a reasonable timeframe for a response to a partially resolved issue. What is 1.5 days in this context? Friday afternoon and Monday? Do you and their security engineers even live in the same time zone?
>Your outrage sounds disingenuous.
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.
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.
This is a symptom of a broader narrative perpetuated the company itself, that any criticism is from "haters".
I know nothing about the product they are selling. As an engineer, I think writing a critical blog post after giving just a 1.5 day notice is bad behavior.
> Why did you wait until the article was ready to be published to inform them?
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
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
> AFAIK the OP did not start writing his article until after they resolved it, which they did within 24 hours.
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.
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.
Agreeing with the reviewer consensus that the product is mediocre is not "hostility". My blog post, on my personal blog, delivers objective technical analysis along with my personal opinions.
I don't owe anyone an emotionless regurgitation of facts, it would be incredibly boring.
I don't owe anyone an emotionless regurgitation of facts, it would be incredibly boring.
The issue was first overlooked up OP, see quote from my previous comment.
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
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
> Standard practice is to inform the vendor early and work with them as you write the article
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.
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.
For security issues, this is true. For finding that the company is lying, evil and obviously engaging in malicious practices... why ask them for a comment at all, except for a better blog post? Fuck them
> why ask them for a comment at all
Journalist integrity, but the author has expressed in several comments that he doesn't care about that. Which is fine I suppose, but it's weird to pretend to be a journalist or security researcher and not adopt any of their ethical standards.
Journalist integrity, but the author has expressed in several comments that he doesn't care about that. Which is fine I suppose, but it's weird to pretend to be a journalist or security researcher and not adopt any of their ethical standards.
It appears Rabbit had already released an update to address the issue on July 11th, the day before the author asked them for comment. They posted it here https://www.rabbit.tech/security-advisory-071124
> 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.
> 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.
How did you find this page? I tried to navigate all visible links from the main page and don't see any security advisory pages.
I believe it was buried in their "community forums", which only recently became publicly viewable.
Yeah, that’s an incredibly short timeframe, done on a Friday with what looks like an 8-hour time difference.
Back before bug bounties, the industry mostly coalesced around RFPolicy[0] in terms of security notification and response timelines. Upon establishing initial contact, five business days were given for a response before public disclosure if no response was received.
To me five business days seems appropriate if you’re acting in good faith and truly interested in hearing a response. It doesn’t feel like that was the intent; it feels more like a weak attempt to use the lack of response to pile on further.
https://packetstormsecurity.com/files/23364/rfpolicy-2.0.txt...
Back before bug bounties, the industry mostly coalesced around RFPolicy[0] in terms of security notification and response timelines. Upon establishing initial contact, five business days were given for a response before public disclosure if no response was received.
To me five business days seems appropriate if you’re acting in good faith and truly interested in hearing a response. It doesn’t feel like that was the intent; it feels more like a weak attempt to use the lack of response to pile on further.
https://packetstormsecurity.com/files/23364/rfpolicy-2.0.txt...
Timezone differences were accounted for (see my other reply), and this wasn't the first time they were hearing any of it. It was just the first time I put it into an article.
RFPolicy was well intentioned but in no way was ever a standard the community at large adhered to in my experience.
They should have used an LLM to write responses when nobody's at the office
[deleted]
[deleted]
> 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, 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.
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.
You still cannot distribute those modules AND the kernel on the same "package", though.
That's why I hate DKMS. A true libre kernel would never need to use that.
And a true, completely libre kernel wouldn't have been used by anyone. DKMS exists for a reason, it's a good, non dogmatic compromise. Linux makes a lot of those compromises that make it easier to use in/with proprietary environments.
If you don't care about freedom then step out and just use MacOS with Macports.
For actual freedom, Linux-Libre it's a must.
May I remind anyone the disaster of Mediatek and most SOCs with propietary drivers which are bound to old kernel releases and they became useless bricks over time, even with PostMarketOS? Or the infamous GMA500/Poulsbo, where even 2D acceleration it's missing. IDK it even supports modesettings thru KMS/DRM.
Inb4 'these are old machines, nearly useless', my n270 atom netbook still runs Luakit like a champ and it supports GL 2.1, enough for tons of tasks. On top of that, with ZRAM the GB of RAM now holds far more data than it did back in the day.
May I remind anyone the disaster of Mediatek and most SOCs with propietary drivers which are bound to old kernel releases and they became useless bricks over time, even with PostMarketOS? Or the infamous GMA500/Poulsbo, where even 2D acceleration it's missing. IDK it even supports modesettings thru KMS/DRM.
Inb4 'these are old machines, nearly useless', my n270 atom netbook still runs Luakit like a champ and it supports GL 2.1, enough for tons of tasks. On top of that, with ZRAM the GB of RAM now holds far more data than it did back in the day.
I don't disagree with any of that. I'm saying that normal Linux doesn't want to optimize for free as in freedom/libre, it wants to be a usable and modern kernel. The license it uses helps it with doing that, but Linus has been clear that the project doesn't care about much more than that.
It's sad but it is a tradeoff. I wish it wasn't and that most hardware and software was "libre", but that's not the case so there's a trade off to be made.
It's sad but it is a tradeoff. I wish it wasn't and that most hardware and software was "libre", but that's not the case so there's a trade off to be made.
Out-of-kernel-tree modules are still useful even if they are exactly the same license. I don't know what's with this tendency of having to put everything under the same umbrella. My modules will never get merged with Linux and I have no intention of doing so, but it is perfectly legal to distribute them with Linux (both are GPLv2). DKMS still helps to manage the mess that is the lack of a stable ABI for Linux.
[deleted]
> 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.
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]
Went back and read some of the old lkml posts from Linus, and it seems most of the kernel is GPLv2 with some version of the "GCC Runtime Library Exception". I assume the "syscall exception" he repeatedly refers to is related, but it's never quite clear what the exact mechanism is. Linus himself seems to take it case-by-case what constitutes a "derived work" from the kernel, or at least did so 20 years ago. It might have become clearer since then, or maybe not.
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.
https://archive.is/HP2Qk
I would love to have an open-source 10 inch epaper device, but for now I have a note air 3.
I would love to have an open-source 10 inch epaper device, but for now I have a note air 3.
was going to mention Onyx as well. what's made it worse was that they tried to spin the outrage about the violation as anti chinese racism
> 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.
[1]: https://www.gnu.org/licenses/old-licenses/gpl-2.0.html
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
The first sentence you're quoting is ambiguous. It might be in full agreement with you, or it might be disagreeing with you.
> GLP requires you to disclose the (license and source code) on request
> GPL requires to to disclose the license and (source code on request)
> GLP requires you to disclose the (license and source code) on request
> GPL requires to to disclose the license and (source code on request)
Good point; I missed that. On a second reading, I'm inclined to believe they intended the second interpretation.
This company is definitely wading through the trough of disillusionment. Excited what root on the device could open up.
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.
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.
I hope it’s presenting him with facts instead of made up history badly regurgitated from troll Reddit posts…
I would expect just as many hallucinations as "normal" from an OpenAI API endpoint. I agree that knowing the difference between facts and formatted content is good media literacy at any age.
Do you really expect a 10 year old to consistently be able to tell when an LLM is feeding them convincing-sounding but ultimately false information?
Ultimately it doesn't matter and that battle is already lost, even adults overly trust the output and never question it. I've had colleagues insist to my face that something wasn't possible in a piece of software I'm an expert in because ChatGPT told them it wasn't possible.
ChatGPT/Open AI's API is such a good liar I have to fact check it externally on matters specific to my field of work for the last decade. I can't imagine being a kid expected to do the same with general knowledge provided by it and having no other sources made available to me while I use it.
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.
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.
Are you sure this device isn't teaching your child how to use gasoline to cook spaghetti faster?
> Excited what root on the device could open up.
It's an low-end android device. It can do exactly no more than your phone or tablet.
It's an low-end android device. It can do exactly no more than your phone or tablet.
> 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
I saw somebody say that they really missed the mark by not making it a kid's device.
I saw somebody say that they really missed the mark by not making it a kid's device.
Good writeup on the process, but the amount of negative spin in the article left a bad taste in my mouth.
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.
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.
There's an acrimonious relationship between Rabbit and hackers and both sides seem to keep escalating.
Just grouping together your other similar comments in this thread, so people can read the existing replies rather than duplicating conversations:
- https://news.ycombinator.com/item?id=40988915
- https://news.ycombinator.com/item?id=40988541
- https://news.ycombinator.com/item?id=40988915
- https://news.ycombinator.com/item?id=40988541
[deleted]
[deleted]
[deleted]
> 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.
Their lawyers are considering the options how to sue you.
> As of the end of July 15th, they have not responded.
Their lawyers are considering the options how to sue you.
That'd be hilarious.
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.
Why? They're under no obligation to ask them in the first place.
Not asking is fine, asking is nice, asking when you know it's a period they won't realistically be able to respond just to be able to list you didn't get a response is shitty.
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.
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.
I report the non-response directly after reporting how long I gave them to respond, it's not in any way misleading or underhanded.
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.
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.
Sometimes "it's just reporting the facts" can be done with a lean in itself. You may disagree, that's fine too of course, but this isn't a plain jane "Rabbit did not immediately respond with comments" it has a timeline omitting some facts like like starting on a Friday and is intermixed with commentary on the reachout. Not anything that's false, just also not maybe as neutral as it set out to be. Also not the end of the world, it's still a good article overall.
fwiw, my article does not set out to be "neutral". It reflects my research-backed personal opinions of Rabbit Inc. and their products (strong negative sentiment) and it would be disingenuous of me to leave that out.
Nonetheless, I reject the idea that saying "July 12th" instead of "Friday" is lying by omission.
Nonetheless, I reject the idea that saying "July 12th" instead of "Friday" is lying by omission.
It wouldn't be instead of, rather both. I.e. Friday doesn't have full context nor does July 12th. It also wouldn't have to get rid of the other personal commentary, just not put it in the section about having reached out for comment. That said you're more than right in that nothing says the article must set out to be neutral.
At least you're honest about it being a hit piece and not a journalistic endeavor, but you should at least feel a little shame about your own shitty behavior.
1. You didn't have to ask them for any comment, that was a courtesy on your part.
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.
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.
Nitpick: How can there be less than 0% chance?
It's a lot higher than that, I scooped cybernews.com, who rushed to publish their similar piece after seeing mine, a day later: https://cybernews.com/security/rabbit-r1-hacked-using-old-vu...
(It's so similar in parts that it almost looks like a rip-off of mine, but I do believe we were just thinking in the same direction)
(It's so similar in parts that it almost looks like a rip-off of mine, but I do believe we were just thinking in the same direction)
[deleted]
Same issue as saying "the [party] didn't immediately respond". It's technically accurate and objective, but to me personally, it has an undertone of pointing out "just another shady way" this entity that's reported on is acting - when really it isn't.
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.
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.
I learned that when they write “did not immediately respond to our request” in the newspaper it means that the journalist called and no one picked up, then went to print.
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.
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.
>when they write “did not immediately respond to our request” in the newspaper it means that the journalist called and no one picked up, then went to print.
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.
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.
Because you look like a god damn idiot if you do that. Maybe people here don't care about that, but real humans in the real world do care about that kind of thing.
[deleted]
No, not at all.
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.
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.
> to ask for a comment at the same time as hitting publish and note that they’d been asked for a comment
No, this is not responsible. The reader is not aware of the time difference and cannot distinguish between a lack of appropriate time to respond and the organization being subversive. Given the context, the usually implies the latter.
I wouldn't ever want this to legally be an issue, but we do have to recognize that a lot of language is implicit and that also matters. If you did such a think I believe it would be more ethical to write something along the lines of
No, this is not responsible. The reader is not aware of the time difference and cannot distinguish between a lack of appropriate time to respond and the organization being subversive. Given the context, the usually implies the latter.
I wouldn't ever want this to legally be an issue, but we do have to recognize that a lot of language is implicit and that also matters. If you did such a think I believe it would be more ethical to write something along the lines of
> we reached out to <x> at the time of publishing and will update when we receive a response.
> On <date> the <y>-news team reached out to <x> and will update when we receive a response.
No. Not in this case.
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.
Given how their devices are selling, I don't think they can afford lawyers.
I'm enjoying reading this, and I never paid much attention to the R1 product. "Carroot" was enough of a chuckle to merit the rest. :D
I have, in fact, not heard of the Rabbit R1. And the link in TFA leads to some weird promo video instead of something informative. Does anyone have a succinct explanation of what the article is talking about?
Edit: nm, I commented before reading other comments. Anyone else confused should read jylam's comment explaining.
Edit: nm, I commented before reading other comments. Anyone else confused should read jylam's comment explaining.
[deleted]
Is the data harvest restricted to that particular device or is it an Android feature?
Very interesting writeup!
> In the spirit of terrible rabbit-themed puns, I'm naming the jailbreak "carroot".
This is good.
This is good.
What’s the actual value of pinpointing behavior for the crowd that bought this?
Maybe identifying who would buy the next Juicero, Multivitamins and “be your own boss” Multi-level-Marketing scheme?
Maybe identifying who would buy the next Juicero, Multivitamins and “be your own boss” Multi-level-Marketing scheme?
Honestly ... what did people expect.
localfirst(1)
SrslyJosh(2)
What did people expect to lapin?
I expected a privacy-preserving open source AI assistant like Mycroft (https://en.wikipedia.org/wiki/Mycroft_(software)) combined with Leon (https://getleon.ai).
Oh, no! GPS, WiFi, cell tower location, token to attach to their network, all that information flowing! Hope none of you are using an Android phone or iPhone.
Get a grip, people.
Get a grip, people.
I hate this type of articles, not because of content but because of what authors trying to do. They always try to be morally superior and create controversy by nitpicking issues.
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.
[deleted]
> I hate this type of articles, not because of content but because of what authors trying to do. They always try to be morally superior and create controversy by nitpicking issues.
> 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.
> 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.
It's kinda funny all/most of the initial goodwill towards the Rabbit was purely because of the Teenage Engineering design.
I hope TE chooses their clients better in the future. The guy behind Rabbit is a known grifter.
I hope TE chooses their clients better in the future. The guy behind Rabbit is a known grifter.
this 'grifter' is on TE's board, so things are out of control
>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.
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.
CoffeeZilla made a thorough video about this: https://www.youtube.com/watch?v=NPOHf20slZg
I need to ask, will this break the warranty trying to recreate these steps?
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.
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.
> 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.
> [...]
> 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.