CSS Paint API: New possibilities in Chrome 65
developers.google.com
developers.google.com
This feels ridiculous. I understand why certain features would be gated behind https (camera access, stuff like that). But this feature doesn't look dangerous at all. I don't always want to deploy https. What about local websites (not localhost, but LAN) ? Am I not allowed to use those APIs then ?
While the https movement has benefits, don't misunderstand Google's interest as altruism. Good cause, murky motivation.
Also do you keep track of the certificates issued to every website you visit? Then if you visit the website notice the certificate has changed. Do you check if it's a legitmate change ect.. If you don't keep track of certificates how do you even know you are not being MITM. You trust the certificate authority to handle that. However, certificate authorities clearly have signed or given out bad certificates.
Further, it only takes one bad certificate authority to compromise the entire system.
If the browsers really cared they would make sure that all login mechanism use something like J-PAKE or a private Key. That way if certificate authority was compromised the attacker would also have to know either your password or private key.
Further, not everything requires an encrypted session. It just adds overhead for no good reason. If you worried about MITM injecting a zero day. It would help if the web standards did not keep getting more and more complicated increasing the attack surface. All you need there is just a simple signed hash of the page. Some things might not even need that.
--EDIT-- I went on a bit of ramble there. If we want to be Mr. Conspiracy. I would say google likes adding more and more features because it makes it harder for competing browsers to exist. Not only that let's consider HTTP 2.0. The standard does require TLS, but Firefox and Google will not talk to HTTP 2.0 web-server without TLS. The large market share of Chrome for instance makes you unable to decide to run a plain text HTTP 2.0 web-server even though TLS is optional according to the standard. Even though Chrome is not the standard as specified by the standard document. I am forced to comply with how chrome and firefox are doing things. The effectively can make their own standards since there are so few browsers. The would be my Mr. Conspiracy reason why google would want to require TLS. Becuase let's face building a secure Crypto stack the meets all the requirements for TLS is not easy. So that just increases the barrier to entry.
>Also do you keep track of the certificates issued to every website you visit? Then if you visit the website notice the certificate has changed. Do you check if it's a legitmate change ect.. If you don't keep track of certificates how do you even know you are not being MITM. You trust the certificate authority to handle that. However, certificate authorities clearly have signed or given out bad certificates.
still better than anyone being able to inject scripts when you're on an untrusted network. the requirement for a compromised CA drops the interception risk for most users to 0.
>Further, not everything requires an encrypted session. It just adds overhead for no good reason.
overhead of what? maybe a few hundred milliseconds on a 3g connection?
>CA drops the interception risk for most users to 0. The risk is not zero for a compromised CA. It's happened before.
>overhead of what? maybe a few hundred milliseconds on a 3g connection? Sure hardware resources are cheap these days. There is more than just hardware resources though. People have to manage that system as well. Further, it makes caching impossible or hard to accomplish. Also this new feature is a clear example of how we got into this mess. We keep adding onto what was supposed just be a document markup. It's now got a turning complete language that you have to worry about. Plus a whole host of other issues.
I will be honest so much the system we use these days is deeply flawed or just a hack. The fact we got to where we are is surprising.
However, for instance in Firefox. I can't even go into the about:config and enable non-encrypted HTTP 2.0. Firefox is telling me they know better. I don't want software forcing decisions down my throat as a user. Sure I could in theory code up what is required to allow me to do so. (Yay open source) However, Chrome and Firefox both do not allow HTTP 2.0 without TLS. What are the chances a web-server will respond to my plain text request? So does it matter if I code up support for plain text HTTP 2.0? At least plain text HTTP I can craft an HTTP request by hand and get a response. I could do the same with plain text HTTP 2.0, but not many servers are configured to allow that or even support it.
Just because a system has flaws doesn't mean you should be using an even more flawed system like HTTP. With HTTPS, attackers can't read or modify traffic. If you really think certificate authorities are that unreliable, you can choose which certificates you trust yourself to avoid spoofing.
However, my problem is the browsers are forcing choices on people that are not part of the standard. They are acting as if they know best. They are also making it harder for advance users to alter these decisions. Try to enable plain text HTTP 2.0 in Firefox? No option exists in about:config.
Further, I don't see an option to disable Firefox's Secure contexts for new features. Might exist, but may need to look more.
Https only shuts down the ability for ISPs and mobile carriers to do that. And many of them were doing so. I suspect that backbone providers were doing it as well. Good thing to shut down, sure, but it's also good for G.
There is wide consensus that while there are certainly trade-offs this is a good thing.
I don't think this was done for technical reasons though. Rather, it's an attempt to drive further adoption of HTTPS with the ultimate goal of phasing plain HTTP out of mainstream use entirely.
For websites on LAN you can either install your own root cert on client devices, or assign the site a public domain name (even if the site itself isn't accessible from the public internet) and get a publicly-trusted cert that way.
That’s a pain in the ass just to test a local website.
With this recommendation, I have to generate a certificate and install it everywhere just to test simple functionality.
Since Google recommended the ".test" domain for internal testing that's what I use. In the past I had used ".dev" (now owned by Google) and ".local" (now used by Apple for bonjour networking) to setup test domains on my LAN. So, Google should allow these features through for ".test" at least.
Honestly, they should make it a flag that developers can toggle at the very, very least.
https://www.chromium.org/Home/chromium-security/deprecating-...
Or just use a self-signed cert and click though the security warning.
The second, well, who knows if it will work today or tomorrow. And, it's still a pain in the ass.
Safari has an experimental API called -webkit-canvas that's very similar to Paint Worklet. You can use it to write code that runs in either engine pretty easily.
I've just thrown together a gist outlining how to do so:
https://gist.github.com/appsforartists/e5d2a4b7826bf5962fad1...
It's not quite a polyfill, because -webkit-canvas doesn't automatically repaint when you change an input property. Otherwise, it would be pretty simple to write one.
I may write a proper tutorial at some point. Hopefully this gives other interested folks a push in the right direction, in the mean time.
background: -webkit-canvas(mycanvas);
In a Paint Worklet, the canvas is generated for you, and your painter is automatically called every time an input property changes.
In -webkit-canvas, you manually instantiate the canvas and manually repaint it.
It's the difference between reactive and procedural programming (even though the actual painter is procedural in either case).
Here's a gist I threw together showing how to use the same paint function with either API:
https://gist.github.com/appsforartists/e5d2a4b7826bf5962fad1...
So I guess the main thing added is convenience? Am I missing something here? Adding CSS that requires corresponding JS code is also new territory isn't it (I can't think of anything else that does this)?
But here it doesn't feel very ergonomic. You still need to write that JS code! Reading into it some more I think the only benefit it adds is state management (rerender on parameter change) but I don't really don't want/need CSS doing that for me.
Also, yeah, it's a more "obvious" way of doing this - instead of rendering to an offscreen canvas and converting that to an image, just render to the right place in the first place.
https://ishoudinireadyyet.com/
This gives a much greater ability to iterate rapidly on new layout and styling details, polyfill for specifications that aren't widely implemented yet, and hook into some parts of the browser stack that you previously just had to use as is and trust that if you need a new feature, it would eventually be specified and/or implemented.
I think this article does the best job of explaining the whole effort:
https://www.smashingmagazine.com/2016/03/houdini-maybe-the-m...
There are so many warts in CSS that I really wish I could customize. For example if I wanted to add a outside-aligned instead of center-aligned stroke to text, you can only accomplish it with lots of hacks: https://css-tricks.com/text-stroke-stuck-middle/ https://css-tricks.com/adding-stroke-to-web-text/. Using pseudoelements hidden behind, a circle of text-shadows, etc.
I wonder if there's anything in the Houdini project that will let me fix this. This paint api is useless to me since it doesn't give me the original contents of the dom being styled (so I would need to redraw the text, style it and layout it on my own). The solution I ended up with is using svg filters: https://www.smashingmagazine.com/2015/05/why-the-svg-filter-.... But a unified solution to customizing CSS without needing to call it a hack would be nice.
- Chrome's implementation won't actually perform a raster at this stage, instead we'll raster later on a background thread. toDataUrl, etc will raster.
- We'll only invoke the paint method for things which we actually need to paint. E.g. if you have a long list, we won't invoke the method for things that are outside the paint window (things off-screen).
- We'll have the ability to add a bunch of caching later on. From memory the servo folks in their experimental implementation actually speculatively generated a bunch of images ahead of time.
- We are actively investigating moving this to a background thread. So even if your main thread is janked, an animation which triggers a paint worklet, will still run at 60fps.
edit - formatting.
Does anyone have an idea as to what those reasons might be? I've heard of JavaScript access to certain CSS features being limited (e.g. getComputedStyle()), but I'm not sure what the benefit is here. Is there any way that user information could be leaked through a paint worklet context?
The primary reason we did this is to ensure there wasn't a performance cliff if you did read-back pixels. With the current API surface you can record all of the canvas commands, and play them back when you need to raster. Additionally it doesn't leak how many pixels we are actually rastering to.
(hope this helps).
Did Chrome come up with Houdini? Are they being brave or pushy here?
Most certainly not. I know people at Mozilla who've been working on Houdini-related features for a while now (cf. https://wiki.mozilla.org/CSS/Houdini). Chrome is just the first to release here.
Houdini is a task force that consists of people from Apple, Mozilla, Microsoft, Chrome, even IBM and Samsung. It’s by no means a Chrome-only thing or us being pushy.
Servo has an experimental implementation, but it’s the part of Servo that hasn’t been merged into FF. All participating browser vendors have given very positive signals about CSS Paint API.
Check http://ishoudinireadyyet.com/ to stay up to date :)
https://googlechromelabs.github.io/houdini-samples/paint-wor...
https://bugzilla.mozilla.org/show_bug.cgi?id=801176#c29
Given the post's mention of running this stuff off-thread in the future, I suspect it's related to that.
Also I am sick the HTTPs everywhere movement. What if I for what ever reason don't want to use HTTPs.
We have so few browsers, that basically what they do is the defacto standard.
Further, when you you Google, Mozzila, ect... saying you can't you use a feature without HTTPs the effectively make HTTPs part the standard even though it's not written in the standard.
For instance let say I wanted to run HTTP 2.0 web server. The HTTP 2.0 standard does not require encryption. However, because none of the browsers vendors support HTTP 2.0 without TLS. I must setup TLS to make my server accessible. It's not part of the standard, but the big browser providers effectively make it part of the standard. I don't have a problem with crypto. I just hate the browsers forcing it to be basically part of the standards. When it should be optional.
For instance in Firefox. I can't even go into about:config and enable plain text HTTP 2.0. They are trying to make choices for me.
Instead of adding more and more things maybe we should restructure things. Instead of adding onto what was supposed to be text markup. Maybe design something more conducive to the fancy interactive graphical object.
But forcing your sites to use HTTPS will also prevent your users from unwittingly participating in DDOS attacks on other sites (e.g. https://en.wikipedia.org/wiki/Great_Cannon). Consider it herd immunity.
Also, to respond to some of your other anti-HTTPS comments:
regarding overhead: people are also working hard to minimize the amount of overhead inherent to TLS. For instance, TLS 1.3 will establish an encrypted connection in a single roundtrip, and is capable of resuming encrypted connections in zero roundtrips with application opt-in (see https://blog.cloudflare.com/tls-1-3-overview-and-q-and-a/). The encryption itself has fairly ubiquitous support in hardware, making most of them ridiculously fast.
regarding CAs: with HTTP you are implicitly relying on the honesty of people in the network path. With HTTPS you are implicitly relying on the honesty of the intersection of a) people in the network path, b) people who control a CA. This is strictly fewer people than with HTTP. People are also working hard to solidify our faith in the set (b), by requiring Certificate Transparency for all new certificates, thereby ensuring that misbehaving CAs can be detected, and drastically raising the cost of mounting a CA-based attack.
You say "What if I for what ever reason don't want to use HTTPs", I you'll have to layout some of those reasons explicitly. You'll probably find that people are working on all of them.
In general, the default expectation on the web should be encrypted and authenticated (i.e. only both endpoints can read/write the data). Once we live in that future, asking for the ability to allow plaintext network traffic will seem a lot like asking modern programming languages to explicitly allow buffer overflows. The language designer would be justified in saying "No", and ignoring you. The considerate language designer might ask "why would you want that", and try to address your real need. But they would still never actually give you what you ask for. This may be "taking away choice" in the same sense that mandating airbags is "taking away choice", but people shrug and accept it because the baseline has moved.
I suppose you could that creating a secure web context is kinda of way of doing that. Separating documents from more interactive content. However, freaking HTML is a horrible way to structure such a system.
Also the CA is single point of failure. A MITM only affects the users along that routing path. CA failure can affect the entire web...
I agree default is fine, but the user should be able to change those defaults. I could always compile a version for Firefox or Chromium that does. However, that's kinda ridiculous that I don't see any thing for instance in about:config Firefox.
--Speaking of programing languages-- Honestly, I don't see any language succeeding that only allows code with run time checks running. It's why rust has the unsafe keyword. To override those checks. The reason there are lots of hardware devices where the data from said device will vary in size, and there is no way the compiler will know how all these devices work. The unsafe keyword allows Rust to be a system programming language. Heck even C requires you to revert to ASM at times for working with hardware. The generated code may not meet some strict requirements set by the hardware or you need to setup the environment so C code can run.
Honestly, the biggest problem I see with programming languages is that too many of them try to be general purpose. Domain specific languages are great. If the language is designed well for the problem space it can lead to well written concise and understandable code. If your problem domain is working with hardware you need raw pointers, memory access and accurate timing. If you problem domain is altering images you probably want easy to use vector operations, handling of regions ect...