Why does that matter if he's not seeing ads. A severely crippled adblocker means that you would see ads during regular usage.
Additionally, Brave a chromium based browser has adblocking built into the browser itself meaning it is not affected by webextention changes and does not require trusting an additional 3rd party.
>I've decided to take matters into my own hands. I am writing a new bus.
Why not reuse Binder which has been to deployed to billions of devices, being a core part of a serious OS, with many many more developers who understand it compared to dbus.
You would probably want to write your own service manager, but you can reuse hardened stuff that already exist.
Yes! Make something built on top of binder, and use something with orders of magnitude more users and developer resources behind it..
> hardened stuff that already exist.
To make it even more hardened(?), Google recently contributed and got merged a Rust implementation of binder for the Linux kernel (and they're apparently planning to eventually remove the old C implementation).
Considering that any new implementation of Binder userspace would realistically also be incompatible with Android Binder, what would really be the gain here? You'd basically have yet another wire protocol that nobody else uses but now also depends on having a obscure Linux feature enabled.
Why would it need to be a new implementation? AOSP is like... right there, and it's not like libbinder has crazy dependencies.
> also depends on having a obscure Linux feature enabled
An extremely widely used and battle hardened Linux feature, though, with corporate sponsorship and active development. With the only real reason it's obscure on desktop linux at all is because upstream blocked it for a long time. If desktop linux embraced it, it certainly wouldn't be obscure anymore, now would it?
Most of binder is in outright Java. Libbinder_ndk is a subset that is unlikely to please anybody. The other libbinder (openbinder) is dead since 2006ish. I actually used this last one in certain commercial product.
> An extremely widely used and battle hardened Linux feature, though, with corporate sponsorship and active development.
Compared to _unix sockets_ , which is the other transport used by almost every other local IPC mechanism, and also what D-Bus uses, there is just no contest. Even Android uses unix sockets more than Binder.
None of binder is in Java. The Java binder code is just JNI bindings to the native implementation.
Things like permission manager are in Java, but that's not part of binder. It's just a service published on binder, and one that wouldn't translate to current desktop Linux anyway.
> Compared to _unix sockets_ , which is the other transport used by almost every other local IPC mechanism, and what both D-Bus, TFA's proposal, and literally any other reasonable desktop IPC proposal out there, there is just no contest.
unix sockets are not an equivalent, which is why protocols are bolted on top to turn it into dbus, etc...
EDIT:
> The other libbinder (openbinder) is dead since 2006ish.
The libbinder I meant is the one in AOSP hence why I said "AOSP is right there":
This libbinder is still way too Java-centric. It can be used from outside, and even slightly reminds me of openbinder (e.g. sp<> https://cs.android.com/android/platform/superproject/main/+/... ) but it doesn't really change the picture much. You have something which smells Java from a mile, and has a lot of other Android-isms to boot, so still likely requires to reinvent a lot of the wheel to actually use it for most desktop programs.
Even the use of C++ is likely to frown many people. (Not me).
That is a java version of a class from libbinder. Having Java and native versions of classes is a common pattern for things meant to be used from both.
No, it is not. It is the Java class which has native methods that call into the C++ version, as someone said above. But it is still primarily a Java class.
The C++ origin of Binder is annoying, but unlike original Binder[1] easily workable around especially given the exact format of messages is left up for implementation to decide outside few standard bits
[1] BeOS, the docs still match what is in Android :D
Not widely known but the original Binder, OpenBinder, was not even for Linux or Android It was developed for BeOS.
OpenBinder was one of the few pieces of code which was open sourced in Be Inc’s dying days just before it was acquired by Palm.
Many of the principal Be developers who worked on OpenBinder, Dianne Hackborn, Jean-Baptiste Queru, et al then moved from Palm to Danger, which was developing Android and which was later acquired by Google.
Which OS? I didn’t get many results for BSD binder. Then I figured maybe you were joking about the “serious” part, so I tried windows binder, iOS binder, didn’t see much…
Including drivers, as since Project Treble, starting with Android 8 all new drivers are required to be userspace, talking with the kernel via Android IPC (aka Binder).
Traditional Linux drivers are considered legacy in Android.
There seems to be a conflict of interest with GNU Guile and GIMP are winning these awards. In the last year there has been a lot of free software related to AI that has been developed along with pushing open source in AI that was more impactful tha than Guile.
I can't speak for GNU Guile, but I wasn't even aware I was in the running for the "Outstanding New Free Software Contributor Award" when I got the email, and I didn't know anyone on the committee. So I don't think there was a conflict of interest.
There's definitely plenty of people out there who were equally deserving of the award!
Internally, it was Embrace, Extend, Innovate, used in an executive memo from 1994 [0].
But it doesn't matter where it originated or who first said it. The reason this phrase gained so much popularity is that outside observers could see that's their strategy was (and still is).
Just the price of the account doesn't mean much alone. The other important factor is how easily the account can get (shadow)banned from the region you are trying to influence. And for the price given we just know it's account. We don't know how sketchy it appears to the provider.
Not all accounts are created equal. For example a verified US account will be cheaper than a verified Japan account because Japan has stricter regulations around phone numbers. And then if you don't have a Japan account you might not be able to reach a potential Japanese audience due to not only antitrust of the platform, but also features that use geolocation for relevance.
That ignores a huge part of how spam detection works. It’s way more complex than buying some accounts.
You’d need thousands of IP addresses / proxies that aren’t flagged and a non suspicious phone number, plus various other signals like browser automation detection and other advanced bot detection.
There’s a reason those Asian spam offices are like slave camps. They use real people because they need to. It’s a whole sophisticated operation.
Take a look at the YouTube algorithm. If those other accounts aren't in the same cohorts as your target audience you aren't going to accomplish much. The idea that accounts are fungible like they were 2 decades ago isn't true.
I am the owner and only user of the computer. Does that mean I should run everything with root? Of course not. It’s simply better to start with little privileges and then elevate when needed. Using any additional privileges should be an intentional act. I also do it the other way: reduce my privileges via sudo -u nobody.
No, you should run every program with only the privileges it needs. The very concept of running your programs with all your privileges as a user by default is wrong-headed to begin with. To strain the "user" model you should have a distinct "user" for every single program which has only the resources and privileges needed by/allocated to that program. The actual user can allocate their resources to these "users" as needed. This is a fairly primitive version of the idea due to having to torture fundamentally incompatible insecure building blocks to fit, but points in the direction of the correct idea.
I have used systemd services before to do this to run an application, I had a user created specifically for the application, and I defined the capabilities the application needed via CapabilityBoundingSet and AmbientCapabilities [0] and I used a lot of stuff from [1] to restrict the application e.g. the sandboxing facilities, restricting the allowed syscalls [2], ...etc. systemd also comes with a useful command systemd analyze security [3]
The root account shouldn't exist either. Having god accounts is a bad idea security wise. Instead everything should follow the principle of least privilege.
The problem is how do you set up those permissions without a god object? How do you fix ones that are broken on a running system?
Ultimately the security systems that introduce high complexity in the name of fine grain permission controls end up being the most fragile and hardest to verify. People get stuff wrong then break it further trying to get their job done. The better system is sometimes the one that doesn’t have all of the features but is comprehensible to humans.
If an app requires a permission, how does OS know that it's OK to grant it? For example, I want to backup my system, so I install app which needs a permission called "bypass any file access control and let me read every file". How does OS know it's legitimate and not malware trying to steal data?
It could be "this requires special digital signature from OS manufacturer" -> then the private key of this digital signature is a "god object"
It could be "this requires confirmation from the physically present user" -> then you basically have passwordless sudo
It could be "this requires users pin/password/biometrics" -> then you have regular sudo
Either way, there is some source of authority in here, even if it's called "root key" or "user pin" instead of "root account".
Let me preface this by saying it is wildly impractical, but you could boot into a separate, minimal OS that mounts your primary OS disk and manages those permissions.
For an extra layer, have the “god mode OS” installed on physically read-only media, and mount the primary OS in a no-exec mode.
Regular OS can’t modify permissions, and the thing that can modify permissions can’t be modified.
It’s too clunky for home use, but could probably be used for things like VM images (where the “god mode OS” is the image builder, and changing permissions would require rebuilding the image and redeploying).
Some BSDs have concept of "securelevel" - a global setting that could be used to permanently put the system up into the mode which restricts certain operations, like writing to raw disks or truncating logs.
The idea is if you want to modify the the system, you reboot into single-user mode and do what you need. It does not start up ssh / networking by default, so it is accessible to local console only.
And of course plenty of smaller MCUs (used in IoT devices) can be locked down to prevent any sort of writing to program memory - you need an external programming adapter to update the code. This is the ultimate security in some sense - no matter what kinds of bugs you have, a power cycle will always restore system into pristine state (*unless there is a bug in settings parser).
>then the private key of this digital signature is a "god object"
You could instead require the app to be part of the OS. The next gotcha would from you I imagine is that the build farm for the next OS update is a god object and at that point I think this is a meaningless tangent. I'll concede and say you have to trust your OS creator. But you always have to trust your OS creator for any OS.
>then you basically have passwordless sudo
If sudo couldn't be used from other programs / she'll scripts and doesn't give access to a god account, but instead did simple things like let you use ping, then that seems fine to me. But why require people to manually wrap programs when it could be handled automatically.
>Either way, there is some source of authority in here
Sure, but it's a system that's much better than sudo.
> the build farm for the next OS update is a god object
This is a very interesting question! It may sound meaningless to you, but modifying firmware images is pretty common when trying to modify locked-down hardware. As in, "I'll unpack the firmware image, set root password and enable telnet, then flash it back". So no, the build farm is not a god object. Whatever controls firmware updates is. Can any app initiate it? Or does it need user's password? Or maybe physical presence? Or a private key that only select people have?
> If sudo couldn't be used from other programs / she'll scripts and doesn't give access to a god account.. But why require people to manually wrap programs..
So, you mean like what "polkit"? This is what systemd is doing - instead of requiring "sudo", commands like "systemctl start SOMETHING" will handle privilege escalation themselves. For example on my computer, running this in terminal pops-up interactive dialog asking for my password. In theory, you can have the whole suite of programs - "secure-cp", "secure-mv", "secure-edit" (see also: "sudoedit"), "secure-find", etc... But it seems pretty wasteful, no? Sure, most common actions (installing/removing apps, configuring networks) can get its own nice privilege-escalating wrappers, but there are many advanced tasks that user can do, and it's much easier to make (and audit) a single "sudo" than hundreds of random scripts.
(Unless you want to have a fully locked-down system where the only OS creator can decide which privileged actions are allowed. Those things exists and are pretty popular: Android and iOS. They are also only usable for a very specific purposes, basically as a remote terminals to server machines running unrestricted OSes without such limitations)
> You could instead require the app to be part of the OS.
That almost sounds like you're advocating for the abolishment of third party or user-made apps that can make changes to the system without the approval of the manufacturer.
This is about being able to read any file on the system including things like the user's bank authentication tokens. No 3rd party developers should be able to read bank authentication tokens. The OS should create a safer API for 3rd parties to use for the use case they want.
Doesn't this just move the bucket: which processes should the OS grant access to that API?
In any case, if the purpose is to make a backup of the system, it seems the possibility to read all and every file as original as possible seems rather critical, in particular if we want to take advantage of e.g. content-based addressing -based deduplication in the backup application. And we in any case want to restore that backup to an empty computer, so there really are no places to hide the encryption keys in such a way that they cannot be read from the backup.
Have you ever tried to fix an application that was getting denied based on SELinux policies? It's a cryptic nightmare. You run a tool that gives you some magic string and hope that it works because nobody really understands what's going on. If that doesn't work you're in a world of pain. Almost as bad as Microsoft's ACLs.
If you have a privilege to replace the kernel or bootloader, you effectively have all privileges on that system. Therefore, there's no need to complicate the access limitations when you get full access anyway.
You should read over NIST 800-53 AC-2 and AC-6. They go over why privileged accounts are important, why they are used, and how they protect users and organizations.
I'm not saying there can't be an admin who can create roles, or do some extra authentication to gain that privilege. I am saying that it shouldn't require assuming an all powerful user to do it. You should be able to do it from your actual account. This is good for keeping accurate records too since all actions are done by the users themselves. Yes, technically sudo can be logged, but it's bypassable by starting a shell.
You could own a microwave, but there doesn't have to be a button that makes it run with the door open. The UI of devices doesn't let just anything happen. Similarly an operating system doesn't need to make accessible a way to do everything to the user.
> You could own a microwave, but there doesn't have to be a button that makes it run with the door open. The UI of devices doesn't let just anything happen.
And where is the UI capability that prevents microwave users from putting liquids (e.g. grape juice) that generate plasma storms inside the microwave and often result in fires? Or, as a bonus, crinkled foil.
To state the matter bluntly – the entire diatribe concerning the system’s role in defining capabilities is as constructive as insisting that every computing device and appliance on the planet must implement B2-level RBAC and capability-based controls – an argument so unmoored from practical reality that one wonders whether its proponent has ever been burdened by implementation.
The UI is missing because the law doesn't require it. That's why it's possible to by tablesaws without a SawStop like safety mechanism despite it being superior to have (ignoring price). Some people will choose the cheaper and less safe option because they don't value safety as much.
> Similarly an operating system doesn't need to make accessible a way to do everything to the user.
Then who is it available to, if not me, the owner of the computer? What if the operating system isn't doing the things it should that I don't have access to? Do I have to bring it to someone and beg them to fix the computer for me?
I instinctually agree with nkrisc, but this is an interesting line of thought.
What's an example of something that nobody should be allowed to do e.g. on a laptop? If I buy a system with OS stuff set up from the get-go. What abilities do you withdraw from the user?
Yea I do. I use it for programs where I’m unsure whether it will read or modify my filesystem. I still allow the program to run arbitrary computation and use the network. It’s just the filesystem part that I want to isolate.
I feel like using "Cosmic Rays" as a reason is equivalent to "Aliens". It makes for good clickbait so everyone is fast to point at it as the reason even if there is no reason to actually believe that the bitflip was due to cosmic rays.
> even if there is no reason to actually believe that the bitflip was due to cosmic rays.
What if there is reason to consider it as it is actually a known, proven, observable phenomenon, especially one with greater likelihood/intensity as you climb in altitude, like planes do, and that likelihood/intensity also scales with solar cycle intensity, which we are currently experiencing the peak of?
Or perhaps you think the Aurora Borealis are because of Aliens too?
It did not. The article itself acknowledged that there is certainly reason to consider it a possibility, predicated on the fact that the people that make the thing stated as such and that experts in the field agree it's also a risk in general, but wasn't particularly high that day.
Average activity is not no activity. Average risk is not No risk.
And even if it wasn't the issue in that instance, it's not hard to reason why it's worth hardening against such a possibility in the absence of any other explanation given just days later "sensors mounted on UK weather balloons at 40,000ft (12km) measured one of the largest radiation events to hit Earth in roughly two decades."
Airbus didn't ground these plains because there was "No reason to believe" a known proven and observed phenomenon might have been the culprit and/or that it is on the level with something we as yet have no proof of to be generous in characterizing your comparing it to aliens.
When you do Raman spectroscopy in a lab the software literally has an automatic cosmic ray rejection mode because for autonomy you are very likely to get cosmic ray initiated return signals over the course of a couple of hours.
"If the signal looks amazingly strong but unexpected and sharp, it's probably a cosmic ray" was what I was trained for.
Thank you for bringing reason to this topic where everyone is losing their mind when it comes up. Cosmic rays are sexy, They're sciency, but they're not a good explanation when you actually run the math.
Random but flips are pretty much always bad hardware. That's what the literature says when you actually study it. And that's also what we find at work: we wrote a program that occupied most of the free ram and checked it for bit flips. Deployed on a sizeable fleet of machines. We found exactly that: yes there were bit flips, but they were highly concentrated on specific machines and disappeared after changing hardware.
> I feel like using "Cosmic Rays" as a reason is equivalent to "Aliens".
This is actually a thing. Cisco had issues with cosmic radiation in some of their equipment a few years back. Same symptoms: random memory corruption, and when they would test the memory everything would check out, but once in a blue moon, the routers would behave erratically.
In practice such an event is rare, and I would expect there to be enough shielding to avoid it from interfering with the electronics. The fact that there is no hard evidence is why it's hard to argue against this clickbait claim, since technically they could be right.
The cosmic radiation that reaches Earth's surface consists mainly of particles that cannot be stopped by thin shields (e.g. muons or other particles with very high energies), otherwise they would not have passed through the atmosphere.
So shielding is not a solution that can be applied in a vehicle. You need something like an underground bunker to be sure that no cosmic radiation can penetrate it.
The only reason that makes rare the events caused by cosmic radiation is that if those particles can pass through shields that means that in most cases they will also pass through the electronic devices without being absorbed and causing malfunction.
People can self sabotage by choosing a bad theme, and then they engage with the app less or even churn. Designers need to be careful to not give people rope for them to hang themselves with.
> Designers need to be careful to not give people rope for them to hang themselves with.
No, they don't. It's my system, and the look should be what I want it to be, period. What designers actually need to do is learn to respect their users, even when they disagree with the user's choices.
My teenager has their cell phone keyboard configured so all the symbols are replaced with cartoon cats. They can't type properly on it at all - I get text messages that are completely garbled - but they love that they can do this even though it actively impairs their functionality.
Some people like having ridiculously long fake nails that make it difficult to do their jobs (i'm thinking some checkout clerks I've seen who can't properly push any of the keys on their terminal), but it's their choice.
Certainly that's a good reason to force a legible version of settings, and the path to settings...
But if the user sets the system to hot dog stand, the apps should be hot dog stand. If the user wants the system text font to be wingdings, they're in for a nasty time, but that doesn't mean an app should force a different font
The issue with this thinking is that it's easier for people to quit using the product than to figure out how to fix the font. You can't beat the simplicity of doing nothing, so you need to avoid getting into this state in the first place.
Gotta keep users engaged in your app, right? Keep them onboard even if that means removing all their choices. I mean, should we even allow users to uninstall apps?
After all, the developer always knows best and all users are helpless children who need to be forced to conform and comply. Who cares what the user thinks or wants so long as we keep that sweet, sweet engagement.
If your users are not engaging with your app, you can't deliver user value to them. If you are unable to provide value to their lives because they happened to accidently changed a font that is an unfortunate circumstance where the user is losing out on value they could have had.
It's not that users are helpless, but that they just don't want to spend their time dealing with stuff they don't want to. Users like it when things "just work."
There is nothing wrong with providing sensible defaults and a good collection of pre-designed profiles to choose from (and yes, even a big, friendly RESET button).
But that doesn't explain taking away options. Users who don't want their time with this stuff would probably not use the customization options in the first place.
Also, the term "deliver value" has been badly tainted after too many companies have used it as an euphemism for "extracting value".
It's the same non-logic that advertisers use: Ads are both a service for the viewer, informing them of amazing opportunities, but also somehow the viewers must be forced into consuming that service.
I'm deeply skeptical of situations where people have to be forced into something "for their own good".
Targeting users who enjoy debugging and troubleshooting software is not the way to develop high quality software. You shouldn't be purposefully adding bugs or corrupting installations just to give people problems to figure out.
Nobody said anything about "purposefully adding bugs or corrupting installations".
What you're advocating is protecting the user from themselves, which is antithetic to the entire ethos of the hacker.
Yes, you as a developer shouldn't fuck up the user's setup. But if the user fucks it up on their own? Then that's on them. Don't limit the power users because you want to infantilize the casual users.
> and then they engage with the app less or even churn
I wasn't aware engagement maximisation is the reason we don't get customization options anymore, but it makes perfect sense.
No one used to care about this because it was at the discretion of the user whether they want to keep using the app or not. Whereas today, it's the company objective to keep the user in the app as much as possible.
I remember the miniform of media players. Because while you need the full interface while managing playlists, you only need a few button and some status when you’re playing music. I don’t think Spotify will ever implement that feature.
The colors is part of the content of the product. And it's not that it is 100% more likely for someone to leave sooner, but that it increases the probability that people leave sooner.
That’s clearly bullshit because
if the user sets a system wide theme and your appLICATION follows that theme, then your appLICATION is not going to be any harder to use than the system itself nor any other appLICATION using native widgets.
What is actually happening is designers are forcing non-native controls, in part because web technologies have infested every corner of software development these days. Unsurprisingly, those non-native widgets break in a plethora of ways when the system diverges even marginally from the OS defaults.
And instead of those designers admitting that they fucked up, they instead double down on their contempt for their users.
Also, can we please not call desktop applications “apps” in response to an article about an OS that predates smartphones by several decades.
This sounds much like a post hoc justification for having not bothered to go to the effort to implement the ability to allow anyone (power users or otherwise) the freedom to customize the "app" to their liking.
reply