headers
Glenn Maynard | 1 Feb 2011 01:05
Gravatar

Re: Appcache feedback (various threads)

On Mon, Jan 31, 2011 at 6:46 PM, Ian Hickson <ian@...> wrote:

> > That's far too generic for servers to default to mapping *.manifest to
> > text/cache-manifest.  For example, Windows uses *.manifest for SxS
> > assembly manifests.
>
> Do they have a MIME type? If not, it doesn't much matter.
>

It does if they're ever served by a webserver, because they'll be served
with a completely unrelated Content-Type.  (Also, the file format is
actually XML, so arguably they do--application/xml--though I wouldn't
configure a server that way in general.)

Microsoft's mistake is using such a generic name--but these files shouldn't
make the same mistake and lay claim to "*.manifest" as if it's the only type
of manifest that exists.  File extensions will never be without collisions,
but an effort should at least be made...

--

-- 
Glenn Maynard
Permalink | Reply | 5 comments |
headers
Ian Hickson | 1 Feb 2011 01:12
Picon

Re: Appcache feedback (various threads)

On Mon, 31 Jan 2011, Glenn Maynard wrote:
> On Mon, Jan 31, 2011 at 6:46 PM, Ian Hickson <ian@...> wrote:
> 
> > > That's far too generic for servers to default to mapping *.manifest 
> > > to text/cache-manifest.  For example, Windows uses *.manifest for 
> > > SxS assembly manifests.
> >
> > Do they have a MIME type? If not, it doesn't much matter.
> 
> It does if they're ever served by a webserver, because they'll be served 
> with a completely unrelated Content-Type.  (Also, the file format is 
> actually XML, so arguably they do--application/xml--though I wouldn't 
> configure a server that way in general.)
> 
> Microsoft's mistake is using such a generic name--but these files 
> shouldn't make the same mistake and lay claim to "*.manifest" as if it's 
> the only type of manifest that exists.  File extensions will never be 
> without collisions, but an effort should at least be made...

Given that SxS manifests don't seem like they'd ever be something you'd 
want to make available to download standalone, and that if you were going 
to expose them to a user you'd want a text/* type anyway, and that cache 
manifests are clearly different (no valid SxS manifest can be a valid 
appcache manifest), I'm honestly not finding a very compelling reason to 
make appcache manifsts have a more verbose extension. The clash here seems 
rather theoretical.

--

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
(Continue reading)

Permalink | Reply | 3 comments |
headers
Bjoern Hoehrmann | 1 Feb 2011 01:17
Picon

Re: Appcache feedback (various threads)

* Glenn Maynard wrote:
>On Mon, Jan 31, 2011 at 6:46 PM, Ian Hickson <ian@...> wrote:
>> > That's far too generic for servers to default to mapping *.manifest to
>> > text/cache-manifest.  For example, Windows uses *.manifest for SxS
>> > assembly manifests.
>>
>> Do they have a MIME type? If not, it doesn't much matter.
>
>It does if they're ever served by a webserver, because they'll be served
>with a completely unrelated Content-Type.  (Also, the file format is
>actually XML, so arguably they do--application/xml--though I wouldn't
>configure a server that way in general.)

http://lmgtfy.com/?q=application+manifest+file+mime
--

-- 
Björn Höhrmann · mailto:bjoern@... · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/
Permalink | Reply | 0 comments |
headers
Ian Hickson | 1 Feb 2011 01:20
Picon

Appcache feedback

On Thu, 30 Sep 2010, Alexey Proskuryakov wrote:
> 
> In definitions of application cache entry categories, it's mentioned 
> that an explicit entry can also be marked as foreign. This contrasts 
> with fallback entries, for which no such notice is made.
> 
> It still appears that the intention was for fallback entries to 
> sometimes be foreign - in particular, section 6.5.1 says "Let candidate 
> be the fallback resource" and then "If candidate is not marked as 
> foreign..."
> 
> I found it confusing that there is a specific mention of foreign for 
> explicit entries, but not for fallback ones.

Oops, yeah. Fixed.

On Thu, 11 Nov 2010, Michael Nordman wrote:
>
> In section "6.6.6 Changes to the networking model" which applies to sub 
> resource loads, step 3 prevents returning fallback resources for 
> requested urls that fall into a network namespace.
> 
> In section "6.5.1 Navigating across documents" which applies to main 
> resource loads, step 17 does not explicitly exclude returning fallbacks 
> for such urls.
> 
> I doubt this difference is intentional, looks like step 17 needs some 
> <additional words>...
> 
> "If the resource was not fetched from an application cache, and was to
(Continue reading)

Permalink | Reply | 2 comments |
headers
Glenn Maynard | 1 Feb 2011 01:28
Gravatar

Re: Appcache feedback (various threads)

On Mon, Jan 31, 2011 at 7:12 PM, Ian Hickson <ian@...> wrote:

> On Mon, 31 Jan 2011, Glenn Maynard wrote:
> > On Mon, Jan 31, 2011 at 6:46 PM, Ian Hickson <ian@...> wrote:
> >
> > > > That's far too generic for servers to default to mapping *.manifest
> > > > to text/cache-manifest.  For example, Windows uses *.manifest for
> > > > SxS assembly manifests.
> > >
> > > Do they have a MIME type? If not, it doesn't much matter.
> >
> > It does if they're ever served by a webserver, because they'll be served
> > with a completely unrelated Content-Type.  (Also, the file format is
> > actually XML, so arguably they do--application/xml--though I wouldn't
> > configure a server that way in general.)
> >
> > Microsoft's mistake is using such a generic name--but these files
> > shouldn't make the same mistake and lay claim to "*.manifest" as if it's
> > the only type of manifest that exists.  File extensions will never be
> > without collisions, but an effort should at least be made...
>
> Given that SxS manifests don't seem like they'd ever be something you'd
> want to make available to download standalone, and that if you were going
> to expose them to a user you'd want a text/* type anyway, and that cache
> manifests are clearly different (no valid SxS manifest can be a valid
> appcache manifest), I'm honestly not finding a very compelling reason to
> make appcache manifsts have a more verbose extension. The clash here seems
> rather theoretical.
>
(Continue reading)

Permalink | Reply | 2 comments |
headers
Ian Hickson | 1 Feb 2011 01:43
Picon

Re: Appcache feedback (various threads)

On Mon, 31 Jan 2011, Glenn Maynard wrote:
> On Mon, Jan 31, 2011 at 7:12 PM, Ian Hickson <ian@...> wrote:
> >
> > Given that SxS manifests don't seem like they'd ever be something 
> > you'd want to make available to download standalone, and that if you 
> > were going to expose them to a user you'd want a text/* type anyway, 
> > and that cache manifests are clearly different (no valid SxS manifest 
> > can be a valid appcache manifest), I'm honestly not finding a very 
> > compelling reason to make appcache manifsts have a more verbose 
> > extension. The clash here seems rather theoretical.
> 
> I've exposed cache manifests for standalone download many times.

It appears you're actually talking about ClickOnce manifests, not SxS 
manifests (though they use the same format).

These would indeed be distributed.

I've changed the suggested extension to ".appcache".

--

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Permalink | Reply | 1 comment |
headers
Michael Nordman | 1 Feb 2011 01:54
Picon
Favicon

Re: Appcache feedback

On Mon, Jan 31, 2011 at 4:20 PM, Ian Hickson <ian@...> wrote:
> On Thu, 30 Sep 2010, Alexey Proskuryakov wrote:
>>
>> In definitions of application cache entry categories, it's mentioned
>> that an explicit entry can also be marked as foreign. This contrasts
>> with fallback entries, for which no such notice is made.
>>
>> It still appears that the intention was for fallback entries to
>> sometimes be foreign - in particular, section 6.5.1 says "Let candidate
>> be the fallback resource" and then "If candidate is not marked as
>> foreign..."
>>
>> I found it confusing that there is a specific mention of foreign for
>> explicit entries, but not for fallback ones.
>
> Oops, yeah. Fixed.
>
>
> On Thu, 11 Nov 2010, Michael Nordman wrote:
>>
>> In section "6.6.6 Changes to the networking model" which applies to sub
>> resource loads, step 3 prevents returning fallback resources for
>> requested urls that fall into a network namespace.
>>
>> In section "6.5.1 Navigating across documents" which applies to main
>> resource loads, step 17 does not explicitly exclude returning fallbacks
>> for such urls.
>>
>> I doubt this difference is intentional, looks like step 17 needs some
>> <additional words>...
(Continue reading)

Permalink | Reply | 0 comments |
headers
Glenn Maynard | 1 Feb 2011 02:14
Gravatar

Re: Appcache feedback (various threads)

On Mon, Jan 31, 2011 at 7:43 PM, Ian Hickson <ian@...> wrote:

> It appears you're actually talking about ClickOnce manifests, not SxS
> manifests (though they use the same format).
>

(In that particular case, SxS manifests distributed standalone for people to
drop into application installations when troubleshooting--but the main point
was just that it's a name likely to collide.)

I've changed the suggested extension to ".appcache".
>

That seems fine.  Thanks.

--

-- 
Glenn Maynard
Permalink | Reply | 0 comments |
headers
Jonas Sicking | 1 Feb 2011 02:41
Gravatar

Re: AppCache feature request: An https manifest should be able to list resources from other https origins.

On Mon, Jan 31, 2011 at 2:57 PM, Michael Nordman <michaeln@...> wrote:
> I don't  fully understand your emphasis on the implied semantics of a
> CORS request. You say it *only* means a site can read the response. I
> don't see that in the draft spec. Cross-origin XHR may have been the
> big motivation behind CORS, but the mechanisms described in the spec
> appear agnostic with regard to use cases and the abstract section
> seems to invite additional use cases.

The spec does say what the meaning of the Access-Contol-Allow-Origin
header means. You're trying to modify that meaning.

Consider things from a web authors point of view. The author develops
a website, bunnies.com, which contains a HTML page which performs
same-site, and thus trusted, XHR requests. The HTML page additionally
exposes an API based on postMessage to allow parent frames to
communicate with it.

Since the site exposes various useful HTTP APIs it further has adds
Access-Control-Allow-Origin: <origin>
Access-Control-Allow-Credentials: true

to a set of the URLs on the site. Including the url of the static HTML
page. This is per CORS safe since the HTML page is static there is no
information leakage that doesn't happen through a normal
server-to-server request anyway.

However, with the modification you are proposing, an attacker site
could forever pin this page the users app-cache. This means that if
there is a security bug in the page, the attacker site could exploit
that security problem forever since any javascript in the page will
(Continue reading)

Permalink | Reply | 8 comments |
headers
Michael Nordman | 1 Feb 2011 03:27
Picon
Favicon

Re: AppCache feature request: An https manifest should be able to list resources from other https origins.

But... the risk you outline is not possible...

> However, with the modification you are proposing, an attacker site
> could forever pin this page the users app-cache. This means that if
> there is a security bug in the page, the attacker site could exploit
> that security problem forever since any javascript in the page will
> continue to run in the security context of bunnies.com. So all of a
> sudden the CORS headers that the site added has now had a severe
> security impact.

The bunnies.com page stored in the attacker's appcache will never be
loaded into the context of bunnies.com. There are provisions in the
the appcache system to prevent that. Those provisions guard against a
this type of attack via HTTP.

On Mon, Jan 31, 2011 at 5:41 PM, Jonas Sicking <jonas@...> wrote:
> On Mon, Jan 31, 2011 at 2:57 PM, Michael Nordman <michaeln@...> wrote:
>> I don't  fully understand your emphasis on the implied semantics of a
>> CORS request. You say it *only* means a site can read the response. I
>> don't see that in the draft spec. Cross-origin XHR may have been the
>> big motivation behind CORS, but the mechanisms described in the spec
>> appear agnostic with regard to use cases and the abstract section
>> seems to invite additional use cases.
>
> The spec does say what the meaning of the Access-Contol-Allow-Origin
> header means. You're trying to modify that meaning.

A strangely existential statement :)

> Consider things from a web authors point of view. The author develops
(Continue reading)

Permalink | Reply | 7 comments |

Gmane