There's minimal evidence that healthy eating alone lowers your long-term body weight. That's part of the point really. Any diet change, be it fad dieting or more sustainable health eating choices, they are all capable of short-term weight loss. Keeping that weight off on the long-term is is a so much harder problem, it's barely related to what works for losing a large amount of weight in the first place.

If you read studies about people who lose and keep weight off, like Long-term weight loss maintenance, the common factors that always show up are both very low calorie counts and constant feedback. Basically, chart your weight all the time, and cut your calories if it ever goes up. That is brutally difficult to sustain for years at a time. If you follow any sort of hunger-driven diet, with healthy foods or not, you will probably go back to whatever weight your body likes over time. That's how hunger works.

Agreed. Flash really should apply the patch, and if it fails, it should refuse to load the Applet.

None of the pages about this bug—not the article, not the CVE, and not the Adobe explanation—tell what the actual attack vector is. They just say that they're vulnerable to XSS. Does that mean that the Flash code can be used on somebody else's domain? Does it mean that the Flash code can in some way be tricked into loading content from the wrong domain on behalf of page JavaScript? If so, and if Flash code uses only non-hardcoded URLs, does that mitigate the problem?

The thing is, even if you got rid of all the insecure Flash applets out there, a malicious person could still host one somewhere. So depending on the nature of the attack, the only real way to fix it might be for Flash to deliberately break every Flash applet linked against the old SDK. If the attack is dependent upon the flash being hosted from the same domain as the content you're trying to steal (e.g. cookies), then the right way to fix it is for web developers to eradicate Flash from their websites.

Not true, not in the slightest. Google has fought hard to minimize the information they have to give to governments, and to be as transparent as the law will allow about what they do give. Remember that Google created the transparency report, and was the company that managed to negotiate permission to share aggregated data about National Security Letters. Many other companies have followed suit, but Google led the way.

No, Google has been shown to comply with legal requirements, and to fight questionable requests in court. Snowden also revealed that the NSA was tapping Google's fiber. Google responded by encrypting the data on that fiber.

Cite? Since Google is a publicly-traded company, it should be easy to point to that line item in their SEC filings.

No, told by the Chinese government to participate in government-mandated censorship or GFTO. Google participated for a while and then decided it wasn't what they ought to be doing, and so chose to GTFO of the biggest market on the planet (albeit one in which they had a small market share.

That grass-roots FLOSS development only happened after the GPL does not mean it was necessary to create it, nor even caused directly by it. Giving away free software to promote consulting and support revenue can be a profit center independently of other motives. I can easily imagine an alternate 2015 where there was no Stallman, so instead consulting companies shared boring infrastructure code to split its development costs.

Good old dictionary.com says paranoia is baseless or excessive suspicion of the motives of others. There are a few examples where I think Stallman is excessively paranoid. I personally like using the web only over e-mail to avoid "survellance". Wander that deep down the rabbit hole, and the all powerful three letter agencies out to get you will also have secret exploits for Lynx. Seriously, it's all in the Snowden documents! And I totally did remember to take my medication!

However, there are way less examples that seem extreme like that today then there used to be. Re-writing your hard drive firmware with secret monitoring tools? In 2015 evidence that might be happening is reasonable news, not paranoia.

I've seen plenty of examples of companies who do not want to share code unless compelled to. There are software compliance tools for lawyers whose main purpose is checking corporate source code repos to make sure there's no GPL code. But the number of corporate contributors to all the BSD distributions says the GPL is not mandatory to develop open code. Did it help? Sure. I think open source software as a way to share overhead on boring infrastructure code was inevitable though, even if there was no "free software" (tm).

The world could have collaborated and built the modern Internet just fine on BSD licensed software, which is itself a variation of public domain. What Stallman deserves credit for is inventing the Copyleft license as a way to compel source code sharing. He's stayed relevant beyond that as source for paranoia about software being used against people, a stance that looks more prescient each year.

The problem with the PHP community is that it's filled with the kind of people who feel it's good idea to work on PHP.

And recently all over again with the EDM kids and their Javascript. My lawn, etc.

It doesn't seem to have a significant impact, AFAICT. I haven't benchmarked with and without, but at leas on my Nexus 6 I didn't observe any obvious decrease in battery life when I turned it on.

Uh, no, this can't work. Security settings changes require password authentication, and there probably isn't an app API to change them anyway (for good reasons).

I've been using this feature for a few months now (I work for Google) and I think on balance it significantly improves my security. It means that I can set my phone to lock instantly on display timeout, with a one-minute timeout, lock instantly on power button press, and use a long, complex password... and not be inconvenienced by having to constantly re-enter a long password. This is a security win, because if I did have to enter a long password two dozen times per day, I wouldn't do it; I'd choose a simpler password and settings that lock my device less aggressively. Even better, I find myself subtly encouraged by the phone to keep it in my pocket, rather than setting it down on tables, desks, etc., because if I put it down somewhere I'll have to re-enter my password.

If I were mugged, I'd just hit the power button as I remove the phone from my pocket. Actually, what I'd really like to do in that case is to power it down, but I'm not sure I could get away with that, since it requires holding the power button for a couple of seconds, then tapping the confirmation dialog. Since my phone is encrypted, getting it into a powered-down state makes my data quite secure. Not that the lockscreen is necessarily easy to bypass, but it's part of a large, complex system, which means there's a lot of attack surface. Once the device is powered down, the risk model is very simple and well-understood: If the attacker can't guess my password, he can't get at my data. Thanks to the hardware-backed encryption used in Lollipop, password guessing is rate-limited by the hardware to a level that would require, on average, about 70 years of continuous trials. Even if the attacker were that patient (a) nothing on my phone would be worth anything after a decade or so and (b) I doubt the device would last that long. Mobile devices aren't built to run flat out for years.

I've also used the bluetooth proximity Smart Lock, paired to a smartwatch, but I've decided I like the "Trusted behavior" feature better, so I've stopped trusting proximity to my watch. The range on bluetooth is large enough that I can set my phone down and be far enough away that someone could use it but still within range for keeping unlocked. Plus, I really like the encouragement to keep the device on my body. In the long run, that user training will, I think, do more for my device security than anything else.

I do still use bluetooth, but paired to my car's bluetooth, so I can put the phone in a cradle or on the center console and have it stay unlocked. I also set the phone to trust proximity to the bluetooth headset I use when cycling, because I put the phone in a cradle mounted on the handlebars and want it to stay unlocked as I use it to track my ride.

The discussion on this thread about phones being snatched from hands, though, makes me think that perhaps I should re-enable trust of my smartwatch. That would address high-speed theft pretty well. I just tested and taking the phone out of range of my smartwatch does lock the phone, even if it's in my pocket. So a thief couldn't just grab it from my hands and drop it in their pocket to keep it unlocked.

However, this means I lose the on-body self-training. I suppose if I turn the smartwatch linkage on only when I'm outside my home or office, I'd get the on-body training most of the time but the smartwatch linkage all of the rest. Hmm... I wonder if I can create a Tasker profile to automate that...

The proximity sensor (same one that prevents you from hitting buttons with your cheek while talking on the phone) should turn the screen off and disable input without locking the screen when it senses your leg/hip.

Does she prefer monolithic or microkernel?

Err.. the only thing any driver really does....