Most active commenters
  • Wowfunhappy(7)
  • saagarjha(4)
  • AnthonyMouse(3)
  • Spivak(3)
  • dumpsterdiver(3)

←back to thread

1183 points robenkleene | 55 comments | | HN request time: 0.002s | source | bottom
Show context
3pt14159 ◴[] No.24838967[source]
This is one of those tough cases where software cuts both ways.

Some people are smart, informed developers that install a trusted tool to monitor their traffic and have legitimate reasons to want to inspect Apple traffic. They're dismayed.

Most people are the opposite and this move protects the most sensitive data from being easily scooped up or muddled in easily installed apps, or at least easily installed apps that don't use zero days.

Is the world better or worse due to this change? I'd say a touch better, but I don't like the fact that this change was needed in the first place. I trust Apple, but I don't like trusting trust.

replies(19): >>24838993 #>>24839043 #>>24839086 #>>24839126 #>>24839194 #>>24839419 #>>24840315 #>>24841406 #>>24841984 #>>24842961 #>>24843115 #>>24843241 #>>24844017 #>>24844287 #>>24844319 #>>24844636 #>>24845405 #>>24845660 #>>24845932 #
Wowfunhappy ◴[] No.24838993[source]
If I install Little Snitch, it's because I trust Little Snitch to be responsible for my computer's network traffic, over and above anyone else.

I recognize that this won't necessarily apply to all users or all apps, but there needs to be a way for the user to designate trust. Apple services and traffic should not get special treatment.

replies(3): >>24839030 #>>24839084 #>>24842512 #
1. coldtea ◴[] No.24839030[source]
They provide the OS. If you don't trust them, then you shouldn't trust anything running on top of it either...
replies(15): >>24839099 #>>24839130 #>>24839176 #>>24839223 #>>24840636 #>>24840860 #>>24842029 #>>24842089 #>>24842540 #>>24842969 #>>24843232 #>>24843903 #>>24843921 #>>24844882 #>>24845297 #
2. Wowfunhappy ◴[] No.24839099[source]
You could (and perhaps would) make the same argument about Intel (for providing the processor) or Broadcom (for providing the wifi chip) or Comcast (for providing internet service). And it's true, all of these parties have the ability to use their positions for nefarious purposes.

However, I would like to limit that potential as much as possible, partly by creating a stigma against practices that remove control from the user.

replies(1): >>24840224 #
3. paulryanrogers ◴[] No.24839130[source]
Right, but many users want to delegate trust to more than just the OS vendor.
4. whimsicalism ◴[] No.24839176[source]
I don't understand these style of responses. I think the point is that this "feature" makes the OS shittier.
replies(1): >>24841005 #
5. AnthonyMouse ◴[] No.24839223[source]
> If you don't trust them, then you shouldn't trust anything running on top of it either...

Trust, but verify.

The problem with this is that it's taking away the ability to verify. Which takes away the ability to trust.

6. LocalH ◴[] No.24840224[source]
I find it interesting how the needs of legitimate security mesh so well with the industry desires to kill off general-purpose computing for the majority of users
replies(5): >>24840678 #>>24841760 #>>24842599 #>>24843104 #>>24844722 #
7. Spivak ◴[] No.24840636[source]
This really isn't about trusting Apple, this is about trusting Little Snitch. I don't think it would be a good decision to allow any app to control your firewall, but I should be able to say "this app should be allowed to because I trust it."
8. Spivak ◴[] No.24840678{3}[source]
I mean the irony is when it comes to browsers you see the general tone of HN shift to the opposite opinion when it comes to features like, RTC, USB, Bluetooth, Filesystem Access. These are all features that give users more power but it's (apparently) easier to see the downsides and how these features can and are used maliciously.

Now put yourself in the Apple's position where "an iOS app" or a "mac App" is about as trusted as a random website. Tech people have a strong culture of locally installed apps being extremely trusted but that doesn't extend to everyone. Can you imagine if websites could control your firewall?

replies(3): >>24841039 #>>24842844 #>>24843471 #
9. mdoms ◴[] No.24840860[source]
I trust my friend Mike to drive me to the pub. I don't trust Mike to be the executor of my will.
replies(1): >>24842315 #
10. coldtea ◴[] No.24841005[source]
For the average user who expects to be able to block malicious traffic via something like Little Snitch, but still expects their OS updates, App Store, etc to work, or for someone who "knows better"?
replies(1): >>24841047 #
11. Wowfunhappy ◴[] No.24841039{4}[source]
> I mean the irony is when it comes to browsers you see the general tone of HN shift to the opposite opinion when it comes to features like, RTC, USB, Bluetooth, Filesystem Access.

I don't think it's that ironic. From my vantage point, the big tech companies specifically and consistently invoke the security arguments that are best aligned with their agendas.

• We need to enforce automatic Windows 10 updates to keep your computer secure. (But also, we won't let consumers use the security-patches-only LTSC branch we offer businesses.)

• You cannot install an app on your iPhone that we have not personally vetted. (As part of the vetting process, we enforce a 30% cut on all digital goods.)

• We need to hide URLs in Chrome to protect users from phishing websites. (But isn't it nice how it makes AMP more seamless?)

• We need to give browsers Bluetooth and USB access, because web apps are safer than random Windows executables. (But also, we can advertise inside of web apps more easily.)

I could go on. The problem with all of these arguments is that they aren't wrong so much as they're selective. The iOS App Store does protect users from malware, and hiding URLs does protect users from phishing. What goes unacknowledged are the trade-offs of these decisions—some of which may themselves be bad for security.

replies(2): >>24841429 #>>24842102 #
12. Wowfunhappy ◴[] No.24841047{3}[source]
The average user isn't using Little Snitch. And if they are, the app provides default profiles for this sort of thing.
13. GekkePrutser ◴[] No.24841429{5}[source]
Also, they lock the user in to the corporation's choices. Most of these don't even have a way to bypass them for knowledgeable users.
14. mlindner ◴[] No.24841760{3}[source]
There has always been a tradeoff between security and freedom.
15. flower-giraffe ◴[] No.24842029[source]
> If you don't trust them, then you shouldn't trust anything running on top of it either...

You start with trust, if you attempt to verify that trust by examining behaviour and discover a covert side channel surely you can no longer trust.

16. kbenson ◴[] No.24842089[source]
It's not about trust that they aren't doing something malicious, it's about trusting them to provide the level of attention and work required to keep something very secure.

A kernel and the core OS capabilities are a high security domain and I expect Apple to be extremely careful and put a lot of attention into making it secure. Desktop applications are a different domain where security is not quite at the same level and Apple will not and can not provide the same level of security for all of them that it can and does provide for the base OS.

As a simple example, compare Safari and the OS. The domains in which they operate make it extremely hard, if not impossible, for Safari to have the same level of security as the OS and kernel because the use case of Safari opens it to far more attack vectors.

Does anyone believe that exempting all Safari traffic from firewalls would be a good idea? If not, then why should we accept that it's a good idea for some arbitrarily set of other Apple applications?

The issue here is simple, it's the same as it always is with Apple. There's a choice to do the thing that's slightly more complex and requires users to provide even a minimal amount of input that they might have to think about ("An application is attempting to change the traffic flow required by X service, if you allow this it may cause problems with this service. Yes/No?"), but instead they opt for "Users must trust us implicitly and entirely in everything we do", which is their go-to solution. It all comes back to control, does Apple control the user, or the the user control their software? Apple has built their empire around the former, so while we can't expect the latter without if being forced on them, that doesn't mean we shouldn't.

17. tpxl ◴[] No.24842102{5}[source]
>hiding URLs does protect users from phishing

Real question: how? I would expect it to be the opposite, a perfect phishing site will have the wrong URL.

replies(2): >>24842215 #>>24842238 #
18. Spivak ◴[] No.24842215{6}[source]
Because it's not really "hiding the URL" despite what all the outrage bloggers tried to make it seem. It's by default (i.e. until you tap/click it) hiding the parts of the URL that the site controls. So paypal.amazon.citibank.scamsite.biz/secure/login/trustus will just show scamsite.biz.
replies(4): >>24843638 #>>24843674 #>>24843710 #>>24849799 #
19. greycol ◴[] No.24842238{6}[source]
google.com.evilwebsite.example?=google.com

Oh that has google in it (twice even) we can go there.

There's also arguments that URLs are too complex for normal people to understand.

I agree with you though, hiding or redirecting URLs is the opposite of protecting users from phishing.

replies(1): >>24843762 #
20. Wowfunhappy ◴[] No.24842315[source]
And also, you might be uncomfortable if Mike blacked out all the windows.
replies(1): >>24842668 #
21. Sporktacular ◴[] No.24842540[source]
Trust but verify. Now we must do the former without being able to do the latter.
replies(1): >>24842595 #
22. DiederikvandenB ◴[] No.24842595[source]
You can very easily monitor all outgoing traffic through an external device.
replies(2): >>24842680 #>>24906738 #
23. heavyset_go ◴[] No.24842599{3}[source]
As is usual, this is something Stallman had touched upon years ago[1].

[1] https://www.gnu.org/philosophy/can-you-trust.en.html

replies(1): >>24843891 #
24. ◴[] No.24842668{3}[source]
25. Wowfunhappy ◴[] No.24842680{3}[source]
You can’t filter per-app, however, which is a key selling point of Little Snitch.
26. AnthonyMouse ◴[] No.24842844{4}[source]
> Now put yourself in the Apple's position where "an iOS app" or a "mac App" is about as trusted as a random website.

The mistake is in creating a category called "iOS app" or "mac app" and trying to fit every piece of third party code in the universe into that category.

What there should be is different categories of apps with different levels of trust. Then 95% of apps can go in the totally untrusted category because they don't actually need any special privileges. Which then makes asking for a trusted privilege a red flag rather than something the user clicks through because they see it for every app they install.

> Can you imagine if websites could control your firewall?

Realize that this has already happened. You wanted to block DNS to untrusted servers so everything would have to use your Pi-hole? Say hello to DoH. You could block AOL Instant Messenger by blocking port 5190, good luck doing that with Facebook.

The web made every protocol run over HTTPS to bypass your firewall, even if it has nothing to do with transferring hypertext.

Because that's what happens when you do security wrong. It has to be usable or it gets routed around. People started blocking unknown ports by default, or blocking/mangling protocols both of the endpoints didn't want blocked or mangled, so firewalls got displaced.

You don't actually want that to happen (again). You don't want the only options to be living in a cage or rooting your device with some unaudited 0-day code you got from some Russian hackers. There is value in the existence of the middle ground.

27. gowld ◴[] No.24842969[source]
Their software could have bugs, or be compromised.
28. dwaite ◴[] No.24843104{3}[source]
As a general rule, you want to prevent software from bypassing a user's informed consent. Apple typically does this in one of two ways:

1. Have functionality only accessible through system frameworks, so that the OS can be responsible for prompting for informed consent and granting it to a process. This means that the system itself has to have functionality to prompt for that informed consent in a way that users can understand.

2. Require processes which an application cannot script that are technically complicated enough that users might realize they are pulling off the warranty-voiding stickers. A prime example would be rebooting into recovery mode to turn off system integrity protections via a terminal command.

Both of these wind up getting gated in priority, but such is the priority of their system - limiting the ability of arbitrary software to act as an unrestricted agent of the user so that user security and privacy (as well as device operation like battery life and radio reception) can be protected.

replies(2): >>24845331 #>>24848124 #
29. abhinav22 ◴[] No.24843232[source]
Great comment - agree 100%
30. dumpsterdiver ◴[] No.24843471{4}[source]
> Can you imagine if websites could control your firewall?

Oh, they can. Cross-site scripting and request-forgery attacks aren't dead yet thanks to widespread terrible security practices :)

31. ◴[] No.24843638{7}[source]
32. dumpsterdiver ◴[] No.24843674{7}[source]
My first instinct was to distrust the hide-until-click URL bar also, but you've illustrated clearly why it's a reasonable default. It mitigates the effect of malicious websites playing URL games, and allows the browser to more accurately convey to the user where they really are.
33. dumpsterdiver ◴[] No.24843710{7}[source]
To drive your point home, paypal.amazon.citibank.scamsite.biz/secure/login/trustus will likely have a perfectly valid certificate, along with the trusted green closed-lock before the URL, implying that the site is "secure".
34. pdkl95 ◴[] No.24843762{7}[source]
> google.com.evilwebsite.example?=google.com

This was solved a decade ago by rendering the 2nd+1st level domains (and sometimes other parts of the URL) in a different style.

> There's also arguments that URLs are too complex for normal people to understand.

That argument is an insulting attempt to justify a form of illiteracy[1]. Most people don't need to know all of the technical features of a URL; they just need to be able to use it as an address and recognize basic features like the hostname.

Street addresses are a good analogy. Most people understand the basics easily even though physical addresses are far more complex[2] than URLs!

[1] https://news.ycombinator.com/item?id=7694919

[2] https://news.ycombinator.com/item?id=7695735

35. fomine3 ◴[] No.24843891{4}[source]
I've been respecting RMS' argument year by year
replies(1): >>24844173 #
36. LdSGSgvupDV ◴[] No.24843903[source]
China (enter the room): Agreed.
37. _jal ◴[] No.24843921[source]
That's the exactly the thing - they are, indeed, chasing me off. When this Mac dies, I'll be replacing it with something running Debian.

It is too bad - the Mac hit this sweet-spot where it was pretty much my perfect machine for several years - a kickass Unix workstation in a decently built laptop, with a decent GUI, with access to consumer apps, too. It was great while it lasted.

Thing is, this is a reasonable thing for Apple to do. Back when they weren't enormous, it made sense for them to at least make token gestures to the Unix-weenie/developer market - we threw a lot of money at them and made them hip when they were down and out. Now we're in rounding-error territory, and that we got what we wanted for a while was sort of a happy accident, anyway. Building developer dream-machines was never Apple's thing.

I bought my first Mac in 1991, and this one will last a while longer. Can't really complain too much about 30 years of decent-to-awesome tools.

replies(2): >>24844889 #>>24845291 #
38. heavyset_go ◴[] No.24844173{5}[source]
I find this article[1] linked by RMS is prescient as well, for something published in 2003.

[1] https://www.cl.cam.ac.uk/~rja14/tcpa-faq.html

39. matheusmoreira ◴[] No.24844722{3}[source]
User freedom means being able to command our computers to do anything, even if it's against the law or against the business interests of corporations. A free computer is by definition hostile to corporations and governments since it can be used against them.

Security as an industry is generally all about protecting the interests of corporations and governments. Just look at how they react when normal people use subversive technology like encryption. The people in power simply cannot tolerate anything they have no control over.

replies(1): >>24845344 #
40. dreamcompiler ◴[] No.24844882[source]
Microsoft makes an OS too. And to use it I have to spend an enormous amount of time turning off all its daemons that phone home, harvest my personal information, show me ads, and force updates on me.

So no, I don't trust OS providers. I tolerate them and defend myself against them.

41. andreareina ◴[] No.24844889[source]
I disagree that it's reasonableness except in the short term. We're seeing a change in developers' opinions; my friends in video production were getting ready to ditch Apple due to their "professional" software and hardware products getting worse both in relative (hardware) and absolute (software) terms. Part of the Apple cachet is that these are professional tools; how long is their reputation going to hold up if those professionals leave the platform?

It's a touch of hubris to think that we are and will continue to be taste makers, certainly. Maybe Apple won't get burned by alienating this crowd. But it seems a risky strategy for dubious return.

replies(1): >>24846130 #
42. KngFant ◴[] No.24845291[source]
I really thought about this yesterday, and the one program i really miss on linux would be Little Snitch. I need a good application firewall on linux.
replies(3): >>24845797 #>>24846167 #>>24855631 #
43. saagarjha ◴[] No.24845297[source]
Well, that's not the whole story: consider another example, the various parts of Safari. Apple wrote that, Apple wrote the whole OS…should they have access to a kernel task port? Shouldn't I trust them to not do bad things? Of course I do, since I use the browser–but I am glad that those are split into separate processes and sandboxed, because an exploit in any of those instantly turns this access into a confused deputy problem. A confused deputy is trustworthy–but they're confused.

Adding exceptions means adding more points of failure, more complexities in code, more opportunities for attackers to bypass restrictions placed on them but not on OS services. Not only that, but you get the upside of having a unified model for Apple and your app developers "for free"–the latter which is of critical importance to Apple in particular, since they have had years of trouble in this area.

44. saagarjha ◴[] No.24845331{4}[source]
Unfortunately, Apple often does 1 far more often than 2, whether it be because 2 is harder, or has a worse experience, or what have you. And Apple exempting themselves is really option 3 for themselves.
45. saagarjha ◴[] No.24845344{4}[source]
> Security as an industry

…is not a monolith. There are plenty of people in security interested in giving you freedom as a user, actually, many do it specifically for that reason.

46. arvinsim ◴[] No.24845797{3}[source]
Sounds like a business opportunity...
replies(1): >>24855637 #
47. MagnumOpus ◴[] No.24846130{3}[source]
Both the tech-bro and the media production audience are now a rounding error of a rounding error for Apple. It is a consumer luxury brand first and foremost, and it derives 99% of net income from that. Catering to dorks in basements is a tiny legacy business and the support level for it is commensurate. (It probably actually only exists because Apple has its own share of dorks in basements.)
replies(1): >>24849094 #
48. input_sh ◴[] No.24846167{3}[source]
There's OpenSnitch, but it's a WIP: https://github.com/evilsocket/opensnitch
49. Wowfunhappy ◴[] No.24848124{4}[source]
> A prime example would be rebooting into recovery mode to turn off system integrity protections via a terminal command.

I actually think the way Apple implemented this downright brilliant. As you say, it can't be done automatically, and it's definitely made to be a bit intimidating. At the same time, it's not difficult or onerous, that's a pretty hard balance to strike.

By contrast, when I try to install unsigned drivers in Windows, I feel as though Microsoft is fighting me, and I get annoyed basically every time. I've never had that feeling with SIP; when I get a new computer, I take off the training wheels I don't need, and move along.

50. AnthonyMouse ◴[] No.24849094{4}[source]
That's assuming nobody cares about the opinions of tech people when they're buying tech.

It's not just that tech people are customers, it's that ten other customers will look at what the tech people are carrying and assume they're the ones to know what's good.

And developers write code for the platform they actually use first. And spend time fixing the problems with that platform that are keeping other people from using it. Then more non-developers switch to it because it's improving.

51. wool_gather ◴[] No.24849799{7}[source]
Safari does not behave as you've described. The subdomain (for example, 'gist' in 'gist.github.com') is displayed.
replies(1): >>24852201 #
52. saagarjha ◴[] No.24852201{8}[source]
I suspect that Safari uses Public Suffix or similar for that.
53. dhaavi ◴[] No.24855631{3}[source]
We are working on an alternative for both Linux and Windows: https://safing.io/portmaster/

Not only is it an application firewall, but also gives you DNS filtering (ie. Pi-Hole basics) and DNS-over-TLS.

If you check it out, we'd love to hear some feedback! (Full UI revamp incoming)

54. dhaavi ◴[] No.24855637{4}[source]
We're on it: https://safing.io/portmaster/
55. ric2b ◴[] No.24906738{3}[source]
How do you get around TLS with cert-pinning?