Is there any end-to-end security between my handset and ? for example ? paypal.com or my bank?
No. If you need full end-to-end encryption, you should use a full Web browser such as Opera Mobile.
I'll pass.
"me too."
opera for the iphone is reliant on the transcoder/proxy that sits between the iphone and the target website. a secure request (https) is decrypted at the proxy/transcoder and then re-encrypted before sending the request on to the target website. likewise on the return trip. used to be referred to as the wap-gap. anyone with access to that proxy/transcoder has access to the specifics of the request.
so no thanks, to any proxy/transcoder based browser.
"just because i'm paranoid doesn't mean they're not out to get me."
Opera knows this app will be rejected because the app violates the iPhone SDK agreement. Everyone knew that since the first public release of the app store.
"An Application may not itself install or launch other executable code by any means, including without limitation through the use of a plug-in architecture, calling other frameworks, other APIs or otherwise. No interpreted code may be downloaded or used in an Application except for code that is interpreted and run by Apple's Documented APIs and built-in interpreter(s)."
Quote:
Originally Posted by Tulkas
Could you explain how you see Opera as violating the quoted restriction?
It seems pretty obvious to me. It launches other executable code on Opera's proxy's, thus falling foul of at least the "otherwise" clause. It uses interpreted code not run by Apple's Documented APIs and built-in interpreter(s) by running JavaScript on those proxies. The quoted restriction doesn't limit itself to "other executable code" or interpreters located on the iPhone. Other browsers or apps with web views are fine because they go through Apple's Documented APIs and built-in interpreter(s).
Application level compression is most effective, especially given latency and processing limitations of different software and hardware.
What I don't understand is why mobile safari doesn't support gzip compression built into most web servers.
Server-side compression is something I still miss from my blackberry, although better rendering makes up for it generally.
I'm unclear what is being compressed. From the article it seems they are rendering the page elsewhere and sending it as a single page image (presumably adding buttons at links.) I'm surprised this makes it smaller or faster than the HTML itself. What am I missing?
BTW, did anyone else notice in the demo video, the progress bars all seem to indicate that Opera is still rendering/downloading when they press the next link. What does this mean? Are they "cheating" in the demo?
Yeah, rejection of Opera for no good reason other than to restrict competition will expose Apple to a complaint for breach of EU Competition Law.
I don't quite see how that would apply, seeing as how the iPhone "App Store only" model for native apps is allowed, and tons of phones don't even allow another browser to be used or installed (even in the EU).
Technically though Opera Mini is a scary beast, as already said by a ton of people. The traffic is still encrypted as I understand it, but instead of it being You > Bank, it's You > Opera > Bank.
Basically, if they were so inclined Opera would have full access to your bank account etc. Balls to that!
It seems pretty obvious to me. It launches other executable code on Opera's proxy's, thus falling foul of at least the "otherwise" clause. It uses interpreted code not run by Apple's Documented APIs and built-in interpreter(s) by running JavaScript on those proxies. The quoted restriction doesn't limit itself to "other executable code" or interpreters located on the iPhone. Other browsers or apps with web views are fine because they go through Apple's Documented APIs and built-in interpreter(s).
Uh Oh, the entire internet just got banned by this explanation....
Sometimes, when 'things' are invoked through a web page from a server, on a network, it results in code being executed....sort of the basis for network based computing. Any browser that connects to the Apple site results in WebObjects code being called and executed. Any web page loads results in servers executing code.
Uh Oh, the entire internet just got banned by this explanation....
Sometimes, when 'things' are invoked through a web page from a server, on a network, it results in code being executed....sort of the basis for network based computing. Any browser that connects to the Apple site results in WebObjects code being called and executed. Any web page loads results in servers executing code.
Only when you conveniently ignore that
Quote:
Originally Posted by anonymouse
... Other browsers or apps with web views are fine because they go through Apple's Documented APIs and built-in interpreter(s).
... Other browsers or apps with web views are fine because they go through Apple's Documented APIs and built-in interpreter(s).
...resulting in code being run on remote servers. So, in other words, it completely abides by the SDK restriction, as much as any other browser or app that using a network connection.
It isn't a matter of ignoring that statement of yours, it is recognizing how totally irrelevant it is.
-All browsers result in code being executed remotely when browsing to web pages.
-Opera and other iPhone browsers abide by the rules set out in the SDK for app development.
-claiming that Opera then violates the SDK because it results in code being executed remotely, as the other browsers also do, is then just a dumb argument.
"opera violates the SDK" "Why?" "because they result in remote code being executed" "But so do other browsers and apps" "The other apps followed the SDK, so opera didn't" "waht?" "Opera didn't because Opera didn't, because others did, so Opera didn't"
...resulting in code being run on remote servers. So, in other words, it completely abides by the SDK restriction, as much as any other browser or app that using a network connection.
It isn't a matter of ignoring that statement of yours, it is recognizing how totally irrelevant it is.
-All browsers result in code being executed remotely when browsing to web pages.
-Opera and other iPhone browsers abide by the rules set out in the SDK for app development.
-claiming that Opera then violates the SDK because it results in code being executed remotely, as the other browsers also do, is then just a dumb argument.
"opera violates the SDK" "Why?" "because they result in remote code being executed" "But so do other browsers and apps" "The other apps followed the SDK, so opera didn't" "waht?" "Opera didn't because Opera didn't, because others did, so Opera didn't"
Nice logic.
It's really quite simple, despite the twisted mess of "reasoning" above. Apps that use WebKit for web access are fine, those that don't aren't. Apps that have been approved do, Opera doesn't.
Of course, there are, as has been pointed out, a number of other perfectly good reasons for Apple to reject Opera, some of which are along the same lines of why Google Voice was rightly rejected.
The html code is text. They use text compression like LZW maybe.
Basic concept is this:
Common character strings are reduced to a numeral.
For example the html text class=" or style=" might be sent as numeral keycodes which it keeps in a dictionary of sorts this can save about 85%
I don't claim to know for sure, but I think its safe to assume anything that leaves from, or arrives at your modem is pretty efficiently compressed already. And JPEGS etc. are already about as compressed as they can be without further loss. I would assume a compressed image of a web page would be more verbose than a compressed file of the HTML that describes that page. So I'm wondering where the gain is.
Is it just in making a choppier versions of web pages?
It's really quite simple, despite the twisted mess of "reasoning" above. Apps that use WebKit for web access are fine, those that don't aren't. Apps that have been approved do, Opera doesn't.
Of course, there are, as has been pointed out, a number of other perfectly good reasons for Apple to reject Opera, some of which are along the same lines of why Google Voice was rightly rejected.
Yes, it is a twisted mess of reasoning. Irrational arguments tend to be.
So, now you have changed your argument to their choice of browser engine (when one argument fails, change arguments, I suppose...) Might be a good argument, but it doesn't relate to the SDK quote in question. If you could quote the SDK clause that specifically forbids the use of alternative engines, you might have a leg to stand on. Of course, I expect you won't be able to find such a clause.
The only argument relating to a violation of the SDK, might be, as you say, the same used for GV. Apple might claim it duplicates existing functionality. Of course, that would be strange, as it was in the GV case, since if it can be considered duplication then there are certainly other examples in the same categories which are also duplications and allowed. So, again you are right, banning Opera might make as little sense as banning the GV app.
In the end, it is silly and a waste of time to try to assume reasons for some apps being banned. Usually, those that need to argue that Apple is right, regardless of circumstance, end up being proven wrong or inconsistent when they try to use 'facts' to justify their arguments. They always end up going to one and only one argument, that being "It is Apple's iPhone, SDK and AppStore and so they can do as they please". Not a very compelling argument as to the why, but they seem to confuse this with the how.
Just got caught up with the comments. Anonymouse's comment about code being executed remotely on an Opera server would still violate the SDK rules is an interesting take. I'm completely buying it, but I also wouldn't put it past Apple as a reason.
Yes, it is a twisted mess of reasoning. Irrational arguments tend to be.
So, now you have changed your argument [...]
In the end, it is silly and a waste of time to try to assume reasons for some apps being banned. [...]
No, I haven't changed my argument at all, but I really can't be bothered with trying to parse your confused counterargument to refute it point by point. I've given my reasons, and expressed my expectations that Opera Mini will not be approved.
In regard to why apps are not accepted, I would note, that in terms of what's come to light in the interim, I was right about the reasons GV was not approved. That was also pretty obvious to anyone with an open mind and any sense of what's important to Apple.
Apple rightly won't approve Opera, and there won't be any even moderately significant fallout from not doing so.
No, I haven't changed my argument at all, but I really can't be bothered with trying to parse your confused counterargument to refute it point by point. I've given my reasons, and expressed my expectations that Opera Mini will not be approved.
of course you have. You perhaps just aren't able to see that.
Quote:
Originally Posted by anonymouse
In regard to why apps are not accepted, I would note, that in terms of what's come to light in the interim, I was right about the reasons GV was not approved. That was also pretty obvious to anyone with an open mind and any sense of what's important to Apple.
No, you were adamant that it was a concern for privacy because of the evil info collecting of Google. Apple even agreed with you on this in their FCC response, so a point for you (but, then they also said it replaced core functions of the OS, so maybe the FCC response was bollocks). With "what's come to light in the interim" it is pretty clear the only reason it was rejected/not approved was because of the perceived insult to Apple/Jobs of Android. No privacy concerns at all.
Quote:
Originally Posted by anonymouse
Apple rightly won't approve Opera, and there won't be any even moderately significant fallout from not doing so.
You are right, likely they won't approve it and there will be little fallout. It isn't the end of the world. But, certainly, pre-rendering the pages on remote servers, doesn't violate the SDK clause regarding API usage, code execution or code interpreters. That much is obvious...or should be to most.
of course you have. You perhaps just aren't able to see that.
No, you were adamant that it was a concern for privacy because of the evil info collecting of Google. Apple even agreed with you on this in their FCC response, so a point for you (but, then they also said it replaced core functions of the OS, so maybe the FCC response was bollocks). With "what's come to light in the interim" it is pretty clear the only reason it was rejected/not approved was because of the perceived insult to Apple/Jobs of Android. No privacy concerns at all.
I suggest you go back and read my posts in this thread, and in other threads regarding GV, and you'll find you are incorrect in all your above assertions.
I suggest you go back and read my posts in this thread, and in other threads regarding GV, and you'll find you are incorrect in all your above assertions.
Oh, I think we all recall the tinfoil hat claims made in the GV threads.
As for your 'arguments in this thread, they are little more than obviously wrong statements, confused ramblings and 'evolving' arguments.
Only one point you have made has any merit as far as SDK clauses that might be used to block that app. Duplication. Which, as we have seen, is simply a vague, lazy, catch all used when there is no valid reason.
Oh, I think we all recall the tinfoil hat claims made in the GV threads.
As for your 'arguments in this thread, they are little more than obviously wrong statements, confused ramblings and 'evolving' arguments. [...]
Actually, I think my first post in this thread, #39 I believe, pretty much lays out my position, and I don't see how any of my subsequent posts deviate from that position in any significant way.
As for "tinfoil hat claims", I guess you apply that to anyone who asserts Google is a potentially, if not already actually, problematic company? I guess it's a sort of argument, but not much of one.
Just got caught up with the comments. Anonymouse's comment about code being executed remotely on an Opera server would still violate the SDK rules is an interesting take. I'm completely buying it, but I also wouldn't put it past Apple as a reason.
I am not buying it, his other argument about only webkit being allowed is understandable. But to say code is executed remotely, well, no, that happens in all servers.
Actually, I think my first post in this thread, #39 I believe, pretty much lays out my position, and I don't see how any of my subsequent posts deviate from that position in any significant way.
Ok, let's look at post #39 (and ignore for the moment that your GV was not about the what potential Google has for evil but how evil the are).
here we go.
Quote:
Originally Posted by anonymouse
I'd be completely and utterly shocked if it were approved because a) it is in fact a browser, regardless of how that functionality is implemented, that violates the terms of the developer agreement, b) it is, as you point out, "dangerous" because it, "doesn't provide any of the standard protections people expect to be there," and c) Opera are clearly baiting Apple, in a rather childish manner, in fact.
a) Bullshit. Please provide the SDK clause the expressly forbids all browsers. We'll wait. (of course, you have since changed it from a laughable claim that it being a browser is enough for it being in violation to the fact that it doesn't use webkit-changing one's argument is easier than just admitting you were wrong, I guess.)
b) A reason not to use it, not a reason to ban it. Want security? Use Safari or one of the other webkit based browsers (you know, the ones you claim are a violation by virtue of existing, yet exist). Not like Opera makes a secret of this. Maybe some people really would be confused when Opera says No. If you need full end-to-end encryption, you should use a full Web browser.
c) They are baiting Apple by trying to get their browser on the iPhone? Using that ridiculous logic, any company that submits an app that abides by the SDK could be defined as 'baiting Apple' instead of 'submitting an app'. Is this really an argument? They submitted it (or 'baited Apple') so it should be rejected because they submitted it? really? This is your 3rd of 3 point? really? The reason for rejecting it is because it was submitted?
Really? Logic isn't everyone forte, but f*ck, basic reasoning should be mandatory for a HS diploma.
Quote:
Originally Posted by anonymouse
I think this is a slam-dunk rejection for violating the developer agreement and for undermining the iPhone user experience and security. Apple should just put this on the fast track, reject it, and be done with it, preferably by the end of the day. It's not like more than a handful of people care about Opera anyway, and it's not like it offers anything useful without also bringing huge downsides with it.
Certainly an opinion. Not one particularly based in facts, but an opinion nonetheless...I guess everyone really does have one of those too.
Comments
From the Opera mini browser FAQ
Is there any end-to-end security between my handset and ? for example ? paypal.com or my bank?
No. If you need full end-to-end encryption, you should use a full Web browser such as Opera Mobile.
I'll pass.
"me too."
opera for the iphone is reliant on the transcoder/proxy that sits between the iphone and the target website. a secure request (https) is decrypted at the proxy/transcoder and then re-encrypted before sending the request on to the target website. likewise on the return trip. used to be referred to as the wap-gap. anyone with access to that proxy/transcoder has access to the specifics of the request.
so no thanks, to any proxy/transcoder based browser.
"just because i'm paranoid doesn't mean they're not out to get me."
Opera knows this app will be rejected because the app violates the iPhone SDK agreement. Everyone knew that since the first public release of the app store.
"An Application may not itself install or launch other executable code by any means, including without limitation through the use of a plug-in architecture, calling other frameworks, other APIs or otherwise. No interpreted code may be downloaded or used in an Application except for code that is interpreted and run by Apple's Documented APIs and built-in interpreter(s)."
Could you explain how you see Opera as violating the quoted restriction?
It seems pretty obvious to me. It launches other executable code on Opera's proxy's, thus falling foul of at least the "otherwise" clause. It uses interpreted code not run by Apple's Documented APIs and built-in interpreter(s) by running JavaScript on those proxies. The quoted restriction doesn't limit itself to "other executable code" or interpreters located on the iPhone. Other browsers or apps with web views are fine because they go through Apple's Documented APIs and built-in interpreter(s).
Application level compression is most effective, especially given latency and processing limitations of different software and hardware.
What I don't understand is why mobile safari doesn't support gzip compression built into most web servers.
Server-side compression is something I still miss from my blackberry, although better rendering makes up for it generally.
I'm unclear what is being compressed. From the article it seems they are rendering the page elsewhere and sending it as a single page image (presumably adding buttons at links.) I'm surprised this makes it smaller or faster than the HTML itself. What am I missing?
BTW, did anyone else notice in the demo video, the progress bars all seem to indicate that Opera is still rendering/downloading when they press the next link. What does this mean? Are they "cheating" in the demo?
Yeah, rejection of Opera for no good reason other than to restrict competition will expose Apple to a complaint for breach of EU Competition Law.
I don't quite see how that would apply, seeing as how the iPhone "App Store only" model for native apps is allowed, and tons of phones don't even allow another browser to be used or installed (even in the EU).
Technically though Opera Mini is a scary beast, as already said by a ton of people. The traffic is still encrypted as I understand it, but instead of it being You > Bank, it's You > Opera > Bank.
Basically, if they were so inclined Opera would have full access to your bank account etc. Balls to that!
It seems pretty obvious to me. It launches other executable code on Opera's proxy's, thus falling foul of at least the "otherwise" clause. It uses interpreted code not run by Apple's Documented APIs and built-in interpreter(s) by running JavaScript on those proxies. The quoted restriction doesn't limit itself to "other executable code" or interpreters located on the iPhone. Other browsers or apps with web views are fine because they go through Apple's Documented APIs and built-in interpreter(s).
Uh Oh, the entire internet just got banned by this explanation....
Sometimes, when 'things' are invoked through a web page from a server, on a network, it results in code being executed....sort of the basis for network based computing. Any browser that connects to the Apple site results in WebObjects code being called and executed. Any web page loads results in servers executing code.
Uh Oh, the entire internet just got banned by this explanation....
Sometimes, when 'things' are invoked through a web page from a server, on a network, it results in code being executed....sort of the basis for network based computing. Any browser that connects to the Apple site results in WebObjects code being called and executed. Any web page loads results in servers executing code.
Only when you conveniently ignore that
... Other browsers or apps with web views are fine because they go through Apple's Documented APIs and built-in interpreter(s).
I'm unclear what is being compressed.
The html code is text. They use text compression like LZW maybe.
Basic concept is this:
Common character strings are reduced to a numeral.
For example the html text class=" or style=" might be sent as numeral keycodes which it keeps in a dictionary of sorts this can save about 85%
Only when you conveniently ignore that
... Other browsers or apps with web views are fine because they go through Apple's Documented APIs and built-in interpreter(s).
...resulting in code being run on remote servers. So, in other words, it completely abides by the SDK restriction, as much as any other browser or app that using a network connection.
It isn't a matter of ignoring that statement of yours, it is recognizing how totally irrelevant it is.
-All browsers result in code being executed remotely when browsing to web pages.
-Opera and other iPhone browsers abide by the rules set out in the SDK for app development.
-claiming that Opera then violates the SDK because it results in code being executed remotely, as the other browsers also do, is then just a dumb argument.
"opera violates the SDK" "Why?" "because they result in remote code being executed" "But so do other browsers and apps" "The other apps followed the SDK, so opera didn't" "waht?" "Opera didn't because Opera didn't, because others did, so Opera didn't"
Nice logic.
...resulting in code being run on remote servers. So, in other words, it completely abides by the SDK restriction, as much as any other browser or app that using a network connection.
It isn't a matter of ignoring that statement of yours, it is recognizing how totally irrelevant it is.
-All browsers result in code being executed remotely when browsing to web pages.
-Opera and other iPhone browsers abide by the rules set out in the SDK for app development.
-claiming that Opera then violates the SDK because it results in code being executed remotely, as the other browsers also do, is then just a dumb argument.
"opera violates the SDK" "Why?" "because they result in remote code being executed" "But so do other browsers and apps" "The other apps followed the SDK, so opera didn't" "waht?" "Opera didn't because Opera didn't, because others did, so Opera didn't"
Nice logic.
It's really quite simple, despite the twisted mess of "reasoning" above. Apps that use WebKit for web access are fine, those that don't aren't. Apps that have been approved do, Opera doesn't.
Of course, there are, as has been pointed out, a number of other perfectly good reasons for Apple to reject Opera, some of which are along the same lines of why Google Voice was rightly rejected.
The html code is text. They use text compression like LZW maybe.
Basic concept is this:
Common character strings are reduced to a numeral.
For example the html text class=" or style=" might be sent as numeral keycodes which it keeps in a dictionary of sorts this can save about 85%
I don't claim to know for sure, but I think its safe to assume anything that leaves from, or arrives at your modem is pretty efficiently compressed already. And JPEGS etc. are already about as compressed as they can be without further loss. I would assume a compressed image of a web page would be more verbose than a compressed file of the HTML that describes that page. So I'm wondering where the gain is.
Is it just in making a choppier versions of web pages?
It's really quite simple, despite the twisted mess of "reasoning" above. Apps that use WebKit for web access are fine, those that don't aren't. Apps that have been approved do, Opera doesn't.
Of course, there are, as has been pointed out, a number of other perfectly good reasons for Apple to reject Opera, some of which are along the same lines of why Google Voice was rightly rejected.
Yes, it is a twisted mess of reasoning. Irrational arguments tend to be.
So, now you have changed your argument to their choice of browser engine (when one argument fails, change arguments, I suppose...) Might be a good argument, but it doesn't relate to the SDK quote in question. If you could quote the SDK clause that specifically forbids the use of alternative engines, you might have a leg to stand on. Of course, I expect you won't be able to find such a clause.
The only argument relating to a violation of the SDK, might be, as you say, the same used for GV. Apple might claim it duplicates existing functionality. Of course, that would be strange, as it was in the GV case, since if it can be considered duplication then there are certainly other examples in the same categories which are also duplications and allowed. So, again you are right, banning Opera might make as little sense as banning the GV app.
In the end, it is silly and a waste of time to try to assume reasons for some apps being banned. Usually, those that need to argue that Apple is right, regardless of circumstance, end up being proven wrong or inconsistent when they try to use 'facts' to justify their arguments. They always end up going to one and only one argument, that being "It is Apple's iPhone, SDK and AppStore and so they can do as they please". Not a very compelling argument as to the why, but they seem to confuse this with the how.
Yes, it is a twisted mess of reasoning. Irrational arguments tend to be.
So, now you have changed your argument [...]
In the end, it is silly and a waste of time to try to assume reasons for some apps being banned. [...]
No, I haven't changed my argument at all, but I really can't be bothered with trying to parse your confused counterargument to refute it point by point. I've given my reasons, and expressed my expectations that Opera Mini will not be approved.
In regard to why apps are not accepted, I would note, that in terms of what's come to light in the interim, I was right about the reasons GV was not approved. That was also pretty obvious to anyone with an open mind and any sense of what's important to Apple.
Apple rightly won't approve Opera, and there won't be any even moderately significant fallout from not doing so.
No, I haven't changed my argument at all, but I really can't be bothered with trying to parse your confused counterargument to refute it point by point. I've given my reasons, and expressed my expectations that Opera Mini will not be approved.
of course you have. You perhaps just aren't able to see that.
In regard to why apps are not accepted, I would note, that in terms of what's come to light in the interim, I was right about the reasons GV was not approved. That was also pretty obvious to anyone with an open mind and any sense of what's important to Apple.
No, you were adamant that it was a concern for privacy because of the evil info collecting of Google. Apple even agreed with you on this in their FCC response, so a point for you (but, then they also said it replaced core functions of the OS, so maybe the FCC response was bollocks). With "what's come to light in the interim" it is pretty clear the only reason it was rejected/not approved was because of the perceived insult to Apple/Jobs of Android. No privacy concerns at all.
Apple rightly won't approve Opera, and there won't be any even moderately significant fallout from not doing so.
You are right, likely they won't approve it and there will be little fallout. It isn't the end of the world. But, certainly, pre-rendering the pages on remote servers, doesn't violate the SDK clause regarding API usage, code execution or code interpreters. That much is obvious...or should be to most.
You want to wiki something? Opera mini.
You want to pay bills? Safari
It's as simple as that.
of course you have. You perhaps just aren't able to see that.
No, you were adamant that it was a concern for privacy because of the evil info collecting of Google. Apple even agreed with you on this in their FCC response, so a point for you (but, then they also said it replaced core functions of the OS, so maybe the FCC response was bollocks). With "what's come to light in the interim" it is pretty clear the only reason it was rejected/not approved was because of the perceived insult to Apple/Jobs of Android. No privacy concerns at all.
I suggest you go back and read my posts in this thread, and in other threads regarding GV, and you'll find you are incorrect in all your above assertions.
I suggest you go back and read my posts in this thread, and in other threads regarding GV, and you'll find you are incorrect in all your above assertions.
Oh, I think we all recall the tinfoil hat claims made in the GV threads.
As for your 'arguments in this thread, they are little more than obviously wrong statements, confused ramblings and 'evolving' arguments.
Only one point you have made has any merit as far as SDK clauses that might be used to block that app. Duplication. Which, as we have seen, is simply a vague, lazy, catch all used when there is no valid reason.
Oh, I think we all recall the tinfoil hat claims made in the GV threads.
As for your 'arguments in this thread, they are little more than obviously wrong statements, confused ramblings and 'evolving' arguments. [...]
Actually, I think my first post in this thread, #39 I believe, pretty much lays out my position, and I don't see how any of my subsequent posts deviate from that position in any significant way.
As for "tinfoil hat claims", I guess you apply that to anyone who asserts Google is a potentially, if not already actually, problematic company? I guess it's a sort of argument, but not much of one.
Just got caught up with the comments. Anonymouse's comment about code being executed remotely on an Opera server would still violate the SDK rules is an interesting take. I'm completely buying it, but I also wouldn't put it past Apple as a reason.
I am not buying it, his other argument about only webkit being allowed is understandable. But to say code is executed remotely, well, no, that happens in all servers.
Actually, I think my first post in this thread, #39 I believe, pretty much lays out my position, and I don't see how any of my subsequent posts deviate from that position in any significant way.
Ok, let's look at post #39 (and ignore for the moment that your GV was not about the what potential Google has for evil but how evil the are).
here we go.
I'd be completely and utterly shocked if it were approved because a) it is in fact a browser, regardless of how that functionality is implemented, that violates the terms of the developer agreement, b) it is, as you point out, "dangerous" because it, "doesn't provide any of the standard protections people expect to be there," and c) Opera are clearly baiting Apple, in a rather childish manner, in fact.
a) Bullshit. Please provide the SDK clause the expressly forbids all browsers. We'll wait. (of course, you have since changed it from a laughable claim that it being a browser is enough for it being in violation to the fact that it doesn't use webkit-changing one's argument is easier than just admitting you were wrong, I guess.)
b) A reason not to use it, not a reason to ban it. Want security? Use Safari or one of the other webkit based browsers (you know, the ones you claim are a violation by virtue of existing, yet exist). Not like Opera makes a secret of this. Maybe some people really would be confused when Opera says No. If you need full end-to-end encryption, you should use a full Web browser.
c) They are baiting Apple by trying to get their browser on the iPhone? Using that ridiculous logic, any company that submits an app that abides by the SDK could be defined as 'baiting Apple' instead of 'submitting an app'. Is this really an argument? They submitted it (or 'baited Apple') so it should be rejected because they submitted it? really? This is your 3rd of 3 point? really? The reason for rejecting it is because it was submitted?
Really? Logic isn't everyone forte, but f*ck, basic reasoning should be mandatory for a HS diploma.
I think this is a slam-dunk rejection for violating the developer agreement and for undermining the iPhone user experience and security. Apple should just put this on the fast track, reject it, and be done with it, preferably by the end of the day. It's not like more than a handful of people care about Opera anyway, and it's not like it offers anything useful without also bringing huge downsides with it.
Certainly an opinion. Not one particularly based in facts, but an opinion nonetheless...I guess everyone really does have one of those too.