Fyi: This change has been made in chrome.
* respect "no-store" headers for cross-origin resources (only for HTTPS)
* allow HTTPS cross-origin resources to be listed in manifest hosted on
HTTPS
On Mon, Feb 14, 2011 at 5:04 PM, Michael Nordman wrote:
> Fyi... I'm planning on making a change along t
Fyi... I'm planning on making a change along these lines to chrome soon...
* respect "no-store" headers for cross-origin resources
* allow HTTPS cross-origin resources
On Tue, Feb 8, 2011 at 3:25 PM, Michael Nordman wrote:
> Hi again,
>
> Just had an offline discussion about this and I think the
Hi again,
Just had an offline discussion about this and I think the answer can
be much simpler than what's been proposed so far. All we have to do
for cross-origin HTTPS resources is respect the cache-control no-store
header.
Let me explain the rationale... first let's back up to the motivation
On Mon, Feb 7, 2011 at 4:35 PM, Jonas Sicking wrote:
> On Mon, Feb 7, 2011 at 3:31 PM, Ian Hickson wrote:
>> On Mon, 7 Feb 2011, Jonas Sicking wrote:
>>> On Mon, Jan 31, 2011 at 6:27 PM, Michael Nordman
>>> wrote:
>>> > But... the risk you outline is not possible...
>>> >
>>> >> However, with t
On Mon, Feb 7, 2011 at 3:31 PM, Ian Hickson wrote:
> On Mon, 7 Feb 2011, Jonas Sicking wrote:
>> On Mon, Jan 31, 2011 at 6:27 PM, Michael Nordman wrote:
>> > But... the risk you outline is not possible...
>> >
>> >> However, with the modification you are proposing, an attacker site
>> >> could fo
On Mon, Feb 7, 2011 at 3:27 PM, Jonas Sicking wrote:
> On Mon, Jan 31, 2011 at 6:27 PM, Michael Nordman wrote:
>> 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 mean
On Mon, 7 Feb 2011, Jonas Sicking wrote:
> On Mon, Jan 31, 2011 at 6:27 PM, Michael Nordman wrote:
> > 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
On Mon, Jan 31, 2011 at 6:27 PM, Michael Nordman wrote:
> 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 attack
On Mon, Feb 7, 2011 at 6:18 AM, Anne van Kesteren wrote:
> On Fri, 04 Feb 2011 23:15:44 +0100, Michael Nordman
> wrote:
>>
>> Just want to wake this thread up and say that I still see CORS as a
>> good fit for this use case, and I'm curious Jonas about what you think
>> in light of my previous po
On Fri, 04 Feb 2011 23:15:44 +0100, Michael Nordman
wrote:
Just want to wake this thread up and say that I still see CORS as a
good fit for this use case, and I'm curious Jonas about what you think
in light of my previous post?
I think Jonas does have a point. There are side effects to settin
Hi again,
Just want to wake this thread up and say that I still see CORS as a
good fit for this use case, and I'm curious Jonas about what you think
in light of my previous post?
-Michael
On Mon, Jan 31, 2011 at 6:27 PM, Michael Nordman wrote:
> But... the risk you outline is not possible...
>
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
On Mon, Jan 31, 2011 at 2:57 PM, Michael Nordman 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 COR
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
On Fri, Jan 28, 2011 at 2:13 PM, Michael Nordman wrote:
> On Thu, Jan 27, 2011 at 8:30 PM, Jonas Sicking wrote:
>> On Thu, Jan 27, 2011 at 5:16 PM, Michael Nordman wrote:
>>> A CORS based answer to this would work for the folks that have
>>> expressed an interest in this capability to me.
>>>
>>
On Thu, Jan 27, 2011 at 8:30 PM, Jonas Sicking wrote:
> On Thu, Jan 27, 2011 at 5:16 PM, Michael Nordman wrote:
>> A CORS based answer to this would work for the folks that have
>> expressed an interest in this capability to me.
>>
>> cc'ing some other appcache implementors too... any thoughts?
>
On Thu, Jan 27, 2011 at 5:16 PM, Michael Nordman wrote:
> A CORS based answer to this would work for the folks that have
> expressed an interest in this capability to me.
>
> cc'ing some other appcache implementors too... any thoughts?
CORS has the semantics of "you're allowed to make these types
A CORS based answer to this would work for the folks that have
expressed an interest in this capability to me.
cc'ing some other appcache implementors too... any thoughts?
On Wed, Jan 26, 2011 at 12:28 PM, Michael Nordman wrote:
> I was alluding to a simple robots.txt like solution with the sta
I was alluding to a simple robots.txt like solution with the static
'allow' file, but it seems like CORS could work too, it is more
burdensome to setup due to the additional HTTP headers.
GET /some-resource
Origin: https://acme.com
HTTP/1.x 200 OK
Access-Control-Allow-Origin: * | https://acme.com
On Tue, 25 Jan 2011 23:37:55 +0100, Michael Nordman
wrote:
Would the public-webapps list be better for discussing appcache
feature requests?
It's not a feature drafted in any of the WebApps WG specifications. If you
want to discuss at the W3C the appropriate place would be the HTML WG.
Al
Would the public-webapps list be better for discussing appcache
feature requests?
This could be as simple as the presence of an
'applicationcaching_allowed' file at the top level. An https manifest
update that wants to retrieve resources from another https origin
would first have to fetch the 'all
AppCache feature request: An https manifest should be able to list
resources from other https origins.
I've got some app developers asking for this feature. Currently, it's
explicitly disallowed by the the spec for valid security reasons, but
there are also valid reasons to have this capability, l
22 matches
Mail list logo
