The betamax case[1] determined that a product "...does not constitute contributory infringement if the product is widely used for legitimate, unobjectionable purposes. Indeed, it need merely be capable of substantial noninfringing uses...."
I think we can all agree that P2P does have substantial noninfringing uses.
The industry wants to argue three points on this: 1) that services (such as P2P sites) are significantly different than products, and so deserve their own precedent, 2) what constitutes "substantial", i.e. if we can show that only 1% of all uses are noninfringing, that is not substantial, and 3) they didn't really mean that whole "capable" thing.
Regarding (1), user scripts can't do anything as damaging as chrome (e.g. extensions).
Regarding (2), I am not content with security through obscurity. GM is getting a fair bit of press... You don't have to be a hacker to want persistent searches in GMail.
How is this revolutionary? Things like the Proxomitron have let you filter content and add user-scripts for years. Sure, Greasemonkey saves you starting up another app, but I wouldn't call it revolutionary.
I agree, "revolutionary" overstates the case. But pretty darn neat, I think, it is.:)
Greasemonkey scripts are bound by the same restrictions as any other javascript.
No, they aren't. They are inserted into the code of another site's pages, therefore they get local access priveleges over those pages.
I'm a dev on GM, and I'd like to shed some light.
First, yes, GM is in the same security sandbox as the page script. It does not run as local script.
The threat model of a user script is the very same as a bookmarklet, except that user scripts get injected without clicks, meaning that the user could forget about some installed script.
If someone installs an Evil(tm) script, it can run on pages that the evil person doesn't control, and provide data back to the evil person.
Note that such evil can be delivered in other ways (bookmarklets, toolbars, etc) which are trojans. You should consider every user script as a possible trojan.
So yeah, don't install scripts that do evil things, and if you're not sure, don't install.
We're working on a community-policed user script directory which can confer some level of trust. It's not ready yet. We were slashdotted a little too early.;) The wiki page (when it's back up) was something I put up when I first saw GM, because it clearly needed some sort of directory to get some momentum. It's now a stopgap until something more structured is completed. You might try delicious as another directory.
Also, Greasemonkey supplies some interesting functions to the user script context, including GM_xmlhttpRequest, which allows cross-domain page requests. Couple this with GM_setValue and GM_getValue, and a user script can indeed very effectively share data between different web apps. Before you wail in terror, note that information could be sent to evil third-party domain already by using scripted image tags, iframes, and form posts. GM only opens up an easier way to share data; it does not allow anything that's truly new in this respect.
While it's true that it's no small task to improve Free software, it's not even an option with non-Free software.
The example of a Photoshop feature missing from GIMP is a strawman.
Instead, consider how costly it would be to get a particular feature in Photoshop added to another non-Free application, such as FireWorks?
And more to Free's point, since you -can- add on to existing Free software, you need not buy additional software to fit the bill, or build from scratch a closed system that does what is needed.
It is, of course, true that a single freelance can't be expected to foot the (larger) bill to develop Free software over buying a copy of non-Free software-- but in this case, Free-software cooperatives can leverage the network effect.
Maybe your freelance web dev forum votes on what enhancement they'd like in their tools this month, and spends its dues that way?
Slashdot Mirror
There's an additional benefit.
After the download is done, the browser is likely to be left open while the user, you know, browses. This addresses the BT leeching problem.
Why would MS want to market a supercomputer OS?
Because they had to build one anyway; they may as well see if they can sell it.
Google is kicking their asses in the cloud-of-services arena, and its doing that on the basis of a 200,000 server farm.
MS is looking to defray their catch-up costs.
The betamax case[1] determined that a product "...does not constitute contributory infringement if the product is widely used for legitimate, unobjectionable purposes. Indeed, it need merely be capable of substantial noninfringing uses...."
a _v._Universal_City_Studios%2C_Inc.
I think we can all agree that P2P does have substantial noninfringing uses.
The industry wants to argue three points on this: 1) that services (such as P2P sites) are significantly different than products, and so deserve their own precedent, 2) what constitutes "substantial", i.e. if we can show that only 1% of all uses are noninfringing, that is not substantial, and 3) they didn't really mean that whole "capable" thing.
[1]
http://en.wikipedia.org/wiki/Sony_Corp._of_Americ
Sounds like a job for Greasemonkey.
You can do that with javascript...
How about this pattern, which is included in the book linked from this article?
Lots of people know JS and the DOM. How many know Privoxy's APIs?
Regarding (1), user scripts can't do anything as damaging as chrome (e.g. extensions).
Regarding (2), I am not content with security through obscurity. GM is getting a fair bit of press... You don't have to be a hacker to want persistent searches in GMail.
Check out the API reference to see what GM gives that bookmarklets don't (aside from automated execution).
0.3.3 is latest, and will work with FF 1.0.4.
How is this revolutionary? Things like the Proxomitron have let you filter content and add user-scripts for years. Sure, Greasemonkey saves you starting up another app, but I wouldn't call it revolutionary.
:)
I agree, "revolutionary" overstates the case. But pretty darn neat, I think, it is.
Greasemonkey scripts are bound by the same restrictions as any other javascript.
;) The wiki page (when it's back up) was something I put up when I first saw GM, because it clearly needed some sort of directory to get some momentum. It's now a stopgap until something more structured is completed. You might try delicious as another directory.
No, they aren't. They are inserted into the code of another site's pages, therefore they get local access priveleges over those pages.
I'm a dev on GM, and I'd like to shed some light.
First, yes, GM is in the same security sandbox as the page script. It does not run as local script.
The threat model of a user script is the very same as a bookmarklet, except that user scripts get injected without clicks, meaning that the user could forget about some installed script.
If someone installs an Evil(tm) script, it can run on pages that the evil person doesn't control, and provide data back to the evil person.
Note that such evil can be delivered in other ways (bookmarklets, toolbars, etc) which are trojans. You should consider every user script as a possible trojan. So yeah, don't install scripts that do evil things, and if you're not sure, don't install.
We're working on a community-policed user script directory which can confer some level of trust. It's not ready yet. We were slashdotted a little too early.
Also, Greasemonkey supplies some interesting functions to the user script context, including GM_xmlhttpRequest, which allows cross-domain page requests. Couple this with GM_setValue and GM_getValue, and a user script can indeed very effectively share data between different web apps. Before you wail in terror, note that information could be sent to evil third-party domain already by using scripted image tags, iframes, and form posts. GM only opens up an easier way to share data; it does not allow anything that's truly new in this respect.
It is contrived, indeed.
While it's true that it's no small task to improve Free software, it's not even an option with non-Free software.
The example of a Photoshop feature missing from GIMP is a strawman.
Instead, consider how costly it would be to get a particular feature in Photoshop added to another non-Free application, such as FireWorks?
And more to Free's point, since you -can- add on to existing Free software, you need not buy additional software to fit the bill, or build from scratch a closed system that does what is needed.
It is, of course, true that a single freelance can't be expected to foot the (larger) bill to develop Free software over buying a copy of non-Free software-- but in this case, Free-software cooperatives can leverage the network effect.
Maybe your freelance web dev forum votes on what enhancement they'd like in their tools this month, and spends its dues that way?