Google is invested into you having WiFi all the time.
Weirdly, my very old Nexus 6P with the WiFi off, could lie untouched for weeks, with almost no battery depletion. Yet if I turn the WiFi on with near stock Android (meaning no messengers, tens of email accounts, etc, to constantly ping _something_), it just eats the battery within 24 hours tops. Perhaps that’s just the module itself, but I remember flashing LineageOS and having better savings. I have no real numbers to support that right now, although I still have the phone lying around somewhere and could test this some day.
Modern Google Android will use neighbouring WiFi networks to guesstimate your location quickly, so it's scanning even when the toggle says "off" unless you disable it. This location can be queried in the background when nearby devices broadcast the equivalent to Apple's "find my" network broadcasts, because Google uses collected reports of beacons+location to roughly locate tags and such. Opting out of all of that stuff should massively improve standby battery time.
I've also noticed the difference between vendor+custom ROM with a Xiaomi device, which I use as a second phone around the house for controlling smart lights and such. The biggest difference there seems to be that I don't have as many apps installed and as many features enabled, because during active use and shortly after, the battery drains just as fast as (actually a bit faster than) when using the original ROM.
Many custom ROMs (at least the LineageOS-based ones) also don't do thing like configure the country code for the WiFi chip and GPS caches. A large part of the 5GHz spectrum simply doesn't exist (by default) on my custom ROM devices so there's just less to scan in the background.
I have an S25 Ultra with the latest version of Android, and these options don't seem to be there at all. I don't have a "data usage" under Permissions for any apps. I do have a Mobile Data section under App Info for any given app, but there's no way to toggle the options you mentioned.
I strongly suggest you try (the selfhosted version of) Browsertrix from Webrecorder, it's really well done, actively delevoped and can export the website as .wacz without problem.
A detergent probably can. On that will be labeled as shampoo, which is intentionally gentle, to not remove too much oil from your scalp (which causes excessive oily hair, since it's regulated with a feedback system by the sebaceous glands), maybe not.
I think you are confusing testosterone and DHT (dihydrotestosterone), which is a testosterone derivative and is not testosterone itself. Shampoos that contain anti-DHT chemicals like minoxidil can block DHT from attacking your hair follicles but don't eliminate it from the body.
The word "enzyme" comes from the Greek words "en-" (in) and "zymē" (leaven), coined by German physiologist Wilhelm Kühne in 1878 from the German word Enzym.
That link seems to have... an agenda. It's way too hand-wavy (e.g., it doesn't at all attempt to tease out the nuance of whether a rooted phone inherently has a broken security boundary by design, or whether [like on Linux] it's secure as long as the implementation is non-buggy) and seems laser-focused on convincing users that desire sovereignty over their own devices that they might as well jump off a cliff.
As dataflow says that site has an agenda. I've used rooted phones continuously since Android v4 and I've had no trouble. Moreover, I'd posit that much of the crap I remove from phones lowers the attack risk which to some degree offsets the risk of rooting.
Granted, I'm not suggesting that everyone should root their phones, in fact in recent years I even stopped suggesting it to my tech-savvy friends (that is unless they approach me for advice).
I don't need to lecture about these things but all those who've rooted their phones know the huge advantages—power and control one has over one's phone is enormous.
For example, some apps contain so many trackers that normally you'd never use them except they're the only apps suitable for one's purpose. Rooting allows you the user to take control and have them do what you want and not that of the developer.
Yes, rooting has its risks but for my purposes its benefits far outweigh them.
Madaidan's articles are well-known to be centered around "security at all costs", and often at the cost of user freedom. That's just not a realistic take when it comes to privacy. What good is absolute security if all it does is secure the device from your "tampering"? Sure, it would be nice if the device were highly secure, but I'd rather it stop spying first.
With absolute security, you can rest assured that only Google has access to all of your data, and only Google is allowed to turn off the siphoning.
> The term [rooting] generally also includes the functionality for making runtime code patches (eg. with Zygisk) and making runtime filesystem modifications (eg. Magisk modules).
> Out of the many root-enabled apps I've studied or reverse engineered, the vast majority fail to handle arbitrary inputs properly (especially filenames). For example, some root-supporting file managers turn a seemingly benign action like listing a directory into local privilege escalation. This is trivially exploitable, especially with browsers auto-downloading files with server-provided filenames to /sdcard/Download/.
To avoid repeated root access UI prompts, some apps spawn a long-running shell session, write commands to stdin, and rely on parsing stdout and searching for the shell prompt to determine when commands complete. This approach is prone to desync, which can lead to commands being skipped or other inputs being interpreted as commands.
All in all, I simply do not trust most root-enabled apps to not leave a gaping security hole, so I avoid them entirely. There are apps that do handle root access in what I would consider a more proper way, by spawning a daemon as root and then talking to the daemon over a well defined binary protocol. Unfortunately, this approach is the extreme minority.
As someone who cherishes the power of root privs, I'd still like to make a point for alternative solutions that came up like distros such as GrapheneOS or CalyxOS or non-root filtering options via VPN.
If it weren't for backups I could manage my everyday life without root. For all other cases I would root and later unroot my phone via an OTA update :D
https://github.com/schnatterer/rooted-graphene/
Hopefully GrapheneOS deliver on their promise to provide a better backup solutions than seedvault.
> Android’s security design has fundamentally been based on a multi-party authorization model: an action should only happen if all involved parties authorize it.
> these are user, platform, and developer (implicitly representing stakeholders such as content producers and service providers). Any one party can veto the action.
How is this not anti-user? It explicitly states that the app developer should be able to veto my decisions...
Under the shared responsibility model, such veto makes sense. Just because the end-user (the app has no way to determine if it was a thief or a spy or a monkey or the actual device owner) approves of an action doesn't mean the OS and the app have to grant authorization.
I can see how such a setup is hostile to power users, but then Android is used by 50% of all humanity, and your guess is as good as mine as to just how many want "sudo make me a sandwich" level of control.
A crude way:
To watermark:
First establish a keyed DRBG.
For every nth token prediction:
read a bit from the DRBG for every possible token to label them red/black.
before selecting the next token, set the logit for black tokens to -Inf, this ensures a red token will be selected.
To detect:
Establish the same DRBG.
Tokenize, for each nth token, determine the red set of tokens in that position.
If you only see red tokens in lots of positions, then you can be confident the content is watermarked with your key.
This would probably take a bit of fiddling to work well, but would be pretty much undetectable. Conceptually it's forcing the LLM to use a "flagged" synonym at key positions. A more sophisticated version of a shiboleth.
In practice you might chose to instead watermark all tokens, less heavy handedly (nudge logits, rather than override), and use highly robust error correcting codes.
It feels like this would only be feasible across longer passages of text, and some types of text may be less amenable to synonyms than others. For example, a tightly written mathematical proof versus a rambling essay. Biased token selection may be detectable in the latter (using a statistical test), and may cause the text to be irreparably broken in the former.
To handle low entropy text, the “adding a smaller constant to the logits” approach avoids having much chance of changing the parts that need to be exactly a particular thing,
Though in this case it needs longer texts to have high significance (and when the entropy is low, it needs to be especially long).
But for most text (with typical amounts of entropy per token) apparently it doesn’t need to be that long? Like 25 words I think I heard?
What if the entire LLM output isn’t used? For example, you ask the LLM to produce some long random preamble and conclusion with your actual desired output in between the two. Does it mess up the watermarking?
reply