[whatwg] Fixing undo on the Web - UndoManager and Transaction

[Ryosuke Niwa]

Hi all,

In the last couple of weeks, I've been working with developers of CKEditor,
TinyMCE, and Google Docs to come up with *new API for undo and redo*.

Why? Because* undo and redo are broken on the Web today*. Whenever Web apps
try to add a custom editing operation without using execCommand or do a "fix
up" after browser executes a user editing action, user agents get confused
by DOM mutations made by the apps and won't be able to undo or redo user
editing actions and execCommand. This forces Web apps to re-implement undo
and redo themselves, and in fact, *many rich text editors store innerHTML of
a contenteditable element* as a string in their internal undo transaction
history (a.k.a undo stack).

Also, there's no way for Web apps to add new undo item and populate undo and
redo menus on user agent's native UI.  In addition, if an editor app has a
widget with input/textarea, then the undo stack of the editor gets confused
when the widget goes away because the undo transaction history exists only
per document.

In order to solve above and numerous other problems, we've come to a
conclusion that we need to *add UndoManager and Transaction*.

*UndoManager* is an interface for managing undo transaction history.  It
exists on a document and an element with the *undoscope* content attribute.
 UndoManager applies new transaction (i.e. make undoable DOM changes) and
manage them.  The main purpose of UndoManager is to communicate the list of
undoable items with the user agent so that the user agent can provide a
native UI (e.g. populating menu items with them).

A *transaction* is a collection of DOM mutations that can be applied,
unapplied, or reapplied. UndoManager manages transactions and execute
unapply and reapply upon undo and redo respectively.

There are two types of DOM transactions:

   - *Managed transaction* - the app supplies apply() and the user agent
   automatically takes care of undo and redo. It is *compatible with user
   editing actions and editing commands*, and allows Web apps to easily add
   new editing operations or fix up DOM after user editing actions or editing
   commands and still have the user agent manage the undo and redo.
   - *Manual transaction* - the app supplies apply(), unapply(), and
   reapply() and *the app takes the full control of undo and redo*. However,
   it is NOT compatible with user editing actions, editing commands, or managed
   transactions, meaning that, the user agents won't be able to undo or redo
   them. This transaction is useful for apps such as a collaborative editor
   that implements domain-specific undo or redo.

You can see more concrete definitions of UndoManager and Transaction at:
https://rniwa.com/editing/undomanager.html and see a list of uses cases at
https://rniwa.com/editing/undomanager-usecases.html.  The documents are
incomplete and I need your feedback in order to refine details.

Best regards,
Ryosuke Niwa
Software Engineer
Google Inc.

Re: [whatwg] DOMCrypt update: July 14 Meeting Report

[David Dahl]

- Original Message 
> From: "Simon Heckmann" 
> To: "Silvia Pfeiffer" 
> Cc: "David Dahl" , "WHATWG Proposals" 
> 
> Sent: Tuesday, July 26, 2011 5:55:30 PM
> Subject: Re: [whatwg] DOMCrypt update: July 14 Meeting Report

> Additionally, are there plans or a roapmap to bring the DOMCrypt
> specification to a W3C technical report?
> 

Yes. Getting this API on a standards track is one of the project goals.

Cheers,

David

Re: [whatwg] DOMCrypt update: July 14 Meeting Report

[Adam Barth]

Hi Simon,

That would look something like the following:

== Phase 1: Key Generation (Client-Side) ==

crypto.pk.generateKeypair("rsa-1024-aes-128", function(keyID, pubKey) {
  ... send pubKey to the server ...
  ... store keyID somewhere??? ...
});

== Phase 2: Encryption (Server-Side) ==

The server encrypts file F under public key pubKey.
The server sends the encrypted file EF to the client and stores it
locally using the File API.

== Phase 3: Decryption (Client-Side) ==

... retrieve keyID from somewhere??? ...

crypto.pk.decrypt(EF, keyID, function(plainText) {
  ... rejoice ...
});

To fill in the ??? we need to store the keyID somewhere.  (To be
clear, the keyID is just a capability to use the private key, which
never leaves the user agent's secure key store.)  To complete your
example, we'd need to provide a facility to protect the keyID with the
user's password.

Adam


On Tue, Jul 26, 2011 at 3:55 PM, Simon Heckmann  wrote:
> Okay, I am a little confused now: What about the following use case:
>
> On the server: Encrypt a file using AES-256 with a MD5 hash of the user's 
> password.
>
> On the client: Download the file and save it on the hard drive using the File 
> API. Some time later when offline the user can then enter their password. 
> DOMCrypt calculates the MD5 hash of the password and decrypts the locally 
> stored file so it can be viewed by the user.
>
> As far as I understand your specification this scenario should be supported, 
> right? How would this look like in source code? Could you give an example of 
> the JavaScript DOMCrypt calls required for this?
>
> Additionally, are there plans or a roapmap to bring the DOMCrypt 
> specification to a W3C technical report?
>
> Thank you very much!
>
> Kind regards,
> Simon Heckmann
>
>
> Am 27.07.2011 um 00:41 schrieb Silvia Pfeiffer :
>
>> OK, so it would apply to a private video conference, but not to
>> protect a server-client-delivery. That's good to know, thanks.
>> Silvia.
>> On Wed, Jul 27, 2011 at 8:26 AM, David Dahl  wrote:
>>> Silvia:
>>>
>>> The design - at this time - allows the client to encrypt data locally, with 
>>> the publicKey of the recipient - not allowing anyone else to read the data. 
>>> The callback that the web page provides which captures the decrypted data 
>>> has full access to the decoded data.
>>>
>>> I imagine the DRM scenario would be possible if the API was implemented 
>>> server side, but I think it would be a rather weak system.
>>>
>>> Generally, this API is designed for private messaging between 2 users, with 
>>> an untrusted server (as well as all of the hashing, HMAC, sign and verify 
>>> methods).
>>>
>>> The use-cases are listed here: 
>>> https://wiki.mozilla.org/Privacy/Features/DOMCryptAPI/UseCases
>>>
>>> Cheers,
>>>
>>> David
>>>
>>> - Original Message -
>>> From: "Silvia Pfeiffer" 
>>> To: "David Dahl" 
>>> Cc: "WHATWG Proposals" 
>>> Sent: Tuesday, July 26, 2011 4:58:30 PM
>>> Subject: Re: [whatwg] DOMCrypt update: July 14 Meeting Report
>>>
>>> If I understand this correctly, then this is introducing a mechanism
>>> for Web publishers to provide a secure service to users where the data
>>> exchanged between the server and the UA is encrypted and not decodable
>>> by anyone else listening in on that communication or getting access to
>>> the data stored in the browser for that communication.
>>>
>>> If so, could this be a means to provide a one-session-only decoding
>>> key to a UA to decode a specially encoded piece of content (e.g. a
>>> video) from a publisher? I am quite directly thinking that this could
>>> be a first step towards providing DRM methodology in the browser, but
>>> also for example for about having secure private video conversations
>>> without needing to install browser plugins.
>>>
>>> Apologies for taking this thread a bit off topic - I am just curious.
>>>
>>> Cheers,
>>> Silvia.
>>>
>>>
>>> On Wed, Jul 27, 2011 at 5:59 AM, David Dahl  wrote:
 Hello All:

 Just a quick report on a DOMCrypt meeting that took place Thursday, 
 2011-07-14 at Mozilla in Mountain View.

 Summary:

    DOMCrypt is a high-level API that should be usable by web developers 
 after a short period of study
    DOMCrypt will be designed and implemented so that it is difficult to 
 "do the wrong thing"
    HASH and HMAC methods may be implemented first
    The Public Key API is the most useful, so it should be implemented 
 before the symmetric encryption API
        Keypairs must be generated on a per-origin basis
        The Keypair for a specific origin cannot be used in another origin
    No private or wrapped key material will be accessible to content scripts
    Each implementation will provide a mechanism to clear keys
    A "Key ID" will be used to tell the decrypt method which (content 
 inaccessible) private key to use to decrypt data
    The returned encrypted object format will be a raw Arr

[whatwg] Access to live/raw audio and video stream data from both local and remote sources

[Rob Manson]

Hi,

sorry for posting across multiple groups, but I hope you'll see from my
comments below that this is really needed. 

This is definitely not intended as criticism of any of the work going
on.  It's intended as constructive feedback that hopefully provides
clarification on a key use case and it's supporting requirements.

"Access to live/raw audio and video stream data from both local
and remote sources in a consistent way"

I've spent quite a bit of time trying to follow a clear thread of
requirements/solutions that provide API access to raw stream data (e.g.
audio, video, etc.).  But I'm a bit concerned this is falling in the gap
between the DAP and RTC WGs.  If this is not the case then please point
me to the relevant docs and I'll happily get back in my box 8)

Here's how the thread seems to flow at the moment based on public
documents.

On the DAP page [1] the mission states:
"the Device APIs and Policy Working Group is to create
client-side APIs that enable the development of Web Applications
and Web Widgets that interact with devices services such as
Calendar, Contacts, Camera, etc"

So it seems clear that this is the place to start.  Further down that
page the "HTML Media Capture" and "Media Capture" APIs are listed.

HTML Media Capture (camera/microphone interactions through HTML forms)
initially seems like a good candidate, however the intro in the latest
PWD [2] clearly states:
"Providing streaming access to these capabilities is outside of
the scope of this specification."

Followed by a NOTE that states:
"The Working Group is investigating the opportunity to specify
streaming access via the proposed  element."

The link on the "proposed  element" [3] links to a "no longer
maintained" document that then redirects to the top level of the whatwg
"current work" page [4].  On that page the most relevant link is the
video conferencing and peer-to-peer communication section [5].  More
about that further below.

So back to the DAP page to follow explore the other Media Capture API
(programmatic access to camera/microphone) [1] and it's latest PWD [6].
The abstract states:
"This specification defines an Application Programming Interface
(API) that provides access to the audio, image and video capture
capabilities of the device."

And the introduction states:
"The Capture API defines a high-level interface for accessing
the microphone and camera of a hosting device. It completes the
HTML Form Based Media Capturing specification [HTMLMEDIACAPTURE]
with a programmatic access to start a parametrized capture
process."

So it seems clear that this is not related to streams in any way either.

The Notes column for this API on the DAP page [1] also states:
"Programmatic API that completes the form based approach
Need to check if still interest in this
How does it relate with the Web RTC Working Group?"

Is there an updated position on this?

So if you then head over to the WebRTC WG's charter [7] it states:
"...to define client-side APIs to enable Real-Time
Communications in Web browsers.

These APIs should enable building applications that can be run
inside a browser, requiring no extra downloads or plugins, that
allow communication between parties using audio, video and
supplementary real-time communication, without having to use
intervening servers..."

So this is clearly focused upon peer-to-peer communication "between"
systems and the stream related access is naturally just treated as an
ancillary requirement.  The scope section then states:
"Enabling real-time communications between Web browsers require
the following client-side technologies to be available:

- API functions to explore device capabilities, e.g. camera,
microphone, speakers (currently in scope for the Device APIs &
Policy Working Group)
- API functions to capture media from local devices (camera and
microphone) (currently in scope for the Device APIs & Policy
Working Group)
- API functions for encoding and other processing of those media
streams,
- API functions for establishing direct peer-to-peer
connections, including firewall/NAT traversal
- API functions for decoding and processing (including echo
cancelling, stream synchronization and a number of other
functions) of those streams at the incoming end,
- Delivery to the user of those media streams via local screens
and audio output devices (partially covered with HTML5)"

So this is where I really start to feel the gap growing.  The DAP is
pointing to RTC saying not sure how if our Camera/Microphone APIs are
being superseded by the work in the RTC...and the RTC then points back
to 

Re: [whatwg] DOMCrypt update: July 14 Meeting Report

[Simon Heckmann]

Okay, I am a little confused now: What about the following use case:

On the server: Encrypt a file using AES-256 with a MD5 hash of the user's 
password.

On the client: Download the file and save it on the hard drive using the File 
API. Some time later when offline the user can then enter their password. 
DOMCrypt calculates the MD5 hash of the password and decrypts the locally 
stored file so it can be viewed by the user.

As far as I understand your specification this scenario should be supported, 
right? How would this look like in source code? Could you give an example of 
the JavaScript DOMCrypt calls required for this?

Additionally, are there plans or a roapmap to bring the DOMCrypt specification 
to a W3C technical report?

Thank you very much!

Kind regards,
Simon Heckmann


Am 27.07.2011 um 00:41 schrieb Silvia Pfeiffer :

> OK, so it would apply to a private video conference, but not to
> protect a server-client-delivery. That's good to know, thanks.
> Silvia.
> On Wed, Jul 27, 2011 at 8:26 AM, David Dahl  wrote:
>> Silvia:
>> 
>> The design - at this time - allows the client to encrypt data locally, with 
>> the publicKey of the recipient - not allowing anyone else to read the data. 
>> The callback that the web page provides which captures the decrypted data 
>> has full access to the decoded data.
>> 
>> I imagine the DRM scenario would be possible if the API was implemented 
>> server side, but I think it would be a rather weak system.
>> 
>> Generally, this API is designed for private messaging between 2 users, with 
>> an untrusted server (as well as all of the hashing, HMAC, sign and verify 
>> methods).
>> 
>> The use-cases are listed here: 
>> https://wiki.mozilla.org/Privacy/Features/DOMCryptAPI/UseCases
>> 
>> Cheers,
>> 
>> David
>> 
>> - Original Message -
>> From: "Silvia Pfeiffer" 
>> To: "David Dahl" 
>> Cc: "WHATWG Proposals" 
>> Sent: Tuesday, July 26, 2011 4:58:30 PM
>> Subject: Re: [whatwg] DOMCrypt update: July 14 Meeting Report
>> 
>> If I understand this correctly, then this is introducing a mechanism
>> for Web publishers to provide a secure service to users where the data
>> exchanged between the server and the UA is encrypted and not decodable
>> by anyone else listening in on that communication or getting access to
>> the data stored in the browser for that communication.
>> 
>> If so, could this be a means to provide a one-session-only decoding
>> key to a UA to decode a specially encoded piece of content (e.g. a
>> video) from a publisher? I am quite directly thinking that this could
>> be a first step towards providing DRM methodology in the browser, but
>> also for example for about having secure private video conversations
>> without needing to install browser plugins.
>> 
>> Apologies for taking this thread a bit off topic - I am just curious.
>> 
>> Cheers,
>> Silvia.
>> 
>> 
>> On Wed, Jul 27, 2011 at 5:59 AM, David Dahl  wrote:
>>> Hello All:
>>> 
>>> Just a quick report on a DOMCrypt meeting that took place Thursday, 
>>> 2011-07-14 at Mozilla in Mountain View.
>>> 
>>> Summary:
>>> 
>>>DOMCrypt is a high-level API that should be usable by web developers 
>>> after a short period of study
>>>DOMCrypt will be designed and implemented so that it is difficult to "do 
>>> the wrong thing"
>>>HASH and HMAC methods may be implemented first
>>>The Public Key API is the most useful, so it should be implemented 
>>> before the symmetric encryption API
>>>Keypairs must be generated on a per-origin basis
>>>The Keypair for a specific origin cannot be used in another origin
>>>No private or wrapped key material will be accessible to content scripts
>>>Each implementation will provide a mechanism to clear keys
>>>A "Key ID" will be used to tell the decrypt method which (content 
>>> inaccessible) private key to use to decrypt data
>>>The returned encrypted object format will be a raw ArrayBuffer
>>>The public key format will be a raw ArrayBuffer
>>>**We agreed to "have all the inputs and outputs be raw, unformatted 
>>> ArrayBuffers, letting higher-level pure JS wrappers deal with conversion to 
>>> application data formats until we understand better what higher-level 
>>> formats would be useful"
>>>HASH and HMAC methods should be synchronous to make them simpler
>>>HASH and HMAC methods should be constructors
>>>We may implement the HASH and HMAC APIs first then the PublicKey API
>>> 
>>> A wiki page with more detail is here: 
>>> https://wiki.mozilla.org/Privacy/Features/DOMCryptAPISpec/Meeting-2011-07-14
>>> 
>>> The DOMCrypt Spec is here: 
>>> https://wiki.mozilla.org/Privacy/Features/DOMCryptAPISpec/Latest
>>> 
>>> Any comments and discussion will be most welcome.
>>> 
>>> Regards,
>>> 
>>> David Dahl
>>> 
>> 

Re: [whatwg] DOMCrypt update: July 14 Meeting Report

[Silvia Pfeiffer]

OK, so it would apply to a private video conference, but not to
protect a server-client-delivery. That's good to know, thanks.
Silvia.

On Wed, Jul 27, 2011 at 8:26 AM, David Dahl  wrote:
> Silvia:
>
> The design - at this time - allows the client to encrypt data locally, with 
> the publicKey of the recipient - not allowing anyone else to read the data. 
> The callback that the web page provides which captures the decrypted data has 
> full access to the decoded data.
>
> I imagine the DRM scenario would be possible if the API was implemented 
> server side, but I think it would be a rather weak system.
>
> Generally, this API is designed for private messaging between 2 users, with 
> an untrusted server (as well as all of the hashing, HMAC, sign and verify 
> methods).
>
> The use-cases are listed here: 
> https://wiki.mozilla.org/Privacy/Features/DOMCryptAPI/UseCases
>
> Cheers,
>
> David
>
> - Original Message -
> From: "Silvia Pfeiffer" 
> To: "David Dahl" 
> Cc: "WHATWG Proposals" 
> Sent: Tuesday, July 26, 2011 4:58:30 PM
> Subject: Re: [whatwg] DOMCrypt update: July 14 Meeting Report
>
> If I understand this correctly, then this is introducing a mechanism
> for Web publishers to provide a secure service to users where the data
> exchanged between the server and the UA is encrypted and not decodable
> by anyone else listening in on that communication or getting access to
> the data stored in the browser for that communication.
>
> If so, could this be a means to provide a one-session-only decoding
> key to a UA to decode a specially encoded piece of content (e.g. a
> video) from a publisher? I am quite directly thinking that this could
> be a first step towards providing DRM methodology in the browser, but
> also for example for about having secure private video conversations
> without needing to install browser plugins.
>
> Apologies for taking this thread a bit off topic - I am just curious.
>
> Cheers,
> Silvia.
>
>
> On Wed, Jul 27, 2011 at 5:59 AM, David Dahl  wrote:
>> Hello All:
>>
>> Just a quick report on a DOMCrypt meeting that took place Thursday, 
>> 2011-07-14 at Mozilla in Mountain View.
>>
>> Summary:
>>
>>    DOMCrypt is a high-level API that should be usable by web developers 
>> after a short period of study
>>    DOMCrypt will be designed and implemented so that it is difficult to "do 
>> the wrong thing"
>>    HASH and HMAC methods may be implemented first
>>    The Public Key API is the most useful, so it should be implemented before 
>> the symmetric encryption API
>>        Keypairs must be generated on a per-origin basis
>>        The Keypair for a specific origin cannot be used in another origin
>>    No private or wrapped key material will be accessible to content scripts
>>    Each implementation will provide a mechanism to clear keys
>>    A "Key ID" will be used to tell the decrypt method which (content 
>> inaccessible) private key to use to decrypt data
>>    The returned encrypted object format will be a raw ArrayBuffer
>>    The public key format will be a raw ArrayBuffer
>>        **We agreed to "have all the inputs and outputs be raw, unformatted 
>> ArrayBuffers, letting higher-level pure JS wrappers deal with conversion to 
>> application data formats until we understand better what higher-level 
>> formats would be useful"
>>    HASH and HMAC methods should be synchronous to make them simpler
>>        HASH and HMAC methods should be constructors
>>    We may implement the HASH and HMAC APIs first then the PublicKey API
>>
>> A wiki page with more detail is here: 
>> https://wiki.mozilla.org/Privacy/Features/DOMCryptAPISpec/Meeting-2011-07-14
>>
>> The DOMCrypt Spec is here: 
>> https://wiki.mozilla.org/Privacy/Features/DOMCryptAPISpec/Latest
>>
>> Any comments and discussion will be most welcome.
>>
>> Regards,
>>
>> David Dahl
>>
>

Re: [whatwg] DOMCrypt update: July 14 Meeting Report

[David Dahl]

Silvia:

The design - at this time - allows the client to encrypt data locally, with the 
publicKey of the recipient - not allowing anyone else to read the data. The 
callback that the web page provides which captures the decrypted data has full 
access to the decoded data.

I imagine the DRM scenario would be possible if the API was implemented server 
side, but I think it would be a rather weak system.

Generally, this API is designed for private messaging between 2 users, with an 
untrusted server (as well as all of the hashing, HMAC, sign and verify methods).

The use-cases are listed here: 
https://wiki.mozilla.org/Privacy/Features/DOMCryptAPI/UseCases

Cheers,

David

- Original Message -
From: "Silvia Pfeiffer" 
To: "David Dahl" 
Cc: "WHATWG Proposals" 
Sent: Tuesday, July 26, 2011 4:58:30 PM
Subject: Re: [whatwg] DOMCrypt update: July 14 Meeting Report

If I understand this correctly, then this is introducing a mechanism
for Web publishers to provide a secure service to users where the data
exchanged between the server and the UA is encrypted and not decodable
by anyone else listening in on that communication or getting access to
the data stored in the browser for that communication.

If so, could this be a means to provide a one-session-only decoding
key to a UA to decode a specially encoded piece of content (e.g. a
video) from a publisher? I am quite directly thinking that this could
be a first step towards providing DRM methodology in the browser, but
also for example for about having secure private video conversations
without needing to install browser plugins.

Apologies for taking this thread a bit off topic - I am just curious.

Cheers,
Silvia.


On Wed, Jul 27, 2011 at 5:59 AM, David Dahl  wrote:
> Hello All:
>
> Just a quick report on a DOMCrypt meeting that took place Thursday, 
> 2011-07-14 at Mozilla in Mountain View.
>
> Summary:
>
>    DOMCrypt is a high-level API that should be usable by web developers after 
> a short period of study
>    DOMCrypt will be designed and implemented so that it is difficult to "do 
> the wrong thing"
>    HASH and HMAC methods may be implemented first
>    The Public Key API is the most useful, so it should be implemented before 
> the symmetric encryption API
>        Keypairs must be generated on a per-origin basis
>        The Keypair for a specific origin cannot be used in another origin
>    No private or wrapped key material will be accessible to content scripts
>    Each implementation will provide a mechanism to clear keys
>    A "Key ID" will be used to tell the decrypt method which (content 
> inaccessible) private key to use to decrypt data
>    The returned encrypted object format will be a raw ArrayBuffer
>    The public key format will be a raw ArrayBuffer
>        **We agreed to "have all the inputs and outputs be raw, unformatted 
> ArrayBuffers, letting higher-level pure JS wrappers deal with conversion to 
> application data formats until we understand better what higher-level formats 
> would be useful"
>    HASH and HMAC methods should be synchronous to make them simpler
>        HASH and HMAC methods should be constructors
>    We may implement the HASH and HMAC APIs first then the PublicKey API
>
> A wiki page with more detail is here: 
> https://wiki.mozilla.org/Privacy/Features/DOMCryptAPISpec/Meeting-2011-07-14
>
> The DOMCrypt Spec is here: 
> https://wiki.mozilla.org/Privacy/Features/DOMCryptAPISpec/Latest
>
> Any comments and discussion will be most welcome.
>
> Regards,
>
> David Dahl
>

Re: [whatwg] Styling of datagrid content

[Ian Hickson]

On Tue, 13 Mar 2007, Sean Hogan wrote:
>
> How do you define style for datagrids?
> e.g.
> - row color
> - alternating row color
> - selected row color
> - initial column widths
> - fixed column widths

For the time being, I have abandoned the idea of specifying a  
element. My plan is to wait to see if recent developments around XBL go 
anywhere, and if they do, see if  can just be implemented using 
a widget binding by authors rather than having a native widget.

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: [whatwg] DOMCrypt update: July 14 Meeting Report

[Silvia Pfeiffer]

If I understand this correctly, then this is introducing a mechanism
for Web publishers to provide a secure service to users where the data
exchanged between the server and the UA is encrypted and not decodable
by anyone else listening in on that communication or getting access to
the data stored in the browser for that communication.

If so, could this be a means to provide a one-session-only decoding
key to a UA to decode a specially encoded piece of content (e.g. a
video) from a publisher? I am quite directly thinking that this could
be a first step towards providing DRM methodology in the browser, but
also for example for about having secure private video conversations
without needing to install browser plugins.

Apologies for taking this thread a bit off topic - I am just curious.

Cheers,
Silvia.


On Wed, Jul 27, 2011 at 5:59 AM, David Dahl  wrote:
> Hello All:
>
> Just a quick report on a DOMCrypt meeting that took place Thursday, 
> 2011-07-14 at Mozilla in Mountain View.
>
> Summary:
>
>    DOMCrypt is a high-level API that should be usable by web developers after 
> a short period of study
>    DOMCrypt will be designed and implemented so that it is difficult to "do 
> the wrong thing"
>    HASH and HMAC methods may be implemented first
>    The Public Key API is the most useful, so it should be implemented before 
> the symmetric encryption API
>        Keypairs must be generated on a per-origin basis
>        The Keypair for a specific origin cannot be used in another origin
>    No private or wrapped key material will be accessible to content scripts
>    Each implementation will provide a mechanism to clear keys
>    A "Key ID" will be used to tell the decrypt method which (content 
> inaccessible) private key to use to decrypt data
>    The returned encrypted object format will be a raw ArrayBuffer
>    The public key format will be a raw ArrayBuffer
>        **We agreed to "have all the inputs and outputs be raw, unformatted 
> ArrayBuffers, letting higher-level pure JS wrappers deal with conversion to 
> application data formats until we understand better what higher-level formats 
> would be useful"
>    HASH and HMAC methods should be synchronous to make them simpler
>        HASH and HMAC methods should be constructors
>    We may implement the HASH and HMAC APIs first then the PublicKey API
>
> A wiki page with more detail is here: 
> https://wiki.mozilla.org/Privacy/Features/DOMCryptAPISpec/Meeting-2011-07-14
>
> The DOMCrypt Spec is here: 
> https://wiki.mozilla.org/Privacy/Features/DOMCryptAPISpec/Latest
>
> Any comments and discussion will be most welcome.
>
> Regards,
>
> David Dahl
>

Re: [whatwg] Proposal for a web application descriptor

[Ian Hickson]

On Fri, 29 Apr 2011, Simon Heckmann wrote:
> 
> I have read a lot in the last month about the future of html and web 
> applications and I am very impressed by the progress this makes. 
> However, I have come across some thing that annoys me: Permissions. I 
> know they are important and I know they are needed but currently I find 
> this quite inconvenient. And with more and more permissions coming up 
> this might get worse so I spent some time thinking about it.
> 
> I have written a short document covering my proposal: 
> www.simonheckmann.de/download/Proposal.pdf (3 pages, ~200KB)
> 
> It should just take only a few minutes to read and includes examples and 
> screenshots. I am really looking forward to hearing your thoughts on 
> this. Please feel free to share this idea with whomever you want to. If 
> you think I should post this proposal somewhere else please say so.

Robert O'Callahan posted a good response:

http://weblogs.mozillazine.org/roc/archives/2011/06/permissions_for.html

In short, the better solution isn't to ask for permissions up-front, but 
to ask for fewer permissions. The ideal solution is to not ask for any 
permission but to base the permission on a natural user gesture. For 
example, drag-and-drop of files to a site doesn't require permissions, but 
it is an implicit permission grant. Same with . With 
getUserMedia() we are doing something similar: instead of asking for 
permission, the user is asked for a specific input to be selected.

Permission grants are a bug.


On Sat, 30 Apr 2011, Glenn Maynard wrote:
> 
> I'd wonder what their response is to Android; the problems on that 
> platform are obvious.  The result is exactly as you say: people end up 
> giving up and just accepting everything.
> 
> (The permissions request for Skype includes: "read contact data, write 
> contact data, coarse (network-based) location, full Internet access, act 
> as an account authenticator, manage the accounts list, user the 
> authentication credentials of an account, modify/delete USB storage 
> contents, change your audio settings, record audio, read phone state and 
> identity, disable keylock, modify global system settings, prevent phone 
> from sleeping, retrieve running applications, write sync settings, view 
> network state, view Wi-Fi state, control vibrator, read sync settings, 
> read sync statistics, discover known accounts".  It's hopeless; if "take 
> out a mortgage on your house" was in there, nobody would notice.)
> 
> Of course, asking each of these while using the application would also 
> be painfully annoying, and it's not obvious how to make permissions 
> meaningful to the user (eg. when you use its feature) while also scaling 
> to lots of permissions.

Indeed. The system shouldn't ask for any permissions. For example instead 
of reading contact data, it could cause the OS to pop up a contacts list 
from which you can pick a contact to give access to it to the app.


On Sun, 1 May 2011, Robert O'Callahan wrote:
> 
> Notifications are a particularly hard case for the principle of 
> requesting permissions in response to user action, because the whole 
> point of notifications is that they happen when the user isn't giving 
> the application attention :-).

My proposal for notifications was to have them default to being just 
inside the page (nothing that a  couldn't do), but that they would 
include explicit UI to promote them to full-system notifications; and 
vice-versa, so a system notification could be demoted back to just in-page 
notification with a similar gesture.


On Tue, 3 May 2011, Cameron Heavon-Jones wrote:
> 
> The quantity of permission requests can be managed in an effective 
> manner by the agent allowing the user to store their preferences for the 
> next command or as a universal setting.

That doesn't work. It might be appropriate for Bing Maps to have access to 
my Geolocation information, but I certainly don't want some random blog to 
have access to it. Defaults don't work here.


> For web applications to specify their required permissions would seem to 
> introduce a duplication of specification. If a web application includes 
> an image file upload which the user chooses to capture from webcam, 
> first how is the application to know that the user would use a web cam?

There's no need for the app to know. It can just allow the user to upload 
a photo, and the browser can offer to use the webcam.



I haven't added anythign to the spec in relation to this proposal.

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

[whatwg] [editing] HTML Editing APIs specification ready for implementer feedback

[Aryeh Gregor]

Since February, I've been working on writing a detailed specification
for browser editing, primarily the document.execCommand() and
document.queryCommand*() methods.  These were created by Microsoft in
the 1990s and were subsequently adopted in some form by all other
browsers, and today browsers have to implement them to be compatible
with web content, but no detailed specification ever existed.
Interoperability is practically nonexistent as a result, which has
driven all major content editing frameworks away from using
execCommand().  Hopefully we can start to fix that and make these APIs
a part of the web platform that just works.

The current version of the specification is at
.  It's about fifty pages
printed, and supersedes the Editing APIs section of HTML

(which is more like two pages).  In the style of modern web specs, it
is phrased in terms of algorithms that attempt to cover all corner
cases unambiguously and leave no behavior undefined, and it tries to
match the behavior of existing browsers to the greatest extent
possible.  At this point, it's stable and complete enough that I
believe it's ready for serious review by implementers, and I would
like as much detailed feedback as possible.

There is a basically complete JavaScript implementation, which is used
to produce expected results for a largely undocumented and entirely ad
hoc test suite:
.  I used the
tests as an aid to writing the spec, and they probably aren't well
suited to aid implementers in implementing it.  I will probably get
around to porting them to something like testharness.js at some point.
 I haven't tried testing my implementation on real-world sites, only
on artificial input, so I don't know at this point how implementable
it really is, but the JS implementation means that it at least has
large parts that make sense.

Anyone reviewing the spec should be advised that I put extensive
rationale in HTML comments.  If you want to know why the spec says
what it does, check the HTML source.  I plan to change this to use
 or such in the near future.  There are lots of minor known
issues still left, but none that I thought was important enough that
it needs to delay review.  Feedback can be sent to the whatwg list,
CCing me, with [editing] in the subject.  (I'm also fine receiving
feedback on public-html or public-webapps, but I don't know if the
chairs would be okay with that, since it's off-topic.)  I should be
available to respond to all feedback promptly at least through the end
of August.  After that, I can't make specific guarantees about my
availability, but I do plan to continue maintaining the spec in the
long term.

I've CCd or BCCd everyone who's commented on or contributed to this
spec at some point.

Re: [whatwg] PeerConnection, MediaStream, getUserMedia(), and other feedback

[sc...@crisscott.com]

- Reply message -
From: "Ian Hickson" 
Date: Tue, Jul 26, 2011 1:30 am
Subject: [whatwg] PeerConnection, MediaStream, getUserMedia(),  and other 
feedback
To: "wha...@whatwg.org" 

[whatwg] DOMCrypt update: July 14 Meeting Report

[David Dahl]

Hello All:

Just a quick report on a DOMCrypt meeting that took place Thursday, 2011-07-14 
at Mozilla in Mountain View.

Summary:

DOMCrypt is a high-level API that should be usable by web developers after 
a short period of study
DOMCrypt will be designed and implemented so that it is difficult to "do 
the wrong thing"
HASH and HMAC methods may be implemented first
The Public Key API is the most useful, so it should be implemented before 
the symmetric encryption API
Keypairs must be generated on a per-origin basis
The Keypair for a specific origin cannot be used in another origin 
No private or wrapped key material will be accessible to content scripts
Each implementation will provide a mechanism to clear keys
A "Key ID" will be used to tell the decrypt method which (content 
inaccessible) private key to use to decrypt data
The returned encrypted object format will be a raw ArrayBuffer
The public key format will be a raw ArrayBuffer
**We agreed to "have all the inputs and outputs be raw, unformatted 
ArrayBuffers, letting higher-level pure JS wrappers deal with conversion to 
application data formats until we understand better what higher-level formats 
would be useful"
HASH and HMAC methods should be synchronous to make them simpler
HASH and HMAC methods should be constructors 
We may implement the HASH and HMAC APIs first then the PublicKey API

A wiki page with more detail is here: 
https://wiki.mozilla.org/Privacy/Features/DOMCryptAPISpec/Meeting-2011-07-14

The DOMCrypt Spec is here: 
https://wiki.mozilla.org/Privacy/Features/DOMCryptAPISpec/Latest 

Any comments and discussion will be most welcome.

Regards,

David Dahl

Re: [whatwg] PeerConnection, MediaStream, getUserMedia(), and other feedback

[ᛏᚮᛘᛘᚤ]

On Tue, Jul 26, 2011 at 07:30, Ian Hickson  wrote:
>
>
> > If you send two MediaStream objects constructed from the same
> > LocalMediaStream over a PeerConnection there needs to be a way to
> > separate them on the receiving side.
>
> What's the use case for sending the same feed twice?
>

There's no proper use case as such but the spec allows this.


>
>
> > I also think it is a bit unfortunate that we now have a 'label' property
> > on the track objects that means something else than the 'label' property
> > on MediaStream, perhaps 'description' would be a more suitable name for
> > the former.
>
> In what sense do they mean different things? I don't understand the
> problem here. Can you elaborate?
>

label on a MediaStream is a unique identifier, while the label on a
MediaStreamTrack is just a description like "Logitech Vision Pro", "Line In"
or "Built-in Mic". I too find this a bit odd.


>
>
> On Wed, 20 Jul 2011, Tommy Widenflycht (á~[~Oá~Z®á~[~Xá~[~Xá~Z¤) wrote:
> > On Mon, Jul 18, 2011 at 20:38, Ian Hickson  wrote:
> > > On Mon, 18 Jul 2011, Tommy Widenflycht (á~[~Oá~Z®á~[~Xá~[~Xá~Z¤)
> wrote:
> > > >
> > > > I am very confused regarding the below paragraph from the latest
> > > > spec:
> > > >
> > > > When a track in a MediaStream parent is disabled, any
> > > > MediaStreamTrack objects corresponding to the tracks in any
> > > > MediaStream objects that were created from parent are disassociated
> > > > from any track, and must not be reused for tracks again. If a
> > > > disabled track in a MediaStream parent is re-enabled, from the
> > > > perspective of any MediaStream objects that were created from parent
> > > > it is a new track and thus new MediaStreamTrack objects must be
> > > > created for the tracks that correspond to the re-enabled track.
> > > >
> > > > After cloning a LocalMediaStream it looks like this:
> > > >
> > > > LocalMediaStream -> MediaStream1
> > > > Track1(E)   Track1(E)
> > > > Track2(E)   Track2(E)
> > > > Track3(E)   Track3(E)
> > > >
> > > > and as I interpret the spec it looks like this if Track1 in the
> > > > LocalMediaStream is disabled:
> > > >
> > > > LocalMediaStream -> MediaStream1
> > > > Track1(D)   Track2(E)
> > > > Track2(E)   Track3(E)
> > > > Track3(E)
> > >
> > > Correct so far (though I'd avoid the term "cloning" since it's not
> > > quite what's going on here -- the spec uses "forking", which may be
> > > closer though is still not ideal).
> > >
> > > > So Track1 disappears from the MediaStream1 object and doesn't come
> > > > back even if Track1 in the LMS object is enabled:
> > > >
> > > > LocalMediaStream -> MediaStream1
> > > > Track1(E)   Track2(E)
> > > > Track2(E)   Track3(E)
> > > > Track3(E)
> > >
> > > No, it'll create a new track object:
> > >
> > >  LocalMediaStream -> MediaStream1
> > >  Track1(E)   Track4(E)
> > >  Track2(E)   Track2(E)
> > >  Track3(E)   Track3(E)
> > >
> > > This is specified in the sentence that starts "If a disabled track in
> > > a MediaStream parent is re-enabled...".
> >
> > Thanks for the explanation. To me this sounds overly complicated, why
> > not just make it so that an disable of a track will override the track
> > settings for forked MediaStreams?
>
> I don't understand what you mean. How would that be different?
>
>
If I may make an analogy to the real world: plumbing.

Each fork of a MediaStream is a new joint in the pipe, my suggestion
introduces a tap at each joint. No matter how you open and close the tap at
the end (or middle); if any previous tap is closed there's nothing coming
through.
The spec currently removes and add the entire pipe after the changed joint.


>
> > Also some follow-up questions regarding the new TrackLists:
> >
> > What should happen when a track fails? Should the entire stream fail,
> > the MSTrack silently be removed or the MSTrack disassociated with the
> > track (and thus becoming a do-nothing object)?
>
> What do you mean by "fails"?
>

Yanking the USB cable to the camera for example. This should imho stop the
MS, not just silently send black video.


> > What should happen when a stream with two or more video tracks is
> > associated to a  tag? Just render the first enabled one?
>
> Same as if you had a regular video file with multiple tracks.
>
>
And that is? Sorry, this might be written down somewhere and I have missed
it.


/Tommy

-- 
Tommy Widenflycht, Senior Software Engineer
Google Sweden AB, Kungsbron 2, SE-11122 Stockholm, Sweden
Org. nr. 556656-6880
And yes, I have to include the above in every outgoing email according to EU
law.

Re: [whatwg] date meta-tag invalid

[aykut.sensoy]

http://www.google.com/support/news_pub/bin/answer.py?answer=93994

See Link above, Google says, that they provide "DC.date.issued", but this
is also not part auf the whatwg metaextensions list.
 


kind regards

Aykut



Am 18.07.11 16:11 schrieb "Julian Reschke" unter :

>On 2011-07-18 15:59, aykut.sen...@bild.de wrote:
>> hi julian,
>> i have asked one from the seo team and he says for example the
>>"freshness
>> factor" is important for google.
>> is it possible to use the time-tag in the head instead (i mean
>>invisible)?
>> dc:created is also not in the Meta Extensions List, see:
>> http://wiki.whatwg.org/wiki/MetaExtensions
>
>I *believe* the SEO time is misguided when it thinks that
>meta/@name="date" affects Google. But only Google can tell us.
>
>I mentioned dc:created not because it's valid, but because it's at least
>*specified* and in more wider use.
>
>Best regards, Julian
>

Re: [whatwg] [Selectors4] case-insensitive attribute value matching (in XML)

[Christoph Päper]

Anne van Kesteren:
> I'm still trying to get HTML and browsers to change so that attribute values 
> always match case-sensitively, irrespective of markup language. The current 
> magic attribute list in HTML whose values needs to be matched ASCII 
> case-insensitively is just ugly.

Can’t that be changed to something like the following?

  When an attribute takes as a value
  – a single keyword or
  – a whitespace-separated list of keywords,
  where all valid keywords are defined in this spexcification,
  these keywords are ASCII case-insensitive.
  All other attribute values are case-sensitive.

or just

  All element names, attribute names and attribute value keywords
  defined in this specification are ASCII case-insensitive.
  All other attribute values are case-sensitive.