Posts in Android (20 found)
マリウス 3 weeks ago

I Do Not Recommend Google Hardware

I’ve been a GrapheneOS user for years now. Back in 2022 I switched away from /e/OS on a Samsung Galaxy S10 to a Google Pixel 6a that I had bought, because at the time it happened to be one of the cheapest devices on the short list of officially supported Pixels . However, my history with Google phones goes way past the 6a and ever since I got my first Nexus , every single piece of Google (branded and manufactured) hardware that has passed through my hands has eventually broken on a hardware level, way quicker than expected. At this point I have run out of patience with Google ’s consumer electronics and have decided to stop giving the company any more of my money. This post is part personal post-mortem, part survey of the wider Pixel landscape, and part forward-looking note on what I’m going to do instead. Disclosure: The opinions in here are entirely my own, formed from years of using Google hardware as a paying customer. To be very clear up-front, I have never been a fan of Google as a company, and I have certainly never been a fan of their hardware design language. I normally do not run Google ’s software on any of my devices , I avoid Google services , and I would prefer not to give the company a single cent. The only reason I have nevertheless ended up with a stack of Pixel devices on my desk is GrapheneOS . Graphene , to this day, requires Pixel hardware because Google ’s phones are essentially the only consumer Android devices that ship with a verified-boot chain, a relockable bootloader after flashing, and a security coprocessor ( Titan M2 ) that the project considers sufficient for its threat model. There is no other Android manufacturer in this market that offers a comparable hardware security surface for an alternative OS. So if you want the strongest privacy- and security-hardened Android, you buy a Pixel . That’s literally the only reason. In my original write-up of the switch to GrapheneOS I went into the why in much more detail. The short version is that, I no longer trusted any stock smartphone OS, and after years of bouncing between CyanogenMod , LineageOS , and /e/OS , GrapheneOS was the first ROM that felt like actual engineering rather than a community paint-job over a vendor blob. In my follow-up post about the Pixel 8 I went so far as to call the Pixel 8 “a solid piece of hardware, if you happen to find a fully functional device” . In hindsight, I have to admit that I was wrong. Let me start with the actual Google devices that I have owned, in chronological order. The Nexus 5 was the first Google -branded phone I bought, back when the device was still being manufactured by LG and GrapheneOS was not yet a thing. I ran it for a while on Google ’s stock Android and, after the initial honeymoon period, switched it over to CyanogenMod , the project that, years later , would be reborn as LineageOS . For its first year or so, the Nexus 5 was actually a likeable phone, as it was compact, light, with a clean software experience that, at the time, felt refreshing compared to the bloated OEM skins on competing Android devices. Then the hardware started giving up. The battery, which had been mediocre to begin with, became unreliable and the phone would report 40% charge one moment and shut off entirely the next, and over time it began to randomly reboot and power off without any obvious trigger. The decline was not gradual either and once the battery started misbehaving, the device was effectively unusable within a matter of weeks. Combined with a charging port that became increasingly finicky about which cables it would accept, the phone went from likeable to unusable in well under two years of moderate use. The Nexus 6 , which, ironically given where this post is heading, was actually built by Motorola rather than by Google itself, replaced the Nexus 5 once the latter had given up on life. As with its predecessor, GrapheneOS was still years away, so I alternated between Google ’s stock firmware, CyanogenMod , and eventually LineageOS over the course of owning it. What made the Nexus 6 particularly memorable was the way in which its internals seemed to fail one component at a time , almost like a series of unfortunate but separate events. First, the microphone began cutting out during calls, with the other end of the line hearing nothing or only a faint, crackling signal. Then the loudspeaker and earpiece started developing distortion, eventually to the point where music and call audio were barely intelligible. Finally, true to the pattern that would later repeat on every subsequent Google / Pixel device I owned, the battery rapidly lost capacity and started misbehaving, with the phone shutting off at high reported charge levels and refusing to hold a charge during light use. All of this happened within the first few years of ownership, well before any reasonable expectation of obsolescence. In retrospect, the Nexus 6 also gave me my first real taste of what Motorola hardware can feel like. It’s worth keeping that in mind for the later section on Motorola ’s planned GrapheneOS -compatible devices . The Pixel 2 XL was my first phone branded purely as a Google device, with all the responsibility for design, hardware integration, and support sitting with Google itself. GrapheneOS still didn’t exist as it does today (the project’s early predecessor, CopperheadOS , was in the middle of its very public implosion right around this time), so the device once again spent its life running Google ’s stock firmware as well as LineageOS . The Pixel 2 XL disappointed me from essentially day one, and only got worse from there. The two main themes were performance, which, even fresh out of the box, felt sluggish for a flagship that was supposed to be competing with the Galaxy S8 and the iPhone 8 , as well as battery, which, as with every Google device before, deteriorated rapidly. The Pixel 2 XL was a particularly bad, with animations stuttered, app launches being inconsistent, and the whole experience feeling half a generation behind what Samsung and Apple were shipping that year. As the device aged, this only got worse. Within the first year I was already noticing significant drops in standby and active runtime, and by the second year I was forced to carry a power bank everywhere and even basic tasks like opening the camera app or switching between recent apps became noticeably slow. In addition, the Pixel 2 XL shipped with a notoriously bad display that suffered from blue-tint shifting, screen burn-in within months of light use, and uneven color rendering. All of which were defects that Google , in classic form, partially acknowledged with software workarounds rather than hardware replacements for most affected owners. The Pixel 2 XL was the phone that, at the time, made me seriously question whether I wanted to keep buying Google hardware at all. The answer, sadly, turned out to be yes , but only because of the eventual emergence of GrapheneOS and the absence of viable alternatives on comparable hardware. The Pixel 6a was purchased on sale for $299 in late 2022. It came with the Tensor G1 , served as my primary GrapheneOS device for roughly a year and a half, and was eventually relegated to “spyware phone” duty after I upgraded to the Pixel 8 . As with every Google phone prior, the Pixel 6a battery life declined noticeably and the device eventually became part of Google ’s Battery Performance Program , which, depending on how you look at it, was either a voluntary repair offer or an opaque battery nerf forced on owners via a mandatory update. In addition, the the charging port developed an unstable connection , which made charging frustrating and unreliable. After roughly two years of daily use, the device became unusable enough for me to downgrade it to a backup device, only to finally toss it after only two more years. Note: Google ’s entire A-series has a documented track record of battery problems. The Pixel 4a has been the subject of a UK Office for Product Safety and Standards alert for overheating and fire risk, the Pixel 6a has been the subject of multiple melted-device reports and was pulled from Google ’s refurbished store after fire incidents, and the Pixel 7a has had its own battery swelling repair program . Google has not initiated a proper recall in any of these cases. The Pixel 8 replaced the Pixel 6a in mid-2024 after I came across an unusually good tax-refunded deal . I have been running GrapheneOS on it from day one. Within less than two years of moderate, careful use, this phone developed the now-infamous Pixel 8 green-screen-of-death , a display defect that causes the screen to glitch with vertical green lines and flicker until you physically squeeze the lower part of the chassis . Google has, in a rare admission, extended the warranty on Pixel 8 displays to three years specifically because of how widespread this defect is, while pointedly not extending it to the Pixel 8 Pro despite reports of the same problem on that model. However, because my device suffered a drop and hence has its backside glass shattered, as well as the adjacent corner scratched open, Google will blame the screen issue (in my case) on the impact and won’t grant me a free repair. It’s also important to note that the lower portion of the device gets noticeably and uncomfortably hot under normal load, which is a known issue with the Tensor G3 SoC and its Samsung Exynos 5300 modem . In addition, the Pixel suffers from the family’s connectivity issues , that had plagued the Pixel 7 series already. When I sat down to research a possible replacement (a Pixel 9 or Pixel 10 ), the picture only got bleaker, but more on this in a moment. Note: Probably the most maddening pet peeve that I have with the Pixel 8 is its slippery surface. It is the only phone that I ever had that, no matter on what surface I put it, will eventually slide down without me interacting with it. Without stickers or protectors on its back the phone is so slippery that it will glide away from virtually any surface material. Put the Pixel 8 on a smooth wooden table and it will move by itself over time. Put it on a rough wooden speaker box and it will fall over the edge halfway through the first song that’s playing. Put it on top of another smartphone and it will fall off sideways. Whenever I hear a hollow knock I already know that it was the Pixel 8 randomly falling off of whatever surface I had put it on. The Pixel Tablet joined the line-up in late 2024 specifically because it is the only tablet that GrapheneOS supports. I wrote a relatively positive review of it at the time, with the significant caveat that it’s “underpowered” and not really suitable for anything more demanding than media consumption and light note-taking. A year and a half later, that already-modest assessment has aged poorly. The device’s Tensor G2 , which was already two generations old at the point Google shipped the tablet, has become noticeably sluggish as apps have continued to grow heavier. Lightroom Mobile , which was one of my primary reasons for buying it, runs with random glitches, crashes and odd behaviour , to the point where I’m looking to migrate my photography workflow once again to something else. Also, it seems like the device developed some WiFi connectivity issue leading to specifically streamed content pausing/stuttering for around half a second before resuming for maybe another half a minute, only to then repeat this behavior. I don’t know whether this is a hardware issue or a GrapheneOS bug, but I’ve noticed this issue for now over a year. Additionally, the battery life has degraded faster than anticipated, with editing workloads draining a full charge in under three hours even with the screen way below maximum brightness, and overall the tablet has aged significantly faster than anticipated , rendering it largely useless for any of the things I originally bought it for. In short, Google shipped a 2023 tablet with a 2021 chip and a sealed battery, and in 2026 this has become very noticeable. Note: These were only the Google -branded and -made devices that I owned, alongside a long list of other Android devices from HTC , Sony , Samsung , OnePlus , and even OPPO , that in all honesty weren’t exponentially better with regard to reliability and longevity. It would be easy to write all of the above off as bad luck, so let me back up the personal experience with what is documented elsewhere. Google ’s A-series phones in particular have, by now, a multi-generation track record of batteries that swell, overheat, or catch fire. The Pixel 4a was included in the UK Office for Product Safety and Standards alert for fire risk. Google ’s Battery Performance Program nerfed the device’s battery via a mandatory update rather than acknowledging a hardware defect. The Pixel 6 had reports of battery swelling and off-gassing , with some users describing flame and smoke incidents. The Pixel 6a saw multiple fire incidents , was pulled from the refurbished store , and was subjected to the same Battery Performance Program as the 4a . Google restricted charge rate and capacity after 400 cycles via forced OTA on July 8, 2025. The Pixel 7 and 7 Pro had widespread swelling reports less than three years post-launch. Google ’s response has been described as “inconsistent” by Android Central , with some users receiving free replacements and others being told to pay out of pocket. Oh, and the Pixel 7a has its own repair program for swollen batteries. When the same failure mode shows up across five consecutive versions/generations of phones from the same vendor, and the vendor’s first response is to throttle charging rather than replace the cells, you’re no longer looking at bad luck but at a structural problem with battery sourcing, cell qualification, or thermal design. I’ve mentioned my own Pixel 8 display dying above. The Extended Repair Program that Google published in response covers Pixel 8 devices that exhibit “a vertical line running from the bottom of the display to the top or a display flicker” , with coverage extended to three years post-purchase. Pixel 8 Pro owners with the same vertical line defect have not been so lucky and are largely on their own. Manufacturers don’t extend warranties on a whim. Google extending warranties on the Pixel 8 display by a factor of three is, in itself, the admission-of-a-defect that the company has otherwise tried to avoid in public. Since the Tensor G2 , Google ’s Pixel flagships have been using a Samsung Exynos 5300 modem (and its successors) for cellular connectivity. This is the same modem family that has, generation after generation, been criticised for worse signal stability than the Qualcomm modems used by competitors, as well as significantly higher power consumption, especially on 5G, and battery drain bugs that essentially trade-off endurance for modem efficiency. Google ’s answer in the Pixel 10 generation has been to switch to a MediaTek T900 , which according to early benchmarks is an improvement, but does not retroactively help any of the millions of Pixel 6 / 7 / 8 / 9 owners who paid flagship prices for what was, by industry standards, a sub-par modem. Google ’s Tensor chips were seemingly never designed to compete head-to-head with Qualcomm or Apple on raw CPU or GPU throughput, despite the pricing being in a similar range. For example, the Snapdragon 8 Gen 3 is roughly 68% faster than the Tensor G3 in Geekbench 6 multi-core, and about 32% faster in single-core. In some graphics workloads, it’s roughly twice as fast. The Apple A17 Pro is nearly 50% faster than the Tensor G4 in multi-core, and the Pixel 9 Pro XL ’s Tensor G4 loses up to 50% of its sustained CPU performance under thermal throttling, with the throttling kicking in within three to four minutes of full load . The Pixel 10 and Pixel 10 Pro , powered by the Tensor G5 , score 3,707 in the Vulkan GPU benchmark , compared to 26,333 for the Samsung Galaxy S25+ , which is a difference of roughly 7x . Even the Pixel 9 Pro ’s outgoing chip outperforms its successor at 9,023 points. In 3DMark Wild Life Extreme , neither the Pixel 10 nor the Pixel 10 Pro break 20 FPS, while a Snapdragon 8 Elite device comfortably clocks 38 FPS. Hence, the Snapdragon 8 Elite -based Galaxy S25 comfortably outscores the Pixel 10 in both single- and multi-core CPU performance , with the S25 posting roughly 75% higher multi-core scores. If you want a single chart that summarises this, Geekbench ’s Android benchmarks page is a good overview and shows that Pixel flagships do not appear anywhere near the top. What this means in practice is that when you buy a Pixel , you are paying roughly the same money as you would for a Samsung , OnePlus , Xiaomi , or Apple flagship, but you are getting an SoC that is one and a half to two generations behind on raw compute, and even further behind on graphics. The phone feels snappy because Android is optimized for these chips and because Google ’s AI use cases are accelerated by the TPU , but once you actually push the device, e.g. with raw photo editing, gaming, prolonged camera use, or pretty much anything that requires sustained performance, it falls behind quickly. Beyond the flagship failures, Pixel devices have, generation after generation, shipped with a steady stream of quality-control issues that read more like early-access hardware than flagship . E.g. with the Pixel 8 , Google shipped a batch of factory-unlocked phones without the ability to relock the bootloader, requiring a return. Then we had the Pixel 8 green screen recall , which had been the precursor to the extended-warranty program, as well as the phantom touches issue, where intermittent ghost- touches were frequently dismissed by support as user error before being diagnosed as actual hardware problems. The Pixel 9 Pro XL had its infamous camera tilt issue, where some users reported the 5x telephoto lens shipping physically tilted out of the box, and the Pixel Tablet had the “check charging accessory” issue, where the charging dock dies surprisingly often , with troubleshooting steps that boil down to “clean the contacts and hope for the best” . You can find an essentially endless stream of similar reports on and the official Pixel Phone Community forums and the pattern is always the same: A defect is reported, Google ’s official support insists on app-uninstalls and factory resets, and after enough public outcry the defect is eventually quietly acknowledged via a support page, hidden so deep that probably won’t people won’t bother to look. Honestly, in my circle of people who care about privacy, the answer is almost always the same as mine, namely because of GrapheneOS . For everyone else, the answer is the camera and the “AI features” , plus a vague brand-loyalty to Google that exists for reasons I truly struggle to understand. The camera is, to be fair, very good. Google ’s computational photography pipeline is one of the few areas where the company’s ML-first approach to silicon pays off in a way the user actually notices. If you primarily care about point-and-shoot photography out of a phone, the Pixel camera is still near the top of the pile, even on the cheaper A-series . Everything else, in my view, is not competitive with what Samsung , Xiaomi , OnePlus , Nothing , or Apple ship for the same money or, in some cases, less. You can verify that for yourself. After my Pixel 8 green-screened on me, my initial instinct was to do what I’ve always done and just replace it with the next Pixel . I spent a few weeks looking at deals on the Pixel 9 and Pixel 10 , reading through their respective issue threads on Reddit , looking at the benchmarks above, and decided that I simply don’t want to give Google any more of my money for what is, charitably put, garbage hardware sold at flagship prices. The interesting development that makes this decision possible is that, on March 2, 2026 , at MWC 2026 , Motorola officially announced a partnership with the GrapheneOS Foundation . This is the first time GrapheneOS will officially support a non- Pixel vendor, with availability expected to begin in 2027. There is some uncertainty in all of this, though, as hardware schedules often slip and partnerships sometimes dissolve, and there’s no guarantee that the eventual Motorola device will meet Graphene ’s requirements (verified boot, relockable bootloader, etc.) at a price point that’ll be remotely interesting to the average GrapheneOS user. There is also the risk that Android 17 turns into more of an Intelligence System launcher than an actual OS. However, I’d rather wait six to twelve months and roll the dice on Motorola than spend another $800-$1000 on a phone that, by all available evidence, is statistically likely to develop a hardware defect shortly past its warranty window. The obvious follow-up question is whether existing Motorola hardware, like the Edge series, or the current razr line-up, is any good to begin with, since these broadly resemble what the eventual GrapheneOS -compatible devices are likely to be. Frankly, I have no idea. The reviews of the Motorola Razr Ultra (2025) seem relatively positive on durability. Android Central ’s one-year follow-up describes the display still looking “like the day it was received” after a year of regular use, with the major caveat that the vegan leather on the back has been peeling. Reviewers have called it “Motorola’s best and most popular flagship phone thus far” . The Motorola Edge 60 is even more interesting from a durability perspective. It carries an IP69 rating , which is above the IP68 on the latest Pixels and means the device is certified against high-pressure, high-temperature water jets in addition to sustained submersion. Motorola also commits to three OS updates and four years of security updates , which is a little behind Google ’s nominal seven years on the Pixel , but in line with the rest of the Android industry, and arguably more honest given that Google ’s seven years are seemingly predicated on the device not physically falling apart in years two and three. Note: I’ve started to believe that Google ’s 7 years of updates is simply a marketing stunt and that the company knows that most of its hardware will fail well before users get even close to the seventh year. If you look up (used) offers for e.g. the now almost 7-year-old Pixel 4a on marketplaces like eBay you’ll find the offer to be surprisingly thin. Similarly, the slightly younger 5a is also relatively hard to come by in good shape. Older smartphones sustained above 80% of their original battery capacity for up to 500 charging cycles, which amounts to less than 3 years if you assume a full charge every two days, which is unrealistically generous especially for an Android device. Even if we assume that modern smartphones sustain 80% capacity for up to 1000 recharges and we use the generous two-day cycle, the phone will likely drop below 80% battery capacity within 5 and a half years. Again, that’s a very positive calculation that doesn’t take into account prolonged charging cycles (over night), environmental impacts (high heat or freezing cold) and arbitrary battery deterioration. A more realistic outlook is a drop below 80% within the device’s first three years. It is also worth noting that at some point past the 80% mark degradation speeds up sharply and becomes roughly exponential, as Lithium plating, electrolyte depletion, and loss of active material compound on each other. This means that the drop from 80% capacity to 60% will happen significantly faster than the initial drop from 100% to 80%. The 80% mark was deliberately chosen by manufacturers as it kind of marks the practical end of the stable region of the battery. Past that point, the phone will become less stable and show effects like sudden reboots, or at some point even shutdowns at around 30% indicated charge. Compared to the Pixel line, Motorola ’s 2025 hardware appears to have notably better water- and dust-ingress protection ( IP69 vs IP68 ), use Qualcomm Snapdragon silicon, which means, per the benchmarks above, meaningfully better raw performance and meaningfully better modem efficiency, have a build quality that holds up better through year-one stress tests, even on the foldable form factors that are notoriously hard to engineer, and are priced lower than the equivalent Pixel Pro , with the obvious caveat that the razr ultra at $1,300 is, in fact, a tough pill to swallow . What it doesn’t appear to offer, at least yet, is the Pixel ’s camera quality. Reviews of the Edge 60 and Edge 50 Ultra are competent but not class-leading on the photography front. For someone who uses a dedicated camera for serious photography and reserves the phone for documentary snapshots, this is a perfectly acceptable trade-off, but your mileage may vary. Until GrapheneOS -compatible Motorola hardware is actually on shelves, I’m going to keep using the Pixel 8 with its hardware workaround (yes, I’m literally squeezing the lower part of the chassis whenever the screen starts glitching) and avoid spending any more money on Google hardware. Unless the Pixel 8 will completely die or become otherwise unusable I won’t be purchasing another Google device. For anyone in a similar situation, my recommendation is to not upgrade if your current Pixel still works, and instead hold on to it . Pixel to Pixel generational improvements are marginal at best, and you’re almost certainly going to inherit a fresh set of defects with each new model. Also, E-waste is a real concern , especially with repairability scores below most Apple devices, particularly because of the extensive use of adhesives within Pixel phones. If you have to get a replacement in the meantime, buy used or discounted. The Pixel 8a is occasionally available below $300 refurbished, the Pixel 9 is now in the same price band as the Pixel 8 was a year ago, and the Pixel 9a is probably the best affordable entry point. Keep in mind that none of the historical hardware-defect patterns have spared the Pro models, but the Pro pricing has consistently included an Apple -level markup for what amounts to a bigger screen and one extra camera sensor. Hence I would avoid those variants. If you can hold off on a phone purchase for another year or so, see how the Motorola / GrapheneOS situation develops. If the first compatible devices land at a reasonable price with an acceptable build quality, that will be the first competitive alternative to the Pixel line for privacy-conscious users. If you’re a tech power-user, however, maybe consider Linux on mobile as a more radical alternative. I’ve been eyeing postmarketOS on the Fairphone 6 for a while, as it appears to be making meaningful progress, but it is not yet a daily-driver experience and probably won’t be for another year or two. The Pinephone is a dead end , imho, but it seems like Ubuntu Touch is coming along nicely. Google ’s consumer hardware is, in my unscientific but consistent personal experience, garbage. The A-series has a multi-generation track record of batteries that swell or catch fire. The Pixel 8 has a display defect serious enough to introduce an extended warranty program. The Pixel Tablet shipped with a chip that was already two generations old. Tensor -based flagships are routinely outperformed by competitors at the same price point, and thermal-throttle hard enough under sustained load that the silicon is barely delivering half of its rated performance for any task longer than a few minutes. I have given Google enough of my money over the past years. The only reason I have kept doing so is because of the community ROMs and, in the recent past, because of GrapheneOS , which I consider one of the most important pieces of consumer software in the privacy and security space today, that has been Pixel -only by hardware necessity. As of MWC 2026 , that constraint has an end date however. Until either GrapheneOS -compatible Motorola hardware actually ships, or Linux on Mobile becomes actually usable on a halfway modern device like the Fairphone (with replaceable battery), I am holding on to my squeezable Pixel 8 and not buying anything else from Google . After that, I expect to never own another Pixel ever again. Note: I deliberately picked the same title format as my I Do Not Recommend Bitwarden and I Do Not Recommend Proton Mail posts. The reason is the same in all three cases, which is that I used the product, in many cases over the course of years, recommended it to others in writing on this site, and have since come to a different conclusion. If your own experience has been different and you’re happily using a Pixel without issues, that’s great. This post is, in part, an updated honest disclosure of where I personally landed, and a counterweight to my own earlier, more positive reviews of these devices.

0 views

‘Popa’ Botnet Linked to Publicly-Traded Israeli Firm

For the past four years, a sprawling Android-based botnet called Popa has forced millions of consumer TV boxes to relay Internet traffic linked to advertising fraud, account takeovers, and mass data-scraping efforts. This week, researchers from multiple security firms concluded that the Popa botnet is linked to NetNut , a “residential proxy” provider operated by the publicly-traded Israeli firm Alarum Technologies Ltd [NASDAQ: ALAR]. Malicious streaming devices sold online that enroll the user’s home Internet address in a residential proxy service. Image: HUMAN Security. Popa is a massive botnet, but by all accounts it is unlike traditional botnets that enlist compromised systems in destructive activities, such as coordinating huge distributed denial-of-service attacks. Rather, Popa appears designed with a singular purpose: Implementing a persistent communications layer capable of registering a device, maintaining long-lived encrypted connections, and opening communication tunnels on demand. Experts say Popa is a plugin component associated with the Vo1d botnet, a large-scale malware campaign targeting unofficial Android-based TV boxes. These devices, which are marketed under thousands of brand names and model numbers and broadly available for purchase at top e-commerce destinations, all advertise the ability to stream hundreds of subscription video services for an up front one-time fee. But as the FBI and security industry experts have warned repeatedly, these streaming boxes typically bundle or come pre-installed with software that turns the user’s TV into a “ residential proxy ” — allowing anyone to route their Internet traffic through that device for as long as it remains plugged into a wall socket and connected to a local network. More concerning, some of these proxy networks do little to stop malicious customers from communicating with and even compromising systems on the local network of the unsuspecting device owner. The first clues about Popa’s origins came in a 2025 report from the Chinese security company XLAB , which flagged at least nine domain names that were used to register and direct the activities of compromised devices. In a report released today, the security firm Qurium described how it stumbled on some of those same domains while investigating a series of disruptive and expensive data scraping events targeting the company’s hosted organizations in May 2026, in which the scraping activity was scattered evenly across more than 1.4 million Internet addresses. Qurium said it found several dozen domains used to control Popa that were all hosted in lockstep across multiple Internet addresses over time, including gmslb[.]net , safernetwork[.]io, tera-home[.]com, and ninjatech[.]io . Digging deeper, Qurium discovered gmslb[.]net was referenced in dozens of pirated or modded video content streaming apps, such as CRICFy , DooFlix , Sprozfy , RTS Tv , Flixoid , CyberFlix , Rapid Streamz , TvMob and HD/OceanStreams . Qurium’s report notes that most of the domains long used to control the Popa botnet were seized or dismantled in July 2025 , after Google , HUMAN Security and Trend Micro teamed up to disrupt Badbox 2.0 , a botnet that is closely associated with Vo1d. Qurium said that immediately after that disruption, several dozen new domains were registered to serve as controllers for the Popa botnet, but that one of those control domains was not new: ninjatech[.]io . Ninjatech is a company founded by Moishi Kramer , whose LinkedIn profile says he is vice president of research and development at NetNut. That resume credits Kramer for helping NetNut to build from the “ground up,” “designing the architecture,” and “scaling the NetNut” before the company was acquired by Alarum Technologies. A self-created listing at the job board F6S references Kramer as the sole owner of the Ninjatech domain (a screen capture of it is pictured below). Image: F6S.com. Responding via email, Mr. Kramer said Ninjatech ceased operations approximately five years ago, when the company sold a software development kit (SDK) called Popa that was designed to use a small portion of a device’s bandwidth and to run only after the host application obtained user consent. “That code was sold and licensed to third parties including resellers years ago,” Kramer said. “Once software is distributed that way, the original developer has no control over how others later modify, rebrand, or deploy it.” Kramer said neither he nor NetNut builds, operates or maintains the infrastructure being described as Popa, nor does he control the Ninjatech domain. “I didn’t register the June 2025 domains you mention, and I don’t know who did,” he continued. “I have no control over, or visibility into, that infrastructure. I can only tell you it isn’t operated by me or by NetNut.” But in a separate Popa research report released today, the proxy-tracking company Synthient said a recent analysis of the Popa SDK revealed outbound traffic clearly associated with NetNut. “The research team assesses with high confidence that devices running Popa forward traffic from Netnut clients,” Synthient wrote. “This proves without a shadow of a doubt that Popa actively continues to be used by NetNut as part of their proxy pool.” Synthient’s platform receiving outbound traffic from Popa. Image: Synthient.com. Alarum Technologies, NetNut’s Tel Aviv-based parent company, said the reports by Synthient and Qurium contained “demonstrably inaccurate assertions and flawed deductions rather than verified facts.” Alarum shared a statement saying they reject the basic characterization of the SDKs and technologies discussed in the reports as a “botnet.” “The SDKs at issue are designed to facilitate bandwidth-sharing functionality and do not transform user devices into malware-controlled systems or otherwise compromise the devices on which they operate,” the statement reads. “Netnut operates a commercial proxy network and maintains policies, procedures, and technological measures designed to promote lawful and responsible use of its services.” Alarum said NetNut places “significant emphasis on appropriate notice and consent mechanisms, conducts customer due diligence, monitors for potential misuse, and takes steps intended to detect and mitigate suspicious or unauthorized activity.” “This method of operation is supported both by internal procedures and policies, including performing KYC checks and additional due diligence of NetNut’s customers, as well as employing various technological measures, designed to assist in identifying and addressing suspected misuse of the network,” their statement continued. However, in a report released on June 8, the proxy tracking service Spur asserted that NetNut does not require corporate verification or meaningful “know your customer” procedures before allowing customers to purchase proxy access. “An individual can sign up, pay, and route traffic through partner address space, including space belonging to institutions whose users never opted in,” Spur wrote . “The ‘verified corporations only’ claim is simply marketing for bandwidth sellers, not an access control on who actually uses the proxies.” “Nor is NetNut the only front door,” Spur continued. “A number of downstream white labelers and resellers repackage the same ISP proxy pool under their own brands. These outlets typically perform no KYC at all, less scrutiny than NetNut itself, who at the very least might assign an account manager to potential users. Anyone who knows where to look can buy access through a reseller with nothing more than a burner email address and $5 in crypto.” Synthient found that although the most recent builds of Popa (as of three months ago) have added the ability to ask the user for consent before installing proxy components, not all variants or previous versions of Popa contain this functionality. “Of the over 20 genuine Popa publishers analyzed, none of them were observed asking for user consent,” Sythient wrote. Chris Formosa is senior lead information security engineer for Black Lotus Labs , a division of the Internet backbone carrier Lumen Technologies . “What especially makes Popa dangerous is just how widely used NetNut is for reselling and sharing,” Formosa said, explaining that many other proxy services simply resell NetNut proxies rather than building out their own far-flung proxy networks. “So these Popa IPs appear in tons of different services all over the ecosystem, which makes it one of the most problematic and dangerous proxy botnets on the market currently.” Formosa said the Popa botnet averages between 1.5 million to 2.5 million distinct IP addresses each day, relying on between 250 and 300 Internet addresses that are used to direct its activities. “That’s why Popa is so dangerous,” Formosa said. “It may not be the largest botnet we have seen, but it is spread all over the industry, making its power very amplified.” Formosa said while that makes Popa one of the larger botnets out there today, its numbers pale in comparison to those previously boasted by IPIDEA , a China-based proxy provider that until recently operated a daily pool of nearly 10 million devices that they resold as proxies to anyone. In January 2026, Synthient published research showing that multiple new large DDoS botnets had grown rapidly by tunneling through IPIDEA proxies into the local networks of unsuspecting TV box owners and infecting other Android-based devices behind the user’s firewall. IPIDEA is based largely on SDKs used to view pirated streaming content on a vast number of TV box devices, but the service’s numbers have dwindled since January, when Google and industry partners took legal action to seize domain names that IPIDEA used to control devices and proxy traffic through them. Jérôme Meyer , a security researcher at Nokia Deepfield , said the total population of devices participating in the Popa botnet may be far higher than Lumen’s estimates. Meyer told KrebsOnSecurity that Nokia is monitoring 26 of at least 359 known relay nodes for the botnet, and estimates that each relay node handles between 35,000 and 60,000 clients simultaneously. “On the relay node subset I am looking at (26 of them), 750,000 unique sources in 24 hours,” Meyer wrote in response to questions. Nokia Deepfield released its own report today on RoboVPN , a VPN app tied to the Vo1d botnet’s Popa plugin that Qurium attributes to NetNut/Alarum Technologies. Experts say many of the world’s largest proxy providers have updated their public-facing branding to highlight their utility for training AI platforms, implying it is a primary use case for their residential proxies. That’s because AI services tend to rely on constantly mass-scraping the Internet for new text, images and video content that can be used to train large language models (LLMs). NetNut and other proxy services have recast themselves as critical infrastructure for the AI scraping economy. Image: Synthient.com. “AI companies depend on web-scraped content: for pre-training, for retrieval, for agent grounding, for search,” reads a report this month from Include Security that examines the prevalence of proxy SDKs in smart TV apps. “But the modern web isn’t scrapeable from a datacenter. Cloudflare, DataDome, HUMAN, among others throttle or block requests from known cloud IPs. The workaround is residential proxies. A scraping job routed through a Comcast or T-Mobile subscriber’s connection arrives at the target site from an IP that belongs to a paying residential customer.” This non-stop content scraping has spawned more than 70 copyright infringement lawsuits against major tech companies that have acknowledged large-scale data scraping as a major source of the “brains” behind their commercial AI offerings. Ironically, much of that scraping is being aided by proxy services that are intimately tied to unofficial Android TV boxes and associated SDKs whose stated purpose is streaming pirated content. The scraping activity has become so aggressive that it often overwhelms the targeted websites, preventing them from being reachable by legitimate visitors. In many reported cases, nonprofit organizations, libraries and universities have complained of constantly battling to keep their services online in the face of relentless data-scraping firms hiding behind residential proxy services. A survey conducted last year by the Confederation of Open Access Repositories (COAR) found while some content scraping bots are rather innocuous, “others are sufficiently aggressive that they are increasingly causing service disruptions in repositories and other scholarly communications infrastructures.” More than 90 percent of survey respondents indicated their repository is encountering aggressive bots, usually more than once a week, and often leading to slow downs and service outages. “Automated web scraping is nothing new, and has been the key technology underlying search engines such as Google for over 30 years,” wrote Brendan O’Connell , platform manager at the Directory of Open Access Journals (DOAJ), a free, community-curated index of peer-reviewed academic journals. “However, the current investor-fueled AI startup craze means there are now thousands of well-funded companies developing and deploying their own scraping tools to train AI models, alongside existing major players like OpenAI and Google.” Across the United States, local communities are pushing back against the proliferation of new data centers aimed primarily at improving the capabilities of AI. But security experts say the general public remains largely unaware that using one of these unsanctioned Android TV boxes means their “smart TV” is almost certainly using a significant amount of bandwidth each month to help train modern AI models. Even households without these sketchy TV boxes can still have their smart TVs turned into residential proxy nodes, just by downloading one of thousands of apps made available on Samsung and LG smart TVs. Spur said it recently scraped the LG and Samsung app stores and found that each had approximately 3,000 apps available for download. Many of these apps are simple games or utilities that state in the fine print that the user’s Internet connection will be used to download data and that they can opt out at any time. Spur said it found that  more than 42 percent of apps available for download via the webOS operating system on LG smart TVs include SDKs that turn one’s television into an always-on residential proxy node. More than a quarter of the apps made for Samsung’s Tizen operating system had similar residential proxy components, Spur found. Image: Spur.us. Experts say it’s questionable whether TV apps with proxy SDKs can obtain meaningful consent from users for installing an always-on proxy connection, particularly when anyone in a household — including children — can effectively opt the family TV into a residential proxy network just by installing a simple game or app. “Privacy-policy disclosure is the wrong control surface for a TV,” Include Security wrote. “It is hard to scroll through a legal document navigated by arrow keys on a remote, and the in-app consent dialog doesn’t convey that a paying customer is about to route their scraping traffic through the user’s home internet.” Spur’s head of research Sean Simmons told KrebsOnSecurity that most people do not have a working mental model for what it means to sell access to their residential IP address, no matter what device they are using. “And on a TV, the gap is even wider,” Simmons said. “A one-time prompt navigated with a remote can disappear into the setup flow, while the app keeps monetizing the connection long after anyone remembers what they accepted.” Simmons said LG and Samsung should follow the lead of other TV platforms that have already drawn a line against residential proxy providers, pointing to policies by Amazon that prohibit apps facilitating proxy services for third parties. Likewise the TV streaming device maker Roku reportedly now bars developers from using proxy SDKs and has removed apps that bundled them. Piracy related apps pushing proxy SDKs onto unconsenting users. Image: Synthient. Apps that turn one’s device into a residential proxy node are not limited to smart TVs and no-name streaming boxes, of course. As noted by the security firm Infoblox , mobile app developers can embed SDKs provided by the residential proxy networks into their products to monetize their software, allowing them to receive a small amount of money on each installation. The result, Infoblox said, is that devices are frequently enrolled without the owner’s knowledge, typically through free applications such as VPNs, streaming apps, screensavers and “productivity” apps such as PDF viewers and break reminders. All too often, these proxy services are beaconing out from employee devices brought into the workplace, Infoblox found. In a blog post earlier this month, Infoblox said it discovered that fully 65% of its customer base was querying one or more residential proxy related domains. “We saw steady growth in these queries in 2025, with a 25% increase over the year to over 500 billion per month,” Infoblox wrote . “Over 90% of our pharmaceutical and food & beverage customers have queried residential proxy indicators. Perhaps even more concerning is that over 60% of government and banking customers have as well.” Infoblox researchers Nick Sundvall and David Brunsdon warned that with residential proxies in the corporate environment, external access is granted to an organization’s IP space. “If threat actors were to abuse the residential proxy to attack a third party, the third party’s incident response would, correctly, identify your residential proxy as the source,” they wrote. “Untangling that, by proving that you were the conduit and not the threat actor, costs time, creates legal exposure, and can damage your reputation. The stunning prevalence of these services within customer environments warrants attention from both network defenders and policy makers who should consider how the risks posed by residential proxies could be impacting their security posture.”

0 views
neilzone 1 months ago

Why are there no good tablets at the moment?

A friend was looking for a new tablet, and they asked me for a recommendation. And… I just don’t have one. The only good tablet, because Android can be replaced with GrapheneOS , was the Google Pixel Tablet, and that is no longer available. Secondhand prices are sky high. That was my go-to recommendation for a while. But it looks like Google has abandoned this project too. Amazon’s range of FireOS tablets are, IMHO, bloated with crapware which one cannot easily remove. Even the Fire-Tools scripts only get one so far. I can’t recommend one. There are some fun-looking “tablet computers”, but they are all expensive. A secondhand Surface Go, if one wants a Linux-based tablet, is readily available and pretty cheap, but honestly not what most people will want. And, while I like it as a cheap, touchscreen, Linux machine, it is not particularly powerful, which can be frustrating. And getting the camera working is a nuisance. I guess that there are some iPads, if one is accepting of Apple / iOS. Again, that wouldn’t be my choice, but I can see why some people like them. Why is there no good (non-Apple) tablet at the moment?

0 views
マリウス 2 months ago

Privacy Setup for Android 16 with GrapheneOS

GrapheneOS is a free and open-source mobile operating system, built on top of the Android Open Source Project (AOSP) but with a strong focus on privacy and security. It’s developed independently, with no ties to Google or any hardware vendor, and it’s the operating system I’ve been recommending (and using on my own devices) for years, both on the phone side and on the tablet side . Compared to the Android you get out of the box on a new Samsung Galaxy , nothing phone or even Google Pixel , GrapheneOS is a fundamentally different thing. Where stock Android ships deeply integrated with Google ’s services, that constantly sync contacts, calendars, search history, advertising identifiers, approximate location, and trickle telemetry back to Mountain View , GrapheneOS strips all of that out by default. Where vendor Android additionally ships with preloaded apps from Facebook , Microsoft , Amazon and the manufacturer’s own ecosystem, each with their own telemetry pipeline, GrapheneOS ships with almost nothing at all. And where stock Android relies on Google for things like push notifications, attestation, captive portal checks and time synchronization, GrapheneOS routes these through its own infrastructure, or makes them optional entirely. On top of that, GrapheneOS adds a substantial amount of hardening at every layer of the stack, from a hardened memory allocator and stricter sandboxing rules, all the way up to user-facing tools like per-app network and sensor permission toggles that simply don’t exist on stock Android. In short, GrapheneOS is what Android could look like if the people building it weren’t in the business of selling your data. And because it’s open source, independently audited and developed with a clear threat model in mind, it has earned the trust of journalists, activists, engineers and plenty of ordinary people who simply don’t want their phone to be a surveillance device. With all that said, there’s a common misconception that I keep encountering, that simply flashing GrapheneOS onto a compatible device is enough to magically protect its owner from Big Tech or other adversaries spying on them and their data. While GrapheneOS goes to great lengths to disable and circumvent the tracking that smartphone vendors like Google usually build into their Android phones, and hardens various aspects of the system on top of that, the main cause for concern is usually less the bare naked Android system, but more often than not the apps running on top of it. If you are using apps like Facebook , TikTok , Outlook and Amazon , the surveillance happens within these apps and platforms, regardless of what operating system they’re running on. Common questions from others that I’m encountering with regard to the use of GrapheneOS are along the lines of “I need to use this banking app on my phone, can I do that with GrapheneOS?” , or “I need to use Microsoft Teams for work, does GrapheneOS support it?” . While many of these questions can be answered with yes , there’s a fundamental issue with this approach, in which people think that if only they switch the base operating system of their smartphone, all of the sudden they will become invisible to the companies behind these apps. This is sadly a misconception. The operating system is, albeit an important part, only one layer of the stack. Flashing GrapheneOS protects you from a lot of what Google bakes into stock Android, and it adds a surprising amount of defense in depth via things like the hardened memory allocator , the network permission toggle or storage scopes . What it cannot do, however, is change what the apps you install are sending to their backends. If you depend heavily on using apps that are inherently privacy-invasive, it doesn’t make much sense to limit yourself to the few devices that an operating system like GrapheneOS is able to run on, and then go through all the hoops of getting the apps that you need to work on those devices. In such a case, compartmentalization is the better approach: Run these type of apps on e.g. a modern iOS device, which is a platform with industry leading out-of-the-box security for the average user, and only use a GrapheneOS device for the apps and platforms that you have full control over or can reasonably trust to not spy on you. This is in my opinion the most important mental model to internalize before starting down this path. The goal isn’t “one device that does it all, perfectly private” , as that device doesn’t exist and chasing it will only give you a false sense of privacy. The goal is to make sure that the device which lives in your pocket, the one that knows where you drive, where you sleep and who you talk to, is running a minimal, trustworthy and hardened stack. Everything that brings known spyware into the mix, like corporate communication suites, banking apps, rideshare apps, airline loyalty clients, food delivery apps, all the usual suspects, belongs on a separate, deliberately untrusted device. That device can happily be a stock iPhone or a stock Pixel. Don’t fight that reality, use it in the most minimal way possible. That device does not need a copy of your full address book and calendar, nor does it needs access to your primary password vault. And it most certainly doesn’t need your family vacation photos or your Taylor Swift concert videos. It can co-exist just fine on a dedicated SIM card, with a dedicated phone number and everything else that the corporate you needs. Using the spyware device in such a conscious way ultimately benefits your privacy alter-ego , as it maintains a public persona of yourself that hAs NoThInG tO hIdE . Many people recoil at the idea of carrying two phones, but in practice the spyware device rarely needs to leave your desk or (Faraday-)bag. You pull it out when you need to check in for a flight, pay a bill, submit an expense report or hop on a corporate video call. For everything else, the GrapheneOS device is more than sufficient. And because it doesn’t carry the weight of two dozen chatty apps, its battery life and overall responsiveness will improve dramatically as a side effect. However, because life is never as clear cut as this, with Android 16 there is a new Private Space feature that can be utilized to further compartmentalize apps within the same device. Private Space is essentially a separate user, nested inside of the owner user, with its own isolated storage, its own set of installed apps and its own work/background state. The apps inside a Private Space don’t share any common data with the rest of your apps and they don’t even necessarily share the same network routes. Therefor, if you are using a VPN on your main profile, your Private Space apps won’t see this and hence won’t be using the connection, and vice-versa. That last bit is worth pausing on. You can have a completely different VPN configuration, a completely different set of DNS settings and, effectively, a completely different exit IP for the apps inside your Private Space , without having to juggle user profiles via the lockscreen. When the space is locked , the apps inside it are frozen, their processes are torn down, their notifications are silenced and their icons disappear from the app drawer and the recents view. When the space is unlocked , it’s as if you briefly teleported to a second phone, used the app you needed, and then went back. Examples of apps which would make sense to run inside the Private Space would be for example the Uber app. This app contains your private information (name, payment info) and is something you don’t want to be running in the background 24/7, as you quite likely only need it sporadically, whenever you have to hail a ride. By installing Uber only inside the Private Space , it will only be allowed to run once you unlock the space. You don’t need to worry about Uber continuing to track your location after you completed your ride ever again. A similar argument can be made for a messenger like WhatsApp . I would not recommend relying on WhatsApp as your primary means of communication, but if you have that one group chat with family members that absolutely refuses to move off WhatsApp , or that one client who insists on sending you voice notes there, installing it inside the Private Space and only unlocking it when you actually need to check in is a reasonable middle ground. You get the communication channel, Meta doesn’t get a background service on your primary profile 24/7. However, this approach clearly only makes sense for apps that you only need to use sporadically or in emergency situations in which you might not have your dedicated spyware device with you. If you need to use something like Microsoft Teams on a constant basis, putting it into the confined Private Space might not make much sense as, unless the space is unlocked, the app won’t deliver message notifications. The official AOSP documentation even carries a warning that Private Space is not suitable for apps that need to run in the background or send critical notifications, such as medical apps. Treat it as the right tool for “occasional use” , not as a replacement for proper profile hygiene. People new to GrapheneOS often ask how Private Space differs from the traditional secondary user profiles that GrapheneOS has supported for years. The short answer is that Private Space is strictly more convenient, and secondary profiles are strictly more isolated. Secondary user profiles have their own encryption keys, derived from their own unlock credential. When you switch out of a profile or, even better, explicitly end the session of the profile, its data goes back to rest on disk and no longer resides in memory in a decrypted state. Private Space , on the other hand, lives inside the owner profile and piggybacks on its encryption context. When the owner profile is unlocked, the mere existence of data inside the Private Space can be inferred, even if the contents themselves remain protected. For most threat models this difference is purely academic, but it’s worth being aware of. In practice, my recommendation, and the one GrapheneOS itself tends to partially make , is roughly as follows: If you’re coming from a setup that relied solely on secondary profiles, you’ll notice that Private Space eliminates the lockscreen dance for the casual apps, while leaving the cryptographic isolation of secondary profiles available for the things that truly warrant it. The GrapheneOS installation itself is a breeze and, in my experience, the easiest way to put a non-stock operating system onto a smartphone. No , no , no fiddling with recovery images or sideloading obscure ZIPs. You unlock the bootloader, connect the phone to a computer and open GrapheneOS’ WebUSB installer in a compatible browser. From there, the installer walks you through the individual steps. The whole process takes around fifteen minutes and results in a factory-fresh GrapheneOS device. Make sure your device is in the list of officially supported models . Up until nowUp until now GrapheneOS specifically targets Google Pixel phones because Pixels offer verified boot with user-controllable root-of-trust, proper firmware and driver updates, the Titan M2 security chip and a bunch of other hardware-level properties that other Android vendors simply don’t match. This, however, is supposed to change with compatible devices from Motorola hitting the market in 2027. Running a “privacy ROM” on an unsupported device is in many ways worse than running stock Android, since you lose verified boot and in some cases even timely security patches. Once the device boots into GrapheneOS for the first time, resist the urge to immediately install all the apps you’re used to. Walk through the setup wizard, set a strong PIN or passphrase (six digits minimum!) and then, before doing anything else, spend fifteen minutes in the settings. This is the part most guides gloss over. GrapheneOS ships with sensible defaults, but a handful of additional tweaks can noticeably harden the device against both remote and physical threats. GrapheneOS adds a network permission toggle that appears on the install dialog of every new app and as a toggle in the app’s permissions screen. Habitually uncheck network access for any app that has no business talking to the internet. A gallery viewer, a calculator, a local file manager, a launcher, none of these should need network access. It’s a tiny friction with a disproportionately large effect on the amount of telemetry and personal data leaving your device. The sensors permission toggle covers everything the regular Android permissions don’t: Accelerometer, gyroscope, compass, barometer, and so on. You can block these on a per-app basis, which is particularly valuable for apps that have no legitimate reason to know how often you pick up your phone. GrapheneOS also exposes quick-toggle tiles for the camera and microphone in the pull-down menu, which cut access at the system level rather than the per-app level and are convenient for walking into a sensitive meeting or leaving the phone on the nightstand. Under Settings ➔ Network & internet ➔ Private DNS you can point the system resolver at a DNS-over-TLS provider of your choice. Quad9 , Mullvad DNS and NextDNS are all reasonable options. Cloudflare is (sadly) GrapheneOS’ default fallback. If you run your own recursive resolver, which I’d argue is the gold standard, even better. Keep in mind that the Private DNS hostname is looked up once via plaintext, so use a provider you’re okay briefly touching in the clear. With the base system locked down, it’s time to think about what actually goes on it. My general recommendation is to solely use F-Droid for free-software apps. Yes, F-Droid has its well-documented issues as is far from perfect, but for technically literate users who can read source code it remains the best option available in terms of provenance and privacy. For a browser, Vanadium is the default and the safest pick from a pure security standpoint, as it’s a hardened Chromium fork maintained by the GrapheneOS team, with strict site isolation, JIT disabled by default and a per-site JavaScript toggle. The main tradeoff is the lack of proper extension support, which rules out more sophisticated blocking support. If that’s a dealbreaker, install Cromite alongside Vanadium and reserve it for sites where you really need content blocking, while keeping Vanadium as your default for general browsing and anything sensitive. Also make sure to disable JavaScript by default and only enable it for sites that you know and trust! Once the setup is done, the real work is maintaining the discipline. A few habits that have served me well over the years: GrapheneOS on a recent Pixel remains, in my opinion, the closest thing to a genuinely private and secure mobile device that a non-state-actor can own today, despite Google ’s hardware being absolute garbage from quality control and performance perspectives. What GrapheneOS is not , however, is a magic spell that undoes the surveillance business models of the companies whose apps we’ve allowed into our lives. If you take one thing away from this post, let it be the compartmentalization mindset. Use a dedicated stock iOS or Android device for the stuff that absolutely demands surveillance-laden apps like banking portals that only ship as an app, corporate messaging suites, airline loyalty programs, food delivery, and rideshare. Use your GrapheneOS device for everything else, and save the Private Space on that GrapheneOS device for the in-between category, the apps you genuinely only need once in a while, like Uber while traveling, or a messenger like WhatsApp that a handful of people in your life refuse to leave behind. Reserve secondary user profiles for the hard cases that require Google services but that you don’t want bleeding into your daily profile. For new GrapheneOS users, the temptation will be to replicate your old app collection one-to-one. Don’t. Treat the move as an opportunity to audit what you actually need, and keep the owner profile as boring and empty as possible. For experienced users, the addition of Private Space in Android 16 is, I think, the single biggest quality-of-life improvement in years. It lets you retire a bunch of those one-off secondary profiles you created for “that one app” , without giving up meaningful isolation. Revisit your profile layout, consolidate where it makes sense, and lock the rest away behind a space that is off until you explicitly ask for it. None of this replaces thinking about your own threat model, your own habits and the people you communicate with. But on top of a thoughtful threat model, GrapheneOS with Android 16 is sadly about as good as it gets. Footnote: The cover image is a parody ( “meme” ) made from a screen capture of Google ’s Made by Google event with Jimmy Fallon . The host sadly did not publicly endorse GrapheneOS the same way he e.g. endorsed the highly questionable Bored Ape NFT . Owner profile: Lean, minimal, no Google services. F-Droid, trustworthy apps, a solid browser like Vanadium or Cromite . Secondary user profile for sandboxed Google Play : Install sandboxed Google Play here, along with the handful of apps that genuinely require Play Services, like certain banking apps. Keep this profile as small as possible, enable notifications so you don’t miss a transfer confirmation, and end the session whenever you’re done. Private Space inside the owner profile: The occasional use bucket. Uber, Lyft, food delivery, maybe WhatsApp for that one stubborn contact, loyalty apps that you open once a quarter. Lock it when you don’t need it. Auto-reboot: Settings ➔ Security & privacy ➔ Auto reboot . By default GrapheneOS reboots the device after 18 hours of being locked, putting all data back at rest and rendering cold-boot and many forensic attacks significantly harder. I personally lower this to eight or twelve hours. Duress PIN: Settings ➔ Security & privacy ➔ Device unlock ➔ Duress Password . This lets you configure an alternate PIN or password that, when entered on the lockscreen, irreversibly wipes the device in the background without any warning or confirmation. Useful if you’re ever in a situation where you’re compelled to hand over the device unlocked. Lockdown: The standard Android lockdown action (long-press the power button ➔ Lockdown ) disables biometrics and notification previews until the next successful PIN/passphrase entry. Make this a reflex whenever you hand the phone to someone or walk into a situation where you might be compelled to unlock it with your face or fingerprint. PIN scrambling and two-factor fingerprint unlock: Both are available in the lockscreen settings. The former randomizes the keypad layout to defeat shoulder-surfing, the latter requires a PIN after the fingerprint as a second factor. USB-C port control: Settings ➔ Security & privacy ➔ More security & privacy ➔ USB-C port . Set this to Charging-only when locked , or even Charging-only at all times if you rarely use the port for data. This prevents a plugged-in cable from establishing a data connection without your explicit consent. Resist re-installing apps you just removed. The whole point of going through this exercise is to shrink your attack surface. If you find yourself missing Instagram after two weeks, it’s worth asking whether you actually miss Instagram or whether you miss the dopamine loop. Review permissions periodically. Keep the spyware device actually separate. No shared WhatsApp account, no shared password manager vault. Treat it as a different person’s phone. Hit lockdown before boarding a plane or crossing a border. Biometrics offer essentially no legal protection in most jurisdictions. Lockdown forces the next unlock to require a passphrase and if things go sideways there’s the duress PIN. Reboot the device before sleep. Before First Unlock is a meaningfully different security state from After First Unlock . A fresh reboot means the keys haven’t been touched since the last time you intentionally typed your passphrase.

0 views
Circus Scientist 5 months ago

Connect SmartPoi to Android Hotspot

Connect your SmartPoi to Android Phone Hotspot instead of using Access Point on your Main Poi. In Router Mode, Poi always swap between AP and STA mode. This is to make sure that you can always connect even if you lose your phone or router. I wrote another blog post about this (before I had a Samsung Phone) which shows different ways to do the hotspot connection. Your phone might not have the same settings, the main thing is to find the IP addresses of the Poi while connected to the Hotspot. The post Connect SmartPoi to Android Hotspot appeared first on Circus Scientist . Main Poi is doing twice as much work (routing for Auxillary Poi) ESP8266/ESP32 have very low power – so we lose signal easily. Also, routing is faster with a Router or Hotspot. That means faster uploads , SmartPoi_Controls works better. Also UDP should work better (it’s not perfect, though). SmartPoi Access Point has no internet – so your phone has none while connected to it. Some advanced features of new Magic Poi will require internet (like instant download of saved Timelines, Sync). Input Hotspot information into Router Settings box in SmartPoi_Controls app (while connected to SmartPoi AP). This should work for both Main and Auxillary Poi at the same time Start Hotspot on phone, re-start poi and check if they connect (Green LED’s). Look in the hotspot menu for information – should show IP addresses of Poi. Put these into SmartPoi_Controls app. Test connection

0 views
Kev Quirk 6 months ago

I've Pre-Ordered the Clicks Communicator

I've yearned for a Blackberry form-factor for years, and now Clicks have made that wish come true. I had to pre-order one! If you don’t know what the Clicks Communicator is, this 12 minute video should help: BlackBerry’s design will always have a special place in my heart. I much prefer a physical keyboard over a touchscreen, and I’ve said many times that smartphones are far too big these days. The Clicks Communicator is smaller and it has a proper QWERTY keyboard. It is all very BlackBerry, and I love that. The team have also teamed up with the Niagara Launcher developer to deliver a more focused UI. That was yet more good news for me, as I already use Niagara Launcher on my Pixel 9a. It felt like a match made in heaven, so I pre-ordered one immediately. In all honesty, I do not understand why Clicks are marketing the Communicator as a companion device. I assume they are positioning it as a slimmed down alternative for people who still want a flagship phone, but that framing feels odd. It will be running full fat Android 16, and their FAQ confirms (in the very first question, no less) that the Communicator can be used as a primary device. That is exactly how I intend to use it. The companion device messaging is confusing. At first, I assumed it was something closer to the Light Phone , but it is not that at all. It’s a normal phone. I am not a marketer, so perhaps there is a strategy here that I am missing, I just hope it does not hurt their sales. Either way, I am genuinely looking forward to receiving my Clicks Communicator later this year. I will, of course, write about it once it arrives. Has this cool new phone piqued anyone else’s interest? Thanks for reading this post via RSS. RSS is great, and you're great for using it. ❤️ You can reply to this post by email , or leave a comment .

0 views
Krebs on Security 6 months ago

The Kimwolf Botnet is Stalking Your Local Network

The story you are reading is a series of scoops nestled inside a far more urgent Internet-wide security advisory. The vulnerability at issue has been exploited for months already, and it’s time for a broader awareness of the threat. The short version is that everything you thought you knew about the security of the internal network behind your Internet router probably is now dangerously out of date. The security company Synthient currently sees more than 2 million infected Kimwolf devices distributed globally but with concentrations in Vietnam, Brazil, India, Saudi Arabia, Russia and the United States. Synthient found that two-thirds of the Kimwolf infections are Android TV boxes with no security or authentication built in. The past few months have witnessed the explosive growth of a new botnet dubbed Kimwolf , which experts say has infected more than 2 million devices globally. The Kimwolf malware forces compromised systems to relay malicious and abusive Internet traffic — such as ad fraud, account takeover attempts and mass content scraping — and participate in crippling distributed denial-of-service (DDoS) attacks capable of knocking nearly any website offline for days at a time. More important than Kimwolf’s staggering size, however, is the diabolical method it uses to spread so quickly: By effectively tunneling back through various “ residential proxy ” networks and into the local networks of the proxy endpoints, and by further infecting devices that are hidden behind the assumed protection of the user’s firewall and Internet router. Residential proxy networks are sold as a way for customers to anonymize and localize their Web traffic to a specific region, and the biggest of these services allow customers to route their traffic through devices in virtually any country or city around the globe. The malware that turns an end-user’s Internet connection into a proxy node is often bundled with dodgy mobile apps and games. These residential proxy programs also are commonly installed via unofficial Android TV boxes  sold by third-party merchants on popular e-commerce sites like Amazon , BestBuy, Newegg , and Walmart . These TV boxes range in price from $40 to $400, are marketed under a dizzying range of no-name brands and model numbers , and frequently are advertised as a way to stream certain types of subscription video content for free . But there’s a hidden cost to this transaction: As we’ll explore in a moment, these TV boxes make up a considerable chunk of the estimated two million systems currently infected with Kimwolf. Some of the unsanctioned Android TV boxes that come with residential proxy malware pre-installed. Image: Synthient. Kimwolf also is quite good at infecting a range of Internet-connected digital photo frames that likewise are abundant at major e-commerce websites. In November 2025, researchers from Quokka published a report (PDF) detailing serious security issues in Android-based digital picture frames running the Uhale app — including Amazon’s bestselling digital frame as of March 2025. There are two major security problems with these photo frames and unofficial Android TV boxes. The first is that a considerable percentage of them come with malware pre-installed, or else require the user to download an unofficial Android App Store and malware in order to use the device for its stated purpose (video content piracy). The most typical of these uninvited guests are small programs that turn the device into a residential proxy node that is resold to others. The second big security nightmare with these photo frames and unsanctioned Android TV boxes is that they rely on a handful of Internet-connected microcomputer boards that have no discernible security or authentication requirements built-in. In other words, if you are on the same network as one or more of these devices, you can likely compromise them simultaneously by issuing a single command across the network. The combination of these two security realities came to the fore in October 2025, when an undergraduate computer science student at the Rochester Institute of Technology began closely tracking Kimwolf’s growth, and interacting directly with its apparent creators on a daily basis. Benjamin Brundage is the 22-year-old founder of the security firm Synthient , a startup that helps companies detect proxy networks and learn how those networks are being abused. Conducting much of his research into Kimwolf while studying for final exams, Brundage told KrebsOnSecurity in late October 2025 he suspected Kimwolf was a new Android-based variant of Aisuru , a botnet that was incorrectly blamed for a number of record-smashing DDoS attacks last fall. Brundage says Kimwolf grew rapidly by abusing a glaring vulnerability in many of the world’s largest residential proxy services. The crux of the weakness, he explained, was that these proxy services weren’t doing enough to prevent their customers from forwarding requests to internal servers of the individual proxy endpoints. Most proxy services take basic steps to prevent their paying customers from “going upstream” into the local network of proxy endpoints, by explicitly denying requests for local addresses specified in RFC-1918 , including the well-known Network Address Translation (NAT) ranges 10.0.0.0/8, 192.168.0.0/16, and 172.16.0.0/12. These ranges allow multiple devices in a private network to access the Internet using a single public IP address, and if you run any kind of home or office network, your internal address space operates within one or more of these NAT ranges. However, Brundage discovered that the people operating Kimwolf had figured out how to talk directly to devices on the internal networks of millions of residential proxy endpoints, simply by changing their Domain Name System (DNS) settings to match those in the RFC-1918 address ranges. “It is possible to circumvent existing domain restrictions by using DNS records that point to 192.168.0.1 or 0.0.0.0,” Brundage wrote in a first-of-its-kind security advisory sent to nearly a dozen residential proxy providers in mid-December 2025. “This grants an attacker the ability to send carefully crafted requests to the current device or a device on the local network. This is actively being exploited, with attackers leveraging this functionality to drop malware.” As with the digital photo frames mentioned above, many of these residential proxy services run solely on mobile devices that are running some game, VPN or other app with a hidden component that turns the user’s mobile phone into a residential proxy — often without any meaningful consent. In a report published today , Synthient said key actors involved in Kimwolf were observed monetizing the botnet through app installs, selling residential proxy bandwidth, and selling its DDoS functionality. “Synthient expects to observe a growing interest among threat actors in gaining unrestricted access to proxy networks to infect devices, obtain network access, or access sensitive information,” the report observed. “Kimwolf highlights the risks posed by unsecured proxy networks and their viability as an attack vector.” After purchasing a number of unofficial Android TV box models that were most heavily represented in the Kimwolf botnet, Brundage further discovered the proxy service vulnerability was only part of the reason for Kimwolf’s rapid rise: He also found virtually all of the devices he tested were shipped from the factory with a powerful feature called Android Debug Bridge (ADB) mode enabled by default. Many of the unofficial Android TV boxes infected by Kimwolf include the ominous disclaimer: “Made in China. Overseas use only.” Image: Synthient. ADB is a diagnostic tool intended for use solely during the manufacturing and testing processes, because it allows the devices to be remotely configured and even updated with new (and potentially malicious) firmware. However, shipping these devices with ADB turned on creates a security nightmare because in this state they constantly listen for and accept unauthenticated connection requests. For example, opening a command prompt and typing “adb connect” along with a vulnerable device’s (local) IP address followed immediately by “:5555” will very quickly offer unrestricted “super user” administrative access. Brundage said by early December, he’d identified a one-to-one overlap between new Kimwolf infections and proxy IP addresses offered for rent by China-based IPIDEA , currently the world’s largest residential proxy network by all accounts. “Kimwolf has almost doubled in size this past week, just by exploiting IPIDEA’s proxy pool,” Brundage told KrebsOnSecurity in early December as he was preparing to notify IPIDEA and 10 other proxy providers about his research. Brundage said Synthient first confirmed on December 1, 2025 that the Kimwolf botnet operators were tunneling back through IPIDEA’s proxy network and into the local networks of systems running IPIDEA’s proxy software. The attackers dropped the malware payload by directing infected systems to visit a specific Internet address and to call out the pass phrase “ krebsfiveheadindustries ” in order to unlock the malicious download. On December 30, Synthient said it was tracking roughly 2 million IPIDEA addresses exploited by Kimwolf in the previous week. Brundage said he has witnessed Kimwolf rebuilding itself after one recent takedown effort targeting its control servers — from almost nothing to two million infected systems just by tunneling through proxy endpoints on IPIDEA for a couple of days. Brundage said IPIDEA has a seemingly inexhaustible supply of new proxies, advertising access to more than 100 million residential proxy endpoints around the globe in the past week alone . Analyzing the exposed devices that were part of IPIDEA’s proxy pool, Synthient said it found more than two-thirds were Android devices that could be compromised with no authentication needed . After charting a tight overlap in Kimwolf-infected IP addresses and those sold by IPIDEA, Brundage was eager to make his findings public: The vulnerability had clearly been exploited for several months, although it appeared that only a handful of cybercrime actors were aware of the capability. But he also knew that going public without giving vulnerable proxy providers an opportunity to understand and patch it would only lead to more mass abuse of these services by additional cybercriminal groups. On December 17, Brundage sent a security notification to all 11 of the apparently affected proxy providers, hoping to give each at least a few weeks to acknowledge and address the core problems identified in his report before he went public. Many proxy providers who received the notification were resellers of IPIDEA that white-labeled the company’s service. KrebsOnSecurity first sought comment from IPIDEA in October 2025, in reporting on a story about how the proxy network appeared to have benefitted from the rise of the Aisuru botnet , whose administrators appeared to shift from using the botnet primarily for DDoS attacks to simply installing IPIDEA’s proxy program, among others. On December 25, KrebsOnSecurity received an email from an IPIDEA employee identified only as “ Oliver ,” who said allegations that IPIDEA had benefitted from Aisuru’s rise were baseless. “After comprehensively verifying IP traceability records and supplier cooperation agreements, we found no association between any of our IP resources and the Aisuru botnet, nor have we received any notifications from authoritative institutions regarding our IPs being involved in malicious activities,” Oliver wrote. “In addition, for external cooperation, we implement a three-level review mechanism for suppliers, covering qualification verification, resource legality authentication and continuous dynamic monitoring, to ensure no compliance risks throughout the entire cooperation process.” “IPIDEA firmly opposes all forms of unfair competition and malicious smearing in the industry, always participates in market competition with compliant operation and honest cooperation, and also calls on the entire industry to jointly abandon irregular and unethical behaviors and build a clean and fair market ecosystem,” Oliver continued. Meanwhile, the same day that Oliver’s email arrived, Brundage shared a response he’d just received from IPIDEA’s security officer, who identified himself only by the first name Byron . The security officer said IPIDEA had made a number of important security changes to its residential proxy service to address the vulnerability identified in Brundage’s report. “By design, the proxy service does not allow access to any internal or local address space,” Byron explained. “This issue was traced to a legacy module used solely for testing and debugging purposes, which did not fully inherit the internal network access restrictions. Under specific conditions, this module could be abused to reach internal resources. The affected paths have now been fully blocked and the module has been taken offline.” Byron told Brundage IPIDEA also instituted multiple mitigations for blocking DNS resolution to internal (NAT) IP ranges, and that it was now blocking proxy endpoints from forwarding traffic on “high-risk” ports “to prevent abuse of the service for scanning, lateral movement, or access to internal services.” An excerpt from an email sent by IPIDEA’s security officer in response to Brundage’s vulnerability notification. Click to enlarge. Brundage said IPIDEA appears to have successfully patched the vulnerabilities he identified. He also noted he never observed the Kimwolf actors targeting proxy services other than IPIDEA, which has not responded to requests for comment. Riley Kilmer is founder of Spur.us , a technology firm that helps companies identify and filter out proxy traffic. Kilmer said Spur has tested Brundage’s findings and confirmed that IPIDEA and all of its affiliate resellers indeed allowed full and unfiltered access to the local LAN. Kilmer said one model of unsanctioned Android TV boxes that is especially popular — the Superbox, which we profiled in November’s Is Your Android TV Streaming Box Part of a Botnet? — leaves Android Debug Mode running on localhost:5555. “And since Superbox turns the IP into an IPIDEA proxy, a bad actor just has to use the proxy to localhost on that port and install whatever bad SDKs [software development kits] they want,” Kilmer told KrebsOnSecurity. Superbox media streaming boxes for sale on Walmart.com. Both Brundage and Kilmer say IPIDEA appears to be the second or third reincarnation of a residential proxy network formerly known as 911S5 Proxy , a service that operated between 2014 and 2022 and was wildly popular on cybercrime forums. 911S5 Proxy imploded a week after KrebsOnSecurity published a deep dive on the service’s sketchy origins and leadership in China. In that 2022 profile, we cited work by researchers at the University of Sherbrooke in Canada who were studying the threat 911S5 could pose to internal corporate networks. The researchers noted that “the infection of a node enables the 911S5 user to access shared resources on the network such as local intranet portals or other services.” “It also enables the end user to probe the LAN network of the infected node,” the researchers explained . “Using the internal router, it would be possible to poison the DNS cache of the LAN router of the infected node, enabling further attacks.” 911S5 initially responded to our reporting in 2022 by claiming it was conducting a top-down security review of the service. But the proxy service abruptly closed up shop just one week later, saying a malicious hacker had destroyed all of the company’s customer and payment records. In July 2024, The U.S. Department of the Treasury sanctioned the alleged creators of 911S5 , and the U.S. Department of Justice arrested the Chinese national named in my 2022 profile of the proxy service. Kilmer said IPIDEA also operates a sister service called 922 Proxy , which the company has pitched from Day One as a seamless alternative to 911S5 Proxy. “You cannot tell me they don’t want the 911 customers by calling it that,” Kilmer said. Among the recipients of Synthient’s notification was the proxy giant Oxylabs . Brundage shared an email he received from Oxylabs’ security team on December 31, which acknowledged Oxylabs had started rolling out security modifications to address the vulnerabilities described in Synthient’s report. Reached for comment, Oxylabs confirmed they “have implemented changes that now eliminate the ability to bypass the blocklist and forward requests to private network addresses using a controlled domain.” But it said there is no evidence that Kimwolf or other other attackers exploited its network. “In parallel, we reviewed the domains identified in the reported exploitation activity and did not observe traffic associated with them,” the Oxylabs statement continued. “Based on this review, there is no indication that our residential network was impacted by these activities.” Consider the following scenario, in which the mere act of allowing someone to use your Wi-Fi network could lead to a Kimwolf botnet infection. In this example, a friend or family member comes to stay with you for a few days, and you grant them access to your Wi-Fi without knowing that their mobile phone is infected with an app that turns the device into a residential proxy node. At that point, your home’s public IP address will show up for rent at the website of some residential proxy provider. Miscreants like those behind Kimwolf then use residential proxy services online to access that proxy node on your IP, tunnel back through it and into your local area network (LAN), and automatically scan the internal network for devices with Android Debug Bridge mode turned on. By the time your guest has packed up their things, said their goodbyes and disconnected from your Wi-Fi, you now have two devices on your local network — a digital photo frame and an unsanctioned Android TV box — that are infected with Kimwolf. You may have never intended for these devices to be exposed to the larger Internet, and yet there you are. Here’s another possible nightmare scenario: Attackers use their access to proxy networks to modify your Internet router’s settings so that it relies on malicious DNS servers controlled by the attackers — allowing them to control where your Web browser goes when it requests a website. Think that’s far-fetched? Recall the DNSChanger malware from 2012 that infected more than a half-million routers with search-hijacking malware, and ultimately spawned an entire security industry working group focused on containing and eradicating it. Much of what is published so far on Kimwolf has come from the Chinese security firm XLab , which was the first to chronicle the rise of the Aisuru botnet in late 2024. In its latest blog post , XLab said it began tracking Kimwolf on October 24, when the botnet’s control servers were swamping Cloudflare’s DNS servers with lookups for the distinctive domain 14emeliaterracewestroxburyma02132[.]su. This domain and others connected to early Kimwolf variants spent several weeks topping Cloudflare’s chart of the Internet’s most sought-after domains , edging out Google.com and Apple.com of their rightful spots in the top 5 most-requested domains. That’s because during that time Kimwolf was asking its millions of bots to check in frequently using Cloudflare’s DNS servers. The Chinese security firm XLab found the Kimwolf botnet had enslaved between 1.8 and 2 million devices, with heavy concentrations in Brazil, India, The United States of America and Argentina. Image: blog.xLab.qianxin.com It is clear from reading the XLab report that KrebsOnSecurity (and security experts) probably erred in misattributing some of Kimwolf’s early activities to the Aisuru botnet, which appears to be operated by a different group entirely. IPDEA may have been truthful when it said it had no affiliation with the Aisuru botnet, but Brundage’s data left no doubt that its proxy service clearly was being massively abused by Aisuru’s Android variant, Kimwolf. XLab said Kimwolf has infected at least 1.8 million devices, and has shown it is able to rebuild itself quickly from scratch. “Analysis indicates that Kimwolf’s primary infection targets are TV boxes deployed in residential network environments,” XLab researchers wrote. “Since residential networks usually adopt dynamic IP allocation mechanisms, the public IPs of devices change over time, so the true scale of infected devices cannot be accurately measured solely by the quantity of IPs. In other words, the cumulative observation of 2.7 million IP addresses does not equate to 2.7 million infected devices.” XLab said measuring Kimwolf’s size also is difficult because infected devices are distributed across multiple global time zones. “Affected by time zone differences and usage habits (e.g., turning off devices at night, not using TV boxes during holidays, etc.), these devices are not online simultaneously, further increasing the difficulty of comprehensive observation through a single time window,” the blog post observed. XLab noted that the Kimwolf author shows an almost ‘obsessive’ fixation” on Yours Truly, apparently leaving “easter eggs” related to my name in multiple places through the botnet’s code and communications: Image: XLAB. One frustrating aspect of threats like Kimwolf is that in most cases it is not easy for the average user to determine if there are any devices on their internal network which may be vulnerable to threats like Kimwolf and/or already infected with residential proxy malware. Let’s assume that through years of security training or some dark magic you can successfully identify that residential proxy activity on your internal network was linked to a specific mobile device inside your house: From there, you’d still need to isolate and remove the app or unwanted component that is turning the device into a residential proxy. Also, the tooling and knowledge needed to achieve this kind of visibility just isn’t there from an average consumer standpoint. The work that it takes to configure your network so you can see and interpret logs of all traffic coming in and out is largely beyond the skillset of most Internet users (and, I’d wager, many security experts). But it’s a topic worth exploring in an upcoming story. Happily, Synthient has erected a page on its website that will state whether a visitor’s public Internet address was seen among those of Kimwolf-infected systems. Brundage also has compiled a list of the unofficial Android TV boxes that are most highly represented in the Kimwolf botnet. If you own a TV box that matches one of these model names and/or numbers, please just rip it out of your network. If you encounter one of these devices on the network of a family member or friend, send them a link to this story and explain that it’s not worth the potential hassle and harm created by keeping them plugged in. The top 15 product devices represented in the Kimwolf botnet, according to Synthient. Chad Seaman is a principal security researcher with Akamai Technologies . Seaman said he wants more consumers to be wary of these pseudo Android TV boxes to the point where they avoid them altogether. “I want the consumer to be paranoid of these crappy devices and of these residential proxy schemes,” he said. “We need to highlight why they’re dangerous to everyone and to the individual. The whole security model where people think their LAN (Local Internal Network) is safe, that there aren’t any bad guys on the LAN so it can’t be that dangerous is just really outdated now.” “The idea that an app can enable this type of abuse on my network and other networks, that should really give you pause,” about which devices to allow onto your local network, Seaman said. “And it’s not just Android devices here. Some of these proxy services have SDKs for Mac and Windows, and the iPhone. It could be running something that inadvertently cracks open your network and lets countless random people inside.” In July 2025, Google filed a “John Doe”  lawsuit (PDF) against 25 unidentified defendants collectively dubbed the “ BadBox 2.0 Enterprise ,” which Google described as a botnet of over ten million unsanctioned Android streaming devices engaged in advertising fraud. Google said the BADBOX 2.0 botnet, in addition to compromising multiple types of devices prior to purchase, also can infect devices by requiring the download of malicious apps from unofficial marketplaces. Google’s lawsuit came on the heels of a  June 2025 advisory  from the  Federal Bureau of Investigation (FBI), which warned that cyber criminals were gaining unauthorized access to home networks by either configuring the products with malware prior to the user’s purchase, or infecting the device as it downloads required applications that contain backdoors — usually during the set-up process. The FBI said BADBOX 2.0 was discovered after the original BADBOX campaign was disrupted in 2024. The original BADBOX was identified in 2023, and primarily consisted of Android operating system devices that were compromised with backdoor malware prior to purchase. Lindsay Kaye is vice president of threat intelligence at HUMAN Security , a company that worked closely on the BADBOX investigations. Kaye said the BADBOX botnets and the residential proxy networks that rode on top of compromised devices were detected because they enabled a ridiculous amount of advertising fraud, as well as ticket scalping, retail fraud, account takeovers and content scraping. Kaye said consumers should stick to known brands when it comes to purchasing things that require a wired or wireless connection. “If people are asking what they can do to avoid being victimized by proxies, it’s safest to stick with name brands,” Kaye said. “Anything promising something for free or low-cost, or giving you something for nothing just isn’t worth it. And be careful about what apps you allow on your phone.” Many wireless routers these days make it relatively easy to deploy a “Guest” wireless network on-the-fly. Doing so allows your guests to browse the Internet just fine but it blocks their device from being able to talk to other devices on the local network — such as shared folders, printers and drives. If someone — a friend, family member, or contractor — requests access to your network, give them the guest Wi-Fi network credentials if you have that option. There is a small but vocal pro-piracy camp that is almost condescendingly dismissive of the security threats posed by these unsanctioned Android TV boxes. These tech purists positively chafe at the idea of people wholesale discarding one of these TV boxes. A common refrain from this camp is that Internet-connected devices are not inherently bad or good, and that even factory-infected boxes can be flashed with new firmware or custom ROMs that contain no known dodgy software. However, it’s important to point out that the majority of people buying these devices are not security or hardware experts; the devices are sought out because they dangle something of value for “free.” Most buyers have no idea of the bargain they’re making when plugging one of these dodgy TV boxes into their network. It is somewhat remarkable that we haven’t yet seen the entertainment industry applying more visible pressure on the major e-commerce vendors to stop peddling this insecure and actively malicious hardware that is largely made and marketed for video piracy. These TV boxes are a public nuisance for bundling malicious software while having no apparent security or authentication built-in, and these two qualities make them an attractive nuisance for cybercriminals. Stay tuned for Part II in this series, which will poke through clues left behind by the people who appear to have built Kimwolf and benefited from it the most.

0 views
Kaushik Gopal 6 months ago

Wi-Fi sharing is a killer Android feature

Ubiquiti announced a new travel router . Much of the internet is excited. So am I. Then I tried to remember the last time I actually needed a travel router. You see, Android has supported a feature I’ll call Wi-Fi sharing for years. 1 Your phone connects to an existing Wi-Fi network and re-shares it as a hotspot. This might sound like a regular hotspot feature that most phones (including the iPhone) come with. But it’s not. iPhones can share mobile data. They can’t re-share a Wi-Fi connection as a hotspot. Wi-Fi sharing Your phone connects to Wi-Fi, and then re-shares that same Wi-Fi as a hotspot. This is different from typical hotspot functionality where the phone shares its mobile data connection (vs Wi-Fi). Neat trick, but why bother? Can’t you just connect each device to Wi-Fi? Captive portals are annoying when you’re carrying multiple devices. I typically travel with 3-4 devices that want internet. Signing each one in, every time, gets old fast. Some devices are worse: Chromecast and Fire TV sticks are particularly painful to get past captive portals. If everything connects to your hotspot, you only deal with the portal once. 2 On a plane, I sometimes want both my laptop and phone online. Some paid Wi-Fi plans only allow one device at a time. Unless you’re ok paying twice, Wi-Fi sharing is simpler. 3 Hotels and conference centers do the same: sign-in plus device limits. Wi-Fi sharing works around it. This one is less obvious, but common in hotels and conference Wi-Fi: your devices have internet, but they can’t see each other locally. Chromecast (or printers) won’t show up as a cast target because it doesn’t appear on the network. That’s usually client/AP isolation. 4 Put your devices on your phone’s hotspot, and local discovery usually works again. This is slightly advanced. With a Tailscale setup and an explicit exit node, you basically have a private VPN. 5 On phones where hotspot traffic routes through that VPN, you only have to set it up on your Android phone, and every device that connects to your phone gets the same “safe” path out. If I have to log in to bank accounts when roaming or connecting to “free” Wi-Fi, this helps me feel safer knowing the local network can’t see or tamper with the contents of my traffic. 6 I should pause my gloating over iPhones for a second: a few Android devices may not support this feature. The Android OS has Wi-Fi sharing baked in, but it still requires hardware + driver support. Notable exceptions include the Pixel 7a, the Pixel 8a, and yes the (first generation) Pixel Fold. Wi-Fi sharing requires Wi-Fi hardware (chipset + drivers) that can run as both a client and an access point at the same time (STA + AP). 7 Chipsets can implement this in a few ways (DBS, SBS, MCC, SCC). 8 Android doesn’t mandate one mode; it depends on the Wi-Fi chipset. DBS/SBS use multiple radios, so the phone can keep the upstream connection and hotspot truly simultaneous (for example, 5 GHz upstream and a 2.4 GHz hotspot). MCC/SCC share a radio, so the hotspot either stays on the same channel (SCC) or the radio hops channels (MCC). If a phone can’t do STA + AP concurrency well (or at all), OEMs disable Wi-Fi sharing (which is why some phones and many older devices don’t support it). Travel routers still have their place: Ethernet ports, better radios, and an always-on box you can run a VPN on. But if you’re on Android and your phone supports Wi-Fi sharing, you already have the core trick. Android doesn’t call it this in Settings, but it’s the best term I have for “connect to Wi-Fi, then share that Wi-Fi as a hotspot”. In strict networking terms, this isn’t L2 bridging; it’s typically tethering (routing/NAT) with a Wi-Fi upstream.  ↩︎ This works because the captive portal only sees your phone; everything else is NATed behind it.  ↩︎ Thank you Delta for being one of the few US domestic airlines that don’t place this restriction. Looking at you United.  ↩︎ Hotel and conference Wi-Fi often blocks device-to-device traffic on purpose (“client isolation”) so guests can’t discover, scan, or connect to each other’s devices. Your phone’s hotspot creates a separate little LAN, so your devices can talk to each other again.  ↩︎ I have a post in the making about this: “With Tailscale you don’t need to pay for a VPN”.  ↩︎ HTTPS encrypts the bank session, but open Wi-Fi is still untrusted: a malicious access point can tamper with DNS and try to steer you into phishing. A VPN (or Tailscale exit node) reduces the surface area by encrypting your traffic to a trusted endpoint.  ↩︎ Modern devices support AP (Access Point) + STA (Station) Mode, letting them act as both a client to one network and a hotspot for others, allowing Wi-Fi extension or tethering.  ↩︎ Definitions from Android’s Wi-Fi vendor HAL ( ): DBS (Dual Band Simultaneous), SBS (Single Band Simultaneous), MCC (Multi Channel Concurrency), SCC (Single Channel Concurrency).  ↩︎ Connect your Android phone to the Wi-Fi network you want to share. If it’s behind a captive portal, sign in as needed. Go to Settings → Hotspot & tethering → Wi-Fi hotspot (wording varies) and turn it on. Typically, if your phone does not support Wi-Fi sharing, it will disable Wi-Fi. Some OEMs show a separate toggle to enable Wi-Fi sharing. On Pixel phones, it’s automatic. Android doesn’t call it this in Settings, but it’s the best term I have for “connect to Wi-Fi, then share that Wi-Fi as a hotspot”. In strict networking terms, this isn’t L2 bridging; it’s typically tethering (routing/NAT) with a Wi-Fi upstream.  ↩︎ This works because the captive portal only sees your phone; everything else is NATed behind it.  ↩︎ Thank you Delta for being one of the few US domestic airlines that don’t place this restriction. Looking at you United.  ↩︎ Hotel and conference Wi-Fi often blocks device-to-device traffic on purpose (“client isolation”) so guests can’t discover, scan, or connect to each other’s devices. Your phone’s hotspot creates a separate little LAN, so your devices can talk to each other again.  ↩︎ I have a post in the making about this: “With Tailscale you don’t need to pay for a VPN”.  ↩︎ HTTPS encrypts the bank session, but open Wi-Fi is still untrusted: a malicious access point can tamper with DNS and try to steer you into phishing. A VPN (or Tailscale exit node) reduces the surface area by encrypting your traffic to a trusted endpoint.  ↩︎ Modern devices support AP (Access Point) + STA (Station) Mode, letting them act as both a client to one network and a hotspot for others, allowing Wi-Fi extension or tethering.  ↩︎ Definitions from Android’s Wi-Fi vendor HAL ( ): DBS (Dual Band Simultaneous), SBS (Single Band Simultaneous), MCC (Multi Channel Concurrency), SCC (Single Channel Concurrency).  ↩︎

0 views
Ivan Sagalaev 7 months ago

Pet project restart

So what happened was, I have developed my shopping list to the point where it got useful to me , after which I lost interest in working on it. You know, the usual story… It was however causing me enough annoyances to still want to get back to it eventually. So a few weeks ago, after not having done any programming for a year, I finally broke through the dread of launching my IDE again and started on slowly fixing the accumulated bitrot. And through the last several days I was on a blast implementing some really useful stuff and feeling the familiar thrill of being in the flow . Since I was mostly focused on making the app useful I didn't pay a lot of attention to the UI, so most of the annoyances were caused purely by my not wanting to spend much time on fighting Android APIs. Here's one of those. The app keeps several shopping lists in a swipe-able pager, and at the same time swiping is how you remove items from the list while going through the store. The problem was that swiping individual items was really sensitive to a precise finger movement, so instead it would often be intercepted by the pager and it would switch to the next list instead. That's fixed now (with an ugly hack). But the biggest deficiency of the app was that it didn't let me get away from one particular grocery store that I started to rather dislike. You might find it weird that some app could exert such control over my actions, but let me explain. It all comes down to three missing features… The central feature of my app is remembering the order in which I buy grocery items. This means I need a separate list for every store, as every one of them has a different physical layout. By the time I was thinking of switching to another store I already had an idea about a new evolution of the order training algorithm in the app, and a new store would be a great dogfooding use case for it. So I've got a sort of mental block: I didn't want to switch stores before I implemented this new algorithm. Over some years of using the app with a single store I've been manually associating grocery categories with products ("dairy", "produce", etc.). They are color coded, which make the list easier to scan visually. But starting a new list for another store meant that I would either need to do it all again for every single item, or accept looking at a dull, unhelpful gray list. What I really needed was some smart automatic prediction, but I didn't have it. I usually collect items in a list over a week for an upcoming visit to the store, and sometimes I realize that I need something that it simply doesn't carry, or my other errands would make it easier to go to another store. At this point I'd like to select all the items in a filled-up list and move them to another, which the app also couldn't do. See, it all makes sense! Now, of course it wasn't a literal impossibility for me to go to other stores, and on occasion I did, it just wasn't very convenient. But these are all pretty major deficiencies, and I'm not ready to offer the app to other people without them sorted out. Anyway… Over the course of three weeks I implemented two of those big features: category guessing and cross-store moves. And I convinced myself that I can live with the old ordering algorithm for a while. So now I can finally wean myself off of the QFC on Redmond Way (which keeps getting worse, by the way) and start going to another QFC (a completely different experience). All the categories (item colors) you see in the screencaps above were guessed automatically. My prediction model works pretty well on my catalog of 400+ grocery items: the data comes from me tagging them manually while doing my own shopping these past 4 years. And this also means, of course, that it's biased towards what I tend to buy. It doesn't know much about alcohol or frozen ready-to-eat foods, for example. I'm planning to put up a little web app to let other people help me train it further. I'll keep y'all posted! One important note though… No, it's not a frigging LLM! It's technically not even ML , as there is no automatic calibration of weights in a matrix or anything. Instead it's built on a funny little trick I learned at Shutterstock while working on a search suggest widget. I'll tell you more when I launch the web app. When I started developing the app, I used the official UI toolkit documented on developer.android.com. It's a bunch of APIs with a feel of a traditional desktop GUI paradigm (made insanely complicated by Google "gurus"). Then the reactive UI revolution happened, and if you wanted something native for Android, it was represented by Flutter . Now they're recommending Compose . I'm sure both are much better than the legacy APIs, but I'm kind of happy I wasn't looking in this space for a few years and wasn't tempted to rewrite half the code. Working in the industry made me very averse to constant framework churn. I'm not making any promises, but as the app is taking shape rather nicely, I'm again entertaining the idea of actually… uhm… finishing it. Which would mean beta testing, commissioning professional artwork and finally selling the final product. The central feature of my app is remembering the order in which I buy grocery items. This means I need a separate list for every store, as every one of them has a different physical layout. By the time I was thinking of switching to another store I already had an idea about a new evolution of the order training algorithm in the app, and a new store would be a great dogfooding use case for it. So I've got a sort of mental block: I didn't want to switch stores before I implemented this new algorithm. Over some years of using the app with a single store I've been manually associating grocery categories with products ("dairy", "produce", etc.). They are color coded, which make the list easier to scan visually. But starting a new list for another store meant that I would either need to do it all again for every single item, or accept looking at a dull, unhelpful gray list. What I really needed was some smart automatic prediction, but I didn't have it. I usually collect items in a list over a week for an upcoming visit to the store, and sometimes I realize that I need something that it simply doesn't carry, or my other errands would make it easier to go to another store. At this point I'd like to select all the items in a filled-up list and move them to another, which the app also couldn't do.

0 views
Circus Scientist 8 months ago

Building the One Button Remote

I did not do a full build video or photo’s today but here is what I have! This project was built with support from my Patreon supporters. Join for free updates! (links are examples from AliExpress) ESP32 C3 Super Mini Latching switch (power) Momenary switch Battery USB charging board (choose overvoltage cutoff protection – important!) Project Box Battery (Buy Locally – too expensive to ship!) When you toggle the latching switch it switches the circuit on/off – when off we can plug USB into the charger board to charge the battery. See this post over here for PlatformIO Firmware and Android App download links. One Button Remote is a simple Bluetooth Foot Switch. It sends Play/Pause media events to any connected device and as such can Play and Pause any media player. When connected to the One Button Player Android App it turns into a full background music controller – add number of music tracks and configure what you want each successive button press to do. I am using this for my Fire Show in particular. I mostly talk but there are two music tracks which I like to spin poi to. Before I made this I would have to press play on my phone with my hands (or trust the DJ if there was one to press play and stop at the right time). This is not practical if you are holding flaming fire torches!! Now I can pair my foot switch, start the app and stomp on the switch at the right time. This project is pretty much done. But I plan to go further. The post Building the One Button Remote appeared first on Circus Scientist . 3D print – fitting the electronics into the box was fine but everything is stuck on with double sided tape, except for the switch which actually is screwed into an L bracket I had (originally for a PIR sensor). This is not the easiest thing to put together securely and in future I plan on doing a nice 3D printed housing. A week ago my Samsung phone finally got upgraded from Android 14 to Android 15. Now the app does not receive media events (button presses) while running in the background – for example if the screen is off. Luckily my media player phone is on Android 7.1 but in future I will have to find out what Google changed and update the app to work on Android 15+ properly. 3.7v battery on 5v input pin is probably not the most efficient way to power this. Needs a boost module – or just a bigger battery ;b

0 views
Danny McClelland 1 years ago

2025 Privacy Reboot: Six Month Check-In

Six months ago, I wrote about my privacy reboot — a gradual shift toward tools that take both privacy and security seriously. It was never about perfection or digital purity, but about intentionality. About understanding which tools serve me, rather than the other way around. Here’s how it’s actually gone. The Wins Ente continues to impress. The family photo migration is complete, and the service has been rock solid. The facial recognition quirks I mentioned on Android have largely sorted themselves out, and the peace of mind knowing our family memories aren’t feeding Google’s advertising machine feels worth the subscription cost.

0 views
Kaushik Gopal 1 years ago

Taildrop - transfer files between Android and MacOS

I use the Pixel 9 Pro as my daily driver and love it. But one notable feature I’ve always missed from the Apple ecosystem is AirDrop . I typically have WhatsApp for Mac open and dump things there for quick access between devices. Clunky, but it worked. Until I realized Tailscale — a VPN 1 that I love and use — has a feature called Taildrop . The name suggests it’s meant as an AirDrop competitor, and I’ve been super happy with it. I can now send images uncompressed 2 to any of my devices. I’m not restricted by Bluetooth, proximity, or other limitations. Just need Tailscale running on the device. Probably the highlight here is that Taildrop works on any device that supports Tailscale. So between a Pixel, iPhone, MacBook, Windows machine — no walls here. There’s no filesize limit. In all fairness, AirDrop doesn’t have one either. Another alpha feature they’re working on, similar to Taildrop, is Taildrive . It’s effectively a shared folder on the internet. If you’re on the same network (Tailnet), you can download files from this folder from anywhere. This basically allows any folder on your device to become a mini NAS or file server. Bonkers! It’s not all sunshine and rainbows though. There are some constraints and issues with Taildrop. Even if you add another user to your Tailscale network, you can still only send files to yourself. I imagine this is still an early restriction, but the good news is that Tailscale is thinking about relaxing this over time (maybe). This is clearly an area where AirDrop is superior since it can more conveniently allow you to send files to anyone nearby. Note this doesn’t apply to Taildrive, just to Taildrop. With Taildrive, anyone on your Tailnet can access the shared files. AirDrop handles sharing URLs or links elegantly. Share a URL from your phone to computer, and it automatically opens in your default browser. You can’t share links with Taildrop yet. When Taildropping from Android, I’ve noticed it occasionally caches the previous files that were sent. If you’re not carefully watching the preview, you can end up sending the wrong file. In all fairness, Tailscale has labeled it as an alpha, so they get a pass on this. Their solutions are typically rock solid, so I fully trust when they graduate it from alpha, it’ll be production ready. Despite these limitations, Taildrop has become an essential tool in my cross-device workflow. For Android users longing for AirDrop-like functionality, it’s worth setting up Tailscale for this feature alone. And if you’re already using Tailscale for other purposes , enabling Taildrop is a no-brainer. VPN might conjure up a different picture here. Think of it simply as a secure tunnel to any of your other devices.  ↩︎ One of the notable problems with my lazy WhatsApp strategy.  ↩︎ VPN might conjure up a different picture here. Think of it simply as a secure tunnel to any of your other devices.  ↩︎ One of the notable problems with my lazy WhatsApp strategy.  ↩︎

0 views
Kaushik Gopal 1 years ago

Age of the AI phone

In Vinay’s latest newsletter , he asks a few of us #AndroidDev to predict what the future of Android development is going to look like. Yours truly had this as one of the predictions: AI everything 🙄 … On the product side, we’ll see more on-device AI, with smaller models like Gemini Flash/o3-mini running locally to provide operator-like intelligence directly on phones and this will probably be what most folks are geared towards doing for mobile development. Looking at this Youtube video that’s now doing the rounds, I’m starting to feel ever so slightly validated. Google (or Samsung) truly have their shot of gaining significant Mobile market share again, especially given how much Apple has been floundering in the AI space.

0 views
Luke Hsiao 1 years ago

How to connect MTP to a kids profile on a Fire tablet

This is mostly a note-to-self. I’m a father with a kid that is starting to get old enough to appreciate some screen time. To that end, we got a cheap Amazon Fire tablet (sidenote, it seems Amazon has a corner on this market). It was nice, we set up a kid’s profile, disabled the store, disabled calling, disabled the web browser, shared VLC (for personal media) and AnkiDroid (for educational flashcards). But, then I couldn’t figure out for the life of me how to get media onto the internal storage in a way that was visible to that kid profile! Here’s the trick: Step 3 in particular was not obvious to me. Log in to the kid profile. Bring down the settings menu by dragging down on the top. Press and hold the Bluetooth icon until a PIN prompt appears. Enter your pin. The “Connected devices” menu will open, where you can change the USB setting to File transfer. Now, the internal storage reflects this kid profile specifically.

0 views

Airplane Mode for Glass

I've built my first little piece of software for Google Glass. I flew home from SF yesterday and realized that there was no way (short of installing a very crashy Settings.apk) to enable Airplane Mode on my Glass. That seemed like a reasonable enough "small" starter project. This is really, really only for folks who are already comfortable running third party apps on their Glass. If you don't know how to sideload apps with adb, please don't install this.  You can grab the initial build at: https://www.dropbox.com/s/rtbt7vc3bz67j3c/GlassAirplane-0.1.apk Source lives at  https://github.com/obra/GlassAirplane Patches welcome!

0 views

Recon MOD Live - a hackable $300 Android wearable (sort of)

I got a MOD Live HUD from Recon Instruments today. It is, indeed, running Gingerbread. As it turns out, if you can get it to install an update.zip, it won't check the signatures. Which means it's pretty easy to root :) Cracking it open, the display is a Kopin, though I don't yet know which model. It's designed as a look-around display. The prism has a mirrored backing and is wrapped in black plastic. The mirror coating on the prism comes off quite easily with a bit of rubbing alcohol. So yeah, rootable Android (2.3) wearable computer. $300. More details as the story develops.

0 views

Google I/O 2013 & Google Glass

Growing up and hanging out near Cambridge, MA, I was always fascinated by the "mediaborgs" - the folks around the Media Lab who were building and using wearable computers. I spent a lot of time trying to figure out how I could get myself a rig. At the time, the $1000+ for a heads-up display was more than I could pull off. I played around with sticking the tiniest laptop I could find (and even a bit of PC104 kit) in a bag and using a Twiddler and Emacs with T.V. Raman 's  emacspeak to have a walking-around computing environment with an audio interface. It was pretty neat, but incredibly clunky. I never really got the hang of it.  Over the years, I made a bunch of half-hearted attempts to get my hands on head mounted display that was functional enough to use and small enough to actually wear. I'd occasionally look around to see if anyone was selling something that seemed workable. Occasionally, I'd poke at http://tekgear.com/hmd.html to see if there was anything that looked reasonable. Generally, though, the cheap options cost around $1000 and are really intended for immersive video or gaming experiences. (Or they're upwards of $10,000 and intended for defense and industrial applications.)  Needless to say, Google Glass somewhat piqued my interest. Google aren't yet making Glass available to folks like me who played the #ifihadglass game. It sounds like they're just getting a handle on the initial production run for folks who were at Google I/O last year. I got to try Glass pretty early in the conference. The friend demoing it for me was pretty happy with his, but the functionality he was able to show me was...very basic. To a first approximation, all you can do with the current "Mirror" API is to push snippets of text or HTML+CSS to be displayed in the upper-right corner of the wearer's vision. At one of the early Glass talks at I/O, the speaker mentioned that a "GDK" to allow native development was coming soon. Glass is, indeed, Android under the hood. (4.0.x for now) Suddenly, this was looking a little more interesting. A couple weeks ago, +Jay Freeman (@saurik) made news by finding an exploit that allowed him to gain root on his Glass. Since then, there's been a bit of a of a hacker scene growing up around Glass. At dinner on Thursday, I  saw a demo of a patched version of Glass Home running on an Android phone. I've heard reports of a homebrew Glass lock-screen app with an improved guest mode, too. The one session at I/O that I was not going to miss was + Hyunyoung Song   & + P.Y. Laligand   talk on "Voiding your warranty: Hacking glass" ( Linked below, since I can't figure out how to inline it in G+.) Having been shut out of a few over-full sessions earlier in the conference, I went and sat second-row center at the previous session in the same room -- and learned a bunch of useful stuff about what's coming in Google Analytics. (During the GA session, I was seated next to a guy who looked to be trying to get his new Chromebook Pixel into developer mode. I...tried to be helpful. I was a little bit embarrassed to realize that  he was none other than + Liam McLoughlin   (@hexxeh), who, uh, knows a little bit about ChromeOS.  Getting there early was a good call. The session was packed.  Really packed. H.Y. and P.Y. demoed how to use adb to push a launcher app and a settings app to your Glass and how to pair a Bluetooth HID device (which just works) and talked a little bit about what one can do by treating Glass as just a "regular" Android device. Porting + K-9 Mail   looks incredibly plausible. I'm really glad we never gave up on QVGA support. Then they got into the good stuff. How to unlock and root your Glass. It's.. really easy. And exactly how you'd assume you'd do it.  https://plus.google.com/118132270929426815661/posts/4MyjGZhN575 is cameraphone shot of the slide from their deck. To explain just how far one could go, H.Y and P.Y. demoed that one could use one of the Linux Installers on the Play Store to install an Ubuntu chroot on Glass. They said that they'd gotten the idea for the demo from + Greg Priest-Dorman   who "does his development in Emacs on Glass."  The world of computing is a very small place. I remember corresponding with Greg when he was at Vassar in the late '90s. If I recall correctly, my friend + Dave Barker  mentioned to Greg that I had a Twiddler I hadn't fallen in love with. He was hoping to get to try out and I was a flaky Wesleyan undergrad, though I'm pretty sure we met and he showed me his wearable when I finally got up to visit friends at Vassar. Chatting with a few other Googlers, it sounds like there's a fair contingent of Glass developers who use emacs (and possibly emacspeak) on Glass. So yeah, after the Hacking Glass session, I..really, really want to get back to wearables stuff. As soon as I can get my hands on a Glass, I will. I think I've found something to tide me over. On more than one occasion, Artur Bergman has told me how amazingly amazing his ski goggles with a heads-up display are. They have a bunch of skiing-related sensors. I just sort of assumed that they had some little microcontroller and a custom OLED superimposed on the faceplate. I was wrong. The folks who make the goggles, http://reconinstruments.com ,  were exhibiting at I/O. Their next gen product, "Jet",  is a Glass-esque setup with (not-see-through) HMD, an HD camera, bluetooth, wifi, a gigahertz ARM chip running what they say will be a fully unlocked build of Jellybean capable of running regular Android apps. It's going to ship "later in 2013" for "less than a thousand dollars." So, that's pretty cool. But I can't have one today. As I talked to them a bit more about their existing product, I found out that it was...not quite what I expected. It's a QVGA (320x240) display that they say looks like a 14" screen 5 feet away. It's powered by...a device running (the slightly dated) Android Gingerbread. (In a previous version of this post, I accidentally said it was running Froyo)  Me: "So, I could buy a set of your ski goggles for $449 and rip them apart and get a wearable computer running Android with a heads up display." Guy from Recon: "Well, you could.The HUD is designed to be taken out of one set of ski goggles and put in new goggles when you upgrade. Bu t, that's kind of a pain in the neck. It'd be easier and cheaper just to buy the HUD from our webshop as a standalone unit. It's $300." Me: "..." Me: "..." Me: "And this is shipping? I can order it today and you already have them in stock?" Recon: "Oh yeah, I mean this is the old model. It's been out for a while. We've actually discounted it from $400 to $300. It's running Froyo. The new one is much nicer and will be out later this year." Me: "Please take my money" So yeah. $300 wearable Android device. Has been shipping for quite a while. You can buy one today. I ordered mine before blogging about it. I'll report back once I've gotten to play with it. To answer the obvious question: Yes, I will be building a version of K-9 Mail for heads up displays. To answer the other obvious question: Yes, I'm going to be playing with building a Bluetooth input device or two for Android wearables.

0 views