Posts in Android (15 found)
Kev Quirk 1 weeks 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

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 2 weeks 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 1 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 1 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 7 months 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 8 months 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 11 months 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 11 months 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