Re: [whatwg] input type=password... restrict reading value from JS?
As a web developer, if I wanted access to the password, I would then avoid
using the input type=password field, and create my own field that reads
characters (perhaps via onkeyup), and fakes a password field visually.
I also think it's a bad idea to change the behavior of input
type=password because it will break websites that assumed they could read
the value. Perhaps a website checks against a user's past 10 passwords to
see if they are using the same one, via XHR. Or perhaps the entire login
process is XHR. Who knows.
I think there is definite room for improvements in security when it comes to
input type=password, and I've also been trying to make it more secure by
designing some sort of client-side hashing. But I don't think restricting
JavaScript from reading the value is a security benefit... in my opinion, it
would just be a hassle for developers who need to read the value, and force
them to use another means of password entry where they can read the value.
~Sean
On Sun, Jul 10, 2011 at 4:38 PM, Aryeh Gregor simetrical+...@gmail.comwrote:
On Sun, Jul 10, 2011 at 4:08 AM, Alex Vincent ajvinc...@gmail.com wrote:
This is just an idea.
For the last 10+ years, password inputs have been accessible from
scripts,
with nary a complaint. If I have this code:
form action=javascript:void
div
input type=password id=pw
button onclick=alert(document.getElementById('pw').value)Show
password!/button
/div
/form
I can extract the password by clicking on the button. More to the point,
with a XHR I can send that password somewhere it shouldn't go... (well,
with
cross-domain security code, maybe not, but that's not the point.)
You can send it anyway by changing the action attribute on the form
and calling submit(). So what attack scenario are you actually
avoiding here? You'd need a really strong security benefit for it to
be possible to even contemplate breaking so many websites.
Re: [whatwg] input type=password... restrict reading value from JS?
We would likely end up with some more of these lovely interfaces: https://online.westpac.com.au/ Try using that without a mouse and not going insane/grossly disclosing your input to anyone paying mild attention to your screen. Tom On 11/07/2011 23:29, Sean Connelly wrote: As a web developer, if I wanted access to the password, I would then avoid using theinput type=password field, and create my own field that reads characters (perhaps via onkeyup), and fakes a password field visually. I also think it's a bad idea to change the behavior ofinput type=password because it will break websites that assumed they could read the value. Perhaps a website checks against a user's past 10 passwords to see if they are using the same one, via XHR. Or perhaps the entire login process is XHR. Who knows.
Re: [whatwg] Call for Clarification of the Menu Element Et Al.
Þann lau 9.júl 2011 04:29, skrifaði Hugh Guiney: 6.1 On that note, why is the spec enabling the use of unstyled spans to achieve alternative rendering? Doesn't this give meaning (however contextual) to an element that is supposed to be semantically neutral? Can you think of any other uses for spans? Theoretically you could just want to identify text for later reference, but this need is better served by divs. If you want to reference a few words, you're probably better off quoting them (and citing a greater resource containing those words and context).
Re: [whatwg] input type=password... restrict reading value from JS?
Þann sun 10.júl 2011 08:08, skrifaði Alex Vincent: /** * Check if a password field's value matches another. * * @param otherPassword Another password element. * * @throws Error if this.type != password * @throws Error if other.type != password * * @returns Boolean True if the fields match. */ boolean passwordEquals(in HTMLInputElement otherPassword); I believe this to belong to CSS. User agents could either ask or require users to input error-prone and important fields twice, without submitting the same value twice. This could be the default rendering (in some UAs) for strong inputs (i.e. input descendants of strong). This has the potential benefit of allowing media-aware prefixes for locales where that makes sense (as in 'Retype Password' vs 'Confirm Password'). Note that the confirmation input in http://www.whatwg.org/specs/web-apps/current-work/multipage/common-input-element-attributes.html#the-required-attribute is optional. !DOCTYPE html titleRegister a FooBar account/title form action=register method=POST labelUsername input name=user required/label stronginput type=password name=pass required/strong /form /** * Check the strength of the password. * * @param type The type of check to execute. * * @returns 0 if dangerously low security * @returns 1 if soon-to-be-deprecated low security * @returns 2 if adequate security * @returns 3 if good security * @returns 4 if strong security * @returns 5 if entropy-death-of-the-universe security :-) */ unsigned octet passwordStrength(in DOMString type); I don't think this is a good idea. Can't user-agents warn about insecure passwords without the help of author-supplied scripts?
Re: [whatwg] The blockquote element spec vs common quoting practices
On 7/8/11, Jeremy Keith jer...@adactio.com wrote: Bjartur wrote: Citation will most likely contain the cited resource (@cite), the title of the cited resource (@title) and the date and optionally time of the quote (@datetime?). All three of which are invisible and so do not match the use cases that Oli has outlined. At least @title has a tooltip but the @cite attribute has proven to be a complete disaster, unsupported by user agents and ignored by authors, I'd like to reemphasize that: *unsupported by user agents* So you're saying that because attributes aren't rendered by default, user agents will ignore them and thus we should not use them? Why can't we fix UAs? Putting attribution inside blockquotes seems like a hack around lax support for attributes. That what's CSS is for. precisely because it is *hidden* metadata. http://www.well.com/~doctorow/metacrap.htm Yes, people lie. Unless you're arguing that using attribute syntax will encourage misquoting, I'll regard this article as interesting, correcting and unrelated. The article argues against searching for information in uncensored repositories of structured data prone to spamming, not typing footerasdf/footer instead of title=asdf. So I think that we can learn from the history of the @cite attribute in that it shows us how *not* to do it. But is it really possible to mark such citations up without presentational elements? I'm not sure I understand the question. Do you mean presentational as in not conveying semantics or presentational as in visible? Not conveying semantics. I'm not arguing against rendering attribution. On the contrary, IMO user agents should render at least the title of the cited resource. Interactive user agents should additionally make the cited resource available in manner similar to how they present other hyperlinked resources. Additionally user agents with superfluous screen space may render the datetime. Handheld renderings should of course not display the datetime without user interaction, but reserve the screen estate for more critical information, such as the quotation itself. It's simply a question of blockquote Lorem ipsum footer a href=kennitala:2112952019 title=Bjartur ThorlaciusBjartur/a on time datetime=1997-4-2the second April, 1997/time /footer /blockquote vs blockquote title=Bjartur Thorlacius datetime=1997-4-2 cite=kennitala:2112952019 Lorem ipsum /blockquote
Re: [whatwg] Call for Clarification of the Menu Element Et Al.
On Fri, Jul 8, 2011 at 9:29 PM, Hugh Guiney hugh.gui...@gmail.com wrote: Hey All, I was in the process of coding a prototype for a site I'm working on when I decided that certain nav's should actually be menu's. While the basic concept is apparent, unfortunately, with zero browser implementation at this time, it is impossible to actually know what my markup is doing (or rather, would do). Really, since there are no browser implementations yet, it's best to *not* use it yet. Without any feedback in the form of actually seeing it work, there's a good chance you'll accidentally get it wrong. As well, your early use of it counts as legacy usage if we decide that, upon attempting to implement it, it needs to be changed. I'll go ahead and answer the rest of your email as if you were speaking from a hypothetical position, but take what I said into account. Using something pre-implementation doesn't help you, and it has a chance of hurting the feature in the future. So I looked to the spec for guidance, but ultimately it leaves me very confused. These are some points I feel could be addressed, in no particular order: 1. How does one know whether to wrap a nested menu in li or leave it as a direct child element? Are these semantically-equivalent coding styles or is there a difference? 1.1. When marking up a menu specifically with *multiple* menu items, is menu/li the only way to do it or would menu/menu also be appropriate? 2. What is the difference between a menu containing command elements and a menu containing form controls? Do they merely favor future and legacy UAs respectively? Mostly, yes, though in some cases using form elements lets you define certain types of commands more easily. For example, you can use select to define a group of type=radio commands more easily/tersely than if you used input type=radio name=foo or command type=radio radiogroup=foo: 3. The spec should provide examples demonstrating when it is better to use context vs. toolbar vs. list, as these are very similar in concept. I could easily see them being misappropriated. context is meant for right-click menus, hooked to an element by specifying the @contextmenu attribute on an element and pointing it to the menu. Note that the default CSS of a menu type=context is display:none. I don't really understand the difference between toolbar and list. 4. In the first example, what renders the button UI? Is it menu[@type=toolbar]/li, or li/menu? Or is it implied CSS? Implied CSS or UA magic. 4.1. Furthermore, should this example even depict a button UI, given that most graphical interfaces display top-level toolbars as text/icons against a [mostly] solid background Were a UA to render the example as demonstrated, would designers not have to style away the button appearance in order to achieve a look feel that matches user expectation? Obviously, this would not be the case in secondary (or n-ary) toolbars, for instance as in word processors, where everything below the initial row are usually buttons. Could there be a way, then, whether in markup or CSS, to denote whether a toolbar is displayed as a primary/top-level toolbar or not? This is something that'll be worked out as browsers actually implement things. 5. Provide more/graphical/clearer examples, to aid both browser vendors in deciding how to implement the elements, and authors in having an idea of what result they can expect from using them. The NPC form, for instance, does not say exactly what it is or does, nor does it represent a common UI convention. The only thing I can think of that comes close is Spotlight in OS X (if I'm interpreting it correctly), which I don't think I've ever seen in a [presumed] game before. Patches welcome. ^_^ Any suggested examples? 6. How is the command element rendered within a menu context when JavaScript is disabled? Is it meant only for non-essential actions? If it isn't, shouldn't it be able to be non-empty, so it can fallback to links or buttons? Or is the only possible fallback replicating every command with form controls that aren't direct children of the parent menu? If you're designing something to be a context menu, it likely won't work at all without Javascript. You'd need a significantly different UI. 6.1 On that note, why is the spec enabling the use of unstyled spans to achieve alternative rendering? Doesn't this give meaning (however contextual) to an element that is supposed to be semantically neutral? Slightly. I don't think it's a big deal, but shrug. Note that *any* element would work there to hide the submit button from the build a menu algorithm. 7. Is the menu element always to be rendered in-page or could it be displayed within the OS itself? Kroc Camen (suggests)[http://camendesign.com/blog/stop_this_madness] the latter but at present there is nothing in the spec about such an implementation. If this is left up to the UA how will
Re: [whatwg] input type=password... restrict reading value from JS?
On Sun, Jul 10, 2011 at 3:44 AM, Alex Vincent ajvinc...@gmail.com wrote: On Sun, Jul 10, 2011 at 3:21 AM, Michal Zalewski lcam...@coredump.cxwrote: For the last 10+ years, password inputs have been accessible from scripts, with nary a complaint. If I have this code: Unfortunately, the problem is not that easy to fix: denying access to the field does not prevent the attacker from changing the form submission URL after autocompletion to achieve the same... Or even simpler, changing the type attribute to something like hidden for an instant. I hate it when I don't think things through. To be fair, we already protect input type=file from vaguely similar type-changing attacks. (You can't make an input type=text, fill it with a filename as the value, then switch to type=file and submit it to steal files from the user.) However, as noted, doing this wouldn't help in any way. The script can redirect the form submission, or just swap out the input entirely for an input type=text that they manually intercept clicks on and insert * for each keypress (or more deviously, set the font-family for the text input to a font where every glyph is an asterisk, and then just read out the value normally). ~TJ
Re: [whatwg] input type=password... restrict reading value from JS?
On Mon, Jul 11, 2011 at 9:29 AM, Sean Connelly s...@pbwhere.com wrote: As a web developer, if I wanted access to the password, I would then avoid using the input type=password field, and create my own field that reads characters (perhaps via onkeyup), and fakes a password field visually. Then browsers wouldn't autofill it, which would defeat the nastiest attack here (stealing passwords without user intervention). But as noted, you can always submit the form, so it really doesn't help that much anyway.
[whatwg] Proposal for a MediaSource API that allows sending media data to a HTMLMediaElement
Hi, Based on comments in the File API Streaming Blobshttp://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-January/029973.html thread and my Extending HTML 5 video for adaptive streaminghttp://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-June/032277.html thread, I decided on taking a stab at writing a MediaSource API spechttp://html5-mediasource-api.googlecode.com/svn/trunk/draft-spec/mediasource-draft-spec.html for streaming data to a media tag. Please take a look at the spechttp://html5-mediasource-api.googlecode.com/svn/trunk/draft-spec/mediasource-draft-spec.htmland provide some feedback. I've tried to start with the simplest thing that would work and hope to expand from there if need be. For now, I'm intentionally not trying to solve the generic streaming file case because I believe there might be media specific requirements around handling seeking especially if we intend to support non-packetized media streams like WAV. If the feedback is generally positive on this approach, I'll start working on patches for WebKit Chrome so people can experiment with an actual implementation. Thanks, Aaron
Re: [whatwg] Timing API proposal for measuring intervals
On Fri, Jul 8, 2011 at 4:37 PM, Robert O'Callahan rob...@ocallahan.orgwrote: , On Fri, Jul 8, 2011 at 2:54 PM, James Robinson jam...@google.com wrote: On Thu, Jul 7, 2011 at 7:36 PM, Robert O'Callahan rob...@ocallahan.org wrote: Using this value as a clock for media synchronization sounds appealing but is complicated by audio clock drift. When you play N seconds of audio, it might take slightly more or less time to actually play, so it's hard to keep media times perfectly in sync with another timing source. Just something to keep in mind. True. On OS X, however, the CoreVideo and CoreAudio APIs are specified to use a unified time base (see http://developer.apple.com/library/ios/#documentation/QuartzCore/Reference/CVTimeRef/Reference/reference.html ) so if we do end up with APIs saying play this sound at time X, like Chris Roger's proposed Web Audio API provides, it'll be really handy if we have a unified timescale for everyone to refer to. Is that unified time base in sync with the system clock, and how accurate is it? I'm concerned about the possibility that it's not feasible to keep the audio hardware clock in sync with the system clock, at least on some platforms. In that case, we probably need to keep media playback and animations in sync with the audio hardware clock, and we could even expose that via some DOM API, but you might not want to use the same clock for other purposes, such general performance timing for example ... I've heard the audio clock drift is often significant. I'm not sure if this is a real problem or not, I just want to make sure. Rob Hi Robert, I think the clock that James is proposing is effectively the system clock (such as mach_absolute_time() or QueryPerformanceCounter()). I completely agree with your concerns about clock drift of this type of clock with the audio hardware clock, since they're almost always running off different crystals. That said, I still think it's useful to have a high-resolution system clock which is monotonically increasing. On Mac OS X the mach_absolute_time() system clock is used extensively in the media APIs, CoreVideo, CoreAudio, CoreMIDI, etc. to synchronize events according to a common time base: CoreAudio: http://developer.apple.com/library/mac/#documentation/MusicAudio/Reference/CoreAudioDataTypesRef/Reference/reference.html#//apple_ref/c/tdef/AudioTimeStamp CoreVideo: http://developer.apple.com/library/ios/#documentation/QuartzCore/Reference/CVTimeRef/Reference/reference.html CoreMIDI ( see MIDITimeStamp: A host clock time typedef UInt64 MIDITimeStamp; ) http://developer.apple.com/library/ios/#documentation/CoreMidi/Reference/MIDIServices_Reference/Reference/reference.html#//apple_ref/doc/uid/TP40010316 mach_absolute_time(): http://developer.apple.com/library/mac/#qa/qa1398/_index.html In the CoreAudio case, the AudioTimeStamp contains *both* the host-time (system clock) and the sample time (based on audio hardware). This creates a relationship between the two clocks. As an example of how these two clocks can be used together for synchronization, audio applications use the high-resolution timestamp of incoming MIDI messages to schedule audio synthesis to happen with very low jitter by doing sample-accurate scheduling when rendering the audio stream. Because of clock-drift, the system clock that James is proposing cannot *directly* be the same clock as what I'm proposing in the Web Audio API AudioContext .currentTime attribute. But there are ways to translate between the two in very useful ways. I would be in favor of introducing a monotonically increasing high-resolution system clock such as James is proposing, as long as we keep in mind some of these subtleties. Chris
Re: [whatwg] Proposal for a MediaSource API that allows sending media data to a HTMLMediaElement
It seems to me that the spec is written assuming only one media element is consuming the MediaSource. But nothing stops multiple elements consuming the same URL simultaneously. Maybe instead of going through a URL you should add API directly to media elements. bytesAvailable is for flow control? Instead of doing it this way, I would follow WebSockets and use a bufferedAmount attribute to indicate how much data is currently buffered up. That makes it easy for authors who don't want to care about flow control to just append stuff without encountering errors, while still allowing authors who care about flow control to do it. Rob -- If we claim to be without sin, we deceive ourselves and the truth is not in us. If we confess our sins, he is faithful and just and will forgive us our sins and purify us from all unrighteousness. If we claim we have not sinned, we make him out to be a liar and his word is not in us. [1 John 1:8-10]
Re: [whatwg] Timing API proposal for measuring intervals
On Tue, Jul 12, 2011 at 7:23 AM, Chris Rogers crog...@google.com wrote: In the CoreAudio case, the AudioTimeStamp contains *both* the host-time (system clock) and the sample time (based on audio hardware). This creates a relationship between the two clocks. As an example of how these two clocks can be used together for synchronization, audio applications use the high-resolution timestamp of incoming MIDI messages to schedule audio synthesis to happen with very low jitter by doing sample-accurate scheduling when rendering the audio stream. Because of clock-drift, the system clock that James is proposing cannot *directly* be the same clock as what I'm proposing in the Web Audio API AudioContext .currentTime attribute. But there are ways to translate between the two in very useful ways. Thanks Chris, I thought you'd know the answer :-). Suppose we wanted to sync animation (either scripted animation or CSS animation) to audio. We'd want them to use the audio clock, right? Rob -- If we claim to be without sin, we deceive ourselves and the truth is not in us. If we confess our sins, he is faithful and just and will forgive us our sins and purify us from all unrighteousness. If we claim we have not sinned, we make him out to be a liar and his word is not in us. [1 John 1:8-10]
Re: [whatwg] Timing API proposal for measuring intervals
On Mon, Jul 11, 2011 at 8:57 PM, Robert O'Callahan rob...@ocallahan.orgwrote: Suppose we wanted to sync animation (either scripted animation or CSS animation) to audio. We'd want them to use the audio clock, right? For that you need the play cursor of the actual audio sample you're synchronizing against, which is typically not strongly tied to the associated hardware audio clock. For example, audio underruns may change their alignment. -- Glenn Maynard
[whatwg] RTC API Proposal
Hi, Mozilla and Cisco have been working on an API for real time communication, which we sent out today to the W3C WebRTC working group (http://lists.w3.org/Archives/Public/public-webrtc/2011Jul/0010.html). It builds on both the WHATWG RTC proposal by Ian Hickson as well as the MediaStream Processing API by Robert O'Callahan. There are few differences though, and they are presented at: http://lists.w3.org/Archives/Public/public-webrtc/2011Jul/0012.html The proposal itself lives at: https://github.com/mozilla/rainbow/wiki/RTC_API_Proposal There is some discussion going on about the proposal on the W3C list but we would love to hear your feedback. Thanks, -Anant
Re: [whatwg] Timing API proposal for measuring intervals
On Tue, Jul 12, 2011 at 1:02 PM, Glenn Maynard gl...@zewt.org wrote: On Mon, Jul 11, 2011 at 8:57 PM, Robert O'Callahan rob...@ocallahan.orgwrote: Suppose we wanted to sync animation (either scripted animation or CSS animation) to audio. We'd want them to use the audio clock, right? For that you need the play cursor of the actual audio sample you're synchronizing against, which is typically not strongly tied to the associated hardware audio clock. For example, audio underruns may change their alignment. OK, but it's the audio clock with some adjustments, right? Definitely not the system clock. Rob -- If we claim to be without sin, we deceive ourselves and the truth is not in us. If we confess our sins, he is faithful and just and will forgive us our sins and purify us from all unrighteousness. If we claim we have not sinned, we make him out to be a liar and his word is not in us. [1 John 1:8-10]
Re: [whatwg] Timing API proposal for measuring intervals
On Mon, Jul 11, 2011 at 10:35 PM, Robert O'Callahan rob...@ocallahan.orgwrote: On Tue, Jul 12, 2011 at 1:02 PM, Glenn Maynard gl...@zewt.org wrote: On Mon, Jul 11, 2011 at 8:57 PM, Robert O'Callahan rob...@ocallahan.orgwrote: Suppose we wanted to sync animation (either scripted animation or CSS animation) to audio. We'd want them to use the audio clock, right? For that you need the play cursor of the actual audio sample you're synchronizing against, which is typically not strongly tied to the associated hardware audio clock. For example, audio underruns may change their alignment. OK, but it's the audio clock with some adjustments, right? Definitely not the system clock. Right. -- Glenn Maynard
Re: [whatwg] RTC API Proposal
On Mon, Jul 11, 2011 at 7:01 PM, Anant Narayanan an...@mozilla.com wrote:
Hi,
Mozilla and Cisco have been working on an API for real time communication,
which we sent out today to the W3C WebRTC working group
(http://lists.w3.org/Archives/Public/public-webrtc/2011Jul/0010.html). It
builds on both the WHATWG RTC proposal by Ian Hickson as well as the
MediaStream Processing API by Robert O'Callahan.
There are few differences though, and they are presented at:
http://lists.w3.org/Archives/Public/public-webrtc/2011Jul/0012.html
The proposal itself lives at:
https://github.com/mozilla/rainbow/wiki/RTC_API_Proposal
There is some discussion going on about the proposal on the W3C list but we
would love to hear your feedback.
Some minor nits:
constructor PeerListener(DOMString config, optional DOMString
negotiationServerURN)
interface PeerListener {
void listen();
attribute Function onIncoming;
};
Window implements PeerListener;
The WebIDL syntax here is a bit wrong, I suspect you're looking for
something like:
[Constructor(in DOMString config, in optional DOMString negotiationServerURN)]
interface PeerListener {
void listen();
attribute Function onIncoming;
};
Window implements PeerListener;
You probably don't mean the last implements line. That line
currently says that Windows *are* PerrListeners. I.e. that you can do
window.listen() and window.onIncoming = function() { ... }, which is
likely not what you want. Simply remove the line as declaring the
constructor should be enough.
To keep consistent with all other onfoo listeners, you should use all
lowercase name: onincoming.
It seems like you are saying that the function assigned to onincoming
receives a Connection object as its first argument. However generally
onfoo attributes are EventListeners and so always receives an Event
object as its first and only argument. If your intent is to be
consistent with other onfoo attributes you should instead create a
PeerListenerEvent object which inherits Event and makes the Connection
available as a property on it. You should also make PeerListener an
EventTarget.
In the example where you create a PeerListener, it appears that you're
only passing the second negotiationServerURN argument
(stun:foobar.net:3476). But the constructor above says that the
first argument is a config string, and that it's not optional. I'm
in particular curious what the syntax for the config string is, and if
it would be better done as a Dictionary. Would love to see some
examples.
In the example you also create a PeerConnection object using |new
PeerConnection(stun:foobar.net:3476, sendToB);|. However the
interface declaration for PeerListener does not include a constructor.
I'm trying to figure out how the sendToB and gotFromB functions work
in the Simple Video Call example, but it the lack of description for
the PeerListener constructor is preventing that. It also seems like
the gotFromB is unused which I assume is a bug in the example.
/ Jonas
