Re: CSRF: alternative solutions
On Mon, Jun 8, 2009 at 3:52 PM, Giovanni Campagna 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 cookie, call it MyBankSID, with the login information 3) user visites http://www.dangerous.com/ within the expiration time of cookie 4) the user clickes a link (or sends a form) to http://www.mybank.com/pay?to=hacker 5) the browser sends MyBankSID cookie, which grants access to user's bank account 6) money goes from the user to the attacker To stop CSRF, we need to stop this algorithm at one of these steps. [...] We can stop it at 4), preventing the user agent from sending automatically state information when the request is originated from a foreign (and possibily untrusted) origin. This means that cookies are not sent for requests that are not same-origin. [...] All of these solution have pros and cons: [...] Then we have solution #4. This may hurt web apps that currently require sensitive cross-site requests, but I'm not sure that there are any, and they could work with automatic redirection to a login page. Architechturally, assuming that the UAs keeps authentication info and automatically sends it is a bad idea that we should not encourage, and so designing web services that require this. This would rule out all SSO mechanisms: 1. user visits mail.google.com 2. given that it is not authenticated (no cookie or stale cookie value), user is redirected to www.google.com/accounts 3. user is already authenticated, so it is redirected back to mail.google.com with a new SID (in the query-string) 4. mail.google.com sets a cookie to authenticate user for later requests I took google.com apps as an example, but ti works the same with, e.g. JA-SIG CAS and probably any other SSO (including OpenID). With your proposal, the redirection to www.google.com/account would not send the cookie and thus would require the user to re-authenticate, defeating the SSO. Would it also mean that the browser forgets about the previous cookie that was set by www.google.com/accounts when the user authenticated first (let's say for using google groups or google docs)? Have you read http://www.adambarth.com/papers/2008/barth-jackson-mitchell-b.pdf ? There are other CSRF threats, such as session fixation. -- Thomas Broyer
Re: File API Feedback
On Tue, Jun 30, 2009 at 2:25 PM, Olli Pettay wrote: On 6/30/09 1:44 PM, Ian Hickson wrote: I'd rather just have an API that lets you split a File into a sequenceFileData (where FileData is what File inherits from) of equally sized chunks, or something like that, than something that lets you get chunks out in particular forms. Yeah, that sounds better. Then XHR .send() could accept FileData as a parameter. All the .getAsXXX methods would move to that interface and there should be something like FileData getFileData(long long offset, long long length) For the record, Gears' Blob (the almost-equivalent of that FileData if I'm not mistaken) has a slice(offset,length) method: http://code.google.com/apis/gears/api_blob.html (and a Blob can be passed to an HttpRequest's send() method, and obtained from an HttpRequest's responseBlob property or in desktop's openFiles callback; note that a File in Gears doesn't inherit Blob, it rather has a 'blob' property of type Blob) -- Thomas Broyer
Re: solving the CPU usage issue for non-visible pages
On Wed, Oct 21, 2009 at 5:16 AM, Robert O'Callahan wrote: There are lots of reasons why the browser might deduce that the user is not paying attention to a document, e.g. -- the browser window containing the document is minimized -- the tab containing the document is hidden -- the document is in an IFRAME and scrolled offscreen -- the browser window is buried behind other windows on the desktop -- the screen is dimmed for power saving -- gaze tracking detects that the user is looking somewhere else -- ultrasonic pings detect that the user is not there If we need an API beyond just animation, you might as well call it something like window.hasAttention so browsers can cover all of those cases. ...which looks a lot like some kind of idleness, as has been already proposed/discussed at the WHATWG and then here: http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2009-August/022443.html (later revised at http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2009-September/022984.html and http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2009-September/022985.html ) http://lists.w3.org/Archives/Public/public-webapps/2009JulSep/1103.html We could add a new idleState value that'd be set (with an idleStateChange event) as soon as the window (browsing context) becomes inactive. -- Thomas Broyer /tɔ.ma.bʁwa.je/
Re: [XHR2] AnonXMLHttpRequest()
On Thu, Feb 4, 2010 at 11:05 PM, Tyler Close tyler.cl...@gmail.com wrote: On Wed, Feb 3, 2010 at 2:34 PM, Maciej Stachowiak m...@apple.com wrote: I don't think I've ever seen a Web server send Vary: Cookie. I don't know offhand if they consistently send enough cache control headers to prevent caching across users. I've been doing a little poking around. Wikipedia sends Vary: Cookie. Wikipedia additionally uses Cache-Control: private, as do some other sites I checked. Other sites seem to be relying on revalidation of cached entries by making them already expired. FWIW, Django also sends Vary: Cookie when using sessions (which includes form authentication AFAICT): http://code.djangoproject.com/browser/django/trunk/django/contrib/sessions/middleware.py -- Thomas Broyer /tɔ.ma.bʁwa.je/
Re: Status of Selectors API Level 1 Candidate
On Wed, May 5, 2010 at 4:28 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Wed, May 5, 2010 at 4:56 AM, Lachlan Hunt lachlan.h...@lachy.id.au wrote: I have not been able to test IE9 because I don't have access to Windows Vista or 7. I would appreciate it if anyone who has a copy of the last public development build, or someone from Microsoft, could report on the implementation status in IE9. The current developer preview of IE9 fails all of the tests. I didn't investigate why, and the tools are extremely limited in any case right now. I can keep you updated when they update the Dev Preview. Something like... just now! ;-) Just tested the 2nd Platform Preview on Windows Vista. Scored: 001: 73.9%: 745 passed, 263 failed 002: 55.9%: 1222 passed, 966 failed 003: crashed -- Thomas Broyer /tɔ.ma.bʁwa.je/
Re: ISSUE-133 (keyCode and charCode): Consider specifying keyCode and charCode [DOM3 Events]
On Thu, Sep 16, 2010 at 2:39 PM, Web Applications Working Group Issue Tracker sysbot+trac...@w3.org wrote: ISSUE-133 (keyCode and charCode): Consider specifying keyCode and charCode [DOM3 Events] http://www.w3.org/2008/webapps/track/issues/133 Raised by: Doug Schepers On product: DOM3 Events Simon Pieters http://lists.w3.org/Archives/Public/www-dom/2010JulSep/0160.html: [[ Please specify keyCode and charCode, even if marked as 'obsolete'. I'm pretty sure no browser is going to ship without at least one of them. (I notice that charCode is undefined in Opera, keyCode always returns 0 in Firefox, and in WebKit they both work.) ]] See http://unixpapa.com/js/key.html and http://www.slideshare.net/pp.koch/yahoo-1337458 for researches on the subject. Basically, and practically, use keyCode in keyDown and keyUp events, and charCode in keyDown events (except in Opera, where keyCode can be used as a fallback). I can't tell how this would translate to spec text though. -- Thomas Broyer /tɔ.ma.bʁwa.je/
Re: ISSUE-133 (keyCode and charCode): Consider specifying keyCode and charCode [DOM3 Events]
On Thu, Sep 16, 2010 at 3:33 PM, Thomas Broyer wrote: Basically, and practically, use keyCode in keyDown and keyUp events, and charCode in keyDown events (except in Opera, where keyCode can be used as a fallback). Sorry, I obviously meant charCode in keyPress events. -- Thomas Broyer /tɔ.ma.bʁwa.je/
