Most (if not all) current phones available in the market cannot even boot without a battery connected, is that correct? I'd feel a lot more comfortable without having to worry about it and risking forgetting about it for any unspecified amount of time just to find a pillow protruding from the back case. I really find it a shame that we have relatively powerful, energy efficient, mass produced devices in our pockets we eventually dispose of when they could have a second life serving another purpose. postmarketOS is a really interesting project, and if most phone manufacturers weren't actively user-hostile I could've used some old phone instead of my Pi(s) for whatever project I'm interested into, but I however think it's fruitless until strict regulations allow users to do whatever they wish with their handheld PCs. Due to this, among other things, I find all the talk about recycling and whatnot hypocritical from big companies, that should be the last stage of something's life, not dictated by obsolete security patches or the likes.
On the battery issue. A place I used to work had iPads stuck on meeting room doors with a webapp for booking and displaying who'd booked meeting rooms. They were puffing batteries in 9-12 months of being plugged in 24x7.
I got a few cheap power point timers, and set them to only charge for 1 hour twice a day, and we didn't have a battery failure in the 3 years after that while I was still there.
(Totally agree with the rest of your comment too...)
I forget when, but in last ~3-5yrs, I've noticed iOS seems to handle this. If you leave a device plugged in for a long period you eventually getting a notification saying it's not gonna charge as much, and it caps the max battery to 80%.
Just wondering if your story is before or after that feature.
Phones can't run without the battery because their peak power usage can exceed what the phone chargers provide. So the battery is used to cover these micro power spikes.
Throttle the CPU if you find that the phone or charger get warm (too much power supplied long-term) or if the phone crashes (sudden power demand -> low voltage and supply can't react).
You have several bottlenecks in the chain. The phones won't draw more than what their internal power distribution system was laid out for. If it requires a battery internally to run stable you can't just fix that by theoretically supplying more at another point. Batteries are very convenient because they can act as a buffer that is able to supply a high peak current. Modern CPUs and GPUs need a high peak current if you don't take countermeasures. Supplying that peak current from an external power supply would be quite expensive.
To rephrase your question:
Could we build a new phone that runs off a 80..120 W charger without battery? Absolutely yes.
Will it help older phones that were not designed to use such a charger? No, most likely that charger will change nothing.
Those aren't the problem. It's that you can't control what the user will do/use (a sort of unbounded problem). The 0.5w or the ultra ultra cheap chargers that let AC signal through or maybe it's not giving true/clean 5/10/20v.
Now you have to have an extra decision circuit that judges whether or not the wall is "good enough to boot the phone" and then ask if it's good enough to run it as well. Last thing you want is wall power to dip randomly and you can't switch fast enough and simply shutting off.
I understand why you would pick the battery as the requirement. You know the exact behavior of when the phone is safely bootable vs not w/ a predictable DC signal.
Yes, commonly referred to as a “battery emulator” in EE labs for mobile devices. Some are lab grade test equipment from big name vendors, and some are home-grown concoctions which use a power supply, capacitors, and adjustable load to shunt the power when the device tries to “charge” the battery. If a battery charging circuit is running, it’s generally not enough to just provide a DC power supply, it actually needs to be able to both source and sink current. But if the battery charger can be disabled, then a high current power supply, lots of capacitors, and a good short connection can be enough to replace a battery for a phone/tablet.
Sure, it must be possible. You just need to give the right voltage to the +/- pins, and most phone batteries have at least one or two additional pins which you'll have to reverse engineer. Usually a thermistor for temperature reporting, which you'd replace with a fixed resistor / voltage divider to report a constant temperature.
Apparently some manufacturers put the phone's NFC coil inside the battery instead of on the phone's back housing, so there could be a fourth pin for that. Or perhaps the battery contains its own microprocessor that answers a DRM challenge from the phone specifically for the purpose of blocking out third party battery manufacturers. Etc. etc.
Still there is the problem that the phone might have peak power usage above what its charger can provide, so you'd have to use a wall adapter with a higher amperage rating.
> Or perhaps the battery contains its own microprocessor that answers a DRM challenge from the phone specifically for the purpose of blocking out third party battery manufacturers.
Ah yes, good old anticompetitive practices. Sleep well, FTC.
This sort of thing exists! I use something like that with my DSLR for a webcam. It’s great, there’s no real battery involved, it’s just a power cable with the end shaped like a battery.
That should be sufficient. The most peaky loads are RF transmit, can be 10-20W instantaneous. If you add that with GPU operations and backlight, camera, etc. But I don't think it'd easily go over a few tens of watts.
This actually happened with me :) I keep the phone wherever and don't look at it a lot; by chance I saw that the battery was bloated. The phone/server has been running fine since I bought the replacement, around 1.5-2 years ago.
Uptime has been really good, only downtime I had was when my wife disconnected the phone a couple of times and forgot to plug it back. Even when I moved a couple of months ago, the battery held, and downtime was basically just the time between disconnecting old wifi-reconnecting new wifi in new place.
I use a Magisk module called ACC (https://github.com/VR-25/acc) to set the charge/discharge range to be between 60-75% for my permanently connected old phone. I'm using it to show a Grafana dash of my computer's resources.
Wait, I assumed manufacturers (or ROM makers / AOSP) did this by default by not charging it to 100%?
Then again, why would they? The faster the battery goes the sooner the end user will have to either replace the battery (which is almost impossible with phones these days) or ditch the old phone and get a new one.
It's worth mentioning if you are going to follow these instructions that the creator of Termux no longer recommends you install from the Play Store[1], and to instead install from F-Droid or Github.
The "write-or-execute" policy causing this havoc is remarkably similar to what is being done with WebExtensions v3 banning any dynamic code execution. Termux wants to be able to bring down code & let users run it, but that's verboten. Similarly, all WebExtensions will be forbidden from bringing down code (or accepting user entered code).
That sounds fine/good for like 98% of extensions. But the other 2%... extensions like GreaseMonkey/VioletMonkey/TamperMonkey, or one could imagine something like IFTTT or PushBullet, where the extension might perhaps want some intrinsic extensibility to itself: those are all now verboten. There's not really any discussion or push/pull on the new security regimes. Computers just get more and more clamped down.
I'm interested to see how Termux goes forward. In the past they seemed to have some "in-APK packaging" notions for how to deal with Android 10+. I haven't stumbled upon a good description of what this is or how it would work, and I'm not really sure whether these ideas are still active or whether F-Droid and using ever aging SDKs is the way forward.
Termux still works fine on any Android device, all you've got to do is install it through F-Droid or similar. Google Play is the party blocking W+X, Android itself will happily execute your downloaded binaries (for now, at least).
There are also other APIs that are absolutely verboten by Google Play but will work fine if the app is installed through alternative app stores.
Nope, Android started to ban linking to native APIs that aren't officially part of the NDK, like Linux syscalls.
More recent versions will just kill the application if they get used, and Termux folks refuse to accept that they have to go through JNI for specific OS features, so they won't be around for much longer, other than on rooted devices.
Or they might eventually accept how things are done on Android.
That's begging the question; the only reason phones aren't general-purpose computers is because Google and Apple tend to block out anything that would let the user actually use the computer as more than a toy.
Pocket PC/Windows CE/Windows Mobile all seem far more like examples of phones trying really hard to be general-purpose like, rather than examples of phones being different. And getting fairly close.
Personally I think it's hard to justify phones as something different than general purpose computers. A device that can load fairly arbitrary apps is already almost by definition a general purpose computers, it's just a matter of what has been built and/or what is allowed to be shipped, and what system resources are available (few, in many of your examples, often owing to it being the aughts). Now that the system resources are clearly no longer a differentiator, it's almost all just corporate-politics & the war-against-general-purpose-computing vested-interests enforcing the distinction.
Yeah, and Q-Tips weren't meant to go in your ear, but we do it anyway. Modern smart phones are built to run applications - they're built with a CPU, RAM, and storage, just like your desktop. The only thing special about them is the integration of the cellular phone radio/modem into the main chip. Doesn't matter what they were or weren't "meant for", it matters what they _are_. Smart phones, nowadays, are essentially general-purpose ARM computers with really good power management.
> Or they might eventually accept how things are done on Android.
Given that the way you say "things are done on Android" is that tools like termux don't exist, you're effectively saying they should just give up and kill the project. I understand that this is consistent with your view of the OS, but can you understand why nobody involved is interested?
I think this is not the worst situation. Downloading executable code is very rare in normal use cases and is extremely common and powerful for malware. For the common user, its better to just turn this off. And for the power user, they are free to sideload apps that can do whatever they want.
The problem is you can't actually turn it off like you think you should be able to do. As well, you should expect feature parity (automated updates and so on) with the R^X turned off.
This is basically similar to the process I've used to turn my phone into a dev/writing environment for spending months thru-hiking in areas without internet.
I use termux to host a jupyterlab instance and bring along a tiny folding bluetooth keyboard. Even in airplane mode I can connect to the locally hosted jupyterlab instance. Notebooks are kept in git and synced up to my private repo when I'm back on grid.
There are simpler solutions for writing, but this allows me to keep a single workflow across home/travel contexts. Being able to run graphs, basic code and computation as needed is also a plus.
My older mac book recently died and instead of buying a new laptop I'm using termux to connect to a droplet for side projects. I've tried two different bluetooth keyboards so far and found one I liked with back-lit keys. Also recently setup wireguard on a raspberry pi at home and had fun working on my droplet through my VPN while on a flight. What a time to be alive.
Cool, I'll check it out. It is an extra hop, but my fdroid termux install has been blown away (along with my ssh key) several times by the play store version. So now I save my key on my pi instead. I did turn off updates from play store for termux so hopefully it doesn't overwrite termux again.
I don't know about brave, but the funniest thing I've done with my phone and keyboard is access an amazon workspace to run adobe InDesign for magazine layout while in my tent— sitting in a sleeping bag, a cold rain pattering against the "roof", with my back resting against my backpack and my phone angled nicely in my lap, using the keyboard's attached touchpad to carefully move and assign articles, tweak colors, and do the final bits needed for printing.
There was definitely some squinting at the screen involved, heh.
I’d love to know more about that. Isn’t running Adobe CC on AWS prohibitively expensive? You need a decent video card and at the very least 8GB of RAM.
Couldn’t you buy a laptop with what they’d charge you for a day of work? A quick simulation here is showing me US$ 140/h for a 4 core 16GB of Ram machine, no mention of video card.
You can easily stow a portable solar panel in a hiking bag that can charge your phone and the other accessories. A laptop would have a harder time getting charged, even if it was a Chromebook. Portable battery packs intended for phones would also be easy to stow. Not only do they fit more compactly, but they are light on your weight budget and not as fragile as lightweight laptops.
Here's the dynamic DNS plugin: https://github.com/mholt/caddy-dynamicdns -- it will just update the A records for your domain directly with your DNS provider, no need for a third-party service.
I don't think dynamic DNS will work on a phone connected to LTE service. LTE providers keep phones behind the NAT (or something with similar results). There is no way to forward/open a port for incoming connections. I wish there was a way to bring up a tunnel to make incoming connections possible via LTE/GSM OTA way.
T-Mobile has open ports on IPv6 (at least as of a few months ago). I was curious, and tried hosting a web site from my phone, and it worked flawlessly (assuming you are willing to abandon IPv4).
This is very interesting, and I want to try it out.
The part about them immediately receiving 'attack packets' made me realise that I am quite ignorant about the realities of web security. It is eye opening to me that a lot of web traffic is malicious.
Are there any 'security hardening your server 101 for n00bs' resources? It should be useful for any of these 'phone servers' as well (preferably tool agnostic)
Use ubiquitous open source software, which has been battle-hardened over the years.
I ran a web forum for years, either on PhPbb, or YAF.net. Never got compromised. Constant, round-the-clock attacks though.
I think the ultimate saving grace is that the site didn't contain anything of interest - it wasn't selling anything, so no stored credit cards. No digital goods to steal, no public forum topics which relate to videogames, politics, etc. It was a small forum for friends of mine, so there was no obvious community anyone wanted to ruin.
The worst we got, was some spam bots once in a while would breach the captcha, and start posting ads. Easily fixed. Not a hack, per se, but neither benign. I don't think we ever attracted the attention of a human hacker, and that's likely why we never got breached.
Genuine question : do you feel that FOSS is at a disadvantage when it comes to security/threat prevention? The hypothesis would be that potential attackers are able to gain the advantage by being able to fully review the source in advance and leverage potential weaknesses. (Or worse, contribute to the project and inject weaknesses)
It's the other way around. Only FOSS code has the ability to gather reviews, improvements and fixes from the general public. Security through obscurity is not security.
Yes, if you are a big corporation, and you have many employees with eyes on the code, there's no obscurity when an employee goes rogue, you are wide open.
But if you are the only person with access to the code, obscurity works
That is a nice hypothesis. The real world isn't that nice. You are assuming that proprietary software vendors care about fixing security vulnerabilities. Most of them don't and they will sue you if you make the foolish mistake of not contacting them anonymously.
The truth is that hiding source code is the security barrier for most proprietary software and nothing else.
Most of those "attacks" are extremely low effort full-Internet searches for easily exploited software, effectively checking if you've left your front door open. Basic security practices make a very large proportion of them entirely harmless. (things like not having default usernames and passwords, not including configuration files to be hosted directly, having authentication turned on at all, etc.)
You'll want to be basic security knowledge for whatever services you are using, but being safe from these kinds of attacks really only requires the absolute minimum.
Problem is if you don't keep on top of updates, your server very quickly goes from well secured to a low effort target. There was one instance I remember where an exploit for router software was found and published at the same time the patch came out so routers were being exploited within hours, before their users even had time to update them.
My servers get constantly hammered. 99% are either WordPress exploit requests (which I ignore as I don't run wordpress) or SSH attacks. For which I recommend using fail2ban.
Connecting fail2ban notifications to your telegram gives you a new perspective on how bad it really is :)
An important thing to know is that most automated exploitation techniques are only effective against old and outdated software. It's very rare someone will burn a 0day on the public internet.
My personal recommendations, ordered by importance, sort of, maybe:
- Minimize attack service: don't install it if you don't need it
- Assume you'll be compromised at some point. NSA servers get hacked. FSB servers get hacked. You're not better than them. Think of what you'll do when you get hacked: do you need to rotate keys, change passwords, delete tokens? It's better to have a plan, even if it's a vague idea, just in case.
- Think about who might hack you, and how. Are you an activist? You may have opponents that want to attack you directly. Are you just some guy with a blog? Focus on defending against your most probable attackers, like botnets and automated scripts. You can make grand plans for when the NSA tries to break into your secure server network, but in practice you should probably be fine if you just defend against botnets. You can find entire threat analysis guides on the internet but a quick think about "who will attack me why and how will they do it" will probably do.
- You probably won't get hacked. Don't become too paranoid; just taking the bare basic steps to prevent getting hacked will make you more secure than millions or even billions of hosts on the web.
- Install software in a way that automatic security updates will take care of common vulnerabilities (i.e. prefer apt-install over ./configure && make && sudo make install or curl | bash).
- Check how quickly your upstream sources (Termux, in this case) are issuing patches. I haven't checked Termux' security stats myself, but I'd personally try a Debian chroot over a Termux environment just because Debian has more funds available to provide timely updates.
- Principle of least privilege: barely anything needs root anymore. Ignore outdated guides and use separate users (or even random user IDs with systemd), it'll probably work. If your server provider gives you a root account, create a normal account, give it sudo permissions, and disable remote root login; root should only be for system maintenance and repair!
- Read the manual for suspicious config you copy/paste. Sometimes config is just data (hostnames etc.) but sometimes config disables or overrides default config; for those cases, think "why is this not on by default"
- When in doubt, update. Auto-update if you have to. I've run sudo apt update && sudo apt upgrade -y" in a cron job for years but there are better options for most server OS's. On Ubuntu (and probably Debian) run sudo dpkg-reconfigure unattended-upgrades to configure automatic security updates
- If you do install stuff manually (downloading a binary, curl2bash, etc.) then find out how to update such software and think of ways to automate the process
- Listen to warning messages. For example, many old Ubuntu guides will have you add PPAs in a manner that will give the security keys of a PPA the ability to sign packages from the main system repos. You'll get warnings if you use this method on a modern system and you should probably heed those.
- Reboot your server after important kernel updates. If you can afford the downtime, reboot after every update just to be sure; if you can't, check if any important patches were released during the past few days. You can often monitor the reboot status file (/var/run/reboot-required, for example) to see if a reboot is necessary.
- Make sure your services come back up after a reboot. One of my servers has a nasty firewall configuration bug somewhere that I haven't been able to track down that causes the firewall to refuse to start on boot. Better to find out that your server isn't reboot safe during a planned maintenance window than when you need the service and it suddenly stops working!
- An important file doesn't exist unless it's at three places, at least two which are in a different geographical location. Make backups!
- Test if you can recover from backups. An untested backup is a non-functional backup.
- Back up recovery/security keys to a safe location. Your fancy, unbreakable hard drive encryption is useless if you forget your password!
- When using Docker, make sure to update regularly. It's very easy to deploy a docker application and forget to update it for years!
- Even if nothing is going on, log in every now and then and check how your server is doing.
- Keep an eye on exploit/security lists for software that you expose publicly, especially if you're not updating them automatically. There are websites that will list all important new vulnerabilities for only certain projects (I use the RSS feed provided by the Dutch government, but others likely exist).
- When you see your server might be vulnerable, don't panic. Vulnerability descriptions often start with "an unauthenticated user may execute code and take over the system and turn the sky red and..." and end with "if the administrator has enabled the enable_apple_II_compatibility setting". For example, the Samba/SMB bug that allowed code execution on NAS devices only applied when the optional AppleTalk extension was enabled, which was commonly disabled by default.
Apparently there's a comment size limit, who knew! Anyway, continued:
- Did I mention updating? You'd better update! Did you update? Good, then you're probably fine!
- Install a firewall. The Internet may tell you that you need to learn nftables but in practice tools like `ufw` will protect you just fine. Work in whitelist mode for incoming traffic. Work in whitelist mode for outgoing traffic if you want to spend an hour every week debugging why your server went down again.
- Pick good passwords, or even better, don't use passwords at all. Use key based authentication for SSH, use WebAuthn/U2F/whatever for admin panels, make it as hard as possible to brute force your way in. Don't reuse passwords! You don't want to get hacked because your password showed up.
- Keep an eye on risky software. For example, WordPress itself is quite secure, but many of its plugins have been plagued with vulnerabilities.
- Make maintenance/updating your services easy. Sometimes that means you need to spend more time setting everything up. Sometimes that means configuring your system in a suboptimal way, or even disabling other security features. Locking everything down can make it impossible to properly update your software and software you don't update is just waiting to get exploited by a bot.
- Not a security measure per se, but useful to reduce log spam: change the SSH port from 22 to literally anything else.
- When serving anything UDP (DNS/SSDP/whatever) make sure to check if there's a DDOS potential and see if you can mitigate it. If you can't, see if you can whitelist destination/source IPs in your firewall.
- HTTPS is free and quite easy. Why not enable it? If you turn it on, you can use "outdated" security mechanisms like HTTP Basic Auth without hesitation!
- Make sure to migrate in time when a software package gets out of date. Ubuntu 18.04 will receive updates for years to come, but you should probably plan to migrate two years before the end date. The longer you wait, the more difficult migration will be, the longer you'll put it off and the more likely you'll run vulnerable, outdated software.
- Hack yourself. Run port scans against your own servers; you might just find that you forgot that Docker will bypass your firewall. That's how I found out! I've accidentally had stuff running publicly that should've been private for months because I didn't port scan after installing new software. Other tools include stuff like wordpress security scanners, OWASP ZAP, etc.
- Sometimes you'll find yourself in a tricky situation: one of your services is vulnerable but no update is out for your platform yet. Consider temporarily disabling the service if it's not _that_ important or restrict your firewall to accept only certain IP addresses if you can't live without it.
- If you're only going to use the service yourself, you might not need to expose it to the internet. Maybe you can use a VPN to only allow trusted devices to connect. Maybe you can use Tor to make a service available (from behind NAT, even!). Never fully disable authentication and such on trusted networks unless you don't care about getting hacked, though.
- If you feel like the software you're running may be a common target, read your web server logs. See if you're getting flooded with weird requests and Google the URLs to see if you might be vulnerable.
- Periodically check if software you've installed is no longer necessary. Removing unnecessary attack surface not only makes your server more secure, it'll also help you keep down the amount of maintenance you need to do!
- Install security updates. Really, that's maybe the most important part, after picking good passwords. An updated server is a happy server. In most cases, an updated server is an unhackable server!
- Don't fall for emails like "I found a vulnerability in your server, do you provide a bug bounty".
- If you write your own software, regularly update dependencies and run vulnerability scanners (preferably automated). Stuff like https://owasp.org/www-project-dependency-check/ isn't hard to integrate into your workflow and might warn you of vulnerable libraries you didn't even know you used!
- Terms to throw into Google if you're interested: WAF (Web Application Firewall), Fail2ban, Tarpit (networking), cgroups, systemd hardening, snort, suricata
Finally, for your personal devices: use a password manager with a Really Good master password and enable 2FA. For most services a good password is a password you don't know. Use software that's as convenient to use as possible without sacrificing security (i.e. use a password manager that integrates with your phone's/browser's autofill). Stuff like WebAuthn/U2F/FIDO2 can make 2FA very usable without having to copy a bunch of numbers every time you log in and they're available on more devices than you might think. You can go ultra secure (I, for one, enabled 2FA on SSH at some point) but the harder you make it for yourself, the less likely it is that you'll find yourself using your fancy security.
Some people will probably disagree with me on some points. Some of them are overkill, some of them are not strict enough. There's no one true answer for any of this, because every server is different and has different security requirements.
In case you feel overwhelmed: what I just typed out isn't followed by (way too) many companies. If you work outside a tech company I doubt the IT departments/people even know what company secrets are on what server. Companies will silently or unknowingly run vulnerable software for years without getting hacked! Your home server may be more secure than a critical application server that some Fortune 500 company relies on, simply because you can run updates and they're stuck with some outdated OS/software/hardware/network/configuration that they can't move away from without spending millions!
The main advice I'd give is don't follow the steps about port forwarding and public DNS if you are noob. If you are just playing around with things, you don't need to put it on the public internet, you can just access it over your local network none of those concerns really apply. Other than that, update software regularly because that malicious traffic can only hurt you if you are vulnerable. Otherwise it is just noise in your logs.
You could use PHONK https://phonk.app/ to create a script that runs a web server and combine it with more custom stuff such as Sound, visuals, MQTT, sms, etc etc
There should be little current through the battery while the phone is plugged in, virtually none if the charger can meet its peak power draw. If degradation over time is a concern (perhaps it boot loops if the battery is very dead), a charge-limiting app set to 50%, the level recommended for storage and used in the Microsoft Surface UEFI Kiosk mode, should maximize life.
Usually these don't like booting without the battery, but maybe there's a way to provide data-only USB connections and a lithium-level voltage internally. Often the early boot stages will interrogate the battery level and refuse to boot if it's too low, but it's very much model dependent.
had two batteries "explode" (ballooned ¹) because of this, then I switched to another phone and knock on wood the battery has not yet exploded (about 2 years).
¹ This is probably why you should not cut off the battery plastic sealing like some DIY guides tell you to do, it's probably there for a reason.
You can leave a phone plugged in all the time with no issues, the same way you can do the same with a laptop or any number of the other ubiquitous USB-chargeable things these days. The only time it's an issue is if the device was _extremely_ poorly designed.
Some good phones will even notice that they are plugged in all the time and drop the charge level to 80%, where most batteries are happiest to stay for long periods of time.
I went the Linux Deploy route and published a couple of container images that Just Work on pretty much any ARM Android device.
Once you shiv systemd, some pretty elaborate scripts can run in an Android chroot just like they would on bare-metal ARM. Just think of your old Android as an off-brand rPi with case, built-in touchscreen LCD, and way, way fewer GPIO pins. No surprise the server will need a new UPS battery.
Doesn't Android's aggressive app sleeping/killing policies (ostensibly to extend battery life) make this somewhat... well if not useless then at least a challenge?
I have a bunch of old Android phones kicking around that I'd like repurpose for random IoT/monitoring things but I don't trust them to stay "on" all the time. And Raspberry Pis are pretty cheap, so...
Termux supposedly has a setting that prevents that. I haven't had issues so far; I keep long-running stuff like tmux with `tail -f log-file` etc running for literally months.
Just make sure to either set the thing to not go to sleep while connected to a power supply in the developer settings, get a wake lock for your specific application or use another app to keep the device awake. Android phones make for versatile sensor-rich platforms for monitoring/media/etc. applications. They come with their own wifi hotspots, 3/4G communications, several cameras, microphones, motion sensors, compass, gyroscope, light sensors, proximity sensors, magnetic sensors and more. They even have their own built-in UPS so... get hackin'.
facepalm. you think you’re saving the planet reusing an old cellphone? what about the other 8 billion people who don’t care? it’s just virtue signaling. fantasy. you don’t have a reason just a rationalization. and that’s a problem because it means your logic is frying like an egg on a hot sidewalk
It is well known you can't do a Good Thing if Others don't do it too because it will be inefficient and have no result globally visible. And why Others don't do it? Nobody else is doing it, duh.
Most (if not all) current phones available in the market cannot even boot without a battery connected, is that correct? I'd feel a lot more comfortable without having to worry about it and risking forgetting about it for any unspecified amount of time just to find a pillow protruding from the back case. I really find it a shame that we have relatively powerful, energy efficient, mass produced devices in our pockets we eventually dispose of when they could have a second life serving another purpose. postmarketOS is a really interesting project, and if most phone manufacturers weren't actively user-hostile I could've used some old phone instead of my Pi(s) for whatever project I'm interested into, but I however think it's fruitless until strict regulations allow users to do whatever they wish with their handheld PCs. Due to this, among other things, I find all the talk about recycling and whatnot hypocritical from big companies, that should be the last stage of something's life, not dictated by obsolete security patches or the likes.
On the battery issue. A place I used to work had iPads stuck on meeting room doors with a webapp for booking and displaying who'd booked meeting rooms. They were puffing batteries in 9-12 months of being plugged in 24x7.
I got a few cheap power point timers, and set them to only charge for 1 hour twice a day, and we didn't have a battery failure in the 3 years after that while I was still there.
(Totally agree with the rest of your comment too...)
Was this recently?
I forget when, but in last ~3-5yrs, I've noticed iOS seems to handle this. If you leave a device plugged in for a long period you eventually getting a notification saying it's not gonna charge as much, and it caps the max battery to 80%.
Just wondering if your story is before or after that feature.
edit: I googled, it was iOS13, so 2019 - https://support.apple.com/en-ca/HT210512
Way before. 2014-ish.
Phones can't run without the battery because their peak power usage can exceed what the phone chargers provide. So the battery is used to cover these micro power spikes.
Throttle the CPU if you find that the phone or charger get warm (too much power supplied long-term) or if the phone crashes (sudden power demand -> low voltage and supply can't react).
Even with 80w-120w chargers these days?
You have several bottlenecks in the chain. The phones won't draw more than what their internal power distribution system was laid out for. If it requires a battery internally to run stable you can't just fix that by theoretically supplying more at another point. Batteries are very convenient because they can act as a buffer that is able to supply a high peak current. Modern CPUs and GPUs need a high peak current if you don't take countermeasures. Supplying that peak current from an external power supply would be quite expensive.
To rephrase your question:
Could we build a new phone that runs off a 80..120 W charger without battery? Absolutely yes.
Will it help older phones that were not designed to use such a charger? No, most likely that charger will change nothing.
Those aren't the problem. It's that you can't control what the user will do/use (a sort of unbounded problem). The 0.5w or the ultra ultra cheap chargers that let AC signal through or maybe it's not giving true/clean 5/10/20v.
Now you have to have an extra decision circuit that judges whether or not the wall is "good enough to boot the phone" and then ask if it's good enough to run it as well. Last thing you want is wall power to dip randomly and you can't switch fast enough and simply shutting off.
I understand why you would pick the battery as the requirement. You know the exact behavior of when the phone is safely bootable vs not w/ a predictable DC signal.
> It's that you can't control what the user will do/use
You can throttle the CPU. In fact you should, especially if you expose it to the public, to prevent it from overheating.
I wonder if you could make a virtual battery, that was really just a dummy load that always said the battery was at 100%, so a charger could be used.
Yes, commonly referred to as a “battery emulator” in EE labs for mobile devices. Some are lab grade test equipment from big name vendors, and some are home-grown concoctions which use a power supply, capacitors, and adjustable load to shunt the power when the device tries to “charge” the battery. If a battery charging circuit is running, it’s generally not enough to just provide a DC power supply, it actually needs to be able to both source and sink current. But if the battery charger can be disabled, then a high current power supply, lots of capacitors, and a good short connection can be enough to replace a battery for a phone/tablet.
Sure, it must be possible. You just need to give the right voltage to the +/- pins, and most phone batteries have at least one or two additional pins which you'll have to reverse engineer. Usually a thermistor for temperature reporting, which you'd replace with a fixed resistor / voltage divider to report a constant temperature.
Apparently some manufacturers put the phone's NFC coil inside the battery instead of on the phone's back housing, so there could be a fourth pin for that. Or perhaps the battery contains its own microprocessor that answers a DRM challenge from the phone specifically for the purpose of blocking out third party battery manufacturers. Etc. etc.
Still there is the problem that the phone might have peak power usage above what its charger can provide, so you'd have to use a wall adapter with a higher amperage rating.
> Or perhaps the battery contains its own microprocessor that answers a DRM challenge from the phone specifically for the purpose of blocking out third party battery manufacturers.
Ah yes, good old anticompetitive practices. Sleep well, FTC.
This sort of thing exists! I use something like that with my DSLR for a webcam. It’s great, there’s no real battery involved, it’s just a power cable with the end shaped like a battery.
Depending on how dumb the battery controller is, all it takes is pumping the right voltage back into the appropriate pins.
You literally can connect 5V instead of the battery (and a capacitor for some more stability) and the phone will gladly take that and power on.
I think even those could be a problem. Wired electronics contain capacitors to handle the spikes while phones use the battery as a cap.
That should be sufficient. The most peaky loads are RF transmit, can be 10-20W instantaneous. If you add that with GPU operations and backlight, camera, etc. But I don't think it'd easily go over a few tens of watts.
This actually happened with me :) I keep the phone wherever and don't look at it a lot; by chance I saw that the battery was bloated. The phone/server has been running fine since I bought the replacement, around 1.5-2 years ago.
Uptime has been really good, only downtime I had was when my wife disconnected the phone a couple of times and forgot to plug it back. Even when I moved a couple of months ago, the battery held, and downtime was basically just the time between disconnecting old wifi-reconnecting new wifi in new place.
I use a Magisk module called ACC (https://github.com/VR-25/acc) to set the charge/discharge range to be between 60-75% for my permanently connected old phone. I'm using it to show a Grafana dash of my computer's resources.
Wait, I assumed manufacturers (or ROM makers / AOSP) did this by default by not charging it to 100%?
Then again, why would they? The faster the battery goes the sooner the end user will have to either replace the battery (which is almost impossible with phones these days) or ditch the old phone and get a new one.
There's also https://f-droid.org/en/packages/com.slash.batterychargelimit... which just needs root.
It's worth mentioning if you are going to follow these instructions that the creator of Termux no longer recommends you install from the Play Store[1], and to instead install from F-Droid or Github.
---
1. https://wiki.termux.com/wiki/Main_Page#:~:text=do%20not%20in...
Does he also mention why?
Its to do with the Play Store requiring apps to target the Android 10 api level. Details at [1].
[1] https://www.xda-developers.com/termux-terminal-linux-google-...
The "write-or-execute" policy causing this havoc is remarkably similar to what is being done with WebExtensions v3 banning any dynamic code execution. Termux wants to be able to bring down code & let users run it, but that's verboten. Similarly, all WebExtensions will be forbidden from bringing down code (or accepting user entered code).
That sounds fine/good for like 98% of extensions. But the other 2%... extensions like GreaseMonkey/VioletMonkey/TamperMonkey, or one could imagine something like IFTTT or PushBullet, where the extension might perhaps want some intrinsic extensibility to itself: those are all now verboten. There's not really any discussion or push/pull on the new security regimes. Computers just get more and more clamped down.
I'm interested to see how Termux goes forward. In the past they seemed to have some "in-APK packaging" notions for how to deal with Android 10+. I haven't stumbled upon a good description of what this is or how it would work, and I'm not really sure whether these ideas are still active or whether F-Droid and using ever aging SDKs is the way forward.
Termux still works fine on any Android device, all you've got to do is install it through F-Droid or similar. Google Play is the party blocking W+X, Android itself will happily execute your downloaded binaries (for now, at least).
There are also other APIs that are absolutely verboten by Google Play but will work fine if the app is installed through alternative app stores.
Nope, Android started to ban linking to native APIs that aren't officially part of the NDK, like Linux syscalls.
More recent versions will just kill the application if they get used, and Termux folks refuse to accept that they have to go through JNI for specific OS features, so they won't be around for much longer, other than on rooted devices.
Or they might eventually accept how things are done on Android.
Since termux just uses regular unix applications, adapting them to use JNI sounds like a world of pain.
That is what they refuse to accept, Android isn't UNIX, it just happens to use Linux kernel.
The official APIs are Java based, ISO C and ISO C++ standard libraries, and the NDK libraries that ship on device.
That may be the case, but that's the reason why termux exists. If termux accepts that, the only logical consequence is to cease development.
Google is killing Android as a general-purpose computing platform.
Phones were never a general-purpose computing platform to start with.
That's begging the question; the only reason phones aren't general-purpose computers is because Google and Apple tend to block out anything that would let the user actually use the computer as more than a toy.
Mobile phones preceed Google and Apple, including the whole concept of stores and selling apps.
Series 30, Series 60, brew, J2ME, Psion OS, Pocket PC,....
They were never general purpose computers.
Pocket PC/Windows CE/Windows Mobile all seem far more like examples of phones trying really hard to be general-purpose like, rather than examples of phones being different. And getting fairly close.
Personally I think it's hard to justify phones as something different than general purpose computers. A device that can load fairly arbitrary apps is already almost by definition a general purpose computers, it's just a matter of what has been built and/or what is allowed to be shipped, and what system resources are available (few, in many of your examples, often owing to it being the aughts). Now that the system resources are clearly no longer a differentiator, it's almost all just corporate-politics & the war-against-general-purpose-computing vested-interests enforcing the distinction.
There are plenty of apps to do coding if one so will, with the APIs provided on the platform.
Not everything with a CPU needs to run yet another UNIX clone.
There are plenty of computers and maker boards for that purpose.
Yeah, and Q-Tips weren't meant to go in your ear, but we do it anyway. Modern smart phones are built to run applications - they're built with a CPU, RAM, and storage, just like your desktop. The only thing special about them is the integration of the cellular phone radio/modem into the main chip. Doesn't matter what they were or weren't "meant for", it matters what they _are_. Smart phones, nowadays, are essentially general-purpose ARM computers with really good power management.
Some people have this hurge to turn anything with CPU into something beyond their original purpose, the large majority of consumers don't.
> Or they might eventually accept how things are done on Android.
Given that the way you say "things are done on Android" is that tools like termux don't exist, you're effectively saying they should just give up and kill the project. I understand that this is consistent with your view of the OS, but can you understand why nobody involved is interested?
On the contrary, they should embrace the way Android applications are supposed to be written.
I think this is not the worst situation. Downloading executable code is very rare in normal use cases and is extremely common and powerful for malware. For the common user, its better to just turn this off. And for the power user, they are free to sideload apps that can do whatever they want.
The problem is you can't actually turn it off like you think you should be able to do. As well, you should expect feature parity (automated updates and so on) with the R^X turned off.
The play store version isn't being updated, owing to a policy change by google affecting their package manager
This is basically similar to the process I've used to turn my phone into a dev/writing environment for spending months thru-hiking in areas without internet.
I use termux to host a jupyterlab instance and bring along a tiny folding bluetooth keyboard. Even in airplane mode I can connect to the locally hosted jupyterlab instance. Notebooks are kept in git and synced up to my private repo when I'm back on grid.
There are simpler solutions for writing, but this allows me to keep a single workflow across home/travel contexts. Being able to run graphs, basic code and computation as needed is also a plus.
My older mac book recently died and instead of buying a new laptop I'm using termux to connect to a droplet for side projects. I've tried two different bluetooth keyboards so far and found one I liked with back-lit keys. Also recently setup wireguard on a raspberry pi at home and had fun working on my droplet through my VPN while on a flight. What a time to be alive.
You could probably set up Tailscail ssh that was recently posted here on HN. Though why do you need to go from VPN to droplet?
[1] https://news.ycombinator.com/item?id=31837115
Cool, I'll check it out. It is an extra hop, but my fdroid termux install has been blown away (along with my ssh key) several times by the play store version. So now I save my key on my pi instead. I did turn off updates from play store for termux so hopefully it doesn't overwrite termux again.
Termux does not update on the play store anymore since 2020 or 2021. In fact, your repositories are probably outdated
If you ever need to upgrade, you have to install from somewhere else, like F-droid
Thanks, I think actually it was something else that made me re-install from F-droid, but I'm glad I can rule out the play store.
I don't know what is braver, if hiking for months or developing on a Bluetooth keyboard and a phone.
I don't know about brave, but the funniest thing I've done with my phone and keyboard is access an amazon workspace to run adobe InDesign for magazine layout while in my tent— sitting in a sleeping bag, a cold rain pattering against the "roof", with my back resting against my backpack and my phone angled nicely in my lap, using the keyboard's attached touchpad to carefully move and assign articles, tweak colors, and do the final bits needed for printing.
There was definitely some squinting at the screen involved, heh.
I’d love to know more about that. Isn’t running Adobe CC on AWS prohibitively expensive? You need a decent video card and at the very least 8GB of RAM.
Couldn’t you buy a laptop with what they’d charge you for a day of work? A quick simulation here is showing me US$ 140/h for a 4 core 16GB of Ram machine, no mention of video card.
You can easily stow a portable solar panel in a hiking bag that can charge your phone and the other accessories. A laptop would have a harder time getting charged, even if it was a Chromebook. Portable battery packs intended for phones would also be easy to stow. Not only do they fit more compactly, but they are light on your weight budget and not as fragile as lightweight laptops.
Sure, but I’m talking about price. AWS Workspace seems crazy expensive, to the point of being unusable almost.
I love the digital nomad lifestyle, but at that price it’s more of a gimmick than a real choice
A g3s.xlarge running Windows is just under a dollar an hour - 4 cores, 30GB ram, 8GB video ram on Nvidia GPUs.
$140 gets you a t3.xlarge 4 core 16gb ram instance (on linux) for a whole month.
But that’s not Amazon Workspace he mentioned. That’s just EC2.
Check out the hourly price of Workspace:
https://aws.amazon.com/workspaces/pricing/?pg=workspaces&sec...
Sure, you can do this with nginx and dynamic DNS if you really want to, but Caddy does it all for you, with automatic HTTPS, and runs natively on Android (or in Termux): https://caddy.community/t/running-caddy-2-on-android/13993?u...
Here's the dynamic DNS plugin: https://github.com/mholt/caddy-dynamicdns -- it will just update the A records for your domain directly with your DNS provider, no need for a third-party service.
Thanks for that, will look at it!
I actually moved away from DDNS after a while because I moved and my new ISP had CGNAT. I posted about it here https://lbrito1.github.io/blog/2020/07/replacing_google_anal...
I don't think dynamic DNS will work on a phone connected to LTE service. LTE providers keep phones behind the NAT (or something with similar results). There is no way to forward/open a port for incoming connections. I wish there was a way to bring up a tunnel to make incoming connections possible via LTE/GSM OTA way.
T-Mobile has open ports on IPv6 (at least as of a few months ago). I was curious, and tried hosting a web site from my phone, and it worked flawlessly (assuming you are willing to abandon IPv4).
Wouldn't it be possible with ssh -R ?
The device connect remotely to a server that you control and give access back to you.
https://man.openbsd.org/ssh#R
Or setup wireguard and forward PUBLICIP:PORT to PHONE_WG_IP:PORT
Well, if you don't mind really slow bandwidth, you can set up a Tor onion service
This is very interesting, and I want to try it out.
The part about them immediately receiving 'attack packets' made me realise that I am quite ignorant about the realities of web security. It is eye opening to me that a lot of web traffic is malicious.
Are there any 'security hardening your server 101 for n00bs' resources? It should be useful for any of these 'phone servers' as well (preferably tool agnostic)
Use ubiquitous open source software, which has been battle-hardened over the years.
I ran a web forum for years, either on PhPbb, or YAF.net. Never got compromised. Constant, round-the-clock attacks though.
I think the ultimate saving grace is that the site didn't contain anything of interest - it wasn't selling anything, so no stored credit cards. No digital goods to steal, no public forum topics which relate to videogames, politics, etc. It was a small forum for friends of mine, so there was no obvious community anyone wanted to ruin.
The worst we got, was some spam bots once in a while would breach the captcha, and start posting ads. Easily fixed. Not a hack, per se, but neither benign. I don't think we ever attracted the attention of a human hacker, and that's likely why we never got breached.
Also - I am more knowledgeable now. Also install ModSecurity. That will block a lot of malicious stuff once you tune it to your application.
PHP forum software getting hacked used to be very common occurrence. Not so sure about those but I remember a vbulitin one being exploited.
Yeah, sure. PHPbb had plenty of exploits too.
You could read about them as they were published/fixed.
Genuine question : do you feel that FOSS is at a disadvantage when it comes to security/threat prevention? The hypothesis would be that potential attackers are able to gain the advantage by being able to fully review the source in advance and leverage potential weaknesses. (Or worse, contribute to the project and inject weaknesses)
It's the other way around. Only FOSS code has the ability to gather reviews, improvements and fixes from the general public. Security through obscurity is not security.
> Security through obscurity is not security
I've never felt comfortable with that argument
Yes, if you are a big corporation, and you have many employees with eyes on the code, there's no obscurity when an employee goes rogue, you are wide open.
But if you are the only person with access to the code, obscurity works
Obscurity doesn't work because someone will find the hole, they don't need the source code.
This is how companies justify not patching security vulnerabilities.
I don't follow, I said obscurity does not work for companies
I only think it can work for very small teams with high trust
That is a nice hypothesis. The real world isn't that nice. You are assuming that proprietary software vendors care about fixing security vulnerabilities. Most of them don't and they will sue you if you make the foolish mistake of not contacting them anonymously.
The truth is that hiding source code is the security barrier for most proprietary software and nothing else.
> Never got compromised.
What makes you 100% sure you would have figured out?
One way of checking is that emails and passwords/hashes might appear in leaks and then DBs like https://haveibeenpwned.com/
Most of those "attacks" are extremely low effort full-Internet searches for easily exploited software, effectively checking if you've left your front door open. Basic security practices make a very large proportion of them entirely harmless. (things like not having default usernames and passwords, not including configuration files to be hosted directly, having authentication turned on at all, etc.)
You'll want to be basic security knowledge for whatever services you are using, but being safe from these kinds of attacks really only requires the absolute minimum.
Problem is if you don't keep on top of updates, your server very quickly goes from well secured to a low effort target. There was one instance I remember where an exploit for router software was found and published at the same time the patch came out so routers were being exploited within hours, before their users even had time to update them.
> It is eye opening to me that a lot of web traffic is malicious.
you should work from the assumption that ALL network traffic is malicious.
This is absurd. If all network traffic is malicious, just unplug your device. Boom, more secure.
At least some traffic is expected to be valid, but the majority will not if internet facing.
Google “Linux hardening for beginners hacker news” there are articles with easy steps and thoughtful comments from time to time.
> If all network traffic is malicious, just unplug your device. Boom, more secure.
I'm not sure why you're saying that like it's ridiculous, it's just plainly true.
Obviously it’s not true. Or you’d have no legit traffic
OK, then work from the assumption that all network traffic is suspect.
There ya go
This is spot-on, especially given the topic of hosting and protecting a server.
If you assume that it is all malicious, (and much/most of it is), you stand a better chance of fending an attack.
My servers get constantly hammered. 99% are either WordPress exploit requests (which I ignore as I don't run wordpress) or SSH attacks. For which I recommend using fail2ban.
Connecting fail2ban notifications to your telegram gives you a new perspective on how bad it really is :)
Step 1) If it's not installed, it can't be exploited.
An important thing to know is that most automated exploitation techniques are only effective against old and outdated software. It's very rare someone will burn a 0day on the public internet.
My personal recommendations, ordered by importance, sort of, maybe:
- Minimize attack service: don't install it if you don't need it
- Assume you'll be compromised at some point. NSA servers get hacked. FSB servers get hacked. You're not better than them. Think of what you'll do when you get hacked: do you need to rotate keys, change passwords, delete tokens? It's better to have a plan, even if it's a vague idea, just in case.
- Think about who might hack you, and how. Are you an activist? You may have opponents that want to attack you directly. Are you just some guy with a blog? Focus on defending against your most probable attackers, like botnets and automated scripts. You can make grand plans for when the NSA tries to break into your secure server network, but in practice you should probably be fine if you just defend against botnets. You can find entire threat analysis guides on the internet but a quick think about "who will attack me why and how will they do it" will probably do.
- You probably won't get hacked. Don't become too paranoid; just taking the bare basic steps to prevent getting hacked will make you more secure than millions or even billions of hosts on the web.
- Install software in a way that automatic security updates will take care of common vulnerabilities (i.e. prefer apt-install over ./configure && make && sudo make install or curl | bash).
- Check how quickly your upstream sources (Termux, in this case) are issuing patches. I haven't checked Termux' security stats myself, but I'd personally try a Debian chroot over a Termux environment just because Debian has more funds available to provide timely updates.
- Principle of least privilege: barely anything needs root anymore. Ignore outdated guides and use separate users (or even random user IDs with systemd), it'll probably work. If your server provider gives you a root account, create a normal account, give it sudo permissions, and disable remote root login; root should only be for system maintenance and repair!
- Read the manual for suspicious config you copy/paste. Sometimes config is just data (hostnames etc.) but sometimes config disables or overrides default config; for those cases, think "why is this not on by default"
- When in doubt, update. Auto-update if you have to. I've run sudo apt update && sudo apt upgrade -y" in a cron job for years but there are better options for most server OS's. On Ubuntu (and probably Debian) run sudo dpkg-reconfigure unattended-upgrades to configure automatic security updates
- If you do install stuff manually (downloading a binary, curl2bash, etc.) then find out how to update such software and think of ways to automate the process
- Listen to warning messages. For example, many old Ubuntu guides will have you add PPAs in a manner that will give the security keys of a PPA the ability to sign packages from the main system repos. You'll get warnings if you use this method on a modern system and you should probably heed those.
- Reboot your server after important kernel updates. If you can afford the downtime, reboot after every update just to be sure; if you can't, check if any important patches were released during the past few days. You can often monitor the reboot status file (/var/run/reboot-required, for example) to see if a reboot is necessary.
- Make sure your services come back up after a reboot. One of my servers has a nasty firewall configuration bug somewhere that I haven't been able to track down that causes the firewall to refuse to start on boot. Better to find out that your server isn't reboot safe during a planned maintenance window than when you need the service and it suddenly stops working!
- An important file doesn't exist unless it's at three places, at least two which are in a different geographical location. Make backups!
- Test if you can recover from backups. An untested backup is a non-functional backup.
- Back up recovery/security keys to a safe location. Your fancy, unbreakable hard drive encryption is useless if you forget your password!
- When using Docker, make sure to update regularly. It's very easy to deploy a docker application and forget to update it for years!
- Even if nothing is going on, log in every now and then and check how your server is doing.
- Keep an eye on exploit/security lists for software that you expose publicly, especially if you're not updating them automatically. There are websites that will list all important new vulnerabilities for only certain projects (I use the RSS feed provided by the Dutch government, but others likely exist).
- When you see your server might be vulnerable, don't panic. Vulnerability descriptions often start with "an unauthenticated user may execute code and take over the system and turn the sky red and..." and end with "if the administrator has enabled the enable_apple_II_compatibility setting". For example, the Samba/SMB bug that allowed code execution on NAS devices only applied when the optional AppleTalk extension was enabled, which was commonly disabled by default.
Apparently there's a comment size limit, who knew! Anyway, continued:
- Did I mention updating? You'd better update! Did you update? Good, then you're probably fine!
- Install a firewall. The Internet may tell you that you need to learn nftables but in practice tools like `ufw` will protect you just fine. Work in whitelist mode for incoming traffic. Work in whitelist mode for outgoing traffic if you want to spend an hour every week debugging why your server went down again.
- Pick good passwords, or even better, don't use passwords at all. Use key based authentication for SSH, use WebAuthn/U2F/whatever for admin panels, make it as hard as possible to brute force your way in. Don't reuse passwords! You don't want to get hacked because your password showed up.
- Keep an eye on risky software. For example, WordPress itself is quite secure, but many of its plugins have been plagued with vulnerabilities.
- Make maintenance/updating your services easy. Sometimes that means you need to spend more time setting everything up. Sometimes that means configuring your system in a suboptimal way, or even disabling other security features. Locking everything down can make it impossible to properly update your software and software you don't update is just waiting to get exploited by a bot.
- Not a security measure per se, but useful to reduce log spam: change the SSH port from 22 to literally anything else.
- When serving anything UDP (DNS/SSDP/whatever) make sure to check if there's a DDOS potential and see if you can mitigate it. If you can't, see if you can whitelist destination/source IPs in your firewall.
- HTTPS is free and quite easy. Why not enable it? If you turn it on, you can use "outdated" security mechanisms like HTTP Basic Auth without hesitation!
- Make sure to migrate in time when a software package gets out of date. Ubuntu 18.04 will receive updates for years to come, but you should probably plan to migrate two years before the end date. The longer you wait, the more difficult migration will be, the longer you'll put it off and the more likely you'll run vulnerable, outdated software.
- Hack yourself. Run port scans against your own servers; you might just find that you forgot that Docker will bypass your firewall. That's how I found out! I've accidentally had stuff running publicly that should've been private for months because I didn't port scan after installing new software. Other tools include stuff like wordpress security scanners, OWASP ZAP, etc.
- Sometimes you'll find yourself in a tricky situation: one of your services is vulnerable but no update is out for your platform yet. Consider temporarily disabling the service if it's not _that_ important or restrict your firewall to accept only certain IP addresses if you can't live without it.
- If you're only going to use the service yourself, you might not need to expose it to the internet. Maybe you can use a VPN to only allow trusted devices to connect. Maybe you can use Tor to make a service available (from behind NAT, even!). Never fully disable authentication and such on trusted networks unless you don't care about getting hacked, though.
- If you feel like the software you're running may be a common target, read your web server logs. See if you're getting flooded with weird requests and Google the URLs to see if you might be vulnerable.
- Periodically check if software you've installed is no longer necessary. Removing unnecessary attack surface not only makes your server more secure, it'll also help you keep down the amount of maintenance you need to do!
- Install security updates. Really, that's maybe the most important part, after picking good passwords. An updated server is a happy server. In most cases, an updated server is an unhackable server!
- Don't fall for emails like "I found a vulnerability in your server, do you provide a bug bounty".
- If you write your own software, regularly update dependencies and run vulnerability scanners (preferably automated). Stuff like https://owasp.org/www-project-dependency-check/ isn't hard to integrate into your workflow and might warn you of vulnerable libraries you didn't even know you used!
- Terms to throw into Google if you're interested: WAF (Web Application Firewall), Fail2ban, Tarpit (networking), cgroups, systemd hardening, snort, suricata
Finally, for your personal devices: use a password manager with a Really Good master password and enable 2FA. For most services a good password is a password you don't know. Use software that's as convenient to use as possible without sacrificing security (i.e. use a password manager that integrates with your phone's/browser's autofill). Stuff like WebAuthn/U2F/FIDO2 can make 2FA very usable without having to copy a bunch of numbers every time you log in and they're available on more devices than you might think. You can go ultra secure (I, for one, enabled 2FA on SSH at some point) but the harder you make it for yourself, the less likely it is that you'll find yourself using your fancy security.
Some people will probably disagree with me on some points. Some of them are overkill, some of them are not strict enough. There's no one true answer for any of this, because every server is different and has different security requirements.
In case you feel overwhelmed: what I just typed out isn't followed by (way too) many companies. If you work outside a tech company I doubt the IT departments/people even know what company secrets are on what server. Companies will silently or unknowingly run vulnerable software for years without getting hacked! Your home server may be more secure than a critical application server that some Fortune 500 company relies on, simply because you can run updates and they're stuck with some outdated OS/software/hardware/network/configuration that they can't move away from without spending millions!
This is awesome! Thank you
The main advice I'd give is don't follow the steps about port forwarding and public DNS if you are noob. If you are just playing around with things, you don't need to put it on the public internet, you can just access it over your local network none of those concerns really apply. Other than that, update software regularly because that malicious traffic can only hurt you if you are vulnerable. Otherwise it is just noise in your logs.
I have always thought the best possible repurposing project for old Androids would be Mesh routers.
https://rodolphoarruda.pro.br/ideias/#202206MESH (Portuguese)
That sounds like a great idea. That or security cameras.
since, ironically, my old phone has a better camera than most security cameras I've ever seen
You could use PHONK https://phonk.app/ to create a script that runs a web server and combine it with more custom stuff such as Sound, visuals, MQTT, sms, etc etc
Any tips on how to do this without eventually exploding your battery from having it permanently plugged in and under load?
There should be little current through the battery while the phone is plugged in, virtually none if the charger can meet its peak power draw. If degradation over time is a concern (perhaps it boot loops if the battery is very dead), a charge-limiting app set to 50%, the level recommended for storage and used in the Microsoft Surface UEFI Kiosk mode, should maximize life.
If the phone is rooted, you can use Advanced Charging Controller to cycle it between min/max values. That would only prolong it, of course.
https://github.com/Magisk-Modules-Repo/acc
also mentioned at https://news.ycombinator.com/item?id=27576120#27578301
and related https://news.ycombinator.com/item?id=31325191#31325561 (laptop)
Also, an alternative to termux, https://github.com/CypherpunkArmory/UserLAnd found https://news.ycombinator.com/item?id=30119029
Usually these don't like booting without the battery, but maybe there's a way to provide data-only USB connections and a lithium-level voltage internally. Often the early boot stages will interrogate the battery level and refuse to boot if it's too low, but it's very much model dependent.
had two batteries "explode" (ballooned ¹) because of this, then I switched to another phone and knock on wood the battery has not yet exploded (about 2 years).
¹ This is probably why you should not cut off the battery plastic sealing like some DIY guides tell you to do, it's probably there for a reason.
I have a quite kiss solution for this I gess It is a low level / harware solution that should solve th issue : a plug timer (https://www.amazon.com/s?k=plug+timer&crid=3ORDWNDPTFJC4&spr...)
Trades one problem for another. Now you are cycling the battery frequently which is going to do the same thing in the end.
As I understand it it's better to just leave the battery plugged in and floating.
I do that for a charging-station of old phones that I like to keep around for ... things.
> This is probably why you should not cut off the battery plastic sealing like some DIY guides tell you to do
Wait, what? What is the purpose of that advice?
You can leave a phone plugged in all the time with no issues, the same way you can do the same with a laptop or any number of the other ubiquitous USB-chargeable things these days. The only time it's an issue is if the device was _extremely_ poorly designed.
Some good phones will even notice that they are plugged in all the time and drop the charge level to 80%, where most batteries are happiest to stay for long periods of time.
I went the Linux Deploy route and published a couple of container images that Just Work on pretty much any ARM Android device.
Once you shiv systemd, some pretty elaborate scripts can run in an Android chroot just like they would on bare-metal ARM. Just think of your old Android as an off-brand rPi with case, built-in touchscreen LCD, and way, way fewer GPIO pins. No surprise the server will need a new UPS battery.
NextCloudDroid: https://github.com/DesktopECHO/nextcloudpi Pi-hole for Android: https://github.com/DesktopECHO/Pi-hole-for-Android
Doesn't Android's aggressive app sleeping/killing policies (ostensibly to extend battery life) make this somewhat... well if not useless then at least a challenge?
I have a bunch of old Android phones kicking around that I'd like repurpose for random IoT/monitoring things but I don't trust them to stay "on" all the time. And Raspberry Pis are pretty cheap, so...
Raspberry Pi's haven't been cheap for quite a while now.
Or available for that matter
Pi pico £3.46, available https://coolcomponents.co.uk/products/raspberry-pi-pico?src=...
I meant the full sized one, with ports.
Termux supposedly has a setting that prevents that. I haven't had issues so far; I keep long-running stuff like tmux with `tail -f log-file` etc running for literally months.
Just make sure to either set the thing to not go to sleep while connected to a power supply in the developer settings, get a wake lock for your specific application or use another app to keep the device awake. Android phones make for versatile sensor-rich platforms for monitoring/media/etc. applications. They come with their own wifi hotspots, 3/4G communications, several cameras, microphones, motion sensors, compass, gyroscope, light sensors, proximity sensors, magnetic sensors and more. They even have their own built-in UPS so... get hackin'.
Oooh, just saw that someone posted this! Author here. Sad that I missed the action. I'll answer questions if there are any.
This is seriously cool. We should burn through old discarded tech as burner RPIs or something.
Then my cyberpunk dreams can be made manifest!
Just bought my significant other a new Android phone. I carefully picked the right device:
- Lineageos supported
- mainline linux 5.17 supported (except for the camera for now)
Is it a OnePlus device ?
Of all the terrible ideas. Just why? get an orange pi for $50 stick OpenBSD on it. they have usb c input and a metal enclosure.
> Just why?
Your suggested alternative increases e-waste unless one specifically hunts for secondhand chips.
facepalm. you think you’re saving the planet reusing an old cellphone? what about the other 8 billion people who don’t care? it’s just virtue signaling. fantasy. you don’t have a reason just a rationalization. and that’s a problem because it means your logic is frying like an egg on a hot sidewalk
It is well known you can't do a Good Thing if Others don't do it too because it will be inefficient and have no result globally visible. And why Others don't do it? Nobody else is doing it, duh.
I've used a cheap samsung A model to run a complete bitcoin node on. I think i used the ABCore.apk for this...
Anyone know if we can run termux on a Fire Stick?
Yes, as long as you know to install the APK. Just google termux apk.
Not only a web server, it is my personal cloud!
what software are you using?
(2020)
oof rip Windows Mobile OS