Jump to content

Gigadoc2

Members
  • Content Count

    40
  • Joined

  • Last visited

Community Reputation

44 Excellent

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. In the above I think you forget a very important commercial aspect: Many (most?) apps are sold as 'free' by being infested with ads, and for some by stealing data. That model would not work if people had complete control and could easily remove/block the ads. E.g. by blocking or restricting network access. In that sentence you quote the app developers are the "content providers", so I don't think I forgot them in that part of the post? This is precisely why they have that veto right in the Android security model, so that they can retain control over their content, be it the App itself or some media distributed through it. This is a very good starting point for me to explain why I don't agree with the Android security model. I am pretty convinced that adblocking is not at all stealing: To make things simpler, let's consider a PC and not a phone for the moment. Leaving aside things like the Intel Management Engine or proprietary UEFI firmware, I am very confident in saying that I own my PC. I bought all the hardware components myself and paid with money; no harddrive, CPU or anything else is being indirectly financed by ad revenue, third-party tie-in (I don't own a Nvidia GPU anymore) or something similar. The operating system and browser I use are free software, while I didn't pay for them there is also no expectation that me using this software somehow generates revenue. So up to the Browser, my system has already been paid for in full, and there is no theoretical or practical "debt" that I have to some vendor. Which means, not only should I be in full control of that system, I am (with the above exception to the Management Engine and UEFI). So I can, and do, enact strict control over what my browser does with the data it is being given by external parties, which may include not loading or displaying ads. So there is a conflict: I control the Browser and the OS, thus can block ads (or as I like to view it, decide not to load them). On the other hand, the websites business model might rely on me loading those ads. I totally acknowledge that this conflict exists, but… It's not my task to fix their business model. I might be willing to pay for content that I consider worthwhile (which for most sites is not even an option, because ads and tracking just pay better), but I am not altruistic enough to relinquish control of my systems to the advertisers. And I don't see a moral reason to do so, unless the system is not actually mine. Which leads back to the question about ownership of Android phones. With the PC, the case is pretty clear-cut (well, maybe not if Windows 10 is involved), but with Android phones it is more difficult. At the very least Google is of the position that a phone is not solely owned by its user, and most of the vendors probably agree with this. The Samsung I bought to tide me over to the Pro1 is probably only that cheap because it gets co-financed by ad or cloud services revenue; if I hadn't bought it used anyway I would have probably costed Samsung some money by immediately installing LineageOS on it. And if I am not the sole owner of my phone, then I also see why I should not block ads with it. If the ads are paying for the phone instead of me, then blocking them would indeed constitute stealing. But there is still one problem with this business model, as it is currently practiced. I admit, I just really don't like this kind of business model, where instead of selling full-price devices you sell at a loss and then get that money back via ads or something. Which is at least as much of a reason than the keyboard for me to have bought the Pro1 btw, as fxtec voluntarily renounces their "veto right" on the device. But aside from my personal dislike, I really think that it is misleading to tell your customers that they "buy" a phone, if they in reality don't. If the phone you are "selling" me is not fully financed by the buying price and you thus expect to retain some degree of control over it, tell me outright. Call it "leasing" or something, make it abundantly clear that I don't fully own the hardware, and specify the timeframe for how long you expect to retain control of the device (especially if that timeframe is "forever"). I think Steam is currently facing some backlash in France over using "buying" terminology and imagery when in reality you just lease a game with a one-time lease-fee; this is similar. And when it comes to apps, and how they too are indirectly financed by you not having full control over the device they are running on, I would apply a similar reasoning. It's not the same as with the phones themselves, as we are already not talking about "buying" here, but the app developer still needs to make obvious that in order to use their app, you have to agree to partially hand over control of your phone to them. Currently I see the marketing around smartphones and apps framing everything as being under your (the users) control: Your phone, your apps, your accounts, etc. But it's all leased, the business models all depend on you not having full control over the hardware you hold in your hand. I'm not sure if this is as big of a problem as vendors like to claim, but if this lockdown is necessary for a vendor to save face, then that too should be communicated honestly: "You are not buying this device but are leasing it, because we need to ensure that you can't break it and make us look bad." 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 :)
  2. I'd like to add a bit unto the things @daniel.schaaaf and @tdm already said, with regards to how Google interprets "security". There is a paper by Google employees where they explain the Android security model, it might even be an official Google position (though I am not 100% sure of that): https://arxiv.org/pdf/1904.05572.pdf#section.3 That paper is quite interesting, they include a detailed threat model (which finally explained to me why Google considers a locked bootloader as a critical security feature for regular end-users) and it is not even that old, it refers to Android 9.0. I really recommend the read if you are interested in knowing why the Android ended up being like it is now. But related to this discussion, I want to point your attention to section 3, "THE ANDROID PLATFORM SECURITY MODEL". The first bullet point here is "Three party consent", and it really confirms what @daniel.schaaaf and @tdm have said. So, without much speculation or conspiracy theories, I think I can safely state that Google does not consider you the owner of your phone. "Your" phones ownership is shared between you, the vendor and the content providers (developers). The paper goes on to list more specific examples where this three-party consent is needed (and where not), but the point is: As long as any single action on your phone requires this three-party consent, you can not have root permissions in any way or shape. If you had root, the veto of the platform and the developer would be void. This is why things like SafetyNet exist, and this is why I believe that getting root or installing custom ROMs will become harder in the future, and not easier. Well, getting root or a custom ROM might not become harder, but actually using your phone with full functionality after that will become harder. Look how small the section 4.8 about fast patching is. They acknowledge that updating is an issue and then… do nothing about it. They do list unpatched vulnerability securities in their threat model (T9), but then they only refer to it when talking about how they sandbox apps - they don't really talk about vulnerable OS components AFAIS. But then why can we root? Why can we install LIneageOS and why is so much of Android open source? Well, here my source ends and I start going into conspiracy theory territory. Similar to @tdm, I think this has just been part of the early marketing strategy. I don't know whether Google would have succeeded against iOS without the openness, but there is another possible reason: You can't compete with free. Someone smarter than me (unfortunately I don't know the source anymore) described Android as a "scorched-earth" strategy. You make a great OS, you make it entirely free for manufacturers to use and adapt (it's not even GPL, you can just take the code and run with it), and then promise to support it entirely for free. No way anyone else is ever (for values of ever being 10-20 years) going to make a mobile OS again. Well, there is SailfishOS and there is Ubuntu Mobile, but they exist in a niche as they cannot really compete with Android for the global market. But doing this obviously carries a heavy price, you have to invest all that developer time into your OS and you might not get anything out of it if every manufacturer adapts the OS to their needs (and leaves out the parts that generate revenue for you). So Google left this "hook" in Android to be able to retain control and pull it back into their ecosystem should it ever get out of hand. There is this tiny part which is not free, the App Store (Android Market, later Play Store). Correct me if I am wrong here, but I think the Market in particular has been closed source from day one. The manufacturers would be willing to accept Googles control over the App Store as long as they could still include their own stuff in the OS (and having Googles App Store in there means having access to a lot of Apps to entice customers). Even the tech enthusiasts and free software fans would accept the Android Market being proprietary, as they could easily replace it (and most of the apps you needed back in that time were shipped with AOSP then). So Android gets adopted, and the people get used to the Android Market. Slowly, one after another, Google stops developing the AOSP apps and replaces them with proprietary GApps. The Android Market becomes the play store, the play services become a thing and they slowly incorporate more and more features (as opposed to those features being provided by AOSP). The line between "Features in the new Android version" and "Features in the Play Services for that new Android version" gets more blurred. This is part of Google reining Android back into their control, after they made it popular by making it free. But because of this history, this marketing decision, we have AOSP, we have our custom ROMs and our root. I don't think that Google will ever directly try to prevent rooting Android, or running custom ROMs. But they will (and already do) provide app and device makers with means to do exactly that, and that may get worse over time. Depending on how long the Pro1 will survive in my clumsy hands, it may very well be the last Android phone for me. I could imagine that by the time the hardware is finally to old to keep using, the Android ecosystem will have become too restrictive for me. I'd like to believe that I can run AOSP + open source apps forever, but even the free software apps are depending on Play services nowadays to actually work. Maybe I am being too pessimistic here, but I kind of see myself falling back to a feature phone at some point. Already today I can see practical limitations of open source Android: I can't use a FIDO2 token without play services. Not a big deal right now, but if even Mozilla is relying on the Play Services for functionality as important as website authentication, I see that as kind of indicative as to how things will continue from here. EDIT: Kind of forgot one major point: For me as an open-source fan, the story of Android and how it started open and then got more closed by means of the Play Services sort of taught me: If it is not 100% open, it is not open. As long as there is some closed source part in an operating system, however tiny, as long as it becomes widely accepted it presents a way for the owner to retain control over the rest of the OS as well. Sure, in theory someone could always fork and fix it, but as long as the proprietary version (here, Android + Play Services) remains popular, the fork has to play catch-up with upstream. For a project the scale of Android, that is just not feasible.
  3. Just keep in mind that this app only works because SELinux is not enforcing. Normally apps wouldn't be allowed to do that (side note: why are the discretionary permissions even allowing this?). So when the build goes official, that app won't work anymore.
  4. You are right, I wanted to make that the point of my reply (but somehow forgot to include it): So far I've only seen anecdotal evidence for either claim, and no reliable statistics (and I am not sure how one would get these). So I wouldn't discount it on the basis of stability claims some people made at some time, but rather because it does not fit either SD cards or Android in general (how would you even use its features?). Well, it depends on what you are benchmarking, certain operations will be faster on any COW filesystem (copying, as an easy example), but then random writing will slow down things a lot. I don't think Android will do much random writing to SD cards (it mostly reads what you put on there, right?), but then it will also not do anything where COW is an advantage.
  5. To defend one of my favourite filesystems: I have my daily driver notebook running on btrfs since 2014, fully stable. And the features that the COW nature of it offers are vastly underestimated: You may think about subvolumes and snapshotting them, but did you know that with reflinking you can have snapshot semantics on a per-file level, without any need to create subvolumes? You don't need to think in advance where you want to set the boundary for a snapshot, you just reflink copy the files that you want to "snapshot". Have a huge build tree with icky or non-existent version control where you want to experiment in? Just `cp --reflink` it, the copy won't take more space than the metadata, do your experiment and just move the folder back if you want to revert. No need to create a subvolume first or anything. Oh, and SailfishOS uses it on it's internal storage as well, and my Jolla still hasn't died, despite many many factory resets (which are based on btrfs subvolumes). But… I also wouldn't use it on an SD card. The strict COW nature of btrfs means that at some point you have to defragment (read: fully rewrite) it, and that will kill your SD card, no matter how expensive and high-end it was.
  6. I am really curious to know what the problem was, if it's not too much work to explain 😇 If you're referring to not having LED notifications (except charging), I can confirm. Notification vibration I have though. @Polaris: Just to make sure, you haven't accidentially disabled vibrating notifications? Not only the global setting, but maybe just for the apps you use? Sometimes things can get weird and the default notification channel settings may not be what you'd expect (I know that I had chat notifications for a certain app completely hidden by default, for some reason). Many here seem to find this important, but, just to make sure, you all know that ext4 on sdcards works as well, and it supports a maximum size of 1 Exbibyte (which is most definitively larger than whatever the SD reader of the pro1 accepts)? For me personally the TWRP would be the most important thing. It feels really dangerous switching between branches and cherry-picking patches without having a way to go back (that includes userdata) 😅
  7. So, now that the topic of keyboard mapping has come up here already, I want to add a bit of (what I hope is) constructive criticism. But first off I want to clarify that I am and will stay grateful for @tdms (and mccrearys) work on this port, without which my Pro¹ be not much more than an expensive toy. And, those who do all the unpaid community work (i.e. @tdm) have the right to decide how this project goes, until we start writing patches ourselves we should only offer suggestions. So, here we go: If I understand @Craigs suggestion right, he would have the semantics of the "slanted arrow" keys and the "fxtec logo" key swapped, with the logo key acting as a modifier and the arrow keys not (but instead being shortcuts and/or a standalone key like slash). I see the appeal of being able to remap one of those keys, but I am afraid that for a lot of other people that would greatly diminish the typing experience. The keyboard we have has the shift, "slanted arrow" and even ctrl modifiers on both sides, and that speeds up typing as you can press the modifier key with one thumb and the "main" key with the other. Even with sticky modifiers it speeds up typing, or at least makes it more comfortable. With @tdm having already implemented his idea of an in-kernel key mapping, I feel doubly bad about criticizing it now (please don't take it the wrong way)... But still, I think this is the wrong way forward. I'll leave aside any architectural or idiomatic aspects, as that is in the end only personal preference; instead I want to point out one Feature that this approach conflicts with (as far as I know): The sticky modifiers. If the keyboard is declared to be of type "ALPHA" (i.e. be a thumb-typing keyboard), we get sticky modifiers and auto capitalization (at the beginning of a sentence). Even though the Pro¹ has a large keyboard, it feels more comfortable to me to have sticky modifiers (after all, it is still thumb-typing). Now currently the `Fn` modifier is not sticky in either case, so it wouldn't make a difference whether handled in the kernel or higher up, but I think that this might be something that Lineage or even upstream AOSP is willing to accept a patch for. After all, when even `Alt` is sticky, having `Fn` left out seems like an oversight, or at least something that should be toggleable at build time. If this would be done, the in-kernel mapping of `Fn` would prevent it from becoming a sticky modifier, or the kernel driver would end up emulating the behaviour from userspace (which still would be weird when an app disables the sticky modifiers and then `Fn` is left as the only stick one). To be fair, I also see the point of doing it in-kernel: Apps on Android can not only disable sticky modifiers (example: Termux), they can also choose to disable some modifiers at all (example: the built-in Terminal disables `Fn`). Especially with QWERTZ, having `Fn` disabled leaves one unable to input some (crucial) symbols. Having the `Fn` mapping done in the driver would work around this and present a full ANSI keyboard to every App (so if an App disables even more modifiers like Shift, it would be unusuable even with a full keyboard). I'd personally say the apps should be fixed, but it is possible that many more apps exhibit this behaviour. I suspect that many "remote desktop" type Apps will fall under this category as they will want to pass the modifiers through to the target (which probably doesn't understand the `Fn` modifier at all, or has a different behaviour for it). The only one I've tested so far is "KDE Connect" with its remote keyboard feature, which surprisingly does not try to pass through `Fn` but correctly applies it locally.
  8. Gigadoc2

    Factory Restore Tool

    It's not an intentional option... I don't really know how the SailfishOS porting process is supposed to work, but I have a Jolla and compared some of the things we found out in the chat with the Jolla; and to me it looks like you mostly take the userland from the Jolla, add changes and put that onto the new phone. Now, I don't know how familiar you are with desktop Linux (I have no idea if your interest is mainly Android or Linux in general), but if you are familiar: SailfishOS is very much like a desktop Linux distribution, amongst other things it is using systemd, udev and udisks2. Now it seems that dirty OEM hacks are not only a thing in Android, they seem to be in Sailfish too: Sailfish has modified the udev rules for udisks2 (in /lib/udev/rules.d/80-udisks2.rules), adding rules that automount all mountable partitions from SD cards and USB sticks (to be precise: they add a dependency for that device on an instanciated systemd service which starts after the user session is up (via a dependency) and calls udisksctl as user nemo to mount the specified device). Problem is, they just hardcoded a matching rule which only works for the Jolla itself (or similar phones): It matches every mmcblk device except mmclbk0 (internal storage on the Jolla), and every partition on every sd[a-z] device. To hide the internal partitions on the Jolla, they just hardcoded the same matching rule in the storage settings. What I probably don't need to tell you: The Pro1s storage appears to the kernel not as mmcblk0, but various sd* devices. So, the internal partitions not only show up in the storage UI, the system even tries to mount them all xD That, btw, is also the reason why Sailfish currently can't mount the SD on the pro1, it is instead recognized as internal storage. Now, here is where my knowledge about udev and udisks ends: On desktops, udisks is aware of which drives are internal and which are externally attached drives, but I don't know how exactly. Udisks is meant for users to mount or format their USB sticks and such without needing root rights, but then it does not allow them to do such to internal storage. Now the proper solution would be for Sailfish in general to use that facility and properly mark the internal storage. If that is also done with udev rules, there could be one rule file specific to the device, making it easy to port to different hardware. But I suppose that is something Jolla has to change, so for now the porters will have to do with somehow overwriting both the storage app and the udev rules :(
  9. Gigadoc2

    Factory Restore Tool

    Ok, so the restore-tool sends the idealte-signed (or is it qualcomm-signed?) firehose programmer to the phone, and then communicates with said programmer over USB to send it the stuff it has to flash (or receive whatever it reads), am I getting this right? So in theory, if one were to take the signed firehose from your tool it could be used with the Linaro tool or something similar? And I take it that you don't have the firehose source (and if you had you couldn't sign the resulting binary), but what with the code from cyngn? I suppose you are not at liberty to release the source of it? 😇
  10. Gigadoc2

    Factory Restore Tool

    Yass! Oh, that sounds very interesting! How much is your tool dependent on the NDA stuff F(x)tec gave you? Do you think it is possible to develop something like it as open source, and add reading capabilities to it? I mean, that sounds like a prime way to fully, completely, back up your device :D But apart from that, if you can read flash with EDL, doesn't that kind of defeat locked bootloaders? As in, now I can dump the data from the phone before I tamper with it to get the decryption key? Or is that completely mitigated by a part of the encryption key being stored in a secure element which is not dumped via EDL?
  11. Gigadoc2

    Factory Restore Tool

    It looks like QDL mode is EDL mode -- at least when I put my device into EDL mode it is listed as "QDL mode" in `lsusb`. As it seems the only tool we have for EDL flashing is the one from this thread, you can't really cherry-pick partitions to flash. However, the tool offers the "Base only" option. I have not tried that, but according to tdm's page here, "base only" will keep most of the "high-level" partitions intact, so it might leave SailfishOS mostly untouched. What you can't do in any case is checking which partitions are "corrupt", as far as I know neither EDL nor fastboot allow you to read data, it will only write it.
  12. Gigadoc2

    Factory Restore Tool

    I am afraid that this is exactly what you did 😞 Just yesterday I talked about this with the others in the Chat (not using SailfishOS myself, that's why I didnt find out sooner). It seems that Sailfishs logic what to hide in the UI, as well as their automount logic, is to some extent hardcoded to the hardware of the Jolla (or maybe the Xperia phones too). So all these unformatted partitions are indeed internal partitions of the Pro1... You may have deleted the bootloader, the modem firmware, or similar stuff... At this point, all you can do is to EDL flash, I am afraid 😞
  13. @EskeRahn: I know, that is why, if they have programmed the changes themselves, they may have the rights to open it :)
  14. @Waxberry: Did you (fxtec) program the stock launcher? If so, could you open-source it? That might allow users to improve it or install it on LineageOS and such.
  15. Why is that stored in persist in the first place? Has it something to do with the FDE of stock? Though you'd always unlock before using Fingerprint anyway?
×
×
  • Create New...

Important Information

Terms