[whatwg] HttpOnly cookie for WebSocket?
May/Should WebSocket use HttpOnly cookie while Handshaking? I think it would be useful to use HttpOnly cookie on WebSocket so that we could authenticate the WebSocket connection by the auth token cookie which might be HttpOnly for security reason. http://www.ietf.org/id/draft-ietf-httpstate-cookie-02.txt -- ukai
Re: [whatwg] HttpOnly cookie for WebSocket?
Hi, a new IETF wg has been formed to take care of WebSocket protocol HyBi: http://tools.ietf.org/wg/hybi/charters So, this issue is something it should be discussed there (btw I am forwdard it to the HyBi ml) N.B. to subscribe to the HyBi ml: https://www.ietf.org/mailman/listinfo/hybi /Sal A new IETF working group has been formed in the Applications Area. For additional information, please contact the Area Directors or the WG Chairs. BiDirectional or Server-Initiated HTTP (hybi) On 01/28/2010 10:12 AM, Fumitoshi Ukai (鵜飼文敏) wrote: May/Should WebSocket use HttpOnly cookie while Handshaking? I think it would be useful to use HttpOnly cookie on WebSocket so that we could authenticate the WebSocket connection by the auth token cookie which might be HttpOnly for security reason. http://www.ietf.org/id/draft-ietf-httpstate-cookie-02.txt -- ukai
Re: [whatwg] HttpOnly cookie for WebSocket?
On Thu, 28 Jan 2010, Salvatore Loreto wrote: a new IETF wg has been formed to take care of WebSocket protocol HyBi: http://tools.ietf.org/wg/hybi/charters So, this issue is something it should be discussed there (btw I am forwdard it to the HyBi ml) N.B. to subscribe to the HyBi ml: https://www.ietf.org/mailman/listinfo/hybi The WHATWG is still actively working on the WebSocket protocol, as we are with all of the specifications listed in the FAQ: http://wiki.whatwg.org/wiki/FAQ#What_are_the_various_versions_of_the_spec.3F ...and feedback on the WebSocket protocol is therefore very welcome on this mailing list. (Indeed, I continue to track all e-mails sent to this list and will reply to all substantial feedback sent to it.) As a side note, it's unclear exactly what the HyBi group is actually going to be working on. The timetable listed on the charter linked above is clearly at odds with reality; WebSocket is already shipping in Chrome and is ready to be shipped in two other browsers, and multiple servers are already available, so clearly March 2011 for a last call isn't really workable (especially since the spec reached last call at the WHATWG in 2009 -- the main thing missing now is test cases). However, I encourage anyone interested in Web Sockets to participate in the HyBi group, and indeed discussion of their timetable is probably best had there. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] HttpOnly cookie for WebSocket?
On Thu, Jan 28, 2010 at 12:12 AM, Fumitoshi Ukai (鵜飼文敏) u...@chromium.orgwrote: May/Should WebSocket use HttpOnly cookie while Handshaking? WebSocket is a stateful protocol, and its cookie support is only applicable in interacting with the HTTP context .. and therefore the spec should simply refer to what's specified for HTTP for clarification ... - Wenbo I think it would be useful to use HttpOnly cookie on WebSocket so that we could authenticate the WebSocket connection by the auth token cookie which might be HttpOnly for security reason. http://www.ietf.org/id/draft-ietf-httpstate-cookie-02.txt -- ukai
Re: [whatwg] history.back()
On 1/28/10 7:15 AM, Darin Fisher wrote: That said, I think it would be good for location.hash = 'a' to interrupt the history.back() request. The net result being that #a is appended to session history, and the history.back() request is discarded. Really? What if iframe has been navigated lately and something calls history.back() (to load previous page in iframe), but right after that top level page calls location.hash = foo; -Olli
Re: [whatwg] api for fullscreen()
On Jan 28, 2010, at 3:38 PM, Robert O'Callahan wrote: On Thu, Jan 28, 2010 at 8:34 PM, Henri Sivonen hsivo...@iki.fi wrote: I haven't seen a proposal, but it looks like code has landed: http://trac.webkit.org/changeset/50893 Demo: http://jilion.com/sublime/video (option-click the full screen button in a fresh WebKit nigthly) Interesting, but I'd still like to see the proposal. This should definitely be something that works on more than just media elements. The code referenced in that commit, and used by jilion.com, is NOT our proposal for a generic fullscreen mechanism. Rather, it's a new, webkit-prefixed method on the HTMLMediaElement which does the equivalent of the user clicking on the fullscreen button in the built-in controls. This is highly desirable for page that want to user their own custom controls, but would still like the user to go fullscreen. We have been discussing a more general fullscreen API that lets you take the page fullscreen (perhaps with the ability to focus on a single element), as Maciej mentions. We have not decided on a final form for this API, nor have we resolved whether it's possible to do some nice transition between the two modes. We have talked at some length about the security issues. Input on what people would like from this API is welcome, as are ideas on how the transitions should work. Simon
Re: [whatwg] history.back()
On Wed, 27 Jan 2010, Darin Fisher wrote:
I think that location.hash = 'a' should synchronously add #a to the
session history, or at least it should appear to the web page that it
was added synchronously.
[...]
That said, I think it would be good for location.hash = 'a' to interrupt
the history.back() request. The net result being that #a is appended
to session history, and the history.back() request is discarded.
[...]
I'm trying to treat history,{back,forward,go} as a UI command to the
navigator. Synthesize the user clicking on the corresponding
back/forward buttons. UI actions typically do not get dispatched during
JS execution (ignoring window.showModalDialog of course).
[...]
I agree that we should not change the location without traversing
history.
I'm arguing for making history.{back,forward,go} start out by
dispatching a task to then run the history traversal algorithm. So,
history.back() would never change the location synchronously.
I've tried to spec this. There is a high risk of compatibility issues, so
I would very much welcome feedback from implementors who try to implement
this.
The main goal of the change here is to make it possible to implement this
(if not completely sanely, but it's the Web, there's only so much I can
do) in a situation with each browsing context having its own process, as
seen to some extent in IE and Chrome, and as is being examined by other
browser vendors also.
While I was at it I made 'hashchange' and 'popstate' fire completely
async, and gave 'hashchange' context information to get around the problem
with it firing async (where it could e.g. fire twice for the same URL,
because the navigations get processed before it fires).
On Thu, 28 Jan 2010, Olli Pettay wrote:
On 1/28/10 7:15 AM, Darin Fisher wrote:
That said, I think it would be good for location.hash = 'a' to
interrupt the history.back() request. The net result being that #a
is appended to session history, and the history.back() request is
discarded.
Really? What if iframe has been navigated lately and something calls
history.back() (to load previous page in iframe), but right after that
top level page calls location.hash = foo;
Per spec now, any code along the lines of:
history.back();
location.hash = foo;
...will cause the back() to be a no-op. This is definitely incompatible
with legacy implementations; the question is whether there are pages
depending on it.
If we can't do this asynchronously, it's going to really suck for
multiprocess UAs, so I think it's worth trying to find a solution here,
even if there is a back-compat risk. In practice I don't think the risk
is as high as it could be, because interop is pretty poor in this area
already; in particular, Chrome does things that are quite drastic when
given code like the above, and Chrome developers aren't aware of having
received bugs about it.
Again, please send feedback on this. The diff is:
http://html5.org/tools/web-apps-tracker?from=4631to=4632
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] api for fullscreen()
On Fri, Jan 29, 2010 at 12:51 PM, Simon Fraser s...@me.com wrote: We have been discussing a more general fullscreen API that lets you take the page fullscreen (perhaps with the ability to focus on a single element), as Maciej mentions. We have not decided on a final form for this API, nor have we resolved whether it's possible to do some nice transition between the two modes. We have talked at some length about the security issues. Input on what people would like from this API is welcome, as are ideas on how the transitions should work. 1) Should be convenient for authors to make any element in a page display fullscreen 2) Should support in-page activation UI for discoverability 3) Should support changing the layout of the element when you enter/exit fullscreen mode. For example, authors probably want some controls to be fixed size while other content fills the screen. 4) Should accommodate potential UA security concerns, e.g. by allowing the transition to fullscreen mode to happen asynchronously after the user has confirmed permission *** WARNING: totally half-baked proposal ahead! *** New API for all elements: void enterFullscreen(optional boolean enableKeys); void exitFullscreen(); boolean attribute supportsFullscreen; boolean attribute displayingFullscreen; beginfullscreen and endfullscreen events While an element is fullscreen, the UA imposes CSS style position:fixed; left:0; top:0; right:0; bottom:0 on the element and aligns the viewport of its DOM window with the screen. Only the element and its children are rendered, as a single CSS stacking context. enterFullscreen always returns immediately. If fullscreen mode is currently supported and permitted, enterFullscreen dispatches a task that a) imposes the fullscreen style, b) fires the beginfullscreen event on the element and c) actually initiates fullscreen display of the element. The UA may asynchronously display confirmation UI and dispatch the task when the user has confirmed (or never). The enableKeys parameter to enterFullscreen is a hint to the UA that the application would like to be able to receive arbitrary keyboard input. Otherwise the UA is likely to disable alphanumeric keyboard input. If enableKeys is specified, the UA might require more severe confirmation UI. In principle a UA could support multiple elements in fullscreen mode at the same time (e.g., if the user has multiple screens). enterFullscreen would throw an exception if fullscreen was definitely not going to happen for this element due to not being supported or currently permitted, or if all screens are already occupied. supportsFullscreen returns false if it's impossible for this element to ever be shown fullscreen. It does not reveal whether permission will be granted. Rob -- He was pierced for our transgressions, he was crushed for our iniquities; the punishment that brought us peace was upon him, and by his wounds we are healed. We all, like sheep, have gone astray, each of us has turned to his own way; and the LORD has laid on him the iniquity of us all. [Isaiah 53:5-6]
Re: [whatwg] api for fullscreen()
1) Should be convenient for authors to make any element in a page display
fullscreen
2) Should support in-page activation UI for discoverability
3) Should support changing the layout of the element when you enter/exit
fullscreen mode. For example, authors probably want some controls to be fixed
size while other content fills the screen.
4) Should accommodate potential UA security concerns, e.g. by allowing the
transition to fullscreen mode to happen asynchronously after the user has
confirmed permission
A couple of points:
Regarding point 1, surely any fullscreen API should only support block-level
elements?
If I'm reading point 2 correctly, I disagree with it (except in cases like
video where a default style exists to manipulate the element itself). To me
(based on how I can envisage using this functionality, particularly regarding
touch-screen kiosks) the use-cases for full-screen capable elements should be
left out of the UA and in the hands of the author (e.g. as Javascript buttons
or links).
When it comes to point 3, I figure a good way to handle this might be to
introduce a CSS pseudo-class for fullscreen elements. Then the UA default style
would simply be *:fullscreen { position: fixed; left: 0; top: 0; right: 0;
bottom: 0; }. Some method for changing the layout of the element is going to be
required to handle cases where the aspect ratio of the screen doesn't match
that of the element in the document flow.
Should zoomed-up versions of a container scale elements like images and text or
merely the containing box? If the latter, does that limit the ability to
provide animation in-UA to naturally zoom the element to full-screen without
distracting re-flow of text? And does it limit the likely use-case for authors
of providing full-screen slideshows etc. where images would be expected to zoom
to fill their new, larger container.
One other brief concern; there's a chance (e.g. on mobile devices) that the
fullscreen layout is smaller than the element in the normal document flow
(where it can be scrolled). That may make it necessary to permit some user
manipulation of the fullscreen layout such as zooming and panning (which may
otherwise be restricted as per point 4).
—Kit
Re: [whatwg] api for fullscreen()
On 1/28/10 10:06 PM, Kit Grose wrote: 1) Should be convenient for authors to make any element in a page display fullscreen 2) Should support in-page activation UI for discoverability 3) Should support changing the layout of the element when you enter/exit fullscreen mode. For example, authors probably want some controls to be fixed size while other content fills the screen. 4) Should accommodate potential UA security concerns, e.g. by allowing the transition to fullscreen mode to happen asynchronously after the user has confirmed permission A couple of points: Regarding point 1, surely any fullscreen API should only support block-level elements? Block-level in what sense? img is not block-level in any sense; One could argue that video and object are block-level in HTML terms, but it's context-dependent (they can contain blocks if their parent can). None of these are block-level in the CSS sense, by default. -Boris
Re: [whatwg] api for fullscreen()
Block-level in what sense? img is not block-level in any sense; One could argue that video and object are block-level in HTML terms, but it's context-dependent (they can contain blocks if their parent can). None of these are block-level in the CSS sense, by default. True, but surely saying any element opens the door to full-screening inline text elements (e.g span elements). Looking at a few lists of all inline elements in HTML, there aren't any except img (except perhaps form inputs/textareas) that should obviously be permitted this sort of full-screen capability (without first being defined as display: block). I suppose the native style being position: fixed would put those elements in a block formatting context anyway, but what implications might that have for things like table cells/table rows being made full-screen? —Kit
Re: [whatwg] api for fullscreen()
enterFullscreen always returns immediately. If fullscreen mode is currently supported and permitted, enterFullscreen dispatches a task that a) imposes the fullscreen style, b) fires the beginfullscreen event on the element and c) actually initiates fullscreen display of the element. The UA may asynchronously display confirmation UI and dispatch the task when the user has confirmed (or never). Don't you think it would make more sense to dispatch the enterFullscreen event only when the element actually goes fullscreen? If the user clicks the fullscreen button, but then doesn't accept whatever options (likely a security dialog or something) then it doesn't make sense to broadcast an enterFullscreen event, as you'd just have to broadcast an exitFullscreen event right away to show that the user isn't actually in fullscreen. The enableKeys parameter to enterFullscreen is a hint to the UA that the application would like to be able to receive arbitrary keyboard input. Otherwise the UA is likely to disable alphanumeric keyboard input. If enableKeys is specified, the UA might require more severe confirmation UI. This seems overly complicated. I think it would suffice to simply show a dialog the first time a user wants to go fullscreen within a domain with an option to remember this choice for this domain. Then the user won't have to jump through the hoops again when they return, but will still protect them from random websites going fullscreen and trying to phish things. This way blocking or restricting keyboard events isn't needed. In principle a UA could support multiple elements in fullscreen mode at the same time (e.g., if the user has multiple screens). That sounds complicated, but brings up the good point of how to choose which screen to go fullscreen on. I'd recommend going fullscreen on the same monitor that the element going fullscreen inhabits. (if there's overlap, I suppose you'd have to calculate which display contains most of the element). Also consider what happens if the user focuses something on another display. Do you then drop out of fullscreen, or just blur() the fullscreen window? (I'd vote to leave it and just blur() it, so you can do things like watch fullscreen video on one display and continue working in the other). Another thing to add in here I haven't seen discussed yet is what to show as the background to the fullscreen element. Consider the example of a 16:9 video going fullscreen on a 4:3 display. How do you tell the browser to fill in the extra space around the video with black (or whatever other color you want). Is this a custom css element?
Re: [whatwg] api for fullscreen()
On Fri, Jan 29, 2010 at 4:06 PM, Kit Grose k...@iqmultimedia.com.au wrote:
Regarding point 1, surely any fullscreen API should only support
block-level elements?
I don't see why. Setting position:fixed does what you want in the cases I
can think of.
If I'm reading point 2 correctly, I disagree with it (except in cases like
video where a default style exists to manipulate the element itself). To
me (based on how I can envisage using this functionality, particularly
regarding touch-screen kiosks) the use-cases for full-screen capable
elements should be left out of the UA and in the hands of the author (e.g.
as Javascript buttons or links).
Sorry I wasn't clear. By in-page UI I meant UI under the control of the
author.
When it comes to point 3, I figure a good way to handle this might be to
introduce a CSS pseudo-class for fullscreen elements. Then the UA default
style would simply be *:fullscreen { position: fixed; left: 0; top: 0;
right: 0; bottom: 0; }. Some method for changing the layout of the element
is going to be required to handle cases where the aspect ratio of the screen
doesn't match that of the element in the document flow.
Indeed. A CSS pseudo-class sounds like a reasonable idea.
Should zoomed-up versions of a container scale elements like images and text
or merely the containing box? If the latter, does that limit the ability to
provide animation in-UA to naturally zoom the element to full-screen without
distracting re-flow of text? And does it limit the likely use-case for
authors of providing full-screen slideshows etc. where images would be
expected to zoom to fill their new, larger container.
If you change the layout, zooming isn't really necessary. My guess is that
there are several interpolation strategies for transition effects that would
all work. For example, you could apply the style change, render the element
at the size of the screen, and then zoom that image out from the element's
old position to the screen size.
Rob
--
He was pierced for our transgressions, he was crushed for our iniquities;
the punishment that brought us peace was upon him, and by his wounds we are
healed. We all, like sheep, have gone astray, each of us has turned to his
own way; and the LORD has laid on him the iniquity of us all. [Isaiah
53:5-6]
Re: [whatwg] api for fullscreen()
On Thu, 28 Jan 2010, Geoff Stearns wrote: I think it would suffice to simply show a dialog the first time a user wants to go fullscreen within a domain with an option to remember this choice for this domain. Users click through dialogs without looking, so that wouldn't work. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] api for fullscreen()
On Fri, Jan 29, 2010 at 5:06 PM, Geoff Stearns tensafefr...@google.comwrote: enterFullscreen always returns immediately. If fullscreen mode is currently supported and permitted, enterFullscreen dispatches a task that a) imposes the fullscreen style, b) fires the beginfullscreen event on the element and c) actually initiates fullscreen display of the element. The UA may asynchronously display confirmation UI and dispatch the task when the user has confirmed (or never). Don't you think it would make more sense to dispatch the enterFullscreen event only when the element actually goes fullscreen? If the user clicks the fullscreen button, but then doesn't accept whatever options (likely a security dialog or something) then it doesn't make sense to broadcast an enterFullscreen event, as you'd just have to broadcast an exitFullscreen event right away to show that the user isn't actually in fullscreen. That was my intent in the last sentence of the paragraph you quoted. The enableKeys parameter to enterFullscreen is a hint to the UA that the application would like to be able to receive arbitrary keyboard input. Otherwise the UA is likely to disable alphanumeric keyboard input. If enableKeys is specified, the UA might require more severe confirmation UI. This seems overly complicated. I think it would suffice to simply show a dialog the first time a user wants to go fullscreen within a domain with an option to remember this choice for this domain. Then the user won't have to jump through the hoops again when they return, but will still protect them from random websites going fullscreen and trying to phish things. This way blocking or restricting keyboard events isn't needed. Those kinds of dialogs are dangerous because users tend to just dismiss them without reading. Passive (ignorable and asynchronous) confirmation works better. The enableKeys option would let authors who don't need alphanumeric input (video playback) go fullscreen with a low confirmation bar (perhaps none at all, if the fullscreen request is in a click event handler). Also consider what happens if the user focuses something on another display. Do you then drop out of fullscreen, or just blur() the fullscreen window? (I'd vote to leave it and just blur() it, so you can do things like watch fullscreen video on one display and continue working in the other). That sounds like a good idea, but I don't think it needs to be in the spec. It's up to the UA. Another thing to add in here I haven't seen discussed yet is what to show as the background to the fullscreen element. Consider the example of a 16:9 video going fullscreen on a 4:3 display. How do you tell the browser to fill in the extra space around the video with black (or whatever other color you want). Is this a custom css element? The video element already letterboxes. So you'd do something like this: div class=fullscreen style=background:black; position:relative; width:640px; height:480px; video style=position:absolute; width:100%; height:100%; src=.../video ... controls ... /div Making the div fullscreen would override the author geometry and produce the effect you want. Rob -- He was pierced for our transgressions, he was crushed for our iniquities; the punishment that brought us peace was upon him, and by his wounds we are healed. We all, like sheep, have gone astray, each of us has turned to his own way; and the LORD has laid on him the iniquity of us all. [Isaiah 53:5-6]
