Is there any word on how this '4K' actually looks at bitrates Youtube can push enough ads to pay for, and your ISP will permit?
I have the greatest respect for people who actually handle the challenges of paying the computational costs of video compression and decompression (and scaling if necessary) as efficiently as possible; but once their work is done, a nominal resolution (even an actual X pixels by Y pixels value, not some marketing bullshit) is nearly meaningless unless you are in the (rare for video, probably less rare for audio) situation of having such a high bitrate that the quality of your reproduction is being constrained by your resolution.
Barring an increase in bitrate, will it even be possible to distinguish between Xmb/s nominally 1080 video scaled up to 4k and Xmb/s nominally 4k video?
I thought that 'RAGEMASTER' was a particularly elegant, if unnerving little toy... Totally passive, delivers the tempest attack from hell when illuminated by a remote RF source. They had some similar mechanisms for tapping keyboards as well. Time to break out the Tinfoil Compute Enclosure, I suppose.
If you can already infect inside computers, do you really need to hack the router?
Two major upsides: hitting the router is a handy way to turn an exploit of a single machine into a position for eavesdropping and/or DNS attacking every device on the network. Odds are good that the one you exploited directly isn't the only one, and the others may be harder targets from the outside. Plus, the router is a handy 'bastion' for re-infection and persistence in case the luckless user finally ditches or wipes his worm farm of a system. Unless you screw it up, badly, most people are barely aware that routers contain software at all, so odds are excellent that they won't be getting rid of you in the near future...
'Pardon' would be better. I'd prefer to see 'ticker-tape parade to the Capitol, down a street lined with intelligence creeps hanging from the lampposts'; but I'm told that my pony is being held up by customs...
That sounds dangerously like a suggestion that the assorted vendor lock-in products should inter-operate with one another in some sane way... True endarkenment is only achieved when each product has some stupid dependency on the others; but not anything that would actually make the whole mess easier. Making a 'cloud' service dependent on a local MS server/client setup, for instance, is excellent; but having that 'cloud' service capable of authenticating against your AD, rather than it's own half-assed credentials system, totally spoils the effect....
Why make a contentious choice between bzr and git when we could implement a new, metalevel distributed revision control system that supports revision control across multiple revision control systems, each potentially running on multiple nodes?
Given sufficient time, I'm sure we can generalize away any petty disagreements!
Given that emacs is Turing-complete, it might be said that it includes all possible features. Some, of course, are available out of the box, while some require considerable configuration (mysteriously, this configuration process takes almost exactly the same amount of time as re-implementing the feature in emacs Lisp...)
The original source (ESR himself) never mentioned GitHub. Just git. Can people stop conflating the two please?
C'mon, man, get with the times. Having 'protocols' with 'definitions' that allow for 'multiple vendor-neutral implementations' is so totally outdated, man. Everybody knows that the future is snappily named proprietary services dependent on a single vendor with a nonsensical business model, ideally accessible only through an iPhone app!
While such a position is surprisingly non-toadying for the NYT, fuck 'clemency'. 'Clemency' is the merciful withholding of some portion of a deserved punishment. Since Snowden deserves a hero's welcome, rather than any punishment, 'clemency' is an insult.
If there's anyone who is in a position to be begging for 'clemency' it's the Oh-So-Very-Serious-and-Responsible spooks currently whining about how much damage Snowden has allegedly done to their hitherto impressive record of completely and utterly unverifiable or demonstrable terrorist hunting.
But what I am interested in is: 1) how many people actually complete; and 2) what quality of education those who complete have actually received. A course where 1000 people complete and 100 drop out vs. a course where 1000 people complete and 5000 drop out has a very different graduation rate, but both have educated 1000 people. The main worry would be whether the 2nd case has degraded the quality of education, by diluting how many attention the 1000 students who finished the course get... the other 5000 could take up a lot of TA/instruction/etc. resources.
I share your suspicion about much of the attrition (signing up for some MOOC is a lot like getting a discount gym membership to go with your New Years' resolution: cheap to do, easy to quit).
However, in addition to your question about quality for graduates, I have one additional concern: much of the hype about MOOCs is not "Hey, this is a cool new way for motivated autodidacts to pick up stuff that you might not find at the local library!"; but various flavors of hype about how Disruptive New Models And Stuff with save us from stratospheric tuition and the higher education bubble and so on. If MOOCs deliver massive attrition, anybody selling that line is either deluded, or just has no interest in the consequences for 'b grade' students who are already most likely to need a bit of coaching to learn to potential.
So long as it's all good fun among consenting participants, MOOCs are under no obligation to produce any particular results at all (though obviously their backers hope that they will), and if the costs are low enough almost any benefit is a net win. However, the minute somebody steps out of their area of strength and starts peddling them as a cheap, innovative, disruptive, etc. alternative to boring old legacy education, they really take on the burden of actually doing reasonably well.
That's what worries me: MOOCs themselves are great stuff, for the sorts of students who have to be actively sabotaged to keep them from learning; but initial results suggest that efficacy plunges once you get outside that category. This is unfortunate; but merely a pity until some huckster shows up with a proposal to replace existing models.
Oh, I'm sure that they are carefully billing the workers for whatever cheap crap they are using. Debt peonage isn't terribly innovative; but it's a time-tested solution to ensure workplace docility.
Just getting out the shackles and whips is discouraged; but there are so many ways of achieving de-facto slave labor...
Oh gosh. This is not a very good precedent. I hope the children are taught that:
-The radiation from WIFI is the same type as what comes from the Sun, which is essential for all life on earth.
-We all emit radiation.
As much as I think that these Kiwis are being a bit cracked (though, by the standards of grieving processes for dead children, I've certainly heard stupider strategies...), those are terrible 'educational' points.
They fall in the horrible zone of being nonfalse; while also eliding virtually all the important distinctions, and providing the poor sucker handed them basically no useful information on which to found decisions.
Is RF in the 2.4 and/or 5GHz band electromagnetic radiation, and thus in the same broad category as (much) of what the Sun emits? Sure. Is that largely meaningless when the flavors of electromagnetic radiation run from extremely longwave RF whose interactions with matter are barely discernable without specialized antennas, all the way to very high energy gamma radiation, with a lot of variety in between, and numerous different uses and effects for various bands? Unfortunately so.
Do we all emit radiation? Sure, in modest quantities. Does that tell us anything useful about radiation safety? Only that the default dose is higher than zero, and that apparently doesn't kill you horribly most of the time. Nothing else.
If you want to talk about safety, arguments from broad classes of things that have some nominal commonality are painfully useless. If you aren't at least introducing concepts related to dosage, population level statistical study, various epidemiological techniques, you are basically just waving your hands from first principles.
If memory serves, they were both 'APC Smart-UPS XL 2200 VA RM 3U 120V' devices. Not elite datacenter stuff (but they were only supporting some peripheral wiring closets, so the load didn't justify anything really serious); but not the best-buy grade junk.
The UPSes in question had both been handling the same load for over a year (with no trouble reports from the little network management card widget) when they died, so I don't think that it was excess draw. It also wasn't 'died' as in 'popped a breaker for safety reasons'; but as in 'all management interfaces, NIC, serial, LEDs on the front and all power outputs go silent, no amount of poking brings the device back to life'.
The Atrix had two cores; but the linux 'desktop' it popped up when put into the "lapdock" accessory wasn't really a separate system (except in that there was absolutely no meaningful integration between the Android side and the 'desktop' side). It was just some Ubuntu-on-ARM stuff running as a less-impoverished-than-usual native linux userland on an Android system.
You can do much the same on basically any non-lockdown Android system; but there tends not to be much point. Getting access to pure linux applications from the Android environment is a bit awkward (X servers and terminal clients exist; but are generally aimed at talking to external hosts) and any android-related stuff (contacts, SMS, etc.) is in a more or less opaque blob as far as the linux userland is concerned(again, it can be done, and various Android tweaker/power-user modding does commonly involve hitting the Android system from the perspective of the root user on the linux system it lives on; but there is essentially zero useful integration).
Especially if you have a recent x86 to work with, I can't imagine why you would choose android as the 'lightweight VM for specific tasks' OS. VMs are absurdly useful; but android is a pretty mediocre experience on anything not designed as touchscreen hardware, usually without a keyboard or mouse.
Who the fuck wants this? Sure, Windows sucks but why would cramming a shitty OEM version of Android make things better?
I suspect that PC OEM's versions of Android will be awful, and probably emphasize every single rough edge that Android has (in particular if it ends up on desktops or non-touchscreen laptops: Android works; but it tends not to take too long to discover some awkwardness in handling devices that lack certain buttons, or have an unexpected screen size, probably from a monitor with crap EDID, or that mix mouse, keyboard, and touch events); but I imagine that it's a cheap way to scare Microsoft, and scaring Microsoft is probably the single largest source of leverage over suppliers (with the possible exception of trying to get marketing kickbacks from Intel) that a PC OEM has. HDDs, RAM, board stuffing, all those guys are on razor-thin margins already, so MS and Intel are the only suppliers who still have margins left to cut.
I've had at least two UPSes add injury to insult by simply dropping dead and failing to even act as a power strip, merrily cutting power to everything attached to them despite mains power being available (and every 'unprotected' device not even flickering). Thanks a lot APC...
For casual users, anything with a steep learning curve (no matter how powerful) is a tough sell because they'll probably spend more time learning than they would save. Trying to evangelize them may be morally satisfying; but is largely pointless.
For people who actually want to do something computer related, at scale, surely anybody sharp enough to be left unsupervised near a computer will learn (the hard way, if necessary) why we use tools with steep learning curves and great power: because the alternative is an essentially unbounded amount of error-prone manual labor.
If that doesn't become clear to them fairly quickly, either the GUI tools are working just fine for them, or they aren't in an area where the CLI really shines, or they should really consider doing something else. You shouldn't need to turn on the hard sell.
Choices of specific tools, with their quirks dating back to design constraints or decisions made, in some cases, before today's students were born are largely a matter of taste; but the use of tricky but high-powered tools swiftly shows itself to be necessary. You just can't click fast enough, even if you wanted to.
My intended point is: while Google does a bunch of interesting things, what makes them money is advertising, the rest is side projects and strategic plays.
They have gotten quite good at this; but getting the data they need is not automatic. They need to draw users in to their own properties, sell site admins on their analytics tools and adsense, and generally build both their surveillance/tracking capacity and their ad delivery capacity.
Your ISP, by contrast, is the one who delivers your requests to their destinations and what you requested back to you. Just for doing what you (over)pay them for, they have activity logs (correlated to a real person, a real address, and a real CC number, no less) as good or better as anybody who depends on tracking code embedded in individual pages. The one exception is encrypted sessions, where they have only information about who you were connected to, when, and how much traffic passed between you. Enough to make some educated guesses; but the details are obscured. So, they have access to analytics data bounded primarily by their competence, and all as a necessary side effect of doing their job.
It terms of squeezing money out of the delivery side, I don't think that the issue of on-the-fly rewrites to inject your own ads has been litigated yet, though bottom feeders flirt with it, and it would certainly be cheaper than paying site operators if it is in fact legal. Similarly unclear, for the moment, is how much latitude ISPs have in shaking down content guys for the 'privilege' of having their stuff make it intact and undelayed to the ISP's subscribers. That sort of blackmail hasn't been clearly decided one way or the other; but it's a hell of an advantage if you do get to exercise it, given users' low tolerance for delays.
I get the unpleasant impression that, just as the patent office treats "Do something obvious but on a cellphone!" as a totally novel invention, a lot of 'apps' are hell-bent on ignoring the (not exactly ironclad) advances in security applied to programs written for typical computers and re-learning, the hard way, what the PC crew had to learn once internet connections became a thing...
At least it can make for interesting reading, if it's some other sucker's phone...
I apologize if my intent wasn't clear; but I drew the 4GB distinction not because I assumed that x32 would limit the system as a whole to 4GB; but because that's the point where limiting a process to 4GB becomes an actual tradeoff:
If you don't even have 4GB of RAM, your application isn't going to have a chance to use more than 4GB, because they don't exist, so being 'limited' to a 32-bit address space is mostly irrelevant, since you'll bump into physical limits first (it might unacceptably reduce the amount of entropy that various ASLR schemes can bring to bear, since the layout randomization is happening within a vastly smaller memory space; but I definitely don't understand the strengths and weaknesses of that stuff well enough to say whether that is real or almost wholly theoretical, or irrelevant).
If you do have more than 4GB, accepting a 4GB process limit becomes a real tradeoff, since you won't hit a physical limit first. For many processes, it won't be a difficult choice, the world is rotten with little helper processes and things that should never consume more than a few MB under any conditions; but for some borderline cases it could be an issue that you have to think about, test, etc.
True, though people hacked the snapchat client up, down, and sideways the moment snapchat was silly enough to insinuate some degree of security and/or when they realized that it would make scoring amateur porn easier, and to the best of my knowledge no such local storage was located. Pitifully sloppy deletion, yes; but not any intentional caching.
If you control the AP, tapping wireless is pretty much identical to tapping wired(whether your 'AP' is also the computer doing the tapping, running an adapter in ad-hoc or AP mode, or whether the computer doing the tapping is sniffing the AP's ethernet link). What makes me nervous is the possibility that (mostly likely out of malice) a phone app might deliberately avoid chatting on any interface except the cellular connection. Non-malicious apps (or malicious apps that assume you aren't paying attention) can presumably be forced over to wifi and sniffed like any computer; but something that maintains silence except when connecting through the cell network would be very hard to pin down.
RF sniffing to establish the the existence of traffic isn't that hard (doesn't everyone seem to own a set of cheap speakers that provides that 'feature' for free?); but anything more than very rough estimates of traffic volume would be orders of magnitude more difficult than anything running over your network...
Isn't Google's hardware strategy based around vast numbers of expendable, replaceable, generic systems operated as cheaply as possible?
Google healthcare would boil down to "This node is uneconomic to repair, it has been sent for recycling and a failover node whose internet browsing habits most closely resemble those of the failed node has been dispatched to replace it. If any of your personal or professional relationships depended on the failed node, please try refreshing your browser."
It would be an unbelievably terrible plan; but We Have The Technology to implement a fairly robust 'trusted computing' dystopian system. Contemporary consoles are already edging close to the point where you need a hardware attack to get in (which makes mass-compromises slower, more expensive, and more time consuming, unlike software hacks) and a bit of origin metadata and a default-deny policy would make 'depublishing' all material originating from traitor systems on all compliant systems quite doable.
That wouldn't prevent the existence of darknets; but it would push them well beyond the reach of Ma and Pa iPad(speaking of lockdown appliances..)
Is there any word on how this '4K' actually looks at bitrates Youtube can push enough ads to pay for, and your ISP will permit?
I have the greatest respect for people who actually handle the challenges of paying the computational costs of video compression and decompression (and scaling if necessary) as efficiently as possible; but once their work is done, a nominal resolution (even an actual X pixels by Y pixels value, not some marketing bullshit) is nearly meaningless unless you are in the (rare for video, probably less rare for audio) situation of having such a high bitrate that the quality of your reproduction is being constrained by your resolution.
Barring an increase in bitrate, will it even be possible to distinguish between Xmb/s nominally 1080 video scaled up to 4k and Xmb/s nominally 4k video?
I thought that 'RAGEMASTER' was a particularly elegant, if unnerving little toy... Totally passive, delivers the tempest attack from hell when illuminated by a remote RF source. They had some similar mechanisms for tapping keyboards as well. Time to break out the Tinfoil Compute Enclosure, I suppose.
If you can already infect inside computers, do you really need to hack the router?
Two major upsides: hitting the router is a handy way to turn an exploit of a single machine into a position for eavesdropping and/or DNS attacking every device on the network. Odds are good that the one you exploited directly isn't the only one, and the others may be harder targets from the outside. Plus, the router is a handy 'bastion' for re-infection and persistence in case the luckless user finally ditches or wipes his worm farm of a system. Unless you screw it up, badly, most people are barely aware that routers contain software at all, so odds are excellent that they won't be getting rid of you in the near future...
'Pardon' would be better. I'd prefer to see 'ticker-tape parade to the Capitol, down a street lined with intelligence creeps hanging from the lampposts'; but I'm told that my pony is being held up by customs...
That sounds dangerously like a suggestion that the assorted vendor lock-in products should inter-operate with one another in some sane way... True endarkenment is only achieved when each product has some stupid dependency on the others; but not anything that would actually make the whole mess easier. Making a 'cloud' service dependent on a local MS server/client setup, for instance, is excellent; but having that 'cloud' service capable of authenticating against your AD, rather than it's own half-assed credentials system, totally spoils the effect....
Why make a contentious choice between bzr and git when we could implement a new, metalevel distributed revision control system that supports revision control across multiple revision control systems, each potentially running on multiple nodes?
Given sufficient time, I'm sure we can generalize away any petty disagreements!
Given that emacs is Turing-complete, it might be said that it includes all possible features. Some, of course, are available out of the box, while some require considerable configuration (mysteriously, this configuration process takes almost exactly the same amount of time as re-implementing the feature in emacs Lisp...)
The original source (ESR himself) never mentioned GitHub. Just git. Can people stop conflating the two please?
C'mon, man, get with the times. Having 'protocols' with 'definitions' that allow for 'multiple vendor-neutral implementations' is so totally outdated, man. Everybody knows that the future is snappily named proprietary services dependent on a single vendor with a nonsensical business model, ideally accessible only through an iPhone app!
While such a position is surprisingly non-toadying for the NYT, fuck 'clemency'. 'Clemency' is the merciful withholding of some portion of a deserved punishment. Since Snowden deserves a hero's welcome, rather than any punishment, 'clemency' is an insult.
If there's anyone who is in a position to be begging for 'clemency' it's the Oh-So-Very-Serious-and-Responsible spooks currently whining about how much damage Snowden has allegedly done to their hitherto impressive record of completely and utterly unverifiable or demonstrable terrorist hunting.
But what I am interested in is: 1) how many people actually complete; and 2) what quality of education those who complete have actually received. A course where 1000 people complete and 100 drop out vs. a course where 1000 people complete and 5000 drop out has a very different graduation rate, but both have educated 1000 people. The main worry would be whether the 2nd case has degraded the quality of education, by diluting how many attention the 1000 students who finished the course get... the other 5000 could take up a lot of TA/instruction/etc. resources.
I share your suspicion about much of the attrition (signing up for some MOOC is a lot like getting a discount gym membership to go with your New Years' resolution: cheap to do, easy to quit).
However, in addition to your question about quality for graduates, I have one additional concern: much of the hype about MOOCs is not "Hey, this is a cool new way for motivated autodidacts to pick up stuff that you might not find at the local library!"; but various flavors of hype about how Disruptive New Models And Stuff with save us from stratospheric tuition and the higher education bubble and so on. If MOOCs deliver massive attrition, anybody selling that line is either deluded, or just has no interest in the consequences for 'b grade' students who are already most likely to need a bit of coaching to learn to potential.
So long as it's all good fun among consenting participants, MOOCs are under no obligation to produce any particular results at all (though obviously their backers hope that they will), and if the costs are low enough almost any benefit is a net win. However, the minute somebody steps out of their area of strength and starts peddling them as a cheap, innovative, disruptive, etc. alternative to boring old legacy education, they really take on the burden of actually doing reasonably well.
That's what worries me: MOOCs themselves are great stuff, for the sorts of students who have to be actively sabotaged to keep them from learning; but initial results suggest that efficacy plunges once you get outside that category. This is unfortunate; but merely a pity until some huckster shows up with a proposal to replace existing models.
Oh, I'm sure that they are carefully billing the workers for whatever cheap crap they are using. Debt peonage isn't terribly innovative; but it's a time-tested solution to ensure workplace docility.
Just getting out the shackles and whips is discouraged; but there are so many ways of achieving de-facto slave labor...
Oh gosh. This is not a very good precedent. I hope the children are taught that: -The radiation from WIFI is the same type as what comes from the Sun, which is essential for all life on earth. -We all emit radiation.
As much as I think that these Kiwis are being a bit cracked (though, by the standards of grieving processes for dead children, I've certainly heard stupider strategies...), those are terrible 'educational' points.
They fall in the horrible zone of being nonfalse; while also eliding virtually all the important distinctions, and providing the poor sucker handed them basically no useful information on which to found decisions.
Is RF in the 2.4 and/or 5GHz band electromagnetic radiation, and thus in the same broad category as (much) of what the Sun emits? Sure. Is that largely meaningless when the flavors of electromagnetic radiation run from extremely longwave RF whose interactions with matter are barely discernable without specialized antennas, all the way to very high energy gamma radiation, with a lot of variety in between, and numerous different uses and effects for various bands? Unfortunately so.
Do we all emit radiation? Sure, in modest quantities. Does that tell us anything useful about radiation safety? Only that the default dose is higher than zero, and that apparently doesn't kill you horribly most of the time. Nothing else.
If you want to talk about safety, arguments from broad classes of things that have some nominal commonality are painfully useless. If you aren't at least introducing concepts related to dosage, population level statistical study, various epidemiological techniques, you are basically just waving your hands from first principles.
If memory serves, they were both 'APC Smart-UPS XL 2200 VA RM 3U 120V' devices. Not elite datacenter stuff (but they were only supporting some peripheral wiring closets, so the load didn't justify anything really serious); but not the best-buy grade junk.
The UPSes in question had both been handling the same load for over a year (with no trouble reports from the little network management card widget) when they died, so I don't think that it was excess draw. It also wasn't 'died' as in 'popped a breaker for safety reasons'; but as in 'all management interfaces, NIC, serial, LEDs on the front and all power outputs go silent, no amount of poking brings the device back to life'.
The Atrix had two cores; but the linux 'desktop' it popped up when put into the "lapdock" accessory wasn't really a separate system (except in that there was absolutely no meaningful integration between the Android side and the 'desktop' side). It was just some Ubuntu-on-ARM stuff running as a less-impoverished-than-usual native linux userland on an Android system.
You can do much the same on basically any non-lockdown Android system; but there tends not to be much point. Getting access to pure linux applications from the Android environment is a bit awkward (X servers and terminal clients exist; but are generally aimed at talking to external hosts) and any android-related stuff (contacts, SMS, etc.) is in a more or less opaque blob as far as the linux userland is concerned(again, it can be done, and various Android tweaker/power-user modding does commonly involve hitting the Android system from the perspective of the root user on the linux system it lives on; but there is essentially zero useful integration).
Especially if you have a recent x86 to work with, I can't imagine why you would choose android as the 'lightweight VM for specific tasks' OS. VMs are absurdly useful; but android is a pretty mediocre experience on anything not designed as touchscreen hardware, usually without a keyboard or mouse.
Who the fuck wants this? Sure, Windows sucks but why would cramming a shitty OEM version of Android make things better?
I suspect that PC OEM's versions of Android will be awful, and probably emphasize every single rough edge that Android has (in particular if it ends up on desktops or non-touchscreen laptops: Android works; but it tends not to take too long to discover some awkwardness in handling devices that lack certain buttons, or have an unexpected screen size, probably from a monitor with crap EDID, or that mix mouse, keyboard, and touch events); but I imagine that it's a cheap way to scare Microsoft, and scaring Microsoft is probably the single largest source of leverage over suppliers (with the possible exception of trying to get marketing kickbacks from Intel) that a PC OEM has. HDDs, RAM, board stuffing, all those guys are on razor-thin margins already, so MS and Intel are the only suppliers who still have margins left to cut.
I've had at least two UPSes add injury to insult by simply dropping dead and failing to even act as a power strip, merrily cutting power to everything attached to them despite mains power being available (and every 'unprotected' device not even flickering). Thanks a lot APC...
For casual users, anything with a steep learning curve (no matter how powerful) is a tough sell because they'll probably spend more time learning than they would save. Trying to evangelize them may be morally satisfying; but is largely pointless.
For people who actually want to do something computer related, at scale, surely anybody sharp enough to be left unsupervised near a computer will learn (the hard way, if necessary) why we use tools with steep learning curves and great power: because the alternative is an essentially unbounded amount of error-prone manual labor.
If that doesn't become clear to them fairly quickly, either the GUI tools are working just fine for them, or they aren't in an area where the CLI really shines, or they should really consider doing something else. You shouldn't need to turn on the hard sell.
Choices of specific tools, with their quirks dating back to design constraints or decisions made, in some cases, before today's students were born are largely a matter of taste; but the use of tricky but high-powered tools swiftly shows itself to be necessary. You just can't click fast enough, even if you wanted to.
My intended point is: while Google does a bunch of interesting things, what makes them money is advertising, the rest is side projects and strategic plays.
They have gotten quite good at this; but getting the data they need is not automatic. They need to draw users in to their own properties, sell site admins on their analytics tools and adsense, and generally build both their surveillance/tracking capacity and their ad delivery capacity.
Your ISP, by contrast, is the one who delivers your requests to their destinations and what you requested back to you. Just for doing what you (over)pay them for, they have activity logs (correlated to a real person, a real address, and a real CC number, no less) as good or better as anybody who depends on tracking code embedded in individual pages. The one exception is encrypted sessions, where they have only information about who you were connected to, when, and how much traffic passed between you. Enough to make some educated guesses; but the details are obscured. So, they have access to analytics data bounded primarily by their competence, and all as a necessary side effect of doing their job.
It terms of squeezing money out of the delivery side, I don't think that the issue of on-the-fly rewrites to inject your own ads has been litigated yet, though bottom feeders flirt with it, and it would certainly be cheaper than paying site operators if it is in fact legal. Similarly unclear, for the moment, is how much latitude ISPs have in shaking down content guys for the 'privilege' of having their stuff make it intact and undelayed to the ISP's subscribers. That sort of blackmail hasn't been clearly decided one way or the other; but it's a hell of an advantage if you do get to exercise it, given users' low tolerance for delays.
I get the unpleasant impression that, just as the patent office treats "Do something obvious but on a cellphone!" as a totally novel invention, a lot of 'apps' are hell-bent on ignoring the (not exactly ironclad) advances in security applied to programs written for typical computers and re-learning, the hard way, what the PC crew had to learn once internet connections became a thing...
At least it can make for interesting reading, if it's some other sucker's phone...
I apologize if my intent wasn't clear; but I drew the 4GB distinction not because I assumed that x32 would limit the system as a whole to 4GB; but because that's the point where limiting a process to 4GB becomes an actual tradeoff:
If you don't even have 4GB of RAM, your application isn't going to have a chance to use more than 4GB, because they don't exist, so being 'limited' to a 32-bit address space is mostly irrelevant, since you'll bump into physical limits first (it might unacceptably reduce the amount of entropy that various ASLR schemes can bring to bear, since the layout randomization is happening within a vastly smaller memory space; but I definitely don't understand the strengths and weaknesses of that stuff well enough to say whether that is real or almost wholly theoretical, or irrelevant).
If you do have more than 4GB, accepting a 4GB process limit becomes a real tradeoff, since you won't hit a physical limit first. For many processes, it won't be a difficult choice, the world is rotten with little helper processes and things that should never consume more than a few MB under any conditions; but for some borderline cases it could be an issue that you have to think about, test, etc.
True, though people hacked the snapchat client up, down, and sideways the moment snapchat was silly enough to insinuate some degree of security and/or when they realized that it would make scoring amateur porn easier, and to the best of my knowledge no such local storage was located. Pitifully sloppy deletion, yes; but not any intentional caching.
If you control the AP, tapping wireless is pretty much identical to tapping wired(whether your 'AP' is also the computer doing the tapping, running an adapter in ad-hoc or AP mode, or whether the computer doing the tapping is sniffing the AP's ethernet link). What makes me nervous is the possibility that (mostly likely out of malice) a phone app might deliberately avoid chatting on any interface except the cellular connection. Non-malicious apps (or malicious apps that assume you aren't paying attention) can presumably be forced over to wifi and sniffed like any computer; but something that maintains silence except when connecting through the cell network would be very hard to pin down.
RF sniffing to establish the the existence of traffic isn't that hard (doesn't everyone seem to own a set of cheap speakers that provides that 'feature' for free?); but anything more than very rough estimates of traffic volume would be orders of magnitude more difficult than anything running over your network...
Isn't Google's hardware strategy based around vast numbers of expendable, replaceable, generic systems operated as cheaply as possible?
Google healthcare would boil down to "This node is uneconomic to repair, it has been sent for recycling and a failover node whose internet browsing habits most closely resemble those of the failed node has been dispatched to replace it. If any of your personal or professional relationships depended on the failed node, please try refreshing your browser."
It would be an unbelievably terrible plan; but We Have The Technology to implement a fairly robust 'trusted computing' dystopian system. Contemporary consoles are already edging close to the point where you need a hardware attack to get in (which makes mass-compromises slower, more expensive, and more time consuming, unlike software hacks) and a bit of origin metadata and a default-deny policy would make 'depublishing' all material originating from traitor systems on all compliant systems quite doable.
That wouldn't prevent the existence of darknets; but it would push them well beyond the reach of Ma and Pa iPad(speaking of lockdown appliances..)