Pros and cons of rooting

[EskeRahn 5,471]

33 minutes ago, Gigadoc2 said:

BTW, I hope these posts do not come off as aggressive, I really enjoy this discussion. The topics of ownership and control in technology are really interesting to me 🙂

I agree with you to a very large extent The nomenclature of "buying" or "owning" is not exactly describing things accurate. It is a bit like heavy carrier subsidised devices where people 'buy' it but is bound for some monthly rather expensive usage fee. So it is a bit muddy what is the real usage fee and what in an instalment plan purchase.

It is indeed an interesting almost philosophic discourse.

And obviously Google have no interest in us flashing say Sailfish or Ubunto

On the ad-thing I just wish some clever people invented an alternative ad-broker model, where we as user could either pay by seeing the ads or pay the same to NOT see it.
Some system where the page had to display thre price for the page to be displayed clean, and the user could then choose. If cleverly implemented the browser could handle a user selectable triffle limit, that was paid without explicit confirm. Perhaps with some system that allowed you to skip the page within a few seconds without paying. Could be a linear model starting after say 3s, and than growing to the full micro-payment if you look at the page for more than say 15s.
This would handle the very common scenario browsing and skipping wrong google-hits

[tdm 2,322]

5 hours ago, Hook said:

Bingo. 👍

 

Yes, exactly this. Not only is it not my job to support their business model, but (1) their business model costs me money by burning through my limited mobile bandwidth and (2) they let malicious ads that carry malware through, putting my device, my personal reputation, and my financial well being at risk.

 

If the ad ecosystem had stuck with a reasonable number of modestly sized ads and vetted the content appropriately, I would not feel the need to block them.

 

[Benni 184]

@tdm I'm reasonably happy with https://f-droid.org/de/packages/org.blokada.alarm/

[daniel.schaaaf 177]

On 6/24/2020 at 11:54 PM, EskeRahn said:

On the ad-thing I just wish some clever people invented an alternative ad-broker model, where we as user could either pay by seeing the ads or pay the same to NOT see it.

This is possible already now by publishing an ad-supported and a paid version of an app.

My guess is that greed or gold fever makes (many) app developers use the ad model for payment. I also presume that ad networks support greed by promising unrealistically high revenues. Some apps might achieve these revenue numbers, but most probably don't.

I came to this conclusion after encountering countless games that exploit an addiction to gambling and countless apps that are mere copies of other apps. This is furthered by Google not allowing us to filter for apps without ads and in-app purchases. The Play Store only distinguishes between paid and "free" apps. This is how the system works and it is integral to the market. Any improvement for users/customers might destroy the whole business.

[EskeRahn 5,471]

3 hours ago, daniel.schaaaf said:

This is possible already now by publishing an ad-supported and a paid version of an app.

My guess is that greed or gold fever makes (many) app developers use the ad model for payment. I also presume that ad networks support greed by promising unrealistically high revenues. Some apps might achieve these revenue numbers, but most probably don't.

I came to this conclusion after encountering countless games that exploit an addiction to gambling and countless apps that are mere copies of other apps. This is furthered by Google not allowing us to filter for apps without ads and in-app purchases. The Play Store only distinguishes between paid and "free" apps. This is how the system works and it is integral to the market. Any improvement for users/customers might destroy the whole business.

I think you misunderstand the idea. My idea is that the site that gets revenue from showing ads would  get exactly the same micro-payment from me for NOT showing the crap, as they would have gotten from the ad-broker for showing it..

[v6ak 4]

Security of temporary root – it can be actually less secure than having full root. Having a temporary root often means that you have an outdated system with a vulnerability that allows you to gain the privileges. The preconditions for the vulnerability might vary, but in general, this vulnerability can be also used by an attacker that meets the preconditions. If it is enough to just run some app, then the permission system on your phone is kind of gone and you essentially trust any app you download that it will not do that...

[v6ak 4]

On 6/13/2020 at 1:23 PM, VaZso said:

Yes, but for access, I need to use a cable and also it is not a really fast protocol.
Basically Mass Storage mode was a much, much better solution, however, it was crossed through by Microsoft by gathering money on every Android hardware because of outdated FAT filesystem.

Also, they chose not to use a modern filesystem and write appropriate user driver for Windows (as Linux, so basically also Android supports a lot of filesystems, but they are not necessarily enabled under Android), so they designed this MTP thing instead, which would be better it it was non-existent.

Well, while there might have been plenty of reasons, I see some advantages of MTP over the mass storage.

Mass storage provides the SD card (or some other internal memory) just as a raw block device. This has some implications:

1. The other OS needs to understand the filesystem. This limits the choices. FAT32 Is far from being a modern filesystem. ExFAT might not be the preferred way for multiple reasons, including fees and compatibility. (While the compatibility might not be a great deal today, the situation was completely different when Android was introduced, and maybe partially different when the MTP support in Android was introduced.)

2. The OS shall not break the filesystem. Maybe the risk of a faulty FS driver is low, but it is still there and out of Google's control. But this can be more a problem in case of sudden disconnect of the cable.

3. The filesystem needs to be unmounted first. That is, all apps that store their data on the SD card have to stop working with the data. This was especially bad in the early days of quite limited internal memories, as the developers tended to use the SD card a lot.

4. The whole filesystem needs to be unmounted*. That gives Google and phone vendor few choices, all of them are bad:

A. Have a separate storage for basic data (i.e., everything that should remain accessible during the mass storage session) and the data shared with the computer. This also means you need to have some fixed** sizes for those. This was the case of early Android devices. They usually had a rather small internal memory and small (e.g. 2 GB) SD card. Without the card, you were not even able to take photos, so vendors would not dare not to provide any. On the other hand, the card was unneeded for many of us – some of us already had some card, and even for those who had no card, the card was usually too small to be useful.

B. (Actually a special case of A, but it deserves its own point.) The device can have something that behaves as a SD card, but it is actually an internal storage. I have heard of some Android device done this way. But this does not much solve issues of A, moreover, it might make it less intuitive. While most users might understand that SD and internal memory are separate, I wouldn't want to explain the two separate partitions to an ordinary user. You don't have a SD card, you have a plenty of space for photos, but you have no space for a small application.

C. Use a single partition. This would obviously require you to turn most phone functions off during the mass storage session. It would also inherently share all the data to the computer. And last but not least, it would cause issues with permissions. Remember, we probably need to stick with FAT32 or exFAT, so the filesystem doesn't support permissions. But we want to separate the apps from each other, so we need this. Sure, there are some hacks that can be done.

MTP is more high-level, so it doesn't affect the storage layout and doesn't require the phone to be disconnected during the session. I believe the protocol is mostly good, at least the basic idea behind that. The problems are in the implementation:

1. In the initial days, it used to be painful to use MTP from Linux. Today, it seems to work well from both GUI and console.

2. The last time I checked it on Windows, it was quite limited – it was not connected as a regular disk, but the support was rather limited to Windows Explorer or so.

3. I have no idea about situation in macOS.

 

*) You might find some hack that removes this need. However, if the storage keeps it's data undamaged, it is by accident, not by design.

**) Well, you can use thin provisioning to fix this problem, at the cost of some other problems – most notably, you would cause issues with fake free space. Especially the computer would not be able to see it.

[v6ak 4]

On 6/15/2020 at 7:09 PM, zurvan2 said:

OTA Updates are affected, not directly by root, but by other things using root to modify the partitions that the OTA updates would affect. The OTA mechanism is a simple binary diff, so if a single byte is out of place, it would fail. This is done to minimize download size.

While OTA updates are a simple binary diff, the reason is different. With verified boot, dm-verity operates on block level. As a result, changing a single bit, even in timestamp or in unused area, can effectively break the device.

As far as I remember, the size of the binary diffs is actually slightly larger than the size of file-based updates. But doing file-based updates on a storage protected by dm-verity would be very questionable and implementation-dependent.

[v6ak 4]

On 6/15/2020 at 7:09 PM, zurvan2 said:

I totally agree that android would be better off for all users if they adopted a finer-grained permission model for apps. In particular, the one permission that I want to see is a permission for network access. Stupid silly local games have no need for network access, etc. Network access is the one permission that trumps all the others. I don't care if a silly game reads my contacts, as long as it is not allowed to talk to the network.

We saw teases of better permission models in Android for a long time, which to me indicates that the Developers want to add them. The features must keep losing out to other work, though. Apparently adding permissions doesn't make money.

Well, I would also like to have a finer-grained permission model. But we need a reasonable trade-off. If the permission model gets too finer-grained from user perspective, users are not likely to be willing to consider all those permissions.

Not giving the app the Internet permission looks nice, but it would be rather a false sense of security for preventing data exfiltration:

* App can open links in web browser, which usually happens without user's contest. This is enough to exfiltrate some data. And even if there was user contest required, I don't think many people would understand it – even if talking just about the technical people.

* There are many ways to pass the data to some other app that can exfiltrate them. Some are direct, some are rather covert channels, but this is hard to get rid of...

* Even some seemingly innocent permissions can be used for exfiltration, e.g. calendar access. Once the app can add a calendar event, it can also send invitations...

As a result, adding the user contest with the Internet permission could do more harm than good: It could provide rather a false sense of security and just one more dialog to mindlessly allow for most of the apps...

Another example how tricky and counter-intuitive can the permission model be: https://www.davx5.com/faq/wifi-ssid-restriction-location-permission

[VaZso 1,998]

14 hours ago, v6ak said:

Well, while there might have been plenty of reasons, I see some advantages of MTP over the mass storage.

You are right at some points but MTP is very slow and limited for me.
So if they do something, it would be better if they would do it in a right way...

[EskeRahn 5,471]

20 hours ago, v6ak said:

2. The last time I checked it on Windows, it was quite limited – it was not connected as a regular disk, but the support was rather limited to Windows Explorer or so.

Indeed this is rather limited, but a convenient usage of MTP to INCREMENTAL copying files can be found here.

[v6ak 4]

7 hours ago, VaZso said:

You are right at some points but MTP is very slow and limited for me.
So if they do something, it would be better if they would do it in a right way...

You might be right about the performance, I don't use it much. But maybe it is OK for large files, which is probably the main point of MTP for many.

I am not sure how could Google have done better here. UMS and MTP protocols were ready to use. While they could have created a new protocol, it they would need to persuade desktop OS vendors to implement it or to persuade users to install additional software just in order to transfer files.

BTW, according to https://en.m.wikipedia.org/wiki/Media_Transfer_Protocol#Direct_modification_and_partial_transfer_features , Google seems to have added some extensions in order to increase performance in some scenarios. I am not sure how widely are those used...

Also, Google could have stocked with UMS, at the costs I mentioned above.

There are even some wireless option for advanced users. We can install Syncthing. Or we can install Termux + OpenSSH server (+optionally rsync) and use SFTP or rsync...