[HN Gopher] Jailbreaking RabbitOS: Uncovering secret logs, and G...
___________________________________________________________________
Jailbreaking RabbitOS: Uncovering secret logs, and GPL violations
Author : Retr0id
Score : 615 points
Date : 2024-07-17 16:41 UTC (6 hours ago)
(HTM) web link (www.da.vidbuchanan.co.uk)
(TXT) w3m dump (www.da.vidbuchanan.co.uk)
| Retr0id wrote:
| Shamelessly resubmitting my own article with a slightly more
| attention-grabbing title ;)
| mtlynch wrote:
| Great write up! Thanks for putting so much work into this
| investigation and report.
| traceroute66 wrote:
| > 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. ;-)
| yjftsjthsd-h wrote:
| > 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.
| Retr0id wrote:
| 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)
| digging wrote:
| Given the situation, I'd recommend updating the article
| title, as it's definitely more interesting to someone who
| _hasn 't_ heard of RabbitOS!
| yjftsjthsd-h wrote:
| 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).
| Semaphor wrote:
| 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 :)
| bloqs wrote:
| 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
| duiker101 wrote:
| HN has actually a page entirely dedicated to posts that went
| overlooked and are therefore invited to resubmit
|
| https://news.ycombinator.com/invited
| Retr0id wrote:
| 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)
| mtlynch wrote:
| 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
| isodev wrote:
| Good call. Thank you for sharing, it's really quite
| fascinating.
| CoastalCoder wrote:
| I really appreciate your writing style for the article. It
| could have been dry, but instead it kept me engaged.
| jylam wrote:
| 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.
| mewse-hn wrote:
| 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
| nerdponx wrote:
| Are you sure it wasn't always meant to just be a preorder +
| data harvesting scam?
| margalabargala wrote:
| 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.
| codetrotter wrote:
| 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.
| aetch wrote:
| iOS apps can record audio in the background with the provided
| API already so this isn't actually a hold up
| danudey wrote:
| You can continue to record audio in the background, but you
| can't use the API to just listen all the time, like "hey
| siri" does, and then open the app and act on it.
| rpcope1 wrote:
| Oh good, now everyone can spy on me, not just Apple.
| mrbluecoat wrote:
| > 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
| nicce wrote:
| Nobody would collect all this by accident, especially when
| considering the purpose of the product...
| freedomben wrote:
| 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
| ghayes wrote:
| 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.
| bilbo0s wrote:
| 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.
| Aurornis wrote:
| 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.
| nicce wrote:
| > 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.
| Aurornis wrote:
| > 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.
| freedomben wrote:
| 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?
| Aurornis wrote:
| 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.
| freedomben wrote:
| Ah thank you, that does make sense! I appreciate the
| context you've been able to add (both here and elsewhere
| in the thread).
| d110af5ccf wrote:
| > 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.
| nicce wrote:
| 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
| bsharper wrote:
| 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...
| ummonk wrote:
| Most likely they were collecting it all to make debugging
| easier.
| Aurornis wrote:
| > 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.
| echoangle wrote:
| 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.
| Aurornis wrote:
| > 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.
| mynameisvlad wrote:
| > 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.
| Aurornis wrote:
| 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.
| mynameisvlad wrote:
| Still doesn't explain why Rabbit chose to not use the
| built-in Settings app that existed, and then logged the
| information. And in some cases sent it to their servers.
|
| It's great they don't log that _now_ , but that doesn't
| magically fix what they've been doing, unnecessarily, for
| months.
|
| You're also going out of your way to defend Rabbit in
| this thread, with several multi-paragraph posts rebutting
| the same things. If they're not paying you, they
| certainly should be.
| refulgentis wrote:
| Way over the top commentary from you, I was already
| shaking my head before this round.
|
| It was unkind of you to write up an elaborate accusation
| just because you felt frustrated.
|
| There's one _very_ obvious reason why they they don 't
| use the Android Settings app: it's built for displays at
| least 2x as tall. (some of the dozens more in [1])
|
| Additionally, a major point of frustration for you seems
| to be a perceived refusal to admit there's no reason to
| send WiFi info to the server. _TFA doesn 't claim they
| are._ Just logged locally in files.
|
| Note everyone along the way clearly said "this is bad and
| I don't like it" along with facts they were trying to
| communicate --- its really annoying to have to add those
| disclaimers because people might be on edge, I can't
| imagine how frustrating it was to add them and _still_
| get the personal attack.
|
| source: I have no love for Rabbit. I left Google in
| October to found an AI startup. At Google, I worked on
| Android for several years.
|
| [1] it's unskinned, has a bunch of unnecessary settings,
| would complicate it with legacy nonsense in what was sold
| as simplification of legacy nonsense, and they're using
| something that makes it the face of the device (setting
| their APK as launcher? kiosk mode?). I can't think of a
| single OEM that says "hey just go to the settings app to
| set up wifi".
| Aurornis wrote:
| > And in some cases sent it to their servers.
|
| Where do you see that they're sending it to their
| servers? The article doesn't say that WiFi names were
| sent to the servers.
|
| > You're also going out of your way to defend Rabbit in
| this thread, with several multi-paragraph posts rebutting
| the same things. If they're not paying you, they
| certainly should be.
|
| No, I'm just correcting misinformation in this comment
| section. Some people are apparently only here to pile on
| Rabbit regardless of the truth, but the rest of us are
| actually curious about the facts of the situation.
| mikestew wrote:
| _If they 're not paying you, they certainly should be._
|
| Accusations of shilling for a company is not only
| uncalled for, in my eyes it greatly weakens your argument
| because I will have to assume that all you have left are
| ad hominems. Let your arguments stand on their own and
| leave the insinuations out of it.
| echoangle wrote:
| 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.
| throw1230 wrote:
| 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.
| Retr0id wrote:
| 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)
| seanhunter wrote:
| 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.
| refulgentis wrote:
| If you have Android, run adb logcat, and note its
| persistent :3
| johnmaguire wrote:
| Logcat is persistent? I thought it used a fairly small
| rolling buffer.
| refulgentis wrote:
| Persistent and rolling, ex. adb bugreport is sufficient
| enough to get details of something an hour ago
| underdeserver wrote:
| Base64 encoded MP3s? That's just ridiculous. All you get by
| base64 encoding them is 33% more data used.
| progbits wrote:
| 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.
| mikenew wrote:
| 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.
| LeoPanthera wrote:
| 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.
| ForHackernews wrote:
| 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.
| chris_pie wrote:
| CBOR could also be a good fit
| crest wrote:
| 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)...
| poincaredisk wrote:
| 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.
| moffkalast wrote:
| It wouldn't surprise me if Google is doing the exact same for
| every Android phone in existence already... but more
| discretely.
| shmatt wrote:
| 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
| xmprt wrote:
| 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.
| llm_trw wrote:
| >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.
| inhumantsar wrote:
| 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.
| chuckadams wrote:
| 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.
| ForHackernews wrote:
| Aren't most of these collected by normal mobile phones anyway?
| Suppafly wrote:
| 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.
| DyslexicAtheist wrote:
| or maybe the burden of proof is on you to articulate why is
| isn't troubling. it helps to read the article too.
| iamexcited wrote:
| lol! I worked at Rabbit and left after reading through the
| codebase and being gaslit by the execs
| rideontime wrote:
| Well? Aren't you going to spill some juicy details about the
| supposed "large action model"?
| Retr0id wrote:
| 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.
| TestingWithEdd wrote:
| This is what coffeezilla said on his channel after speaking
| to devs at Rabbit
| krukah wrote:
| 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.
| RobotToaster wrote:
| Sounds like you hopped a bullet.
| barnabee wrote:
| 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?
| Retr0id wrote:
| 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.
| Arnavion wrote:
| 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.
| lagniappe wrote:
| Nobody's defending Rabbit here, but that's chickenshit
| journalism, and it happens too often.
| mynameisvlad wrote:
| Since when is an individual's personal blog "journalism", and
| therefore expected to live up to that standard?
| Retr0id wrote:
| I take it as a compliment!
| gruez wrote:
| 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.
| mynameisvlad wrote:
| 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.
| JoshTriplett wrote:
| I think it's entirely reasonable to report what you find
| when you find it, and update later with responses
| received.
| KibbeWater wrote:
| 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
| callalex wrote:
| It's also pretty reasonable to respect the GPL when you
| financially benefit from it, yet here we are.
| Ylpertnodi wrote:
| >I could write a whole other article about how hostile and
| dismissive they've been to researchers
|
| Please do.
| Retr0id wrote:
| 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.
| Arnavion wrote:
| Sure, up to you. In any case I take it they still haven't
| responded?
| Retr0id wrote:
| Still no response.
| Aurornis wrote:
| > 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.
| Retr0id wrote:
| > 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.
| fantasybuilder wrote:
| 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?
| qual wrote:
| > _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.
| Retr0id wrote:
| This is a symptom of a broader narrative perpetuated the
| company itself, that any criticism is from "haters".
| KibbeWater wrote:
| > 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
| Aurornis wrote:
| > 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 PS122
| (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.
| Retr0id wrote:
| 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.
| KibbeWater wrote:
| 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
| fullspectrumdev wrote:
| > 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.
| Aurornis wrote:
| 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.
| Lockal wrote:
| 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.
| Retr0id wrote:
| I believe it was buried in their "community forums", which
| only recently became publicly viewable.
| clwg wrote:
| 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...
| Retr0id wrote:
| 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.
| fullspectrumdev wrote:
| RFPolicy was well intentioned but in no way was ever a
| standard the community at large adhered to in my experience.
| unleaded wrote:
| They should have used an LLM to write responses when nobody's
| at the office
| OsrsNeedsf2P wrote:
| > 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.
| chuckadams wrote:
| 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.
| AshamedCaptain wrote:
| You still cannot distribute those modules AND the kernel on
| the same "package", though.
| harles wrote:
| 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.
| GrantMoyer wrote:
| > 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
| taylorbuley wrote:
| 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.
| callalex wrote:
| I hope it's presenting him with facts instead of made up
| history badly regurgitated from troll Reddit posts...
| taylorbuley wrote:
| 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.
| bmoxb wrote:
| 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?
| pizzalife wrote:
| Are you sure this device isn't teaching your child how to use
| gasoline to cook spaghetti faster?
| madeofpalk wrote:
| > 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.
| Aurornis wrote:
| 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.
| wmf wrote:
| There's an acrimonious relationship between Rabbit and hackers
| and both sides seem to keep escalating.
| Retr0id wrote:
| 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
| usr1106 wrote:
| > 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.
| Retr0id wrote:
| That'd be hilarious.
| Suppafly wrote:
| 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.
| madeofpalk wrote:
| Why? They're under no obligation to ask them in the first
| place.
| zamadatix wrote:
| 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.
| schmookeeg wrote:
| 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
| bigstrat2003 wrote:
| 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.
| jmakov wrote:
| Is the data harvest restricted to that particular device or is it
| an Android feature?
| heyrikin wrote:
| Very interesting writeup!
| fabiensanglard wrote:
| > In the spirit of terrible rabbit-themed puns, I'm naming the
| jailbreak "carroot".
|
| This is good.
| freetanga wrote:
| 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?
| nineteen999 wrote:
| Honestly ... what did people expect.
| RobotToaster wrote:
| What did people expect to lapin?
| dboreham wrote:
| So..umm..not an internet connected sex toy then?
| jrflowers wrote:
| Not with that attitude it isn't
___________________________________________________________________
(page generated 2024-07-17 23:00 UTC)