In email exchange, the threat here is that pages can track the users browsing in a single tab because the tab id is the same. While we strip the tab id from going out over the wire, it's still present in navigator.userAgent and thus accessible to the page. 

We've had this behavior since our launch 2 years ago, so it's not necessarily a blocker, but putting that tag so that it gets some immediate tracking and the auto-punter doesn't touch it.

Choosing droger as initial owner. 

There is no API in iOS to know, in the network layer, from which UIWebView a network request is coming from.

What you see in these twitter reports is a side effect of the solution we implemented to bypass this limitation: all the UIWebViews get the tabID (which is only local to the device) added to the user agent string. When a request is processed in the network stack this ID is used to collate requests from the same UIWebView together.

The tabID is then stripped off from the user agent before the request goes over the network. Again: this tab ID is not send over the network, only the normal user agent is send.

The only place the modified user agent is visible from is navigator.userAgent.

As for what this feature allow us to do here is a non exhaustive list:

- Attaching SSL info to a page
- Page level validation for example, making sure non-ssl request on a ssl page are flagged properly. 
- Progress bar on handsets
- Routing incognito requests differently from non-incognito one so nothing is saved to disk
- Making error pages/safe browsing/SSL errors appear on the right UIWebView
- Stop all the network requests for a UIWebView when it is deallocated
- etc... etc...

See also bug 227989, specifically comment 15; we don't know of any way to strip this out from the JS side that doesn't break things.

So the options I see are::
- Find a new way to implement RequestTracker
- Use something that's not unique across users (e.g., start a counter from 1, and recycle numbers whenever possible)
- Change the ID for a tab ~every page load (not sure if that's actually feasible; we'd at least have to do a bunch of bookkeeping to route the current *and* previous ID on the network side back to the corresponding Tab, but there might also be issues with restore)

We tried to fix this in the past, by swizzling the navigator object. The issues were:
1) we sometimes don't swizzle early enough, and thus sometimes it still leaks. We're making progress on this and we can expect being able to swizzle early enough in *most* cases.
2) some websites were broken. MapQuest was one of them (https://code.google.com/p/chromium/issues/detail?id=227989), but looking at this bug maybe we can fix it?

A probably-more-feasible version of the last would be:
- Reset in on each UIWebView creation (eviction restore, native page).

droger: For (1), see the discussion I linked to in bug 227989. It's not a case of JS injection timing, it's a limitation of when it's possible to replace navigator.

The next major release won't use a GUID to associate requests with tabs; it will be based on a partially-randomized counter within a specific range. The result will be unique within a run of the app, but common throughout the entire population of users.

Later we may implement a recycling strategy to reduce the range significantly, but that requires more restructuring than could safely be done for M34.