Re: Web Activities: counter-proposal to Web Intents
On 12/6/12 16:08 , Mounir Lamouri wrote: 2. Discovery: some consumers seem to be inclined to use Web Intents to discover other services. This is what Bryan Sullivan suggested for the Push Notification API. When the Intent is invoked no action would actually be taken, instead a URL is returned and then it's up to the page to communicate with that URL with the Web Intent API no longer involved. JCD: Web intents does not provide discovery, but more like a directory service. Your proposal also provides registration and a sort of directory service, even if you do not provide a matching algorithm. So your proposal is more or less at the same level of functionality than web intents in this respect. 3. Communication: you can use Web Intents to simply create a channel of communication between APP A and APP B: you can easily specify which service should be used to handle the intent and then, you can communicate with it. JCD: Web Intents also provides some isolation between the client and the service. Are you providing this isolation too ? If your APP A and B can later establish a communication channel, it seems not. Yet that is a very appealing feature. Best regards JC -- JC Dufourd Directeur d'Etudes/Professor Groupe Multimedia/Multimedia Group Traitement du Signal et Images/Signal and Image Processing Telecom ParisTech, 37-39 rue Dareau, 75014 Paris, France Tel: +33145817733 - Mob: +33677843843 - Fax: +33145817144
Re: [admin] Mail List Policy, Usage, Etiquette, etc. Top-posting
On 29/5/12 17:56 , Julian Reschke wrote: On 2012-05-29 16:53, Glenn Maynard wrote: On Tue, May 29, 2012 at 9:22 AM, Arthur Barstow art.bars...@nokia.com mailto:art.bars...@nokia.com wrote: * Messages should be encoded usingplain text http://en.wikipedia.org/wiki/Plain_text No, messages should have a plaintext *version* (MIME alternative). It's common and useful to use HTML messages, especially when posting about actual spec text, where being able to use italics and bold is extremely useful. This is quite a relic; I havn't heard anyone make the emails should only be in plain text claim in a decade or so. Emails should only be in plain text. JCD: It would be easier for me to comply with this rule if I understood the rationale. My perception is that this rule is not relevant any more. Against this rule, I claim that the readability of replies in text-only threads is much worse, unless the replier spends ages paying attention to text formatting by hand which is not acceptable. At least, that was the case the last time I tried. Best regards JC -- JC Dufourd Directeur d'Etudes/Professor Groupe Multimedia/Multimedia Group Traitement du Signal et Images/Signal and Image Processing Telecom ParisTech, 37-39 rue Dareau, 75014 Paris, France Tel: +33145817733 - Mob: +33677843843 - Fax: +33145817144
Re: Installing web apps
As you are saying, we seem to be talking of different things, even if I have a problem seeing how different. You make a difference between apps using web technologies accessed by HTTP or not, which I thought close to installed or not. You postulate the absence of a safe and usable way of escalating privileges for apps. That is probably what I most react to. You are talking of either sandboxing, or unfettered access. That is basically the difference between web apps and native apps in iOS, and I hate it! I can live with it only because Apple does some strict checking on native apps, but I hate relying on their judgment on privacy-related data. So I hope you are wrong, and we can find a workable model with finer grain. Best regards JC On 8/2/12 14:21 , Robin Berjon wrote: On Feb 8, 2012, at 01:06 , Jean-Claude Dufourd wrote: On 7/2/12 05:31 , Robin Berjon wrote: The first problem is that of the security model. A lot of smart people have tried to come up with a lot of different solutions here, often involving signatures, policies, intricate user interfaces, etc. I think that's all massively over-engineered. Once you take into account the fact that the number of applications that actually need this level of privilege is only a tiny fraction of the whole, you realise that you can just give up on privilege policies. These are just regular apps: they have unfettered access — period (within the limits of the underlying platform's permissions system naturally). They ought to be harder (and unusual) to install, and maybe should look different, but that's it. We might want to give them strong CSP protection by default to defend against XSS attacks, but that's a detail. JCD: I strongly disagree with you there, Robin. I do not see why installed apps should have more access. You're the one calling them installed apps :) In the section you quote above (and, unless I made a mistake, in the entirety of my post) I don't refer to high-privilege apps as installed. The installation method is largely an orthogonal problem. I personally think that it should be close to impossible to access a page in one's browser and by mistakenly clicking on a dialog to grant it permissions that would be dangerous. You probably need at least something involving multiple clicks with no quick keyboard bindings and a speed bump. Normal apps and installed apps should have the same security model, but installed apps may have permanently remembered security clearances, and that could be the only difference. That's not the line that I'm drawing. I'm drawing a line between browser apps and the rest. I'm further pointing out that the number of applications that actually fall into the rest category is smaller than most people expect once we have a generic user-mediation security system, such as Intents provide. That works *because* the number of security clearance dialogs (or the size of their content) can be diminished, perhaps even to the point that they disappear in most cases. Under this approach, System Apps are few are far apart. For a lot of users I suspect it might even be possible that they would never want any beyond those preinstalled. Safety comes from cutting the escalation vector, and making interactions between users and security about what the user wants to do rather than about a personal security policy decision — which most people (myself very much included) don't want to hear about. My proposal is as simplistic as yours, but in the opposite direction. You are saying installed apps should have all rights, I am saying installed apps should obey the exact same security as normal apps. In your system, it is dangerous to install an app, but it is very simple. In mine, there is no danger, but it is a bit more work. It's difficult for me to reply to this properly since you're making a distinction that isn't the one I'm making. How does the approach you propose acquire privileges? Upfront permissions are a security no-go. Doorhanger/infobars don't scale to multiple permissions. Facebook's current model which mixes both in moderation (ask only the smallest set you absolutely need upfront, in full knowledge that asking too many permissions decreases your adoption, and ask more in the flow of user actions) could be an interesting option but I don't know if it could scale to the sort of dangerous features that we'll eventually need for a full platform. The missing part in your description above is there is no danger *if we have a way of escalating privileges from web apps in a safe, usable manner*. To the best of my knowledge we don't, hence the noodling on a different approach. Java tried that for applets, and Java is now gone from the web apps stage. Applets could gain a lot of permissions! It was a terrible model, and has nothing in common with what I'm thinking about :) -- JC Dufourd Directeur d'Etudes/Professor Groupe Multimedia/Multimedia Group Traitement du Signal et
Re: Installing web apps
On 7/2/12 05:31 , Robin Berjon wrote: The first problem is that of the security model. A lot of smart people have tried to come up with a lot of different solutions here, often involving signatures, policies, intricate user interfaces, etc. I think that's all massively over-engineered. Once you take into account the fact that the number of applications that actually need this level of privilege is only a tiny fraction of the whole, you realise that you can just give up on privilege policies. These are just regular apps: they have unfettered access — period (within the limits of the underlying platform's permissions system naturally). They ought to be harder (and unusual) to install, and maybe should look different, but that's it. We might want to give them strong CSP protection by default to defend against XSS attacks, but that's a detail. JCD: I strongly disagree with you there, Robin. I do not see why installed apps should have more access. Normal apps and installed apps should have the same security model, but installed apps may have permanently remembered security clearances, and that could be the only difference. My proposal is as simplistic as yours, but in the opposite direction. You are saying installed apps should have all rights, I am saying installed apps should obey the exact same security as normal apps. In your system, it is dangerous to install an app, but it is very simple. In mine, there is no danger, but it is a bit more work. Having a difference between installed apps and normal apps is actually counter-productive. Java tried that for applets, and Java is now gone from the web apps stage. Best regards JC -- JC Dufourd Directeur d'Etudes/Professor Groupe Multimedia/Multimedia Group Traitement du Signal et Images/Signal and Image Processing Telecom ParisTech, 37-39 rue Dareau, 75014 Paris, France Tel: +33145817733 - Mob: +33677843843 - Fax: +33145817144
Re: Installing web apps
On 1/2/12 20:03 , Ian Hickson wrote: As a user when I install an app, I want to be able to give it access to a selection of: Providing access to these things when the app is installed is IMHO a net worse security model than granting access to these things implicitly when the feature is needed. JCD: I do not see why the granting of privileges should be implicit when some webapp is installed. I believe Tim was hinting (through the use of the words a selection of) at non-implicit, selective granting. Others in the thread have tried to clarify the installation. Something that could reconcile Tim and Ian might be to just consider installation as an association of a selection of privileges to a webapp. One privilege among others could be to be locally stored. What strikes me as important right now is: - the level of detail of requested privileges vs. the training of the users to just accept without reading; - the duration of the association of a set of privileges to webapps... Best regards JC -- JC Dufourd Directeur d'Etudes/Professor Groupe Multimedia/Multimedia Group Traitement du Signal et Images/Signal and Image Processing Telecom ParisTech, 37-39 rue Dareau, 75014 Paris, France Tel: +33145817733 - Mob: +33677843843 - Fax: +33145817144
Re: [widgets] How to divorce widgets-digsig from Elliptic Curve PAG?
On 18/12/11 20:31 , Marcos Caceres wrote: On Sunday, December 18, 2011 at 5:45 PM, Leonard Rosenthol wrote: Undated references (what you are suggesting) has the MAJOR PROBLEM that it makes it DIFFICULT/IMPOSSIBLE to do validation of any product that claims conformance to a standard – since it's impossible to determine which version of each undated reference they used. That's a FEATURE, not a problem. Makes it inexcusable not to keep up with specs (same design built into HTML5, SVG, etc.). JCD: How can you seriously state something like this ? It is so naive to think such hand waving on the spec will have any effect on how businesses adopt it and use it. See also how this de-cupling worked for XML: http://lists.w3.org/Archives/Public/spec-prod/2011OctDec/0192.html http://lists.w3.org/Archives/Public/spec-prod/2011OctDec/0201.html Additionally, it makes interoperability difficult/impossible since you can have multiple valid conforming implementations BUT they don't actually interoperate due to changes between revisions (and algo changes would be a good example of such an interoperability issue). I don't see how that is possible: if your spec does not conform to /latest/, then you are non-conforming. JCD: No! It means the spec is broken. Just because you decide on a new definition of conformance does not mean it is shared by everyone. Regards JC (speaking as coordinator of conformance in all MPEG standards between 1998 and 2006) If you were conforming yesterday, but a new version of the a spec comes out tomorrow, then you update your software to conform to the latest version. As an example, almost all Browsers are on a 6 week release cycle now: so it's quite inexcusable to expect to just conform to some dates draft and then expected to never have to update the software (i.e., conformance is an ongoing living process: specs are buggy, tests are buggy, and software is buggy… any of those can affect an conformance over time: the are all living things). Pretending that slapping a date on spec means anything is unhelpful (and actually harmful, because all specs contain bugs and hence must be continuously maintained). -- Marcos Caceres -- JC Dufourd Directeur d'Etudes/Professor Groupe Multimedia/Multimedia Group Traitement du Signal et Images/Signal and Image Processing Telecom ParisTech, 37-39 rue Dareau, 75014 Paris, France Tel: +33145817733 - Mob: +33677843843 - Fax: +33145817144
Re: [widgets] How to divorce widgets-digsig from Elliptic Curve PAG?
Marcos You are replying beside the point everywhere. Please read again what Leonard wrote about undated references. Leonard is right. In ISO specs, undated references are forbidden. There is a team of people (called ITTF) whose job includes checking these things and bugging spec editors to fix them. There is such a thing as certification. It is impossible to do if the spec is not fixed, including references. What you are advocating is entirely counterproductive given the source of the discussion (= a PAG): if the spec has undated references, you cannot make sure it is royaltee-free. If the scope of one reference changes, there is a new risk. It is not only a problem of conformance testing. Your vision of fluid standards is completely unmanageable in practice. Regards JC On 19/12/11 12:33 , Marcos Caceres wrote: On Monday, December 19, 2011 at 8:55 AM, Jean-Claude Dufourd wrote: On 18/12/11 20:31 , Marcos Caceres wrote: On Sunday, December 18, 2011 at 5:45 PM, Leonard Rosenthol wrote: Undated references (what you are suggesting) has the MAJOR PROBLEM that it makes it DIFFICULT/IMPOSSIBLE to do validation of any product that claims conformance to a standard – since it's impossible to determine which version of each undated reference they used. That's a FEATURE, not a problem. Makes it inexcusable not to keep up with specs (same design built into HTML5, SVG, etc.). JCD: How can you seriously state something like this ? Because it's a fact. Go and look at the specs. It is so naive to think such hand waving on the spec will have any effect on how businesses adopt it and use it. I'm not handwaving. I'm just pointing out a fact. And I don't see how you can call me naive, when it's you that hasn't even looked at the specs. See also how this de-cupling worked for XML: http://lists.w3.org/Archives/Public/spec-prod/2011OctDec/0192.html http://lists.w3.org/Archives/Public/spec-prod/2011OctDec/0201.html Additionally, it makes interoperability difficult/impossible since you can have multiple valid conforming implementations BUT they don't actually interoperate due to changes between revisions (and algo changes would be a good example of such an interoperability issue). I don't see how that is possible: if your spec does not conform to /latest/, then you are non-conforming. JCD: No! It means the spec is broken. No it's not. Just because you decide on a new definition of conformance does not mean it is shared by everyone. I didn't redefine conformance (or you don't know what conformance is?). Conformance: passing tests in a test suite. Tests represent conformance requirements in a specification. Test may be buggy. Spec may be buggy. Regards JC (speaking as coordinator of conformance in all MPEG standards between 1998 and 2006) Are you telling me that every test in the MPEG test suite was perfect and none have been changed after it became a standard? Or that no new tests needed to be added? Or that implementers found no issues with the MPEG specs? -- JC Dufourd Directeur d'Etudes/Professor Groupe Multimedia/Multimedia Group Traitement du Signal et Images/Signal and Image Processing Telecom ParisTech, 37-39 rue Dareau, 75014 Paris, France Tel: +33145817733 - Mob: +33677843843 - Fax: +33145817144
Re: WebTV Use Cases (was Re: [DRAFT] Web Intents Task Force Charter)
What is the exact problem with this document ? Best regards JC On 14/11/11 13:56 , Giuseppe Pascale wrote: On Mon, 14 Nov 2011 13:30:28 +0100, timeless timel...@gmail.com wrote: As sa note, that document is in violation of http://www.w3.org/Consortium/Translation/ The working language of the W3C is US English. The official version of a W3C document is the US English language version at the W3C site. So I fully expect it to change. I mean no significant changes as in new use cases or such. I also want to point out that this is the first document of this (new in W3C) group and is a collective effort, so we apologize if it doesn't follow W3C style/pubrules. As said, we are in the process of turning it into a W3C Note document, that also imply making it compliant with pubrules. cheers, /g On 11/14/11, Giuseppe Pascale giusep...@opera.com wrote: On Thu, 10 Nov 2011 17:01:51 +0100, Robin Berjon ro...@berjon.com wrote: Hi Rich, On Nov 10, 2011, at 16:27 , Rich Tibbett wrote: Opera would like to explore Local Device and Local Network Discovery as a subset of Web Intents. Yes, and that desire has been heard. As discussed last week, people interested in discovery need to bring their use cases to the intents TF so that we can figure out which just work, and for those that don't look at which of modifying intents or spawning a separate specification makes most sense. Let me add one thing on this point: if it wasn't clear from the joint F2F, the webtv IG have been discussing use cases for few months and collected them in a document that will be soon published as IG note. This document collects major use cases we are looking into. http://www.w3.org/2011/webtv/wiki/HNTF/Home_Network_TF_Requirements I'll send around the link to the final document once published, but note that NO changes are expected. /g -- Giuseppe Pascale TV Connected Devices Opera Software -- JC Dufourd Directeur d'Etudes/Professor Groupe Multimedia/Multimedia Group Traitement du Signal et Images/Signal and Image Processing Telecom ParisTech, 37-39 rue Dareau, 75014 Paris, France Tel: +33145817733 - Mob: +33677843843 - Fax: +33145817144
Re: Widgets PAG seeks feedback on Widget Updates spec
Marcos Caceres a écrit : From the spec ...an author can request that a widget asynchronously check if a widget has been updated [(i.e., that a new version of the widget package is available online)] via the widget.update() method, defined in the Widgets-API specification. This strategy also relies on the author having declared a update element in the widget configuration document, as it makes use of the URI to potentially retrieve an UDD and relay whether an update is available back to the instantiated Widget. ***Actually performing the update is left to the discretion of the widget user agent.*** JCD: this standards trick works if your aim is to have a patent on the highlighted point be judged as non-essential. There are a few points to check to ensure non-essentiality: - the language of the standard makes the feature a MAY (seems to be the case); - no test case uses the feature (should be easy too). However, if the implementations consistently implement the feature, they will infringe the patent and will get a call from the patent holder. It seems to me that this feature may end up as consistently implemented. There would then be a good case for the WG to spend some time on devising a proper workaround. Anyone sharing my opinion that the widget update feature will be consistenly implemented (even if optional) ? Best regards JC -- JC Dufourd Groupe Multimedia/Multimedia Group Traitement du Signal et Images/Signal and Image Processing Télécom ParisTech, 46 rue Barrault, 75 013 Paris, France
Re: Widgets PAG seeks feedback on Widget Updates spec
Dear Robin, Thanks for your email. Robin Berjon a écrit : There would then be a good case for the WG to spend some time on devising a proper workaround. Anyone sharing my opinion that the widget update feature will be consistenly implemented (even if optional) ? You seem to be mixing up Widget Updates and the update() method, is that the case? JCD: I understood the widget.update() method being discussed to be the scripted version of the Widget Updates mechanism. Please tell me if I am wrong. The current draft seems to still say that. And I am really not sure that a script-triggered version of the update mechanism can be discarded off-hand. Best regards JC PS: test sequences may be informative, but their content defines what is tested for normative behavior, so if a feature is tested in a sequence, it will appear normative to lawyers, even if the text of the spec says otherwise. -- JC Dufourd Groupe Multimedia/Multimedia Group Traitement du Signal et Images/Signal and Image Processing Télécom ParisTech, 46 rue Barrault, 75 013 Paris, France
Re: [widgets] [preference element] question on the value attribute
Robin Berjon a écrit : If by text content you mean actual text content, then there is no difference whatsoever between what can be stored in an attribute value and the text content (as per DOM 3 textContent) of an element — at least not semantically. JCD: I think I agree with you Robin, but Marcos writes something different. In the IDL, both are DOMStrings right ? Is there spec text limiting attributes ? I cannot find a If by text content you mean structured content, then we're talking about turning the preference system into an XML storage system since most XML constructs could appear there. JCD: Are you not contradicting yourself ? If the two are identical in storing possibilities, there should be no difference (if appropriate quoting of special characters is applied). Do you mind clarifying which one it is you are wondering about? JCD: It is indeed a question of allowing the users (users of widget spec = authors actually) to place anything in the value of a preference, including bits of XML or whatever that needs a CDATA section around it to fit in an XML file. To reformulate my current understanding, informed by your answer, using an attribute vs. the text content is equivalent in terms of which strings are allowed, but the attribute format is more difficult to express (because more intricate quoting is needed) than the text content. Is this clearer ? and am I correct in this last understanding ? Thanks JC -- JC Dufourd Groupe Multimedia/Multimedia Group Traitement du Signal et Images/Signal and Image Processing Télécom ParisTech, 46 rue Barrault, 75 013 Paris, France
[widgets] [preference element] question on the value attribute
We are wondering about the choice of an attribute to store the value of a preference. We would prefer to use the text content of the preference element for the value of the preference. Is there a good reason that we missed for using an attribute instead ? Thanks JC -- JC Dufourd Groupe Multimedia/Multimedia Group Traitement du Signal et Images/Signal and Image Processing Télécom ParisTech, 46 rue Barrault, 75 013 Paris, France
Re: [widgets] Widgets URI scheme... it's baaaack!
Arve Bersvendsen a écrit : The main issue here, I think, is one of being proactive on this front. Given that absolute URIs are required for resolution, and that UA vendors will, unless specified, have to pick a URI scheme of their own, the situation may well arise where they have specified something that would either be insecure (eg. file:), incompatible ( again, file:) or inappropriate (all schemes that fail to make query strings and fragment identifiers useful) JCD: I am unconfortable with such thinking that standards makers somehow know better than implementors (and I am a standard maker). This is a case where you would expose the problem in an informative part of the spec and propose (not mandate) a working solution to implementers. If it is not seen by the author, and not useful for interoperability, there is no reason to mandate a solution. Otherwise, you force extra technology on vendors, and that is a recipe for failing standards. Best regards JC PS: I agree with Thomas, but my tack is different. -- JC Dufourd Groupe Multimedia/Multimedia Group Traitement du Signal et Images/Signal and Image Processing Télécom ParisTech, 46 rue Barrault, 75 013 Paris, France
