joev_

ServiceWorkers are scoped to the basename of the path they are served from, so you could only intercept a small subset of all possible CDN URLs. In the example, this would be resources under `/hads-ak-xat1/t45.1600-2/`. But you probably can't create a ServiceWorker here anyways as you need a route that returns valid Javascript of your choosing with a Content-Type `text/javascript`. Usually when I've seen an opportunity for ServiceWorker exploits it's due to a JSONP endpoint that does not sanitize its callback parameter.

If you could create a valid ServiceWorker at this route, and load it inside some same-domain HTML page, then you could theoretically use it to intercept and rewrite responses to any resources on the domain under its path. Depending on how you rewrite the response you might be able to get the browser to cache the rewritten resource, which could then get used by other domains. Theoretically. I have never tested this :)

Out of curiosity, did you actually replace the Browser app, or did you just install a new one? If the stock Browser is still installed, you may consider the fact that it can probably be launched from Chrome with a specific URL intent.

> If I want to style my button, I set some properties on the button.

You cannot be serious. A 1000+ line long setup() method that creates a ton of one-off elements, sets a million properties, and saves them all as instance variables is in no way superior to using some XML to structure your elements, and then a separate, extracted layer for styling. I've done the procedural shit before, in Java, UIKit, Cocoa, you name it. There's just no way you can actually think that is better. Presentational separation is a good thing. (btw you can write your UI in the same procedural way in Javascript if you think it is superior/are a masochist).

The rest of your comment is very rambling and does not really have a point so I will hold off on replying to it. I write polished, pixel-perfect, cross-platform interfaces, and HTML/CSS is the best tool I have found for the job. Nobody will ever say it is perfect of course, but IMHO it beats the hell out of WinForms! You are right, it is a lot to learn for a 1st year developer, but you are going to get a shitty UI out of a 1st year developer, who cares?

> Yes, there is more memory available than before, but that doesn't mean we should just waste it for useless stuff.

I disagree. I think the point is that it's not useless, by its own existence. It saves dev time (which allows more - and better! - programs to be built), it allows richer features and interactions, it lowers the barrier to entry for maintenance work, and most of all prevents constant re-inventing/implementing the wheel, which is reflected to the user in a lack of many common types of bugs, annoyances, and accessibility issues.

> Apple wants to relegate websites to second-class status on their popular computers, and exercises viewpoint censorship on what “apps” they allow in their “app store”.

I don't remember it that way all. Does anyone else? From what I remember, there was a very heavy consumer demand for the App store, meanwhile Apple was telling everyone just to make web apps. They actively developed WebKit into a cutting-edge, standards-oriented, developer-friendly browser. I don't see how you could say they wanted to "relegate websites to second-class status".

Can you list some native UI controls that you'd like to use but can't recreate in HTML? I am writing a similar framework and would like to know the use-cases for doing this.

Edit: besides Window and Menu, of course

/bin/sh depends on the system. It might be busybox or a minimal shell (this is common on embedded devices). On some systems like OSX and I think CentOS /bin/sh is just bash. You can check with `/bin/sh --version`.

My understanding is that Chrome replaced Webkit in WebView's internal implementation in 4.4, so the bug should never appear in 4.4.

I didn't test back this far; I should have, it's about 10% of android users. I tested back to 4.0 (not that 4.0-4.1.2 being vulnerable matters much, since you can get remote code execution easily through the addJavascriptInterface vulnerability). I tried out 2.1 in the emulator just now and got the same results as you, so it looks like 2.x is not affected by this.

I wish I had tested this sooner, but yes, Webview is vulnerable (use document.write(document.domain) instead of alert() to test). So afaict apps that embed webview/ads on < 4.4 are at risk.

Actually X-Frame-Options does not save you here. There is a BYPASS_XFO datastore option in the module that turns this into a one-click exploit. This allows the attack to work against sites with the XFO header.