Need a car?

blakeyrat

The key differences are: single-user paradigm,

I have no idea what that means. What makes a mobile browser more or less single-user than a PC user account?

no right-click, no hover, larger hit area for buttons (because of the size of fingers), higher network latency and weaker processing resources (CPU and RAM).

If your web app relies on any of these things, it's already fucking broken. Tablet PCs have existed far longer than mobile tablets, and the same "rules" apply to those.

@Ronald said:

You can also use other means such as detecting the browser configuration (see how unique you are using this demo from the EFF).

Unreliable as fuck, ESPECIALLY on mobile. I don't give a shit what the EFF says.

@Ronald said:

So at the moment there is not one major technology that replaces cookies but you can work around them and on a mobile this is worth it.

Oh here's where you get to the part where you admit I'm right.

@Ronald said:

It would be convenient if mobile vendors could agree on something, like Google supporting Apple IDFA, but that fragmentation is not something new. Web development has been done for years with browser-specific limitations (that's why stylesheets are filled with -webkit and -moz prefixes).

If they can't compromise on something important, like what video codecs to support in HTML5, what the fuck makes you think they can compromise over something to save maybe 3k of data usage a day? You're living in a fantasy world of elves and fairies.

error

@blakeyrat said:

If they can't compromise on something important, like what video codecs to support in HTML5, what the fuck makes you think they can compromise over something to save maybe 3k of data usage a day?

I love that for even the <audio> tag to be mostly cross-browser, you have to have a minimum of two audio stream formats (usually, ogg and mp3). Mozilla won't support MP3 because it's not free and Microsoft won't support Ogg because it is.

PJH

@joe.edwards said:

and Microsoft and Apple won't support Ogg because ~~it is~~ of the risk of a submarine patent .

FTFY.

error

You're scaring off the fish.

Also, Montgomery does a decent job responding in that interview.

dkf

@Faxmachinen said:

Cookies are only becoming obsolete because frameworks like jQuery and Dojo make it easy to build entire applications in JS, not because of bandwidth considerations.

Are you talking about session cookies or persistent cookies? Session cookies are very unlikely to be going away soon; there'll continue to be lots of apps that want to handle logins to sites and things like that, and all the server side parts of that interaction are usually driven by session cookies. (You can't use per-GET crypto-tokens unless you authenticate to the authN provider on every connect; I bet you don't want that, as that's very slow!) You also can't substitute with long-open sockets (networks aren't that reliable) or geolocation (many devices can move quite a bit between networks being available, sometimes many people are in close proximity)and URL rewriting is a horrific workaround, as it ends up putting security tokens in the site log. Persistent cookies are less critical; there are some viable alternatives, even if they're not actually simpler in any real sense (persistent cookies have a number of actual advantages if used right, though you know and I know that's not universal).

JQuery and other client-side JS frameworks sit on top of the cookie system. Maybe you're doing smaller requests because of using them, but you're still needing to pass critical session state around and that's where session cookies are precisely the right thing. (OTOH, normal JS shouldn't be able to poke around in the cookie jar.)

daveime

@Ben L. said:

For a typical web page, the browser will make multiple requests (one for the company logo, one for the background image, etc), none of which would contain the session ID in the URL. With each of those requests the browser will happily upload the cookies for the entire domain. That means all the cookies for the domain uploaded for each request to ANY content hosted on that domain. This quickly adds up to a lot more than having the ID in some of the URLs (which I never suggested in the first place).

Pardon my ignorance, but won't this "extended" URL replete with session id information be passed in the referer header anyway, whatever content type is requested (and indeed be passed even to OTHER domains you're getting content from, whether they are subdomains of your website, or the latest Facebook sharing widget) ?

As blakey said, you've just moved the problem from one place to another, you haven't actually changed your bandwidth consumption at all ! And for all intents and purposes, you are potentially broadcasting your session ID to other peoples websites also !

I'm not sure I'm willing to trade my session security for 20 bytes saved.Especially when you are probably not saving them anyway.

Ben L.

@daveime said:

@Ben L. said:
For a typical web page, the browser will make multiple requests (one for the company logo, one for the background image, etc), none of which would contain the session ID in the URL. With each of those requests the browser will happily upload the cookies for the entire domain. That means all the cookies for the domain uploaded for each request to ANY content hosted on that domain. This quickly adds up to a lot more than having the ID in some of the URLs (which I never suggested in the first place).
Pardon my ignorance, but won't this "extended" URL replete with session id information be passed in the referer header anyway, whatever content type is requested (and indeed be passed even to OTHER domains you're getting content from, whether they are subdomains of your website, or the latest Facebook sharing widget) ?
As blakey said, you've just moved the problem from one place to another, you haven't actually changed your bandwidth consumption at all ! And for all intents and purposes, you are potentially broadcasting your session ID to other peoples websites also !
I'm not sure I'm willing to trade my session security for 20 bytes saved.Especially when you are probably not saving them anyway.

What the fuck? I never said any of that!

HardwareGeek

@Ben L. said:

@daveime said:
@~~Ben L.~~Ronald said:
For a typical web page, the browser will make multiple requests (one for the company logo, one for the background image, etc), none of which would contain the session ID in the URL. With each of those requests the browser will happily upload the cookies for the entire domain. That means all the cookies for the domain uploaded for each request to ANY content hosted on that domain. This quickly adds up to a lot more than having the ID in some of the URLs (which I never suggested in the first place).
Pardon my ignorance, but won't this "extended" URL replete with session id information be passed in the referer header anyway, whatever content type is requested (and indeed be passed even to OTHER domains you're getting content from, whether they are subdomains of your website, or the latest Facebook sharing widget) ?
As blakey said, you've just moved the problem from one place to another, you haven't actually changed your bandwidth consumption at all ! And for all intents and purposes, you are potentially broadcasting your session ID to other peoples websites also !
I'm not sure I'm willing to trade my session security for 20 bytes saved.Especially when you are probably not saving them anyway.

What the fuck? I never said any of that!

Apparently, daveime responded to a post of yours in which you quoted Ronald, but daveime messed up the nested quotations. Meh, it happens. That's what "Preview" is for.