[DonHB]

Besides, anyone can load F-Droid or any number of other stores.

Non-GMS appstores exist already for the outliers who want to use them.

Are they actual stores where apps are for sale (other than Amazon)?

[conite]

Are they actual stores where apps are for sale?

Nothing is stopping a developer from having a premium upgrade option from within their own app. Many do.

[DonHB]

Many do, but trial ware requires more work for the developer and some apps don't lend themselves to optional functionality.

[conite]

Many do, but trial ware requires more work for the developer and some apps don't lend themselves to optional functionality.

You're still inventing problems that don't really exist.

[Dunt Dunt Dunt]

You're still inventing problems that don't really exist.

It's the only way he can make things "fit".... by hammering them into place.

[chetmanley]

I've been messing around with an AOSP 11 Sony Xperia 10. I learned that while it isn't rooted, ADB can be used to access the root directory in order to open and modify system files or fully delete system packages. The only protection against this access is when the device is password protected, and USB debugging is off.

So my Xperia on AOSP 11 isn't rooted in the sense that applications can't be given root access, but through ADB, I can control the device. This seems like a good compromise between device security (against malicious apps) and device control for the user.

There must be a way to implement this on an OM Blackberry that would still ensure device security in case they device is lost or stolen, while allowing the owner full control of their devices. Just like Linux distros on servers and PCs. Especially if the device is to be used with an MDM, then that MDM will provide another layer of security whereby it automatically blocks or wipes devices which become rooted.

So I don't see why OM can't do this with their devices. If a device is purchased for personal use, then that owner should be allowed full control of their device - just like any computer. If a Linux or Windows user wants to start deleting system files for some reason...they can fill their boots. But if that device is owned by a company and an MDM is being used, then the MDM will provide protections against root system access and blocks ADB access.

SailfishOS controls root access through a setting which must be activated by the user in the device settings. When active, the user is prompted to create a root password (just like any other linux distro). Then the user can access and modify root system files while using the device. They can then turn the setting back off if they choose.

I believe LineageOS provides a feature in Developer Options which allows the user to enable Root Access via ADB. So it should be technically possible for OM to implement.

Thoughts?

[conite]

I've been messing around with an AOSP 11 Sony Xperia 10. I learned that while it isn't rooted, ADB can be used to access the root directory in order to open and modify system files or fully delete system packages. The only protection against this access is when the device is password protected, and USB debugging is off.

So my Xperia on AOSP 11 isn't rooted in the sense that applications can't be given root access, but through ADB, I can control the device. This seems like a good compromise between device security (against malicious apps) and device control for the user.

There must be a way to implement this on an OM Blackberry that would still ensure device security in case they device is lost or stolen, while allowing the owner full control of their devices. Just like Linux distros on servers and PCs. Especially if the device is to be used with an MDM, then that MDM will provide another layer of security whereby it automatically blocks or wipes devices which become rooted.

So I don't see why OM can't do this with their devices. If a device is purchased for personal use, then that owner should be allowed full control of their device - just like any computer. If a Linux or Windows user wants to start deleting system files for some reason...they can fill their boots. But if that device is owned by a company and an MDM is being used, then the MDM will provide protections against root system access and blocks ADB access.

SailfishOS controls root access through a setting which must be activated by the user in the device settings. When active, the user is prompted to create a root password (just like any other linux distro). Then the user can access and modify root system files while using the device. They can then turn the setting back off if they choose.

I believe LineageOS provides a feature in Developer Options which allows the user to enable Root Access via ADB. So it should be technically possible for OM to implement.

Thoughts?

I agree that it would be most beneficial to many users, like me.

But I think BlackBerry's take was that the switch itself was a potential vulnerability - tiny though it would be. Nor would a company want its users messing with that.

[DonHB]

I agree that it would be most beneficial to many users, like me.

But I think BlackBerry's take was that the switch itself was a potential vulnerability - tiny though it would be. Nor would a company want its users messing with that.

As usual you ignore what was written as suits you. He said that an MDM could be used to disable this feature. And that was the POINT.

[conite]

As usual you ignore what was written as suits you. He said that an MDM could be used to disable this feature. And that was the POINT.

You misunderstand. As I said, I have no issue with it. As a user, I would prefer to have control of that feature.

I'm simply stating how BlackBerry's implementation differed from Knox and why THEY believe their solution was better.

Whether by accident, or on purpose, a company would be none too pleased if one of its users blew the fuse and permanently disabled a company-issued device from being able to access the EMM - assuming the EMM caught the root.

We were asked for our thoughts.

[DonHB]

It's the only way he can make things "fit".... by hammering them into place.

Judging how tech companies are censoring their customers having a third platform option would be very good. For a platform to be viable it needs to be commercial:

• A store where developers can sell their wares without having to each create or choose a payment solution would be a best means to remove barriers to entry.
• Store of this kind could encourage smaller businesses to provide competitive services.
• The store would help to fund continued development of the AOSP fork.
• An API that, as part of the license, includes free use would encourage developer interest (and function as check on the store and the fork developers).
• An API witch is designed for the purpose of device differentiation would also remove barriers to entry.
• AOSP is stepping off (UP) point which is readily available and if utilized can facilitate change of the platform status quo.
• The platform, based on ART, can be established before devices become available, if it it offered in the form of an app store and installs the required libraries to run on existing devices (Google and unGoogled alike). This would further remove barriers to entry.
• Store that sells Google free apps can spur adoption of the platform before devices are introduced and allows devices makers creating GSF free devices time to transition to the platform.

The store could be added later by OM to its devices. The store and AOSP fork can be started by a wholly separate entity or be a partnership among those that started LineageOS, SailFish, PureOS, /e/, etc. This would make it possible to easily find and BUY apps that are Google free. BlackBerry could could have a role by offering its enterprise development tools (and Cylance, etc.) to these partnering companies to qualify apps as part of the process of submitting apps to the store.

[conite]

Judging how tech companies are censoring their customers having a third platform option would be very good. For a platform to be viable it needs to be commercial:

• A store where developers can sell their wares without having to each create or choose a payment solution would be a best means to remove barriers to entry.
• Store of this kind could encourage smaller businesses to provide competitive services.
• The store would help to fund continued development of the AOSP fork.
• An API that, as part of the license, includes free use would encourage developer interest (and function as check on the store and the fork developers).
• An API witch is designed for the purpose of device differentiation would also remove barriers to entry.
• AOSP is stepping off (UP) point which is readily available and if utilized can facilitate change of the platform status quo.
• The platform, based on ART, can be established before devices become available, if it it offered in the form of an app store and installs the required libraries to run on existing devices (Google and unGoogled alike). This would further remove barriers to entry.
• Store that sells Google free apps can spur adoption of the platform before devices are introduced and allows devices makers creating GSF free devices time to transition to the platform.

The store could be added later by OM to its devices. The store and AOSP fork can be started by a wholly separate entity or be a partnership among those that started LineageOS, SailFish, PureOS, /e/, etc. This would make it possible to easily find and BUY apps that are Google free. BlackBerry could could have a role by offering its enterprise development tools (and Cylance, etc.) to these partnering companies to qualify apps as part of the process of submitting apps to the store.

You still haven't said what this new fork of AOSP will do that LineageOS, or GrapheneOS can't or won't.

F-Droid (and other stores) already exist. Having a PayPal button in your own app is utterly trivial. Developers don't really care for more options because they're happy already - as are customers.

[DonHB]

You still haven't said what this new fork of AOSP will do that LineageOS, or GrapheneOS can't or won't.

F-Droid (and other stores) already exist. Having a PayPal button in your own app is utterly trivial. Developers don't really care for more options because they're happy already - as are customers.

As you have acknowledged the Android alternatives have not been successful.

The idea is to create a common source platform which developers can develop for. Sailfish, for example, uses Qt, but it also supports an older release of Android and, I suspect, does not support the UX provided through Qt. Other platforms should be supported with their own user experiences.

The idea is to create an API that would allow developers to support various user experiences with minimal or any changes to their code due to the commonality of the Android runtime underneath. The intention is that an app store would fund the development of the underlying code and APIes (freee use) to fund this. The goal is to also change the existing dynamics of the marketplace. So, it should be possible to have apps from the store running Google free (as much as they can) on Android (TM'd) devices as well.

[conite]

As you have acknowledged the Android alternatives have not been successful.

The idea is to create a common source platform which developers can develop for. Sailfish, for example, uses Qt, but it also supports an older release of Android and, I suspect, does not support the UX provided through Qt. Other platforms should be supported with their own user experiences.

The idea is to create an API that would allow developers to support various user experiences with minimal or any changes to their code due to the commonality of the Android runtime underneath. The intention is that an app store would fund the development of the underlying code and APIes (freee use) to fund this. The goal is to also change the existing dynamics of the marketplace. So, it should be possible to have apps from the store running Google free (as much as they can) on Android (TM'd) devices as well.

Of course the alternatives aren't popular, because the vast majority are perfectly happy with what we have.

Look, what SPECIFICALLY do you want this new OS to DO?

Imagine your mom picking up her phone tomorrow running this OS. What can she DO that she can't today?

[DonHB]

To start there is no OS. The focus is for the API is privacy and security and the potential for less censorship. The AOSP fork may offer an updated ART for those device makers that need it. The OS would come later if there is interest from device makers.

From the software engineering perspective it is just an alternative un-Googled API for use with ART with the focus on allowing as much software commonality as possible that will allow differentiated user experiences. Think something like a fully fleshed out MicroG, but allows for alternative UXes like Silica running on Android. The existing Android development tools should be applicatble.

So, the delivery mechanism would be an app store running on Android (un-Googled or not). This means that owners of existing Android (TM'd) devices can become customers of these developers and allows for device makers to make the API "native".

It would be nice if one differentiated UX (e.g.from OM) is a fully fleshed out Hub. OM could provide certified Android device with this alternative app store also loaded. Other device makers could do the same; even those that are already un-Googled (e.g. Purism).

[howarmat]

I can see another thread getting sidetracked into a useless conversation that goes nowhere…