It's nice that they're testing how new users, preferably those who have never seen a computer before in their lives, react to UIs and how quickly they discover new features.
But what about all the existing users, who know the app and its features and who are really annoyed by these "modern" HUGE UIs that waste 60% of screen space with some jumbotron and hide all other features behind menus (or downright remove them) because "they might confuse new users"?
We need a list of apps that include these libraries and any malware scanner - including Windows Defender, Play Protect and whatever Apple calls theirs - need to put infected applications into quarantine immediately.
Just because it's not directly causing damage to the device running the malware is running on, that doesn't mean it's not malware.
My iPhone occasionally displays an interrupt screen to remind me that my weather app has been accessing my location in the background and to confirm continued access.
It should also do something similar for apps making chatty background requests to domains not specified at app review time. The legitimate use cases for that behaviour are few.
On the one hand, yes this could work for many cases. On the other hand, good bye p2p. Not every app is a passive client-server request-response. One needs to be really careful with designing permission systems. Apple has already killed many markets before they had a chance to even exist, such as companion apps for watches and other peripherals.
P2P was practically dead on iPhone even back in 2010. The whole "don't burn the user's battery" thing precludes mobile phones doing anything with P2P other than leeching off of it. The only exceptions are things like AirDrop; i.e. locally peer-to-peer things that are only active when in use and don't try to form an overlay or mesh network that would require the phone to become a router.
And, AFAIK, you already need special permission for anything other than HTTPS to specific domains on the public Internet. That's why apps ping you about permissions to access "local devices".
Maybe there could be a special entitlement that Apple's reviewers would only grant to applications that have a legitimate reason to require such connections.
Then only applications granted that permission would be able to make requests to arbitrary domains / IP addresses.
That's how it works with other permissions most applications should not have access to, like accessing user locations. (And private entitlements third party applications can't have are one way Apple makes sure nobody can compete with their apps, but that's a separate issue.)
You mean, good bye using my bandwidth without my permission? That's good. And if I install a bittorrent client on my phone, I'll know to give it permission.
> such as companion apps for watches and other peripherals
That's just apple abusing their market position in phones to push their watch. What does it have to do with p2p?
It’s an example of when you design sandboxes/firewalls it’s very easy to assume all apps are one big homogenous blob doing rest calls and everything else is malicious or suspicious. You often need strange permissions to do interesting things. Apple gives themselves these perms all the time.
> That’s the main use case for p2p in an application isn’t it? Reducing the vendors bandwidth bill…
The equivalent would be to say that running local workloads or compute is to reduce the vendors bill. It’s a very centralized view of the internet.
There are many reasons to do p2p. Such as improving bandwidth and latency, circumventing censorship, improve resilience and more. WebRTC is a good example of p2p used by small and large companies alike. None of this is any more ”without permission” than a standard app phoning home and tracking your fingerprint and IP.
Oh, funny you should pick WebRTC. Back when I was still using Chrome, it prevented my desktop from sleeping because 'WebRTC has active peer connections'. With no indication on which page that is happening.
Android is so fucking anti-privacy that they still don't have an INTERNET access revoke toggle. The one they have currently is broken and can easily be bypassed with google play services (another highly privileged process running for no reason other than to sell your soul to google). GrapheneOS has this toggle luckily. Whenever you install an app, you can revoke the INTERNET access at the install screen and there is no way that app can bypass it
I think capability based security with proxy capabilities is the way to do it, and this would make it possible for the proxy capability to intercept the request and ask permission, or to do whatever else you want it to do (e.g. redirections, log any accesses, automatically allow or disallow based on a file, use or ignore the DNS cache, etc).
The system may have some such functions built in, and asking permission might be a reasonable thing to include by default.
Try actually using a system like this. OpenSnitch and LittleSnitch do it for Linux and MacOS respectively. Fedora has a pretty good interface for SELinux denials.
I've used all of them, and it's a deluge: it is too much information to reasonably react to.
Your broad is either deny or accept but there's no sane way to reliably know what you should do.
This is not and cannot be an individual problem: the easy part is building high fidelity access control, the hard part is making useful policy for it.
I suggested proxy capabilities, that it can easily be reprogrammed and reconfigured; if you want to disable this feature then you can do that too. It is not only allow or deny; other things are also possible (e.g. simulate various error conditions, artificially slow down the connection, go through a proxy server, etc). (This proxy capability system would be useful for stuff other than network connections too.)
> it is too much information to reasonably react to.
Even if it asks, does not necessarily mean it has to ask every time if the user lets it keep the answer (either for the current session for until the user deliberately deletes this data). Also, if it asks too much because it tries to access too many remote servers, then might be spyware, malware, etc anyways, and is worth investigating in case that is what it is.
> the hard part is making useful policy for it.
What the default settings should be is a significant issue. However, changing the policies in individual cases for different uses, is also something that a user might do, since the default settings will not always be suitable.
If whoever manages the package repository, app store, etc is able to check for malware, then this is a good thing to do (although it should not prohibit the user from installing their own software and modifying the existing software), but security on the computer is also helpful, and neither of these is the substitute for the other; they are together.
Do you suggest to outright forbid TCP connections for user software? Because you can compile OpenSSL or any other TLS library and do a TCP connection to port 443 which will be opaque for operating system. They can do wild things like kernel-level DPI for outgoing connections to find out host, but that quickly turns into ridiculous competition.
Vast majority of revenues in the mobile apps ecosystem are ads, which by design pulled from 3rd parties (and are part of the broader problem discussed in this post).
I am waiting for Apple to enable /etc/hosts or something similar on iOS devices.
I don’t understand the hatred for select multiple on desktop. It’s a list box that uses standard UI conventions that have been present for three or four decades now.
They're probably referring to it not being usable without keyboard, unlike regular select, or checkboxes, or anything else sans a text field. Specifically, to select elements one by one, you need to hold down Ctrl (on Windows; modifiers for other OSes are different).
For better or worse, this element is not obvious for those who didn't grow up using desktop computers 10+ years ago.
I use it in one place in my app, and even with me putting text right above it saying something like "ctrl+click to select multiple entries", I still periodically get emails from confused users. No idea what the actual % is, but it's gotta be some non-trivial fraction of people who just have no idea how to use that thing.
The thing is, this is a catch-22 problem: if everyone used the default multiple select, people would know how to operate it (and they’d be able to transfer their knowledge from how the control works elsewhere in their os to the web: for example, if you know how to select multiple files in Finder, Windows Explorer or in a open file dialog, it works exactly the same way in the multiple select control). But, because web developers have decided to invent a 1,001 different multiple selects, the default control is inaccessible.
The real issue I have with the web is everyone has broken user interface consistency across the platform with custom web controls where the default controls would be fine.
The trouble with the multiple select is that you have to use it usually when that's what the control is. Users who don't know to control-click can do things like moving files one at a time in the OS, but rarely (never?) is an OS showing you a control like that that makes you use ctrl-click to use it at all, vs. a list of checkboxes or whatever, or contexts like selecting files where you usually can accomplish your goal piecemeal.
I agree that the feature/appearance/accessibility inconsistency you get from reimplementing the controls is a problem, but I think the right way to fix it is to raise that common floor of what the web platform provides. People want, e.g., comboboxes, they've been around forever in UI toolkits, but the web's standard answer for them is still pretty terrible, so it's no surprise that people reach for the libraries that replace the whole thing.
>The company lashed out again in its latest statement, saying it’s “deeply concerned about the safety risks that hardcore porn apps of this type create for EU users, especially kids.”
I like how Apple always conveniently forgets that Safari exists when making claims like this.
What's easier: opening the browser and searching for porn, or installing a third party app marketplace, going into the settings to enable it, finding a .json document for a source that has a porn app and adding it to the app marketplace, then downloading the porn app?
This is what Apple and macrumors users actually believe.
reply