[chromium-dev] Re: [extensions] content-type

2009-05-11 Thread Aaron Boodman
On Mon, May 11, 2009 at 12:12 PM, Peter Kasting wrote: > On Mon, May 11, 2009 at 12:02 PM, Aaron Boodman wrote: >> >> That is a good idea. We could just use the same download UI and >> everything. When you click "yes" in the shelf, it just leads to the >> normal install dialog. > > Note, the pla

[chromium-dev] Re: [extensions] content-type

2009-05-11 Thread Peter Kasting
On Mon, May 11, 2009 at 12:02 PM, Aaron Boodman wrote: > That is a good idea. We could just use the same download UI and > everything. When you click "yes" in the shelf, it just leads to the > normal install dialog. Note, the plan is to change when the download prompting occurs to be based on h

[chromium-dev] Re: [extensions] content-type

2009-05-11 Thread Adam Barth
On Mon, May 11, 2009 at 12:02 PM, Aaron Boodman wrote: > On Mon, May 11, 2009 at 11:59 AM, Darin Fisher wrote: >> >> We should use the same messaging that we use for downloaded >> executables.  Or, at least we should not make downloaded extensions >> seem less scary than downloaded executables.

[chromium-dev] Re: [extensions] content-type

2009-05-11 Thread Aaron Boodman
On Mon, May 11, 2009 at 11:59 AM, Darin Fisher wrote: > > We should use the same messaging that we use for downloaded > executables.  Or, at least we should not make downloaded extensions > seem less scary than downloaded executables. That is a good idea. We could just use the same download UI a

[chromium-dev] Re: [extensions] content-type

2009-05-11 Thread Darin Fisher
We should use the same messaging that we use for downloaded executables. Or, at least we should not make downloaded extensions seem less scary than downloaded executables. -Darin On Mon, May 11, 2009 at 11:40 AM, Nick Baum wrote: > Not all extensions will be hosted in the gallery, some will

[chromium-dev] Re: [extensions] content-type

2009-05-11 Thread Adam Barth
On Mon, May 11, 2009 at 11:40 AM, Nick Baum wrote: > Not all extensions will be hosted in the gallery, some will be private > (hosted on intranet, etc). Maybe the thing to do is have the confirmation interaction look similar to the gallery install page for a just-uploaded extension. That way we

[chromium-dev] Re: [extensions] content-type

2009-05-11 Thread Nick Baum
Not all extensions will be hosted in the gallery, some will be private (hosted on intranet, etc). -Nick On Mon, May 11, 2009 at 11:21 AM, Adam Barth wrote: > > 2009/5/11 Nick Baum : > > I'd like to avoid the "An unknown party wishes to install an extension." > phrasing. It's scary and I don't th

[chromium-dev] Re: [extensions] content-type

2009-05-11 Thread Adam Barth
2009/5/11 Nick Baum : > I'd like to avoid the "An unknown party wishes to install an extension." > phrasing. It's scary and I don't think this actually helps the users make a > decision (and often this will happen in legitimate cases where the developers > simply can't set the MIME type). > Cou

[chromium-dev] Re: [extensions] content-type

2009-05-11 Thread Nick Baum
I'd like to avoid the "An unknown party wishes to install an extension." phrasing. It's scary and I don't think this actually helps the users make a decision (and often this will happen in legitimate cases where the developers simply can't set the MIME type). Could we do something like: "Are you su

[chromium-dev] Re: [extensions] content-type

2009-05-07 Thread Adam Barth
On Thu, May 7, 2009 at 9:12 PM, Aaron Boodman wrote: > Just to clarify, you understand we're talking about a binary package > here, right? Not a text file. Oh, I didn't realize that, but I'm not sure it makes much of a difference. > Chrome extensions are distributed in what are essentially zip

[chromium-dev] Re: [extensions] content-type

2009-05-07 Thread Aaron Boodman
On Thu, May 7, 2009 at 4:20 PM, Adam Barth wrote: > On Thu, May 7, 2009 at 4:17 PM, Aaron Boodman wrote: >> Ok, thanks for the recommendation. Currently the magic string is >> "Cr24". Not enough characters? > > I suggested the above to be analogous to HTML5's appcache manifests: > > http://www.w

[chromium-dev] Re: [extensions] content-type

2009-05-07 Thread Adam Barth
On Thu, May 7, 2009 at 4:17 PM, Aaron Boodman wrote: > Ok, thanks for the recommendation. Currently the magic string is > "Cr24". Not enough characters? I suggested the above to be analogous to HTML5's appcache manifests: http://www.whatwg.org/specs/web-apps/current-work/#a-sample-manifest In

[chromium-dev] Re: [extensions] content-type

2009-05-07 Thread Aaron Boodman
On Thu, May 7, 2009 at 4:09 PM, Adam Barth wrote: > Ugg. I know. What can I say? We are caught between idealism and practicality. > 1) If the response has the right MIME type, then we can believe that > the site has endorsed the extension.  As Adam says, "Site > http://foo.bar.com wises to inst

[chromium-dev] Re: [extensions] content-type

2009-05-07 Thread Adam Barth
On Thu, May 7, 2009 at 3:55 PM, Aaron Boodman wrote: > On Thu, May 7, 2009 at 3:52 PM, Evan Martin wrote: >> Options here (I can't tell if you're suggesting #2 or #3): >> 1) filename extension only (what I'm suggesting) >> 2) require both filename extension and sniffing to match (seems to be >>

[chromium-dev] Re: [extensions] content-type

2009-05-07 Thread Aaron Boodman
On Thu, May 7, 2009 at 3:52 PM, Evan Martin wrote: > You have two use cases in mind here, and I think your solutions are mixing > them. > In the (rare) case where someone has the correct mime type set, we > should obey the mime type and do no sniffing.  I think that's > non-controversial. Yes,

[chromium-dev] Re: [extensions] content-type

2009-05-07 Thread Evan Martin
On Thu, May 7, 2009 at 3:35 PM, Aaron Boodman wrote: > Right now, the extension system treats any downloaded file that ends > in ".crx" as an extension. > > This seems like a bad idea, and that we should use a content type. You have two use cases in mind here, and I think your solutions are mixi

[chromium-dev] Re: [extensions] content-type

2009-05-07 Thread Adam Langley
On Thu, May 7, 2009 at 3:35 PM, Aaron Boodman wrote: > I know that content sniffing is a very dirty business, but our crx > files have a very specific format, including a few signature bytes at > the very beginning. What if we supported both a content-type *and* did > content sniffing of down