Re: [whatwg] Making cross-domain overlays more user-friendly
On Fri, Feb 5, 2010 at 2:46 PM, Boris Zbarsky wrote: > On 2/5/10 5:40 PM, Rowan Nairn wrote: >> >> - don't introduce new security issues like susceptibility to phishing >> attacks > > > >> - The main URL bar should display the framed URL i.e. >> http://destination-site.com/ > > I'm having a really really really hard time reconciling these two, > especially in the cases when the is not actually visible (e.g. > is visibility:hidden). An alternative is to drop this requirement. It is not necessary to replace the main URL bar as long as the URL of the framed content is available *somewhere*. I wouldn't want to dictate much about the UI to vendors but maybe the requirement would be more like: - The UA must prominently display the URL of the framed page somewhere while making it clear to the user that the main URL is that of the overlay page. I agree that it's a very difficult UI problem. Understanding one URL is hard enough for many users. Rowan
Re: [whatwg] Making cross-domain overlays more user-friendly
On Fri, Feb 5, 2010 at 2:46 PM, Boris Zbarsky wrote: > On 2/5/10 5:40 PM, Rowan Nairn wrote: >> >> - don't introduce new security issues like susceptibility to phishing >> attacks > > > >> - The main URL bar should display the framed URL i.e. >> http://destination-site.com/ > > I'm having a really really really hard time reconciling these two, > especially in the cases when the is not actually visible (e.g. > is visibility:hidden). > >> - The browser should display some chrome around any elements from the >> overlay page that signify them as foreign to the framed content > > Is this supposed to address the issue above? If so the problem is, I'm not > sure I see a good way to do this Then again, UI design is not my strong > point. Yes it is and yes you are right, my proposal is vague on that account. I don't have a good suggestion yet which would both provide enough context to the user and not look horrible. One way would be displaying the URL of the overlay page next to any overlaid elements along with an outline. Maybe someone has a better idea? Rowan
Re: [whatwg] Making cross-domain overlays more user-friendly
On 2/5/10 5:40 PM, Rowan Nairn wrote: - don't introduce new security issues like susceptibility to phishing attacks - The main URL bar should display the framed URL i.e. http://destination-site.com/ I'm having a really really really hard time reconciling these two, especially in the cases when the is not actually visible (e.g. is visibility:hidden). - The browser should display some chrome around any elements from the overlay page that signify them as foreign to the framed content Is this supposed to address the issue above? If so the problem is, I'm not sure I see a good way to do this Then again, UI design is not my strong point. -Boris
[whatwg] Making cross-domain overlays more user-friendly
Hi, In the spirit of paving some cow paths I'd like to put forward a proposal for a future version of HTML. The behavior I'm addressing is sites that replace links to external content with a framed version of that content, along with their own overlay of information and links. I think with some small tweaks it's possible to create a better experience for the user in these situations. I wasn't able to find any discussion of this use case in the archives. Please excuse me if this has already been discussed. Popular websites which often frame other sites instead of linking directly: - facebook - ow.ly - stumbleupon - digg Current practice: - User follows a link which may look like it will take them to destination-site.com - Instead they get a page from overlay-site.com with the page from destination-site.com loaded in an iframe - The viewport contains the destination-site.com frame taking up most of the space, plus some "chrome" from overlay-site.com - The overlay may be completely disjoint from the framed content or overlapping it slightly - The overlay may contain information about the framed content, including URL, title or data specific to overlay-site.com - The overlay may contain links to further act on the framed URL or return to overlay-site.com - The overlay may contain a "close this overlay" button which sets the location of the window to the framed URL - Performing actions in the overlay may cause it to increase in size relative to the framed content, or show dialogs above the framed content Problems for user: - URL of framed page is often hidden - Navigation in framed page does not get rid of the overlay (without explicit frame breaking) - It may not be obvious how to get rid of the overlay - After the user navigates within the frame, information in the overlay no longer applies to framed content - Getting rid of the overlay means refreshing the framed page, either losing scroll position, or having navigated to another page, possibly losing the page entirely. - Framed content may use javascript to detect and break out of frame, denying the user access to the overlay information - Malicious overlay sites may try to cause the user to disclose passwords or private information to them Requirements: - address the problems above - don't introduce new security issues like susceptibility to phishing attacks - don't rely on a lot of extra effort on the part of web designers - degrade gracefully in legacy browsers A Proposal: I would be interested to hear any ideas for addressing this use case better. My idea is as follows: - Add one new attribute to iframe e.g. http://destination-site.com/"; main> - Add one new method to iframe: e.g. removeOverlay() Effect of : - The main URL bar should display the framed URL i.e. http://destination-site.com/ - The browser should display some chrome around any elements from the overlay page that signify them as foreign to the framed content - Possibly the browser should display the URL of the overlay somewhere - The browser should have a built-in button for getting rid of the overlay - Pressing this button would promote the framed content to the top level window, retaining state like scroll position - a iframe.removeOverlay() method should be available in the overlay page which performs the equivalent of this button - Navigation within the framed content should have target=_top implied by default so that navigation always removes the overlay - The framed content should not be aware that it is framed i.e. its window object should equal its top object This proposal would allow current practices to still work but, with the addition of a single attribute, make the experience better for users. Are there any browser vendors interested in implementing such a feature? Cheers, Rowan
[whatwg] Suddenly, ~40% of IE users get HTML5 Theora with no effort
http://www.atoker.com/blog/2010/02/04/html5-theora-video-codec-for-silverlight/ http://arstechnica.com/open-source/news/2010/02/nuanti-brings-html5-and-ogg-theora-video-to-silverlight.ars The 40% is from the blog post at the top. - d.
Re: [whatwg] Lists and legal documents
On Feb 5, 2010, at 10:21 AM, Anne van Kesteren wrote: > These indicators are part of the content and cannot be governed by style > sheets. End users having their own custom style sheets overwriting the > indicators with their own preference would be a problem, for instance. > > I have seen at least one editor used that generates markup like this: > > > a. ... > ... The obsolete and non-conforming @type, along with the @value attribute on , can be used for this purpose: ... Or, if you want to keep the type information together with the value: ... Would it make sense to make this no longer obsolete and non-conforming, as the list item type really is meaningful in many documents? Also, is the behavior of @type currently documented anywhere in HTML5? While the values that @type currently accepts are fairly limited (a, A, 1, i, I, as far as I know), they could be extended to include all of the values defined in CSS, with the old values deprecated. I'm not particularly attached to this solution, but it is implemented in browsers already, and it is fairly widely used; for instance, see the Mozilla Public License http://www.mozilla.org/MPL/MPL-1.1.html , the IBM public license http://www.opensource.org/licenses/ibmpl.php , and various other usages you can find with a Google code search: http://www.google.com/codesearch?q=lang:html+"ol+type"&hl=en&btnG=Search+Code . Many of those uses may be better handled with a stylesheet, but @type is used in many places in which the format of the number is meaningful for referring to clauses in legal documents. -- Brian
Re: [whatwg] api for fullscreen()
On Feb 4, 2010, at 16:53 , Kit Grose wrote: > I also develop kiosk and medical applications where fullscreen is not only > desirable but necessary behaviour. Crippling the API such that the developer > cannot determine whether or not the user permitted their application to run > fullscreen is unnecessary—it's up to developers to use the API in a usable > manner, and up to UAs to provide an easy "escape hatch" if the developer > fails to do so, just like in desktop environments. You're not crippled in this environment. In a kiosk, you write the content, choose your browser, OS and hardware platform. You can (and maybe should) use non-standard extensions to take a vice-like grip of the display and UI. David Singer Multimedia and Software Standards, Apple Inc.
[whatwg] Weaning the Web off of Session Cookies
Hello, Not long ago I published a paper which makes some observations about the state of security in web session management and proposes some small changes in browsers. Someone suggested I post it here for comments. See: http://www.vsecurity.com/download/papers/WeaningTheWebOffOfSessionCookies.pdf I'm currently most interested in feedback on the proposed change in 401 behavior vs the possible header addition for log outs. I realize the WHATWG may not mess with stuff at the HTTP level much, but I definitely welcome any comments. Regards, tim
Re: [whatwg] Codecs for and
On Mon, Feb 01, 2010 at 04:10:51PM -0800, David Singer wrote:
>
> On Feb 1, 2010, at 14:02 , Silvia Pfeiffer wrote:
>
> > On Tue, Feb 2, 2010 at 4:05 AM, Chris McCormick wrote:
> >> I think I speak for all procedural audio people when I say, can't we get
> >> the browsers to allow sample-block access to audio?
> >
> > Sounds like a solid argument to me. But I'm not the one who counts. :-)
>
> I think that the browser vendors are currently trying to nail basic HTML5
> multimedia, then accessibility, then they'll take a breath and ask what's
> next. But do you have ideas as to how?
Hi David,
Since you ask, I'll volunteer my opionion on how this interface should look.
First of all, it would be great to have the audio equivalent of the pixel-level
access that Canvas exposes. In the other post on this thread we can see a
reasonable start at an implementation of that in Firefox:
mozSetup(channels, rate, volume) // called to create the audio stream
mozWriteAudio(buffer[], bufferCount) // called to write buffer to the stream
So building from that, ideally you'd have something like:
// Set up a new audio output stream.
// 'callback' specifies a javascript function which will be called each time
// the buffer is empty.
// This should probably be double buffered to allow javascript time to fill
// the next buffer, or else just ask for two buffers to start with so the audio
// is always one buffer ahead of the callback.
o = setupAudioOutput(channels, rate, bufferSize, callback);
// direct write immediately into the audio buffer (should happen at the
callback)
o.writeAudioToOutput(buffer);
// The following is the input equivalent for accessing the microphone.
// 'callback' specifies a javascript function which will be called each time
// a new buffer of audio data is available and will pass that audio.
callback = function(buf) {
// buf will contain a javascript array, or an AudioBuffer object
// (see below)
}
// set up an listen to the microphone
i = setupAudioInput(channels, rate, bufferSize, callback);
// immediately read what is in the mic buffer at the moment
buffer = i.readAudioFromInput();
Those are the truly essential bits. Code level access to audio in and out.
Once those basics are in place, it would be great to be able to do fast vector
operations on buffers of audio data. It would be cool to have an AudioBuffer
type to enable this. This would basically be a javascript array, but with
convenience audio functions.
a = AudioBuffer([0, 0.5, 0.2, ... (64 samples) ...]);
o.writeAudioToOutput(a);
For example, if you wanted to apply a volume ramp to a chunk of audio data you
might have an operation like this:
// this could be a buffer of audio that has come in, e.g. from the microphone
myBuffer = i.readAudioFromInput();
// this is a buffer of audio data going from 1 to 0 (a 'fade' over one block)
lineBuffer = AudioBuffer([1, 0.9, 0.8, ... (buffer-length number of samples)]);
// multiply our buffer by the fade ramp
newBuffer = myBuffer.multiply(otherBuffer);
// post our audio into the device
o.writeAudioToOutput(newBuffer);
Some other fast AudioBuffer functions for operating on vectors of audio data
would be:
multiply() -> multiply two vectors together (or a constant with a vector)
add() -> add two vectors together (or a constant with a vector)
shift(x) -> delay a vector in time by x samples
* shift would return the remaining samples
* this would be useful for building filters and other audio effects
fft() -> perform a fast fourier transform
* returns an array of two buffers with the result - real + imaginary
ifft(r, i) -> perform an inverse fast fourier transform with two buffers
* returns an array of audio data
copy() -> fast copy of an entire buffer of audio data
Ideally some of those could operate on sigle-value floats as well as vectors of
audio data, where appropriate. Additionally, if two vectors are different
sizes, the default behaviour should be to 'wrap' the shorter vector to match up
with the longer one.
So the developer would do this stuff in the output-buffer callback. If just
these few functions could be implemented it would take us a huge distance
towards being able to do amazing audio stuff right inside the browser without
requiring flash.
Thanks very much for your time.
Best regards,
Chris.
---
http://mccormick.cx
Re: [whatwg] Lists and legal documents
On Fri, Feb 5, 2010 at 9:21 AM, Anne van Kesteren wrote: > These indicators are part of the content and cannot be governed by style > sheets. End users having their own custom style sheets overwriting the > indicators with their own preference would be a problem, for instance. > > I have seen at least one editor used that generates markup like this: > > > a. ... > ... > > to work around this. You can see this online here: > > http://regels-stadskanaal.nl/ > > I think it would be good if we either solved this problem natively or at > least gave some advice for people finding themselves in a similar situation. Since they are indeed part of the content, not a question of style, I'm not seeing anything wrong with putting the marker directly in the content. Preferably you'd still want to use an , though, with list-style:none on it. User stylesheets can't generally turn on markers, as a lot of sites use them or s as navigation and the like, and completely restyle them in such a way that the website would be rendered horribly if you turned the markers back on. Some advice might be a good idea, just recommending still using , turning off markers, and then putting the exact marker content into the s. ~TJ
[whatwg] Lists and legal documents
Legal documents often use various indicators for list items. E.g. a. ... b. ... c. ... or 1. ... 2. ... 3. ... or I. ... II. ... III. ... or A. ... B. ... C. ... etc. These indicators are part of the content and cannot be governed by style sheets. End users having their own custom style sheets overwriting the indicators with their own preference would be a problem, for instance. I have seen at least one editor used that generates markup like this: a. ... ... to work around this. You can see this online here: http://regels-stadskanaal.nl/ I think it would be good if we either solved this problem natively or at least gave some advice for people finding themselves in a similar situation. (That editor/site also has ordered definition lists, with similar markup.) -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] some thoughts on sandboxed IFRAMEs
On Thu, Feb 4, 2010 at 11:12 AM, Ian Hickson wrote: > On Mon, 25 Jan 2010, Alex Russell wrote: >> >> AFAICT, the objections fall into several buckets: >> >> 1.) Users might pick badly or may re-use nonces when they shouldn't. >> 2.) Escaping " is believed to be more secure because it's likely to >> break more often, raising developer awareness >> 3.) The fix to correct escaping problems is believed to be more reliable >> >> I'm interested in 2 and 3. Users will do dumb things, and both 2 and 3 >> assumes a similar baseline scenario as 1; a developer did something >> dumb. Nonces need not be cryptographically strong for most apps, so >> the big problem is re-use. UA's have broad leeway here to prevent >> re-use on origins and deny sandboxing to containers that re-use the >> same nonces on a single page. They can even help by keeping a list of >> recently used nonces and denying reuse. > > Could you elaborate on how one could avoid reuse? That seems like a bad > idea, since it would prevent any non-client caching mechanism from > working. The problem is not nonce re-use, it's that the token has to be > either unpredictable or unspoofable. (It could be predictable and > unspoofable if it was constructed using a diagonal of the user's text.) Seems like it should be easy to get secure tokens by doing: $token = sha512_hex($input); print "$input"; (or whatever the sandbox syntax is), so there's no need to worry about cryptographically secure RNGs or nonces or reuse or caching problems. Is this what you meant by "a diagonal of the user's text"? (I'm assuming here that the UA treats the token as an opaque blob, it doesn't try to recompute the hash itself, so it's robust to changes in character encoding etc. People could still choose insecure tokens instead, but it's pretty trivial to use the hash solution correctly in most programming environments (easier than good random numbers). To attack it, you'd have to pick two strings X and Y and a hash H such that hash(X+""+Y) = H, which for a good hash function should be hard, I think.) -- Philip Taylor exc...@gmail.com
Re: [whatwg] some thoughts on sandboxed IFRAMEs
On 5 Feb 2010, at 14:19, Lachlan Hunt wrote: >> where $token is the random part. This avoids oddity of attributes in >> closing tag, and is compatible with XML. In XML you could also use: >> >> <$token:sandbox xmlns:$token="…"> > > No, you couldn't use a namespace like that, because then the sandbox element > would not be in the HTML namespace, and thus would not have any known > semantics. Eh, I've left out namespace URI, because I don't like to type it. Here's complete example that applies HTML semantics: http://www.w3.org/1999/xhtml";> http://www.w3.org/1999/xhtml";> HTML -- regards, Kornel
Re: [whatwg] some thoughts on sandboxed IFRAMEs
Lachlan Hunt wrote: Kornel Lesinski wrote: However, if we're going to introduce token-based sandbox anyway, I suggest putting token in tag name: ... where $token is the random part. This avoids oddity of attributes in closing tag, and is compatible with XML. In XML you could also use: <$token:sandbox xmlns:$token="…"> No, you couldn't use a namespace like that, because then the sandbox element would not be in the HTML namespace, and thus would not have any known semantics. Um, ignore me. I'm just not thinking properly today. -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: [whatwg] some thoughts on sandboxed IFRAMEs
Kornel Lesinski wrote: However, if we're going to introduce token-based sandbox anyway, I suggest putting token in tag name: ... where $token is the random part. This avoids oddity of attributes in closing tag, and is compatible with XML. In XML you could also use: <$token:sandbox xmlns:$token="…"> No, you couldn't use a namespace like that, because then the sandbox element would not be in the HTML namespace, and thus would not have any known semantics. -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: [whatwg] some thoughts on sandboxed IFRAMEs
On 4 Feb 2010, at 17:44, Michal Zalewski wrote: >> >> If there's no HTML, there's no need for a sandbox, so the simplest >> solution is just to escape the > Which people fail at, big time. There are 50,000+ entries on > xssed.com, many of them against big sites presumably developed by > skilled developers with the help of sophisticated frameworks - > microsoft.com, google.com, amazon.com, ebay.com, etc. It is a really > low-effort tweak to accommodate it here, and it may offer a very > significant security benefit, so...? The problem comes from lack of escaping of any kind, so change in escaping method will not fix the problem, i.e., Hello $unescaped_name is as vulnerable as: Hello > I think the difference is huge; in a typical web framework, you need > to explicitly escape every single piece of potentially dangerous > attacker-controlled input to stay safe - and because people tend to do > some validation at input stage, it's very difficult to audit for it. > Escaping also needs to be very different depending on the context > (URLs need to be encoded differently than HTML parameters, and > differently than standalone text). > > So even though your framework may provide several escape() functions, > it's very easy to get it wrong, and people constantly do. OTOH, if > your framework provides a get_token() function, there's really not > that much to using it properly. That's problem with the frameworks (a big one, admittedly). However, there are templating engines that escape all variables, everywhere, by default, and this solves the problem very well. Addition of token-based sandbox won't improve anything in cases where authors forget to escape or wrongly assume that input is already filtered/escaped or harmless. If someone forgets to add escape(), why would they remember to add ? Additionally will cause new security problem in all current UAs, so for plain text I don't see any benefit at all. However, if we're going to introduce token-based sandbox anyway, I suggest putting token in tag name: ... where $token is the random part. This avoids oddity of attributes in closing tag, and is compatible with XML. In XML you could also use: <$token:sandbox xmlns:$token="…"> -- regards, Kornel Lesiński
Re: [whatwg] Drag-and-drop feedback
Quick correction/addendum: FireFox seems to be actually fine with CRLF as
line separator in setData("text/uri-list", data) and will return only the
first URL within data on getData("URL"). However, it doesn't seem to return
files as URLs with getData("text/uri-list"), which I guess would be my third
question:
.) should dragged files be converted to file URLs and returned in a call to
getData("text/uri-list") or getData("URL")?
- Roland
On Fri, Feb 5, 2010 at 4:34 PM, Roland Steiner wrote:
>
> Since I am currently in the process of fixing bugs in this area for Chrome,
> there are 2 things I'm wondering about:
>
> .) whether "Text" and "URL" should be part of the return value of "types"
> (probably not, according to Ian's comment). However, since "text/uri-list"
> may in fact not contain a valid URL, the presence/absence of "URL" in types
> could be useful. I.e., it could indicate whether getData("URL") will return
> something useful.
>
> .) Judging from the example in
> https://developer.mozilla.org/En/DragDrop/Drag_Operations#drop , Firefox
> seems to use only LF for line feeds within text/uri-list, while RFC 2483
> calls for CR-LF for all "text/*" formats, including "text/uri-list", as does
> the HTML5 spec in the section on the drag-and-drop processing model.
> Since the UA has to parse "text/uri-list" for the return value of "URL", I
> wonder whether both should be accepted (break on LF, filter out any CR). The
> other problem here is that WebKit/Safari and Chromium convert files to file
> URLs to return for "text/uri-list"/"URL". Is there a consensus how this
> difference should be best handled (or is this just a bug in FF)?
>
>
> Cheers,
>
> Roland
>
>
> On Thu, Feb 4, 2010 at 11:29 AM, Ian Hickson wrote:
>
>> Webkit and Firefox are case-sensitive. IE only does "TEXT" and "URL", but
>> case-insensitively (at least for Text, I didn't test URL). Chrome is
>> case-insensitive for everything.
>>
>> Tough call. I guess we'll go with just converting everything to lowercase,
>> so that it's case-insensitive.
>>
>> BTW I noticed Chrome includes "Text" and "URL" in the .types list. That's
>> incorrect according to the spec.
>>
>> --
>> Ian Hickson U+1047E)\._.,--,'``.fL
>> http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
>> Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
>>
>
>
