Comments on: Customising GMail with GreaseMonkey

By: Skunk

Skunk — Wed, 31 Dec 1969 19:00:00 +0000

That is freakin' brilliant. GreaseMonkey (and bookmarklets) add a whole new angle to the idea of rich web applications - the JavaScript on the site becomes an API for customising the applications. The Google Maps bookmarklets are another great example of this.

By: cranial-bore

cranial-bore — Wed, 31 Dec 1969 19:00:00 +0000

Impressive stuff.
I have wanted to know more Javascript for a while, but I now I don't have to as my visitors can just write their own ;)

By: sil

sil — Wed, 31 Dec 1969 19:00:00 +0000

Yes indeed. This sort of thing works well as long as you have a well-defined URL API for getting at data (examine del.icio.us for the best example). If, for example, GMail used some complex URL scheme which wasn’t stable and didn’t have the same URLs for a given search (it added loads of “session ID” stuff or whatever) this would be a lot harder to write. This is why a good URL API is important, why REST is great, and why SOAP etc is a lot more of a pain, because you need SOAP built in to the browser to use it in this sort of situation.

By: Rynoguill

Rynoguill — Wed, 31 Dec 1969 19:00:00 +0000

See, i can definately agree thats great and all, i mean your giving yourself features that you don’t have provided, BUT, from a webdevelopers standpoint doesn’t this concern anyone? I mean I use a lot of things like the way forms are passed around and html along with my programming language to ensure some security. For one thing if someone gets in there and starts monkeying around (no pun intended) theyre going to more than likely screw a lot of stuff up before theyre going to get it right, which could mean bad data getting in the db, could mean security problems. While its cool, I don’t really see this as any different than another form of hacking, that personally I feel shouldn’t be allowed.

By: Jim

Jim — Wed, 31 Dec 1969 19:00:00 +0000

You should not be expecting any sort of security when your passing around forms. If you’re relying on anything that can be reached through the DOM and javascript to protect you, you really need to invest in learning better security practices. If you’re not validating user input with anything other than javascript, for instance, what do you do with someone who has it disabled?

People should be able to do what they want to a page in their browser, as long as they don’t get on your server to do it for everyone ;).

By: Jeremy Dunck

Jeremy Dunck — Wed, 31 Dec 1969 19:00:00 +0000

Rynoguill,
A responsible web app developer should not expect valid data from the browser. At all.
You can use client side JS and specific data modelling to improve user experience, but the only thing you (the developer) really control is the server, and that's where trust needs to be established.

By: Jeremy Dunck

Jeremy Dunck — Wed, 31 Dec 1969 19:00:00 +0000

You know, I was just wondering how long it might be before they think to implement URL-per-message and URL-per-conversation.

Authenticated, of course.

I just felt a need to refer to a previous email in a note to myself, and it sure would have been handy to refer to it by identifier.

By: boogs

boogs — Wed, 31 Dec 1969 19:00:00 +0000

Rynoguill,

The most important thing to remember when developing web applications is that you can never trust the client. I can't count the number of times when this has been drilled home by older, wiser souls.

Even though you are used to looking at it in a browser, where the inputs are somewhat controlled, other people are not.

Anything you put on a server is accessible to anyone using any client. It is literally impossible to keep non-browser user agents from monkeying with your public website. This is the entire idea of the web, and it is how great services like search engines are possible.

The solution is to stop making these assumptions, not to ban useful extensions like gm.

full disclosure: i wrote the initial verison of gm.

By: z0s0

z0s0 — Wed, 31 Dec 1969 19:00:00 +0000

I think Ryno’s got it now, after 3 paraphrased explanations ;-)

By: Brak

Brak — Wed, 31 Dec 1969 19:00:00 +0000

I think Ryno's got it now, after 3 paraphrased explanations ;-)

If this were any other explination, I'd say it's overkill. Unfortunately, not validating data on the server is the #1 reason for security breaches in websites. It accounts for something like 90% (or so I remeber form smewhere) of security breaches.

So, once again: We can never, ever, ever, ever trust what the browser will give us (Except in intranet apps)

I love to see developments like this, as I use bookmarklets constantly :)