Re: [whatwg] Proposal: Specify SHA512 hash of JavaScript files in
Sorry for the late response. Igor Minar, 2014-02-05 03:08 (Europe/Helsinki): I've been in discussions in the past where developers expressed concerns about inability to verify that the bits delivered from CDN were the same bits as the ones they reviewed and tested against during development. It's very common to pull popular libraries (like jquery, angular, underscore, bootstrap, etc) from a CDN, while delivering the html, css and app specific bits from a different server. In this scenario the developer has to blindly trust the CDN provider to disallow any kind of modification of the bits. From what I read this is the reason why financial and healthcare apps can't use 3rd party CDNs at all. I understand the problem and I have hit the same issue by myself. However, the suggested hash signature is far from enough. Most popular libraries have means to load additional files and plugins and the suggested hash is able to "sign" only the main file. If you cannot trust the CDN provider, you cannot trust that the rest of the files have not been modified. An attacker could use *any* file in the CDN network for an attack. If your signature cannot cover *all* files, adding the signature is wasted effort. There's no need to provide any additional tools for false sense of security. In addition, financial and healthcare apps may have to deal with rules set by local laws in addition stuff required by strict minimum for mathematically sound encryption. As a result, such apps may have to distribute copies of all the libraries by themselves in the future, too, regardless of any signature support for 3rd party distributed content. And if such app provider simply switched to SPDY, the service would highly probably work faster than the combination of plain HTTPS and CDN can provide. In the end, even if we had such a hash signature system (where authenticity of hash is provided by TLS of the main site), when it would be supported well enough to be trusted? 10 years has not been enough to get rid of MSIE 6.0... If you need security, the only real option is to serve content from servers that you can trust and use TLS to encrypt the traffic. -- Mikko
Re: [whatwg] High-density canvases
On Thu, Jun 26, 2014 at 10:13 AM, Robert O'Callahan wrote: > To clarify, I think a version of option #1 would be the best way to go. > renderedPixelWidth would return the current canvas buffer width when the > canvas element's CSS specified value for 'width' is 'auto', and similar for > height. > Actually, that would break some use-cases involving object-fit, so instead renderedPixelWidth/Height should return the current canvas buffer width only when *both* 'width' and 'height' are 'auto'. Rob -- Jtehsauts tshaei dS,o n" Wohfy Mdaon yhoaus eanuttehrotraiitny eovni le atrhtohu gthot sf oirng iyvoeu rs ihnesa.r"t sS?o Whhei csha iids teoa stiheer :p atroa lsyazye,d 'mYaonu,r "sGients uapr,e tfaokreg iyvoeunr, 'm aotr atnod sgaoy ,h o'mGee.t" uTph eann dt hwea lmka'n? gBoutt uIp waanndt wyeonut thoo mken.o w
Re: [whatwg] High-density canvases
On Thu, Jun 26, 2014 at 10:10 AM, Robert O'Callahan wrote: > On Thu, Jun 26, 2014 at 2:49 AM, Justin Novosad wrote: > >> I was wondering if there is anything we can do with this feature to >> prevent >> web apps from creating layout feedback loops. What I mean is that if the >> event listener for renderedsizechange changes the layout of the page in a >> way that does not preserve renderedPixelWidth/Height, we can get into a >> lot >> of trouble. Even if the resizing arithmetic in the event listener is >> sound, >> if the rounding logic does not match exactly what the browser does, >> fractional scales may cause instabilities. >> >> The main source of of the problem is that intrinsic size affects CSS size >> when width or height are set to 'auto', which is the default. Some ideas >> that come to mind for breaking the feedback loop: >> 1) renderedPixelWidth/Height return the intrinsic size when CSS >> width/height are set to 'auto' >> 2) renderedPixelWidth/Height do not change when CSS width/height are set >> to >> 'auto' >> > > We could do this and I think it would work. It's arguable whether the > complexity is justified, but I'd be OK with doing it. > To clarify, I think a version of option #1 would be the best way to go. renderedPixelWidth would return the current canvas buffer width when the canvas element's CSS specified value for 'width' is 'auto', and similar for height. Rob -- Jtehsauts tshaei dS,o n" Wohfy Mdaon yhoaus eanuttehrotraiitny eovni le atrhtohu gthot sf oirng iyvoeu rs ihnesa.r"t sS?o Whhei csha iids teoa stiheer :p atroa lsyazye,d 'mYaonu,r "sGients uapr,e tfaokreg iyvoeunr, 'm aotr atnod sgaoy ,h o'mGee.t" uTph eann dt hwea lmka'n? gBoutt uIp waanndt wyeonut thoo mken.o w
Re: [whatwg] High-density canvases
On Thu, Jun 26, 2014 at 2:49 AM, Justin Novosad wrote: > I was wondering if there is anything we can do with this feature to prevent > web apps from creating layout feedback loops. What I mean is that if the > event listener for renderedsizechange changes the layout of the page in a > way that does not preserve renderedPixelWidth/Height, we can get into a lot > of trouble. Even if the resizing arithmetic in the event listener is sound, > if the rounding logic does not match exactly what the browser does, > fractional scales may cause instabilities. > > The main source of of the problem is that intrinsic size affects CSS size > when width or height are set to 'auto', which is the default. Some ideas > that come to mind for breaking the feedback loop: > 1) renderedPixelWidth/Height return the intrinsic size when CSS > width/height are set to 'auto' > 2) renderedPixelWidth/Height do not change when CSS width/height are set to > 'auto' > We could do this and I think it would work. It's arguable whether the complexity is justified, but I'd be OK with doing it. Rob -- Jtehsauts tshaei dS,o n" Wohfy Mdaon yhoaus eanuttehrotraiitny eovni le atrhtohu gthot sf oirng iyvoeu rs ihnesa.r"t sS?o Whhei csha iids teoa stiheer :p atroa lsyazye,d 'mYaonu,r "sGients uapr,e tfaokreg iyvoeunr, 'm aotr atnod sgaoy ,h o'mGee.t" uTph eann dt hwea lmka'n? gBoutt uIp waanndt wyeonut thoo mken.o w
Re: [whatwg] Fetch: asFormData()
On Wed, Jun 25, 2014 at 5:31 PM, Domenic Denicola wrote: > What about asURLSearchParams()? It seems qualitatively different, because if > a form sends form data in a body, then parsing it as form data makes sense. > But asURLSearchParams() seems like it is instead parsing a form-data body as > a query string representation, which was not its original format. Servers > manipulate query strings all the time too, but they usually don't manipulate > request bodies as if they were query strings. I think you are confused. will by default use the format associated with URLSearchParams. However, per option 1) we can also parse this format and spit out a FormData, making asURLSearchParams() redundant and probably unneeded. If you have you would not invoke this method on the body (there is no body, doh). You'd simply use request.url.searchParams which is fully synchronous to boot. -- http://annevankesteren.nl/
Re: [whatwg] Fetch: asFormData()
From: annevankeste...@gmail.com on behalf of Anne van Kesteren > I expect the common usage scenario to be the page sending such data to a > service worker. Note that we have to care about the server side now we have > this proxy. That is a great point. My uneasiness has been dispelled. From this perspective, you are conceptually just reconstituting the data in its original form, not parsing it. And servers manipulate form data all the time. What about asURLSearchParams()? It seems qualitatively different, because if a form sends form data in a body, then parsing it as form data makes sense. But asURLSearchParams() seems like it is instead parsing a form-data body as a query string representation, which was not its original format. Servers manipulate query strings all the time too, but they usually don't manipulate request bodies as if they were query strings.
Re: [whatwg] Fetch: asFormData()
On Wed, Jun 25, 2014 at 5:17 PM, Domenic Denicola wrote: > Hmm. To clarify, this is in case the server sends you > application/x-www-form-urlencoded data, and you want to then get it in a > format that can easily become a mutable query string or form data object? I expect the common usage scenario to be the page sending such data to a service worker. Note that we have to care about the server side now we have this proxy. -- http://annevankesteren.nl/
Re: [whatwg] Fetch: asFormData()
On 25 June 2014 08:17, Domenic Denicola wrote: > Hmm. To clarify, this is in case the server sends you > application/x-www-form-urlencoded data, and you want to then get it in a > format that can easily become a mutable query string or form data object? > > If so, neither use case seems like they are worth the convenience method > to me. The common use would be request.body.asFormData()
Re: [whatwg] Fetch: asFormData()
Hmm. To clarify, this is in case the server sends you application/x-www-form-urlencoded data, and you want to then get it in a format that can easily become a mutable query string or form data object? If so, neither use case seems like they are worth the convenience method to me. Servers sending data in that format (as opposed to JSON) are pretty rare. And it's even rarer that you want to get the data in that former, then manipulate it before sending it along; usually you would just pass it along as an opaque string. I would rather that the query string parser and the form data parser be exposed by their relevant specs, i.e. people would just use ```js var params = new URLSearchParams(req.body.asText()); var data = new FormData(req.body.asText()); // why doesn't this work currently? ``` I guess a similar argument can be made for `var json = JSON.parse(req.body.asText())`, but that is a much more common use case. Am I wrong?
Re: [whatwg] Fetch: asFormData()
On Wed, Jun 25, 2014 at 4:51 PM, Jake Archibald wrote: > On 25 June 2014 04:50, Anne van Kesteren wrote: >> Do we want to keep that tradition and have both asFormData() and >> asURLSearchParams() or should we embed some smarts in the asFormData() >> algorithm? (FormData is basically a more general URLSearchParams as it >> can handle Blob/File objects as well as strings.) > > A single asFormData() sounds useful and intuitive. Are you suggesting it'd > always return a FormData object even if it was urlencoded? That sounds > better than returning objects of different types. Yes, however, that does mean asFormData() would inspect the MIME type whereas other as*() methods do not. To be clear, the other suggestion was not to vary the return type. Some options: 1) Have asFormData() check the MIME type for urlencoded. If it is urlencoded, urlencoded-parse into FormData. Otherwise, formdata-parse into FormData. 2) Have both asFormData() and asURLSearchParams(). The former formdata-parse into FormData. The latter urlencoded-parse into URLSearchParams. 1a) Like 1), but check MIME in the otherwise clause. Reject if neither MIME type is there. 2a) Like 2), but check MIME. Reject if MIME type is incorrect. 3) Have 1/1a, but also asURLSearchParams() per 2/2a. Feelings: 1) Simple, works. 2) Also simple, but harder for developers. 1a/2a meh. 3) No need for asURLSearchParams if asFormData handles it already. -- http://annevankesteren.nl/
Re: [whatwg] Fetch: asFormData()
On 25 June 2014 04:50, Anne van Kesteren wrote: > Do we want to keep that tradition and have both asFormData() and > asURLSearchParams() or should we embed some smarts in the asFormData() > algorithm? (FormData is basically a more general URLSearchParams as it > can handle Blob/File objects as well as strings.) > A single asFormData() sounds useful and intuitive. Are you suggesting it'd always return a FormData object even if it was urlencoded? That sounds better than returning objects of different types.
Re: [whatwg] High-density canvases
I was wondering if there is anything we can do with this feature to prevent web apps from creating layout feedback loops. What I mean is that if the event listener for renderedsizechange changes the layout of the page in a way that does not preserve renderedPixelWidth/Height, we can get into a lot of trouble. Even if the resizing arithmetic in the event listener is sound, if the rounding logic does not match exactly what the browser does, fractional scales may cause instabilities. The main source of of the problem is that intrinsic size affects CSS size when width or height are set to 'auto', which is the default. Some ideas that come to mind for breaking the feedback loop: 1) renderedPixelWidth/Height return the intrinsic size when CSS width/height are set to 'auto' 2) renderedPixelWidth/Height do not change when CSS width/height are set to 'auto' 3) have an explicit way to enable this feature. When it is enabled, the canvas follows non-replaced element layout rules. On Wed, Jun 25, 2014 at 1:09 AM, Robert O'Callahan wrote: > On Wed, Jun 25, 2014 at 3:30 PM, Rik Cabanier wrote: > > > Add a new event renderedsizechange to HTMLCanvasElement. This event does > > not bubble and is not cancelable. Whenever the value that would be > returned > > by renderedPixelWidth orrenderedPixelHeight changes, queue a task to fire > > renderedsizechange at the HTMLCanvasElement if there is not already a > task > > pending to fire such an event at that element. > > > > > > - If there's a transition or animation that affects the canvas element, > > should it receive resize events at 60fps? > > > > UA dependent. In practice I would change the renderedPixelWidth/Height > properties whenever Gecko rerasterizes the surrounding CSS content with a > new resolution. > > > > - will CSS 3D transforms affect the rendered canvas size? If so, what > would > > the optimal resolution be if there's a rotation > > > > UA dependent. Again, I would change the renderedPixelWidth/Height > properties whenever Gecko rerasterizes the surrounding CSS content with a > new resolution, based on that resolution. > > > > - what happens if the canvas element is not in the document? Will it just > > return the pixel width/height? > > > > UA dependent. I'd probably just leave it unchanged while it's not in the > document (and assume 1 CSS pixel per device pixel if it's never been in a > document with a screen presentation). > > Rob > -- > Jtehsauts tshaei dS,o n" Wohfy Mdaon yhoaus eanuttehrotraiitny eovni > le atrhtohu gthot sf oirng iyvoeu rs ihnesa.r"t sS?o Whhei csha iids teoa > stiheer :p atroa lsyazye,d 'mYaonu,r "sGients uapr,e tfaokreg iyvoeunr, > 'm aotr atnod sgaoy ,h o'mGee.t" uTph eann dt hwea lmka'n? gBoutt uIp > waanndt wyeonut thoo mken.o w >
[whatwg] Fetch: asFormData()
The as* methods do not check MIME at the moment, except for asBlob(), which does it so it can store it along with the bytes. Do we want to keep that tradition and have both asFormData() and asURLSearchParams() or should we embed some smarts in the asFormData() algorithm? (FormData is basically a more general URLSearchParams as it can handle Blob/File objects as well as strings.) We did just discuss layering, but I feel that including support for the most common form submission formats is not an undue burden on the Fetch library. They should be part of Fetch in my opinion. (There's still the outstanding issue of defining multipart/form-data parsing/serializing. Any volunteers? I noticed https://github.com/masinter/multipart-form-data/ but it seems not very far along.) -- http://annevankesteren.nl/
Re: [whatwg] SVG cloning elements from HTML5
On Tue, Jun 24, 2014 at 9:50 PM, Tab Atkins Jr. wrote: > 1. Define that the SVG layout model is a thing. Yes, this. And also that the layout attributes act are "presentational hints" as per HTML's rendering section. That will explain the cascade effects we want. And then given enough iterations and progress you can display a as a polygon. -- http://annevankesteren.nl/
