We need more transparency from companies, this time it was a 'bug' that was visible to the end user (hey! who turned on power saving?). Would Google go public if they also develop a 'bug' that is not visible easily by the user or if it was not discovered by anybody but them? Like a 'bug' that changes certs temporarily to intercept your encrypted traffic or uploads random data elsewhere, etc?
You can avoid all of this by using an iPhone. Apple's business model does not involve ad revenue or data collection. Your data is collected but is used purely to improve the iPhone. Your data is intentionally obfuscated for privacy. For an example of Apple's strict policy, check out this article on Apple Maps: https://techcrunch.com/2018/06/29/apple-is-rebuilding-maps-f...
Except this is not really about data collection, but about the other direction: Who can send data to my phone (or other device) I ostensibly own and make it do all kinds of things without my permission - or restrict what I can do with it.
I don't see how Apple is better than anyone else in that regard.
> This is why I've always insisted, for example, that if you're going to start talking about "AI ethics", you had better be talking about how you are going to improve on the current situation using AI, rather than just keeping various things from going wrong. Once you adopt criteria of mere comparison, you start losing track of your ideals—lose sight of wrong and right, and start seeing simply "different" and "same".
It doesn't, monitoring and configuring battery saving is relatively harmless to the majority of consumers. The point that the OP made is that there is nothing stopping them from doing more harmful tests like experimenting with web traffic, running benchmarks or something, tracking app usage in terms of direct relationships (e.g. this person always reads emails, then hacker news, then checks snapchat, then browses these kinds of shopping apps), etc. I'm not saying that these are likely, but when information about specific users drives ad revenue up then it's not much of a leap to suggest they'll collect a bunch of information that people don't want them to collect.
> I fail to see how ad revenue and data collection has anything to do with battery saving mode.
The implication is clearly that someone whose revenue is based on prying on your personal information has more incentive to do things like this than someone whose revenue is not affected by how much they know about you.
Apple's business model heavily relies on planned obsolescence to bully you into throwing away YOUR working iPhone when they've decided its time for you to drop another 700-1000$ by making their latest OS so slow that your phone is essentially unusable. Of course you'll also have to throw away all the expensive accessories you might own because the connection port has changed format too, yet again.
At least on Android I can install a custom ROM, root it, and install a system wide adblocker like adaway. Oh and also my phones cost under 300$ and I can keep them working until I decide it's time to replace it.
Because android works better for me doesn't mean it has to be the same for everyone, but in any case Apple is out to milk money out of you and not to save you from google. Neither companies have your best interest in mind, you're just there to make them money.
> Apple's business model heavily relies on planned obsolescence to bully you into throwing away YOUR working iPhone when they've decided its time for you to drop another 700-1000$ by making their latest OS so slow that your phone is essentially unusable.
Ah. That’ll explain why the 5s - a phone that was released 5 years ago - is still supported with iOS 12.
I am. My partner uses it as her daily driver everyday. I have asked her if she wants to upgrade, but she doesn't see the point as there is nothing wrong with the 5s, which is running the latest release of iOS11.
> Your data is collected but is used purely to improve the iPhone. Your data is intentionally obfuscated for privacy.
As per Apple.
I see no reason to trust Apple any more I trust Google. Especially in the context of Snowden's disclosures of tech giants collusion under the Prism program. What they say is only remotely related to what they actually do.
I'm not sure if it is still the case nowadays, but back when I had an iPhone I remember that Apple had a killswitch which allowed them to remove already installed apps on one's phone.
Nevertheless, I doubt that Apple is more inclined to give away their control of your device. I would guess that they could do the exact same as Google did.
I like that I can put my IPhone in low power mode even if it is at 100 percent. I also like that I can turn off all notifications in one central place. This has helped me lower distractions from the phone. Previously I was on a Nexus 5. Upgrading to newer versions of Android always came with the possibility that my wifi would not work or my cell signal degraded etc.
OP meant why tech savvy people are surprised the Google has the possibility to do such things even though it's obvious they have full control over your operating system.
That is just an illusion ultimately, which you see crack in instances like these. Google play services have system level privileges. If you don't want such surprises, run AOSP.
There's the difference between the possibility of a software update changing settings and "Google has a whole configuration management infrastructure deployed and active and phones polling for new settings so that one slip of a finger can change the settings on millions of phone by mistake"
Thus is the nature of updating settings. Easy mistakes to make include:
* Changing a field's default value (is that even a mistake? users might perceive it that way. Also, is there a difference between a field set to the default value and has never been changed vs a field explicitly set to the default value? Should you change it in the latter case? Did you even track the latter case?).
* Overwriting a field's non-default value and setting it back to default.
* Migrating a field and mapping the non-default value to the wrong non-default value.
* Migrating a tuple of fields to another tuple of fields and getting the map wrong for an edge case subset of the input values (bonus points if that subset was thought to be an impossible state to get into).
etc...
The best way to avoid settings updates it to throw it all on the user. eg, Arch Linux just takes the approach: if, you update a file in /etc, the new file is just created with a special file extension and merging the new and current file is left to the user. You don't get nearly as many surprise updates, but... you spend time merging config files, which few people are willing to do.
That is a combination of different problems. Updates are hard in general, to which there aren't too many mainstream solutions. Emerging ones seem to be in nixos, rpmostree etc. However, ubuntu/debian has a more pedestrian problem, which is that they do a bunch of junk in the post install scripts (like automatically starting and enabling the systemd service for the package). Systemd being a fragile flake will break. That's not the worst that can happen. More likely is that some poor sap will pull in some random server (mail server, database server, http server etc.) as a dependency, and it will get enabled. And ubuntu in their wisdom, don't enable the firewall in desktop variants. So you may be running an open server unknowingly.
In fairness, deleting (even moderately) old stuff from /tmp is a Unix convention that goes back roughly three decades prior to the very existence of systemd. In SCO Unix in the early 1990s, for example, it was the task of the /usr/lib/cleantmp program. AIX had a script, invoked by a daily cron job, called /usr/sbin/skulker that did this and more besides.
Putting stuff in /tmp and expecting it to stick around has been a user and indeed a system administration mistake for all of that time, motivating, for example, warnings like this in Kent's & Williams' 1990 Encyclopedia of Computer Science and Technology (volume 22, "The UNIX operating system"):
> /tmp and /usr/tmp: These directories are used by utility programs to contain temporary files. They are cleaned out periodically, so files should not be stored here.
Que Corporation's Using UNIX and Using Linux both said:
> Because the system automatically deletes the contents of this directory periodically, do not keep anything you might need later in this directory.
15 years before the existence of systemd, Linux Filesystem Structure (later to become the Filesystem Hierarchy Standard) was similarly warning:
> /tmp may be cleaned out at boot time or at relatively frequent intervals. Therefore, data stored in /tmp should not be expected to remain for any long period.
A mere 13 years before the existence of systemd, that warning was made starker:
> Programs must not assume that any files or directories in /tmp are preserved between invocations of the program.
I don't see WHS the the big issue is. Yes my phone went to red battery low power mode. So what? What aspects of this alter contract between me and Google over automatically applied updstes? I gave can implicitly ages ago.
If they involuntarily disabled battery saving and caused me to loose service or drain and reduce battery life i could see an issue.
Truly, bemused at the hate. What did you think the t&c said when you enabled updates?
You've put into words exactly what I was thinking.
From the thread:
"Ok, but how is it that you have the power to control our phones this way? "
Christ buddy. You have a phone thats made by Google. Google, the company that tracks you everywhere and rolls greenfield updates on all their other software. And then this person says they're going to turn 'allow modify system settings' off... What do these people seriously think Google is going to do?
I think people with a Google phone should just implant a chip in their arm, reporting to Google. It's basically the same thing, and you can view your body information on a Google dashboard and get Google advice on health care, along with a Google map to get there.
Except for the 20% of users who feel that Google is not to be trusted and implant an Apple iChip for the premium experience.
In all seriousness, the percentage of people willing to forego using an Apple or Google smartphone (or any smartphone) to uphold at least some semblance of (digital) control over their life sometimes feels so low that it should be called a permillage.
I think the hate is directed more at the general concept here rather than the specifics. What if they'd pushed out an update that silently broke SSL, made all your Google Photos public or started calling people at random, for example? This particular bug is pretty innocuous but the fact that it's possible to push out very obviously broken updates like this (and only admit to it when they're publicly called out on it) could lead to all sorts of issues. It's not like these users were opted in to some kind of "insider" or "testing" builds, after all.
I guess it depends on how you view your phone. Is it your phone or is it Googles phone that they can update with whatever software and settings they want to.
The same debate is around Windows 10. Some people are fine with Microsoft getting a stream of privacy data from them. Others feel it's their device, not Microsofts.
Right. I know, and I run my device this way. But my point was just installing Lineage by itself doesn't free you from Google's clutches if you install GApps anyway.
After my Samsung Galaxy S7 phone started having hardware issues, I looked to see if a phone running open source software was available, one that also could run the Android apps I currently use.
I've had sucess with LineageOS 15.1 on a Xiaomi Redmi Note 5 Pro (codename "whyred"). Unfortunately the phone's LTE bands don't support every country, but it works fine here in India. The phone hardware costs USD 210 and buys a lot of hardware: https://www.gsmarena.com/xiaomi_redmi_note_5_pro-8893.php
The phone comes with Xiaomi's Android fork called MIUI. It comes with the bootloader locked, and Xiaomi makes you wait for about 2 weeks to 2 months to be able to unlock the bootloader to install a different phone OS (called a custom ROM). Until then, one has to either put up with MIUI or leave the phone sitting on a shelf.
Once you unlock the bootloader, you can install LineageOS on it which is fully open source stock Android with some minimal tweaks and extra privacy features. The current version for this phone is 15.1 which is based on Android Oreo. This reminds me of my old Google Nexus 5's phone OS, but it is far more tweakable.
You can build the LineageOS ROM for your phone from source code: https://download.lineageos.org/whyred
I've been running LineageOS (on Nexus 5X, then Galaxy S7, now Nexus 5X again) since it was Cyanogenmod. It pains me to say it but it seems to be getting steadily worse. The first install after the Cyanogenmod fork was perfect for two years until I broke the phone. I then got a Galaxy S7 and it was fine initially but an update introduced a bug which made it drop calls randomly. It took a couple of months of updates not helping before I wiped it and went back to the first ROM which worked perfectly. Now I'm back on a Nexus 5X again and there's an intermittent problem with voice calls where the sound goes quiet/muddy, and just in the past couple of weeks they broke Bluetooth music streaming (the music app crashes and needs to be manually restarted - which is great when you've hopped in the car and started driving!)
When I have time I'm going right back to 14.1 in the hope that that fixes it.
Xiaomi temporarily locks the bootloader to prevent third-party Chinese retailers from bundling malware and adware with its phones sold on the international market[1].
Which is hilariously dumb because now 3rd party retailers are the go to source if you want to buy a Xiaomi with unlocked bootloader rather than waiting a month . It's creating more business for the people they are supposedly trying to stop.
Also none of the stock Android phones they sell have a wait time for bootloader unlocking, it's only the ones with their own os MIUI
Xiaomi doesn't give a shit about the bootloader itself. What it cares about, is people receiving a modified version of MIUI which it has no control over:
"The retailers would buy Xiaomi devices in bulk, unlock the bootloader, change the software themselves or flash a custom ROM like Xiaomi.eu (unofficial ROMs based on MIUI China but with more languages and features), and then sell the device. Most consumers would have no way of knowing they’re running unofficial/modified software, and would instead blame Xiaomi for a lack of updates or bugs they encounter."
>Most consumers would have no way of knowing they’re running unofficial/modified software
It's right there on the boot screen. They can make it more explicit if they want with a red skull or whatever. That reason doesn't fly. Also, what changes in 30 days ?
Xiaomi is primarily a software company, not hardware. It sells hardware almost at its costs, because it treats it as a user acquisition. If a re-seller replaces the official MIUI version with a modified one, Xiaomi loses a customer. Xiaomi doesn't care about Android One phones, and allows them to be unlocked instantly.
I think you are conflating a few different things. That they want you to use their OS is obvious. The 30 day period may even be a wear-you-down period, so that you grow to like their OS. That is quite unrelated to the evil reseller backstory, mainly because the reseller could do that after 30 days too, and if they only wanted to thwart resellers, they could do captcha + ip checks, which they presumably anyway do.
The percentage of people who unlock the bootloader themselves is so small, that Xiaomi couldn't be less worried about them. On the contrary, unlike many other manufacturers, Xiaomi releases the source code and welcomes enthusiasts. The problem is with re-sellers, who unlock the devices in bulk and sell a modified version of MIUI to non-technical people. The longer the unlock period is, the longer the re-sellers have to keep the inventory purchased before they are able to make any modifications. This increases their costs and risks, because they now have to make large investments up-front.
Waiting is inconvenient to buyers and to explain it away, Xiaomi provide some silly reasons such as saying they are trying to thwart sideloading of apps and custom ROMs by resellers, that does nefarious things like steal data... it's a silly excuse, and the wait time inconveniences buyers who want to unlock and install custom ROMs.
Edit: I suspect Xiaomi do this to keep you using MIUI as long as possible because they make money from showing ads in various parts of the system, and also sync your data back to their cloud which probably is resold in some derived form to advertisers. In my opinion, MIUI sucks. MIUI vs. LineageOS proved it is the phone OS (software) which influences how much a person likes a phone, rather than the hardware.
They've recently increased the wait time from 2 weeks to 2 months which had buyers complaining loudly on forums. So for their newest device (the Pocophone) they reduced the wait time to about 3 days. But I think the long wait times still exist for other phone models.
The wait time depends on Xiaomi's mood-of-the-day. They keep fluctuating it.
I'm also using a 'Whyred' (silly name but since Xiaomi used the model name 'Redmi Note 5 (sometimes followed by 'Pro' or 'AI', terms which have different meanings in different countries)' for several different devices it is better to be accurate and use the code name), it offers great hardware for its price (around $180 for the 4GB/64GB model on Aliexpress) and - just as important - runs for 7 days/15 hours of screen-on time on a single charge. I'd just add that once you unlock the bootloader (which can be done in Linux using the java-based MiUnlocktool [1]) you can also de-fang MIUI by disabling all the intrusive bits, installing a different launcher and configuring iptables. Turn on the firewall log to see what tries to get through, you'll notice the thing trying to establish XMPP connections to some Xiaomi-owned domains. After disabling most of Xiaomi's 'services' the log stays empty without anything of value having been lost. This is a good compromise for those who'd rather use stock firmware, albeit de-bloated.
[1] http://xiaomitool.com/MiUnlockTool - make sure to run it on a 64bit machine as the included fastboot binary doesn't work on 32bit installations
LineageOS was working great for me on my Oneplus 3T for about 6 months, but something has gone wrong with recent updates. It has started slowing down to the point of being unusable and I have to reset my phone several times a day. There have been about 6 updates since I started seeing the issue and it hasn't been addressed.
I loathe going back to Oneplus's stock ROM as they modified it to kill background processes to make the phone seem like it has better battery life. I own a Tesla Model 3 and it uses the phone as a key, and the stock ROM doesn't work well with it at all.
They do look at them. But I would suggest taking a quick glance at those logs and see if you notice anything familiar. It may be something you recognize.
LineageOS 15.1 is great, except it STILL doesn't have exchange support, and yes a bug/regression has been logged. That's a pretty big thing to be missing, since all the competitors (Outlook, GMail, Nine) are closed source.
It would take someone with reasonable technical skills to install LineageOS as it involves unlocking the phone's bootloader (depending on the choice of phone hardware), working around any anti-rollback features by flashing, flashing TWRP recovery, and then boot into TWRP and install LineageOS, GApps and Magisk (if you want root). But the OS once installed can be used by all. Take my non-technical cousin for example who looked at what I was doing and bought the same phone and made me put LineageOS on it and now uses it.
It isn't advice or suggestion BTW.. just my experience. :)
Well beyond reason to assume something pedestrian for you - a developer - to be "reasonable skills" for the average Joe.
Do you build your own car? Or bike? Or home? Or even mattress? All of these can be done with reasonable skills, they aren't because you pay for a finished product, in most cases, for the economy to remain productive. No one ever said 'reinvent the wheel' for making progress.
You be ashamed of trying to shame strangers on the interwebs for talking freely!
There's plenty of benefits Google's product offers that lineage doesn't. The surprising thing is, this kind of parameter toggling (turning on battery saver in an OS update) typically happens in non-Google OS-es too. What are you even offering, other than rhetoric, by suggesting lineage as an alt? How does lineage prevent an OS update from toggling a feature - something put in source code.
This happened to me today! I was using my phone and then it went all weird with no haptic feedback when typing. I finally figured out that battery saver was on and disabled it...
This really bothers me... I am starting to think we need a truly open source phone. That is hardware and software. like GNU/phone or something.
We must have full control over our hardware and software!
Viva La Gnu! (no clue what this actually means, but it seemed like the thing to say at this time).
I'm a broken record at this point, but I'll say it again until I'm convinced I'm wrong -- FirefoxOS did great but was tragically mishandled. I'm 100% a FFOS stan (https://en.wikipedia.org/wiki/Fan_(person)#%22Stan%22_fans) but it absolutely could have (and did) work -- they just fumbled the execution and 0 executives took responsibility (as per usual).
While I appreciate Mozilla's recent exploits like the IoT Gateway (https://iot.mozilla.org/gateway/), they should have put all their non-thunderbird non-firefox effort into FirefoxOS, it was a strategic bet.
Please don't remind me, I have PTSD (and like 3 FFOS devices in my closet) from watching it die twice.
Someone posted these up and comers today that look somewhat polished now (versus when I've looked at them in the past):
- Ubuntu Touch[0] seemed like vaporware years ago but seems to be making progress
- Purism is making the Librem phone[1] and it's running F/OSS linux (debian?) underneath, and for some reason they're building their own thing, but it might be awesome as well.
I just want someone to hurry up and add some competition to the landscape already.
Yes, but it is slower, and doesn't allow me to make small payments without the security token. Also, even checking the balance requires the security token with the web portal. Further, I'm sure that many banks don't have their web portal optimized for phone screens (because on a phone you are supposed to use their app).
Once upon a time, your bank probably didn't have an app either -- that isn't a strike against mobile platforms. In that same vein, having a bad web portal isn't a strike against the web as a platform, it just means your bank isn't taking full advantage (yet).
The only strike against FFOS as a platform that you mentioned was speed, and I acknowledge that web-based apps do render slower than native ones 99% of the time. The parser/execution system that handles HTML/CSS/JS is almost guaranteed to be slower than one that can handle a more limited subset (there's just less to do).
That said, speed seems like a red herring though -- just how fast do you need your banking application to be? Is the half-second you had to wait longer to see your balance really the mission-critical feature? I get that rendering speed is important, but there are lots of bloated native apps that don't render as fast as possible either.
I've got two "high street" bank accounts, and one with a fintech startup (starling). My starling bank account is app-only. My high street banks both (basically) require their mobile apps for login to their web portals.
The fact that Google has brought Android to ChromeOS and not the other way around, that Fuchsia is based on Flutter and not ChromeOS UI, and all the corpses of Web based OSes all the way back to Web Widgets Runtime on Symbian is quite telling about the performance of web UIs on phone hardware.
As far as Flutter vs ChromeOS UI, I think it makes sense because of how Flutter works and how much success it's seen being used on android/iOS which reflects how much work they put into it. Flutter literally draws every pixel on the screen, and they put their army of engineers to work on rebuilding native interfaces in android[0]/iOS[1] to replicate their interfaces. The amount of control that flutter gives them is probably can't be matched by any existing widget framework, I don't think anyone's actually done something that crazy yet. Fuchsia is their thing, it makes sense for them to re-use the projects that they find offer the best abstraction for them I don't think this is so much a condemnation of web UIs on phone hardware, they also chose not every other widget/display library in existence.
Also I want to point out that rendering and performance of web UIs could be good on phone hardware, the native implementations just have to want that to be the case. I honestly haven't thought about it deeply, but I also haven't seen a compelling case for why android/iOS's specific markup languages naturally render faster than something that was HTML based -- android/iOS just have subsets of the power HTML offers and that's where the savings is.
[EDIT] - I got what you mean about bringing Android-to-ChromeOS, so removed the section asking for clarification
Flutter original team started with former Chrome engineers and one of the first design decisions was to drop the Web UI concepts.
If I am not mistaken it was Timothy Jordan that explained it on an interview.
So Google, the company pushing Web UIs, including PWAs in collaboration with Microsoft, still thinks they aren't worthwhile to be the default stack on their devices.
Apple and Microsoft also have UI stacks where JavaScript has first class support (TVML and UWP) and like Flutter, completely dropped the DOM.
Just because they decided to drop the Web UI concepts do not mean that what they chose was more powerful or the better decision in general -- it suggests it was the right decision for them.
Also, since when was Google "the" company pushing web UIs forward? Mozilla is that company in my mind -- remember the time when they made a whole mobile operating system based on it, and at the same time tried to push forwards for various parts along (WebBluetooth, other APIs)? That's what investing in the web as a platform looks like. Flutter is successful, but not in a way that plays nicely with anything else -- if you want to push a platform forward or encourage growth, doing things that play nicely with others even if they're less convenient for you is the way to go.
I'd love to be enlightened to what you think is the problem with DOM in particular that makes it not the right model -- TVML and UWP dropped the DOM, but basically replaced them with their own walled-garden re-implementations of basically the same concept. A quick look at the documentation for both and pages like collectionList[0] in TVML and the Getting Started page for UWP[1] look just like shitty HTML.
Ultimately, I can see why they would invent their own UI languages, because it means they don't have an external standard to comply with and can move pretty quickly. I think this is the major reason, not that those other markup languages they created are magically better than HTML's standard. Again, I think this is less of an indictment of HTML than it is companies trying to move as fast as they can without care for interop -- great for them, but probably bad for developers who have to learn all their little languages that are re-creations of an established standard.
> Also, since when was Google "the" company pushing web UIs forward?
Since they introduced JIT compilers for JavaScript, keep spending money pushing forward an operating system that is basically a browser juggler and introduced PNaCL.
> I'd love to be enlightened to what you think is the problem with DOM in particular that makes it not the right model
Rendering performance.
The way DOM semantic works is no match for a composition engine designed from the bottom up for accelerated graphics UI.
DOM is for displaying documents not interactive graphics.
This is also the main reason why Flutter team dropped DOM, at they were hitting the border of what was possible while keeping DOM semantics.
Also why Houdini project exists, but it is far from ever reaching the browsers.
>Also I want to point out that rendering and performance of web UIs could be good on phone hardware, the native implementations just have to want that to be the case.
So that raises the question why Google, the king of the web, wouldn't want it.
I noted this in my other response but since when is Google the king of the web and in what way do you mean that?
Mozilla seems to do the most work trying to move the web as a platform forward.
Flutter is a system that would be impossible to create or fund unless you were at google scale, because it's massively wasteful as an idea -- it's literally a complete rendering engine and widget system built from relative scratch. It offers more flexibility than adhering to any other established UI standard, so I'm not surprised it made sense for them -- surely they can move faster with Flutter than they can by trying to support all of HTML.
There is a cost to using established standards and being held accountable to outside forces, Google just chose not to pay that tax here, which is well within their rights.
I think both Google and Mozilla are moving the web forward. But I'm using "king" as a metaphor for power+money.
No one derives more power and money from the web than Google, and therefore they have a vested interest in keeping the web at competitive levels of performance compared to native platforms.
So if neither Google nor Mozilla can make web rendering as fast as Flutter, then I suspect that there is an inherent technical reason for that and not just lack of want.
That is the real problem I see. The networks and tech required to connect to cell towers are too closed. Even when you do get a open phone going the bits and parts that connect to the network are often small computers themselves that allow very little control.
At least in the US the people sort of own the airwaves, maybe we can push for our government to enforce open protocols for connecting to cell networks?
Isn't that a bit of a marketing issue as well? I am tracking development of Fairphone, puri.sm Librem5 and e.foundation (just released beta version, based on LineageOS). Do you have pointers to the FOSS OS'es you refer to?
the irony that a product which top feature is literally "Does not run Google Android" serves their javascript from google cdn :)
...also the fact that they have boot up sound means that they are not focusing on user experience and needs, but on copying any and all features from the current phones :(
it was a category in their ring tones contest. they have three boot up sounds, which has absolutely no real use.
fun fact, it was originally included in older phones as a marketing gimmick, a way to generate more revenue. someone at nokia or siemens had the idea to sell it to operators the same way as an Ad spot is sold. telco operators paid manufacturers to have their jingle there instead. and in markets without buyers, they put in the manufacturer jingle as a placeholder.
Their site says it runs Android 6.0, and the UBPorts site says Fairphone 2 has random reboots and other issues running Ubuntu Touch?
Have you had successful experience running Ubuntu Touch on the Fairphone 2? I'm ok with occasional bugs, but it needs to be still be reliable as a daily phone.
This looks absolutely amazing -- reasonably ethically sourced and it runs LineageOS. Does anyone have one of these that would care to comment on what ownership is like?
I've been trying to find good reviews and feedback too, but all I can seem to find are people saying it's the greatest thing since sliced bread, or that it's a piece of crap that doesn't even work.
I generally don't trust any review that goes to the extremes like that, as I find it incredibly hard to believe that a device can have such extreme difference of views unless there's bias or intent behind it.
Super keen to hear from anyone who can give me a proper breakdown of pros/cons though. I'm very close to buying one, but I don't have the expendable income to take too big a risk on stuff like this (I know it's always a risk, but still).
The primary issue here though isn't open source vs not, it's how updates and changes are rolled out.
What you're actually looking for is a phone where you manually initiate updates, and where it's guaranteed that change in behavior (e.g. theough experiments) can only be controlled through the device and not remotely.
With OS it's more likely to get that, but not guaranteed.
It won't happen, IMHO. That's because we have a whole pile of.. technologies, that are making good security nearly impossible. So if they want to avoid half of android users getting owned at the same time, they need to be able to push live updates.
Bugs are part of it too (smaller I think), everything is moving fast enough that early reporting mostly took place of extensive testing.
Ubuntu and Firefox tried. I actually bought a phone with Firefox OS when it was released, it was horrible. I don't know if it was the cheap Chinese built ZTE hardware or the OS itself, or a combination of both. But I could hardly get it to boot, and when it actually did, the screen was flickering to death making it completely unusable. Glad it was so cheap, think I have it lying around somewhere though.
I agree with you however. We must be able to have more control over something that has become so personal.
The GP's comment still stands though, it's a dead platform. Mainstream support ends on December 10, 2019, but lots of little things will die as we get closer to that date. Recently the Podcast app stopped letting me add new podcasts with some vague error about being unable to contact Bing. When Microsoft shut down their music service they killed Cortana's ability to identify music playing in the background. Notifications can be hit or miss depending on the app in question.
I went through the same cycle with webOS. What finally did it in the end for me was the browser crashing on about every 6th website I would visit.
Clicked on this expecting it to be something about making sure people's phones didn't die while they were evacuated due to hurricanes or gas explosions. Now I'm curious how the response would have differed had that had been the case.
Great point, I think the response would be very different. It's pretty clear that Google owns android phones with play store and can do as they please with them, you can install new apps using their website ffs, or erase all data on the phone using android/find.
You can't turn off Google Play Services any more. There's no "Disable" button. I use F-Droid apps for everything and have all the Google stuff turned off, but can't easily get rid of Google Play Services.
We need silent updates to be disabled by default until the user opts in, and we need 7 figure bug bounties on any method of bypassing that. We also need a certificate transparency type system for updates so users know whether how unique the update they're being asked to accept is. Otherwise this functionality will be abused for wiretapping purposes.
Set aside for a moment this specific issue (which all in all did not create particular damages), I wonder what is the actual authorization/implementation procedure in a firm like Google to actually push these "potentially destructive" updates (or tests or whatever you call them).
I mean, I imagine that there is a control room where people receive an order by the president, together with a launch code, then an officer in command retrieves the other half of the launch code from a safe he opens with a key he keeps at all times on a chain around his neck, and then two other officers, each one with at least 5 years of service and the grade of captain enter the code and press simultaneously two buttons on two consoles rather far apart.
But I fear that the procedure is much simpler and - theoretically - at the reach of a disgruntled or "gone mad" employee, hired only a couple months before...
If a system setting is changed (in this case, power-saving mode = on) _without_ associated user trigger (UI action), then the system should issue a push notification and prompt for confirmation. That's the right thing to do - for all apps no matter who made them.
Google is so deep-rooted in our life and they are doing it so elegantly without making much noise and the majority of people are least bothered about this. I want Google out of my phone, and I need it now.
What am I going to do about it? Nothing because Google is so convenient.
Backstory: It was created after the death of copperheadOS to fill in the gap. It builds stock AOSP (without any google play blobs), and signs it with your own keys for verified boot. This project is still pretty new, and has some limitations. It builds on aws, whereas I would like to do local builds. Still, a pretty neat and useful project.
Most people buy Google phones specifically because they want Google to remotely manipulate their phones as quickly as possible with the latest Candy-named software. It's an in-demand feature.
> turning on/off certain features without the user's consent.
I think that in practice, that applies to only the privacy sensitive features. Would you be upset if suddenly they rolled out a feature that reduced battery consumption by 10%?
This particular case was obviously a bug, but I suppose every software manufacturer is continuously doing A/B testing, and 99% of time the user would not even notice. I would be surprised if Google was not doing A/B testing, and did not have the whole framework for doing it.
Would you be upset if suddenly they rolled out a feature that reduced battery consumption by 10%?
If you're talking about battery saving mode, I would be upset if they activated the feature (turning it on) without my consent, yes. I don't have issues with Google pushing improvement to their code via OS updates.
I wouldn't be surprised if both Google and Apple could do whatever they want with our phones remotely. It's just that they usually don't, so we never see it.
On iOS, at least, software updates require the user to enter their passcode, to prevent a San Bernardino-type backdoor. Though, I believe there are some assets that can be updated without a full system update.
I don't mean to be a tin foil hat, but I have to ask: How do you know? Do you work at Apple, with this exact thing?
From my perspective there shouldn't be a problem for Apple to have the regular updates work as you describe. And also for them to have an alternative method they can use without any user intervention at all. (Which probably very seldom is used.)
>> That is unsettling that they can remotely manipulate your phone without your permission.
> Did you even read the post? It was a bug... They do A/B testing and experiments all the time. What's up with hackernews and going full technopanic at the smallest most benign things. It's not like someone at Google hacked into your phone and turned battery saver off.
I'm sure he did read the post.
For Google to perform A/B experiments on a random person's phone, they'd have to remotely manipulate that person's phone, which means Google has control of it at all times. They shouldn't even have the capability to perform an A/B test. We're not talking about some webapp running on their servers.
obvious iphone user - google play services has full control of your phone. find your phone on android works because of this. if you don't trust google you CAN use the phone without google play services(you have to jump through some hoops like with everything privacy related)
You don't even need to uninstall it. The permission to modify system settings etc can be set to not allowed in the Google Play Services app info page. So it isn't even surprising that the service can do what it did.
Don't use a Google phone if you don't want to be the product. That simple. Why would anybody trust Google and the Android ecosystem with security in general?
This doesn't address the OP's concerns at all, and how would it be any better? I get wanting to A/B test for apps, but doing so for OS-level features is a bit unsettling.
Is this for real? Was it deleted specifically on Google Photos, with a local copy still available or possibly available if it hadn't already been cleared locally? Or was it a legitimate "reach into local storage and clear it"?
If you lack real control over your device, "absolutely zero proof" is the new normal, and everything that gets zeroed out of RAM is rendered anecdotal thusly.
To help those who may not be able to read between the lines, or know a time before the app store:
Externally initiated and unattended changes to my phone only impact the ability to trust and rely on my phone. This is a battery setting today, but might it be the last thing?
Windows forced updates and reboots come to mind of where we could end up.
Off topic, but Google is getting killed this last week. I was pretty ticked at them ignoring Senator Warner’s request the other day and I think the hearings are usually a public circus. Google is just the most powerful lobbyist in Washington. They face no repercussions for anything.
In 2016, Trump (probably his admin he didn’t know anything) wanted to appoint the most badass anti monopoly czar in America. Probably the most momentous position in recent memory in terms of the future of society. Sounds like I’m exaggerating, but free speech, monopoly, hate speech, income inequality, spying, tracking everything, face recognition, Orwellian themes, and potential usurpation of nation states in favor of data harvesting multinationals was on the line. Google used all their lobbying capital to shut it down. Threatened to nuke every bipartisan bill and every conservative judicial appointment with the congressmen in their pockets. The WSJ had a great expose about this.
In the end the one man who scared the hell out of even Google and was poised to take down uber monopolies like att&t, Disney etc. was passed over for a pushover.
What a misleading, fake title. Honestly disappointing coming form HackerNews... The post quite literally says it's an experiment, accidentally enabled. A bug. Literally an A/B test, which they do all the time.
The title makes it sound like they hacked in your phone. With that logic, any time your apps update or you get a notification, you're getting hacked.
The title is accurate. The Google account linked to says just as much.
> The post quite literally says it's an experiment, accidentally enabled. A bug.
And this can be accurate too, without being in conflict with any claim in the title.
> Literally an A/B test, which they do all the time.
On accounts enrolled into beta programs. Not on regular accounts. This one happened to phones with only regular accounts.
> The title makes it sound like they hacked in your phone.
The title makes it sound — at best — as if it was unexpected. Which it was. The title does not make it sound like they "hacked in your phone". Perhaps you're reading some outrage in the title that isn't there.
You're projecting and reading something that isn't there. How is the title "fake" and "misleading"?
The title is: "Google remotely activated battery saving more on multiple people's phone today", which they did (saw it on my own 2XL). That's it. That's a fact. There's no mentions of Google hacking anybody's phone.
I think Apple remotely activated battery killing mode on mine. The battery was already in bad shape but since this morning it's been ticking down like a clock. It's much worse than yesterday. Anyone else? Am I just paranoid? Seems like an odd coincidence.
This is more like an App (or a JavaScript website on safari) has gone havoc and is draining a lot of power. Look for statistics in power setting to identify a potential culprit. If nothing suspicious an it keep doing after a reboot contact apple support, they have a recall program rolling for some models.
Apps and websites that drain power will be quickly killed by the OS. More likely, there's a system daemon that's running amok, which should usually be fixed by a reboot.
