Re: Security use cases for packaging
On Fri 2015-01-30 01:50:43 -0500, Yan Zhu wrote: 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. I see what you're saying -- and javascript that is directly embedded in the app would all definitely need to be loaded first (since we don't know how it would affect the rest of the application). I was thinking of other resources that might be invoked or loaded later, via XHR or dynamic script load other requests. I suppose the question then arises of what to do if the app triggers an XHR or dynamic script load for a piece of signed content, and that signed content can't be fetched, the entire application would have to block or something to avoid the scenario you describe. That kind of UX doesn't sound very web-like :/ --dkg
Re: Minimum viable custom elements
On Fri, Jan 30, 2015 at 11:05 AM, Steve Faulkner faulkner.st...@gmail.com wrote: In this radio and checkbox example (view in chrome) https://rawgit.com/alice/web-components-demos/master/index.html (which has been referenced several times in this thread, but no one has critiqued to my knowledge) all of the above are evident, while at the same time appearing to overcome the issue of standard control fugliness The only way it overcomes that is by relying on a proprietary extension called -webkit-appearance that is not standardized and does not work reliably across browsers. Furthermore, it's not at all clear to me why that example needs custom elements to begin with. If we assume this proprietary extension exists, we can just do this: http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=3397 Which is much much simpler and requires none of the HTML imports, shadow tree, and all that script. It's also fully accessible and backwards compatible to the same extent. And shows that the real tidbit here is -webkit-appearance and not custom elements at all. (For identical styling you need to move the background-image line into a distinct input:checked selector block. I messed up a bit with copy and pasting.) -- https://annevankesteren.nl/
Re: Security use cases for packaging
On Thu, Jan 29, 2015 at 10:50 PM, Yan Zhu y...@yahoo-inc.com wrote:
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.
The application developer could cope with this in the top-layer code:
===
script
var passwordChecker = null;
...
/script
script src=password-checker.js/script
script
if (null == passwordChecker) {
// handle failure of security dependency
}
/script
===
Just as a native application developer should do:
===
void* passwordChecker = dlopen(password-checker.so, ...);
if (NULL == passwordChecker) {
// handle failure of security dependency
}
===
But,
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.
You're probably right, about both web developers and native code developers.
But, if we provide a declarative interface for the package format that
allows developers to declare that a given dependency should be
pre-loaded when possible and mandatorily pre-loaded, they might be
more likely to use that than to write the tedious error-handling code
like that above. I.e. we can create good affordances, and thus get the
benefits of security and performance most of the time.
Re: Minimum viable custom elements
On Jan 30, 2015, at 10:22 AM, Alice Boxhall aboxh...@google.com wrote: On Fri, Jan 30, 2015 at 8:46 AM, Anne van Kesteren ann...@annevk.nl mailto:ann...@annevk.nl wrote: On Fri, Jan 30, 2015 at 11:05 AM, Steve Faulkner faulkner.st...@gmail.com mailto:faulkner.st...@gmail.com wrote: In this radio and checkbox example (view in chrome) https://rawgit.com/alice/web-components-demos/master/index.html https://rawgit.com/alice/web-components-demos/master/index.html (which has been referenced several times in this thread, but no one has critiqued to my knowledge) all of the above are evident, while at the same time appearing to overcome the issue of standard control fugliness The only way it overcomes that is by relying on a proprietary extension called -webkit-appearance that is not standardized and does not work reliably across browsers. Furthermore, it's not at all clear to me why that example needs custom elements to begin with. If we assume this proprietary extension exists, we can just do this: http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=3397 http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=3397 Which is much much simpler and requires none of the HTML imports, shadow tree, and all that script. It's also fully accessible and backwards compatible to the same extent. And shows that the real tidbit here is -webkit-appearance and not custom elements at all. (For identical styling you need to move the background-image line into a distinct input:checked selector block. I messed up a bit with copy and pasting.) Sure, that works for this example (which was created in a huge rush at the last minute before a talk, like probably 90% of my productive work), but I don't believe it wouldn't work for http://www.polymer-project.org/components/paper-radio-button/demo.html http://www.polymer-project.org/components/paper-radio-button/demo.html which has a fancy animation for changing states. It doesn’t but how does custom elements solve that problem? This example doesn’t even seem to use “is” and manually sets ARIA attributes. Could you clarify exactly which accessibility issues custom elements would solve in this example? So, I naively ask, what's stopping us from standardising something like -webkit-appearance: none? I think that a bunch of the most common accessibility issues we see today come from people (quite justifiably) re-implementing standard HTML elements in order to get the styling they need - with or without using Custom Elements. Indeed. It would be really useful to solve this problem either with a CSS property like -webkit-appearance or decorator. Perhaps Tantek or Fantasai could enlighten us. Relevant URLs: https://www.w3.org/Search/Mail/Public/search?type-index=www-styleindex-type=tkeywords=appearancesearch=Search https://www.w3.org/Search/Mail/Public/search?type-index=www-styleindex-type=tkeywords=appearancesearch=Search https://lists.w3.org/Archives/Public/www-style/2014Jul/0334.html https://lists.w3.org/Archives/Public/www-style/2014Jul/0334.html https://lists.w3.org/Archives/Public/www-style/2014Feb/0459.html https://lists.w3.org/Archives/Public/www-style/2013Feb/0625.html - R. Niwa
Re: Minimum viable custom elements
On 01/30/2015 07:54 PM, Ryosuke Niwa wrote: On Jan 30, 2015, at 10:22 AM, Alice Boxhall aboxh...@google.com mailto:aboxh...@google.com wrote: The only way it overcomes that is by relying on a proprietary extension called -webkit-appearance that is not standardized and does not work reliably across browsers. Furthermore, it's not at all clear to me why that example needs custom elements to begin with. If we assume this proprietary extension exists, we can just do this: http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=3397 [...] So, I naively ask, what's stopping us from standardising something like -webkit-appearance: none? I think that a bunch of the most common accessibility issues we see today come from people (quite justifiably) re-implementing standard HTML elements in order to get the styling they need - with or without using Custom Elements. -webkit-appearance: none isn't a proprietary extension, it's a prefixed version of something that was once in a standards-track document. It got removed because there were serious design problems with the original idea, but some values stuck around. Indeed. It would be really useful to solve this problem either with a CSS property like -webkit-appearance or decorator. Perhaps Tantek or Fantasai could enlighten us. Relevant URLs: https://www.w3.org/Search/Mail/Public/search?type-index=www-styleindex-type=tkeywords=appearancesearch=Search https://lists.w3.org/Archives/Public/www-style/2014Jul/0334.html https://lists.w3.org/Archives/Public/www-style/2014Feb/0459.html https://lists.w3.org/Archives/Public/www-style/2013Feb/0625.html I think you caught the important points right there. Tantek and Florian are actively working on updating the CSS3 UI draft right now, so this might come up at the CSSWG f2f in a couple weeks. ~fantasai
Re: Minimum viable custom elements
I'm tracking the state of requests for 'appearance' here: https://wiki.csswg.org/spec/css4-ui#appearance Feel free to directly edit that wiki page and add more concrete data / research that you think will help make a decision in terms of design etc. For now, there is insufficient data to show anyhing of any reasonable interop for this property, hence it is still postponed at best. Thanks, Tantek tags: [css-ui] [css3-ui] [cssui] On Fri, Jan 30, 2015 at 8:58 PM, fantasai fantasai.li...@inkedblade.net wrote: On 01/30/2015 07:54 PM, Ryosuke Niwa wrote: On Jan 30, 2015, at 10:22 AM, Alice Boxhall aboxh...@google.com mailto:aboxh...@google.com wrote: The only way it overcomes that is by relying on a proprietary extension called -webkit-appearance that is not standardized and does not work reliably across browsers. Furthermore, it's not at all clear to me why that example needs custom elements to begin with. If we assume this proprietary extension exists, we can just do this: http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=3397 [...] So, I naively ask, what's stopping us from standardising something like -webkit-appearance: none? I think that a bunch of the most common accessibility issues we see today come from people (quite justifiably) re-implementing standard HTML elements in order to get the styling they need - with or without using Custom Elements. -webkit-appearance: none isn't a proprietary extension, it's a prefixed version of something that was once in a standards-track document. It got removed because there were serious design problems with the original idea, but some values stuck around. Indeed. It would be really useful to solve this problem either with a CSS property like -webkit-appearance or decorator. Perhaps Tantek or Fantasai could enlighten us. Relevant URLs: https://www.w3.org/Search/Mail/Public/search?type-index=www-styleindex-type=tkeywords=appearancesearch=Search https://lists.w3.org/Archives/Public/www-style/2014Jul/0334.html https://lists.w3.org/Archives/Public/www-style/2014Feb/0459.html https://lists.w3.org/Archives/Public/www-style/2013Feb/0625.html I think you caught the important points right there. Tantek and Florian are actively working on updating the CSS3 UI draft right now, so this might come up at the CSSWG f2f in a couple weeks. ~fantasai
[Bug 27931] New: Override 'flex' and 'transform' styling
https://www.w3.org/Bugs/Public/show_bug.cgi?id=27931
Bug ID: 27931
Summary: Override 'flex' and 'transform' styling
Product: WebAppsWG
Version: unspecified
Hardware: PC
OS: All
Status: NEW
Severity: normal
Priority: P2
Component: Fullscreen
Assignee: ann...@annevk.nl
Reporter: ann...@annevk.nl
QA Contact: public-webapps-bugzi...@w3.org
CC: fal...@chromium.org, m...@w3.org, phil...@opera.com,
public-webapps@w3.org, r...@ocallahan.org,
sim...@opera.com
The conclusion from
https://lists.w3.org/Archives/Public/www-style/2014Nov/thread.html#msg287 seems
to be that the rendering section should override 'flex' and 'transform'.
Presumably as follows:
*|*:not(:root):fullscreen {
flex:none !important;
transform:none !important;
}
If anyone disagrees with this now would be a good time to speak up.
--
You are receiving this mail because:
You are on the CC list for the bug.
Re: =[xhr]
Hi, Thank you for your feedback. Please see the archives for previous iterations of this discussion, e.g. https://lists.w3.org/Archives/Public/public-webapps/2014JulSep/0084.html (and click next in thread). On 29.01.2015 21:04, LOUIFI, Bruno wrote: Hi, I am really disappointed when I saw in Chrome debugger that the XMLHttpRequest.open() is deprecating the synchronous mode. This is was the worst news I red since I started working on web applications. I don’t know if you release the negative impacts on our professional applications. We made a huge effort creating applications on the web and also providing JavaScript APIs that behave as Java APIs in order to help developers migrating from java to JavaScript technology. So please reconsider your decision. Our customers use APIs for their professional business. You don’t have right to break their applications. Regards, Bruno Louifi Senior Software Developer
Re: Minimum viable custom elements
On 29 January 2015 at 19:48, Ryosuke Niwa rn...@apple.com wrote: And we have a proposal to do both of these things: decorators [1] yes, indeed. What is the status of decorators? Last I looked, it had been removed from the web components umbrella, so I thought it had been sent to a farm upstate, but I haven't been following its progress particularly closely. 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. I'm not certain anyone has made the claim that anything's magically improved ... 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. could you provide a pointer to them, please? bruce
=[xhr]
Hi, I am really disappointed when I saw in Chrome debugger that the XMLHttpRequest.open() is deprecating the synchronous mode. This is was the worst news I red since I started working on web applications. I don't know if you release the negative impacts on our professional applications. We made a huge effort creating applications on the web and also providing JavaScript APIs that behave as Java APIs in order to help developers migrating from java to JavaScript technology. So please reconsider your decision. Our customers use APIs for their professional business. You don't have right to break their applications. Regards, Bruno Louifi Senior Software Developer
