The fate of ATS

[tiennou]

I'm opening a meta-issue so we don't use some (unrelated 😉) PR as scratch space.

See #2126, #2249.

It seems to me it's possible to allow insecure loads generally, because (as the docs say) "[we] allows the user to specify connection to an arbitrary URL", while using the exception mechanism to say which URLs are to be ATS-ified (which is good for security), like our own https://qsapp.com.

https://developer.apple.com/library/ios/documentation/General/Reference/InfoPlistKeyReference/Articles/CocoaKeys.html#//apple_ref/doc/uid/TP40009251-SW33

[tiennou]

What I'm not fond of is that if we go that route, we can't use the exception mechanism from plugins since the ATS rules are in application's Info.plist (eg. Dropbox would work because we generally allow insecure loads, not because we've been explicit about it).

Apart from that, it seems to me that ATS is aimed at apps that access webservices, not a full-fledged thing that can act as a web browser. So, we do the strict minimum we can, which is use ATS for the things under our control, or for which we want to be explicit about (like RTM), and let it be otherwise.

[skurfer]

OK, I re-read the docs. I didn’t know you could reverse the meaning of the exceptions list to enable, rather than disable ATS. If you guys want to turn it off, then enable it just for qsapp.com, that sounds fine to me.

[pjrobertson]

This still raises the problem of what if you want to browse to http://qsapp.com http://qsapp.com/ in QS? OK, in reality you’d just get redirected straight to the HTTPS site, but you wouldn’t even be able to get that far.
I’m ok with that being one edge case for better security to qsapp.com http://qsapp.com/

There’s also the question of: nobody’s raised this issue in the past year or so, so is it really that important to → into URLs? I never do it.
It’s nice to have but actually how useful is it in the end?

On 30 Jul 2016, at 00:43, Rob McBroom <notifications@github.com mailto:notifications@github.com> wrote:

OK, I re-read the docs. I didn’t know you could reverse the meaning of the exceptions list to enable, rather than disable ATS. If you guys want to turn it off, then enable it just for qsapp.com http://qsapp.com/, that sounds fine to me.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub #2251 (comment), or mute the thread https://github.com/notifications/unsubscribe-auth/AAJLn_5hM1lkn2PohiD0xCr51dQU3tfgks5qai2dgaJpZM4JYWTt.

[skurfer]

I’m ok with that being one edge case for better security to qsapp.com

So am I. But for what it’s worth, my first choice is still to use the Python solution so we can leave ATS enabled globally.

There’s also the question of: nobody’s raised this issue in the past year or so, so is it really that important to → into URLs? I never do it.

I do it in real life at least once a week (and it makes for a cool demo). And it’s not just right-arrow we’re talking about here. The same code is necessary to create a trigger for “URL ⇥ Search Contents” or anything else that loads children.

Also, I’m going to work on #767 any day now. I knew less about IB when I opened that and hoped someone else would do it, but I can probably handle it now.

[skurfer]

my first choice is still to use the Python solution so we can leave ATS enabled globally.

Hold the phone! I forgot how much the current Cocoa method benefits from OS integration when it comes to authentication. (It automatically uses the Keychain, Kerberos tickets, etc.) So, forget what I said and turn off ATS. TURN IT OFF! ❗

[tiennou]

Yeah, I think the only thing we can safely do is to try to make our URL-accessing machinery the more ATS-looking as possible (promote https over http, silently switching if that's not available), and display a broken padlock on http URL in the GUI.

😉