On Sat, Jun 21, 2008 at 6:51 PM, Bjoern Hoehrmann [EMAIL PROTECTED] wrote:
The stated goal was to balance easy protection against session riding
attacks without compromising privacy too much. Allowing session riding
via some sites but not others is something that cannot be done securely
today
On Mon, Jun 23, 2008 at 2:35 PM, Jonas Sicking [EMAIL PROTECTED] wrote:
What I have seen suggestions for though is a simpler policy language that
doesn't send a full white-list to the client, but rather just a yes/no
decision to the client.
If we go this route, we should be careful about
On Tue, Dec 9, 2008 at 12:42 PM, Marcos Caceres
[EMAIL PROTECTED] wrote:
If authors want to use application/xml,
then they can use content src=somefile type=application/xml /
and hope for the best :)
I haven't been following the widget discussion very closely, so I
apologize if this issue is
On Wed, Dec 10, 2008 at 2:55 AM, Marcos Caceres
[EMAIL PROTECTED] wrote:
The content element is defined here:
http://dev.w3.org/2006/waf/widgets/#the-content
Would certainly appreciate more details about the security threat.
Thanks for the pointer. As timeless points out, this doesn't look
On Mon, Jan 5, 2009 at 9:06 AM, Bil Corry b...@corry.biz wrote:
My demo that is listed (http://www.corry.biz/neverleave.lasso) will require
you forcibly terminate
your browser, so open it with a browser you want to forcibly terminate.
Chrome lets me leave that page without terminating the
Yeah, Thomas Roessler suggested that. Would you find that helpful?
On Sat, Jan 17, 2009 at 3:47 AM, Anne van Kesteren ann...@opera.com wrote:
Hi Adam,
I heard you might be going to work on an IETF draft for the Origin header
which both HTML5 and CORS (formerly access-control) could
On Mon, Jan 19, 2009 at 4:51 AM, Arthur Barstow art.bars...@nokia.com wrote:
Yes, I too am interested in the timeline for the Origin spec at the IETF.
I'm in the process of writing version 00. I'd imagine I'll upload
version 00 in the next few days.
Also, where can we find the latest version
On Mon, Jan 19, 2009 at 7:39 AM, Adam Barth w...@adambarth.com wrote:
On Mon, Jan 19, 2009 at 4:51 AM, Arthur Barstow art.bars...@nokia.com wrote:
Yes, I too am interested in the timeline for the Origin spec at the IETF.
I'm in the process of writing version 00. I'd imagine I'll upload
On Sat, Jan 24, 2009 at 7:03 AM, Anne van Kesteren ann...@opera.com wrote:
I'm wondering whether it's a good idea to define that the Origin header is
always included for all those type of requests. Is that really what we want?
Or do we want to use it for CORS, HTML form submission, and maybe
Hi Marcos,
On Fri, Jan 30, 2009 at 8:17 AM, Marcos Caceres
marcosscace...@gmail.com wrote:
As our Widget packaging
spec [2] has some dependency on content sniffing, we would like to
contribute to this specification where possible.
Great! Currently, the draft is optimized for resources
On Tue, Feb 3, 2009 at 7:39 AM, Marcos Caceres marcosscace...@gmail.com wrote:
At the moment, [1] reads:
For resources fetched from the file system, user agents should use
platform-specific conventions, e.g. operating system extension/type
mappings.
We are concerned that operating
On Sun, Apr 5, 2009 at 2:36 PM, William Edney
bed...@technicalpursuit.com wrote:
I've tried a few of the CORS examples out there, and they all fail in this
scenario (load the page containing the JS code from the 'file://' system and
try to access the test server).
I'm surprised this doesn't
On Mon, Apr 6, 2009 at 2:19 AM, Thomas Roessler t...@w3.org wrote:
Perhaps it's worthwhile to summarize the Mozilla-internal discussions and
send them here first? I'm having a sense that much of what's needed right
now is for somebody to ask the right questions.
I'll let someone from Mozilla
On Mon, Apr 6, 2009 at 8:01 AM, Bil Corry b...@corry.biz wrote:
Nevermind, I forgot that Adam conceded to changing his original Origin spec
to match the redirect behavior in CORS, and reading through his draft, I see
the change has been made to make them compatible.
Yes. This is not ideal
On Mon, Apr 6, 2009 at 2:09 PM, Bil Corry b...@corry.biz wrote:
Can we please include the Origin header for all same-origin requests,
including GET and HEAD? Or is there a compelling reason why not do to so?
Also, would there be value in having Origin sent for *all* requests, and if
On Tue, Apr 7, 2009 at 10:24 AM, Bil Corry b...@corry.biz wrote:
How set in stone is Origin within CORS?
I don't think we want to impede CORS with these issues. CORS is quite
close to shipping in a number of implementations. I certainly don't
want to hold it hostage.
The ideal scenario would
On Wed, Apr 8, 2009 at 10:34 AM, Bil Corry b...@corry.biz wrote:
Is draft-abarth-origin-00.txt entirely compatible now with CORS-Origin?
Yes, as far as I know. If you find any incompatibility, please let me
know and I'll fix it.
Adam
On Thu, Apr 9, 2009 at 8:48 AM, Bil Corry b...@corry.biz wrote:
My point is that a robust Origin moves us closer to better security controls,
perhaps not all the way, but certainly much closer than CORS-Origin gets us.
I think we should focus on clear use cases and techniques that address
This is to support things like data URLs that can't be represented as
a (scheme, host, port) tuple.
Adam
On Thu, Apr 9, 2009 at 9:48 AM, Bil Corry b...@corry.biz wrote:
I wanted to clarify something in the IETF Origin draft[1], which is now going
to serve as the basis for HTML5's Origin.
it's sent to the server (Section 4.2 Step
1). If it will be sent as null, then why not just have Section 2 Step 3
skip the implementation-defined value and instead set it to null? Or is
there another use client-side for the implementation-defined value?
- Bil
Adam Barth wrote on 4/11/2009
Yeah, this requirement doesn't make very much sense:
User agents should guard against sites storing data in the storage
areas or databases of subdomains, e.g. storing up to the limit in
a1.example.com, a2.example.com, a3.example.com, etc, circumventing the
main example.com storage limit.
Someone
On Wed, Apr 29, 2009 at 1:30 AM, Ian Hickson i...@hixie.ch wrote:
I've changed it a bit, because it seems UAs are likely to still want a
per-origin limit. But I'm not really sure what to suggest that's more
concrete that the vague handwaving that is there now.
Yeah, I'm not sure how to guard
On Mon, May 25, 2009 at 2:34 PM, Marcos Caceres marc...@opera.com wrote:
should the following inline resources load?
html
script src='http://foo.com/ /script
img src=http://foo.com/image;
iframe src=http://bar.com;
I haven't studied the widgets use case in detail, but these sorts of
loads
On Mon, May 25, 2009 at 3:24 PM, Marcos Caceres marc...@opera.com wrote:
I know what origin means, what I was asking is what is the origin
for the widget example above? (for fun, pretend I sent the widget to
you over BlueTooth)
You might consider using a unique identifier, similar to how HTML5
I haven't read all the threads about the widget URI scheme, but I
wanted to contribute this thought:
Instead of using a UUID as the authority, you might consider using a
public key. You could then require that the widget is signed by the
cooresponding private key.
Using a public key has several
On Wed, May 27, 2009 at 9:05 AM, Henri Sivonen hsivo...@iki.fi wrote:
On May 27, 2009, at 18:32, Adam Barth wrote:
3) A developer can write two widgets that occupy the same origin
(again, but re-using the public key). These widgets will be able to
interact more freely, for example by sharing
On Wed, May 27, 2009 at 1:58 PM, Arve Bersvendsen ar...@opera.com wrote:
1. A widget is simply a packaging for any application, and may use any
technology a widget user agent supports, so in that sense, a widget that
supports HTML5 should support anything in widget transparently and without
Hi Mark,
Thanks for your feedback. At a high level, you seem concerned about
very advanced sites (e.g., ones use object-capability mashups). The
Origin-header-as-CSRF-defense is aimed at making CSRF defense easier
for simple sites. Just like you need to do complex gymnastics to
avoid XSS when
On Fri, Jun 5, 2009 at 9:42 PM, Mark S. Miller erig...@google.com wrote:
[+www-tag]
I have received several private responses to my post, but oddly, nothing
public yet. In these responses, I have been asked most frequently about:
Sorry for the lag in public comments.
On Wed, Jun 3, 2009 at
On Sun, Jun 7, 2009 at 2:53 PM, Mark S. Miller erig...@google.com wrote:
While I clearly am concerned about object-capability mashups, from your
response, and from some private responses I've received, I have clearly
created some confusion by leading with this example. The point I am making
On Sun, Jun 7, 2009 at 3:21 PM, Mark S. Miller erig...@google.com wrote:
If the hypothesis I am raising is indeed not a problem, then it doesn't
matter whether these same origin requests carry Origin: null or nothing.
What matters is that JavaScript code have a standard way to request their
On Sun, Jun 7, 2009 at 3:46 PM, Mark S. Miller erig...@google.com wrote:
[- all but Adam and pubic-webapps]
On Sun, Jun 7, 2009 at 3:24 PM, Adam Barth w...@adambarth.com wrote:
On Sun, Jun 7, 2009 at 2:53 PM, Mark S. Miller erig...@google.com wrote:
If servers at A don't freely hand out
On Sun, Jun 7, 2009 at 4:18 PM, Mark S. Miller erig...@google.com wrote:
On Sun, Jun 7, 2009 at 3:54 PM, Adam Barth w...@adambarth.com wrote:
GET really doesn't have anything to do with it. The attacker can
issue POST requests (and really any other method) too. Note that the
attacker can
On Sun, Jun 7, 2009 at 6:24 PM, Mark S. Miller erig...@google.com wrote:
On Sun, Jun 7, 2009 at 4:29 PM, Adam Barth w...@adambarth.com wrote:
Right, but once the attacker has XSSed site A, the attacker learns the
secret token necessary to issue the next request in the chain to site
The below doesn't appear to be a technical criticism of
Origin-as-CSRF-defense but rather a recommendation for a certain
design pattern for building web applications. That design pattern
seems useful. You might consider building a framework a la Rails that
makes it easy for developer to adopt
Hi Giovanni,
On Mon, Jun 8, 2009 at 6:52 AM, Giovanni
Campagnascampa.giova...@gmail.com wrote:
As I understand from various discussions here and from articles
around, I've learned that CSRF is a security leak which involves:
1) user visites http://www.mybank.com/login
2) the server sends a
On Tue, Jun 9, 2009 at 5:33 AM, Giovanni
Campagnascampa.giova...@gmail.com wrote:
1) I cannot understand what advantages has the attacker into logging
the user with attacker's credentials. I expect that the user will
notice the different account used (for example in the web app
interface)
I
On Tue, Jun 9, 2009 at 9:55 AM, Giovanni
Campagnascampa.giova...@gmail.com wrote:
2009/6/9 Adam Barth w...@adambarth.com:
I recommend reading
http://www.adambarth.com/papers/2008/barth-jackson-mitchell-b.pdf for
examples of why this is often sufficient for the attacker to perform
misdeeds
On Tue, Jun 9, 2009 at 9:38 AM, Tyler Closetyler.cl...@gmail.com wrote:
On Tue, Jun 9, 2009 at 9:29 AM, Adam Barthw...@adambarth.com wrote:
Isn't the whole
point of this feature to be able to distinguish guest and non-guest?
So requests from XMLHttpRequest have an Origin header, and requests
Thanks Tyler. I understand your use case now. I don't see the harm
in sending Origin: null, so I haven't changed the I-D, which requires
a (possibly null) Origin header in some cases.
Adam
On Tue, Jun 9, 2009 at 11:50 AM, Tyler Closetyler.cl...@gmail.com wrote:
On Tue, Jun 9, 2009 at 11:19
On Tue, Jun 9, 2009 at 3:40 PM, Jonas Sickingjo...@sicking.cc wrote:
I'm in general not a big fan of the redirect model in CORS, but this
one especially seems like a problem. One solution would be to include
the full redirect chain (or change the Origin to 'null') if
redirecting across servers
On Thu, Jun 11, 2009 at 4:35 AM, Jonathan Reesj...@creativecommons.org wrote:
I think this may be a foolish question, but is the value of Origin:
limited to sites? Couldn't it be an individual web page (URI)? Or a
wildcard? Is there some principled reason for such a limitation (if it
exists)?
On Fri, Jun 12, 2009 at 7:17 PM, Mark S. Millererig...@google.com wrote:
On Fri, Jun 12, 2009 at 7:03 PM, Adam Barth w...@adambarth.com wrote:
What server side behavior difference do you expect between messages with
no Origin and messages with Origin: null.
You'll have to include Origin
On Sat, Jun 13, 2009 at 5:39 AM, Tyler Closetyler.cl...@gmail.com wrote:
On Fri, Jun 12, 2009 at 10:36 PM, Adam Barthw...@adambarth.com wrote:
Suppose GuestXHR doesn't send an Origin header for any requests and a
server uses the algorithm in draft-abarth-origin to mitigate CSRF
attacks. Now,
On Sat, Jun 13, 2009 at 12:20 PM, Tyler Closetyler.cl...@gmail.com wrote:
On Sat, Jun 13, 2009 at 10:23 AM, Adam Barthw...@adambarth.com wrote:
For example, GuestXHR could be used to mount a login CSRF attack.
Are you sure about that? Since the response won't carry the
Re-sending from the right address.
Adam
2009/6/17 Adam Barth a...@adambarth.com:
2009/6/17 Anne van Kesteren ann...@opera.com:
On Wed, 17 Jun 2009 16:35:13 +0200, Tyler Close tyler.cl...@gmail.com
wrote:
Isn't it already possible to forge the IP address
on a HTTP request to a web site
On Wed, Jun 17, 2009 at 4:31 PM, Tyler Closetyler.cl...@gmail.com wrote:
2009/6/17 Adam Barth a...@adambarth.com:
I'd classify this as moderately difficult. It's not something I can do for
$5, but given a few hundred dollars, I can probably do it. Recall that
sending an HTTP request requires
On Wed, Jun 17, 2009 at 5:02 PM, Mark S. Millererig...@google.com wrote:
On Wed, Jun 17, 2009 at 4:46 PM, Ian Hickson i...@hixie.ch wrote:
But... we want the page talking on behalf of the user. That's the point
of a browser.
Not in this way. At least not according to Roy Fielding (Mr. REST)
On Wed, Jun 17, 2009 at 4:45 PM, Ian Hicksoni...@hixie.ch wrote:
That's news to me. As far as I can tell short of a man-in-the-middle
attack it would take a phenomenal combination of a brute-force attack on
the sequence numbers and a simultaneous DOS of the spoofee's network
connection.
In
On Wed, Jun 17, 2009 at 5:16 PM, Mark S. Millererig...@google.com wrote:
On Wed, Jun 17, 2009 at 5:09 PM, Adam Barth w...@adambarth.com wrote:
On Wed, Jun 17, 2009 at 5:02 PM, Mark S. Millererig...@google.com wrote:
Not in this way. At least not according to Roy Fielding (Mr. REST)
http
On Sat, Jun 20, 2009 at 12:57 PM, Bil Corryb...@corry.biz wrote:
I've lost track, is this still something being considered?
I should have an updated draft posted soon.
Adam
On Mon, Jun 22, 2009 at 11:30 AM, Tyler Closetyler.cl...@gmail.com wrote:
It appears to me that almost all
the complexity of CORS comes from its attempt to protect resources
that rely solely on IP-based authentication.
I'm not sure this is the case. I think the reasoning goes like this:
1)
On Mon, Jun 22, 2009 at 1:16 PM, Tyler Closetyler.cl...@gmail.com wrote:
On Mon, Jun 22, 2009 at 12:33 PM, Adam Barthw...@adambarth.com wrote:
1) We can't strip all the credential information from cross-origin requests.
2) There's a large amount of value is supporting all the normal
On Mon, Jun 22, 2009 at 2:26 PM, Tyler Closetyler.cl...@gmail.com wrote:
On Mon, Jun 22, 2009 at 2:01 PM, Adam Barthw...@adambarth.com wrote:
Why is this the case? Suppose I have a weather widget that wants to
remember for which ZIP codes I want to see the weather. It seems
easiest to store
On Mon, Jun 22, 2009 at 3:09 PM, Tyler Closetyler.cl...@gmail.com wrote:
Why do you assume my router has a private IP address?
Because it does?
I've used several networks that used several networks that used public
IP addresses behind firewalls and that relied on connectivity
security. If I
On Wed, Jun 24, 2009 at 12:43 PM, Jonas Sickingjo...@sicking.cc wrote:
As for the Origin spec that Adam Barth is working on, I'm not sure
that the last draft is published yet, but I believe that the idea is
to append the full redirect chain in the Origin header. (hence
possibly making
On Wed, Jun 24, 2009 at 5:48 PM, Bil Corryb...@corry.biz wrote:
Adam Barth wrote on 6/20/2009 6:25 PM:
On Sat, Jun 20, 2009 at 12:57 PM, Bil Corryb...@corry.biz wrote:
I've lost track, is this still something being considered?
I should have an updated draft posted soon.
I'm not clear
On Wed, Jun 24, 2009 at 5:42 PM, Bil Corryb...@corry.biz wrote:
Adam Barth wrote on 6/24/2009 6:16 PM:
I've uploaded the latest draft just now:
http://www.ietf.org/internet-drafts/draft-abarth-origin-01.txt
The draft now uses a different header name to avoid conflicting with
CORS
On Wed, Jun 24, 2009 at 6:39 PM, Mark S. Millererig...@google.com wrote:
On Wed, Jun 24, 2009 at 8:14 AM, Anne van Kesteren ann...@opera.com wrote:
As is widely recognized, CSRF is a form of confused deputy attack
http://www.cis.upenn.edu/~KeyKOS/ConfusedDeputy.html. From the beginning,
the
On Wed, Jun 24, 2009 at 8:42 PM, Bil Corryb...@corry.biz wrote:
As written, a conforming UA could choose to always send NULL for redirects,
which would be unfortunate.
That's correct.
More concerning though, a conforming UA could choose to always send NULL for
*all* HTTP requests.
That's
On Wed, Jun 24, 2009 at 8:50 PM, Bil Corryb...@corry.biz wrote:
Continuing your example, if XHTML defines requests from form as
privacy-sensitive, then the UA will have two different behaviors for
Sec-From, depending on if it's rendering HTML5 or XHTML?
That's correct. Hopefully folks
On Wed, Jun 24, 2009 at 10:12 PM, Mark S. Millererig...@google.com wrote:
The server can sensibly wish to reveal a particular piece of information to
those parties that it thinks should be authorized to learn that information.
Without assuming your conclusion, why should the server wish to
On Thu, Jul 16, 2009 at 8:47 AM, Bil Corryb...@corry.biz wrote:
I think you mean everything will NOT be privacy-sensitive except non-XHR GETs.
I don't think we've quite settled on exactly what will be privacy
sensitive. It's most likely that POSTs and XHR will not be and that
hyperlinks and
On Thu, Jul 16, 2009 at 1:13 PM, Jonas Sickingjo...@sicking.cc wrote:
On Thu, Jul 16, 2009 at 10:45 AM, Adam Barthw...@adambarth.com wrote:
When a browser creates an instance of a DOM object defined by an
WebIDL interface, the browser must choose where to connect it's
prototype chain. For
On Thu, Jul 16, 2009 at 2:58 PM, Jonas Sickingjo...@sicking.cc wrote:
There's currently a bug in 3.5 which is why functions are failing. It
is fixed in the upcoming 3.5.1 release.
The only other non-PASS thing I see in firefox is .content, which
basically is the same as .top and so is working
On Thu, Jul 16, 2009 at 3:08 PM, Jonas Sickingjo...@sicking.cc wrote:
On Thu, Jul 16, 2009 at 2:59 PM, Maciej Stachowiakm...@apple.com wrote:
One thing to note: any object or method that is exposed cross-origin should
specifically *not* have this behavior. Instead, it should create a separate
On Fri, Aug 7, 2009 at 5:51 PM, Ian Hicksoni...@hixie.ch wrote:
How should I address this for HTML5?
We talked over several option in #whatwg. Here's something that might
make sense. The approach below is designed to allow for robust
implementation and to isolated the magical properties in the
On Tue, Aug 18, 2009 at 10:30 AM, Michael A. Puls
IIshadow2...@gmail.com wrote:
However, 3 out of the 4 main browsers support it. Behavior and security
could be aligned and improved.
We should tread carefully here. The security model for file URLs
isn't fully developed yet.
For example:
1.
On Tue, Aug 18, 2009 at 12:50 PM, Michael A. Puls
IIshadow2...@gmail.com wrote:
On Tue, 18 Aug 2009 15:25:35 -0400, Adam Barth w...@adambarth.com wrote:
On Tue, Aug 18, 2009 at 10:30 AM, Michael A. Puls
IIshadow2...@gmail.com wrote:
3. file://bark/path and file://meow/path are different
On Tue, Aug 18, 2009 at 2:40 PM, Michael A. Puls IIshadow2...@gmail.com wrote:
On Tue, 18 Aug 2009 16:27:29 -0400, Adam Barth w...@adambarth.com wrote:
For example,
that wouldn't appear to work well in a deployment that uses AFS.
I'm not sure how things work for AFS. What do paths look like
On Tue, Aug 18, 2009 at 2:59 PM, Michael A. Puls IIshadow2...@gmail.com wrote:
So, if you access the abarth directory in your browser's address field,
it'll say:
file:///afs/cs.stanford.edu/u/abarth (or
file://localhost/afs/cs.stanford.edu/u/abarth in Opera)
?
Yep.
If so, then indeed the
On Fri, Sep 18, 2009 at 10:30 PM, Jonas Sicking jo...@sicking.cc wrote:
I wonder for example if the client when receiving a
Strict-Transport-Security header should make a request to the root url
of the same origin to verify that the server indeed wants to opt in to
STS.
That's a good idea.
Comments below.
Web user agents MUST prevent web content from obscuring, hiding, or disabling
security user interfaces.
This is impossible in a multi-window web user agent in an overlapping
window manager (e.g., every major browser on every major
general-purpose operating system).
Web user
On Sat, Sep 19, 2009 at 1:46 AM, Jonas Sicking jo...@sicking.cc wrote:
(am I understanding it correctly that http requests can't opt in to STS?)
Well, they opt in by redirecting to HTTPS and then sending the header
over HTTPS. :)
One virtue of your algorithm is that there are no extra requests
On Mon, Sep 21, 2009 at 8:31 AM, Aryeh Gregor simetrical+...@gmail.com wrote:
Is it true that UAs MUST NOT note a server as a Known STS Server if
the Strict-Transport-Security header was received over an unsecured
request, or there were underlying secure transport errors?
That's correct. We
On Wed, Sep 23, 2009 at 5:34 AM, Anne van Kesteren ann...@opera.com wrote:
For simple cross-origin requests Origin would be a space-separated list of
origins indicating the redirect chain.
When we used this syntax for the Sec-From header, Mark Nottingham
advocated using commas to separate the
This sounds like a good idea. One thing we can do to reduce the
complexity is to have different grammars for server conformance and
for user agent conformance. Essentially, servers would be required to
conform to the current grammar, but UAs would be required to conform
to the more tolerant
On Thu, Sep 24, 2009 at 9:00 AM, Anne van Kesteren ann...@opera.com wrote:
I have now specified the approach we discussed:
http://dev.w3.org/2006/waf/access-control/
For simple requests redirects are followed. For other cross-origin requests
they are the equivalent of a network error. The
This is an interesting proposal. It addresses a different threat
model than the core STS proposal (because you assume the attacker has
a valid certificate for victim.com).
I think we should resist expanding the scope of the core STS proposal.
There are many different kinds of tokens one could
On Mon, Oct 12, 2009 at 8:24 PM, Mark S. Miller erig...@google.com wrote:
Most obviously, CORS proposes ACLs, with comma separated origins
(following an Origin: header) to be used by servers to determine
whether to grant read/PUT/DELETE access to cross-origin resources.
The CORS spec doesn't
On Fri, Oct 23, 2009 at 5:29 PM, Doug Schepers schep...@w3.org wrote:
That's an interesting point... if the proponents or opponents of CORS did
more testing and modeling, would that satisfy concerns? Surely it couldn't
be hard to set up a few common model architectures using CORS and announce
On Fri, Oct 23, 2009 at 10:34 PM, Doug Schepers schep...@w3.org wrote:
Sorry for being dense, but why couldn't the whitehats build toy systems on
an open honeynet?
They could, but what would we learn from such an experiment? If they
build only secure systems, then we'd learn that security
On Fri, Oct 23, 2009 at 11:07 PM, David-Sarah Hopwood
david-sa...@jacaranda.org wrote:
The specific risk is quite clear: it's the risk of CSRF attacks that
are currently prevented (or mitigated) by the same-origin policy.
These won't be prevented or mitigated to the same extent by browsers
Thanks for your feedback. Comments inline. (I've skipped the
editorial comments.)
On Tue, Oct 27, 2009 at 5:01 PM, Eric Lawrence
eric...@exchange.microsoft.com wrote:
I am a bit concerned that the spec doesn’t mandate behavior for
mixed-content; I know such requirements would be controversial
On Tue, Nov 3, 2009 at 7:39 AM, Anne van Kesteren ann...@opera.com wrote:
On Mon, 02 Nov 2009 23:46:30 -0800, Adam Barth w...@adambarth.com wrote:
It is somewhat frustrating to be unable to participate in this forum.
Any particular reason you cannot be here? Would be nice if you could come
5, 2009 at 8:56 AM, Adam Barth w...@adambarth.com wrote:
Hi Tyler,
I've been trying to understand the GuestXHR protocol you propose for
replacing CORS:
http://sites.google.com/site/guestxhr/maciej-challenge
I don't understand the message in step 5. It seems like it might have
a CSRF
I support publishing this document as a FPWD.
Adam
On Tue, Nov 3, 2009 at 9:27 PM, Arthur Barstow art.bars...@nokia.com wrote:
This is a Call for Consensus (CfC) to publish the First Public Working Draft
(FPWD) of the File API spec, latest Editor's Draft at:
Which is the proper mailing list to follow development of the file
writing API? I'd like to follow it's security considerations.
Thanks,
Adam
On Tue, Nov 10, 2009 at 1:56 AM, Dominique Hazael-Massieux d...@w3.org wrote:
Hi,
I alluded to this during the joint F2F meeting between WebApps and
very relevant to the current discussion. All that said, I'm happy to
fill out the scenario with as much detail as you'd like, if that helps
us reach an understanding.
--Tyler
On Thu, Nov 5, 2009 at 8:31 PM, Adam Barth w...@adambarth.com wrote:
You seem to be saying that your description
On Tue, Nov 10, 2009 at 7:40 PM, Bil Corry b...@corry.biz wrote:
Gervase Markham wrote on 10/01/2009 5:51 PM:
I therefore propose a simple extension to the STS standard; a single
token to be appended to the end of the header:
lockCA
One idea to consider, especially for lockCA, is to somehow
On Wed, Nov 11, 2009 at 7:25 AM, Bil Corry b...@corry.biz wrote:
Would LockCA prevent the site from loading if it encountered a new cert from
the same CA?
My understanding is that it would not.
Or are you talking about a site that wants to switch CAs and is using LockCA?
I think Gervase
2009/11/12 Jonas Sicking jo...@sicking.cc:
2009/11/12 Ian Fette (イアンフェッティ) ife...@google.com:
This is really getting into fantasy-land... Writing a file and hoping that
the user actually opens up explorer/finder/whatever and browses to some
folder deep within the profile directory, and then
On Thu, Nov 19, 2009 at 2:49 AM, David Rogers david.rog...@omtp.org wrote:
-Original Message-
From: public-device-apis-requ...@w3.org
[mailto:public-device-apis-requ...@w3.org] On Behalf Of Adam Barth
Sent: 19 November 2009 07:42
To: Marcin Hanclik
Cc: Maciej Stachowiak; Dominique
David, you're not listening.
On Thu, Nov 19, 2009 at 3:02 AM, David Rogers david.rog...@omtp.org wrote:
-Original Message-
From: Jonas Sicking [mailto:jo...@sicking.cc]
Sent: 19 November 2009 10:11
To: Marcin Hanclik
Cc: David Rogers; Maciej Stachowiak; Dominique Hazael-Massieux;
On Thu, Nov 19, 2009 at 3:24 AM, Robin Berjon ro...@berjon.com wrote:
Finally, we can all talk about policy and trust in browsers until we're bluer
in the face than a hypothermic smurf the fact of the matter is that I don't
believe that this is a case where discussion can produce consensus.
[public-device-apis-requ...@w3.org]
On Behalf Of Maciej Stachowiak [...@apple.com]
Sent: Thursday, November 19, 2009 6:35 PM
To: Adam Barth
Cc: Robin Berjon; public-device-a...@w3.org; public-webapps WG
Subject: Re: Trying to summarise (was Re: DAP and security)
On Nov 19, 2009, at 7:58 AM, Adam
On Fri, Nov 20, 2009 at 8:34 AM, Robin Berjon ro...@berjon.com wrote:
DAP will handle security at the API definition level. Full stop.
Can you elaborate on what this means concretely? For example, how is
security handled at the API definition level for the file writing API?
Adam
I haven't been following the localStorage mutex discussion in detail,
but have we already rejected the idea of having content specifically
ask for the mutex via a transaction callback, similar to how web
databases work?
localStorgage.atomicTransaction(function() {
localStorage[counter]++;
});
On Thu, Dec 10, 2009 at 12:04 PM, Jonas Sicking jo...@sicking.cc wrote:
On Thu, Dec 10, 2009 at 10:53 AM, Arthur Barstow art.bars...@nokia.com
wrote:
Ideally, the group would agree on a single model and this could be achieved
by converging CORS + UM, abandoning one model in deference to the
On Sun, Dec 13, 2009 at 8:54 AM, Mark S. Miller erig...@google.com wrote:
On Sat, Dec 12, 2009 at 7:17 PM, Adam Barth w...@adambarth.com wrote:
I agree with Jonas. It seems unlikely we'll be able to
design-by-commitee around a difference in security philosophy dating
back to the 70s.
Hi
1 - 100 of 265 matches
Mail list logo
