Re: [whatwg] Fetch SVG images with No CORS tainted cross-origin
On Wed, Nov 27, 2013 at 1:13 AM, Boris Zbarsky bzbar...@mit.edu wrote: Note that Gecko has serious security concerns with allowing subresource loads like this in SVG loaded via img; we currently disallow them altogether due to those concerns. Such SVG documents can link to things internal to themselves and to data: URIs, but not to anything requiring network access. SVG loaded via object is a different story, of course. It seems weird to say Gecko has serious security concerns. Either there's a factual security issue or not, right? And as far as I can tell the issue is that if someone allows uploading SVG images, people could include tracker images in those SVG images. And therefore the SVG specification should simply outlaw that. Note that even then those SVG images cannot be hosted same-origin unless you run them through some kind of whitelist-based filter. -- http://annevankesteren.nl/
Re: [whatwg] Fetch SVG images with No CORS tainted cross-origin
On 11/27/13 9:08 AM, Anne van Kesteren wrote: It seems weird to say Gecko has serious security concerns. Either there's a factual security issue or not, right? In theory, yes. In practice, opinions seem to differ, not least because one person's security/privacy issue is another's business model. In this particular case, last I checked, other UAs are more permissive than Gecko, and seem to not care about the issue we care about in this situation. And as far as I can tell the issue is that if someone allows uploading SVG images, people could include tracker images in those SVG images. That's correct. And therefore the SVG specification should simply outlaw that. I'm all for that, obviously. ;) Note that even then those SVG images cannot be hosted same-origin unless you run them through some kind of whitelist-based filter. Indeed. -Boris
Re: [whatwg] Simplified picture element draft
On Wed, 27 Nov 2013 00:48:56 -, Simon Pieters sim...@opera.com wrote: You introduce a proxy that needs to be tested to see that it works in different scenarios (e.g. removing an attribute, that events are forwarded properly, that it does not affect parts it shouldn't like document.images, that the context menu works, etc.). You introduce a (or two) new fallback mechanism. You haven't specified that picture should be able to be drawn on a canvas in 2d (and WebGL?). Thanks, very good examples. Now I understand (although I wish specifying it exactly like img would make that easy enough). -- regards, Kornel
Re: [whatwg] Proposal: Locale Preferences API
The proposal looks good except for one reservation I have about. A few years ago, we proposed a similar API to webkit-dev, but it's 'killed' there and we didn't bring it up in whatwg (Chromium ended up adding an extension API for that for Chrome extensions). My reservation is : it's not a good idea to conflate the browser's UI language and the ordered list of preferred content languages (Accept-Language). Specifically, I think it's better to leave alone 'navigator.language' when the preferred list of languages is changed. *2.1 If the first item of the lang list is not the same value as the value of* *the 'navigator' object's `language` attribute, update the `navigator` object's `* *attribute` to be the first item lang list.* That is, I suggest that 'navigator.language' always be the UI language of a web browser. When the 'preferred lang list' changes, it should NOT affect 'navigator.language' (singular) but ONLY updates 'navigator.languages' (plural). If 'language vs languages' is likely to cause confusion/errors, we might as well choose to use 'preferredLanguages' or 'preferredContentLanguages' for the latter. Jungshik 2013/10/16 Erik Arvidsson a...@chromium.org This looks very useful and the proposal looks solid. On Mon, Oct 14, 2013 at 6:43 PM, Ian Hickson i...@hixie.ch wrote: On Mon, 14 Oct 2013, Marcos Caceres wrote: Ping? Mozilla would like to know if anyone else is interested or specially if people are NOT interested. We would like to implement this and expose it on the platform. See: https://bugzilla.mozilla.org/show_bug.cgi?id=780953 I was just looking at this, actually. I filed the following bug to track it: https://www.w3.org/Bugs/Public/show_bug.cgi?id=23517 Seems like a reasonable feature to me, FWIW. See also: Notification of change to navigator.language (locale change) https://www.w3.org/bugzilla_public/show_bug.cgi?id=21289 API to expose locale-specific settings https://www.w3.org/Bugs/Public/show_bug.cgi?id=22679 API to expose actual language of a node, to aid scripts doing localisation and CJK editors during copypaste and dragdrop https://www.w3.org/Bugs/Public/show_bug.cgi?id=23512 -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' -- erik
Re: [whatwg] Proposal: Locale Preferences API
On 11/27/13 4:28 PM, Jungshik Shin (신정식, 申政湜) wrote: That is, I suggest that 'navigator.language' always be the UI language of a web browser. That's an unacceptable privacy leak from Mozilla's point of view. See https://bugzilla.mozilla.org/show_bug.cgi?id=55366 where we explicitly switched from that to basing navigator.language on the Accept header. -Boris
Re: [whatwg] Proposal: Locale Preferences API
2013-11-28 0:20, Boris Zbarsky wrote: On 11/27/13 4:28 PM, Jungshik Shin (신정식, 申政湜) wrote: That is, I suggest that 'navigator.language' always be the UI language of a web browser. That's an unacceptable privacy leak from Mozilla's point of view. See https://bugzilla.mozilla.org/show_bug.cgi?id=55366 where we explicitly switched from that to basing navigator.language on the Accept header. More importantly, I would say, the browser’s UI language should normally be completely irrelevant to page design and implementation. I might be using an English-language browser because there is no better option (localizations are lousy). This does not mean that when viewing a page in, say, German, I would want the page to talk to me in English, to use English-language month names in date controls and info, etc. Yucca
Re: [whatwg] Type strings to specify number of AAC audio channels
On Mon, 23 Sep 2013, Bolin Hsu wrote:
Since the royalty for decoding surround sound AAC is higher than stereo
AAC, some platforms can decode stereo AAC but not surround sound AAC.
But the type string passed to HTMLMediaElement.canPlayType(type) doesn't
specify number of channels. I discussed this with some colleagues before
I found this list. Has this been covered by standard? Below are some
ideas came up during discussion:
- Use a new codec string, such as
HTMLMediaElement.canPlayType('audio/mp4; codecs=aac51')
- Add a new parameter, such as
HTMLMediaElement.canPlayType('audio/mp4; codecs=mp4a.40.2, channels=6)
These seem like appropriate approaches. They would merely need updates to
the relevant RFCs.
- Add new element for platform configuration. Some platforms can only
output stereo audio, so the surround sound is down mixed to stereo. This
can potentially query the platform if it can really output 6 simultaneous
audio streams, amount other things:
HTMLNewElement.getCapability('audio')
I don't think this would be appropriate for an element. As an API, it's a
client capability query, which, if we support it, would probably belong to
an API for doing such things. Not sure what the right spec would be for
that. Anyone?
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
