Re: comments on Packaging and Configuration specification

[Marcos Caceres]

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  wrote:
> I'm ok with the resolution of all the comments I have not re-commented on 
> below.
>
> Marcos Caceres  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  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 "must"s.

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

Re: Progress Events normative text

[Ian Hickson]

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.   `._.-(,_..'--(,_..'`-.;.'

[widgets] Agenda for 12 March 2009 Voice Conference; *** NOTE TIME CHANGE FOR non-US ***

[Arthur Barstow]

Below is the draft agenda for the March 12 Widgets Voice Conference  
(VC).


Inputs and discussion before the meeting on all of the agenda topics
via public-webapps is encouraged (as it can result in a shortened
meeting).

Logistics: *** NOTE TIME CHANGE FOR non-US PARTICIPANTS ***

   Time: 22:00 Tokyo; 15:00 Helsinki; 14:00 Paris; 13:00 London;  
09:00 Boston; 06:00 Seattle

   Duration = 60 minutes
   Zakim Bridge +1.617.761.6200, conference 9231 ("WAF1")
   IRC channel = #wam; irc.w3.org:6665
   Confidentiality of minutes = Public

Agenda:

1. Review and tweak agenda

2. Announcements

a. Next f2f meeting is June 9-11 in London; host is Vodafone

3. DigSig spec -
 

a. Comments on "Identifier and Created Signature property" proposal:
 


b. File naming proposal; any comments on last proposal:

 


4. Widgets Updates spec [led by Mike Smith]: status of the patent  
disclosure for the Updates spec; Q&A; next steps:


 


5. A&E spec: Arve's proposed change to the A&E spec regarding  
preferences:


 


6. P&C spec:

a. MaxF's comment set #1 (first one):

 


b. Mandatory config file:

 


7. Opportunities and ToDos; seeking volunteers:

 


8. AOB

[widgets] Opportunities and ToDos ... [Was: Agenda for 5 March 2009 Voice Conference]

[Arthur Barstow]

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:


 

* 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:


 

* 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 (P&C, A&E, 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   
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 | AT&T

widget signature proposal - Identifier and Created Signature property

[Nokia-CIC/Boston]

I propose we add the following to the Widgets Signature 1.1. This is
in response to Thomas Roessler review comments, see http://lists.w3.org/Archives/Public/public-webapps/2009JanMar/0547.html


Proposal - Add the following to the latest editor's draft 
http://dev.w3.org/2006/waf/widgets-digsig/

(1) In Section 5.1, Use of XML Signature in Widgets

Add to bullet list:

+ Each Signature MUST contain  a dsp:Identifier signature properties  
element compliant with XML Signature Properties [XMLSec-Properties]  
and this specification.


+ Each Signature MUST contain  a dsp:Created signature properties  
element compliant with XML Signature Properties [XMLSec-Properties]  
and this specification.


(2) Add new section 5.5 and 5.6:

5.5 Identifier Signature Property

The dsp:Identifier signature property is intended to be used to  
uniquely identify the signature to enable signature management. It  
MUST be unique for a given signer.


5.6 Created Signature Property

The dsp:Created signature property provides the time of signature   
creation and is intended to be used to provide additional information  
associated with signatures. It is a wall clock timestamp as noted in  
XML Signature Properties.


To give just one example of use, assume a distributor's signing  
process is found to be broken, but it's not practical to exchange the  
signature key. Being able to weed out all signatures made before a  
particular date might turn out really important in this context.


(2) Update 7.2 Signature Generation to add the following at the end:

The current wall time MUST be placed in the dsp:Created signature   
property upon signature generation. The granularity of this time need   
not be finer than to the minute. The time SHOULD reflect the time that  
signature generation completes.


A unique identifier string for the signature MUST be placed in the   
dsp:Identifier signature property by the signer. This MUST be a  
unique  signing string for all signatures created by the signer.


(3) Update 7.3 Signature Validation to add after the second sentence a  
new paragraph:


The Created Signature Property value MUST represent a timestamp  
earlier than the current time, to the nearest minute, according to  
wall clock time.  There MUST NOT be more than one such value in the  
signature.


---
In addition to these changes in Widget Signature, the latest Editors
Draft of XML Signature Properties reflects the addition on the new  
Identifier [1] and Created [2] Signature properties.


Please review and indicate any suggestions for  those as well.

Thanks

regards, Frederick

Frederick Hirsch
Nokia

[1] 
http://www.w3.org/2008/xmlsec/Drafts/xmldsig-properties/Overview.html#identifier-property

[2] 
http://www.w3.org/2008/xmlsec/Drafts/xmldsig-properties/Overview.html#created-property

Re: comments on Packaging and Configuration specification

[Max Froumentin]

I'm ok with the resolution of all the comments I have not re-commented on below.

Marcos Caceres  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.

>> "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  element, and for various normative 
statements that are about the behaviour 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.

> Author guidelines are just warning to authors

ha! Not if you write statements as above, containing "must"s.

>  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!

Max.

Re: [widgets] Making config.xml mandatory

[Marcos Caceres]

On 3/10/09 3:48 PM, Mark Baker wrote:

I think the TAG's finding on authoritative metadata is germane here;

http://www.w3.org/2001/tag/doc/mime-respect


That only applies to widgets that acquired over HTTP. Widgets can come 
from any source, include those that know nothing of media types. 
Nonetheless, media types are respected when a widget is acquired over 
HTTP (see Step 1 in P&C spec [1] to see if we have spec'd it correctly).


Kind regards,
Marcos

[1] 
http://dev.w3.org/2006/waf/widgets/#step-1--acquire-a-potential-zip-archive

Re: [widgets] Making config.xml mandatory

[Mark Baker]

I think the TAG's finding on authoritative metadata is germane here;

http://www.w3.org/2001/tag/doc/mime-respect

Mark.

On Mon, Mar 9, 2009 at 8:36 AM, Marcos Caceres  wrote:
> Opera would like to make the config file in widgets packages
> mandatory. Our rationale is that having at least one  config.xml file
> at the root of the widget give a sure way to identify a zip archive as
> a widget; otherwise arbitrary zip packages with an index.html could be
> fed to a widget engine and would run with the security privileges of a
> widget.
>
> Kind regards,
> Marcos
>
> --
> Marcos Caceres
> http://datadriven.com.au
>
>

Re: ISSUE-85 (clipops security practice): What are common sucrity practices for Clipboard APIs? [Clipboard Operations]

[Paul Libbrecht]

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

Re: comments on Packaging and Configuration specification

[Marcos Caceres]

Hi Max,
On Mon, Mar 9, 2009 at 11:25 AM, Max Froumentin  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 y

RE: [widgets] Making config.xml mandatory

[Hillebrand, Rainer]

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 . 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: [widgets] Making config.xml mandatory

[Arve Bersvendsen]

On Mon, 09 Mar 2009 14:12:38 +0100, Hillebrand, Rainer 
 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: ISSUE-85 (clipops security practice): What are common sucrity practices for Clipboard APIs? [Clipboard Operations]

[João Eiras]

On , Web Applications Working Group Issue Tracker  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.