31–40 of 59 posts
> As of now, text rendering methods are missing and for security reasons you cannot read back pixels from the canvas. 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?
> As of now, text rendering methods are missing and for security reasons you cannot read back pixels from the canvas. 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?
Earlier quoted context omitted.
Or maybe Google and Mozilla actually want to make the web more secure? Not everything has to be a conspiracy.
I would hardly call it secure. There have been too many failures with certificate authorities. The whole system is dependent on that weak point. 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.…
>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?
Another day, another wart on the modern web stack.
Earlier quoted context omitted.
Wat
Try to implement the rendering engine of a web-browser. The standards keep growing. A much simpler model could have been drafted for web content. Instead we keep hacking onto HTML adding things like CSS, JS. Then we keep adding on to those add-ons. Clearly, people are building things that are not documents. So why do we keep adding hacks to this document model? Further, when you you Google, Mozzila, ect... saying you…
Earlier quoted context omitted.
Or maybe Google and Mozilla actually want to make the web more secure? Not everything has to be a conspiracy.
I would hardly call it secure. There have been too many failures with certificate authorities. The whole system is dependent on that weak point. 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.…
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.
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.
Earlier quoted context omitted.
I would hardly call it secure. There have been too many failures with certificate authorities. The whole system is dependent on that weak point. 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.…
>I would hardly call it secure. There have been too many failures with certificate authorities. The whole system is dependent on that weak point. >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…
>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.
Earlier quoted context omitted.
Try to implement the rendering engine of a web-browser. The standards keep growing. A much simpler model could have been drafted for web content. Instead we keep hacking onto HTML adding things like CSS, JS. Then we keep adding on to those add-ons. Clearly, people are building things that are not documents. So why do we keep adding hacks to this document model? Further, when you you Google, Mozzila, ect... saying you…
the problem is that if it's optional, lazy/ignorant developers will never implement it, even for sites that actually need it (pretty much any sites that handle login). requiring tls for new features is just another nudge that browser developers have put in place to encourage tls adoption.
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.
we already had this all the way back in 2008. It's called webkit css canvas! Iconapp.io is using that heavily! background: -webkit-canvas(mycanvas);
with the CSS Paint API you instantiate a new canvas like object for every time your reference the painter, while this was referencing one specific instance of a canvas, right?
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...