Opera looks set to release a version of its Opera Mobile browser for Android soon -- when that happens we'll be taking Android competitors into the ring, so stay tuned.
They buried that right on the first page of the article though, so I can see how you missed it.
How about we simply disallow deceptive advertising? That would fix this and a host of other bullshit besides.
That's brilliant! In addition to outlawing it, of course we also need to be able to enforce those rules. So that means that we should set up a federal body, or maybe a commission, that could regulate false and deceptive practices in commerce and trade. Sort of like a Federal Trade Commission, if you will.
Perhaps we could implore President Wilson to consider this in his crusade against the trusts!
Yeah, I can agree with that as well. I guess my premise for the pro-cookie argument has hinged on the fact that cookies are used for persisting a local session ID, and nothing else. In an ideal world, people who exist solely to market other people's products wouldn't have a job and wouldn't interfere with my development activities.
In reality though, I'm still content to use cookies because they provide the best state management I think I can get using HTTP.
So, I'll concede that you've got several good ("reality") arguments against cookies, but I've got several good ("idealist") arguments for cookies. Between reality and idealism I think we can both agree that reality turns out to be the only thing that matters.
That being said, do you have any applications that do successfully use an alternative session-management scheme? The primary reason I've stuck with cookies for session management are that they're drop-dead easy and I've yet to receive a problem report from a user who's blocking first-party cookies. I've ever only used cookies for my local session management (I have a severe allergic reaction to advertisers, online or otherwise), so if you've got any tried-and-true methods of persisting session state without a cookie I would be interested to hear.
I haven't felt comfortable with ever using PHP's own cookie-less session handling, just because I cringe at any URL I see that contains "?PHPSESSID=". I suppose it wouldn't be too much of an issue if you had your global include file get all of the session data (start the session) and then change the session ID for the output filter, but most of what I'm doing these days is using ajax so I would have to pass the session ID back and forth with each request. Have you seen any ajax application that pass the session ID back and forth like that, or have you heard of any issues? I suppose you could use a global Javascript variable to store the current session ID to send back and use to store the new one that comes back, I just have a feeling that changing the session ID on any request would have some implications that I'm not considering.
The objection isn't to cookies per se, but to the way that they have become pervasive and intrusive.
I can agree with that.
"This site doesn't use cookies" or "Cookie-free Zone" would offer some guarantee that when they leave a site, they've truly left it behind
I agree, I'd actually like to see exemptions in the law specifically to allow same-domain session-tracking cookies without requiring explicit consent. The difficulty would be in writing that in such a way that it truly only allows session state cookies for the application you're using and nothing else, specifically marketing- and advertising-related activities. I just think that the state-preserving that cookies allow is too useful to throw the baby out with the bathwater, as it were.
The unfortunate thing about all of this is that it requires the developers to comply, I tend to think that the developers interested in complying with anything aren't really the source of the problem they're trying to fix.
You're right - it IS like talking to a stone. first hit - xmlhttprequest supports post variables, complete with code [openjs.com]. No flash involved, no plugins.
So we've gone full circle, from simply passing the session ID around in the querystring to now implementing everything in ajax (incidentally, if you're using ajax, it doesn't really matter if you pass the session ID in get or post). I'm all for ajax, everything I've done for the past few years makes a lot of use of ajax, but the vast majority of sites do not use ajax and it's a little silly to assume that every site will start using ajax as a means of passing session IDs so that they don't need to use cookies.
So, let's review. These are the options for tracking state:
1. Cookies 2. Querystring 3. Post body: Use Javascript to tranform each link to a form post, or change the site design and use ajax for all content loading, requiring you to also manually add in "back" support and making sure your users can still email links to specific pages, in addition to making sure your content can still be found by search engines.
Ask me again in a couple of years when the NDA expires.
That's convenient. So the "some sites" you mentioned before are actually just one project that you've worked on. In other words, you aren't aware of any public sites using your method.
fix your sites to comply with both the RFC and end-users' expectations of privacy
1. My sites are not broken, if the browser saves a cookie without asking consent it's not because I told the browser to save a cookie without asking consent, I just told it to save a cookie. If the browser the user happens to be using does not comply with the RFC that's not the fault of my application. 2. I would even argue that end user's expectation of privacy online includes the knowledge that sites save some sort of information about them either on the server or on their own computer. In other words, users expectation of privacy includes cookies.
From all the complaining from people who can't be arsed to even read the RFC.
I didn't realize I was complaining about anything, I just thought I was trying to get you to come up with a way to persist session state that was as convenient (for both developers and users), reliable, and secure as cookies. So far you've got passing the information along in the querystring and using ajax. If someone is hacking your cookies do you think they won't be able to figure out what information you're submitting via ajax? Do you think that using ajax is any more secure than using cookies or any other method of requesting? Sure, you can send everything over SSL, but you can also require that cookies only go over SSL. I still think that passing that information in the form of an HTTP header, in other words a cookie, is clearly more secure than the querystring and has all of the same benefits and faults of using the post body.
Too lazy to learn new ways to do things.
I'm trying to educate myself here, but you haven't told me anything I didn't already know.
I'll also point out that so far I haven't even bothered to bring up the fact that not all users run Javascript and relying on Javascript to control state isn't really the best idea.
Moreover, for someone so concerned about what the RFCs say, I'm a little surprised that you're so willing to ignore RFCs 2109 and 2965. Turns out we've already got a state management mechanism for HTTP.
Artificially bending the market to do what you want it to do is not improving anything.
Spoken like someone who wants to have to view ads every five minutes to continue a phone call.
What, are you kidding me? Between you and I, there's only one of us arguing that mandatory ads are a good thing. There's only one of us defending Apple's ridiculous patent and methods. And I do believe that there's only one of us that currently owns an iPhone (and it's not me).
those apps would quickly get deleted and never run again, and there would be lots of negative ratings as a result.
Exactly, the results are all negative.
Thus abusing such an API would be counter to the developers' best interests.
Yeah, spammers and scammers really seem to care about their reputation.
It's like trying to talk to a stone, but would you mind elaborating? How are you going to send a post request to the server from the client without submitting a form? Any solution I can think of involves a plugin like Flash. Obviously you can send whatever requests you want using XHR, but that's not going to load a new page. You still need a URL to redirect to, which is going to be a get request.
There is no technical reason for any application to absolutely require cookies.
Correct, "enhanced security" is not a technical reason, it's a policy reason. Like I said, many applications and developers subscribe to this policy.
On every get, you update the session variable. Some sites already do this.
Do you have an example?
This also prevents people from using the back button, or opening it in a second window, or hijacking a session, which is a good idea in web apps.
Not necessarily, in many applications usage of the back button and session support across multiple windows is desirable. As is refreshing the page, which your scheme also breaks. So you've broken back, refresh, and multi-window functionality in order to provide functionality that already exists with cookies.
With a scheme like this, cookies would just represent more disk i/o overhead.
With cookies, a scheme like that is not necessary.
they can in some small way improve the cell phone industry by ensuring that no one ever designs a free phone or a low cost cellular plan that is subsidized in this way
Artificially bending the market to do what you want it to do is not improving anything. If the market can sustain free ad-supported phones, who the hell is Apple to say "no, you can't do that". "Sorry, you can't get a free ad-supported phone, instead you need to buy our $600 ad-supported phone. Enjoy the customer service. Think different."
How does that "improve the industry"? If Apple wants to improve the industry then they can start by giving their own users and developers the freedom to do what they want.
If it were an API for those iPhone app writers who make two versions of their app---a free, ad-supported version and a paid version---then it would help support that model.
If Apple gave app developers the ability to use this API, do you really think that would not get abused? Are you actually that naive? An API that allows the developer to completely take over whatever the device is doing, and you think this is a positive step forward?
You want to continue playing your free game? OK, view this ad and answer the question. Good job, you got it right! Now view this ad, and answer that question. Now here's three more ads for our "affiliates", let's see if you're still paying attention before taking that call from your boss.
As I pointed out, you can also pass it around in a POST variable.
Using forms for navigation causes additional problems with bookmarking, linking, refreshes, redirecting, etc. Especially redirecting.
Also, if you're using php and the user has cookies disabled, it'll get passed around in the query string anyway.
Only with the options set a certain way, many PHP applications simply require cookies.
That just doesn't parse. At all. I can't link my dog to a cookie either - so what?
Maybe you can understand this: you can't copy and paste the URL and send it to your friend and have them be logged into your session if you're using a cookie to persist the session ID, but your session is vulnerable if you send your friend a link that includes the session ID in the querystring.
Put simply, if the options are passing the session ID through get, post, or cookies, the best solution is cookies.
Passing a session ID around in the querystring has more severe security implications than storing the session ID in a cookie. You can't link your friend to your cookie.
No it's not, the formats allow for this. A zip file can have a SWF prepended to it and still be a valid zip file. New Office documents are zip files, so an attacker could create an office document and then prepend a SWF file to it. That makes a valid zip-family file with an executable SWF payload, and the content type says that it's a Word document or whatever.
What kind of content checking do you recommend to mitigate this? Since you're asserting that everyone else's content checking is broken, then I assume that yours works, can you share it? Your extensive admin experience should give you insight that most people don't have.
He's right though; the user cares about the response time between their action and the final result.
I know that, but he asked what the difference was between SPDY and output compression. The difference is that SPDY decreases the latency, and output compression decreases the total message length. They both have an effect on the total time the user sees, but they aren't the same. Obviously combining both low latency and a smaller message would be the ideal situation, if you could transfer several files in one request that would be even better.
You are confusing a packet with the entire message. Compressing the data means there are fewer packets, but it doesn't affect the time that it takes for one packet to be transmitted. It means the overall transfer takes less time, but the time to transfer a single packet is not affected.
For the same reason that it's a lot faster to transfer one 100MB file over FTP than it is to transfer 10,000 10KB files: the overhead in setting up the connection and transfer.
Slashdot Mirror
Sunspider isn't exactly a nameless Javascript benchmark..
They mentioned Android right here:
Opera looks set to release a version of its Opera Mobile browser for Android soon -- when that happens we'll be taking Android competitors into the ring, so stay tuned.
They buried that right on the first page of the article though, so I can see how you missed it.
I don't think you can replace the browser on a Blackberry, and the article mentioned they were getting ready to have an Android comparison as well.
Does Opera Mobile include the mouse gestures? Or, finger gestures, I guess. How does it distinguish between a gesture and scrolling?
That's right, this is the American system of laissez-faire commerce at work.
As you know, laissez-faire is an American term that means "a whale's vagina". At least, that's what Ron Burgundy told me.
How about we simply disallow deceptive advertising? That would fix this and a host of other bullshit besides.
That's brilliant! In addition to outlawing it, of course we also need to be able to enforce those rules. So that means that we should set up a federal body, or maybe a commission, that could regulate false and deceptive practices in commerce and trade. Sort of like a Federal Trade Commission, if you will.
Perhaps we could implore President Wilson to consider this in his crusade against the trusts!
Yeah, I can agree with that as well. I guess my premise for the pro-cookie argument has hinged on the fact that cookies are used for persisting a local session ID, and nothing else. In an ideal world, people who exist solely to market other people's products wouldn't have a job and wouldn't interfere with my development activities.
In reality though, I'm still content to use cookies because they provide the best state management I think I can get using HTTP.
So, I'll concede that you've got several good ("reality") arguments against cookies, but I've got several good ("idealist") arguments for cookies. Between reality and idealism I think we can both agree that reality turns out to be the only thing that matters.
That being said, do you have any applications that do successfully use an alternative session-management scheme? The primary reason I've stuck with cookies for session management are that they're drop-dead easy and I've yet to receive a problem report from a user who's blocking first-party cookies. I've ever only used cookies for my local session management (I have a severe allergic reaction to advertisers, online or otherwise), so if you've got any tried-and-true methods of persisting session state without a cookie I would be interested to hear.
I haven't felt comfortable with ever using PHP's own cookie-less session handling, just because I cringe at any URL I see that contains "?PHPSESSID=". I suppose it wouldn't be too much of an issue if you had your global include file get all of the session data (start the session) and then change the session ID for the output filter, but most of what I'm doing these days is using ajax so I would have to pass the session ID back and forth with each request. Have you seen any ajax application that pass the session ID back and forth like that, or have you heard of any issues? I suppose you could use a global Javascript variable to store the current session ID to send back and use to store the new one that comes back, I just have a feeling that changing the session ID on any request would have some implications that I'm not considering.
The objection isn't to cookies per se, but to the way that they have become pervasive and intrusive.
I can agree with that.
"This site doesn't use cookies" or "Cookie-free Zone" would offer some guarantee that when they leave a site, they've truly left it behind
I agree, I'd actually like to see exemptions in the law specifically to allow same-domain session-tracking cookies without requiring explicit consent. The difficulty would be in writing that in such a way that it truly only allows session state cookies for the application you're using and nothing else, specifically marketing- and advertising-related activities. I just think that the state-preserving that cookies allow is too useful to throw the baby out with the bathwater, as it were.
The unfortunate thing about all of this is that it requires the developers to comply, I tend to think that the developers interested in complying with anything aren't really the source of the problem they're trying to fix.
You're right - it IS like talking to a stone. first hit - xmlhttprequest supports post variables, complete with code [openjs.com]. No flash involved, no plugins.
So we've gone full circle, from simply passing the session ID around in the querystring to now implementing everything in ajax (incidentally, if you're using ajax, it doesn't really matter if you pass the session ID in get or post). I'm all for ajax, everything I've done for the past few years makes a lot of use of ajax, but the vast majority of sites do not use ajax and it's a little silly to assume that every site will start using ajax as a means of passing session IDs so that they don't need to use cookies.
So, let's review. These are the options for tracking state:
1. Cookies
2. Querystring
3. Post body: Use Javascript to tranform each link to a form post, or change the site design and use ajax for all content loading, requiring you to also manually add in "back" support and making sure your users can still email links to specific pages, in addition to making sure your content can still be found by search engines.
Ask me again in a couple of years when the NDA expires.
That's convenient. So the "some sites" you mentioned before are actually just one project that you've worked on. In other words, you aren't aware of any public sites using your method.
fix your sites to comply with both the RFC and end-users' expectations of privacy
1. My sites are not broken, if the browser saves a cookie without asking consent it's not because I told the browser to save a cookie without asking consent, I just told it to save a cookie. If the browser the user happens to be using does not comply with the RFC that's not the fault of my application.
2. I would even argue that end user's expectation of privacy online includes the knowledge that sites save some sort of information about them either on the server or on their own computer. In other words, users expectation of privacy includes cookies.
From all the complaining from people who can't be arsed to even read the RFC.
I didn't realize I was complaining about anything, I just thought I was trying to get you to come up with a way to persist session state that was as convenient (for both developers and users), reliable, and secure as cookies. So far you've got passing the information along in the querystring and using ajax. If someone is hacking your cookies do you think they won't be able to figure out what information you're submitting via ajax? Do you think that using ajax is any more secure than using cookies or any other method of requesting? Sure, you can send everything over SSL, but you can also require that cookies only go over SSL. I still think that passing that information in the form of an HTTP header, in other words a cookie, is clearly more secure than the querystring and has all of the same benefits and faults of using the post body.
Too lazy to learn new ways to do things.
I'm trying to educate myself here, but you haven't told me anything I didn't already know.
I'll also point out that so far I haven't even bothered to bring up the fact that not all users run Javascript and relying on Javascript to control state isn't really the best idea.
Moreover, for someone so concerned about what the RFCs say, I'm a little surprised that you're so willing to ignore RFCs 2109 and 2965. Turns out we've already got a state management mechanism for HTTP.
Artificially bending the market to do what you want it to do is not improving anything.
Spoken like someone who wants to have to view ads every five minutes to continue a phone call.
What, are you kidding me? Between you and I, there's only one of us arguing that mandatory ads are a good thing. There's only one of us defending Apple's ridiculous patent and methods. And I do believe that there's only one of us that currently owns an iPhone (and it's not me).
those apps would quickly get deleted and never run again, and there would be lots of negative ratings as a result.
Exactly, the results are all negative.
Thus abusing such an API would be counter to the developers' best interests.
Yeah, spammers and scammers really seem to care about their reputation.
You don't need forms to use post variables.
It's like trying to talk to a stone, but would you mind elaborating? How are you going to send a post request to the server from the client without submitting a form? Any solution I can think of involves a plugin like Flash. Obviously you can send whatever requests you want using XHR, but that's not going to load a new page. You still need a URL to redirect to, which is going to be a get request.
There is no technical reason for any application to absolutely require cookies.
Correct, "enhanced security" is not a technical reason, it's a policy reason. Like I said, many applications and developers subscribe to this policy.
On every get, you update the session variable. Some sites already do this.
Do you have an example?
This also prevents people from using the back button, or opening it in a second window, or hijacking a session, which is a good idea in web apps.
Not necessarily, in many applications usage of the back button and session support across multiple windows is desirable. As is refreshing the page, which your scheme also breaks. So you've broken back, refresh, and multi-window functionality in order to provide functionality that already exists with cookies.
With a scheme like this, cookies would just represent more disk i/o overhead.
With cookies, a scheme like that is not necessary.
they can in some small way improve the cell phone industry by ensuring that no one ever designs a free phone or a low cost cellular plan that is subsidized in this way
Artificially bending the market to do what you want it to do is not improving anything. If the market can sustain free ad-supported phones, who the hell is Apple to say "no, you can't do that". "Sorry, you can't get a free ad-supported phone, instead you need to buy our $600 ad-supported phone. Enjoy the customer service. Think different."
How does that "improve the industry"? If Apple wants to improve the industry then they can start by giving their own users and developers the freedom to do what they want.
If it were an API for those iPhone app writers who make two versions of their app---a free, ad-supported version and a paid version---then it would help support that model.
If Apple gave app developers the ability to use this API, do you really think that would not get abused? Are you actually that naive? An API that allows the developer to completely take over whatever the device is doing, and you think this is a positive step forward?
You want to continue playing your free game? OK, view this ad and answer the question. Good job, you got it right! Now view this ad, and answer that question. Now here's three more ads for our "affiliates", let's see if you're still paying attention before taking that call from your boss.
As I pointed out, you can also pass it around in a POST variable.
Using forms for navigation causes additional problems with bookmarking, linking, refreshes, redirecting, etc. Especially redirecting.
Also, if you're using php and the user has cookies disabled, it'll get passed around in the query string anyway.
Only with the options set a certain way, many PHP applications simply require cookies.
That just doesn't parse. At all. I can't link my dog to a cookie either - so what?
Maybe you can understand this: you can't copy and paste the URL and send it to your friend and have them be logged into your session if you're using a cookie to persist the session ID, but your session is vulnerable if you send your friend a link that includes the session ID in the querystring.
Put simply, if the options are passing the session ID through get, post, or cookies, the best solution is cookies.
If your only motivation is money, even the IRS would rather see you do the right thing:
http://www.irs.gov/compliance/article/0,,id=180171,00.html
Passing a session ID around in the querystring has more severe security implications than storing the session ID in a cookie. You can't link your friend to your cookie.
It's not a problem for Web sites, except for their users that run crappy software (ie Flash).
That's exactly right. In other words, this only affects 99% of web users. Clearly a non-issue, and I praise your insight for pointing this out.
No it's not, the formats allow for this. A zip file can have a SWF prepended to it and still be a valid zip file. New Office documents are zip files, so an attacker could create an office document and then prepend a SWF file to it. That makes a valid zip-family file with an executable SWF payload, and the content type says that it's a Word document or whatever.
What kind of content checking do you recommend to mitigate this? Since you're asserting that everyone else's content checking is broken, then I assume that yours works, can you share it? Your extensive admin experience should give you insight that most people don't have.
Actually, no. Lynx is never, ever "for the win".
He's right though; the user cares about the response time between their action and the final result.
I know that, but he asked what the difference was between SPDY and output compression. The difference is that SPDY decreases the latency, and output compression decreases the total message length. They both have an effect on the total time the user sees, but they aren't the same. Obviously combining both low latency and a smaller message would be the ideal situation, if you could transfer several files in one request that would be even better.
You are confusing a packet with the entire message. Compressing the data means there are fewer packets, but it doesn't affect the time that it takes for one packet to be transmitted. It means the overall transfer takes less time, but the time to transfer a single packet is not affected.
Do we need a faster http? Really?
Of course not. HTTP as it exists now is perfect and sublime, and people will still be using this exact implementation over the next thousand years.
How is the separate GET slower?
For the same reason that it's a lot faster to transfer one 100MB file over FTP than it is to transfer 10,000 10KB files: the overhead in setting up the connection and transfer.
How is this different from Web servers that serve up gzipped pages?
Well, for one, gzipping output doesn't have any effect on latency.
You could also remove images, CSS, Javascript, and text, imagine the time savings!
Now I don't have to worry about throttled torrent downloads.
Uh right, problem solved there. In other news, once you get an oil change in your car you no longer have to rotate the tires.