Based on what you're saying, it seems very possible to me that there are ranges at which the transponder signal can be receive but the skin paint has not.
Signals in both directions will attenuate according to the normal square-of-distance law. Suppose that the aircraft is at a distance from the radar such that the signal is attenuated to just below the detection threshold. That is the radar can not get a skin paint -- but barely. However, the strength of the radar signal that strikes the aircraft at that range is 4X (in an ideal world; in reality its probably even higher) the strength of the signal that arrives back at the radar receiver. This is because doubling the distance (which assumes perfect reflection; in reality it's not quite that good) will quarter the power.
Therefore, the transponder can very likely detect the incoming radar signal -- and respond to it -- at ranges beyond which the radar can get a skin paint, since it receives 4X as much power.
The question, then, is whether the transponder replies with greater energy than the reflection at those long ranges. If so, then there is a zone in which the transponder signal can be detected but the skin paint cannot. Turning off the transponder in that zone would make the plane instantly and completely disappear from radar.
It has been "in progress" for so long that stationary might be a better term.
Did you look at the link? The last update was in January, and described the current status as depending only on one other piece to be ready for launch.
I see. I wouldn't be surprised if this is the root of the problem. They have conflated a web-browser with an OS. No good will come from it except an unfocussed bloated browser and an anaemic OS.
I can see you've never used it.
i) They don't fix the appalling font rendering issues on Windows promptly and as a priority. Most of Google's own web fonts are unusable in production because of this.
I haven't used Windows since about 2000, so I have no comment on this. I will point out that it appears work is in progress: https://code.google.com/p/chro...
ii) They don't follow standard most-recently-used order when ctrl-tab between tabs and they don't see the problem and close any bug report as won't fix.
I disagree with this one. The Chrome tab ordering is better. most-recently-used sucks when you have 20 tabs and have bounced around between them somewhat randomly (as is normal). It makes ctrl-tab completely unpredictable unless you're just jumping back one or two levels. The Chrome way is better.
iii) They start adding animations to html elements you can't restyle with CSS e.g. the zoom ease-in they added to select elements in a recent Chrome.
Got a link to more information? I'm not sure what you're referring to.
There were wide-spread issues on their recent releases. You can only auto-update if you are rock-solid.
Link? I certainly never noticed any issues, but perhaps that's -- again -- because I don't use Windows.
v) They fork from the web-kit project, a once high-point in cross company collaboration for the betterment of the web. Now... beginning of the end.
Nonsense. There is still cross-collaboration between Blink and Webkit, and Google isn't the only company working on Blink.
I also fundamentally disagree with the common
I think the "we should all work on one implementation" theory has basically the same merits as the old Soviet one-gigantic-factory model for production of goods. On the face of it one would think that producing many different designs for one type of product and then building all of them in separate production facilities, distributed through different distribution networks, etc., is very inefficient. One design, one huge factory to maximize economies of scale should be better, right? But history showed that the opposite is true, that a competitive market produces more goods, better goods and does it at a lower cost. The issues in software are different, but at a high level the emergent properties are similar.
vi) And now they are going to spend their time re-implementing a cross-platform widget toolkit.
They already implemented it. It's been used in ChromeOS for a while. My guess is that they've decided it will take less engineer effort to port and maintain Aura than to keep up with Gtk+. I also wouldn't be surprised if a goal isn't to remove some unused cruft from Chrome on platforms (like Windows) that don't tend to have Gtk+ libs lying around. I doubt Chrome uses more than a tiny fraction of the Gtk+ functionality.
- why don't we just let the free market do what it always does, eliminates bad products.
Yeah, that really worked well with Microsoft.
It is working. A decade or two slower than would be ideal, but it is working.
Investing money in securities is typically about as useful to the economy as stuffing it in a mattress.
When I buy $100 in Google stock, that money just vanishes as far as the economy is concerned (well, modulo the 30% broker fee, of course)
Again, this is wrong. For one thing, note that broker fees are on the order of fractions of a percent, not 30%.
When you buy Google stock from Google (i.e. during an IPO or subsequent public offering), that money goes to the company so that it can invest the cash in growth -- that means buying equipment, facilities, real estate, hiring and paying employees, etc. That money is most definitely in circulation.
Of course Google isn't selling stock right now because it has plenty of cash to fund growth and doesn't need to raise capital. So if you buy Google stock right now, you're buying it from someone else who bought it from Google (or from someone who did; the chain can be arbitrarily long). But the point is that you're buying it from someone. As it happens, I just sold a non-trivial (for me) chunk of Google stock; there's a check waiting at home for me which I'm going to spend on building a house (well, on covering some of the early incidentals; I'll get a loan for the bulk of it). That money will buy building materials, pay constructor workers, etc. That money is also definitely in circulation.
But what if you buy your stock from a big investment firm rather than from someone like me? Is it out of circulation then? Nope. The investment bank will take your cash and put it into something else... something, in fact, that it believes will be more productive than Google. At least that's true of the value-investing portion of the investment industry, obviously there are other segments that focus on arbitrage. The money managed by those segments is more debatable, but they do contribute significantly to liquidity, which translates to your ability to buy or sell Google stock on a whim.
There are some issues with the velocity of money in the US, which is a measure of how quickly it circulates. It's at the lowest point in decades. The fed has been pumping massive amounts of new money into the system, and it's not helping. I'm not enough of an economist to really understand the issues here, but the most sensible explanation I've seen is that circulation is reduced because people are using the money to pay down debt. We had a massive explosion of velocity fueled by an extravagant credit boom, but it was unsustainable. That unsustainability was a big part of the housing crash and the recession, but we still have excessive debt and the correction isn't over yet, so velocity stays low.
With physical access and being prepared to destroy the device you can access it, but then you have to defeat the AES-256 key in the HSM.
There is no HSM in iOS devices. They do use the ARM TrustZone, which is a good thing, but is no HSM.
Nope, Starting with the iPhone 3GS, the flash is encrypted. The encryption key used is encrypted with a per-device key that's known only by the device
Yes, I know the flash is encrypted (read the thread). But the key is on the device...
You're right that the code is not encrypted. What is encrypted is the user data, which is what you want to protect.
Whether or not you need a TPM to call it "secure" depends on the threat model. Under the most extreme threat models, TPMs aren't secure, either (they aren't designed to resist hardware hacks). Under a fairly reasonable threat model which assumes the attacker can read out flash but not RAM (because the RAM contents disappeared when the device was turned off for disassembly), the Android encryption model is secure, to the strength of the user password. The decryption key is gone from RAM so the flash-based storage cannot be decrypted, and of course any copies of the data in RAM are also gone.
No, it's not "safe". It violates the first three rules of passwords: 1. Do not write passwords down 2. Do not store all of your passwords together. 3. If you do break #1, do not store your password in an un-safe location.
Meh. The corollary to your rules is "Don't have very many passwords", which means either not having very many accounts (impractical), or reusing passwords (a really bad idea). You have to compromise somewhere, and IMNSHO a good password manager -- with an encrypted database -- is the lesser evil.
10 random chars are good for 65bits. Log(92^10)/Log(2) = 65.24
Heh. Good catch. I should have done the math, or at least thought about it for another second or two. Five bits per character assumes a character set of 32, which is obviously silly.
An offline attack would require a bootrom/bootloader exploit, since you can't get data off the device while it's locked (it refuses to complete the USB handshake). Even in restore mode, USB DFU mode won't dump data, only overwrite.
Android is the same in that respect. With either OS, the attacker can open the device and read out the flash directly, however.
In the other areas you mention Android needs to improve.