Re: Minimum viable custom elements
Anne wrote: but do you see a viable way to get there? I don't have enough technical understanding to know what is viable or not, you and others are saying that the current accessibility feature support baked in to custom elements spec via is= is not acceptable To recap What is= provides: A way for developers take advantage of the built in roles,states and properties of existing HTML elements without having to add ARIA to reflect the acc properties and scripting to emulate behaviours (see what ARIA does not do http://www.paciellogroup.com/blog/2014/08/what-aria-does-not-do/) For example. putting aria-disabled=true on a button does not make the element disabled like the ‘disabled’ attribute does (removes from tab order etc), it just sets the disabled state flag in accessibility APIs. So being able to do: button is=”my-super-button” means that devs can take advantage of built-in focus and keyboard handling and built in states and properties (all of which have acc built-in where needed) - for example button related attributes. autofocus - Automatically focus the form control when the page is loaded disabled - Whether the form control is disabled form - Associates the control with a form element formaction - URL to use for form submission formenctype - Form data set encoding type to use for form submission formmethod - HTTP method to use for form submission formnovalidate - Bypass form control validation for form submission formtarget - Browsing context for form submission menu - Specifies the element's designated pop-up menu name - Name of form control to use for form submission and in the form.elements API type - Type of button value - Value to be used for form submission I think being able to extend existing elements has potential value to developers far beyond accessibility (it just so happens that accessibility is helped a lot by re-use of existing HTML features.) I am not married to the is= method, but am very concerned that custom elements without some useful method to leverage existing HTML features will make the accessibility support story for this new technology bleak and as much as I love ARIA it is accessibility that must be bolted on by the developer which is unfortunately prone to error and often left off. -- Regards SteveF On 16 January 2015 at 16:52, Anne van Kesteren ann...@annevk.nl wrote: On Fri, Jan 16, 2015 at 5:45 PM, Steve Faulkner faulkner.st...@gmail.com wrote: I have not suggested is= as the method that must be implemented (I have not demanded anything), what I have tried to suggest is that minimum viable custom elements with all accessibility as bolt-on is a poor solution by design. From an acc view it means custom elements are nothing more than divs with fancy names. Sure, I hope everyone understands that, Again, I think that unless we solve the styling problem for native elements, we're not going to see them adopted, not even if you can subclass them (and proper subclassing without the is= hack is another hard problem, as explained). -- https://annevankesteren.nl/
CfC: publish Wide Review Draft of Manifest for web application; deadline Feb 5
Marcos is working toward a Candidate Recommendation of Manifest for web application and before that step, we need to publish a Working Draft for Wide Review [WR] (a WR Draft is equivalent to a Last Call draft as defined in the consortium's 2005 Process). As such, this is a Call for Consensus to publish a new WR draft of this spec using the 2014 Process [PD-2014] and the proposed review period is three weeks. The latest Editor's Draft of the spec is: http://w3c.github.io/manifest/. If you have any comments or concerns about this CfC, please reply by February 5 at the latest. Silence will be considered as agreeing with the proposal and explicit responses are preferred. If no non-resolvable blocking issues are raised, this CfC will be considered as passing and we will proceed with the publication. Assuming this CfC passes, Marcos suggested the following groups be explicitly asked to review this spec: CSS WG - in particular, the display mode media feature, and WebAppSec WG. Please let us know if there are other groups we should ask to review the spec. -Thanks, ArtB [WR] http://www.w3.org/2014/Process-20140801/#wide-review [PD-2014] http://www.w3.org/2014/Process-20140801/#rec-advance
Custom elements and the HTML parser
I tried to explore the synchronous constructor option a bit more. (See https://wiki.whatwg.org/wiki/CustomElements for details.) From an HTML parser perspective the main problem would be that elements with a dash would have to go into the same path that is basically a special case for /script today. So the performance of the parser would suffer. It's unclear how much of a hit that would be. Only /script causes synchronous invocation of script. Otherwise script is invoked based on a timer or lack of incoming data from the network to process. This would change that as elements with a dash could cause synchronous invocation of script as well. This would give custom elements the same freedom as builtin elements. We could even add a hook for popping of the end tag so you can emulate the behavior of these elements: script, style, object, video, and audio. I don't think there's a way to do that with the alternative strategies. (I checked and Servo has no plans to parallelize tree building.) -- https://annevankesteren.nl/
Re: Minimum viable custom elements
On 29 January 2015 at 14:54, Steve Faulkner faulkner.st...@gmail.com wrote: I think being able to extend existing elements has potential value to developers far beyond accessibility (it just so happens that accessibility is helped a lot by re-use of existing HTML features.) I agree with everything Steve has said about accessibility. Extending existing elements also gives us progressive enhancement potential. Try https://rawgit.com/alice/web-components-demos/master/index.html in Safari or IE. The second column isn't functional because it's using brand new custom elements. The first column loses the web componenty sparkles but remains functional because it extends existing HTML elements. There's a similar story with Opera Mini, which is used by at least 250m people (and another potential 100m transitioning on Microsoft feature phones) because of its proxy architecture. Like Steve, I've no particularly affection (or enmity) towards the input type=radio is=luscious-radio syntax. But I'd like to know, if it's dropped, how progressive enhancement can be achieved so we don't lock out users of browsers that don't have web components capabilities, JavaScript disabled or proxy browsers. If there is a concrete plan, please point me to it. If there isn't, it's irresponsible to drop a method that we can see working in the example above with nothing else to replace it. I also have a niggling worry that this may affect the uptake of web components. When I led a dev team for a large UK legal site, there's absolutely no way we could have used a technology that was non-functional in older/proxy browsers. bruce
Re: Minimum viable custom elements
One additional point, unrelated to accessibility: is also enables piggybacking to special parser behavior of existing elements. For example, I can extend template or link. Here are some examples: http://jsbin.com/xuheb/3/edit?html,output https://blog.polymer-project.org/howto/2014/09/11/template-is-autobinding/ :DG On Thu, Jan 29, 2015 at 7:33 AM, Bruce Lawson bru...@opera.com wrote: On 29 January 2015 at 14:54, Steve Faulkner faulkner.st...@gmail.com wrote: I think being able to extend existing elements has potential value to developers far beyond accessibility (it just so happens that accessibility is helped a lot by re-use of existing HTML features.) I agree with everything Steve has said about accessibility. Extending existing elements also gives us progressive enhancement potential. Try https://rawgit.com/alice/web-components-demos/master/index.html in Safari or IE. The second column isn't functional because it's using brand new custom elements. The first column loses the web componenty sparkles but remains functional because it extends existing HTML elements. There's a similar story with Opera Mini, which is used by at least 250m people (and another potential 100m transitioning on Microsoft feature phones) because of its proxy architecture. Like Steve, I've no particularly affection (or enmity) towards the input type=radio is=luscious-radio syntax. But I'd like to know, if it's dropped, how progressive enhancement can be achieved so we don't lock out users of browsers that don't have web components capabilities, JavaScript disabled or proxy browsers. If there is a concrete plan, please point me to it. If there isn't, it's irresponsible to drop a method that we can see working in the example above with nothing else to replace it. I also have a niggling worry that this may affect the uptake of web components. When I led a dev team for a large UK legal site, there's absolutely no way we could have used a technology that was non-functional in older/proxy browsers. bruce
Re: Minimum viable custom elements
On Thu, Jan 29, 2015 at 3:54 PM, Steve Faulkner faulkner.st...@gmail.com wrote: I don't have enough technical understanding to know what is viable or not, you and others are saying that the current accessibility feature support baked in to custom elements spec via is= is not acceptable That seems rather disingenuous. I have said these things: 1) Compared to my-element the is= construct is a hack that is unlikely to be attractive to those building libraries. Existing libraries seem to support this. 2) As long as the styling problem for form controls remains unsolved, making some form of automatic prototype mutation work for them is not going to get them adoption. Others have already explained how turning 1) around is hard as browsers, specifications, and stylesheets branch on local name rather than instance checks. 2) is even harder and has always been the real problem. -- https://annevankesteren.nl/
Re: Minimum viable custom elements
I don't have enough technical understanding to know what is viable or not, you and others are saying that the current accessibility feature support baked in to custom elements spec via is= is not acceptable That seems rather disingenuous. where am I being disingenuous? I don't understand how the various pieces are pulled together to make an element work in browsers to an extent to be able to offer possible technical solutions. If I did I would. -- Regards SteveF HTML 5.1 http://www.w3.org/html/wg/drafts/html/master/ On 29 January 2015 at 15:37, Anne van Kesteren ann...@annevk.nl wrote: On Thu, Jan 29, 2015 at 3:54 PM, Steve Faulkner faulkner.st...@gmail.com wrote: I don't have enough technical understanding to know what is viable or not, you and others are saying that the current accessibility feature support baked in to custom elements spec via is= is not acceptable That seems rather disingenuous. I have said these things: 1) Compared to my-element the is= construct is a hack that is unlikely to be attractive to those building libraries. Existing libraries seem to support this. 2) As long as the styling problem for form controls remains unsolved, making some form of automatic prototype mutation work for them is not going to get them adoption. Others have already explained how turning 1) around is hard as browsers, specifications, and stylesheets branch on local name rather than instance checks. 2) is even harder and has always been the real problem. -- https://annevankesteren.nl/
Re: Minimum viable custom elements
On Fri, Jan 30, 2015 at 3:52 AM, Brian Kardell bkard...@gmail.com wrote: On Thu, Jan 29, 2015 at 10:33 AM, Bruce Lawson bru...@opera.com wrote: On 29 January 2015 at 14:54, Steve Faulkner faulkner.st...@gmail.com wrote: I think being able to extend existing elements has potential value to developers far beyond accessibility (it just so happens that accessibility is helped a lot by re-use of existing HTML features.) I agree with everything Steve has said about accessibility. Extending existing elements also gives us progressive enhancement potential. Try https://rawgit.com/alice/web-components-demos/master/index.html in Safari or IE. The second column isn't functional because it's using brand new custom elements. The first column loses the web componenty sparkles but remains functional because it extends existing HTML elements. There's a similar story with Opera Mini, which is used by at least 250m people (and another potential 100m transitioning on Microsoft feature phones) because of its proxy architecture. Like Steve, I've no particularly affection (or enmity) towards the input type=radio is=luscious-radio syntax. But I'd like to know, if it's dropped, how progressive enhancement can be achieved so we don't lock out users of browsers that don't have web components capabilities, JavaScript disabled or proxy browsers. If there is a concrete plan, please point me to it. If there isn't, it's irresponsible to drop a method that we can see working in the example above with nothing else to replace it. I also have a niggling worry that this may affect the uptake of web components. When I led a dev team for a large UK legal site, there's absolutely no way we could have used a technology that was non-functional in older/proxy browsers. bruce Humor me for a moment while I recap some historical arguments/play devil's advocate here. One conceptual problem I've always had with the is= form is that it adds some amount of ambiguity for authors and makes it plausible to author non-sense. It's similar to the problem of aria being bolt on with mix and match attributes. With the imperative form of extending you wind up with a tag name that definitely is defined as subclassing something super-button 'inherits' from HTMLButtonElement and I'll explain how it's different. With the declarative attribute form you basically have to manage 3 things: ANY tag, the base class and the final definition. This means it's possible to do things like iframe is=button which likely won't work. Further, you can then proceed to define something which is clearly none-of-the-above. The is@ only works on the element you defined it to apply to, so iframe is=button does nothing unless the element button was registered as a type extension to iframe. I don't see that as any more error prone than writing paper-buton instead of paper-button. Also fwiw most share buttons on the web are actually iframes, so iframe is=facebook-button makes total sense. - E
Re: Minimum viable custom elements
On Thu, Jan 29, 2015 at 1:50 PM, Elliott Sprehn espr...@chromium.org wrote: On Fri, Jan 30, 2015 at 3:52 AM, Brian Kardell bkard...@gmail.com wrote: On Thu, Jan 29, 2015 at 10:33 AM, Bruce Lawson bru...@opera.com wrote: On 29 January 2015 at 14:54, Steve Faulkner faulkner.st...@gmail.com wrote: I think being able to extend existing elements has potential value to developers far beyond accessibility (it just so happens that accessibility is helped a lot by re-use of existing HTML features.) I agree with everything Steve has said about accessibility. Extending existing elements also gives us progressive enhancement potential. Try https://rawgit.com/alice/web-components-demos/master/index.html in Safari or IE. The second column isn't functional because it's using brand new custom elements. The first column loses the web componenty sparkles but remains functional because it extends existing HTML elements. There's a similar story with Opera Mini, which is used by at least 250m people (and another potential 100m transitioning on Microsoft feature phones) because of its proxy architecture. Like Steve, I've no particularly affection (or enmity) towards the input type=radio is=luscious-radio syntax. But I'd like to know, if it's dropped, how progressive enhancement can be achieved so we don't lock out users of browsers that don't have web components capabilities, JavaScript disabled or proxy browsers. If there is a concrete plan, please point me to it. If there isn't, it's irresponsible to drop a method that we can see working in the example above with nothing else to replace it. I also have a niggling worry that this may affect the uptake of web components. When I led a dev team for a large UK legal site, there's absolutely no way we could have used a technology that was non-functional in older/proxy browsers. bruce Humor me for a moment while I recap some historical arguments/play devil's advocate here. One conceptual problem I've always had with the is= form is that it adds some amount of ambiguity for authors and makes it plausible to author non-sense. It's similar to the problem of aria being bolt on with mix and match attributes. With the imperative form of extending you wind up with a tag name that definitely is defined as subclassing something super-button 'inherits' from HTMLButtonElement and I'll explain how it's different. With the declarative attribute form you basically have to manage 3 things: ANY tag, the base class and the final definition. This means it's possible to do things like iframe is=button which likely won't work. Further, you can then proceed to define something which is clearly none-of-the-above. The is@ only works on the element you defined it to apply to, so iframe is=button does nothing unless the element button was registered as a type extension to iframe. I don't see that as any more error prone than writing paper-buton instead of paper-button. In other words, if there are 350 elements in HTML - in 349 you could say is=button and it would do nothing. This isn't possible with the pure tag form, it either is or isn't the tag. This is all I described - ambiguity for authors and ability to author nonsense. Maybe it is 'benign' nonsense but it's nonsense and potentially frustrating in a way that misspelling a tag isn't IMO. Also fwiw most share buttons on the web are actually iframes, so iframe is=facebook-button makes total sense. youre somewhat locked into thinking that because it's how we've dealt with things, don't you think? I mean button is=iframe might conceptually work too, but we know that they're iframes for SOP/isolation reasons. That said, what exactly would you add to your custom element facebook-button that adds value then? ... Like... what could you legitimately do with that that you couldn't do with iframe class=facebook-button? Would it actually submit a form in *your* page, would your focus act the same, etc? I'm asking for real because I think the use-cases are on the small end of limited I'm not saying it's better or worse, I'm actually trying to take the devils advocate position here because there might be something beneath it worth thinking about... It does seem that composition actually seems to let you express something equally good without ambiguity more easily except insofar as giving you a really first-class fallback option if you don't support JS, but... I'm having a really hard time imagining more than 3-4 cases where that's really a useful thing. - E -- Brian Kardell :: @briankardell :: hitchjs.com
Re: Minimum viable custom elements
On 29 January 2015 at 19:09, Brian Kardell bkard...@gmail.com wrote: composition actually seems to let you express something equally good without ambiguity more easily except insofar as giving you a really first-class fallback option if you don't support JS, but... I'm having a really hard time imagining more than 3-4 cases where that's really a useful thing. I'm thinking of all the HTML elements that people feel compelled to recreate with div soup and JS (some of this is because the CSS hooks don't exist, but I doubt we could ever define all conceivable CSS hooks, but that's another story). The canonical example is button but input type=date is=fab-calendar ; input type=range is=rotary-knob; input type=checkbox is=woot-checkbox !-- OMG the checkmark spills outside the box and it's in corporate magenta and indigo! -- All of these degrade very nicely and work even when JS isn't present, whereas woot-checkbox and fab-calendar don't. I'd also very much like to do nav is=glorious-accordian etc. a really first-class fallback option if you don't support JS is vital for the quarter of a billion people who use Opera Mini and the 100 million people who use the Nokia proxy browser. Fallback rather than non-functional pages is vital for the people who don't use latest greatest Chromium or Gecko browsers. Sure, not everyone will do this. But not everyone puts alt text on images; that's not an argument for removing img alt from the platform. b
Re: Minimum viable custom elements
On Jan 29, 2015, at 7:52 AM, Steve Faulkner faulkner.st...@gmail.com wrote: On 29 January 2015 at 15:37, Anne van Kesteren ann...@annevk.nl mailto:ann...@annevk.nl wrote: I don't have enough technical understanding to know what is viable or not, you and others are saying that the current accessibility feature support baked in to custom elements spec via is= is not acceptable That seems rather disingenuous. where am I being disingenuous? I don't understand how the various pieces are pulled together to make an element work in browsers to an extent to be able to offer possible technical solutions. If I did I would. I think there is a bit of miscommunication here. Correct me if I'm wrong but I think you're trying to fix the problem of Web developers writing their own UI widgets and components and they're often inaccessible because they didn't set ARIA roles right, etc… If that's the problem you're trying to solve here, then what you need is shadow DOM, not custom elements. As someone who cares about accessibility deeply, I want to solve this problem too. However, like Anne pointed out in earlier threads, authors aren't going to start using custom elements to implement those fancy UI widgets currently implemented via div's and span's using is=~ attribute since custom elements doesn't provide any mechanism to change the appearance of a builtin element. Shadow DOM, on the other hand, is one proposed mechanism to replace the appearance of a builtin element by way of replacing the contents of the element via a shadow tree. Now, if we're using shadow DOM to change the appearance of a builtin element, then choosing which appearance to use in the HTML markup via a content attribute is a layering violation. We should be doing that in CSS instead. And we have a proposal to do both of these things: decorators [1] One more thing. I would really like if we could stop making claims such as web components as currently spec'ed magically improves accessibility because it's doing a huge disservice to the future of the Web accessibility. They don't. Far from it. I've pointed out numerous issues with them over the last couple of years but none of them have been adequately addressed. [1] https://dvcs.w3.org/hg/webcomponents/raw-file/57f8cfc4a7dc/explainer/index.html#decorator-section - R. Niwa
Security use cases for packaging
Hi all, looking over the W3C TAG packaging draft [1], I would like to see security through package signing as a use case for packaging. A hypothetical scenario using Google/Yahoo's End to End email encryption project: 1. User goes to https://cryptomail.yahoo.com/app.pack for the first time. The HTTP response header includes a package signing key for that resource. This key is pinned, like in HPKP, for some max-age. (The key could also just be included as part of the package.) 2. The browser verifies the signature over app.pack (perhaps as a special signature part in the package body, as in PGP/MIME) using the pinned key for that resource. 3. The packaged app only runs if signature verification succeeds. Verification using the same pinned key is enforced for the max-age amount of time whenever the user loads the package in the future. The context here is that some app authors would like to provide better code integrity guarantees via signing with an offline key. This can be achieved by writing a browser extension or certain types of installable apps, but those have various disadvantages (lack of cross-browser compatibility and dependency on a central app store, for instance). More considerations in the github issue I opened: https://github.com/w3ctag/packaging-on-the-web/issues/21 Thoughts? -Yan [1] https://w3ctag.github.io/packaging-on-the-web/
Re: Security use cases for packaging
chris palmer wrote: But other code from the same origin might not be signed, which could break the security assertion of code signing. Maybe the code from the downloaded package has to be run from a local origin like chrome://*.
Re: Security use cases for packaging
Paging (future Dr.) Deian Stefan to the ER... Any thoughts on using COWL for this kind of thing, with a pinned crypto key as a confinement label to be combined with the regular Origin label? -Brad On Thu Jan 29 2015 at 1:43:05 PM Yan Zhu y...@yahoo-inc.com wrote: chris palmer wrote: But other code from the same origin might not be signed, which could break the security assertion of code signing. Maybe the code from the downloaded package has to be run from a local origin like chrome://*.
Re: Minimum viable custom elements
On Thu, Jan 29, 2015 at 2:43 PM, Bruce Lawson bru...@opera.com wrote: [snip] a really first-class fallback option if you don't support JS is vital for the quarter of a billion people who use Opera Mini and the 100 million people who use the Nokia proxy browser. Fallback rather than non-functional pages is vital for the people who don't use latest greatest Chromium or Gecko browsers. b But in the context of custom elements (not shadow dom) these should be able to do 'createdCallback' etc on the server... I can't really see any reason why they couldn't/wouldn't. -- Brian Kardell :: @briankardell :: hitchjs.com
Re: Security use cases for packaging
But other code from the same origin might not be signed, which could break the security assertion of code signing. The unit of signing should be the same as the unit of isolation, i.e. the origin. Or, the origin should be expanded to include a 4th element, the signing key(s). I don't know how to achieve that in a way that does not bring with it the operational risks (bricking) of HPKP and TACK.
Re: Security use cases for packaging
Maybe the code from the downloaded package has to be run from a local origin like chrome://*. Doesn't the same issue that Chris raised still exist? You need a unit of isolation that says only code signed with this public key runs in this isolation compartment. Chrome extensions have that model. Whether we achieve this via origins, COWLs, or origin+key as the identifier, is a separate question, but Chris' high level bit remains true. cheers dev
Re: Security use cases for packaging
Brad Hill hillb...@gmail.com writes: Paging (future Dr.) Deian Stefan to the ER... Any thoughts on using COWL for this kind of thing, with a pinned crypto key as a confinement label to be combined with the regular Origin label? Thanks for paging me! I've thought about something like this---providing some form of code integrity---in the context of COWL as well. The idea was to grant a worker the privilege corresponding to the (hash of the) source, in addition to its origin. This would allow a server to verify if the code it is communicating with is trustworthy. (COWL labels are not limited to origins.) I really like Yan's use case. And I think it fits in pretty naturally with COWL: the app, if verification succeeds, can be granted the privilege corresponding to the (hash of the) crypto key: Privilege(https://cryptomail.yahoo.com).and(app-key:...). Other code from the same origin would only have Privilege(https://cryptomail.yahoo.com). I think this may partly address Chris and Dev's concerns. But deciding when not to run the app code is still a question. Though I think the github issue already brings this up. Deian
Re: Security use cases for packaging
devdatta wrote: Maybe the code from the downloaded package has to be run from a local origin like chrome://*. Doesn't the same issue that Chris raised still exist? You need a unit of isolation that says only code signed with this public key runs in this isolation compartment. Chrome extensions have that model. Whether we achieve this via origins, COWLs, or origin+key as the identifier, is a separate question, but Chris' high level bit remains true. thanks, I meant a unique local (pseudo-)origin assigned to the downloaded package. Chrome extensions derive it purely from the public signing key IIRC; seems like that would suffice here too. ilya wrote: Would it be possible to meet the security goals without assuming that the response body is part of the package? See [1] for background on why that's beneficial.. at least for performance side of the story. I'm picturing a package description where each resource has a SRI token, plus a signature to authenticate the tree of resources / package description itself? A signed manifest-like package description that lists the hash and location of every resource seems fine as long as all the resources are downloaded and verified before running the app. Perhaps this kills some of the performance benefits motivating packaging in the first place. :(
Re: Security use cases for packaging
Would it be possible to meet the security goals without assuming that the response body is part of the package? See [1] for background on why that's beneficial.. at least for performance side of the story. I'm picturing a package description where each resource has a SRI token, plus a signature to authenticate the tree of resources / package description itself? [1] http://lists.w3.org/Archives/Public/public-web-perf/2015Jan/0008.html On Fri, Jan 30, 2015 at 9:27 AM, Devdatta Akhawe dev.akh...@gmail.com wrote: Maybe the code from the downloaded package has to be run from a local origin like chrome://*. Doesn't the same issue that Chris raised still exist? You need a unit of isolation that says only code signed with this public key runs in this isolation compartment. Chrome extensions have that model. Whether we achieve this via origins, COWLs, or origin+key as the identifier, is a separate question, but Chris' high level bit remains true. cheers dev
Re: Security use cases for packaging
On Thu 2015-01-29 20:14:59 -0500, Yan Zhu wrote: A signed manifest-like package description that lists the hash and location of every resource seems fine as long as all the resources are downloaded and verified before running the app. Perhaps this kills some of the performance benefits motivating packaging in the first place. :( Why would you need to fetch all the pieces before running the app? Consider a manifest includes an integrity check covering resources X, Y, and Z, but X is the only bit of code that runs first, and Y and Z aren't loaded. If you can validate the manifest, then you know you only run X if you've verified the manifest and X's integrity. If the user triggers an action that requires resource Y, then you fetch it but don't use it unless it matches the integrity check. (i haven't developed webapps myself for ages, and the idea of a signed webapp is relatively new to me, so feel free to explain any obvious part that i'm missing) --dkg signature.asc Description: PGP signature
Re: Security use cases for packaging
packaging and complicated signing is routine for most installable web apps and browser extensions; see https://developer.mozilla.org/en-US/docs/Signing_a_XPI for instance. Developers who build those might actually want the process to be less complicated. Given that the packaging spec lists installable web apps as a use case, it should probably define a signature format. -Yan On Thursday, January 29, 2015 7:12 PM, Michaela Merz michaela.m...@hermetos.com wrote: Pardon my french, but the whole idea is ridiculous. Web development is fluid and flexible. While I most certainly understand the idea and the need for secured loadable code (AFAIK I brought up this issue about 2 months ago), packaging and complicated signing is counter productive. What about external scripts like jquery? Do I really need to download a complete package because I fixed a stupid typo in one of the scripts? Maybe I am completely on the wrong track here (please correct me if I am) - but I think signed code should be handled completely different - thus preserving the flexibility of the LAMP/Script environment as we know it. Michaela On 01/30/2015 03:22 AM, Daniel Kahn Gillmor wrote: On Thu 2015-01-29 20:14:59 -0500, Yan Zhu wrote: A signed manifest-like package description that lists the hash and location of every resource seems fine as long as all the resources are downloaded and verified before running the app. Perhaps this kills some of the performance benefits motivating packaging in the first place. :( Why would you need to fetch all the pieces before running the app? Consider a manifest includes an integrity check covering resources X, Y, and Z, but X is the only bit of code that runs first, and Y and Z aren't loaded. If you can validate the manifest, then you know you only run X if you've verified the manifest and X's integrity. If the user triggers an action that requires resource Y, then you fetch it but don't use it unless it matches the integrity check. (i haven't developed webapps myself for ages, and the idea of a signed webapp is relatively new to me, so feel free to explain any obvious part that i'm missing) --dkg
Re: Security use cases for packaging
On Thursday, January 29, 2015 6:25 PM, Daniel Kahn Gillmor d...@fifthhorseman.net wrote: On Thu 2015-01-29 20:14:59 -0500, Yan Zhu wrote: A signed manifest-like package description that lists the hash and location of every resource seems fine as long as all the resources are downloaded and verified before running the app. Perhaps this kills some of the performance benefits motivating packaging in the first place. :( Why would you need to fetch all the pieces before running the app? Consider a manifest includes an integrity check covering resources X, Y, and Z, but X is the only bit of code that runs first, and Y and Z aren't loaded. If you can validate the manifest, then you know you only run X if you've verified the manifest and X's integrity. If the user triggers an action that requires resource Y, then you fetch it but don't use it unless it matches the integrity check. Say that resource Y is a javascript file that listens for users typing in password fields and shows them a warning if the password is weak. The user verifies and loads the HTML page that includes Y but an attacker then blocks the request to fetch Y, so the user picks a weak password. My intuition is that most developers think about the security of their app as a whole, not the security of their app minus any-given-subset-of-resources.
Re: Security use cases for packaging
Pardon my french, but the whole idea is ridiculous. Web development is fluid and flexible. While I most certainly understand the idea and the need for secured loadable code (AFAIK I brought up this issue about 2 months ago), packaging and complicated signing is counter productive. What about external scripts like jquery? Do I really need to download a complete package because I fixed a stupid typo in one of the scripts? Maybe I am completely on the wrong track here (please correct me if I am) - but I think signed code should be handled completely different - thus preserving the flexibility of the LAMP/Script environment as we know it. Michaela On 01/30/2015 03:22 AM, Daniel Kahn Gillmor wrote: On Thu 2015-01-29 20:14:59 -0500, Yan Zhu wrote: A signed manifest-like package description that lists the hash and location of every resource seems fine as long as all the resources are downloaded and verified before running the app. Perhaps this kills some of the performance benefits motivating packaging in the first place. :( Why would you need to fetch all the pieces before running the app? Consider a manifest includes an integrity check covering resources X, Y, and Z, but X is the only bit of code that runs first, and Y and Z aren't loaded. If you can validate the manifest, then you know you only run X if you've verified the manifest and X's integrity. If the user triggers an action that requires resource Y, then you fetch it but don't use it unless it matches the integrity check. (i haven't developed webapps myself for ages, and the idea of a signed webapp is relatively new to me, so feel free to explain any obvious part that i'm missing) --dkg
