While there is extensive infrastructure for detecting active transmitting devices like Stingrays, there's no discussion (or tooling) around passive IMSI grabbers. These devices are significantly more limited (no IMEI or MSISDN, GSM-only), they remain pretty effective in areas/networks where GSM is still in place.
For what it's worth, PBS has an app[1] for Apple TV, and it has much of PBS' content.
With that said, the general problem of certain services being restricted from/to specific platforms is extremely frustrating, and will only get more painful as exclusives become common.
I'm not convinced this localization argument holds so much water. Consider the following:
Case 1: If you're using a search engine not based in the US, and you're not a US person, then the NSA probably can't use any legal tools against you (depending on country). However, the NSA is allowed to use the full range of its capabilities to collect against you (PPD28 notwithstanding). They can infiltrate that service by technical or human means and carry out espionage activity without legal restriction (Title 50/EO12333). Further, they can retain the data unredacted for a long time.*
Case 2: On the other end of the spectrum, if you're a US person and you're using a US-based search engine, surveillance activities against you are far more complex. Warrants, NSLs, and/or other legal paperwork is involved, and there are strict rules on data retention, sharing, and minimization. That's not to say that there isn't surveillance, just that it comes with substantially more overhead. Meanwhile, most of the NSA's technical exploitation approaches are off-limits, and any collection/exploitation activity must be carefully managed.
Case 3: The intermediate case, where you're a non-US person using a US service, is a bit more hairy but still is better than the first case. While the NSA/FBI can utilize a range of legal tools (again, warrants, NSLs, etc) against you, because your data is likely entangled with US-persons data, it must also deal with all the overhead of minimizing and redacting that data (same as case 2). Similarly, the use of technical means against US providers is heavily restricted, so you won't be fighting against the same capabilities as you would be in case 1.
At the end of the day, which do you think is easier for the engineers at NSA: exploiting, entering, and just taking everything (case 1) or filling out a huge amount of paperwork and carefully handling the redacted scraps of data that comes back from the provider eventually (cases 2 and 3)?
I think you can make an argument for either side, but I tend to believe that technical exploitation is easier than legal, for now.
*Caveat here is that this intelligence data is hard[er] to use in US law enforcement activity against you. It's worth noting, however, that NSLs and FISA data are also non-trivial.
Maybe I'm just out of the loop, but the author doesn't make it clear what exactly is objectionable about Palantir with respect to privacy issues. That's not to say that there isn't anything, but just that it would be helpful to have a synopsis of what exactly they're doing wrong.
I understand that they do work with governments, but that's as much as I've seen in the press. There has been far wider discussion of the privacy challenges facing Facebook and Google.
Neither the F-35B nor the F-35C carries a gun. The USAF's F-35A is the only model affected by this issue.
Also, the Marines want the STOVL F-35B for operation on LHA/LHDs, as well as small island bases with short/limited runways. It's not just the ski-jumping Brits who want that feature.
With that said, you're right that the STOVL capability has added substantial complexity to the airframe.
If you find the work in cancer interesting, it's worth looking into a few commercial outfits that are doing this type of testing:
* Genomic Health ($GHDX) with OncotypeDX
* Foundation Medicine ($FMI) with FoundationOne
Both of these companies have tests on the market that analyze tumor genomes (sequencing or microarray-based) and provide information to oncologists to better treat their patients. Information like drug efficacy and tumor aggressiveness (requiring chemo-/radiotherapy).
Your explanation is clever and could account for most of the behavior of the product. Certainly the environments, rapid booting, and even hot resizing.
What's missing, however, is how they do machine state snapshots (not supported in any container system afaik). I know Xen/VMWare support these, but if they are running atop AWS they will not have access to the hypervisor. I can imagine kludgily running another hypervisor atop AWS, but there would appear to be a more clever solution.
Xen/VMWare also support hot resizing of CPU and RAM.
What's interesting is that neither LXC nor Docker support memory snapshots (machine state), which Terminal.com has demonstrated. Xen, KVM, and VMWare do, but I can't really imagine people running these atop AWS infrastructure (Xen underneath).
Your demos show impressive speed in booting, machine resizing, and snapshotting. Kudos.
With that said, several hypervisors do support hot-resizing, snapshotting, and cross machine migration. Xen has excellent hot resize support, where VMWare has pushed hard for live migration and proper snapshotting over the years.
That 15 years of experience at one of the world's top software companies is seen is a negative disgusts me.
It seems disrespectful to judge an employee based on the negative perception of an entire company. For all the broken things within a company like Microsoft, I think it would be foolish to mark the company's talent pool as tainted.
Perhaps this reflects a subtler form of the fanboy-ism that exists in technology culture today. The sentiment is that companies we dislike must have incompetent employees. Competent employees would surely build a better product, right? Obviously this is naive.
Absolutely right, ageism plays into this as well. If you're hiring, keep in mind that, while fashionable, it is illegal to discriminate based on age. I wish this law was slightly easier to enforce.
While I am aware that this is the reality, I find the attitude underlying this reality rather unfortunate.
As an interviewer assessing a candidate, I would like to believe that I'm thoughtful enough to see that corporations lay people off for any number reasons. The macro-scale conditions at Microsoft likely have no bearing on the candidate's quality.
Imagine if the candidate were from RIM. We'd hardly question the reality that RIM has to lay off people, many of whom are competent.
In the US this doesn't make sense (for most people), unfortunately.
Employers offer group plans which tend to be much cheaper and offer substantially better benefits than individual plans. The larger the company, the better the arrangement tends to be.
COBRA is designed to fill in that coverage gap when you leave, but as others have noted in this thread, it is not always economical.
The SA-11 'Buk' TELAR (9A310M1) was indeed designed to be used as part of a broader system including C&C, dedicated launchers, and the 9S18M1 radar. It certainly requires trained personnel to operate.
With that said, the Buk was also designed to surpass its predecessor('Kub') by incorporating a fire control radar into each launcher (TELAR vs TEL), so that it could operate with some autonomy. The original idea was to allow the whole SAM network to track multiple targets independent of the 9S18M1 radar, which would focus on detection and delegation.
This capability also enables an autonomous TELAR unit (as the various images and videos are showing) to target an aircraft at a range of 3-32km, much as people are hypothesizing happened to MH17. It is plausible, although far from certain.
AWS definitely dogfoods, to the point where people have to be careful internally to not create circular dependencies (this nearly happened to me once).
I think there's a notion of persistence in AWS' leadership that propagates through the teams. AWS is willing to fight through the early painful years for products to see them arrive at the stage that EC2/S3 have attained.
Webhooks would address this challenge for a certain class of applications (those with their own server component), but if you imagine building a solid desktop email app (APNS/GCM not used), then you have a problem.
Flipping through the documentation, the RESTful API seems to only allow for polling for new messages (deltas via the sync protocol[1]).
While I'm glad that there is a delta-API, I'm concerned that this doesn't support proper "push" notifications for new messages. This is a valuable feature of Exchange and IMAP[-IDLE](where supported).
I understand that the heterogeneity of these push protocols makes it difficult to expose a push API, but it seems an important feature of mail clients.
Similarly, it seems that REST is not quite the best protocol for the "push" piece of modern email. I suppose long-polling support on the Sync API would work fine, however.
I filed a patent at age 16; there are no laws governing how old you must be to file, and rightfully so.
While you may stereotype young people as being unready to write and file patents--and perhaps many are--at least some have developed the right skills and technical knowledge to do so.
Judge the patents on their own merits, not their authors.
Excellent product; I've used ExpanDrive in the past and it works remarkably well.
Curious--any chance you can put together support for OneDrive for Business? Microsoft currently lacks a proper client for that service on the Mac, and it's a minor pain.