Re: [whatwg] Fetch: crossorigin="anonymous" and XMLHttpRequest

[Anne van Kesteren]

On Tue, Mar 19, 2013 at 6:30 PM, Jonas Sicking  wrote:
> I don't think that that is a particularly convincing argument since there is
> no confused deputy problem here, and if a website is making security
> decisions based on referrer headers even when there are no other identifying
> signals, then that website is a lost cause.

Not if the referring URL was a capability, which I think might have
been the point.


> In other words, I see no new attack vectors being introduced, but I do see
> additional value, if we keep the referrer.

You do know there are efforts to making Referer obsolete within
Mozilla so to leak less information about the user?


> Regarding origin. I guess I don't care terribly strongly either way. But I
> don't really see the value of creating an exception here from regular CORS
> given that I don't see any attack vectors that are being closed.

Yeah, hmm, I wish more people participated in this thread.


-- 
http://annevankesteren.nl/

Re: [whatwg] Hide placeholder on input controls on focus

[Kit Grose]

On 20/03/2013, at 1:42 AM, Tim Streater wrote:

> On 18 Mar 2013 at 23:44, Glenn Maynard  wrote: 
> 
>> On Mon, Mar 18, 2013 at 12:51 PM, Markus Ernst  wrote:
>> 
>>> A reason for the behaviour of Firefox and Chrome may be that some user may
>>> not have read the placeholder text before focusing the control. Anyway, if
>>> this behavior lets some users think they can't even fill in the form, there
>>> must be something wrong about it.
> 
>> I've seen browsers (or maybe pages emulating placeholder in script) that
>> hide the placeholder text while the input field is focused.  When the
>> placeholders are labels for the inputs, it's incredibly annoying to have to
>> focus something else in order to see the placeholder text.  If placeholders
>> are meant to be useful and not just eyecandy, they need to remain visible
>> until the user enters something.
> 
> But that's not what users do. You read the placeholder text, which may may 
> hint at what is expected there, and the field should have a separate label. 
> Then you focus there, and the placeholder text should vanish. Why? because 
> I've lost count of the number of users I see trying to select the placeholder 
> text so they can delete it, and then start typing.

I believe this issue—in the limited situations it presents itself—is more a 
factor of the treatment of the placeholder itself than the existence of a 
placeholder.

One of the key benefits of the HTML5 placeholder attribute is the 
standardisation of its presentation and behaviour, so it can eventually become 
more predictable to users. Right now, Safari uses an input with a placeholder 
string for its URL bar ("Search Google or enter an address"), Chrome uses one 
in its settings interface ("Search settings"), Firefox uses one for its 
awesomebar ("Go to a Web Site") and for its search field ("Google"). Opera uses 
one for its search field too ("Search with Google"). Internet Explorer seems to 
be the only browser left that _doesn't_ do this (although it used to in IE8, 
when its search field said, e.g. "Live Search").

Facebook uses a placeholder for pretty much every form they have (including 
their search form and wall submission form). Wikipedia uses it for its search 
form too.

In almost every case the placeholder remains visible until the user has begun 
typing, as I strongly believe it ought to be remain in the specification, since 
it provides the contextual hint for as long as possible.

That it has historically been implemented in a way that implies selectable 
content is, I believe, chiefly due to the lack of support for a "right" way to 
do this (which has led many developers to implement the placeholder text simply 
by setting the field's value to the placeholder text as the simplest 
implementation).


Kit Grose
User Experience + Tech Director,
iQmultimedia

Re: [whatwg] Priority between and content-disposition

[Glenn Maynard]

On Tue, Mar 19, 2013 at 1:15 AM, Michal Zalewski wrote:

> > This is about how the Web works, not browser UIs.  If I click a link on
> > www.computerviruses.com, and it prompts me to save a file to disk, I
> make my
> > decision of what to do with the file based on the context of the link I
> > clicked.
>
> In my experience, the web is a lot more complicated than that. There
> are many interesting corner cases here, including but not limited to
> downloads initiated by other documents / windows (say,
> http://lcamtuf.coredump.cx/fldl/).
>

I don't think the solution to that issue is to put the hosting URL in a big
font in the download dialog.  People won't read it; if they do, they won't
know how to interpret it (amazonaws.com probably looks "safe" to many
casual users), and some browser UIs don't even have a download popup
(Chrome).

My intuition for this case is that the download UI should be tab-modal to
the page that started the download.  For example, flash the tab that
started the download, and only prompt to download as an interface internal
to that tab.  In Chrome, for example, this might show up like the "download
this dangerous file?" prompt, but only be seen on the tab that started the
download.

This is a tricky case, but I don't think this feature makes it any worse,
since I don't think showing the hosting URL is a solution.  More generally,
given how hard it is to even get people to check for a TLS lock icon, I
don't think expecting users to evaluate URLs is reasonable.

With content sniffing, we have learned the hard way that
> second-guessing the intent of the owner of a server in terms of the
> way the content should be interpreted by the browser will almost
> always bite back. I think we're making the same mistake here (and in
> several other areas, too).
>

Content sniffing is something else entirely: it's software automatically
ignoring what the server says and doing something else.  This is an
explicit override by authors, not second-guessing.

-- 
Glenn Maynard

Re: [whatwg] Fetch: crossorigin="anonymous" and XMLHttpRequest

[Jonas Sicking]

On Mar 19, 2013 4:20 AM, "Anne van Kesteren"  wrote:
>
> On Mon, Mar 18, 2013 at 3:57 PM, Jonas Sicking  wrote:
> > By not including cookies or other login information you are already
> > forcing the capability model since you can't tell the connection from
> > one that is server-to-server.
> >
> > Including the referrer header, at least by default, seems very useful
> > still since there is lots of infrastructure in servers which are using
> > those for logging purposes.
>
> I don't disagree, but they wanted to avoid exposing any kind of
> originating data so people could not make trust decisions based on
> that at all (however silly doing that may be). See
> http://www.w3.org/TR/UMP/#request-sending in particular.
>
> I don't really mind what we do here either way.

I don't think that that is a particularly convincing argument since there
is no confused deputy problem here, and if a website is making security
decisions based on referrer headers even when there are no other
identifying signals, then that website is a lost cause.

In other words, I see no new attack vectors being introduced, but I do see
additional value, if we keep the referrer.

Regarding origin. I guess I don't care terribly strongly either way. But I
don't really see the value of creating an exception here from regular CORS
given that I don't see any attack vectors that are being closed.

/ Jonas

Re: [whatwg] Priority between and content-disposition

[Roger Hågensen]

On 2013-03-19 15:31, Nils Dagsson Moskopp wrote:

Roger Hågensen  schrieb am Tue, 19 Mar 2013
14:31:15 +0100:


[…]
What should be shown if there is an issue/conflict?

Maybe:
Download "https://example.com/reports/1/xml/"; as "report1.xml" ?
WARNING! File identified as actually being an executable! (*.exe)

At least here on Debian GNU/Linux, executables have no file extension.
Besides that, what would be the MIME type of windows executables?


application/octet-stream as far as I know for most exes and misc 
binaries on most platforms, and windows exe's start with "MZ" as the 
very first two bytes.





Or:
Download "https://example.com/reports/1/xml/"; as "report1.xml" ?
NOTE! File identified as not being a xml, appears to be text. (*.txt)

So, what about polyglots?



Data hiding? (well close to it anyway) That is way beyond the scope of 
this, also I doubt you could do that with a executable on most platforms.
And if a .jpg turns out to have a zip attached then it just a .jpg with 
a zip attached, it's as simple as that.



The key though is showing: Download "url" as "file.ext" ?
And in cases where a quick file header scan reveals a possible issue
(or simply wrong fileformat extension) either a notice or warning
text in addition.
But this is only if the user actually hose "Save As" in the download
dialog, they might have chosen "Share on facebook" or "Print" or
"Email to..." or even "Open"
a similar but different dialog would obviously be needed in that case.

I find all of this approach insanely complex for a negligible benefit.



How so? All the information is mostly there. (HTTP header from server is 
always fetched be it HEAD, GET, POST calls, and a browser usually 
fetches the beginning of a file to sniff anyway).
The suggested name and extension would be in the download attr, and href 
is as it's always been.


Today if you download/run a link to a exe you do get asked if you really 
want to run this. (and this is a browser UI not a OS UI).

What is so complex about simply adding : as "file.ext ?
to that UI which is already there?

In cases where the download attr and href and the server header and 
browser sniffing all agree it looks no different (nor behaves any 
different) than it does today when you right click and choose "Save As...".
What is so complex about just suggesting some consistency in behavior 
with a improvement to boot?


And if you refer to the "Share on/at..." or "Email to..." or Print or 
Open then those are dialog options that do exist today or will, and was 
just used as examples and is not otherwise part of this in any other way.


Maybe there is a language barrier here and I'm not explaining this 
correctly, in which case I apologize for that. Let me know if anything 
in particular needs clarification.



--
Roger "Rescator" Hågensen.
Freelancer - http://www.EmSai.net/

Re: [whatwg] [html][webcomponents]: Link element in body?

[Boris Zbarsky]

On 3/19/13 11:18 AM, Brian Kardell wrote:

Section 4.2.4 of the HTML Standard[1] contains a note:
"Note: If the rel attribute is used, the element is restricted to the
head element. When used with the itemprop attribute, the element can
be used both in the head element and in the body of the page, subject
to the constraints of the microdata model."


That's an authoring requirement, like pretty much everything to do with 
element content models.


As in, if you have a  without itemprop but with rel inside  
your HTML validator will complain at you (and chances are your page will 
end up with FOUC and whatnot, which is why this is not something the 
spec makes valid).



However, all modern browsers at least seem to respect/treat rel link
elements in the body as most developers would expect (ie, they work
just fine).


Yes, and the spec requires that behavior.  Note that 
http://www.whatwg.org/specs/web-apps/current-work/multipage/semantics.html#concept-link-obtain 
says nothing about where the  is located.  You could stick it as a 
child of the  (or even as the documentElement) and that algorithm 
would still run.



Is it worth opening a bug or am I missing something important?


The spec lists UA implementation requirements and authoring 
requirements.  Generally speaking, the UA requirements define processing 
of all input, including input that is not valid per the authoring 
requirements.


-Boris

[whatwg] [html][webcomponents]: Link element in body?

[Brian Kardell]

Section 4.2.4 of the HTML Standard[1] contains a note:
"Note: If the rel attribute is used, the element is restricted to the
head element. When used with the itemprop attribute, the element can
be used both in the head element and in the body of the page, subject
to the constraints of the microdata model."

However, all modern browsers at least seem to respect/treat rel link
elements in the body as most developers would expect (ie, they work
just fine).

Given that this would appear to be a de-facto standard and that is to
some extent the goal of the spec (documenting what _is_ actually
standard), I'm curious as to the discrepancy... Can someone (Hixie
maybe) explain?  Is it worth opening a bug or am I missing something
important?

1. http://www.whatwg.org/specs/web-apps/current-work/#the-link-element


--
Brian Kardell :: @briankardell :: hitchjs.com

Re: [whatwg] Hide placeholder on input controls on focus

[Tim Streater]

On 18 Mar 2013 at 23:44, Glenn Maynard  wrote: 

> On Mon, Mar 18, 2013 at 12:51 PM, Markus Ernst  wrote:
>
>> A reason for the behaviour of Firefox and Chrome may be that some user may
>> not have read the placeholder text before focusing the control. Anyway, if
>> this behavior lets some users think they can't even fill in the form, there
>> must be something wrong about it.

> I've seen browsers (or maybe pages emulating placeholder in script) that
> hide the placeholder text while the input field is focused.  When the
> placeholders are labels for the inputs, it's incredibly annoying to have to
> focus something else in order to see the placeholder text.  If placeholders
> are meant to be useful and not just eyecandy, they need to remain visible
> until the user enters something.

But that's not what users do. You read the placeholder text, which may may hint 
at what is expected there, and the field should have a separate label. Then you 
focus there, and the placeholder text should vanish. Why? because I've lost 
count of the number of users I see trying to select the placeholder text so 
they can delete it, and then start typing.

--
Cheers  --  Tim

Re: [whatwg] Priority between and content-disposition

[Nils Dagsson Moskopp]

Roger Hågensen  schrieb am Tue, 19 Mar 2013
14:31:15 +0100:

> […]

> What should be shown if there is an issue/conflict?
> 
> Maybe:
> Download "https://example.com/reports/1/xml/"; as "report1.xml" ?
> WARNING! File identified as actually being an executable! (*.exe)

At least here on Debian GNU/Linux, executables have no file extension.
Besides that, what would be the MIME type of windows executables?

> Or:
> Download "https://example.com/reports/1/xml/"; as "report1.xml" ?
> NOTE! File identified as not being a xml, appears to be text. (*.txt)

So, what about polyglots?


> […]

> The key though is showing: Download "url" as "file.ext" ?
> And in cases where a quick file header scan reveals a possible issue
> (or simply wrong fileformat extension) either a notice or warning
> text in addition.
> But this is only if the user actually hose "Save As" in the download 
> dialog, they might have chosen "Share on facebook" or "Print" or
> "Email to..." or even "Open"
> a similar but different dialog would obviously be needed in that case.

I find all of this approach insanely complex for a negligible benefit.

-- 
Nils Dagsson Moskopp // erlehmann

Re: [whatwg] Priority between and content-disposition

[Roger Hågensen]

On 2013-03-18 13:50, Bjoern Hoehrmann wrote:

* Jonas Sicking wrote:

It's currently unclear what to do if a page contains markup like  if the resource at audio.wav
responds with either

1) Content-Disposition: inline
2) Content-Disposition: inline; filename="B.txt"
3) Content-Disposition: attachment; filename="B.txt"

People generally seem to have a harder time with getting header data
right, than getting markup right, and so I think that in all cases we
should display the "save as" dialog (or display equivalent download
UI) and suggest the filename "A.txt".

You mention `audio.wav` but that is not part of your example. Also note
that there are all manners of other things web browsers need to take in-
to account when deciding on download file names, you might not want to
e.g. suggest using "desktop.ini", "autorun.inf" or "prn" to the user.

That aside, it seems clear to me that when the linking context says to
download, then that is what a browser should do, much as it would when
the user manually selects a "download" context menu option. In contrast,
when the server says filename="example.xpi" then the browser should pick
that name instead of allowing overrides like

   ...

which would cause a lot of headache, especially from third parties. And
allowing such overrides in "same-origin" scenarios seems useless and is
asking for trouble ("download filenames broken after moving to CDN").


The expected behavior from ...> is that it is a download "hint"
A UI of some sorts should appear where the user has the option to 
download. (for example a requester with Run Now and Save As or Print or 
Share or Email and similar).
download="" attribute is  just a browser hint, a user (and thus the 
browser) can (and should be able to) override this behavior if desired 
(in options somewhere, maybe under a Applications tab?)


If the server provided file-type matches that of the href (i.e. they are 
both .xpi), or are identical then the download attribute filename "hint" 
should be the default.


If the server provided a file-type that conflict with the href then the 
browser need to use some logic to figure out which of the three to display.
If the server provided a filename is different than the href then the 
browser need to use some logic to figure out which of the three to display.
If download attribute has a full or relative url then href (or server) 
should be used instead.


What is the best logic to use?
Both href and download are put there by either the author of the page or 
some automated system (forum/blog software/CDN/who knows...)
href and download in that respect should be equally trusted (or is it 
distrusted?)
What the server says always trumps href and download, and href (or 
server) always trumps download if href and server match in file-type.

The only exception is situations where the content is generated in some way.
Download Report 1 
as CSV
Download Report 1 
as XML


Now the server might categorize it as "text/html", I've seen this by 
mistake on servers before (not properly configured),

or the script did not set the proper content type when creating the headers.
So in this case the download hint is very helpful.

How many web scripts "extensions" out there is there? .php .asp .cgi .py 
.???

What about this then?
download="report1.xml">Download Report 1 as XML
and with the server type "text/html" by mistake, how to handle that 
then? Whom to "trust"?
The server may (or may not) redirect to a url of 
example.com/reports/1/index.php?type=xml or 
example.com/reports.php?id=1&type=xml

it may also simply remain example.com/reports/1/?type=xml
Or what if it is download="report1.xml">Download Report 1 as XML


A URL is simply a way to point to some content, what to do with it is up 
to the browser and the user.
One would hope the server serves it as the right type but this is not 
always true.
The page author may not even have control or the ability to add 
filetypes to the server configuration. (webhotels for example)
The download attribute indicate the authors desired behavior for 
clicking the link.


So let's break it down (from a more or less browser's point of view):

1. The user clicks the link, there is a download attribute so we will 
show a dialog with a Save As (and possibly other alternatives, dependent 
on browser and OS features and user options).
2. If there is no download attribute/no filename hint, then use href and 
try to make a user friendly filename out of that.
3. Listen to what the server says (in the HTTP header), does it say it 
is  a .xml ? If yes then that is good, if not then treat it as if it was 
binary for the moment.
4. Make sure the text displayed is along the line of: Download 
"https://example.com/reports/1/xml/"; as "report1.xml" ?
5. When download has started do a quick "magic id" check, is it a exe, 
is it something else, is it a xml as we expected?
6. If it seems to be what it is supposed to be, start downloading to 
whatever location (or alternative behavior)

Re: [whatwg] Fetch: crossorigin="anonymous" and XMLHttpRequest

[Anne van Kesteren]

On Mon, Mar 18, 2013 at 3:57 PM, Jonas Sicking  wrote:
> By not including cookies or other login information you are already
> forcing the capability model since you can't tell the connection from
> one that is server-to-server.
>
> Including the referrer header, at least by default, seems very useful
> still since there is lots of infrastructure in servers which are using
> those for logging purposes.

I don't disagree, but they wanted to avoid exposing any kind of
originating data so people could not make trust decisions based on
that at all (however silly doing that may be). See
http://www.w3.org/TR/UMP/#request-sending in particular.

I don't really mind what we do here either way.


-- 
http://annevankesteren.nl/

Re: [whatwg] Hide placeholder on input controls on focus

[Markus Ernst]

Am 19.03.2013 00:44 schrieb Glenn Maynard:

On Mon, Mar 18, 2013 at 12:51 PM, Markus Ernst  wrote:


A reason for the behaviour of Firefox and Chrome may be that some user may
not have read the placeholder text before focusing the control. Anyway, if
this behavior lets some users think they can't even fill in the form, there
must be something wrong about it.



I've seen browsers (or maybe pages emulating placeholder in script) that
hide the placeholder text while the input field is focused.  When the
placeholders are labels for the inputs, it's incredibly annoying to have to
focus something else in order to see the placeholder text.  If placeholders
are meant to be useful and not just eyecandy, they need to remain visible
until the user enters something.



The spec does clearly say: "The placeholder attribute should not be used 
as an alternative to a label."

http://www.whatwg.org/specs/web-apps/current-work/multipage/common-input-element-attributes.html#the-placeholder-attribute

Thus, the use case you mention is an authoring mistake. I am sure that 
the spec should weigh possible confusion of unexperienced users higher 
than problems caused by authoring mistakes. (Also, misusing the 
placeholder as a label is potentially annoying once the value of the 
control is not the empty string anymore: As you can't even focus 
someting else in order to see the placeholder text, you will have to 
delete whatever you have typed before.)


Anyway, both your and my use cases may be worked around by an obvious 
visual distinction of the placeholder in focused fields. E.g. the 
placeholder text may be rendered almost transparent when the control has 
focus. There must be something that indicates an unexperienced user that 
(s)he can enter text now, which is not the case in the current 
implementations of Firefox and Chrome.


(I must admit I am surprised about this discussion. Huge efforts are 
made in HTML development to enhance accessibility by removing obstacles 
for various groups of users. I am reporting an obstacle. Of course the 
problem will lose weight once placeholders are commonly known, but it is 
still a source of confusion.)