jzdziarski

Literally read this while loading an old Famicom disk game into a Nintendo disk drive. Thirty years and it not only still works, it was more capable by its design. Nothing wrong with magnetic media, but good luck on your modernization effort.

Fascinating study. It would carry more currency with me if the ngrams used were learned through ML and corpus training rather than heuristics. It is assumed these ngrams are particularly useful markers today. The significance in their absence doesn’t seem to be part of the research. When there is such dramatically “off the chart” data such as this, you need to start looking under the hood at other factors. Studying individual authors would be a good start. Other factors may also include the editorial process. Publishers tend to have common nuances they like to conform to. Could the editorial process explain why some of these nuances are widespread? It’s also worth considering that technical language (computing, for example) made great leaps around this same time period and bled into common parlance. Social media, which is cited here only as a loose correlation, also altered the brevity of writing, which changed how we use and communicate language - but it’s a far stretch to call these subtle changes distortions, at least beyond letting Jack Dorsey fuck up our use of language. The authors argue that the meaning of these ngrams hasn’t changed, but their application sure has. Overall it feels like a great area to study, and as good science does, presents more questions than it does answers. There is much more to explore here though before we can conclude the entire world is depressed. I am not an expert in linguistics, but I do feel as though there is a modern element missing from this research.

First, I’m so glad this turned out to be hypothetical, and you didn’t have to suffer through such a catastrophic loss. Second, if you had actually suffered such a loss, your digital life would hopefully be the last thing on your mind, and you’d just be glad to have your life and your family - the only real things that matter in this world.

That said, planning a strategy for offsite data storage or a secondary authenticator is of course wise. A safety deposit box or other offsite location that you can frequently refresh and keep up to date would be a good investment. If you’re worried about keeping a master key to your life in a single place, you could separate your data and your authenticator. The how likely depends on your threat model, several people on this site may find it insufficient. To whatever degree you obfuscate or complicate your recovery path, you also increase the risk of losing access to it yourself.

You might also consider it’s not necessarily the “thing you have” that might go MIA, but due to physical injury, age, or just forgetfulness, the “thing you know” could also be at risk. I realize this the older I get. Finding a secure way to store a master password in the event you cannot recall it, or perhaps in the event of your death, is something you may also consider. In this case, I would avoid a cipher or something else you’re likely to forget.

I don’t even understand what we’re comparing here. Is it lines of code? In that case, you must include all of the code from tr, sort, and any other shell commands used to perform the task at hand. By that standard, Knuth still wins by a long shot. Were this an actual coding contest (if such things exist anymore), one does not simply argue that instead of coding the solution in the given language, I’m going to just use five other people’s solutions and claim my trophy. Had the argument been who could most efficiently reuse all of the resources of an operating system to produce the laziest solution that will likely produce the highest number of obscure edge cases in the future, create unexpected dependencies, and likely scale the worst, then perhaps the shell script wins. But I think Knuth was trying to demonstrate quite the opposite - good coding praxis that can be maintainable, debuggable, and made to scale. I guess what I’m saying is that it’s difficult to see any comparison here, whatsoever, since the purposes were so markedly different. The shell script is not a solution any professional would ship in a product, and would only appeal to lazy one off tasks. Who would have been daft enough firstly, to not read Knuth’s paper, but secondly to think there is anything worth comparing in the first place? The script might be the quickest solution. Knuth’s code is the proper solution.

Graham seems to have missed the mark here. What he’s describing as the unjust labeling of x-ism usually isn’t related to the deviation from a norm, insomuch as it is the prejudices behind that deviation. He argues that truth is ignored, but it’s not the truth that’s usually at issue in such matters, it is the manner of delivery of whatever truth may be, filtered through a set of prejudices the hearer is offended by. The hearer then can either utilize the thought terminating x-ist label, and walk away, or attempt to address those prejudices directly. In the former, they are saying, “because I have identified these prejudices in the way you’ve presented your case, I cannot give credence to any of the truth you are arguing”. Reasonable, but less than ideal. The latter - and often better response is, “that’s x-ist and let me tell you why.” That’s how you cut through the BS and have a productive conversation. I hope this is what he was trying to convey, but didn’t quite get there.

What he seems to have missed in separating truth from prejudices is important to recognize. This is an expected communications problem in a society that struggles with decency, and decency is what’s at issue here - not truth. Because at least one party lacks decency, they’ve lost their credibility to convey any truth. The other party may lack tolerance, but that intolerance is, at least usually, about those prejudices, and not any underlying truth.

Regardless, actual heresy - of the biblical type that Graham is trying to use to support his argument here - has historically been more based on threatening a power structure, such as was the case with Martin Luther, for example. Ironically here, the tables were turned, and the “heretic” (Luther) presented factual information while it was the hearer that reeled with prejudice. The two cases are about as much alike as a camel and a spork. I am surprised he tried to make the comparison. Nonetheless, if that is what he’s trying to argue, then he’s seemingly suggesting the fault is always on the listener for being offended. In the cases Graham is describing though, it is far more likely to be the speaker who wraps whatever truth there might be into vitriol brought into the conversation. It at least would have made for a good essay to point out both possibilities.

Tl;Dr: truth always falls victim to prejudice, on either side, which is why we should work to identify and root out our own prejudices before engaging.

Startups had unbelievable burn rates, sales and marketing teams overpromised technology, and greedy executives, who should never have been in charge of money, sought to invest millions in building the appearance of an empire rather than grow organically. Eyeballs, not earnings, was the focus. Many such companies would go bankrupt overnight. I was out of a job for six months. It was the most humbling part of my career. We almost lost everything. For a short time, we were on food stamps. I knew some scripting languages, Oracle, and systems engineering at the time and was doing mostly web based development, DBA, and server infrastructure buildout work - yet we couldn’t afford to pay for baby formula. During that six months, I taught myself C, discovered machine learning, and picked up other skills that would later open doors I never imagined would be possible for me. Hard times brought perseverance, humility, and an appreciation for the value of a dollar. I learned some of the most foundation skills and life lessons during the dot bomb.

If the aliens typed “call amazon” into google, they’d get a human almost instantly. It’s not rocket science, although aliens would be good at that too i guess.

Have been going back and forth on this. The trade off is that you lose a lot of potential to alert the user to suspicious behavior. For example, you might get promoted to give an all permission to use "your Library" (for access to certain cache folders); but if it later misbehaves then you won't see it accessing other cache folder, some belonging to other apps. On the other hand, it's still better than not using it at all, which most novice users will end up doing for a power user app (not using it).

2. We see no indicator of account compromise; current usage is consistent with past usage.

I'm calling BS. This site was disabled repeatedly for exceeding bandwidth today. I find it hard to believe traffic is as usual.

Correction: testifying against, not for.

I wouldn't call these tools "Scary" unless you're a criminal. These tools have been used to build networks of previously unknown terrorists, put murderers in jail (two of which I had the pleasure of testifying for in high profile cases pro-bono), and frequently (on a daily basis) finds smoking guns in child rape and molestation, grand theft, kidnapping, and a number of other cases to which you should be thankful that you are entirely oblivious to. If you knew what really went on in our society, you'd be helping the good guys out too. I imagine you probably have in your mind some redneck cop pulling you over and checking for text messages on your phone illegally, or some other stupid misappropriation of authority... 99.99% of the time, these tools are used for the right purposes, and against people who might be living on your street, committing unspeakable offenses in private.

Now, as for the tools, saurik is entirely correct. The PIN code is, for the most part, just a GUI lock - think of it as a screen saver lock. The file system is encrypted on the chip, but applications need to be able to read and write from the file system. If you read the FAQ, I make no secret about how this works: we boot a custom RAM disk (from DFU mode) that mounts the disk. The kernel takes care of the decryption and because we're not actually booting the OS on disk, we don't have any pesky screen saver lock or anything else to even content with, though if we did, the forensic imaging process runs entirely in the background, and has the same level of access (root) that most of Apple's processes do.

As for encryption, what IS encrypted on disk that you can't get from the file system includes keychain passwords, HFS journal (to undelete files, thanks to Jean-Baptiste's most awesome code), and files protected with iOS' data-protection classes. These files are few and far between. In fact, a vast majority of the evidence you'll find on an iPhone is entirely unencrypted. For the files that ARE encrypted, Jean-Baptiste's brute forcing and decryption tools allow us to extract the master encryption keys from the device. Each keychain password is encrypted with its own key ("AES wrap"); we apply the device's keys to this wrap, decrypt the password's key, then use that key to decrypt the password. Apple's data-protection classes are about the same. Each file is wrapped and we use one of the class keys to ultimately decrypt the file. This includes the few files on the device that are encrypted, such as email + attachments, and some third party data files using this encryption.

Once you unwrap that, you'll find that even applications using their own encryption code are storing keys in the keychain - so once the keychain is decrypted, the keys to these third party crypto stores are equally exposed.

The moral of the story here is that the only GOOD way to protect files is 1. To encrypt them (something Apple really doesn't do very well), 2. To have the encryption depend on a very complex key that only the owner has knowledge of and must supply in order to decrypt the files, and finally 3. To protect the device in such a way that the key cannot be intercepted by trojans or other malware. Unfortunately, iOS fails on all of these counts, making it very easy (thanks to many world class hackers contributing code) to defeat all of the encryption on the device, and MOST of the encryption even when the device is password locked.

Scary? What's scary here is just how neglected security is on mobile devices, and how easy it would be for me, or Saurik, or anybody who can use code.google.com to steal all of the data on your device in just a few minutes.

Thanks. Made mention of the battery or other power source needed in the home.

Thanks for mentioning the converter boxes. I forgot about that; added to the article. Unfortunately they require power too.

Technologically, this could be anybody's FiOS, or anybody's Cable.. I realize FiOS is more of a trade name, but the general design of 'fiber to the last mile' is being adopted by others too. Fairpoint I believe is also using the FiOS moniker due to deals w/Verizon. So IMO it's more about the two technologies and why one's superior in this situation.

Neither Comcast nor Verizon use POTS lines around here. Everything is routed across their cable/fiber network. While the poles themselves were down, a majority of the wiring was still intact. The power went out as a result of over 400 transformers blowing, and a manual shutdown of most circuits for safety. Enough of the lines were connected in order for Verizon's fiber to remain connected (most of which is not underground here), and the same was true of Comcast's coax... it just didn't have the signal strength to make it back to the CO without power.

This is why heuristic tests suck and statistical classifiers are superior.

I'm not entirely sure the author himself understands the difference between data and metadata. It has nothing to do with importance; rather metadata is "data about data". The author seems to think it's got something to do with a distinction between system and user data, which isn't the case. It's an important logical abstraction to make, as "data" is a noun, whereas metadata can be thought of as a collection of adjectives.

Now if you want to start discussing why "data about data" should be considered part of the data itself, that's an argument we can have... but that doesn't appear to be the goal of this article (at least if it is, he doesn't make much of an argument on that level).

Apps have been running in the background since Backgrounder was published on Cydia. And it doesn't cost anything to do so. Backgrounder lets me set up my TomTom, Flow Chat (IRC), and AMBER Alert to background themselves automatically... and my 3G[s] still runs plenty fast.

How does this factor in for the large number of people I run into who don't seem to have a brain whatsoever?

Shit.

Six weeks is not a long time to wait. I've had applications take 3+ months before they ever get a response. Google should stop acting so entitled and get in line like the rest of us.

Perhaps also is the fact that many newspapers are no longer newspapers but editorial-papers... maybe some are failing because nobody wants to read everybody's opinion, but is actually interested in finding some actual news.

$15B in sales and he makes $75k a year? Doesn't sound like a sustainable business model to me.

Arbitration clauses are getting tossed out left and right... a class action clause would likely be out the window even faster. They might as well put, "you permit us to be evil greedy bastards and screw you" in the contract... it's not going to stop me from suing them when they actually become evil greedy bastards who screw me.

I respect Schneier as a security expert, but he seems to have completely failed at conceptualizing the threats involved in using password managers. Other than your basic problems, such as malware, screen spying, and the like, whenever you use your password manager, all of your passwords will be decrypted in memory and displayed on the screen. This leaves your passwords exposes in two places. Cold boot attacks make it very easy to grab this from memory, especially on desktop machines where they might remain in memory for a good while. On the iPhone, screen leaking is of particular concern as the device has several things going on in the background transparent to the application. These include a keyboard logger which caches input into insecure fields and a screenshot utility which takes screen snaps to process animations and transitions, among other things. I've seen some password managers that input your passwords into normal, insecure fields where your password winds up in the keyboard cache in plain text. I've also seen plenty of passwords show up in screen shots taken by the iPhone unbeknownst to the user.

It's far better to adopt the good habit of committing passwords to memory, and reduces your risk of exposure greatly. And if your data is that important that you absolutely have to protect access to it, you should be using one-time passwords or RSA keys.

Hmm I exercise daily and have been more tempted to eat healthier foods, rather than undo all the work my body has put in exercising. I'm down 30LB in the past 45 days. Time can suck it.

The fact that you have PhD at the top of your list, rather than as a footnote, tells me that you don't know what you need in a designer/developer, aren't entirely sure that your concept is viable or even doable, and are likely to wind up with some mediocre corporate programmer with little experience, and even less creativity, rather than someone who truly knows what he's doing and could have turned your idea into a real product; and as is usually the case, your poor selection in a designer/developer will result in a poor company with mediocre products that probably don't work like they were originally meant to, but not before you burn all of your venture capital on his salary and numerous wasted expenses on infrastructure and partner products to give your non-working solution an overcomplicated and underrated backend.

Good luck!

I think I've worked with you before.

Yeah, and now that we know where it's coming from, please don't screw with the hum and kill us all, k?

Give me a break. How desperate are these people for news. I can write secrets to. Here's the secret code to tenthings' thought process:

if (lame) write_about_it; else write_about_it; notify_press; waste_my_time; act_like_a_dillweed;