Live data from Hacker News

Webkit.js

trevorlinton.github.io

51–60 of 106 posts

Re: Webkit.js

#51

It's a little contrived, but a "practical" use of this might be for an online HTML editor to embed the document (or display a preview) without any interference from the parent document.

You can do that via iframe as well

If you allow custom HTML via an iframe and make it shareable you have to host the iframe from a different domain, otherwise it's XSS vulnerability heaven. The trick will be authentication because separate domains don't share sessions (and you wouldn't want a secured domain access to your session anyway) but you can do communication via postMessage.

Re: Webkit.js

#52

Earlier quoted context omitted.

You can fork the project on Github and Mercurial and write DOM bindings to whatever JavaScript engine you'd like. [0] https://github.com/mozilla-b2g/B2G [1] http://hg.mozilla.org/

Having to convince users to install your fork of the OS really isn't the same thing as being able to run a different native browser alongside their existing software. If the only way to use a browser other than Internet Explorer had been to switch OS then Firefox could never have been created in the first place.

How is that any different than with native code? You can't just rip out your OS' implementation of libc and have all of your programs use another (not all implementations of libc are ABI compatible).

You can't boot your computer into two operating systems at once (or can you?). This whole post is analogous to running Windows in a VM on Linux.

Re: Webkit.js

#53
Very nice and with JS support it would be perfect! I wonder if this is a solution to potential XSS attacks with embeded iframes or embeded user-generated html+css+js.

Re: Webkit.js

#55
post #44

Earlier quoted context omitted.

There are privacy and security concerns to address. Similar to this situation: https://hacks.mozilla.org/2010/03/privacy-related-changes-co...

One solution is for the browser to provide a "anonymized" bitmap picture, e.g. setting the links to default colors. I don't know how feasible that is. It would require a new rendering of the page, at least.

That's not a solution for the general problem of getPixel + iframes though.

Here, I'll give a simple example. Let's say there's a site that uses cookies to track logins. For example, hacker news. Now, hacker news does have the X-Frame-Option Deny, but let's assume it doesn't.

So to figure out my hacker news username, all you have to do now is create an iframe with hacker news, and then getPixel on the area of the frame that contains usernames, run some trivial OCR, and done.

Now, this issue is even more serious in other instances. For example, google talk widgets are embedded by iframes I believe.

In both these cases, a fresh rendering would still have the inappropriate material due to cookies. If cookies aren't sent, e.g. you do a fresh render in a private tab, it would still have security concerns for anything that displays different, sometimes private, content based on ip address.

For an example of that, you could render "private.internal.company.localsite" in an iframe and if a visitor from that company visited, even a cookie-less load would probably show private data due to the internal site relying on ip/nat controls.

Re: Webkit.js

#56

Earlier quoted context omitted.

Chrome forked Webkit over a year ago, creating Blink. They're two independent layout engines now.

I believe he is referring to the fact that iOS Chrome is the only version still using WebKit

Yes, that's exactly what I meant. I think that a few people may have missed that due to the fact that my comment is currently at -2.

Re: Webkit.js

#57
post #17
post #4

Earlier quoted context omitted.

What exactly are iOS users missing in Safari, in your opinion, that they would get from Firefox? I can see that Chrome has some cool sync features if you're into that sort of thing. But it still uses WebKit. And from what I've observed, people seem happy with the "Chrome" app in the app store, even though it uses a handicapped renderer. (Although in iOS 8, it won't be handicapped anymore, and will be as powerful as n…

The funny thing is that the "RAWR NO SAFARI, ONLY CHROME!" people don't seem to realize that both are WebKit at the core. Sure, some features are in Chrome first, but that's only because Apple is very cautious when releasing the new features to the general public.

I can't edit my comment for some reason, but as thefreeman pointed out in response to agildehaus' comment, I was referring to how the iOS Chrome is still WebKit.

Re: Webkit.js

#58
Pretty cool. There's been a push to make HTML run everywhere, but this proves you can make X run on HTML.

Maybe someday we'll code apps in Objective-C/Java that run in the browser, all inside a canvas.

Re: Webkit.js

#59
post #4

Earlier quoted context omitted.

What exactly are iOS users missing in Safari, in your opinion, that they would get from Firefox? I can see that Chrome has some cool sync features if you're into that sort of thing. But it still uses WebKit. And from what I've observed, people seem happy with the "Chrome" app in the app store, even though it uses a handicapped renderer. (Although in iOS 8, it won't be handicapped anymore, and will be as powerful as n…

Because competition in the browser market is vital to keep the web platform progressing and to prevent a single party from controlling web standards. Do you remember the dark ages when IE ruled the web and things like HTML5, canvas, webgl, etc... couldn't happen?

I agree on principle. Many of us still have emotional baggage from the days of 95% IE market share, where the web really, REALLY sucked.

But nowadays, I see it as, multiple companies have a vested financial interest (including MS with their new leadership) to ensure that browsers are very powerful.

Even Apple, with iOS 8 has enabled 3rd party devs to have a full speed browser now with a JIT'd JS engine. They are simply not doing this from a position of weakness. There are no market forces. There's nobody out there saying "I won't use iOS because it only has Safari." Yet they still did it.

Your mobile platform won't succeed today unless it has a powerful browser built in, apps or not.

Re: Webkit.js

#60

Pretty cool. There's been a push to make HTML run everywhere, but this proves you can make X run on HTML. Maybe someday we'll code apps in Objective-C/Java that run in the browser, all inside a canvas.

We're closer than you think!

https://developer.gnome.org/gtk3/stable/gtk-broadway.html http://www.youtube.com/watch?v=fr8eo4RlPw4

Post reply on HN