Stallman calls autoupdates a "universal backdoor".
Think of TV remotes. They used to work with infrared. Nowadays, there are bluetooth remotes (not sure how widely deployed they are, but at least some vendors offer them instead of IR remotes). An infrared device can be send only. No way to hack it even if you have an infrared sender in range. The pattern transmitted was quite simple. The bluetooth protocol however requires both sending and receiving ability. Bluetooth stack is in the tens of thousands of lines range. There will be a security bug somewhere...
OpenBSD for instance, was recently discussed on here for dropping a Bluetooth stack over concerns about the correctness of the implementation, and no one has bothered to write a better one.
He's also smart enough to recognize is that most people are going to have someone technically competent in their circle of friends, or within few minutes of walking distance. So people need a set of rights that will allow them to ask or hire someone else to care for their computing. In this sense, Free Software is like Right to Repair - it isn't about making individuals technically competent; it's about enabling local markets of specialists.
We are not talking about patching. We are talking about updating.
> They'd just keep it around unpatched, while connecting it to the network. Is millions of vulnerable devices better than giving vendors of some software the ability to remotely patch their software?
Yes. Vendors do not patch their SW. For the average SW developer fixing bugs is like castor oil. Remember the forced transition from Win 7 to Win 10 when a good OS was replaced by an abomination ? And no, 10 is not better securitywise than 7. There are lot of RCEs in 10. Did you ever play an EA game ? With Origin doing a 4GB update before playing ? On a 25 Mbps internet connection ?
So for me if you have a security patch for your sw i will apply it. Maybe after some buffer period in the case of known offenders (MS) depending on severity. If it's "performance and usability improvements" just forgetit. If you did't bother to write a changelog for your SW i will not waste my time and money (an internet connection is not free ) updating it.
If you had a shower fan/light that broke, and the manufacturer supplied a new model to replace it that had a working fan but no light and also an undisclosed camera and connectivity that sent everything it saw home to the manufacturer, no-one would be debating the situation. People would be going to jail.
No, he's talking about all auto updates. Here's the interview with the quote in question: https://archive.org/details/LundukeHourApril14RMS
https://www.bleepingcomputer.com/news/security/tens-of-thous...
Pinging the IPv6 address from outside doesn't seem to work - I guess there is some sort of firewalling going on.
I mean, if they do, all the better, but my point is that advanced enough tech knowledge should not be a requirement for a safe system.
They re-designed it. When I went to click my usual “schedule payment” button on a bill payment, it just said “Coming Soon”.
I wasn’t a happy person about it.
Big Canadian bank too. US$65b mkt cap.
When I complained 2 years ago about it my banker told me to participate in their feedback program... Now they send me market research polls about future products and features, no way to report usability issues, it's not even run by the bank itself...
Complain about updates all you want but not keeping your bank apps up to date is the wrong solution.
Well then, let me tell you about Toronto Dominion bank (TD, market cap ~$105B)
The app allows you to photograph a cheque to deposit from the app. This option is displayed for their TD USD chequing account.
I scanned a cheque from a US bank in the app (to deposit into my USD chequing account), only to be informed that cheques from US banks cannot be deposited using the app and that I'd have to go to a branch.
The same app is missing transactions and does not correctly display the current balance of some accounts (which are correctly shown in EasyWeb) The app has also blocked screenshots, so I was unable to provide their customer support with proof of the missing transactions.
Call me entitled, but I would expect all transactions and current account balances visible in the web interface to be accurately reflected in the bank's official app.
If you have ever experienced N26, Revolut, or any number of European "FinTech" banks, you will understand that Canadian banks are busy banging rocks together while telling you they're hot shit.
Dunno if Canadian banks would be game for this, but back when AdSense only mailed cheques in US$, and inexplicably refused to e-deposit to my US-based bank account, I’d mail my cheques in.
There’s always more things you can do to a product to improve it for its users.
Another point is the often complete change in UI or app behavior and you only find out about when you want it the least. I once had the case where I came out of a bar in the middle of a cold night, tired, had some beers and just wanted to use my Bikesharing app to unlock a freefloating bike to get home - whilst the app decided that it had to introduce a completely new UI and forced me to take an unskippable "guided tour" through the new features right at the spot.
I'd have to say that most apps now connect to a rather large number of hosts/servers, and it's getting increasingly untenable to not offer users proper control of this. I get that Apple wants to be "friendly computers", but looking at my firewall logs I'm seeing:
- third party audience segmenting - third party analytics - third party static content being fetched - third party ad networks - first or third party generic cloud server connections
I think the attack vector on apps is quite significant if you consider the app itself to have been built to monetize data - there's no outbound traffic filtering to check the system isn't leeching user data and/or device identifiers (the latter getting better and hopefully Apple will require consent soon for the ID for advertisers).
It's trivial to make an app that leeches a user's contacts regularly to a server, then does anything the developer feels like to build a social graph. See clubhouse. I fear the biggest issue for most users' privacy are the "legitimate" apps they use simply not being built with incentives aligned with their interests, and having access to phone home to any server with anything they can access.
Just think through the implications of that phrase for a moment, though. Your own device comes with a built-in mechanism specifically designed for advertisers to track you. Why was that ever a good idea in the first place?
Either there are alternative ways to track a user of an Apple device without IDFA or there are not. If there are, then it is reasonable to assume that unethical advertisers will return to using them if their access to IDFA is gated.
So, whether or not IDFA exists, the only robust way to protect users is to block apps from having access to anything about the host device that implicitly provides a unique method of identifying the user.
This is what other platforms have been trying to achieve. For example, in the web browser ecosystem, software has been restricting programmatic access to features that can be used for fingerprinting or deliberately reducing the level of detail exposed by some APIs.
With control of the entire ecosystem, why is Apple not better placed to adopt this strategy than anyone else, and whether or not Apple is technically capable of achieving the perfect result, how does introducing IDFA make any difference?
I agree entirely - it seems that the solution going forwards is to prevent any access to any kind of persistent identifier that is part of the runtime environment. This might get in the way of some security mitigations (which seem pretty weak to begin with) and some monetisation models (i.e. enabling pervasive tracking across apps), but the end result feels more "clean" and like users would expect - the app runs in a sandbox where there's no access to anything to distinguish the app from any other instance of it.
Clearly keeping this up at the network level is far harder (and some app developers will probably fall back to using the WAN IP and other factors), but perhaps there are even solutions here - perhaps TCP relay servers mix user traffic (while leaving it HTTPS-protected) to prevent services from seeing user IPs, and a virtual network interface internally in the runtime ensures apps only see an IP of 10.0.0.1.
It seems a worthy goal to try to ensuer that runtime environments are indistinguishable, at least to end cross-service ad tracking once-and-for-all. Handling it within apps probably comes down to policy - not sure any technical mitigations can prevent this while apps can remain Turing complete (as they can simply store their own identifier).
That would be premature. Nobody is in a position to know how the "extinguish" portion of the plan will turn out because it hasn't happened yet. All we can say is that the plan looks quite robust in theory and would be a significant coup for Apple if they can pull it off.
Obviously there will always be some unethical operators, but that is true of all major platforms. Apple has the benefit of top-down control and some amount of market incentive to get it right.
> For example, in the web browser ecosystem
...there is precious little to block effective fingerprinting of 99%+ of installs and little prospect of that changing.
Unfortunately to make it work you can't give it network access (easily, at least). But you have a whole host of stuff in /proc and /sys that you also need to block (at least on Android) - there's just too much unique per-device information available to apps. Clearly ensuring runtimes are indistinguishable was never a design goal (as some simple chroot'ing together a virtual filesystem would help to prevent a lot of this, as long as the APIs are limited enough).
But alas, when your phone OS comes from an adtech company, that is probably a hint they are not interested in making it indistinguishable from others.
But there is the iOS sandbox FS. So if an App gets exploited, it can only every leech the data from exactly THAT app. Just the same as an auto-update might just start to leech and upload that data. Given the real-world practices, I think it is more likely an App creator choses to upload the data, than some malicious hacker doing it.
> It's trivial to make an app that leeches a user's contacts regularly to a server
On iOS this is not possible - either the App requests access to the contacts list then I have to consent via iOS sandbox features, or it doesn't get access. And if I didn't give this consent, any security hole that exploits the App will need to get that consent too (at which I will not give it).
I fear however that the majority of "regualar users" are being coerced into giving consent without realising what is happening - seeing the number of people end up in a FOMO-induced panic to join Clubhouse (or whatever the next big popular phone number based app is), a simple "give access to your contacts to invite a friend" masks the fact the app uploads your contacts to the server every time you open the invite tab.
It feels we need to address coercive practices or at least try to do some kind of taint analysis to allow iOS to alert that it believes the memory buffer about to go into a networking API originates from a permission-protected memory buffer, and are you sure you want to let the app upload your contacts... But I suspect we just end up shifting the problem, and they coerce users again, ad infinitum, until they harvest their social graph (illegally, at least in Europe/UK).
The Play Store doesn't give enough information to really judge if the upgrade is necessary.
This separation should be the price of admission for software developers who want to use online updates, and by now there is probably a need for real laws to regulate the industry since firstly it is very clear that it will not regulate itself effectively and secondly it is no longer just random applications but essentials like operating systems, web browsers and even the software controlling your car that are being treated in this cavalier way.
Also it gets very hard for developers to keep track of past versions and apply new fixes to them, when they also have to apply fixes to the new versions.
Then maybe they release too often?
I have been developing software professionally for a long time, much of it code that needed to be high quality. I have never worked on such a team that couldn't keep track of its own software, often over a period of years or even decades, and backport fixes when necessary.
Yes, it's less convenient for the developers than just having a single version that users are forced to update constantly if they want fixes. But it is achievable if you drop the pretence that every minor change in functionality or appearance must be pushed into production instantly through some CD system, which is of course a luxury that only those running hosted software have anyway.
Yes auto updates allow delivery of malware but its not like manual updating was any better. No user was auditing changes before hitting the update.
I'd love for Google to take away the security update channel from the phone vendors and auto-update ONLY security-related things through that.
Microsoft went in hard / aggressively and are forcing update installs and restarts, which IMO is going the wrong direction.
Wasn't there a Linux project where they could update the OS / kernel without a restart? I feel like this is what all OSes should aim for. I like to think Android is going in one direction, moving shared libraries (Play Services) outside of the core OS so it can be updated independently.
Ubuntu? Last time I updated, they asked me if I wanted to start using Livepatch, so it seems pretty integrated: https://ubuntu.com/security/livepatch
(though I'm horrible at noticing the critical battery warnings so I get frequent reboots for free – but that method wouldn't work on Windows which installs updates on shutdown!)
...or because it doesn't justify its right to be there. As a user, the updates mean to me a high probability of getting more bloated, less usable app with important functionality moved or missing. The security implications are abstract. The usability impact is real.
You can turn it off, but you have to dig in settings. During initial iOS 14 setup it has a screen telling you it's turning autoupdates on, but you're not allowed to opt out there.
Unattended upgrades are a remote code execution vulnerability.