Re: ISSUE-85 (clipops security practice): What are common sucrity practices for Clipboard APIs? [Clipboard Operations]
On , Web Applications Working Group Issue Tracker sysbot+trac...@w3.org wrote: ISSUE-85 (clipops security practice): What are common sucrity practices for Clipboard APIs? [Clipboard Operations] http://www.w3.org/2008/webapps/track/issues/85 Raised by: Charles McCathieNevile On product: Clipboard Operations What are the common security restrictions and considerations that should be listed in the clipboard apis spec? I have thought thoroughly about this issue. There are the following bad use cases, that I can remember currently: - the user wants to copy/paste content from a webpage but the webpage is constantly setting the text on the clipboard as empty. Unfortunately, this already happens with pages using 3rd party plugins. - a webpage that silently sniffs the clipboard to try to find sensitive data, like something that could resemble an email or a credit card number. When I refer to system clipboard, I mean the clipboard that's shared between all applications and the user agent. To cope with these cases I thought of having 3 levels of security regarding clipboard access: - no access - webpage cannot set nor get data from clipboard. This fixes most malicious use cases. - write-only access - webpage can write to system clipboard but can't read from it. Incidentally, the UA should store a secondary clipboard to which data is written and read freely by the webpage, but only write operations pass on to the system clipboard. This is good enough for applications that preprocess data and store it in the clipboard, while still giving the user full privacy over his system clipboard. - full-access - webpage has full access to system clipboard. I don't think that the read-only case is feasible. If the user does not trust a page to write data, much less will he/she trust it to read. It would be up to user agents to actually provide an UI to allow users to control this. Cheers.
Re: [widgets] Making config.xml mandatory
On Mon, 09 Mar 2009 14:12:38 +0100, Hillebrand, Rainer rainer.hillebr...@t-mobile.net wrote: Which different security privileges does a widget have in comparison to any other content? Doesn't it depend on a security policy that we do not define in the W3C? While this is not yet defined by the W3C or other organizations, pre-existing implementations do indeed have different privileges: 1. Commonly, widget runtimes may ignore the same-origin policy that browsers have used 2. Some legacy implementations essentially have shell access, and bundle a set of Gnu (or gnu-like) tools 3. Filesystem access 4. Extended device API work is ongoing, such as OMTP's initiative -- Arve Bersvendsen Developer, Opera Software ASA, http://www.opera.com/
RE: [widgets] Making config.xml mandatory
Dear Arve, Good point regarding OMTP/BONDI. BONDI supports a security framework for widgets and web pages (or non-widgets). On the other, if widgets in pre-existing implementations may use sensitive resources then I as an attacker would pack my rogue content in a widget resource, add the config.xml file and run my attack. In other words, the config.xml file does not prevent any attack. I agree with you that the config.xml file already supports security relevant features, like access network=true/. However, as long as we do not have any means to check whether a widget user agent could trust a widget and that it does not misuse the network access, then a widget user agent must always allow this network access. If the config.xml file is the major means to identify a zip archive as widget resource then we will not need to define the file extension wgt and the MIME type application/widget. IMHO, I do not see the config.xml as a security solution. I would agree with you that it might be required to define settings that do not have default values. Do we have such settings? Best Regards, Rainer * T-Mobile International Terminal Technology Rainer Hillebrand Head of Terminal Security Landgrabenweg 151, D-53227 Bonn Germany +49 171 5211056 (My T-Mobile) +49 228 936 13916 (Tel.) +49 228 936 18406 (Fax) E-Mail: rainer.hillebr...@t-mobile.net http://www.t-mobile.net This e-mail and any attachment are confidential and may be privileged. If you are not the intended recipient, notify the sender immediately, destroy all copies from your system and do not disclose or use the information for any purpose. Diese E-Mail inklusive aller Anhänge ist vertraulich und könnte bevorrechtigtem Schutz unterliegen. Wenn Sie nicht der beabsichtigte Adressat sind, informieren Sie bitte den Absender unverzüglich, löschen Sie alle Kopien von Ihrem System und veröffentlichen Sie oder nutzen Sie die Information keinesfalls, gleich zu welchem Zweck. T-Mobile International AG Aufsichtsrat/ Supervisory Board: René Obermann (Vorsitzender/ Chairman) Vorstand/ Board of Management: Hamid Akhavan (Vorsitzender/ Chairman), Michael Günther, Lothar A. Harings, Katharina Hollender Handelsregister/Commercial Register Entry: Amtsgericht Bonn, HRB 12276 Steuer-Nr./Tax No.: 205 / 5777/ 0518 USt.-ID./VAT Reg.No.: DE189669124 Sitz der Gesellschaft/ Corporate Headquarters: Bonn
Re: comments on Packaging and Configuration specification
Hi Max, On Mon, Mar 9, 2009 at 11:25 AM, Max Froumentin max...@opera.com wrote: Hi, Here are a few comments on the 4 March version of the editor's draft: This document standardizes a general packaging format for applications. 1- just applications? Not web applications, or sofware applications, or something less vague? went with software This document standardizes a general packaging format for applications. The specification relies on PKWare's Zip as the packaging format 2- that somehow sounds contradictory. I would perhaps change the second packaging to archive or container. went with archive. 3- I know that user agents is the official term, but in this case I would use the more obvious execution environment or runtime, or client machines as used in the introduction. runtimes it is. 4-Mention that widget is a special case of web application, as soon as widgets is first used. And somehow convey that any mention of widget in the text applies to general web applications. I added Widgets are client-side applications that are authored using Web standards, but whose content can also be embedded into Web documents into the abstract. The configuration document is an XML vocabulary that authors can use to declare metadata 5- The configuration document is an XML vocabulary that declares metadata done. This document also defines conformance criteria [to verify] that Zip archives and configuration documents conform to this specification. 6- a bit tautaulogical :) removed conformance criteria and, hopefully less tautological. 1.3 7- Why is localized folder not called locale folder? Fixed globally. The second half, which starts in the section ... 8- starts with? fixed erroneous [DOM3Core] nodes 9- not sure what that means Changed [DOM3Core] nodes DOM nodes. Better? 1.4 10- I assume 1.4 is a joke, and will be removed? Nope. 1.6 (I like that section very much, I have to say. Much nicer than a boring glossary ;) Global definitions 11- just Definitions? Fixed An author is a person who creates a widget resource or an authoring tool that generates widget resources. 12- so if I use a tool to generate a widget, who's the author? Me or the author of the tool I used? The tool... or both... does it matter? A language tag is a string that matches the syntax, and expected usage, of Language-Tag as defined 13- text string. But maybe I'm nitpicking, but you say text string later in the spec. Added text 14- expected usage of _a_ Language-Tag or plural? or just language tags. added a. 15- I would drop the periods, but add one after language-Tag, but maybe I'm very nitpicking A language tag is a text string that matches the syntax and expected usage of language tags, as defined... Ok. Used your text. Because widgets are packaged, they can be liberally shared by users 16- liberally? Freely, rather? Or nothing. Dropped liberally 2 relevant to authors and authoring tool implementers 17- given your definition of author, both are the same Right. Dropped and authoring tool implementers Products that generate widget resources and/or allow authoring of configuration documents must not claim conformance to this specification 18- I love the logical conundrum! Given that RFC2119's must really means must ... in order to conform to this spec, your use of must not means you use conformance to this spec in order to define non-conformance to the spec! As if you'd written: Producs must not claim conformance to this specification, in order to claim conformance to this specification :) Hehe. gone. FWIW, Josh also pointed out that the above was kinda broken. 19- Authoring tools and markup generators must generate conforming configuration documents and/or widget resources. Somehow means to me authoring tools must generate conforming stuff to conform to this specification Also removed. 3.1 In addition to this specification, a user agent must support the following specifications and file formats: 20-remove In addition to this specification. It's redundant. Done. [ZIP], but with the exclusions listed in the Zip support section. 21- with the exclusions could be misinterpreted. I'd prefer The mandatory features of [ZIP], as defined below, even though it's not great either. Unless you change 3.3 to say: a user agent must support all of zip, except: ... which is optional. Fixed. 22 - Deflate is not part of Zip? Yes and no. The algorithm is defined elsewhere. 4. 23-It's confusing that inform is in bold. Because we're not in a definitions section, it's not obvious that the paragraph defines what inform means. Couldn't it go in the definitions section, or rephrased to something like informing means... I see what you mean, but, as stated in the Definition section, lots of definitions are given throughout the document. I would prefer to leave this one as is. 5. A file entry is the data held
Re: ISSUE-85 (clipops security practice): What are common sucrity practices for Clipboard APIs? [Clipboard Operations]
A few ideas: - one of the dangers is that flavours may be damageable... so the general practice would be that, unless we're in a de-sandboxed region (anything else than file://?) all flavours should be sanitized (e.g. no scripting, no relative reference, no embedding, except for pack- embedded data, no remote calls) - another danger is that the clipboard should not be read without the user knowing, I would recommend, as Safari does, to only allow the standard gestures within the user-agent to be triggering clipboard operations which in turn, offer access to the clipboard. To my knowledge, this is enough for a model that can be trusted to the users. I am not very comfortable with the suggestions of trust-level that João Eiras suggests (having played with them in MSIE always prompts the unknowledgeable user to boost things a bit more in case something doesn't work which I find a catastrophic attitude) although I fully agree that we are here talking of either the central user clipboard and or the content of a drag-and-drop feature (i.e. we are talking of acting with external applications as well). paul Le 09-mars-09 à 02:36, Web Applications Working Group Issue Tracker a écrit : ISSUE-85 (clipops security practice): What are common sucrity practices for Clipboard APIs? [Clipboard Operations] http://www.w3.org/2008/webapps/track/issues/85 Raised by: Charles McCathieNevile On product: Clipboard Operations What are the common security restrictions and considerations that should be listed in the clipboard apis spec? smime.p7s Description: S/MIME cryptographic signature
[widgets] Opportunities and ToDos ... [Was: Agenda for 5 March 2009 Voice Conference]
Bryan, Marcos, All, Among the areas we need contributions: * The red block issues in the specs as well as inputs to address open actions and Issues: http://www.w3.org/2008/webapps/track/products/8 * Widgets test suite - does BONDI have something we can use? I don't understand how they will objectively evaluate the goodness of their Release Candidate without some type of test suite so surely they must have something. * Issue #16 URI scheme spec - no one has yet agreed to take the lead on this spec: http://www.w3.org/2008/webapps/track/issues/16 * Window Modes specs - I expect Marcos or Arve to let us know what specific contributions they want * Widget security model - we've talked about the need for this model but no one has agreed to lead it. For starters, we will need to document the relevant use cases and requirements. It may also make sense to document/investigate related work ongoing as as well as prior standardization work. Regarding adding an Editor to any of the specs we have published at least once (PC, AE, DigSig), unless the Editor(s) indicate otherwise, I am not aware of any opportunities. -Regards, Art Barstow On Mar 6, 2009, at 8:34 AM, ext Marcos Caceres wrote: I was going to suggest that Bryan work on Widgets 1.0: Updates. It is currently the only spec not being actively worked on. However, Bryan, if you feel strongly about contributing to any other of the specs, then please do not hesitate to nominate a spec and section to work on. We could certainly use a hand with the new media query specs [1]. If you don't already have it, MikeSmith can set you up with CVS access. Kind regards, Marcos [1] http://dev.w3.org/2006/waf/widgets-wm/Overview.src.html On Thu, Mar 5, 2009 at 12:48 PM, Sullivan, Bryan bs3...@att.com wrote: My regrets for this call. One input however, in the last F2F there was a call for more editors to help speed up the widgets work (part of the AI to Dave Rogers). Please let me know which specs need editors, and I will make a proposal on where I can help. Best regards, Bryan Sullivan | ATT
Re: Progress Events normative text
On Thu, 5 Mar 2009, Charles McCathieNevile wrote:
I think it is wrong to make content non-conforming because it
fires events in a fashion that isn't consistent with this draft.
It seems odd to me to say that content is not allowed to work around
bugs in browsers, for instance.
Content is allowed to do whatever it wants.
Ok now I'm really confused. Here you say that content is allowed to do
whatever it wants, but then you say:
However, only some content is defined as conforming
...which as far as I can tell is a direct contradiction.
If something is non-conforming, that means that the spec is prohibiting
it, that it is not allowed. That's what it means to make something non-
conforming, as I understand it.
and in this case, content that does things not predicted by the spec is
defined as non-conforming. This avoids attempting to ascribe motive to
the content.
I don't understand what this means.
I still think it is wrong for us to make content non-conforming for firing
events that use the ProgressEvents interface in a manner different than
what the spec describes.
# 2.3 Interface definitions
This is the one section that really needs normative text, since it
is the one section that is really defining new features. However,
as far as I can tell, it really doesn't define anything
normatively. For example, the attributes have no UA requirements.
Is lengthComputable supposed to throw, return true, return false,
have any side-effects? Same for the others.
This problem still exists.
Perhaps I am missing something here. They are attributes. They have
values, which are described. In what circumstances would they throw, or
have side effects, or return anything except their value?
If I run the following script:
var e = document.createEvent('ProgressEvent');
e.initProgressEvent('load', true, true, true, 1, 2);
alert(e.loaded);
...what number is alerted? What must conformance criteria requires this?
As far as I can tell, nothing in the spec today requires that the
attributes have any particular value.
Similarly if I init the event with lengthComputableArg set to false and
totalArg set to 100, what does the must in the definition of total
mean? Does it mean it returns zero? The conformance criteria are very
confusingly written in this section.
I continue to think that RFC2119 terms are overused, used unnecessarily
and redundantly in a manner that will cause future pain, and used in
manners that do not directly map to clear testable features, which I think
is problematic. However, I don't really know how to convince you that this
is a real problem.
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: comments on Packaging and Configuration specification
Hi Max, Thanks for the prompt reply. I think I have addressed all of your concerns. For the sake of the LC process, can you give us a final thumbs up that you are happy with the changes. On Tue, Mar 10, 2009 at 4:22 PM, Max Froumentin max...@opera.com wrote: I'm ok with the resolution of all the comments I have not re-commented on below. Marcos Caceres marc...@opera.com writes: erroneous [DOM3Core] nodes 9- not sure what that means Changed [DOM3Core] nodes DOM nodes. Better? Yes, although I would remove the whole sentence, actually. A must in a sentence that starts with typically is dangerous. And since it gives a preview of statements that come later in the document, it's in principle not necessary. Ok, right. I've freed ignore from any evilness related to typically. It now sits happily on its own: During the processing of a configuration document, the specification will state that a user agent ignore DOM nodes. This means that the user agent must act as if those nodes were not present An author is a person who creates a widget resource or an authoring tool that generates widget resources. 12- so if I use a tool to generate a widget, who's the author? Me or the author of the tool I used? The tool... or both... does it matter? It matters for the content of the author element, and for various normative statements that are about the behavior of the author in the specification. 23-It's confusing that inform is in bold. Because we're not in a definitions section, it's not obvious that the paragraph defines what inform means. Couldn't it go in the definitions section, or rephrased to something like informing means... I see what you mean, but, as stated in the Definition section, lots of definitions are given throughout the document. I would prefer to leave this one as is. ok. must not rely upon script - rely is a vague term, especially after a must not, although I can't find a better wording. Changed it to Authors using [SVG] as an icon format should create icons that use declarative animation, and must not make icons exclusively dependent on scripts for animation and interactivity. Not sure if it any better? Yes, better for me. I can't find a better way to say it. ok. Author guidelines are just warning to authors ha! Not if you write statements as above, containing musts. Ok. I changed all of them to not use conformance terms. your suggestion implies that the author must treat it as an invalid archive (which is kinda correct, but not really). The UA treating the widget as invalid happens later in the doc. - start file encoding is ISO8859-1? Think you can get away with it? The i18n WG said we should use it. Problem? No, they're the experts! Agreed :) -- Marcos Caceres http://datadriven.com.au
