Have either of you guys actually seen the text of this message?
Yes, it is in one of the links I put in the story.:-)
Neither have I but I am sure (because it's Mac OS X) it goes a lot farther to empower and help the user understand the implications of their actions than the 'Always Trust Content from Gator Corp.' dialog you get with Internet Exploder./em?
It doesn't. It says "if you were not expecting this application to open, click Cancel." I am not arguing about this dialog specifically, but the fact of having a dialog at all, which will confuse and scare many users, and they will not understand what to do, no matter what it says. If I were arguing about this specific dialog box, my task here would be far easier, because it really stinks.:-)
This is what clicking 'Yes' in the dialog box does. Explicitly runs an app.
The user doesn't understand that, let alone its implications. Users are stupid. You must assume, for the sake of security, that the dialog reads "Kdas Huhuadsd Dudhasd Zdhasd." They will not understand it. I am not trying to be mean, I am not trying to be a snob, I am just being realistic.
This you may as well remove the functionality completely, considering you just removed the only way to run a handler explicitly.
Remove the URI handling functionality? If that is what you mean, you're missing the point. You must run the app the first time. After that, a handler for it will work. The issue is a new app sneaking its way onto your system and being executed remotely.
Every time the dialog pops up, put a phrase saying "If you don't understand, click no because you could be hax0red".
It would be far better if the language were this strong (it is not), but even still, most users won't understand it. You must assume they won't understand the question you are asking them, because the fact is, they won't.
And again, I am only so strict about this because it is a remote attack. Yes, users, can do lots of damage to their own system, of their own accord. But this attack will succeed if the user simply clicks the wrong button, and the fact is that they will.
Tell any unsophisticated OS X user to always click cancel. Always.
They won't hear you tell them, and they won't remember you told them. Even if it is in the dialog box itself -- which it is not -- it won't help.
Even the most unsophisticated user can follow those easy instructions.
No, they cannot.
It is going to be a rare event for the average user.
Which only hurts your argument, as infrequency dulls the memory. There is no chance, for some of them, that they will recognize the dialog box for what it is, and remember that you told them to do something, and remember what that thing is.
I think you are overstating the problem.
I am absolutely certain you are overestimating users.
Any rule as or more complex than "don't open unknown email attachments" is a proven failure. How are you not getting this? If they can't follow that, which is far simpler, far easier to understand the problem, and happens far more frequently... how can you reasonably expect theycan follow what you say? You're not living in the real world.
If you have that low an opinion of people, then you should realize that there is almost nothing that can be done to protect them. At some point, a user has to be allowed to run programes - and new ones at that. If not, then the computer is nearly useless.
You're committing the Excluded Middle fallacy here. There are degrees. In this case, we are talking about a remote attacker doing things without user interaction, except to click on a dialog box *they don't understand*. They only have two options, and they don't know which is the right one. And no matter what the dialog says, that won't change. This is very different from a user going and clicking to open an application of their own accord.
IMO, the way this should work is to disallow an app to be executed for the first time, period, except explicitly. There should be no dialog asking them if they want to open it for the first time, it should simply be disallowed, period.
On the other hand, if a user is innocently visiting a web site and a dialog box all of a sudden appears prompting the user to accept that *an application* be run, I think it's pretty clear that this handles the issue.
You think much more highly of the average user than I do.
You miss the point, as usual. I want to allow other people to change the music. I don't want them to have full access to my server, wirelessly, with a well-known passphrase.
I just got word from a "knowledgable source":-) that iTunes 4.6 can send any music to the base station that it has access to, including from iTunes Music Sharing. However, since it just acts as a remote speaker, it means to do this, you will be streaming twice the amount of data over your network, and you'll need to leave iTunes open on the laptop. Bleah.
So the options now -- since VNC and ARD are not an option, because of ease-of-use and security concerns -- are netTunes (which works now, because -- I didn't realize -- it basically just does a VNC of that one app), and an Apache interface.
Also, the Express CAN share Internet access over the LAN to wired clients.
No seriously, if you have a laptop there, you can easily control itunes remotely. Heck, you could do it from a web page [deadendsw.com], if you wanted to.
Yes, I know. I had a CGI on my Mac to allow people to control my CDs, back in 1996. They could even eject the CD if they disapproved of it. That didn't last long.:-)
This is almost worse than the VNC option. On my laptop, I'd need to manage between multiple music libraries. Not to mention how SLOW loading my big iTunes library is over wireless.
Right... except that there's no indication that will work. There's nothing on the AirTunes page etc. that says you can stream shared playlists from a client to the AirPort Express.
You want Mac::Glue. That module is fairly slow and unsupported, and won't be extended to talk to AirTunes (unless it is ported to Mac::Glue anyway, likely).
use Mac::Glue ':all'; my $itunes = new Mac::Glue 'iTunes'; my $track = $itunes->prop('current track'); # will always point to whatever is current track my $artist = $track->prop('artist'); # will always point to current track's artist print $artist->get; $itunes->next_track; # etc.
I have an X-Chat Aqua script which does all this; it's fairly trivial to extend it to working for a mod_perl interface, except the part about getting your http server running as the current user, or root (else Apple events won't work). And from there, pretty trivial to extend it to talking to AirTunes... assuming Apple provides that access in iTunes' aete, which is a pretty big presumption.
Yes, I had pondered writing some fairly simple perl + Mac::Glue code to handle this, maybe extend Apache::MP3 (which I already have running). But I won't invest $130 in the experiment, and I don't have time to work on it anyway.
VNC for this SUCKS. GO AWAY. Also note the security problems if I want other people to be able to access it. Yeah, let's give access to my server to anyone who wants it! FLM.
Unless it is built-in, there'd be no GOOD way to handle it, except writing an app that would be able to talk to the server iTunes, using daap perhaps to get the library, and Apple events to tell it to talk to the Express box... assuming you can do this with Apple events, which, given Apple's record, is a pretty big IF.
But even then, it wouldn't be exceptionally efficient, and it would be difficult to overcome the security problems (since the client must have "Program Linking" access).
It appears to me as though you can only share music to the Express from a machine that has the audio locally. But I'd want to control the music from a laptop in the living room, using music shared from my server in a closet, and then close the laptop. Seems like I can't do that, so it sounds like I won't be getting this.
Yeah, jeez. My CD collection takes up about 60GB, plus there's other stuff. My 30GB really isn't big enough. Now, in part this is because I use higher quality MP3s, so I can play them on my home stereo, and I really wish iTunes would optionally downsample tracks when it moves them to the iPod. Regardless... 60GB would be just about right.
And what was that someone said about not storing the MP3s on the player, where they could get lost? Hello, you have them on both. And actually, my home HD busted recently, and the only MP3s I didn't lose were the 30GB of music on my iPod. Next time, I'll back them all up, so I don't need to rerip.
Re:URL Handler Exploits appear to be fixed...
on
Mac OS X 10.3.4 Released
·
· Score: 4, Informative
I just ran the Paranoid Android example exploit on a basically unmodified Mac OS X 10.3.4 user account, with no extras or RCDefaultApp or changed settings etc., and it ran just fine. The hole is still there. The "you have been owned" dialogue came up without any interaction from me.
Slashdot Mirror
Have either of you guys actually seen the text of this message?
:-)
:-)
Yes, it is in one of the links I put in the story.
Neither have I but I am sure (because it's Mac OS X) it goes a lot farther to empower and help the user understand the implications of their actions than the 'Always Trust Content from Gator Corp.' dialog you get with Internet Exploder./em?
It doesn't. It says "if you were not expecting this application to open, click Cancel." I am not arguing about this dialog specifically, but the fact of having a dialog at all, which will confuse and scare many users, and they will not understand what to do, no matter what it says. If I were arguing about this specific dialog box, my task here would be far easier, because it really stinks.
This is what clicking 'Yes' in the dialog box does. Explicitly runs an app.
The user doesn't understand that, let alone its implications. Users are stupid. You must assume, for the sake of security, that the dialog reads "Kdas Huhuadsd Dudhasd Zdhasd." They will not understand it. I am not trying to be mean, I am not trying to be a snob, I am just being realistic.
This you may as well remove the functionality completely, considering you just removed the only way to run a handler explicitly.
Remove the URI handling functionality? If that is what you mean, you're missing the point. You must run the app the first time. After that, a handler for it will work. The issue is a new app sneaking its way onto your system and being executed remotely.
Every time the dialog pops up, put a phrase saying "If you don't understand, click no because you could be hax0red".
It would be far better if the language were this strong (it is not), but even still, most users won't understand it. You must assume they won't understand the question you are asking them, because the fact is, they won't.
And again, I am only so strict about this because it is a remote attack. Yes, users, can do lots of damage to their own system, of their own accord. But this attack will succeed if the user simply clicks the wrong button, and the fact is that they will.
Tell any unsophisticated OS X user to always click cancel. Always.
... how can you reasonably expect theycan follow what you say? You're not living in the real world.
They won't hear you tell them, and they won't remember you told them. Even if it is in the dialog box itself -- which it is not -- it won't help.
Even the most unsophisticated user can follow those easy instructions.
No, they cannot.
It is going to be a rare event for the average user.
Which only hurts your argument, as infrequency dulls the memory. There is no chance, for some of them, that they will recognize the dialog box for what it is, and remember that you told them to do something, and remember what that thing is.
I think you are overstating the problem.
I am absolutely certain you are overestimating users.
Any rule as or more complex than "don't open unknown email attachments" is a proven failure. How are you not getting this? If they can't follow that, which is far simpler, far easier to understand the problem, and happens far more frequently
You're committing a genetic fallacy!
If you have that low an opinion of people, then you should realize that there is almost nothing that can be done to protect them. At some point, a user has to be allowed to run programes - and new ones at that. If not, then the computer is nearly useless.
You're committing the Excluded Middle fallacy here. There are degrees. In this case, we are talking about a remote attacker doing things without user interaction, except to click on a dialog box *they don't understand*. They only have two options, and they don't know which is the right one. And no matter what the dialog says, that won't change. This is very different from a user going and clicking to open an application of their own accord.
IMO, the way this should work is to disallow an app to be executed for the first time, period, except explicitly. There should be no dialog asking them if they want to open it for the first time, it should simply be disallowed, period.
On the other hand, if a user is innocently visiting a web site and a dialog box all of a sudden appears prompting the user to accept that *an application* be run, I think it's pretty clear that this handles the issue.
You think much more highly of the average user than I do.
You miss the point, as usual. I want to allow other people to change the music. I don't want them to have full access to my server, wirelessly, with a well-known passphrase.
**** UPDATE ****
:-) that iTunes 4.6 can send any music to the base station that it has access to, including from iTunes Music Sharing. However, since it just acts as a remote speaker, it means to do this, you will be streaming twice the amount of data over your network, and you'll need to leave iTunes open on the laptop. Bleah.
I just got word from a "knowledgable source"
So the options now -- since VNC and ARD are not an option, because of ease-of-use and security concerns -- are netTunes (which works now, because -- I didn't realize -- it basically just does a VNC of that one app), and an Apache interface.
Also, the Express CAN share Internet access over the LAN to wired clients.
Yes, that's great, if it is modified to support AirTunes.
No seriously, if you have a laptop there, you can easily control itunes remotely. Heck, you could do it from a web page [deadendsw.com], if you wanted to.
:-)
Yes, I know. I had a CGI on my Mac to allow people to control my CDs, back in 1996. They could even eject the CD if they disapproved of it. That didn't last long.
This is almost worse than the VNC option. On my laptop, I'd need to manage between multiple music libraries. Not to mention how SLOW loading my big iTunes library is over wireless.
Right ... except that there's no indication that will work. There's nothing on the AirTunes page etc. that says you can stream shared playlists from a client to the AirPort Express.
Yes, I had pondered writing some fairly simple perl + Mac::Glue code to handle this, maybe extend Apache::MP3 (which I already have running). But I won't invest $130 in the experiment, and I don't have time to work on it anyway.
VNC for this SUCKS. GO AWAY. Also note the security problems if I want other people to be able to access it. Yeah, let's give access to my server to anyone who wants it! FLM.
Unless it is built-in, there'd be no GOOD way to handle it, except writing an app that would be able to talk to the server iTunes, using daap perhaps to get the library, and Apple events to tell it to talk to the Express box ... assuming you can do this with Apple events, which, given Apple's record, is a pretty big IF.
But even then, it wouldn't be exceptionally efficient, and it would be difficult to overcome the security problems (since the client must have "Program Linking" access).
I have a laptop in the closet now, and use ARD (not ARA :-) to control it now. This would not be an improvement. :-)
It appears to me as though you can only share music to the Express from a machine that has the audio locally. But I'd want to control the music from a laptop in the living room, using music shared from my server in a closet, and then close the laptop. Seems like I can't do that, so it sounds like I won't be getting this.
Yeah, jeez. My CD collection takes up about 60GB, plus there's other stuff. My 30GB really isn't big enough. Now, in part this is because I use higher quality MP3s, so I can play them on my home stereo, and I really wish iTunes would optionally downsample tracks when it moves them to the iPod. Regardless ... 60GB would be just about right.
And what was that someone said about not storing the MP3s on the player, where they could get lost? Hello, you have them on both. And actually, my home HD busted recently, and the only MP3s I didn't lose were the 30GB of music on my iPod. Next time, I'll back them all up, so I don't need to rerip.
Yes. See the Slash project page.
See CmdrTaco's journal. The Section/Topics stuff.
I started my LotR marathon today while working on some new features in the Slash code. I hope it doesn't show ...
Ho hum. This is just whining that should be scoffed at for the nonsense it is.
No.
I just ran the Paranoid Android example exploit on a basically unmodified Mac OS X 10.3.4 user account, with no extras or RCDefaultApp or changed settings etc., and it ran just fine. The hole is still there. The "you have been owned" dialogue came up without any interaction from me.