Kornel Lesinski wrote on 2/25/2010 6:04 PM:
> On Thu, 25 Feb 2010 16:00:37 -, Timothy D. Morgan
> wrote:
>
>> As a follow up to my paper advocating HTTP authentication over
>> cookies [1], I've built a simple sample application which demonstrates
>> how a combination of XMLHttpRequest and re
ddailey wrote on 9/20/2009 7:43 PM:
> I'm saying to son: "if you can't figure out what it says, type the characters
> you are sure about. Use '?' marks for the letters that you aren't sure about."
You might consider using the Unicode Replacement Character, which is used by
Unicode to "replace a
Elliotte Rusty Harold wrote on 8/10/2009 1:26 PM:
> On Thu, Aug 6, 2009 at 2:09 PM, Ian Hickson wrote:
>
>> Do either of you have a minimum font size preference set?
>>
>
> Yes, I have a 16 point minimum font size set; and removing that moved
> the boxes out of the way. It also made the text in
Charles McCathieNevile wrote on 8/6/2009 2:24 PM:
> On Thu, 06 Aug 2009 15:12:07 -0400, Manu Sporny
> wrote:
>
>> The test ensures that attributes originating in the markup of an HTML4
>> document are preserved by the HTML parser and are preserved in the DOM.
> [...]
>> http://html5.digitalbazaa
Charles McCathieNevile wrote on 8/6/2009 2:24 PM:
> Opera 10 - Opera/9.80 (Macintosh; Intel Mac OS X; U; en) Presto/2.2.15
> Version/10.00
>
> (yeah, the UA string is like that because important websites with
> browser sniffing check version numbers, but only the first digit. I.e.
> they can't co
Under section 2.7 Character encodings[1], there are two [CHARMOD] links, both
of which appear to be broken.
- Bil
[1]
http://www.whatwg.org/specs/web-apps/current-work/multipage/infrastructure.html#misinterpreted-for-compatibility
Ian Hickson wrote on 7/30/2009 7:21 PM:
> On Tue, 21 Jul 2009, Bil Corry wrote:
>> Ian Hickson wrote on 7/19/2009 5:39 AM:
>>> On Wed, 15 Jul 2009, Bil Corry wrote:
>>>> I'm curious too, since the HTML5 draft itself says[1]:
>>>>
>>>> --
Aryeh Gregor wrote on 7/24/2009 5:44 PM:
> On Fri, Jul 24, 2009 at 6:26 PM, Bil Corry wrote:
>> That's a classic XSS vulnerability. The backend developer must know if
>> there are quotes or not in the template, then encode/sanitize the value
>> accordingly.
>
>
Keryx Web wrote on 7/24/2009 2:52 PM:
> In that post I talked about a common scenario. One developer works on
> the business logic. It puts out attribute values. Another developer
> works on the presentation logic. He makes templates. Dev 2 omits the
> quotes and for a long time it might work, sin
Aryeh Gregor wrote on 7/23/2009 8:42 PM:
> On Thu, Jul 23, 2009 at 6:12 PM, Peter Kasting wrote:
>> For my part, I would be very unhappy to see the HTML5 process made more
>> consensus-driven; I much prefer systems that approximate benevolent
>> dictatorships, and I don't perceive the current lead
Aryeh Gregor wrote on 7/22/2009 5:47 PM:
> On Wed, Jul 22, 2009 at 1:56 PM, Bil Corry wrote:
>> The idea here is 'when in doubt, favor the more restrictive option.' There
>> shouldn't be both headers, but if there are, then CSP wins.
>
> Ah, I see, you
Aryeh Gregor wrote on 7/22/2009 12:38 PM:
> On Wed, Jul 22, 2009 at 1:20 PM, Bil Corry wrote:
>> If it's desirable to add a 'report only' feature to CSP, I'd prefer see a
>> second CSP-related header (X-Content-Security-Policy-ReportOnly???) that
>> i
Aryeh Gregor wrote on 7/21/2009 5:34 PM:
> If we could do reports only, then we would probably publish the data
> live in some form, yes.
If it's desirable to add a 'report only' feature to CSP, I'd prefer see a
second CSP-related header (X-Content-Security-Policy-ReportOnly???) that
implements
Ian Hickson wrote on 7/19/2009 5:39 AM:
> On Wed, 15 Jul 2009, Bil Corry wrote:
>> I'm curious too, since the HTML5 draft itself says[1]:
>>
>> -
>> "This specification does not define how new values will get approved. It
>> is expected that the Wik
Jeremy Keith wrote on 7/7/2009 5:32 AM:
> Meanwhile, back on the Rel values wiki page...
> http://wiki.whatwg.org/wiki/RelExtensions
>
> Can anyone help with either of my questions:
>
>> 1. Should I change all of the values derived from XFN from "proposal"
>> to "accepted" as they seem to fit th
James Ide wrote on 7/13/2009 10:05 PM:
> Currently rel="canonical" (
> http://googlewebmastercentral.blogspot.com/2009/02/specify-your-canonical.html)
> is not in the allowed set of link types listed at
> http://www.whatwg.org/specs/web-apps/current-work/#linkTypes . Looking back
> through archive
Adam Barth wrote on 6/20/2009 6:25 PM:
> On Sat, Jun 20, 2009 at 12:57 PM, Bil Corry wrote:
>> I've lost track, is this still something being considered?
>
> I should have an updated draft posted soon.
I'm not clear with the new draft if it now allows Sec-From for same
Ian Hickson wrote on 6/2/2009 8:11 PM:
> On Thu, 2 Apr 2009, Bil Corry wrote:
>> Related, HTML5 currently prohibits sending the XXX-Origin header for GET
>> requests. This is to prevent intranet applications leaking their
>> internal hostnames to external sites (ar
cations should probably implement that in a way such
>> that just one session (identified by a session cookie or whatever) gets
>> logged out -- in contrast to all sessions of a user. The user might be
>> logged in using 2 different browsers and might want to log out in one
>
Den.Molib wrote on 6/2/2009 4:19 PM:
> Bil Corry wrote:
>> It's less likely to occur legitimately, but more likely to occur under a
>> header injection scenario. For example, here's a page that simulates
>> serving an image from an untrusted user[1], with the co
Adam Barth wrote on 6/2/2009 11:47 AM:
> On Tue, Jun 2, 2009 at 9:25 AM, Bil Corry wrote:
>> It's less likely to occur legitimately, but more likely to occur under a
>> header injection scenario.
>
> As I wrote before in this thread, if the attacker can inject hea
Adam Barth wrote on 6/2/2009 3:17 AM:
> Now, consider the reverse:
>
> Content-Type: image/gif
> Content-Type: text/html
>
> In this case, IE renders the image correctly, but Firefox and Chrome
> don't show the image. This is less likely to occur on the web because
> it doesn't work in Firefox
Den.Molib wrote on 6/1/2009 4:55 PM:
> follow the last one, as it's the one provided nearer the content.
And by the same logic, the header closest to the content could be the one that
was injected by an attacker (via application hole) -- so might choosing the
first header be more prudent?
- B
Ian Hickson wrote on 4/27/2009 1:24 PM:
> One option would be to have an attribute, say , which
> causes the user agent to ping the site when the window is closed and there
> are no other windows open to the same origin.
>
> Of course this would break if the other window in question was open to
Ian Hickson wrote on 4/24/2009 6:36 PM:
>>> Why do session cookies not address this already?
>> I think there are still scenarios where it would be valuable for the
>> server to know *exactly when* the user logged out. One example would be
>> those "XY is online" badges you see in many internet
Aryeh Gregor wrote on 4/8/2009 12:23 PM:
> On Wed, Apr 8, 2009 at 1:02 PM, Bil Corry wrote:
>> Is there really a use case for wanting to show up at a site as yourself, but
>> not have any footprint of the visit saved locally?
>
> Yes. The commonly-cited use-case is buyi
Brady Eidson wrote on 4/7/2009 7:24 PM:
> A commonly added feature in browsers these days is "private browsing
> mode" where the intention is that the user's browsing session leaves no
> footprint on their machine.
I must admit, I haven't ever used "private browsing" but my expectation of such
a
Ian Hickson wrote on 4/2/2009 11:33 PM:
> On Thu, 2 Apr 2009, Bil Corry wrote:
>> Since the public-webapps list was never able to reconcile[1] HTML5's
>> Origin header (now renamed XXX-Origin[2]) with CORS's Origin header[3],
>> we're left with two head
Since the public-webapps list was never able to reconcile[1] HTML5's Origin
header (now renamed XXX-Origin[2]) with CORS's Origin header[3], we're left
with two headers with similar implementations and similar names. Due to this,
it may prudent to rename XXX-Origin to something without "Origin"
Related, HTML5 currently prohibits sending the XXX-Origin header for GET
requests. This is to prevent intranet applications leaking their internal
hostnames to external sites (are there other reasons?).
However, there is value in a site being able to determine that a request
originated from it
Bil Corry wrote on 3/24/2009 11:01 AM:
> Ian Hickson wrote on 3/24/2009 12:09 AM:
>> The original plan was to just have the filename. Unfortunately, it
>> turns out that if you do that, there are certain sites that break,
>> because they expect the path (and they expect a Win
Ian Hickson wrote on 3/24/2009 12:09 AM:
> The original plan was to just have the filename. Unfortunately, it turns
> out that if you do that, there are certain sites that break, because they
> expect the path (and they expect a Windows path, no less). This is why
> Opera and IE8 return a fake
Ian Hickson wrote on 3/24/2009 12:09 AM:
> On Mon, 23 Mar 2009, Alex Henrie wrote:
>> First, this change is dishonest. It tells JavaScript that the file is
>> stored somewhere that it is not. And why say anything, true or not,
>> about where the file is stored at all? All JavaScript needs to kno
Tab Atkins Jr. wrote on 3/5/2009 6:55 AM:
> For example, someone writing a calendar app can safely assume that
> any and all dates they have to deal with are within the appropriate
> era.
Unless it contains "This Day in History" type content or a family calendar with
significant genealogical dat
Sigbjørn Vik wrote on 2/20/2009 8:46 AM:
> One proposed way of doing this would be a single header, of the form:
> x-cross-domain-options: deny=frame,post,auth; AllowSameOrigin;
> allow=*.opera.com,example.net;
> This incorporates the idea from the IE team, and extends on it.
Have you taken a loo
Boris Zbarsky wrote on 2/18/2009 9:27 AM:
> On Thu, 25 Sep 2008, Michal Zalewski wrote:
>> 1) Create a HTTP-level (or HTTP-EQUIV) mechanism along the lines of
>>"X-I-Do-Not-Want-To-Be-Framed-Across-Domains: yes" that permits a web
>>page to inhibit frame rendering in potentially dangerous
Kristof Zelechovski wrote on 2/12/2009 11:06 AM:
> I do not know much about UI standards but the rule that the answer should be
> formulated in the language of the question is rather straightforward. It is
> just common sense. Exceptions are questions like "How is that in German?".
No one can c
Křištof Želechovski wrote on 2/12/2009 10:15 AM:
> The UI you described is inconsistent and it should be fixed.
Inconsistent with which UI standard?
- Bil
Kristof Zelechovski wrote on 2/12/2009 9:05 AM:
> Markup for German AND English submissions at the same time, as per your
> request:
> Inhalt:
> Contents:
In my case, we have a single field, "bug description" that may contain both
English and German. And in some cases, even a pure German bug
Kristof Zelechovski wrote on 2/12/2009 6:24 AM:
> Stretching it a bit, a user's language always matches the site's,
> otherwise the user would not be able to submit to the site anything
> that makes sense, except when the site is a gateway for submissions
> to an uninvolved third party in which
Mikko Rantalainen wrote on 1/21/2009 5:03 AM:
>> For another example, consider the case where I post on a Swedish forum
>> in English, knowing that the general level of English in Sweden is
>> excellent and in any case better than the level of my Swedish.
>
> I agree. However, if the forum main
Ian Hickson wrote on 12/12/2008 5:11 PM:
> On Fri, 12 Dec 2008, Bil Corry wrote:
>>> Why do session cookies not address this already?
>> They do to some extent. You can choose to make the session life
>> shorter, increasing security but potentially logging the user out
Ian Hickson wrote on 12/12/2008 2:34 PM:
> If the goal is auto-logout, then what you describe wouldn't help, as it
> would have false-positives (leaving the site when another tab still has
> the site open) and false-negatives (a crash wouldn't log out the user).
Well, more thought needs to go i
Ojan Vafai wrote on 12/12/2008 12:49 PM:
> If we're going for matching what browsers do, there's a number of cases
> (different in each browser) where the confirm doesn't popup. In Chrome, for
> example, if the beforeunload handler takes too long, we kill it and navigate
> away. Similarly, in Fire
Ian Hickson wrote on 12/12/2008 2:50 AM:
> On Thu, 28 Feb 2008, ddailey wrote:
>> The user opens a web application as one of many tabs in a web browser.
>> They then, either within the application window, accidentally hit CTRL W
>> (or its Mac equivalent), or from the operating system, issue a c
45 matches
Mail list logo
