[HN Gopher] Jailbreaking RabbitOS
___________________________________________________________________
Jailbreaking RabbitOS
Author : Retr0id
Score : 1057 points
Date : 2024-07-17 16:41 UTC (1 days 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!
| Retr0id wrote:
| I updated the article title in the end, but ironically
| the HN mods appear to have put it back to closer to the
| original (minus parenthetical).
| 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
| ehPReth wrote:
| 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
| 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.
| mlsu wrote:
| 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.
| 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.
| Kwpolska wrote:
| If the product was truly revolutionary, users wouldn't mind
| opening an app to talk to it.
| throwaway3306a wrote:
| The whole point of the product is not having to open
| apps...
| incompatible wrote:
| 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.
| prmoustache wrote:
| 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.
| throwaway3306a wrote:
| 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.
| prmoustache wrote:
| That is the thing, it is only really interesting if it is
| software incorporated into an existing wearable or a
| smartphone.
| throwaway3306a wrote:
| It's interesting if it replaces a wearable or smartphone,
| too.
| prmoustache wrote:
| Well from the very start you knew it wouldn't.
| 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.
| DaiPlusPlus wrote:
| 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.
| YurgenJurgensen wrote:
| 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.
| freedomben wrote:
| "pray I don't alter it further"
| 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.
| seanhunter wrote:
| 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
| 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.
| 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.
| bonestamp2 wrote:
| > 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.
| 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.
| unscaled wrote:
| 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).
| ForHackernews wrote:
| 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.
| 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)...
| recursive wrote:
| 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.
| DaiPlusPlus wrote:
| HTTP multi-part. It's a decades-solved problem _and_
| works with whatever the current request compression
| scheme is (gzip, brotli, etc).
| sitharus wrote:
| 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.
| Spivak wrote:
| 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.
| odo1242 wrote:
| If you're looking for the simplest possible replacements,
| MessagePack (for data in transit) and SQLite (for data at
| rest) are worth considering
| 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.
| monocasa wrote:
| > unless somebody is doing something stupid like sending
| files via json
|
| Like mp3s?
| TeMPOraL wrote:
| 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.
| waterTanuki wrote:
| 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
| Barrin92 wrote:
| 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.
| troupo wrote:
| > it should cost 50 bucks and run on chips from 2010.
|
| If we're really honest it should run on Tamagotchi-era
| hardware.
| erinaceousjones wrote:
| 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".
| whywhywhywhy wrote:
| > 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.
| anthk wrote:
| 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.
| quotemstr wrote:
| 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.
| pantalaimon wrote:
| CBOR is basically JSON but with binary keys and values
| hnlmorg wrote:
| > 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.
| foobiekr wrote:
| 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.
| moffkalast wrote:
| It wouldn't surprise me if Google is doing the exact same for
| every Android phone in existence already... but more
| discretely.
| arcanemachiner wrote:
| How else would they be able to tell you how busy a location
| is when you pull it up in Google Maps?
| prmoustache wrote:
| 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.
| moffkalast wrote:
| https://xkcd.com/1807/
| baegi wrote:
| 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.
| brookst wrote:
| 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.
| 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.
| vagrantJin wrote:
| Apple will make a much better version? On what evidence?
| alternatex wrote:
| 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.
| 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?
| niutech wrote:
| No, my Ubuntu Touch device doesn't send my location anywhere
| and it's a normal smartphone.
| Bayko wrote:
| 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
| 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.
| Suppafly wrote:
| 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.
| yard2010 wrote:
| 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.
| Suppafly wrote:
| >so it's troubling.
|
| How so?
| 7bit wrote:
| 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.
| 8jef wrote:
| How is this different from average smartphone telemetry sent
| back to ... ?
| niutech wrote:
| Both Ubuntu Touch nor Sailfish OS doesn't send this kind of
| private data by default.
| rty32 wrote:
| 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.
| nebulous1 wrote:
| I saw this first thing in the morning and was wondering why you
| were giving them a nastiness score of zero
| 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
| klabb3 wrote:
| 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_.
| 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.
| copywrong2 wrote:
| 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 :(
| Suppafly wrote:
| >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.
| 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".
| fantasybuilder wrote:
| 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.
| 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.
| copywrong2 wrote:
| 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
| Suppafly wrote:
| > 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.
| 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.
| Ylpertnodi wrote:
| "Only recently" will have a date.
| Retr0id wrote:
| Would you like to share that date with us?
| 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.
| anthk wrote:
| That's why I hate DKMS. A true libre kernel would never
| need to use that.
| mardifoufs wrote:
| 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.
| AshamedCaptain wrote:
| 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.
| monocasa wrote:
| > 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.
| chuckadams wrote:
| 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.
| 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.
| draven wrote:
| 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.
| 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?
| whywhywhywhy wrote:
| 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.
| zamadatix wrote:
| 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.
| 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.
| nebulous1 wrote:
| > 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.
| 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.
| Retr0id wrote:
| 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.
| zamadatix wrote:
| 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.
| Retr0id wrote:
| 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.
| zamadatix wrote:
| 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.
| Suppafly wrote:
| 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.
| carlosjobim wrote:
| 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.
| thomashop wrote:
| Nitpick: How can there be less than 0% chance?
| Retr0id wrote:
| 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)
| posix86 wrote:
| 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.
| hmottestad wrote:
| 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.
| Ylpertnodi wrote:
| >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.
| 1992spacemovie wrote:
| 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.
| barnabee wrote:
| 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.
| godelski wrote:
| > 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
| > we reached out to <x> at the time of publishing and will
| update when we receive a response.
|
| While one could still presume subversive behavior, I think
| we can all recognize that this is at least less of an
| implicit blame. For more accuracy, you can even put the
| date. I've seen this format before > On
| <date> the <y>-news team reached out to <x> and will update
| when we receive a response.
|
| This ensures that the reader is able to properly understand
| the time differential and the implications. Remember that
| reading articles is highly asynchronous. You may be reading
| them the day of or a month later. If you read that line and
| <date> was the same day as today or even yesterday, you
| wouldn't think anything suspicious. But if it is a week
| later or a month later you have quite a good reason to
| believe <x> is being subversive.
| yard2010 wrote:
| No. Not in this case.
| walrus01 wrote:
| 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.
| archon810 wrote:
| Given how their devices are selling, I don't think they can
| afford lawyers.
| 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
| smm11 wrote:
| 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.
| make_it_sure wrote:
| 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.
| irjustin wrote:
| > 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.
| steakscience wrote:
| 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.
| tb1989 wrote:
| this 'grifter' is on TE's board, so things are out of control
| Ylpertnodi wrote:
| >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.
| asenna wrote:
| CoffeeZilla made a thorough video about this:
| https://www.youtube.com/watch?v=NPOHf20slZg
| LangChinBob wrote:
| I need to ask, will this break the warranty trying to recreate
| these steps?
| mlekoszek wrote:
| 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.
| TillE wrote:
| 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.
| stalfosknight wrote:
| So this is the Juicero of AI assistants.
| 542354234235 wrote:
| 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.
| 93po wrote:
| 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.
| alephxyz wrote:
| 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
| broomzy wrote:
| > _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.
___________________________________________________________________
(page generated 2024-07-18 23:07 UTC)