Google Blogoscoped

Forum

Extending Google Office With a Plug-in API  (View post)

stefan2904 [PersonRank 10]

Saturday, February 24, 2007
7 years ago2,824 views

Nice idea. But i think, if google donĀ“t check every plug-in for security-holes, the risk is too big. and do you thing plug-ins, which can access to your mail-value, are safe? without checking the value for passwords etc this is bad, but with it is evil!

Philipp Lenssen [PersonRank 10]

7 years ago #

No they wouldn't check every single plug-in, but instead secure the scripting language framework – by default it would need to disallow any communications with the world outside the application at hand (not to say that this is easy!). As an example of the security approach, take client-side JavaScript: you can write a lot of JavaScript that handles how a web page behaves, but you can't use JavaScript to automatically read a local file from the PC and submit it. Or at least in theory – in practice, JavaScript *does* decrease the security simply because the JavaScript implementation may contain holes.

Eytan Buchman [PersonRank 10]

7 years ago #

What happens if someone develops a mind-bogglingly awesome plug in. Something that just works brilliantly. Google, wanting to increase the general awesomeness of their product decides to integrate...Plug in functionality is duplicated in Google code, users benefit from the roll out of said awesome plug in but our poor developer no long gets his cut of the action. By definition, all of the good plug ins will be snagged by Google.

Hong Xiaowan [PersonRank 10]

7 years ago #

Great Theory. We are bosom friends. We have the same dreaming.

You are nearing Google OS instead of Google Office. Should be 3 level for the Google OS

1.Google Language, just like C++, Php, Asp or mixed. Google Language can runing at a platform of local computer(For example, Ubuntu), Google Language Team should build a unique department to make this language simple, fast and powerful. Remember the Microsoft's terrilble fat and terrible wasteness, Google should have a fresh way.

2.Google Functions, you can call it as add-ons, plug-in, I call it module. For designing a soft, we often structured it to be many simple modules. Also we can combine many recents modules to be a great soft. The Functions can be written both Google inside and outside. Google should build a quality team to test the modules to prevent most problems. Many problem created at this level. Just like Philipp says, the users may call in for Google Office problems but in fact it is the problem of Add-ons of Google Office.

3.Google Applications, in this level, even a developer can not programming, he also can design a perfect soft. They can easy combine many modules to be a soft.

Google Code can be this platform, the developer can test their Functions or Applications at Google Code online. After test, they can compile the source at Google Code and download to local computer and run it at local computer. Sure, they can also run it online. So, Google Office really is a a kind of Google Applications that should be developed by users not only google-self.

For money back, Google OS can be two, one need to pay, two free but with Adwords. For money sharing, Google should built a fair system to share the profits, I guess it is a complex system like pagerank system. The users do not want Adwords everywhere.

***For example, Google Office have many modules, when this application show a Adwords. The profit should be shared at a reasonable rate to per developer of modules instead of giving the Google Office developer only.

Hong Xiaowan [PersonRank 10]

7 years ago #

This mode, Microsoft can not keep its market position. Also Google will become a powerful company like water. You can freeze it, boiling it , but can not remove it. Water everywhere, free, but can not be removed. Microsoft's competitor is not Google, its competitors is Microsoft's users. Google is just a simple platform to jion them together.

Now, it is time to begin to say Good Bye to Microsoft.

Jan Szumiec [PersonRank 0]

7 years ago #

DabbleDB uses something called plug-outs. What it does, is you give it a url, which acts as a web service (you have to construct the web service). This web service then processes the data passed into it. Definitely safe, not necessarily fast or reliable, or convenient, but it works. :)

Greg Bays [PersonRank 0]

7 years ago #

I provided a link to you on my blog. I was speculating this about a month ago on my blog and look forward to the day that the contacts portion of Gmail will be open with an api. You get it. We add the functionality that we need and nothing more.

Philipp Lenssen [PersonRank 10]

7 years ago #

Do you have a permalink to your post in question Greg?

Pamela Fox [PersonRank 2]

7 years ago #

Have you played around with the Spreadsheets API JSON feed? It actually only takes about 10 lines total to make a gadget to read in your spreadsheet and make a random quote gadget, sorted to-do list gadget, map of your favorite places, etc. With a bit more server-side scripting, I've used the API to create self-updating spreadsheets to track various things, and then fed those into a spreadsheets -> chart wizard I made a while back. (Most of that I did before I started working for Google).

The API is there (atleast for spreadsheets, which is in my opinion the most powerful) – the question is more about the publicity of what's available, and making it a fast process for a novice user to choose an add-on. Your post has some great ideas in it for what the user experience could be like.

Damian [PersonRank 0]

7 years ago #

I think, that it would be a killer! I hope the take your idea seriouslly, because that will put them forward against any competitor and most importatn the users will be very beneficied by that.

Hong Xiaowan [PersonRank 10]

7 years ago #

Yes, Damian, this should be the top secrets of Google.

Mike Samuel [PersonRank 0]

7 years ago #

Security is a serious concern for a plugin model since you wouldn't want to allow this to become a vector for malware, but there are some security models that could make this work.

If you adopt the model that the embedding application can restrict which urls the plugin can access, then you could make sure the plugin can interact with the app (same-domain) but can't steal user data and send it out of the application. That might reduce the incentive to write malware, limiting malware writers to causing annoyances.

How can you do that in practice? Well you have to restrict access to the DOM, to XMLHttpRequest, CSS, etc.

One way to do that and still allow people to write plugins that could do anything would be to allow generation of HTML and CSS via templating languages that are known to produce safe outputs – where you can check dynamically anything that would cause the browser to issue a request.

Source code rewriting can get you the rest of the way – rewriting global references so that they can't access the DOM (including window) directly, and closing off eval and other arbitrary code execution functions, preventing changes to base prototypes, and access to things like .constructor, and .caller.

This thread is locked as it's old... but you can create a new thread in the forum. 

Forum home

Advertisement

 
Blog  |  Forum     more >> Archive | Feed | Google's blogs | About
Advertisement

 

This site unofficially covers Google™ and more with some rights reserved. Join our forum!