Re: [whatwg] File API Streaming Blobs
See below! Am 11.08.2011 um 23:24 schrieb Bjartur Thorlacius : > Þann mán 8.ágú 2011 20:31, skrifaði Simon Heckmann: >> Well, not directly an answer to your question, but the use case I had in >> mind is the following: >> >> A large encrypted video (e.g. HD movie with 2GB) file is stored using the >> File API, I then want to decrypt this file and start playing with only a >> minor delay. I do not want to decrypt the entire file before it can be >> viewed. As long as such as use case gets covered I am fine with everything. >> > Has the decryption to happen above the File API? Well, ist could also be part of the File API, but ist should not be below the File API.
Re: [whatwg] File API Streaming Blobs
It's actually confidential company data, I was thinking off. Together with the DOMCrypt API I thought this could be a valid use case. But I think there might be more cases in which it might make sense to preprocess locally stored video data. Kind regards, Simon Heckmann Am 08.08.2011 um 23:51 schrieb Glenn Maynard : > On Mon, Aug 8, 2011 at 4:31 PM, Simon Heckmann wrote: > Well, not directly an answer to your question, but the use case I had in mind > is the following: > > A large encrypted video (e.g. HD movie with 2GB) file is stored using the > File API, I then want to decrypt this file and start playing with only a > minor delay. I do not want to decrypt the entire file before it can be > viewed. As long as such as use case gets covered I am fine with everything. > > Assuming you're thinking of DRM, are there any related use cases other than > crypto? Encryption for DRM, at least, isn't a very compelling use case; > client-side Javascript encryption is a very weak level of protection (putting > aside, for now, the question of whether the web can or should be attempting > to handle DRM in the first place). If it's not DRM you're thinking of, can > you clarify? > > -- > Glenn Maynard >
Re: [whatwg] File API Streaming Blobs
Well, not directly an answer to your question, but the use case I had in mind is the following: A large encrypted video (e.g. HD movie with 2GB) file is stored using the File API, I then want to decrypt this file and start playing with only a minor delay. I do not want to decrypt the entire file before it can be viewed. As long as such as use case gets covered I am fine with everything. Kind regards, Simon Heckmann Am 08.08.2011 um 22:17 schrieb Eric U : > Sorry about the very slow response; I've been on leave, and am now > catching up on my email. > > On Wed, Jun 22, 2011 at 11:54 AM, Arun Ranganathan wrote: >> Greetings Adam, >> >>> Ian, I wish I knew that earlier when I originally posted the idea, >>> there was lots of discussion and good ideas but then it suddenly >>> dropped of the face of the earth. Essentially I am fowarding this >>> suggestion to public-weba...@w3.org on the basis as apparently most >>> discussion of File API specs happen there, and would like to know how >>> to move forward with this suggestion. >>> >>> The original suggestion and following comments are on the whatwg list >>> archive, starting with >>> >>> <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2011-January/029973.html> >>> >>> Summing up, the problem with the current implementation of Blobs is >>> that once a URI has been generated for them, by design changes are no >>> longer reflected in the object URL. In a streaming scenario, this is >>> not what is needed, rather a long-living Blob that can be appended is >>> needed and 'streamed' to other parts of the browser, e.g. the >>> or element. >>> The original use case was: make an application which will download >>> media files from a server and cache them locally, as well as playing >>> them without making the user wait for the entire file to be >>> downloaded, converted to a blob, then saved and played, however such >>> an API covers many other use cases such as on-the-fly on-device >>> decryption of streamed media content (ie live streams either without >>> end or static large files that to download completely would be a waste >>> when only the first couple of seconds need to be buffered and >>> decrypted before playback can begin) >>> >>> Some suggestions were to modify or create a new type of Blob, the >>> StreamingBlob which can be changed without its object url changing and >>> appended to as new data is downloaded or decoded, and using a similar >>> process to how large files may start to be decoded/played by a browser >>> before they are fully downloaded. Other suggestions suggested using a >>> pull API on the Blob so browsers can request for new data >>> asynchronously, such as in >>> >>> <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2011-January/029998.html> >>> >>> Some problems however that a browser may face is what to do with urls >>> which are opened twice, and whether the object url should start from >>> the beginning (which would be needed for decoding encrypted, on-demand >>> audio) or start from the end (similar to `tail`, for live streaming >>> events that need decryption, etc.). >>> >>> Thanks, >>> P.S. Sorry if I've not done this the right way by forwarding like >>> this, I'm not usually active on mailing lists. >>> >>> >> >> I actually think moving to a streaming mode for file reads in general is >> desirable, but I'm not entirely sure extending Blobs is the way to go for >> *that* use case, which honestly is the main use case I'm interested in. We >> may improve upon ideas after this API goes to Last Call for streaming file >> reads; hopefully we'll do a better job than other non-JavaScript APIs out >> there :) [1]. Blob objects as they are currently specified live "in memory" >> and represent "in memory" File objects as well. A change to the underlying >> file isn't captured in the Blob snapshot; moreover, if the file moves or is >> no longer present at time of read, an error event is fired while processing >> a read operation. The object URL may be dereferenced, but will result in a >> 404. >> >> The Streaming API explored by WHATWG uses the Object URL scheme for >> videoconferencing use cases [2], and so the scheme itself is suitable for >> "resources" that are more dynamic than memory-resident Blob objects. >> Segment-plays/segment dereferencing in gen
Re: [whatwg] DOMCrypt update: July 14 Meeting Report
I totally agree with you. My code was just an example. I also think it should
be idiot proof.
However, I think the whole API should be loosly coupled. Requiring the client
to initialize a cryptographic function on the server seems to tightly linked. I
think it should be possible to decrypt any chunk of data with the DOMCrypt API
as long as I know the algorithm and the key. But maybe this is out of scope and
I am thinking in too universal concepts?
Kind regards,
Simon Heckmann
Am 27.07.2011 um 10:57 schrieb Adam Barth :
> The downside of that sort of API is that you end up storing key
> material in the JavaScript heap. There's some question about whether
> we should avoid doing that, which is part of the motivation to do the
> public key API before the symmetric API.
>
> Your example also raise the question of how to do key derivation and
> key agreement. Taking the MD5 hash of a password isn't really the
> best key derivation function! There's a design question of whether we
> should design the API to be usable (relatively) safely by non-experts.
> Given that this is an API for the web, you can understand the desire
> to make things as "idiot-proof" as possible.
>
> I'd certainly like to see DOMCrypt be able to handle these sorts of
> use cases in the future. It's mostly a question of which use cases to
> address first.
>
> Adam
>
>
> On Wed, Jul 27, 2011 at 1:18 AM, Simon Heckmann
> wrote:
>> Thank you for your reply, but to me this seems overly complicated. Why do I
>> need a KeyId?
>>
>> What about the following proposal:
>>
>> Phase one: The server knows the user's password and encrypts the file.
>> Phase two: The encrypted file is stored on the local hard drive using the
>> File API.
>> Pase three: User enters the password, which is hashed and used for
>> decryption:
>>
>> var password = document.getElementById('passwordfield').value;
>> var hash = window.crypto.hash('md5', password);
>> var data = window.crypto.decrypt('aes-256', hash, encfiledata);
>>
>> This code is just a sample, but it looks way more convenient to me.
>> Additionally there is no need to store the keyid somewhere?!?
>>
>> Kind regards,
>> Simon Heckmann
>>
>>
>> Am 27.07.2011 um 04:14 schrieb 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?
Re: [whatwg] DOMCrypt update: July 14 Meeting Report
Thank you for your reply, but to me this seems overly complicated. Why do I
need a KeyId?
What about the following proposal:
Phase one: The server knows the user's password and encrypts the file.
Phase two: The encrypted file is stored on the local hard drive using the File
API.
Pase three: User enters the password, which is hashed and used for decryption:
var password = document.getElementById('passwordfield').value;
var hash = window.crypto.hash('md5', password);
var data = window.crypto.decrypt('aes-256', hash, encfiledata);
This code is just a sample, but it looks way more convenient to me.
Additionally there is no need to store the keyid somewhere?!?
Kind regards,
Simon Heckmann
Am 27.07.2011 um 04:14 schrieb 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
Re: [whatwg] DOMCrypt update: July 14 Meeting Report
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] window.cipher HTML crypto API draft spec
Am 24.05.2011 um 16:48 schrieb David Dahl : > - Original Message - > From: "Henri Sivonen" > To: "David Dahl" > Cc: whatwg@lists.whatwg.org > Sent: Tuesday, May 24, 2011 2:25:53 AM > Subject: Re: [whatwg] window.cipher HTML crypto API draft spec > >> It seems unfortunate that crypto is only available when a JavaScript > program explicitly drives encryption. This means that in order to use > crypto, the Web app has to be written in such a way that all its > resource handling is programmed in JavaScript instead of using > traditional browser-handled resource retrievals. > > I imagine using resource retrieval would be the way to handle larger binary > data decryption, and would be an amazing counterpart to this API - it also > seems like a much bigger project to undertake. The emphasis on DOMCrypt is > mainly on giving content developers a way to write privacy-enhanced web apps. > >> Consider for example a DropBox-style service that has a browser-based UI > but that has a design where content is encrypted on the client-side so > that the service provider is unable to decrypt the data. In this case, > it would make sense to be able to implement a file download by having a > plain to an excrypted file and have the browser automatically > decrypt it. Likewise, a service that allows the transmission of > encrypted images should be implementable by having point > directly to an encrypted file. > > I think someone was asking about that kind of functionality during my > presentation at Mozilla. Again, this would be a pretty advanced complement to > this API - I would love to see something like that spec'd and implemented as > well. > >> I suggest adding a Content-Encoding type that tells the HTTP stack that > the payload of a HTTP response is encrypted and needs to be decrypted > using a key previously initialized using the JS API. > > cool. I'll look into that. Now while your at this, here is another use case I would like to add: Some time ago I developed an offline video viewer using the file system API. To increase security I encrypted the files on the server with username and password. I then used a JavaScript implementation to decrypt the files offline. Sadly this was way to slow. However with a native crypto API, similar to what you are proposing here, the offline decryption could be done quite efficiently. So maybe you want to consider specifying typed arrays and ArrayBuffers as input as well. So there is efficient use for a huge amount of binary data. Kind regards, Simon Heckmann > >> On the other hand, it seems that letting Web apps generate per-user key > pairs and letting Web apps discover if the user possesses the private > key that decrypts a particular message is a privacy problem. Someone who > wishes to surveil Web users could use private keys as supercookies, > since the generated private key is most probably going to be unique to > user. > > Currently, my implementation requires the enduser to open a file from the > file system in order to view the contents of the private key. It is only > accessible to privileged code - content has no access to it whatsoever. > >> OTOH, wiping keys along with cookies could lead to accidents. >> Is there a plan on how this will integrate into various private data > deletion UIs in such a way that users have the option to delete keys but > understand the implications and don't delete them accidentally? > > Not yet. There no doubt will have to be a UI that helps users understand the > ramifications of deleting keys, etc. > >> Are all the methods that take a success callback meant to pop up a > geolocation-style asynchronous authorization UI until the user > perma-authorizes a site to use crypto? > > It is not implemented yet, but yes, that would be the plan. > - - > >> Is the plan to use Firefox Sync to sync the user's private keys across > multiple browser instances so that the user doesn't need to manually > transfer keys in the usual case? > > I do think so, however, there are those who would caution against the private > key ever going over the wire. I think with Sync, it would be safe. > > - - > >> Currently, it is unfortunate that choosing to use a webmail client > effectively prevents a person from using encrypted email. To allow > people to use end-to-end encrypted email with webmail apps, it would be > useful to support OpenPGP as an encryption format. (Obviously, a > malicious webmail app could capture the decrypted messages on the > browser and send them back to the server, but when the webmail app > itself doesn't contain code like that, putting the decryption
Re: [whatwg] window.cipher HTML crypto API draft spec
Why does it only handle asymmetric encryption? Something to encrypt/decrypt data with e.g. AES would be nice as well! Kind regards, Simon Heckmann Am 20.05.2011 um 20:45 schrieb Adam Barth : > Why window.cipher and not just window.crypto? > > Adam > > > On Fri, May 20, 2011 at 8:04 AM, David Dahl wrote: >> Hello WHATWG members, >> >> With user control and privacy in mind, I have created a spec and an >> implementation for an easy to use cryptography API called DOMCrypt. This API >> will provide each web browser window with a 'cipher' property that >> facilitates: >> >> * asymmetric encryption key pair generation >> * public key encryption >> * decryption >> * signature generation >> * signature verification >> * hashing >> * easy public key discovery via meta tags >> >> I have created a Firefox extension that implements all of the above, and am >> working on an experimental patch that integrates this API into Firefox. >> >> The draft spec is here: >> https://wiki.mozilla.org/Privacy/Features/DOMCryptAPISpec/Latest >> >> The project originated in an extension I wrote, the home page is here: >> http://domcrypt.org >> >> The source code for the extension is here: >> https://github.com/daviddahl/domcrypt >> >> The Mozilla bugs are here: >> https://bugzilla.mozilla.org/show_bug.cgi?id=649154 >> https://bugzilla.mozilla.org/show_bug.cgi?id=657432 >> >> You can test the API by installing the extension hosted at domcrypt.org and >> addons.mozilla.org, and going to http://domcrypt.org >> >> Best Regards, >> >> David Dahl >> >> Firefox Engineer, Mozilla Corp. >>
Re: [whatwg] Proposal for a web application descriptor
Well, the API should work in both cases, I guess. On mobile devices the UI design would be more challenging, but the idea is the same. If desired I could also design mock-ups for phones. Am 01.05.2011 um 18:31 schrieb Göran Eriksson AP : > Hi Simon, > > Just to be certain, I'd like to ask if You are targeting desktop browser > in mobile devices, such as iPad and iPhones, as well, or is Your proposal > focused on PC/laptop devices? > > Kind Regards > Göran > > > > On 2011-05-01 16.49, "Simon Heckmann" wrote: > >> Hello everyone, >> >> After reading all your comments I partly re-tought some of my ideas. >> First of all it might not be the best idea to create a full application >> descriptor if it would only be used to specify permissions. Additionally, >> I can see why people do not want to be asked for all permissions at once. >> However, I on the other hand do not want to be asked for all permissions >> separately. After reading some of the links posted in this discussion I >> modified my proposal a little. You can find the new version here: >> >>http://www.simonheckmann.de/proposal/draft2 >> >> While the first part has not changed much, the second part is all-new and >> includes two completely re-modeled mock-ups. >> >> Again, comments are welcome. >> >> Kind regards, >> Simon Heckmann >> >> >> Am 30.04.2011 um 17:23 schrieb Robert O'Callahan: >> >>> On Sun, May 1, 2011 at 1:52 AM, Glenn Maynard wrote: >>> >>>> On Sat, Apr 30, 2011 at 5:23 AM, Robert O'Callahan >>>> >>>> wrote: >>>>> The application could have a settings page with a checkbox "Enable >>>> desktop >>>> notifications". When you click on that box, the browser shows its >>>> (passive, >>>> asynchronous) UI for enabling desktop notifications for that >>>> application. >>>> >>>> This still implies having an API to ask for permission for a feature >>>> before >>>> using it. (Web Notifications has a draft for this: >>>> >>>> >>>> http://dev.w3.org/2006/webapi/WebNotifications/publish/FeaturePermission >>>> s.html >>>> .) >>>> >>>> Also, many developers won't want a UI like that, since when you >>>> disable a >>>> feature and expect users to enable it in settings, a lot of them won't. >>>> Many people never look at settings pages at all. Pages are more >>>> likely to >>>> request permissions as soon as they can. >>>> >>> >>> 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 :-). >>> >>> Another possible approach would be to have the default be for >>> notifications >>> to show up in browser UI associated with the page --- e.g., highlight >>> the >>> tab title and show the notification(s) at the top of the page if you >>> switch >>> to the tab --- and in that notification-showing UI, offer a "show on >>> desktop" button which lets the notifications for that application >>> migrate to >>> the desktop --- effectively a permission grant. >>> >>> 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. >>>> >>> >>> I think we have to consider specific cases. For Skype, it depends on >>> whether >>> all those permissions are really needed, and why... It might not be that >>> hard to figure out how to make on-demand permission grants >>> intelligible. We >>> owe it to users to try. >>> >>> Rob >>> -- >>> "Now the Bereans were of more noble character than the Thessalonians, >>> for >>> they received the message with great eagerness and examined the >>> Scriptures >>> every day to see if what Paul said was true." [Acts 17:11] >>
Re: [whatwg] Proposal for a web application descriptor
Hello everyone, After reading all your comments I partly re-tought some of my ideas. First of all it might not be the best idea to create a full application descriptor if it would only be used to specify permissions. Additionally, I can see why people do not want to be asked for all permissions at once. However, I on the other hand do not want to be asked for all permissions separately. After reading some of the links posted in this discussion I modified my proposal a little. You can find the new version here: http://www.simonheckmann.de/proposal/draft2 While the first part has not changed much, the second part is all-new and includes two completely re-modeled mock-ups. Again, comments are welcome. Kind regards, Simon Heckmann Am 30.04.2011 um 17:23 schrieb Robert O'Callahan: > On Sun, May 1, 2011 at 1:52 AM, Glenn Maynard wrote: > >> On Sat, Apr 30, 2011 at 5:23 AM, Robert O'Callahan >> wrote: >>> The application could have a settings page with a checkbox "Enable >> desktop >> notifications". When you click on that box, the browser shows its (passive, >> asynchronous) UI for enabling desktop notifications for that application. >> >> This still implies having an API to ask for permission for a feature before >> using it. (Web Notifications has a draft for this: >> >> http://dev.w3.org/2006/webapi/WebNotifications/publish/FeaturePermissions.html >> .) >> >> Also, many developers won't want a UI like that, since when you disable a >> feature and expect users to enable it in settings, a lot of them won't. >> Many people never look at settings pages at all. Pages are more likely to >> request permissions as soon as they can. >> > > 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 :-). > > Another possible approach would be to have the default be for notifications > to show up in browser UI associated with the page --- e.g., highlight the > tab title and show the notification(s) at the top of the page if you switch > to the tab --- and in that notification-showing UI, offer a "show on > desktop" button which lets the notifications for that application migrate to > the desktop --- effectively a permission grant. > > 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. >> > > I think we have to consider specific cases. For Skype, it depends on whether > all those permissions are really needed, and why... It might not be that > hard to figure out how to make on-demand permission grants intelligible. We > owe it to users to try. > > Rob > -- > "Now the Bereans were of more noble character than the Thessalonians, for > they received the message with great eagerness and examined the Scriptures > every day to see if what Paul said was true." [Acts 17:11]
Re: [whatwg] Proposal for a web application descriptor
Am 30.04.2011 um 01:41 schrieb Glenn Maynard : > On Fri, Apr 29, 2011 at 6:40 PM, Simon Heckmann wrote: > >>> Some challenges include: >>> >>> * how to justify the request to the user being asked to grant the >> privileges >>>starting with a text string and a link to more information >> >> Well, this is what I thought of: The users visit a website they have never >> visited before. A notifications pops up allowing them to set all permissions >> required for this page. The users might not trust the site yet so they do >> not grant all permissions immediately. > > > There's a more common issue: when you ask me for a bunch of permissions at > once, I don't know why you want them. This happens constantly with Android > apps: you install a simple notepad or clock app, and it'll ask for Internet > access and the ability to make phone calls, and you don't know why. > > This is why--in general--I like the model so far: the user is asked for > permission in response to actually doing something that uses a feature. In > the notepad app, you're asked for permission to access the internet when you > select "sync notes to your desktop PC"; it's immediately obvious why it's > asking for it. (That's an Android example, of course, not a web app > example.) > > Hopefully the ultimate solution will deal with both, allowing UAs the option > of asking all at once or on-demand, depending on the situation. (Some > permissions inherently have to be asked in advance, like Web Notifications, > which doesn't happen in response to a user action.) > > -- > Glenn Maynard I agree: That is why the example you quote from my previous mail went on like this: As the users continue to use the page, the web site could check the status of the permission using javascript and remind the user to rethink his permission settings: "This site would like to access your camera to scan for a barcode. If you want to use this feature, please use the global permissions dialog to set them." This way users that trust/know the application can give permissions directly while others might grant permissions one at the time. Thats why I like the idea of a consolidated dialog. The user could always quicky return to it and maintain all permissions at once.
Re: [whatwg] Fwd: Proposal for a web application descriptor
As far as I am concerned, I am fine with all of these solutions. I was just
thinking that an application descriptor could be extended over time with
additional information and maybe even contain the files required for offline
caching. Of course this could also be done the other way around and the offline
cache manifest could be turned into a web application manifest containing all
the information about the application. Maybe we could even include the
robots.txt information into the manifest?
Am 29.04.2011 um 17:33 schrieb Alexandre Morgaut:
> Oops I did it again !!!
>
> A direct Reply which did not include the whatgw list
> Thanx Simon for pointing it out, the direct response was not done
> intentionally ;-)
>
> So here my comments:
>
>> Am 29.04.2011 um 11:34 schrieb Alexandre Morgaut:
>>
>>> Hi Simon,
>>>
>>> The user interface proposal looks interesting.
>>> Please, think to turn your system into english for your screenshoots ;-)
>>>
>>> I'm just not sure it should be handled via an external xml file, but why
>>> not...
>
> Note that the XML format is actually used for sitemaps and rss feeds,
> openSearch descriptions, ...
> so it is still an option
>
>>>
>>> Other solutions could be:
>>>
>>> 1 - Robots.txt like file
>>>
>>> With a simpler syntax, as it has been chosen for the Offline cache manifest
>>>
>>> ex:
>>>
>>> LOCATION: on
>>> CAMERA: on
>>> MICROPHONE: on
>>> STORAGE: 100MB
>>> NOTIFICATIONS: on
>
> Of course, as Simon replied to me, robots.txt, the offline cache manifest,
> and this application manifest may even be merged
>
>>>
>>>
>>> 2 - Simple Meta elements
>>>
>>> Via multiple meta tags
>>>
>>>
>>>
>>>
>>>
>>> Potentially grouped into a single meta tag
>>>
>>>
>>>
>>>
>>>
>>> 3 - HTTP headers with Meta http-equiv support
>>>
>>> Via multiple headers
>>>
>>> Webapp-Permission: location
>>> Webapp-Permission: storage; size=100MB
>>>
>>> Potentially grouped into a single header
>>>
>>> Webapp-Permission: location, camera, storage; size=100MB, notifications
>>>
>>>
>>> with the Meta element equivalent
>>>
>>>
>>>
>>>
>>>
>>> 4 - and/or a JavaScript method
>>>
>>> window.requestPermissions(
>>> {
>>> location: true,
>>> storage: 10
>>> }
>>> );
>
>
>
>
>
>
>
> Alexandre Morgaut
> Product Manager
>
> 4D SAS
> 60, rue d'Alsace
> 92110 Clichy
> France
>
> Standard : +33 1 40 87 92 00
> Email :alexandre.morg...@4d.com
> Web : www.4D.com
Re: [whatwg] Proposal for a web application descriptor
Am 29.04.2011 um 16:47 schrieb Dave Raggett: > You may also want to look at the ideas being floated by Mozilla and others > for installed web apps to request extra privileges. This is expected to lead > to a new W3C Working Group within a few months from now, and I am hoping to > see progress on being able to run the browser in a locked down mode that is > more secure than is the default for web pages today (e.g. no eval, > constrained innerHTML), and to then make a single request for a list of > privileges: > > http://dougt.org/wordpress/2011/03/device-api-permission-management/ > http://groups.google.com/group/mozilla-labs/browse_thread/thread/e592b27e54b7f857 > http://dev.w3.org/2009/dap/docs/feat-perms/feat-perms.html > <http://dev.w3.org/2009/dap/docs/feat-perms/feat-perms.html#capability> Thank you! I read through these articles and I like what they are proposing. I also think it is a good idea to tackle this with a joint proposal. While some of the suggestions made in the documents relate to querying the permission through javascript I still see room for my idea to ask for permissions on start-up. I am not yet sure if this all only holds true for super-applications, as even normal websites would want to access my camera or address book and therefore need permission. Anyway, I am looking forward to giving input to a larger scope proposal. > > Some challenges include: > > * how to justify the request to the user being asked to grant the privileges > starting with a text string and a link to more information Well, this is what I thought of: The users visit a website they have never visited before. A notifications pops up allowing them to set all permissions required for this page. The users might not trust the site yet so they do not grant all permissions immediately. As the users continue to use the page, the web site could check the status of the permission using javascript and remind the user to rethink his permission settings: "This site would like to access your camera to scan for a barcode. If you want to use this feature, please use the global permissions dialog to set them." > > * white and black lists for well behaved and evil applications - which leads > on to the role of trust delegation for improved usability and whether > crowd based recommendations are practical I agree! But in the end this is similar to desktop applications. It pretty much depends on the users which applications they run and which they do not trust. I think this is where web app stores might come into play. A central place where user can share their experience. > > We should think how to work together with Mozilla, Google and others on a > joint proposal as this is likely to have greater chance of widespread > adoption than doing something in isolation. Great idea! Is there another mailing list where this should be posted on? > > > On 29/04/11 13:00, Simon Heckmann wrote: >> Hello again, >> >> As requested I updated the proposal to contain screenshots from English >> browser versions now. You can always find the latest version on >> http://www.simonheckmann.de/download/Proposal.pdf. Additionally, I created >> an HTML version of the file which might come in handy for some readers: >> http://www.simonheckmann.de/proposal/. >> >> Kind regards, >> Simon Heckmann >> >> >> Am 29.04.2011 um 11:03 schrieb Simon Heckmann: >> >>> Fixed! >>> >>> Am 29.04.2011 um 10:52 schrieb Benjamin Hawkes-Lewis: >>> >>>> On Fri, Apr 29, 2011 at 9:39 AM, Simon Heckmann >>>> wrote: >>>>> I have written a short document covering my proposal: >>>>> www.simonheckmann.de/download/Proposal.pdf (3 pages, ~200KB) >>>> I can't open this PDF in Preview. >>>> >>>> -- >>>> Benjamin Hawkes-Lewis >>> Sorry for the inconveniences! I tried it in Acrobat and it worked >>> flawlessly. I uploaded it again and it now displays in Preview as well. I >>> hope this fixes it for you, too! >>> >>> Kind regards, >>> Simon Heckmann >> > > > -- > Dave Raggett http://www.w3.org/People/Raggett
Re: [whatwg] Proposal for a web application descriptor
Hello again, As requested I updated the proposal to contain screenshots from English browser versions now. You can always find the latest version on http://www.simonheckmann.de/download/Proposal.pdf. Additionally, I created an HTML version of the file which might come in handy for some readers: http://www.simonheckmann.de/proposal/. Kind regards, Simon Heckmann Am 29.04.2011 um 11:03 schrieb Simon Heckmann: > Fixed! > > Am 29.04.2011 um 10:52 schrieb Benjamin Hawkes-Lewis: > >> On Fri, Apr 29, 2011 at 9:39 AM, Simon Heckmann >> wrote: >>> I have written a short document covering my proposal: >>> www.simonheckmann.de/download/Proposal.pdf (3 pages, ~200KB) >> >> I can't open this PDF in Preview. >> >> -- >> Benjamin Hawkes-Lewis > > Sorry for the inconveniences! I tried it in Acrobat and it worked flawlessly. > I uploaded it again and it now displays in Preview as well. I hope this fixes > it for you, too! > > Kind regards, > Simon Heckmann
Re: [whatwg] Proposal for a web application descriptor
Fixed! Am 29.04.2011 um 10:52 schrieb Benjamin Hawkes-Lewis: > On Fri, Apr 29, 2011 at 9:39 AM, Simon Heckmann > wrote: >> I have written a short document covering my proposal: >> www.simonheckmann.de/download/Proposal.pdf (3 pages, ~200KB) > > I can't open this PDF in Preview. > > -- > Benjamin Hawkes-Lewis Sorry for the inconveniences! I tried it in Acrobat and it worked flawlessly. I uploaded it again and it now displays in Preview as well. I hope this fixes it for you, too! Kind regards, Simon Heckmann
[whatwg] Proposal for a web application descriptor
Hello everyone, 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. Kind regards, Simon Heckmann
Re: [whatwg] File API Streaming Blobs
Hello everyone, I found this thread (<http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2011-January/02997 3.html>) in the archive of this mailing list, but I could not determine if any decision was made whether this should be implemented or not. I am interested in this, because I came up with a scenario which would benefit from Streaming Blobs: I use the File API to locally store larger video files on the users hard drive. For security purposes I encrypted them with AES and use a javascript library for local just-in-time decryption. This is not yet a productive application bur more of a prototype. However, I experienced javascript manipulation of large data can be quite slow so we do not want the user to wait until the full video is decrypted/manipulated. Therefore I would vote for a way to append data to a Blob and the ObjectURL reflects these modifications. Maybe something like createStreamableObjectURL could be used for differentiation? Just wanted to express my thoughts because I think the whole File API is a great idea! Kind regards, Simon Heckmann
