Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

CSS Paint API: New possibilities in Chrome 65

developers.google.com

Post reply on HN
Print view View original

51–59 of 59 posts

Re: CSS Paint API: New possibilities in Chrome 65

#51

Post by tyingq »

jopsen wrote: post #43
anfilt wrote: post #30

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.…

The certificate transparency initiative is going to make MITM really hard.

Unless the majority of sites choose to run your javascript. Like Adsense and Analytics. Not much need for actual MITM when you are "on the page".

Re: CSS Paint API: New possibilities in Chrome 65

#52

Post by dassurma »

matmo wrote: post #3

I always find it interesting that Chrome is charging ahead full steam on experimental API's like this while most other browsers have given no intent to implement them yet. Did Chrome come up with Houdini? Are they being brave or pushy here?

Author 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 :)

Re: CSS Paint API: New possibilities in Chrome 65

#54

Post by anfilt »

agentS wrote: post #47
anfilt wrote: post #22

Quit bloating the web... 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.

I am sorry that you are sick of the HTTPS everywhere movement. 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 inheren…

The biggest problem is Java Script. Netscape made huge mistake when they added that to their browser. If we wanted to download code on the fly it should have been a separate format from HTML. HTML is supposed to be a document. Sadly, that boat sailed decades ago. I really wish the standards committee would quit adding basically hacks to what was supposed to be a bunch documents. Then create a separate format more conducive to that goal.

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...

Re: CSS Paint API: New possibilities in Chrome 65

#55

Post by Santosh83 »

anfilt wrote: post #38
gruez wrote: post #33

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…

>The whole system is dependent on that weak point. A single weak point does not strike you as a bad idea? >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…

Too late. The Web is well on the way to becoming the next operating system. Very soon the local OS will mostly just open web frameworks like Electron to run nearly all our apps. This way has clear benefits for s/w developers and corps. Just like there are only 3 mainstream OS vendors, there'll only be 3-4 mainstream browsers in the future. There won't be another Linus for OSes and there won't be another Mozilla for browsers. The slope has become too steep. At least not for PC and general purpose computing devices.

Re: CSS Paint API: New possibilities in Chrome 65

#56

Post by hungerstrike »

Ajedi32 wrote: post #49
hungerstrike wrote: post #48

Earlier quoted context omitted.

> install your own root cert on client devices... That’s a pain in the ass just to test a local website.

If you're just testing on localhost, there should be no need for a cert. As the article says, localhost is treated the same as https here. In the future, I expect all features that require a secure context will start treating localhost as secure, if they don't already.

I usually have 2 or 3 devices that I need to test a website on, so no - localhost alone doesn't help at all. For example: I run the website on my workstation and I want to test it on my iOS and Android devices.

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.

Re: CSS Paint API: New possibilities in Chrome 65

#57

Post by Ajedi32 »

hungerstrike wrote: post #56
Ajedi32 wrote: post #49

Earlier quoted context omitted.

If you're just testing on localhost, there should be no need for a cert. As the article says, localhost is treated the same as https here. In the future, I expect all features that require a secure context will start treating localhost as secure, if they don't already.

I usually have 2 or 3 devices that I need to test a website on, so no - localhost alone doesn't help at all. For example: I run the website on my workstation and I want to test it on my iOS and Android devices. 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 th…

--unsafely-treat-insecure-origin-as-secure="http://example.com"

https://www.chromium.org/Home/chromium-security/deprecating-...

Or just use a self-signed cert and click though the security warning.

Re: CSS Paint API: New possibilities in Chrome 65

#58

Post by hungerstrike »

Ajedi32 wrote: post #57
hungerstrike wrote: post #56

Earlier quoted context omitted.

I usually have 2 or 3 devices that I need to test a website on, so no - localhost alone doesn't help at all. For example: I run the website on my workstation and I want to test it on my iOS and Android devices. 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 th…

--unsafely-treat-insecure-origin-as-secure=" http://example.com" https://www.chromium.org/Home/chromium-security/deprecating-... Or just use a self-signed cert and click though the security warning.

The first recommendation doesn't work on iOS or Android.

The second, well, who knows if it will work today or tomorrow. And, it's still a pain in the ass.

Re: CSS Paint API: New possibilities in Chrome 65

#59

Post by matmo »

dassurma wrote: post #52
matmo wrote: post #3

I always find it interesting that Chrome is charging ahead full steam on experimental API's like this while most other browsers have given no intent to implement them yet. Did Chrome come up with Houdini? Are they being brave or pushy here?

Author 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…

Thanks for the info. Love your youtube videos by the way :)
Post reply on HN