By coincidence, I've been working for the past 6 months on a port of Pac-Man to the Intellivision platform (CP-16010 CPU). I've based much of my game logic on the insight I gained from reading Jamey Pittman's The Pac-Man Dossier.
An even bigger coincidence is that this weekend I had started working on Ghost AI.
That is true. It is reproducible typically after a level has been playing for a while (during Cruise Elroy), when Blinky is going at the same speed as Pac-Man. It's pretty cool. It's predictable enough that there are some patterns exploiting this feature.
Some people enjoy interacting in a personal way with people they already know. Game Center is geared towards the users not the game developers. It seems to work well so far.
Ah, Utopia, the memories. Have to watch out for those insurgents. If you're not careful, they'll take over the school and hospital. Oh, and the hurricanes! I say always plant your crops on the west side, so you don't lose them.
If Google is providing an answer to a question asked (which is what a query is), then almost by definition the inquiring party does not have the necessary knowledge to judge the validity or accuracy of the response.
Or do you expect that people search in Google only using those terms for which they already know the results?
>> And while we're on that topic, why is always considered a bad thing
Correction: Always is considered a bad thing only sometimes, but never is considered a bad thing always. On the other hand, sometimes is never considered a good thing, so it's always considered a bad thing.
I think your comment agrees with my point, though you said it more directly: the Blizzard Forum was public and people expected to be anonymous, while the Apple service is intended for private interactions between already acquainted people.
I think you do not understand Apple's approach to "social media". There is a large part of the population who is not interested in the accretion of unknown and anonymous "friends", and thus shy away from vastly over-abused services like Facebook. Apple is attempting to fill that gap by offering a "social media" experience that is truly social, and revolves around people's real friends and family.
Their intention was never to compete with Facebook or the like, but to offer their users a way to participate in music sharing and games with their friends without having to go out into the wilderness.
Blizzard tried to introduce this feature to an already existing community of anonymous people. Apple introduced the Game Center and Ping services as a way to interact with your family and friends. It was never intended to be a free-for-all, anonymous community and lots of people accept this.
The other part, which people seem to easily forget, was the ruthless anti-competitive behaviour exerted by Microsoft over OEMs, and the huge strategic missteps that Apple made; due in part to the hubris and inexperience of Jobs. Neither of these are likely to re-occur on the current mobile market, at least not in the same way.
I'm not suggesting that Apple will "win". All I'm saying is that it is not clear that "open will trump closed every time," as some suggest, and that taking the WinTel PC open architecture as an example and proof is questionable.
If in doubt, take a look at the Linux on the Desktop movement.
You mean, isn't anybody else bothered that the military was not concerned about the non-threat of a normal airliner cruising, enough to dig through their massive information store to figure out which particular plane it was?
Except that Skyhook does not send a vehicle through your neighborhood to collect the information, unrequired; they calculate it and store it as part of the location-detection service that the user initiated.
So, if I access Google and request location information, then it's fine for them to catalog my MAC address and Wi-Fi network information in order to properly and accurately provide the service. However, if I don't use Google, I do not want them cataloging my network information, uninvited.
There's one major difference: The delivery of the goods is the consummation of a transaction between the purchaser and the vendor; the return and exchange is legally a separate transaction between the vendor and the recipient.
It may appear to you as a single, redundant transaction, but it is not. Your Aunt engaged in a commercial transaction with Amazon, not you; and Amazon is legally bound to fulfill this transaction.
You cannot just "remove the unnecessary steps of sending it to you," because that is a completely separate transaction, which is a prerequisite for the second.
What I'm suggesting is that currently apps have a responsibility to do their own authz dialogs because nothing else does. Ultimately an app that does potentially risky/costly things depending on the specifics of the passed URL will always have to do that unless Apple creates a means of registering a parser to translate an URL to the text of an authz request. Because apps are written and used by populations large enough to each follow Sturgeon's Law, the right thing for Apple to do given the established architecture is to add a default behavior of asking before switching apps with an API that lets apps suppress that (i.e. if they are going to need to ask anyway) and a UI that lets users tweak behavior to their liking. If Apple had done this right from the start, thinking first about the UI and working back to a more robust API, they could have created a better system. It's too late for that, because the UI now is broken whether apps actually handle their authz issues or ignore them and there are scores of apps written to the existing system.
There are two issues here which have been conflated. On the one hand, there is the inconvenience of being taken out of a Safari browsing session. On the other, there is the potential risk of an external application performing some unwanted action. The former is a UI issue, but not a security risk. The second one is a security risk, but is mitigated by the OS controlling access to risky services, such as location information, and network and telephone communications. However, if the user has already granted permission to the target application to do its actions, then it is not really a security risk when it tries to perform them.
If the developer of the application decided to perform the action during use cases when the user may not be aware of the request--such as the one in question, when a URL (or maybe even a hidden iFrame) requests a VoIP call--then this is not the OS's issue, it is an issue of transparency. It makes the application look sneaky. But still, let's not forget, that the user granted it permission. It is a matter of user expectations, which the developer is arguably not fulfilling.
At the heart of the matter is the fact that the URL does not dictate function nor context, just the target handler. How can the OS ultimately know that the target application will do something potentially risky or costly? After all, something as innocuous as, say "pdf://" scheme, does not preclude the target handler from deciding that it will use the telephone API to call a 1-900 number. If it did, then you would imagine iOS intercepting this request. However, if the user granted permission to the handler to make telephone calls, is it really a violation of OS security policy, or user expectations?
Granted, this is an obviously obtuse example, but the same applies to the "skype://" scheme: the user already granted it permission to make phone calls. Perhaps the user does want Safari to automatically make a call when he clicks on the a "skype://" hyperlink. It is not Safari's job to decide this, but Skype's. In my opinion, this is an assumption that should not be made automatically; but still it is the responsibility of the Skype application to either make the assumption, or request confirmation.
But there's no way for it to know what the handler is going to do prior to calling it! It's like asking Safari to solve the Halting Problem when seeing a URL protocol scheme.
You are predicating this solution on the assumption that the scheme "skype" means "make a VoIP phone call", but it doesn't mean that at all. It literally just means "this scheme is handled by the application Skype, for it knows what to do with it." It could mean "make a VoIP call," but it just as well could mean "write to log file," "download update," "delete address book," or "phone home."
Slashdot Mirror
By coincidence, I've been working for the past 6 months on a port of Pac-Man to the Intellivision platform (CP-16010 CPU). I've based much of my game logic on the insight I gained from reading Jamey Pittman's The Pac-Man Dossier.
An even bigger coincidence is that this weekend I had started working on Ghost AI.
-dZ.
That is true. It is reproducible typically after a level has been playing for a while (during Cruise Elroy), when Blinky is going at the same speed as Pac-Man. It's pretty cool. It's predictable enough that there are some patterns exploiting this feature.
-dZ.
Some people enjoy interacting in a personal way with people they already know. Game Center is geared towards the users not the game developers. It seems to work well so far.
-dZ.
You mean Excite?
-dZ.
Ah, Utopia, the memories. Have to watch out for those insurgents. If you're not careful, they'll take over the school and hospital. Oh, and the hurricanes! I say always plant your crops on the west side, so you don't lose them.
-dZ.
If Google is providing an answer to a question asked (which is what a query is), then almost by definition the inquiring party does not have the necessary knowledge to judge the validity or accuracy of the response.
Or do you expect that people search in Google only using those terms for which they already know the results?
-dZ.
>> And while we're on that topic, why is always considered a bad thing
Correction: Always is considered a bad thing only sometimes, but never is considered a bad thing always. On the other hand, sometimes is never considered a good thing, so it's always considered a bad thing.
Oh wait, I guess you were right.
-dZ.
Right, because having a small market share is killing Apple, while Microsoft's margins keep on growing along with their desktop OS market share.
-dZ.
I think your comment agrees with my point, though you said it more directly: the Blizzard Forum was public and people expected to be anonymous, while the Apple service is intended for private interactions between already acquainted people.
-dZ.
I think you do not understand Apple's approach to "social media". There is a large part of the population who is not interested in the accretion of unknown and anonymous "friends", and thus shy away from vastly over-abused services like Facebook. Apple is attempting to fill that gap by offering a "social media" experience that is truly social, and revolves around people's real friends and family.
Their intention was never to compete with Facebook or the like, but to offer their users a way to participate in music sharing and games with their friends without having to go out into the wilderness.
-dZ.
Blizzard tried to introduce this feature to an already existing community of anonymous people. Apple introduced the Game Center and Ping services as a way to interact with your family and friends. It was never intended to be a free-for-all, anonymous community and lots of people accept this.
-dZ.
OMG! you met Steve Jobs?
-dZ.
I'll fight for my right to it... oh wait!
>> Rethink that statement again, and awe in their ability to manage and grow their business even when chips were terrible.
I once had to grow my business when the chips were terrible. We had to switch to popcorn and peanuts because people just wouldn't eat them.
-dZ.
The other part, which people seem to easily forget, was the ruthless anti-competitive behaviour exerted by Microsoft over OEMs, and the huge strategic missteps that Apple made; due in part to the hubris and inexperience of Jobs. Neither of these are likely to re-occur on the current mobile market, at least not in the same way.
I'm not suggesting that Apple will "win". All I'm saying is that it is not clear that "open will trump closed every time," as some suggest, and that taking the WinTel PC open architecture as an example and proof is questionable.
If in doubt, take a look at the Linux on the Desktop movement.
-dZ.
If we need train people for airplane security, does that mean that railroad travel is more secure already? I'm booking on AMTRAK then!
-dZ.
Well, they can source it in CBS as "Anonymous Coward".
-dZ.
You mean, isn't anybody else bothered that the military was not concerned about the non-threat of a normal airliner cruising, enough to dig through their massive information store to figure out which particular plane it was?
-dZ.
Apparently, not if it is a run-of-the-mill, uninteresting airliner.
-dZ.
I stand corrected. They both are eh-veel!
-dZ.
Except that Skyhook does not send a vehicle through your neighborhood to collect the information, unrequired; they calculate it and store it as part of the location-detection service that the user initiated.
So, if I access Google and request location information, then it's fine for them to catalog my MAC address and Wi-Fi network information in order to properly and accurately provide the service. However, if I don't use Google, I do not want them cataloging my network information, uninvited.
-dZ.
I weep for the future.
-dZ.
There's one major difference: The delivery of the goods is the consummation of a transaction between the purchaser and the vendor; the return and exchange is legally a separate transaction between the vendor and the recipient.
It may appear to you as a single, redundant transaction, but it is not. Your Aunt engaged in a commercial transaction with Amazon, not you; and Amazon is legally bound to fulfill this transaction.
You cannot just "remove the unnecessary steps of sending it to you," because that is a completely separate transaction, which is a prerequisite for the second.
-dZ.
There are two issues here which have been conflated. On the one hand, there is the inconvenience of being taken out of a Safari browsing session. On the other, there is the potential risk of an external application performing some unwanted action. The former is a UI issue, but not a security risk. The second one is a security risk, but is mitigated by the OS controlling access to risky services, such as location information, and network and telephone communications. However, if the user has already granted permission to the target application to do its actions, then it is not really a security risk when it tries to perform them.
If the developer of the application decided to perform the action during use cases when the user may not be aware of the request--such as the one in question, when a URL (or maybe even a hidden iFrame) requests a VoIP call--then this is not the OS's issue, it is an issue of transparency. It makes the application look sneaky. But still, let's not forget, that the user granted it permission. It is a matter of user expectations, which the developer is arguably not fulfilling.
At the heart of the matter is the fact that the URL does not dictate function nor context, just the target handler. How can the OS ultimately know that the target application will do something potentially risky or costly? After all, something as innocuous as, say "pdf://" scheme, does not preclude the target handler from deciding that it will use the telephone API to call a 1-900 number. If it did, then you would imagine iOS intercepting this request. However, if the user granted permission to the handler to make telephone calls, is it really a violation of OS security policy, or user expectations?
Granted, this is an obviously obtuse example, but the same applies to the "skype://" scheme: the user already granted it permission to make phone calls. Perhaps the user does want Safari to automatically make a call when he clicks on the a "skype://" hyperlink. It is not Safari's job to decide this, but Skype's. In my opinion, this is an assumption that should not be made automatically; but still it is the responsibility of the Skype application to either make the assumption, or request confirmation.
-dZ.
But there's no way for it to know what the handler is going to do prior to calling it! It's like asking Safari to solve the Halting Problem when seeing a URL protocol scheme.
You are predicating this solution on the assumption that the scheme "skype" means "make a VoIP phone call", but it doesn't mean that at all. It literally just means "this scheme is handled by the application Skype, for it knows what to do with it." It could mean "make a VoIP call," but it just as well could mean "write to log file," "download update," "delete address book," or "phone home."
-dZ.