I've been following this thread (and similar threads) with interest.
I've written a blog post about some of the challenges I see facing
developers who would like to use "HTML5" and the emerging
browser-based platform versus relying on, for example, Apple's App
Store, or, indeed, any native applicat
Anne van Kesteren wrote:
On Tue, 11 May 2010 07:10:59 +0200, Nathan wrote:
exactly, but the current set up stops xhr from getting resources that
the could be retrieved from site A with wget - with an inverted model
all the issues would disappear, leaving only one issue; namely
informing sys a
On Mon, May 10, 2010 at 4:34 PM, Dirk Pranke wrote:
> 3) UMP appears to be nearly a subset of CORS, and does have a lot of
> nice properties for security and simplicity. We support UMP and would
> like to see the syntax continue to be unified with CORS so that it is
> in fact a subset (I believe
On May 11, 2010, at 10:03 AM, ext Nathan wrote:
One request though, does anybody have a chart or note of UA support
for
CORS? (even partial definitely doesn't work in x,y,z)
Some implementation data re CORS is available at:
http://www.w3.org/Security/wiki/
Comparison_of_CORS_and_UMP#User_
Boris Zbarsky wrote:
On 5/11/10 1:10 AM, Nathan wrote:
[!snip]
Boris, all,
I honestly don't have the solutions (as you can easily see) - what I can
see is that with CORS as it stands, and with same origin rules, then the
web is about as safe as it can get from xss, which is crucial. This
wo
On 5/11/10 1:10 AM, Nathan wrote:
it's almost inevitable that somebody
will make another OS browser that doesn't respect site origin policies
and CORS
And sites will then blacklist it, while users using it will get
exploited. So it won't gain significant market share, and the problem
will re
On Tue, 11 May 2010 07:10:59 +0200, Nathan wrote:
exactly, but the current set up stops xhr from getting resources that
the could be retrieved from site A with wget - with an inverted model
all the issues would disappear, leaving only one issue; namely informing
sys admins that they must pr
Boris Zbarsky wrote:
On 5/11/10 12:27 AM, Nathan wrote:
This leaves us in a scenario where it is the norm to download, install
and trust an application that runs in the browser
Perhaps. The difference is that it's much harder to do a drive-by app
install.
agree~ish, imho it's more the use
On 5/11/10 12:27 AM, Nathan wrote:
This leaves us in a scenario where it is the norm to download, install
and trust an application that runs in the browser
Perhaps. The difference is that it's much harder to do a drive-by app
install.
agree~ish, imho it's more the user giving the Site A po
Over the past few years numerous others have hit this issue, for
instance TimBL and his team on the Tabulator project - they had to move
to a browser extension where the access is granted, as have many others,
and as I'll probably end up doing, and those that follow after me.
quote TimBL yeste
On 5/10/10 11:14 PM, Nathan wrote:
2: Implement a user UI confirmation screen to allow JS applications xhr
access to other origin resources. (Similar to the allow desktop
notifications scenario in chromium)
Under what conditions would the typical user be able to make an
informed decision here?
Boris Zbarsky wrote:
On 5/10/10 10:21 PM, Nathan wrote:
2: Implement a user UI confirmation screen to allow JS applications xhr
access to other origin resources. (Similar to the allow desktop
notifications scenario in chromium)
Under what conditions would the typical user be able to make an in
On 5/10/10 10:21 PM, Nathan wrote:
2: Implement a user UI confirmation screen to allow JS applications xhr
access to other origin resources. (Similar to the allow desktop
notifications scenario in chromium)
Under what conditions would the typical user be able to make an informed
decision here?
Jonas Sicking wrote:
On Mon, May 10, 2010 at 6:38 PM, Bjoern Hoehrmann wrote:
* Nathan wrote:
If you do not depend on a user's special standing with a third party
site, you can configure your server as proxy between your user and the
third party site. That's more difficult for you, but easier
On Mon, May 10, 2010 at 6:38 PM, Bjoern Hoehrmann wrote:
> * Nathan wrote:
>>> If you do not depend on a user's special standing with a third party
>>> site, you can configure your server as proxy between your user and the
>>> third party site. That's more difficult for you, but easier for users
>
* Nathan wrote:
>> If you do not depend on a user's special standing with a third party
>> site, you can configure your server as proxy between your user and the
>> third party site. That's more difficult for you, but easier for users
>> and maintainers of third party sites. If we'd do away with th
Bjoern Hoehrmann wrote:
* Nathan wrote:
Personally, I don't follow why JS running in a user agent should have
completely different access rules to the rest of the web, primarily
because a few site admin's feel it's a good idea to expose sensitive
data via IP-based auth on intranets / on the we
* Nathan wrote:
>Personally, I don't follow why JS running in a user agent should have
>completely different access rules to the rest of the web, primarily
>because a few site admin's feel it's a good idea to expose sensitive
>data via IP-based auth on intranets / on the web via stateful session
Dirk Pranke wrote:
Hi all,
A couple weeks back there was a question as to implementor support for
UMP and CORS, and that ended up launching a longish thread on the
chromium-dev mailing list [1].
Tyler Close has asked me to summarize the conclusions of that thread
here, so ...
1) CORS is alread
Hi all,
A couple weeks back there was a question as to implementor support for
UMP and CORS, and that ended up launching a longish thread on the
chromium-dev mailing list [1].
Tyler Close has asked me to summarize the conclusions of that thread
here, so ...
1) CORS is already implemented and shi
20 matches
Mail list logo
