Most active commenters
  • Wowfunhappy(3)
  • dumpsterdiver(3)

←back to thread

1183 points robenkleene | 14 comments | | HN request time: 0.001s | 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 #
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 #
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 #
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 #
1. Spivak ◴[] No.24840678[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 #
2. Wowfunhappy ◴[] No.24841039[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 #
3. GekkePrutser ◴[] No.24841429[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.
4. tpxl ◴[] No.24842102[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 #
5. Spivak ◴[] No.24842215{3}[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 #
6. greycol ◴[] No.24842238{3}[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 #
7. AnthonyMouse ◴[] No.24842844[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.

8. dumpsterdiver ◴[] No.24843471[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 :)

9. ◴[] No.24843638{4}[source]
10. dumpsterdiver ◴[] No.24843674{4}[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.
11. dumpsterdiver ◴[] No.24843710{4}[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".
12. pdkl95 ◴[] No.24843762{4}[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

13. wool_gather ◴[] No.24849799{4}[source]
Safari does not behave as you've described. The subdomain (for example, 'gist' in 'gist.github.com') is displayed.
replies(1): >>24852201 #
14. saagarjha ◴[] No.24852201{5}[source]
I suspect that Safari uses Public Suffix or similar for that.