I didn’t downvote you, but it’s unclear what you meant by stating that.

Depending on how one interprets it, it can be seen as a justification for using “fascist” (since there isn’t a more accurate word) or simply a way to emphasize that the term is inaccurate and shouldn’t be used.

So I’m not surprised if you get up/down votes from both sides in either direction, specially in a polarizing discussion. Not because of what you said being wrong/right, but because of what they might read between lines.

I’m just calling it a paradox because they are making it less secure by enforcing stricter security.

It’s like how creating stricter regulation against drugs sometimes results in more problems with drugs than when the regulation was more relaxed. To me, that’s a paradox.

Generally, a stricter security policy results in more security, but there are times it gives the opposite reaction when the stricter policy causes a trend that popularizes alternative methods that are actually less secure. There’s always the social factor, and that one is not easily predictable… in fact, it could be that I’m wrong and most devs will decide to register with Google, or simply stop supporting official Android firmware, instead of relying on insecure debug keys. We’ll see.

In theory, it can. One possible reason with Btrfs might be that you are only mounting a subvolume even though there might be other files in the same filesystem (such as snapshots/copies of the subvolume for backup) but that are not being mounted.

Also some tools like gparted do not handle btrfs disk usage very well and will display it as if the whole partition is 100% full.

I feel that the only way out is gonna be using the debug account (ie. the one with the public “androiddebugkey” keyAlias, which the SDK uses for development builds), as this seems to be the only possibility Google is still allowing.

This has the side effect that devs that want to remain Google-independent can no longer rely on the built-in protections in Android which prevents an app from being updated if it hasn’t been signed with the same credentials… but well, that seems to be the only road Google is allowing for anyone who does not wanna register with them.

I mean… the other alternative would be to, essentially, fork Android / expect a custom AOSP to be installed… which might not be an option for all hardware out there.

But the thing is that they are not really making Android more secure with this policy.

They are still allowing APKs signed with debug keys to work… so the only alternative now for any developer that doesn’t want to register with Google is gonna be using those debug credentials to sign their app releases. I expect shipping APKs with debug keys will become more common, resulting in objectively a more unsafe Android ecosystem.

This is not gonna stop rogue APKs from outside Google’s store, it’s just gonna make them less secure, since being signed with a debug key means a malicious APK from a different source can produce another version of the app as an “update” and supplant the original.

This is not gonna stop alternative stores either, in fact, it will make it more important to use stores (as opposed to installing apks from github or so), since at least that way they can still implement alternative methods to check package authenticity before installing, even when using debug keys.

What’s your filesystem?

If you are using something like btrfs, for example, the usage reports can be misleading, and getting the exact size can be complicated… I’d recommend using more fs-specific tools, such as btdu.

That’s why it’s a paradox. They are claiming to do something for security, where in actuality their stricter policies are doing the opposite. This move essentially renders apk’s built-in signing mechanisms worthless. Android is going down the path now of being as insecure as MS Windows when it comes to app installation.

This is not gonna stop rogue apks from outside Google’s store, it’s just gonna make them less secure.

This is not gonna stop alternative stores, it’s actually gonna make them more important for further security checks.

This is not gonna give Google more control over Android, it’s gonna make it easier for abusers to gain control.

I suspect a step Google could take is start adding extra warnings and layers of confirmation when it comes to installing apps making use of debug keys to try and deter users from doing it… but this could then annoy developers, numb users to the warnings, and strengthen the case regarding anti-competitive behavior.

Paradoxically, this move towards trying to make things more secure is actually gonna make things LESS secure.

Because it means that now the only way for people to continue using alternative apps is for them to be shipped with debug keys (the ones used during development) which are fundamentally insecure since they allow anyone to produce an apk and be accepted as a valid update of the app…

You still can release an apk that works by using a debug key… the problem is that debug keys have essentially “public” credentials. Until now, it was possible to use your own credentials and ensure the app is secure by protecting your own keys and credentials, which is what F-droid was doing. Now this no longer is possible. I don’t think this is the end of F-droid, but it’ll be the end of F-droid using mechanisms for verification that used to be built-in on Android.

But I expect F-droid should be able to have it’s own system for verification, before installing, that is parallel and independent of the apk signing process. They could have signatures in a separate file, outside the APK. This also has the additional paradoxical result that in order to ensure that the apps installed are safe, it’s MORE important now to have a store app alternative that you trust and that can implement alternative signing/verification methods.

So… if anything, this move from Google makes Android less secure and makes key signatures within the apks kind of moot for any store that isn’t Google-owned… however, it also means installing a non-Google owned store with some level of security guarantees is much more important now.

I see, thanks for the overview.

If NixOS really does need a community in order for things to work at all, and it cannot be independent from it, then it looks like the moderation team asking for independence is a hard ask. It’ll require restructuring it.

However, with this context it looks to me that what they are asking is not really independence for the moderation team, but independence from Anduril… which are 2 completely different things. The message is misleading.

I get that big projects are not the same, but in my experience there’s always a hierarchy, not a collection of independent bodies (except for fan-made communities that are clearly “unofficial”, those are independent, sure). It’s not unheard of for maintainers at the top of the hierarchy to influence other parts of the organization, like moderation. In fact most open source projects are like that, led by a group of “benevolent dictators”.

For full independence, why not simply detach development from community?

You can even have multiple independent communities with multiple independent moderation teams all about the same software.

As a developer I’ve never needed to engage a particular community on a personal level in order to make a PR to a project… if the technical maintainers want to accept the change, they will, if they won’t then that’s fine, they probably have their reasons. It’s ok to communicate with communities to get feedback, but I’m not making contributions for the social approval, I’m making them when I believe they are useful, and most of the times I write them because I want to have that change myself. If it’s rejected and enough other people are interested in the change, it can be forked. That doesn’t mean I hate the maintainers or that I don’t want the original to exist or anything, it’s not personal.

But well, I understand that some communities wanna make software and they intertwine development and social relationships. However, if you do this then I don’t see how can independence be a thing. Either separate them and don’t intermix them or mix them and don’t expect them to be separate.

Yes, the matter of fact is that the reason why that choice was taken away is because everyone except MS was forbidden from “having” that engine. It might have still been alive today in some form had it not been an exclusive MS-owned thing.

Yes, I understand that. But in my view, Microsoft is the one that might have had “a non Google-reliant engine” (if it’s true that they didn’t rely on Google code).

They just let us use it under their conditions, for the limited time they decided to make it available to us… but it was never “ours”. We were just contractually allowed to use it, but we didn’t really “have” it.

Personally, I think if the engine was closed source, then we didn’t in fact “had that”. Maybe Microsoft had it, not us.

What makes things like chromium, firefox and webkit actual ecosystems is that they at least have an open source basis. Edge isn’t an ecosystem, it’s a black box. We don’t even know whether it’s true or not that it was its own thing or just they sneakily used bits and pieces of chromium from the start anyway.

User Agent checks is the easiest thing to overcome. Had edge’s engine been open source we would have had spins of it resolving the issue within hours. There are many examples of “random developers” succeeding where big companies tied by business strategies (I bet they had business reasons to keep a distinctive user agent) didn’t, to the point that the web runs on servers relying on open source software.

I just wanna say that we have Webkit. After Google moved over to Blink Webkit has not stopped development… and it even has multiple big names behind it (like Apple, but also Valve partnered with WebkitGtk maintainers, and many devices like Amazon’s Kindle are heavily invested on it) so it’s not gonna go away anytime soon. Specially with Safari being the second most used browser on the web, right after chrome and several times more users than Firefox.

On Linux we have some browsers making use of Webkit (like Epiphany, Gnome’s default browser) that are thus independent from Google or even Mozilla. I’m not sure if there’s any browser like that for Windows though.

There’s also Netsurf, they also have their own rendering libraries, but development for it is super slow, I’ve been following them for a couple decades and they still haven’t got a stable javascript engine, so it only works for the most basic of websites. The plus side is that it’s very light on resources, though.

Yeah, that’s why I’m saying that the current solution does not work. It’s why I was proposing a new standard that is enforced by law and that does not depend on subjective definitions of what’s “essential” so anyone who does only want to allow certain purposes can opt in/out of certain cookies without the hassle.

If the comment really does refer to “form factor” and not “OS”, then the comment is irrelevant.

You can also run Android on a desktop form factor, the app would be then technically able to run on “desktop”. The OP’s post clearly refers to the OS, it does not matter what the form factor is, you can even run Linux on the phone (eg. PureOS).

Just note that @RiverRabbits@lemmy.blahaj.zone wasn’t the one who opened the Thread, that’s why they said they didn’t ask the question (I get the feeling there might have been some confusion here :P ).

Still, very informative comment.

@PumpkinSkink@lemmy.world said “reject all”, not “reject optional cookies” or “allow essential”. If the website offers a “reject all” button (which many do, even if that’s not mandated by the law), it actually does reject even the essential cookies. In my experience, the times I’ve chosen to press such button it always result on the banner showing again if you refresh the page.

And “Could be seen as” is subjective too. They could argue that having the banner, even if inconvenient, does not really break the website. They can also easily argue that since the point of the law was to get them to request consent then they are actually being even safer in terms of compliance by asking more.

Also, I still would rather have the possibility of no banners, not even the first time I open the page. The configuration from the browser following the standard could set a default for all websites and potentially avoid the popup to begin with. Then the responsibility would be with the browser, not the website.

I wonder what the balance is for the company…

I mean, it wouldn’t be impossible that they still save money even while paying you more if they have fired more people. If they fire 3 people and hire 1 code-reviewer for double the salary they are still having to pay 1 less wage.