|
The phone's web browser is a slightly out of date version of
NetFront, an embedded mini-browser designed for mobile deployment. Well,
if you consider a 5 Mb footprint as "mini".
The number of reported security issues in this appears to be vanishingly
small compared to its bigger cousins, and one of the first things I
noticed while messing with phones in the store was the option to disable
Javascript. That alone will head off a large fraction of the web-based
client-side exploits and traps that are out there -- assuming that the
option truly turns off all scripting. As a routine user of "lynx" which
is a terminal-oriented, text-based browser that doesn't handle scripting
or pictures or stylesheets or any of that extra web-fluff, anything that
caters to those of us preferring a lean, less complex environment gets many
plus points in my book. It even allows disabling sending Referer: lines
for a modicum of greater surfing privacy; unfortunately this is not balanced
by also having control over User-Agent and various other headers.
And in the HTTP headers is also one of the browser's major security downfalls: it *always* sends one of the form ClientID: basE64stRIngwhich is not only a non-standard header, it only has meaning within Sprint's own infrastructure. But the header is sent to every server queried, appears to be invariant, and thus constitutes a way for any website to reliably identify a single subscriber even if they don't know specifically who it is in real life. I trapped the set of headers by simply listening on a random port at a reachable server and then telling the phone's browser to visit there, and snagged the goodies when the connection arrived from 68.28.115.somethingorother. Worse, the header is also likely used as an authenticator to things like the *billing* site, which can identify a particular account from it -- so that when the phone interacts with "vision.sprintpcs.com" and similar Sprint sites it immediately has information on who's asking without the user having to specifically log in. This is Sprint's fault as opposed to that of Access that makes the browser software; it gets customized for each target device. Sprint offers a rather lame rationale for all this on one of their developer forums. [For a good laugh, remove the "&forumId=118" part from that URL and look at the resulting page source.] They clearly have not thought through the risks of trusting the client, especially with the number of rooted smartphones running around out there. Depending on User-agent or anything else a client can trivially modify is idiotic, but a lot of sites still do it because they've allowed far too many browser-specific dependencies creep into their code. What if a client brower doesn't send one, or sends a random one from a list of a hundred or so very different types [as the proxy on my laptop can]? Let's just say I see a lot of "oops, internal server error" pages in my travels. The ClientID base64 string encodes nine bytes which don't spell anything or appear to have an obvious relationship to the phone number or account number, but the forum-posting hint that the ClientID is "encrypted" doesn't convince me that it's safe to send beyond the immediate Sprint facilities at all simply because since it is static it can be replayed. Grab someone else's ClientID string, and then you can probably go muck with their customer account especially if you can come from the wireless-service cloud. Note the page-1 comments on "tethering", where it doesn't always have to be a captive app on the phone that's doing the talking. Sprint seems to think that this could never happen. They're too busy dropping sketchy ads for ringtones and girlie pix into your stream just to make their own site abysmally slow to load. The real kicker? None of the Sprint-side traffic ever gets encrypted, including when someone goes to make a *payment* via the phone. The page to enter credit card or other billing information is NOT SSLed, it just flies up to Sprint's site in the clear. The browser *can* do SSL, but evidently the misguided webk1dZ at Sprint think the wireless cloud *and* where it hits the ground are "private" enough that they don't force that for sensitive information. Heh. The only time I'll actually use that facility will be to burn the dumbass "prepaid AMEX" card that their mail-in rebates now come as to pay part of some future bill, and then shred the thing. [Why any business wants to form these affiliations with AMEX I cannot imagine, because a lot of merchants won't accept their cards at all.] I can't quite determine which web traffic gets massaged by a WAP gateway or not, but it's clear that "mobile-friendly" sites format their output in various ways for better small-screen readability. In many cases this requires trying to keep control over future connections, in which Google is notable in that it also implies a fairly clear privacy issue. In a set of search results, clickable links that would go directly to sites with the information are instead vectored through Google which can then produce a reformatted version. To see this in operation, fire up a "real browser" and note carefully the behavioral difference between http://www.google.com/search?q=golden+gate and http://www.google.com/m/search?q=golden+gate where the difference is the "/m/" implying that we want the mobile version. Hover over some of the output links in both cases. In the second case, everything is channeled through Google's gateway via "http://www.google.com/gwt/x?..." and many of the links in *that* content are massaged in a similar way as the data comes back, so Google gets to see everything you visit from search results and beyond. There are times this can be useful, as it'll also render PDFs as HTML text which works around the fact that the phone doesn't seem to have a PDF reader built in. And of course Sprint encourages the phone users to dive into this swamp even more readily by having a "sprint search" item hardwired into the browser's menus that backends out to Google's mobile-aware facilties anyway. While this departs somewhat from discussion of the phone it should be pointed out that Google's search-results relaying can be a two-edged sword -- for some value, albeit only for permitted destinations, it also amounts to free proxying where Google makes the connection to the endpoint. This is with the caveat that it does send the real origin as an X-Forwarded-for header. For example, asking for http://www.google.com/gwt/x?u=http://www.someplace.org/pages/whatever.htmlcauses the server to see
GET /pages/whatever.html HTTP/1.1
User-Agent: Mozilla/5.0 (en-us) AppleWebKit/534.14 (KHTML, like Gecko;
Google Wireless Transcoder) Chrome/9.0.597 Safari/534.14
Accept: text/html, application/xhtml+xml, text/plain, image/*, */*; q=0.1
Host: www.someplace.org
X-Forwarded-For: 41.205.116.23
Accept-Encoding: gzip
and that works from everywhere, not just a phone, and without all the
intervening guk that Google tends to drop into the search-results links
that it generates. It also changes the User-agent line. Most servers do
log the Forwarded-for IP as the client, so it doesn't gain any real privacy
especially when Google's still watching all this go by, but it might be
useful to work around various other problems.
Unfortunately, the little NetFront mini-browser doesn't show you where any of the links on a displayed page are *about* to go if you click them, let alone letting you change them before actually visiting, so you're a bit hobbled in making intelligent decisions about what to follow. Showing destinations would have been easy to do as pop-up balloons or something just like in almost any other app that handles links. It does an okay job rendering regular non-mobilized [or is that mobilified, or mobilated, or ...?] pages as well, offering an "overview mode" that scales the whole page to the full screen and allows highlight movement around to specific areas within it before zooming back in to a readable size. It seems to eventually choke and freeze when the "error logging" facility is turned on, possibly because all that gets held in memory. Ironically, with the logging turned on Sprint's very own "vision" homepage generates a slew of CSS errors, and in some early playing around the browser hung so hard that the entire phone was locked up. It must have a watchdog timer, because after about 30 seconds of brick-like functionality it reset as though I had just powered it on. But with logging off and a few bookmarks defined up to access known resources, it's good enough to bring me what I need without the overhead of a full-bore smartphone. And it's easy to clean up afterward, with a few checkboxes for deleting cache/cookies/history. For more perspective on embedded browsers, there's a useful overview of several different efforts here. I know that none of this is new to many people, but just now getting into a little bit of the mobile data picture makes it new to me and when viewed from the security-curmudgeonly point of view, a lot of what goes on here is immediately intrusive and/or lame. At least I couldn't back-scan the address that my test connection came in from in any obvious fashion and didn't see any received-data on the EVDO traffic icon while trying, so the gateways possibly offer a little protection from teh big bad internetz as a whole. But the majority of problems relating to phones are likely to be client-side issues anyway. I'm sure this one has its share of bugs but at least it doesn't seem to be in the class of high-profile targets at the moment, and backing that up with common sense about usage probably counts for far more. So there you have it. I've figuratively got the world at my hip now, but it remains to be seen how useful this winds up being for roadtrips and such. Out west I will undoubtedly need to roam for both phone and data, as Sprint's coverage in the wide open spaces is spotty at best. They never heard that guy singing, "oh give me a phone / where the buffalo roam ..." |
Go back to Page 1: features