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

Introducing Chrome for Android

googleblog.blogspot.com

Post reply on HN
Print view View original

201–210 of 240 posts

Re: Introducing Chrome for Android

#201

Post by Achshar »

nextparadigms wrote: post #29
trotsky wrote: post #16

Decoupling the browser from the OS is one of the best things that could happen for android security going forward. While it won't help people who can't get upgrades to ICS, at least it will solve the future problems of people who get stuck on 4.x while their OS browser slowly becomes more and more exploitable. I have one phone that is still on 2.2 - it is trivially easy to own the phone with a little bit of javascrip…

I'm hoping this means it will get updates every 6 weeks, too.

yes it will..

> There will be the same 6-week release cycle for new versions, Pinchai says.

http://parislemon.com/post/17215781807/chrome-for-android-th...

but i would ask will they be automatic or manual?

Re: Introducing Chrome for Android

#202

Post by nookiemonster »

trotsky wrote: post #16

Decoupling the browser from the OS is one of the best things that could happen for android security going forward. While it won't help people who can't get upgrades to ICS, at least it will solve the future problems of people who get stuck on 4.x while their OS browser slowly becomes more and more exploitable. I have one phone that is still on 2.2 - it is trivially easy to own the phone with a little bit of javascrip…

trivially? please, more detail. Also: own is a loaded term. Please, more detail. Getting access to the sdcard is not the same as owning.

Re: Introducing Chrome for Android

#203

Post by eklitzke »

klausa wrote: post #132

It appears to be significantly faster on JS front than stock Browser. Sunspider results: Stock - 3852.2ms Chrome - 3131.8ms (tested on HP Touchpad with CM9 A.06) edit: I was curious and redid it after rebooting: Stock - 2816.1ms Chrome - 2928.1ms (!) So it turns out it's faster on systems under load, but actually slightly slower on freshly booted one. Weird. In case anyone is interested in full benchmarks: Stock: htt…

I believe that both browsers are based on WebKit and V8 (that's what they've said about the stock browser in the past, anyway), so your results aren't too surprising. The Chrome app adds a bunch of new features, better UI, and makes the browser into a real, bona fide app.

That's my read on it, anyway.

Re: Introducing Chrome for Android

#204

Post by nextparadigms »

dpifke wrote: post #142
dochtman wrote: post #111

Earlier quoted context omitted.

Why in the world is this restricted? I live in the Netherlands, and I really don't get what's so hard about releasing here. Sure, we're a small market, so not as important, but still... Software is global, man!

Software may be global, but patent licenses for things like codecs aren't.

Why are they even bothering with h.264 anymore? Didn't they want to remove it from Chrome since like version 10? It's about time they start to aggressively push for WebM, if it's ready.

Re: Introducing Chrome for Android

#205

Post by TwoBit »

The problem with FireFox on my (512 mb) phone is that the OS usually kills it when I switch to another app (even tiny apps like messaging), and it's a slow FireFox restart if I want to use it again. The OS doesn't do this with the stock browser.

Re: Introducing Chrome for Android

#206

Post by rodion_89 »

klausa wrote: post #132

It appears to be significantly faster on JS front than stock Browser. Sunspider results: Stock - 3852.2ms Chrome - 3131.8ms (tested on HP Touchpad with CM9 A.06) edit: I was curious and redid it after rebooting: Stock - 2816.1ms Chrome - 2928.1ms (!) So it turns out it's faster on systems under load, but actually slightly slower on freshly booted one. Weird. In case anyone is interested in full benchmarks: Stock: htt…

ICS on Nexus S.

  Browser - 4432.6 ms
  Chrome  - 3258.4 ms
EDIT: Didn't reboot or anything like that.

Re: Introducing Chrome for Android

#207

Post by zobzu »

tikhonj wrote: post #173
nuclear_eclipse wrote: post #156

Earlier quoted context omitted.

Then their algorithm isn't consistent, as shown by screenshot. Some comments on HN are "boosted", while others remain tiny. This also makes it impossible to reliably hit any of the other page controls, like voting, without having to manually zoom way in and then back out.

Of course, the voting arrows are hard to hit even on a normal browser! I actually really like the idea of adjusting text size like this, but the particular implementations of this idea may be less than ideal. I'll have to play around with it when I get the chance and see what it's like.

they're ok on a normal browser.. arrows are many pixels wide and the cursors are 1 or 2 pixels wide.

on mobile.. your finger takes like 50 pixels; so yeah.

Re: Introducing Chrome for Android

#208

Post by ReturnTheGift »

nookiemonster wrote: post #202
trotsky wrote: post #16

Decoupling the browser from the OS is one of the best things that could happen for android security going forward. While it won't help people who can't get upgrades to ICS, at least it will solve the future problems of people who get stuck on 4.x while their OS browser slowly becomes more and more exploitable. I have one phone that is still on 2.2 - it is trivially easy to own the phone with a little bit of javascrip…

trivially? please, more detail. Also: own is a loaded term. Please, more detail. Getting access to the sdcard is not the same as owning.

I presume trotsky is referring to the "content://" URI vulnerability found by Thomas Cannon:

http://thomascannon.net/blog/2010/11/android-data-stealing-v...

http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2010-480...

http://www.securityfocus.com/bid/48256/info

Exploit needs to be able to determine the exact path + filename of any file to be stolen. The securityfocus.com entry referenced above includes a demo script implementing the exploit if you want to see the details. Just wrap the XHR requests to the local URIs in a try/catch and go fishing for filenames of interest within standard directories. As mentioned in Cannon's original article, photos would be an easy target given the common location plus filename format for the jpg files (e.g., /sdcard/DCIM/Camera/IMG_yyyymmdd_hhmmss.jpg). Another interesting directory to poke around in would be /sdcard/Android/data/com.dropbox.android/files/scratch/. I tweaked the demo script a bit and was able to steal my own dropbox files and photos on my junky little LG Optimus V on Android 2.2.1. Good Times.

Re: Introducing Chrome for Android

#209

Post by zobzu »

sern wrote: post #56

And in typical Google fashion, they have assumed that devices have an infinite amount of memory: https://imgur.com/zkh7C (this is with the app in the background!)

this might be because: - its loading its own webkit/js lib - it might be multiprocecss (is it?)

I'm wondering how much firefox nightly uses on your phone

Re: Introducing Chrome for Android

#210

Post by cromwellian »

rsynnott wrote: post #190
jonknee wrote: post #88

Earlier quoted context omitted.

> USB Web Debugging That will be great. Even better if iOS gains something similar--it's maddening to not have a real debugger.

See this thing: http://www.iwebinspector.com/

Simulator != real device
Post reply on HN