Hacker News new | past | comments | ask | show | jobs | submit | Pesthuf's comments login

The entire EU is in flames ever since they allowed "sideloading". Every device is compromised, people are eating their children to survive.

This is what Apple and macrumors users actually believe.


Looks like the build is even reproducible. That makes me trust Signal even more.

https://github.com/signalapp/Signal-Android/blob/main/reprod...


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"?


You missed a small amount of sarcasm there


"Small" as in "small startup"


I think that was exactly the joke.


Whose urgent warnings on privacy concerns will be ignored by everyone, as usual.


Do third party plugin authors get this privilege, to remove reviews where they deem the mentioned issues solved?


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.


Apps should be required to ask for permission to access specific domains. Similar to the tracking protection, Apple introduced a while ago.

Not sure how this could work for browsers, but the other 99% of apps I have on my phone should work fine with just a single permitted domain.


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".


> other than HTTPS to specific domains on the public Internet

They should need special permission for that too.


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.)


> On the other hand, good bye p2p.

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?


> using my bandwidth without my permission

What are you talking about?

> 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.


Wait, why should applications be allowed to do rest calls by default?

> What are you talking about?

That’s the main use case for p2p in an application isn’t it? Reducing the vendors bandwidth bill…


> 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.

Great respect for the user's resources.


Haha yeah I personally hate WebRTC. It’s a mess and I’ve literally rewritten the parts of it I need in order to avoid it. (Check my profile)

I just brought it up as a technology that at the very least is both legitimate and common.


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


Asus added this to their phones which is nice.


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.


> but that quickly turns into ridiculous competition.

Except the platform providers hold the trump card. Fuck around, if they figure it out you'll be finding out.


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.


Oh, that's an interesting idea. A local DNS where I have to add every entry. A white list rather than Australia's national blacklist.


All of these look so off that I wonder why they even exist.


I don’t really see if there’s now an option to further improve the select with JavaScript to add, for example, a search textbox for filtering.

And what about the nearly unusable (on desktop) <select multiple>?


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.


search textbox: would be supported under the even more customizable combobox element

select multiple: both the enhanced select and combobox plan to support this

Combobox: https://open-ui.org/components/combobox.explainer/

Enhanced Select: https://open-ui.org/components/customizableselect/


How about the literally unusable <select multiple> on mobile? You can't select more than one option on a touch screen...


Seems to work fine on iOS Safari and Chrome


>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.


Both Jobs and Cook have mentioned/acknowledged in interviews that people who want it can use Safari.


Right, because of course children are incapable of browsing the web.


Any teenager looking for porn find a way to gets porn. Nothing can stop them.


Are you not capable of imaging how ease of access and availability increases use?


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?


on my little kids devices, safari is blocked with built in parental controls. this isn't difficult


Built-in parental controls can also block kids from installing apps from alternative app stores.


Consider applying for YC's Fall 2025 batch! Applications are open till Aug 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: